Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[TheBlackCat]

Why have 'ls' and 'grep' when the new, improved 'lsgrep' can do both?

Because ls and grep are two entirely different things. Starting services is starting services. It is more like arguing that 'ls' shouldn't be able to list both user files and system files, instead we should have one tool to list system files and another to list user files.

[doom_Oo7]

Because ls and grep are two entirely different things.

Why should they be ? Generally when you're in front of your computer, what you want is as simple as : "give me some data according to parameters I want".

Why not have a system where you could say "i want the pictures of my girlfriend" or "i want the latest websites I browsed" or "i want the list of every connection to this computer since it woke up" using the same command ? It would be quite logical.

Like:

show *kind of thing* *according to:*

This would be quite unix-y

[TheBlackCat]

Why should they be ? Generally when you're in front of your computer, what you want is as simple as : "give me some data according to parameters I want".

"Give me some data" and "according to the parameters I want" are two separate things. The first one is an io task, the other is a filtering task. lsgrep combines one specific sort of io task with generic filtering, but there are lots of other io tasks I might want to filter. For example I might want to filter by tags, which ls won't give me.

There are three options: give every tool their own filtering capabilities, keep io and filtering completely separate, or decide on a case-by-case basis. There are certainly situations where having an optimized, domain-specific filtering system is useful. But forcibly joining together a specific io with a generic filtering system seems to be a bad solution to me. At the very least you would want to have a filtering system optimized for ls. But what you are suggesting is basically what tpruzina was suggesting for systemD, taking a general-purpose system and forcibly restricting it to a specific use.

[doom_Oo7]

"Give me some data" and "according to the parameters I want" are two separate things.

I disagree : both are useless if taken separately. And I don't want useless things on my computer

[doom_Oo7]

FFS 5 minutes edit.
Well.

Actually I understand the need for the professional to choose the most acute tool for the job, but for the "average" end-user, every kind of data should be able to be abstracted, a bit like here : https://code.google.com/p/dhtfs/

[erendorn]

I disagree : both are useless if taken separately. And I don't want useless things on my computer

But both could be replaced independently, which is good for all sorts of reasons, even outside the IT field. In the end, both approaches are correct, because you cannot always have high flexibility and high performance. Because flexibility means standard interactions, and standard interactions mean no specialization.

People don't grep databases, they use special language queries, which means that grep is not the end all/be all of filtering. But then grep can filter any text input, wherever it comes from, which is very good.

SystemD targets reduced flexibility with external tools, for increased performance, and does a pretty good job at doing both. That can be good or bad depending on how people weight the first of the second.

[Nobu]

I disagree : both are useless if taken separately. And I don't want useless things on my computer

I disagree, I think 'ls -lh | less' is just as useful, or moreso, depending on what your purpose is. Another one I like is 'find . --name foo* |grep -i bar', or even, 'find . |grep foo |grep bar'.

You don't propose merging find into that tool too, do you?

[doom_Oo7]

I disagree, I think 'ls -lh | less' is just as useful, or moreso, depending on what your purpose is. Another one I like is 'find . --name foo* |grep -i bar', or even, 'find . |grep foo |grep bar'.

You don't propose merging find into that tool too, do you?

Well of course I do !
Let's see :
ls -lh <=> give current directory files information with details in an human-readable form (less is only a display medium, it could as well give the data as XML or JSON...)

find . --name foo* | grep -i bar <=> give current hierarchy files whose name begins with foo and whose name contains a case-insensitive occurence of bar

find . |grep foo |grep bar' <=> give curren hierarchy files whose name contains foo and whose name contains bar.

I don't really see where the pattern doesn't apply. It would make for a nice human-without-training-useable command system.
(sorry for small mistakes maybe, lack of cafeine <_<)

[Guest]

It's not plug and play anymore; you can't replace libjpeg with something else without re-coding your software.
It's not plug and play anymore; you can't replace alsa with something else without re-coding your software.
It's not plug and play anymore; you can't replace cups with something else without re-coding your software.
It's not plug and play anymore; you can't replace freetype with something else without re-coding your software.

This is the logic of not reinventing the wheel.

1. alsa is in kernel and even pulseaudio uses it by default
2. cups is defacto standard print server, nobody uses anything else.
3. srsly, you can use whatever fonts you like and this is handled by libraries anyway so...

Whole comment makes no sense (troll).

If your sw has hard dependency on these, there is something wrong with your sw.
Also, it's plug and play in a sense that that you can easily bundle needed libraries with your software (and users can easily replace them with their own system versions via LD_PRELOAD if they want to).

Tho back to my original point, there is no sw created by competent develope which should depend on systemd (except things depening on udev that is bundled with systemd).

[Gusar]

1. alsa is in kernel and even pulseaudio uses it by default

Alsa is in userspace as well, and applications willing to use it must explicitly link with alsa-lib, which means writing the necessary code to interface with it. And getting your app to play sound by other means requires rewriting your app. Well, there's abstractions (SDL, portaudio) and sound servers (pulseaudio), but several apps don't use them, they interface with alsa-lib directly.

2. cups is defacto standard print server, nobody uses anything else.

Why is such a defacto standard ok in the printing scope, but not ok in the service management scope? It's silly to accept "the one true solution" in one area, but oppose it in another area.

3. srsly, you can use whatever fonts you like and this is handled by libraries anyway so...

If you want your app to display fonts, you need to interface with those libraries, so just like with alsa-lib, you need to write appropriate code. And you can't switch to something else than your chosen library (usually freetype/fontconfig) without rewriting your app.

So TheBlackCat's argument is fully valid and a nice display of how silly gamer2k's argument was. So please kindly take back your claim about who the troll here is.

there is no sw created by competent develope which should depend on systemd

Yes, theoretically KDE could use a different service manager for their needs. But since systemd is there and is suitable for the task, they've decided to use it. And I'd say using the already existing (and proven to be working - SailfishOS on the Jolla phone uses systemd --user) solution rather than implementing your own is the more competent thing to do. Your insinuation about who is competent or not is quite condescending.