Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[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.

[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/

[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

[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]

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 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.

[TheBlackCat]

Because you have now locked your software in with another software package you do not control. That's the issue here. It's not plug and play anymore; you can't replace Systemd with something else without re-coding your software. You have a dependency within your INIT, which lets face it, should be independent of everything else.

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.

[Nobu]

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

...really? Maybe because, I dunno, 'ls' has one purpose while 'grep' has an entirely different one? On the other hand, you might be considered more-or-less sane if you merged 'less' and 'more', and just used an option to choose the desired action.

[Vim_User]

Like busybox? It's already there since almost 20 years :-P

With reduced features aimed for minimal size, so it can replace ls and grep only if you don't need or want all the features.

He is most definitely trolling us, if there was ever any doubt, now it must be clear to everyone.