Trainwreck Design
j3s.sh
j3s.sh
Improving this stuff isn't happening because no one is funding the work. A hobbyist or gainfully employed contributor stealing time from "real" work can't manage this anymore: complexity is too high now and the gatekeepers aren't -- for good reason -- going to tolerate naïve contributions.
There is very little money in the Linux world for anything a Linux distributor or hardware manufacturer doesn't care about. The former care only about the high value features people pay license/subscription/support fees for, and the latter just get drivers working, and maybe rework a kernel subsystem when absolutely necessary, and leave the rest.
The money exists. The Linux Foundation collects a quarter billion a year, for example. But they've found a long list of better priorities to spend it all on.
I don't know about the "trainwreck design" concept. There is nothing here that can't be solved given some hard headed refinement. It's just that no one is doing that.
My first instinct was to answer your question with a question. I'll avoid that.
In the real world of devops, whatever you might have in mind as not "naked eye," fails. Deeply isolated systems, embedded systems, development environments, headless systems, virtualized systems, etc., don't have working GUIs, complex input devices or other high fidelity tools. You get a terminal. The terminal tools are the ground truth when all else has failed. They need to work. And when they work in a usable manner they're wonderful: you can deal with complex tasks and issues over absurdly slow connections, tunneled and bounced through a endless chain of hosts, with no client side capability beyond a terminal emulator. This is one of the key benefits of the UNIX legacy and a reason it has proliferated to nearly every application.
Having answered your question directly, I'll ask mine: what, pray tell, do you recommend that meets every requirement stated or implied above?
There's a new wave of Rust based tools. Things like sd instead of sed, and fd instead of find. I think they have an opportunity to fix these things. They're not built in right now, and probably won't be anytime soon. But maybe eventually they will be.
Although, on a different note, I don't think they follow the hive or cathedral design that this author discusses so maybe they will end up with their own lack of cohesion.
I really wish we'd stop naming things `a`
Hyperlinks are the cornerstone of the web. Don't be afraid of using them!
The difference between them and a simple hyperlink is that they can and often will provide some additional context, that is out of the scope of the original text. Ideally on a website meant for computer screens you wouldn't have them on the end, but in the margins, next to the information, but for short stuff it is okay to put them at the end of the chapter – bonus points if the reference numbers can be clicked and take you to the foot note, extra bonus points if there is an arrow taking you up again.
But this is scientific literature style writing, not everything needs footnotes.
<a href=“Foo” title=“go to Foo” />
"hover" has no meaning on touch-based interfaces.
It's possible to 'link' to a html tag, so the page jumps to the bottom, where the additional context is, much like wikipedia does
Hyperlinks would be convenient, but something about the raw text / ascii art vibe makes me happy everytime I read a blog post from j3s even if it doesn't have the conveniences of the modern web.
It is clear that the author is very explicitly going for the aesthetics of a terminal, given that all formatting of the text is ASCII based down to the line length being hard coded as if we are dealing with a hard limit of columns.
Personally, I'd prefer something more like this: https://www.creesch.com/dump/img/img_66c3127604542.png.
The output of df and mount shows the truth as it is: raw and shitty. Don't dumb it down. Your version of usability might be my idea of a nightmare. I like the raw truth, ugly as it is. If I or anybody needs a `tiktok-disk-usage --fancy` we'll conjure one up. Are we tech or what?
It is exceedingly easy to filter the output of said tools. Nothing to do with money or incentives. It is a completely solved "problem" for the people that need it and are capable of "solving" it. Maybe you should opt for a "desktop environment" that "manages" your stuff so you can have a nice set of disk percentage indicators? I hear good things about "Windows".
Also, a substantial amount of this problem is just systemd. Don’t shit on df, which looks fine on, say, BSD.
This is not for the “average user” IMO.
> The output of df and mount shows the truth as it is: raw and shitty.
Is pretty much the point they are making about Trainwreck Design. They are using their output of df as a talking point to illustrate the issue.
If you want to call out design shit then just call it what it is: systemd. Leave df out of it, the poor fellow. Mount also has nothing to do with it.
I still think it means you are missing the overall point of the author thoughts by focussing so heavily on them using df as an example.
The underlying reason for this mess is that several popular tools, especially in the systemd and containerization-adjacent space, are built on a bunch of non-standardized userspace hacks (e.g. per-process tmpfs chroot jails) that pollute the mount table of the host system. That is the trainwreck.
Where was that demanded?
> It is exceedingly easy to filter the output of said tools.
This is provably false. Consider the content of Linux file systems. There is no one tool to simultaneously observe conventional POSIX properties, ACLs, capability attributes, selinux properties, AppArmor references, etc., to which you might apply a filter. So you have to repeatedly create your own, half-baked, inefficient, throw-away correlation tools on the fly in what little time you can spare.
Why? These features didn't appear last week. Most are older than a lot of people coping with this stuff. I answer that question here[1].
This implies both tools need to adjust to reality - aka systemd bs - to make it easier for the user. Also known as dumbing down. I concede it is not explicitly requested, but it’s not that much of a reach TBH.
It is provably true that the output of df and mount is exceedingly easy to filter. You don’t even need tools to do it.
I don’t care about AppArmor and other BS because I am not on Linux. Those weren’t part of the discussion anyway. It is about mount and df and the author explicitly called them out for failure to be “easy”.
user@hostname:~$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 1007G 49G 908G 6% /I find it weird that despite having a bunch of options to control output and even filter things, df does not have an option to specify "show me only physical block devices and only once (my /dev/sda4 shows up for various mountpoints but still all show the same size/used/avail values)".
On my machine, none of the snap/tmpfs/efivars stuff shows up:
user@hostname:~$ df -ht ext4
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 1007G 49G 908G 6% /You'll google it and find 10 different ways for 10 different distros, and most of them will require doing byte math (but you're not sure if KB is really kB and 1000 or 1024). If you get it wrong your computer blows up (probably).
And if you think resizing was hard, try to defrag and shrink one!
[1] For example if you install RHEL using wizard it will create a bunch of virtual logical areas that each have partitions allocated that each have disks allocated and if you want to resize them later you have to resize the onion all in the correct order.
It'll require root, yes. But in Windows you're already "root", so it doesn't count. No, "permission elevation prompts" doesn't count. You're still defacto Administrator on that system.
BTW, none of the CLI tools allow you to overlap partitions or shrink below used percent. So you can't blow your data up unless you try really hard (like fdisk delete/recreate tricks).
Systems like Raspberry Pi make these things easier, too. They both have docs, or you can do on your system with gparted already. Also, as I aforementioned, none of the CLI tools eat your data unless you force them to.
Lastly, all the tools accept KB, MB, etc. as prefixes/suffixes. So, I rarely make back of the napkin math for these things, if ever.
> But for example if you installed Red Hat CLI-only version, it's probably so hard you'll give up and just ask Red Hat support to look at your logs and send you the commands to run.
Actually it's not hard. You only need to know that you have your filesystems in a LVM (Logical Volume Manager) container. Unless you're not changing the size of the LVM volume, it's the same thing, only the device name changes.
If you're adding disks, you need to first increase the LVM size to span the other disk, and add or resize your partiton there.
It's not intentionally hard, you meet with a layer you generally don't see everyday. Even if you boot a LVM containing system from a live distro, say GRML, you only need to "activate" the LVM container with a single LVM command, and it's the same thing after that point.
It's a matter of thinking in layers.
If by any chance someone knows the tools that were used to make the big-font subtitles (or the whole page?), enlightenment would be highly appreciated!
Yes, vscode and plugins can do everything. But Phpstorm integrates everything into one coherent package. Too many random directions is more annoying.
In terms of software dev, it's quite hard to get a good app wide experience. There's just so many people working on the project. Without someone to make sure things are aligned, things fall apart into random wild patterns everywhere.
alias dfx='df -x nfs -x none -x smbfs -x tmpfs -x cifs -x tmpfs -x fuse.sshfs -x devtmpfs -x squashfs' alias dfx='df -x nfs -x none -x smbfs -x tmpfs -x cifs -x tmpfs -x fuse.sshfs -x devtmpfs -x squashfs -x overlay -x efivars -x nfs4'It does what mount and df do, only with more options and filters. It is part of mount -- IIRC today's mount just runs findmnt --mtab under the hood -- and therefore available on all modern Linux systems. I guess the article's author would have been happy with
findmnt -s -D -e
findmnt --fstab --df --evaluate df -h ~Linux : Everything is a filesystem
For example if the overwhelming majority of users use df to get an overview of how much disk space they are using and how much they have left, the default option should be giving you a easily digestable output of precisely that.
I get that in terminal-land this can be a problem, as the default df command is now probably parsed by a thousand shell scripts and chaninging it breaks things. But that is also bad design: If there are hard reasons like that that could conceivable lock you into doing it a certain way, you should warn against it and offer a stable alternative (stderr: "The output of df -h is not meant to be machine readable, use df --machine instead"). Again frequency is the guide here. People will more often type df -h to manually check things than they have to write df --machine in a script.
Same goes for the default output of ip a (which in my opinion should be more like ip -br -c a).
The other day I took the output of df -h and gave fed it to an LLM, asking, anything stands out here? It helped.
That being said, Claude turned no fun. [0] I remember back when ChatGPT first came out, I'd say `ssh root@mainframe.nsa.gov` and it came up with some interesting outputs.
mount | column -t …
df has a switch to exclude types like tmpfs, mount can use grep -v, etc. Make aliases.
[1] We have inside-out retinas, why did we not get them the right way around just like squid have? Why can we not synthesize vitamin C? OK, we evolved somewhere where it was available on every tree but would those few extra genes have bothered us? The dog under the table has them, why not we?
Perhaps one may learn to remember <df> and <ls -a>, but will definitely not care to produce by heart oneliner bash abominations sprinkled with sygils and pipes and three-char cmd names.
This whole article very true, but somewhat irrelevant to 2024. Claude/Mistral/CHatGPT been parsing outputs perfectly, and there are plenty of experiments into getting the LLM to assist code writing and parsing results directly from the cmdline. And you know what, this also works in 100% console mode, you don't need GUI to talk to the new GUI called LLM.
the smaller models get, the sooner they get embedded in shells. then you'll get the real Ghost in the Shell, yeah...
besides this comment of yours is exactly what was expected as a first response, and is very boring.
The good ones will produce more reliable code than current LLMs. But on average, I don't think so.
Maybe it has to do with strings not really having been a first class citizen in C? Processing strings in C is a (dangerous) pain even in the year 2024.
I often find myself just writing python scripts calling subprocesses (if needed, so much is already included), ideally with a --json option so I get proper machine-readable output. This has shown to be far more stable and reliable than bash.
The author is complaining about inconvenience. If I'm in the shell, and I want to see how much disk space I have, asking a LLM for a command then running the command then asking the LLM to parse it is still inconvenient, compared to just typing "df -h" and getting a reasonable output.
The fact that Claude or whoever can parse that output seems irrelevant to the article as I understand it. "AI" is not a magic silver bullet.
All I’m saying is long prompts of shell progs that you need to use once or twice are easier written in the newskool way, not that proper output of common programs is bad idea.
But I really can’t imagine anyone or anything convincing thousands of devs to conform certain format. Really a wet dream today unless started so from day one. Only big players can do that.
The year is 2024 and I need to give a presentation. I walk up, plug the HDMI cable into my laptop. On my Xfce desktop, a window pops open with 4 buttons: Laptop only, external display only, mirror, expand. I choose "mirror", the desktop is resized to the smallest common size and it "just works". Unlike the next person who has to futz around their Windows settings for a few minutes and afterwards asks me excitedly what that tool was that I used.
Of course then there is also that one guy who fidgets around on stage for 10 solid minutes, before we are treated to a tiling window manager with eleventynine terminal windows and a hundred nervously fat-fingered xrandr command lines. Everyone in the audience chuckles and shakes their head "Linux people, typical...", and the guy on stage, already sweating blood begins the presentation.
But I guess you just gotta have your command line and complain about it too.
Lol exactly. These people cause everyone else to think that's what Linux is like in 2024...just because you can doesn't mean you should, especially with the OP. Why use some arcane commands instead of the easily, single glance solution? We're not talking about advanced power user cases, just a simple day to day check...
To align with the colorful analogies in the article, governance in The Hive is 'draw the rest of the fucking owl' here. Ahem, what is distributed consensus?
I have quite a few ideas about that, but they remain to be tested (Define a voting pool, let everyone vote for everyone, run a PageRank, publish the top 20 Queen Bees, let singleton decisions be taken in Queen Bee committees, decay votes for renewal). Let's call it "Human Staking"? Surely some research has already been done about that.
https://askubuntu.com/questions/162391/how-do-i-fix-my-local...
what sticks out to me is there is no definitive answer. every answer is different. I'd have to already know the correct answer to know the correct answer
Further, I've never done anything out of the ordinary on either Ubuntu nor MacOS. Both are standard setups.
How can it be 2024 and I'm running into issues like this?
_obviously_ he's looking too low level. That's why there are layers, apps, tools, that ride above that low level and summarize it for different perspectives.
We need the full information, mostly raw, at the low level. Then we can choose what to do with that information when presenting it to users.
I can think of a load of small ones like Hare, Suckless tools, etc. But no big ones (not necessarily an argument against it working though- could just be me not knowing any)
That said, anyone know of any good alternatives that parse it into something actually -human readable?
People forget that Nature's default is to devolve to the chaos of the jungle (beautiful, but does not work toward any human purpose). The absolute best human designs are those controlled by benevolent dictatorships with a ruthless focus on simplicity. Nature's default is for every garden to overgrow with weeds, unless a gardener keeps at it relentlessly. Eventually the weeds become a beautiful jungle, but the absolute worst gardens are those designed my multiple competing gardeners. Either have 1 gardener, or 0.
See also the incompetent clusterfuck that is the European Union.
I also noticed the /var/credentials/ mounts showing up recently; that's for a systemd feature that neither I nor you actually use, to set encrypted secrets for these services in a way that is exposed only to those services via a centralized framework. If you didn't explicitly use it, it's all empty. But it started years ago with the mounts for efivars, pstore, binfmt-misc, kernel/debug, kernel/security, etc. Sure they're useful sometimes, but they shouldn't be enabled until you have a need and then explicitly enable it. Well, that's my preference, so I always start with minimal debian or arch linux, but even on such minimal systems that have switched to systemd, you get all this stuff enabled and mounted by default.
If you're actually using a tmpfs mount, like perhaps just one on /tmp, then you do want df to tell you how full it is. The problem is that you have 20 fs mounts that are truly useless to you, and IMHO should not be there. And ironically I think systemd developers do have a strong opinionated design vision, and if you don't like it you can pound sand (or use void or alpine for a desktop system I guess), because they have successfully taken over the vast majority of the desktop and server linux ecosystem. Anyway I still like linux for the flexibility I have elsewhere in the stack to make it work the way I want, reasonably conveniently for me.
(Many would think I'm an idiot for not appreciating the brilliance and necessity of what systemd has done, but for a completely different angle about systemd I recommend: https://blog.darknedgy.net/technology/2020/05/02/0/ (seems tls cert expired a few days ago, but it's fine to ignore))
- df -h /
- ip -brief a s
- mount -t ext4 (or whatever you usually are using)
I’ve filed bug fixes on a handful of projects and tracked open issues on quite a few, and the stream of inbound PRs is often so random. Not just bug fixes but new features. Where’s the plan? Whats the scope? Which of these PRs is likely to land? Can anyone but the maintainer guess?
In the end users lose anyway
(ok the analogy starts breaking down at some point but you get the idea :-P)