The point is that there was basically no reason to totally kill Wordpad in the way that they did. They're different products and the new Notepad is closer to the ideal version of Wordpad than what Notepad is supposed to be, and now there's no Notepad.
I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Your points are well taken. Linux is far from perfect and people shouldn't worship it. sysvinit is inferior to BSD init in my view and there are other questionable design decisions.
The biggest problem is that people are being railroaded into one thing or the other by the strong arm of corporations instead of being given options. My system helps with that.
I won't support systemd/wayland/etc, but others easily can add that in to their version of the distro if they like and support it themselves without too much work, as it's designed to be forked by anyone.
Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.
Yeah, it’s so tiresome that other people have a philosophy different from mine which seems to have prevailed for now. Like ok so sorry. Systemd on linux is the worst of both worlds imho which apparently according to GP to which I’m progressively less entitled. I like NetBSD and its rc init and config system. Oh no systemd sore winners incoming!
> Not once in my career have I experienced a showstopping issue with systemd.
Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.
I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.
> and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
I'm afraid I don't have a reference. The combination of the facts that the bugs are always damn obscure, there are so many Github Issues filed against systemd/systemd, $DAYJOB keeps me so busy with a huge variety of tasks, and the inappropriate lack of giveashit demonstrated by the project maintainers made me so angry means that the details just get blown out of my head.
> ...we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
To whom would these issues be raised to? Based on my personal and professional experience, the SystemD maintainers (and -for those who are paid to work on the project- those who manage them) seem to disagree that "eliminating sharp edges" is a big priority!
Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.
My experience, and the common experience I’ve read, is the exact opposite. Run scripts worked. They always worked. They were simple. I’ve run into so many difficulties with systemd, on the other hand. I gave up managing my own server as a result.
I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.
thanks for the clarification on how the kernel development works.
do you mind expanding on what is the benefit for companies like Microsoft, Google, IBM, Red Hat, Meta, Oracle, SUSE, Canonical, Amazon, Nvidia, AMD, Qualcom, Samsumg, Broadcom, Cisco, arm to spend an enormous amount of capital, both employing individuals to work full time on the kernel and making donations to cncf/linux foundation?
Certainly all of the big players behind linux have our best interest in mind and certainly NONE of this companies have some history of making decisions in detriment of consumer agency and freedom.
I would love to hear more about how linux is driven by passion and generosity if you don`t mind, please share!
I fail to see your point. Kernel development by the aforementioned big players benefits everyone and is all done in the open. Hence, "open source". In fact they use a public mailing list to submit patches.
All of the patches are auditable. If I don't want a patch, I can *trivially* omit it from my kernel before compiling.
How exactly are open source kernel modules and drivers affecting my freedom?
Why rethink tools that have existed since the 70s and function predictably for a landscape that drastically shifts every two months? Seems shortsighted to me.
IDEs have changed a lot in the last 50 years. Just like we shouldn't advocate for hand writing assembly for all code, we shouldn't be stuck using CLI tooling the same way.
I share your apprehension regarding the current AI landscape changing so quickly it causes whiplash but I don't think a mindset of "it's been fine for 50 years" is going to survive the pace of development possible by better LLM integration.
The reason that tools have not changed that much is that our needs haven't changed that much either. Even something like `find` or `ffmpeg`, while complex, are not that complicated to use. They just require you to have a clear idea of what you want. And the latter is why most people advocating for LLMs want to avoid.
IDEs have not changed that much. They've always been an editor superchaged with tools that will all share the same context of a "project". And for development, it's always been about navigation (search and goto), compile/build, and run.
Not at all. The shell already provide us ways to get contextual information (PS1, ...). And the commands generally provides error message or error code.
In one of the example provided:
$ sdfsdf
zsh: command not found: 'sdfsdf'
zsh: current directory is /Users/ryan
zsh: Perhaps you meant to run: cd agent_directory; sdfsdf
You could just use `pwd`, like most people that put the current directory in the $PS1 to make sure that the agent stays in the correct directory.
Yeah, this example isn't great - you can just tell the llm to run pwd more frequently or something.
But for the `$command | head -100` example, the usage is a bit different. I run into this myself on the cli, and often ended up using `less` in similar context.
Two cases
1) sometimes I use head to short circuit a long running, but streaming output, command so I just assess if it is starting to do the right thing but not bear the time/computational cost of full processing
2) sometimes the timing doesn't matter but the content is too verbose, need to see some subset of the data. But here head is too limited. I need something like wc & head and maybe grep in one command line with context. Maybe something like
1) That's why some tools have a simulate option, or you can just do a kill 9 on the processes you've just launched. Just make sure you've capture their output in a file
2) Again logs, if actions needs to be taken after the command has stopped. For immediate action, you can use `tee`.
Managing context isn't hard. I see more issues with ensuring the right command.
I'm sorry, but no. The tools work. I don't need "more context" from my `less` or `more` commands. The LLM can train on the man pages just as a human can read the man pages.
What man page? I have never worked on a product with one. We're not teaching the LLM how to use `ls`; we are talking about the code being written today.
> I think watching the agents use our existing command line utilities get confused and lost is a strong indicator that the information architecture of our command line utilities is inadequate.
Seems pretty clear the article is talking about teaching LLMs how to use 'ls'.
> The agents may benefit from some training on tools available within their agents. This will certainly help with the majority of general CLI tools, there are bespoke tools that could benefit from adapting to LLMs.
You can pretty much obviate that with an alias that catches the user requesting something then operates deterministically. What is nice about aliases is you don’t need to learn other peoples semantic patterns, you craft ones that make sense to you and your use cases then they always work and consume virtually no resources to work.
