It's insane that I can have a conversation with this thing and in a few moments and a few back and forths build a working program in a language I know nothing about (I don't know Go)… don't tell me this isn't huge 😳 #golang#chatgpt
@juliank I wanted to do something like that and realized that at the end of the day people handle lists better than graphs. I would render it as a list of direct and indirect dependencies. Graphs of even tiny size quickly render into illegible artwork. Unless you want to invest in a kick-ass layout, rendering and navigation widget, avoid graphs.
@matk@juliank the problem with graphs is thatvyou need useful user interface for the worst case. Nail that before touching the easy cases. This is why I think lists are better for communication with humans.
Here is a comparison of the new apt(8) UX vs the classic apt-get(8) one for the install command.
Not duplicating the listing for dependencies means that despite having more padding (of sorts) it actually is comparable in length, but much more readable.
The working branch of my userspace parser for binary #AppArmor profiles that are usually parsed by the kernel can now parse any profile I throw at it.
I don't do the DFA unpacking and analysis yet but given that I'm stuck at home (extreme allergy to whatever is in the air recently) I think I will get to that today.
I've been working on improving visibility into what apparmor_parser compiles by effectively de-compiling it back to human-readable data.
@roddhjav AppArmor has very little visibility into the userspace-kernel interface. The best you can do is run apparmor_parser with the dump option to see what the parser claims to do. The second problem is lack of up-to-date documentation that's readable and accessible.
The goals of the project are:
Document the userspace-kernel interface in detail
Provide a 2nd implementation (apart from the kernel) that reads binary profiles and displays them in human readable format for debugging
@roddhjav apparmor has, sometimes, surprising semantics and as a part of figuring out where the problem lies, the text profile, the included base/abstractions, the compiler (aka parser) or the kernel, one has to figure what the binary profile actually says. Once that is demystified it is clear which side is wrong: userspace or the kernel.
@drewdevault, how can a business close something that was not entirely owned? It cannot.
It must start with the same owner releasing something significant enough to warrant asymmetric contributions (small) from the wider community.
You can argue that over time, this is immoral, but the basic stance is too strong as the owner had every right to make that decision, and all the participants understood the deal.
@drewdevault, but then you also say that all the contributors participated in immoral activity, and I think you can not make that claim for them without taking their agency away.
@drewdevault no, it's really just a business model: someone hires a bunch of people to create some software and then releases that under *GPL + CLA hoping it gets popular and can be sold (either as a service or as license).
There's no moral part there yet, it's just a decision to operate in this specific way.
The moral decision is individual making the contribution. The rules are clear.
@drewdevault the contributors are not ignorant and CHOOSE to play along.
They could have forked but didn't.
The non-free angle is entirely up in the air: it's possible, I totally agree on that but it's not guaranteed. Only certain types of software is susceptible to being closed as a SAAS.
GNU requires CLA for entirely different reasons but it's (more or less) clear why they do that.
In both cases the contributor chooses to contribute under the rules set out by the project or fork or not.