I never noticed `runcon` before, it and `chcon` seem decidedly out of place being in core-utils, being that they're a) linux specific, b) SElinux specific.
Decoded: GNU Coreutils
31–40 of 56 posts
Re: Decoded: GNU Coreutils
#32I'm not particularly interested in coreutils per se but this is a super-interesting way to look at any piece of software. I just _love_ the block diagrams... why can't source code look like this?
Great work!
Re: Decoded: GNU Coreutils
#33I'm not particularly interested in coreutils per se but this is a super-interesting way to look at any piece of software. I just _love_ the block diagrams... why can't source code look like this? Great work!
There are languages that model code like this. Using one for a while will likely teach you why. If you think "spaghetti" is an apt description for text code, wait until you see flow based code that's evolved in place for a while.
Re: Decoded: GNU Coreutils
#34I'm not particularly interested in coreutils per se but this is a super-interesting way to look at any piece of software. I just _love_ the block diagrams... why can't source code look like this? Great work!
There are languages that model code like this. Using one for a while will likely teach you why. If you think "spaghetti" is an apt description for text code, wait until you see flow based code that's evolved in place for a while.
In the best of those languages the user is getting input and output through the diagram in realtime. Also, syntax errors are either removed completely or converted into runtime errors.
These features allow the user to iterate rapidly through the development process to create a prototype, perhaps even gaining an average 100x development-time increase over using a compiled text-based language. The spaghetti is evidence of that-- the user moved so quickly that they were able to hold the relevant abstractions in their short term memory to produce the final write-only diagram. And at least in my experience, the final write-only diagrams tend to work to produce the desired output, even if they were written a decade ago.
In fact if there were a button users could push to "abstractify" some pre-spaghetti sub-diagram I believe that would negatively impact the language. The point is that when you've got mental model of all inputs and outputs within a single page visual cheat sheet, you can instantly connect any input to any output to take the next step in the development process. For certain domains like audio synthesis the fact that the user can leverage the diagram-based system to get any output at all is worth the seemingly prohibitive price of write-only programming.
Re: Decoded: GNU Coreutils
#35This is fantastic work!
Re: Decoded: GNU Coreutils
#36the diagram is really nice,is it done by dia?
I use dia once a while, and wish freeplane could draw arrows between its nodes as freeplane is easier to add child nodes.
Re: Decoded: GNU Coreutils
#37Interesting project, this would make a good teaching tool for people interested in more operating system interaction. On the website it would be nice if you had a way to flag which ones were fully annotated. But I like the main page design. The block graphics on the flow is very helpful. You've done some very nice work here.
I had considered rewriting a few of them in Python as an exercise. But, I’ve never really gotten around to it, and I’m not entirely sure it would be that useful to do so, so, I’ve held off.
Re: Decoded: GNU Coreutils
#38I've been trying to contribute additional flags for some coreutils commands, but I've been having trouble building on macOS. Should I use a certain VM or container instead? Does anyone have a link to instructions for building on a mac?
Re: Decoded: GNU Coreutils
#39Interesting project, this would make a good teaching tool for people interested in more operating system interaction. On the website it would be nice if you had a way to flag which ones were fully annotated. But I like the main page design. The block graphics on the flow is very helpful. You've done some very nice work here.
Agreed, this would be very beneficial to students and people learning C.
I have used the source code for Plan 9's core utilities as a teaching aid for students learning the basics of C and operating systems to great effect. I have found GNU's tools to contain a lot of "cruft" to make them run fast, which is not necessarily conducive for those who are not familiar to why they work.
Re: Decoded: GNU Coreutils
#40Earlier quoted context omitted.
Reminds me of a time at a large animation studio where I was working on performance issues with the in-house asset management system. The asset management tool was fully commandline based, no GUI. An artist showed me what was involved in committing their scene: launch the command, type yes, hit return, wait about 30 seconds, type yes, hit return, repeat. I piped yes to stdin and it ran for 47 hours. If you need a per…
yes(1) takes a custom "expletive", so in the performance context it's usually used for flood filling in situations where e.g. /dev/zero or /dev/urandom are not appropriate sources for some reason.
yes outputs newlines, though, which makes it somewhat annoying to use for flood filling in practice.