Systemd Rolls Out Its Own Mount Tool

[pal666]

I agree with your insightful assessment that some peope prefer the simplicity of gluing together imperfect pieces and thus don't like the newly required precision of the more coherence solution put forward by systemd.

i will disagree with you. systemd is backwards compatible with sysvinit scritps and allows to run shell or any other scripts, so retarded people can still glue everything together in thousands lines shell script, depending on half of /usr/bin/*

[unixfan2001]

What I mean is: we (the community) can contribute to projects, but any merge request needs approval to get in. The "community" doesn't have direct write access to a Github project or any large scale project, and so it needs the developers' approval to do anything besides forking, and even after forking there will be a group of people in charge of this new project who will become the maintainers/developers with the power to accept or reject merge requests, anyone else is the "community".
Go ahead, try to contribute with a single line in one of my projects, see how much power you have in regards to it: https://github.com/amarildojr/Firewa...b/master/rules
None, right? You can fork your own, but that's it. The request gets merged only if I (the "developer/maintainer") agree with it. That's what I meant by "the community", it's anyone who doesn't have the power to directly commit changes to my project, in this case it's YOU.

So?

That's true for any large scale project. Give everyone direct write access and see where that gets you.
I suspect the entire repository would get nuked in less than an hour.

[anda_skoa]

i will disagree with you. systemd is backwards compatible with sysvinit scritps and allows to run shell or any other scripts, so retarded people can still glue everything together in thousands lines shell script, depending on half of /usr/bin/*

Oh, we are not in disagreement here, because I know about these compatibility features and I also don't perceived the new options as limiting or to strict.
I was also thinking more about the wider systemd eco system, not just the init part.

What I was saying is that I agreed with the assessment that some people in the "don't like systemd" camp apparently like the messy, less coherent approach, not whether this perception is accurate or not.

Cheers,
_

[sdack]

What I was saying is that I agreed with the assessment that some people in the "don't like systemd" camp apparently like the messy, less coherent approach, not whether this perception is accurate or not.

Cheers,
_

Just accept that some people don't like it, but don't make it a camp or imply that some would like it messy. This kind of lingo only helps to polarize. The mess was created by the distributions themselves and they all embraced systemd rather very quickly. It's hard to find a distribution these days that comes without it (or that doesn't at least offer it). That's as good as a confession. You can blame them for it if you want (but you don't have to blame anyone).

Does systemd add coherency? Yes and no. No, because coherency isn't an object, but a description for the relationship of a group of objects. So it's not something you add into a random group of objects with another object and they all magically*) become coherent. You will need to change the objects within the group first to get coherency.
And yes, because systemd actually replaces software and introduces its own coherency. But this isn't quite the same, because any software that doesn't work with systemd doesn't suddenly become coherent - it becomes isolated or even obsolete.

To make this more obvious to understand, you don't get more coherency between black and white communities by increasing the number of police officers. Yet there are quite a few mature adults who believe it did (which is actually sad).

Back to systemd... The fact that people here in this thread want to use only parts of it, but can't, shows there is room for improvement. We will likely see how systemd becomes more modular, and also how software adapts and starts replacing parts of systemd in return.

*) I am using the word "magically" here, because one can always make it appear like it did work like this. I.e. by using a group of pre-conditioned objects, where a coherency existed but was lost by removing an object, just to add the missing object and to reestablish coherency. This would however not be the same as doing it with any random group of objects.

[aht0]

What I was saying is that I agreed with the assessment that some people in the "don't like systemd" camp apparently like the messy, less coherent approach, not whether this perception is accurate or not.
_

Everyone who states that particular thing, seems to conveniently forget, that sysvinit was by far not the only init around. Just most widely used one in Linux.. Also, you seem to imply that there is only one reasonable solution set to the sysvinit and thats only systemd. What specifically is wrong with for OpenRC? It can do much the same as systemd init, including parallel service handling during boot..

Literally every time someone brings up OpenRC, post is ignored and rambling goes on trying to justify svchost.exe Linux Edition.

[anda_skoa]

Just accept that some people don't like it, but don't make it a camp or imply that some would like it messy.

I think you are misunderstanding me.

I merely pointed out that your observation about people liking "gluing together" and percieving the coherency of systemd as an obstacle to that was one of the motivations of not liking systemd. Which I found particularily insightful since I hadn't though about it that way.

The mess was created by the distributions themselves and they all embraced systemd rather very quickly.

Exactly. A lot of distribution maintainers like the coherence that systemd brings to the table.

Does systemd add coherency? Yes and no. No, because coherency isn't an object, but a description for the relationship of a group of objects. So it's not something you add into a random group of objects with another object and they all magically*) become coherent. You will need to change the objects within the group first to get coherency.
And yes, because systemd actually replaces software and introduces its own coherency.

Exactly!
The systemd project achieves the increased coherency by providing several new components and having them fit together well.

But this isn't quite the same, because any software that doesn't work with systemd doesn't suddenly become coherent - it becomes isolated or even obsolete.

True, but it can also benefit from the better overall coherency by adapting to it, increasing the coherent space beyond the systemd project's scope.

Back to systemd... The fact that people here in this thread want to use only parts of it, but can't, shows there is room for improvement. We will likely see how systemd becomes more modular, and also how software adapts and starts replacing parts of systemd in return.

Yes, possibly, though I am not sure there are currently any efforts into that direction.

Cheers,
_

[anda_skoa]

Everyone who states that particular thing, seems to conveniently forget, that sysvinit was by far not the only init around. Just most widely used one in Linux..

True, but again, this was in the context of sdack's really interesting observation that systemd is, by some, perceived as a negative impact of the possibly of gluing together things without much restrictions.

Again, I have not made that observation, I just said I found it insightful.
You'll have to check with sdack if, according to the observation, these even overlap with people preferring OpenRC.

Also, you seem to imply that there is only one reasonable solution set to the sysvinit and thats only systemd.

Being one reason doesn't imply it is the only one, no?
Many people have many reasons in favor or against something.

Cheers,
_

[aht0]

Being one reason doesn't imply it is the only one, no?
Many people have many reasons in favor or against something.

My apologies in case you took it personally. I was keeping in mind the fact that in this thread, plenty of people have rambled how bad the sysVinit was and how much they personally like the change. My impression so far is that they are much less concerned whats good for Linux as an operating system but how much it makes their life easier - conclusion, mostly motivated by pure self-interest.

[Amarildo]

where are they? i see only whiners

I said "there could", not "there are".

there was even example of forked distro in this thread. of course nobody will use sucking distros with sucking ports and that is what systemd-less ports will turn into

Again, not my point. You're very good at nitpicking, yet not good at understanding the context. My response was only in a hypothetical situation, if a systemd fork was to every exist, because systemd is already in use in a very large scale and it wouldn't be an easy/quick task for everybody to switch.

lol, nobody will make shitty software because of your pressure

Why the "shitty" part? Because aparently you think I hate systemd (which I don't) and aparently for you that qualifies for a "shitty opinion"? I'm not talking about me or how I want a software to work, specifically. Learn to read:

That falls exactly on one of my previous comments where I ask if it's actually a good idea to fork a project every time we find something wrong with it, instead of pressuring the developers to make the software work as we want.

Someone asked and I responded on my definition of "community", which is "the people who don't have commit access to a project", and I said the community "can fork it but that's it". Then you said "if the fork is good everybody will switch", then I commented on why "forking a project everytime we don't like it" may not be a good idea and why I think pressuring developers is a better/faster idea since that's the least-effort way that has had very good results in the past (in the example I gave on my comments, VALVe and their plans to charge for MOD's that were once paid, but the community pressured the developers, and then they followed the community).

I see having a consistent coversation on Phoronix is a hard task to achieve.

[pal666]

if a systemd fork was to every exist, because systemd is already in use in a very large scale and it wouldn't be an easy/quick task for everybody to switch.

it would't, but systemd prevailed against preexisting large scale competition. to win you have to be better

Why the "shitty" part?

because usual complains against systemd boil down to "i failed to read docs", "i don't understand how it works", "i don't want to learn" or "you must make software as i like even if it will suck for everyone else"

That falls exactly on one of my previous comments where I ask if it's actually a good idea to fork a project every time we find something wrong with it, instead of pressuring the developers to make the software work as we want.

you can't pressure the developers. you can make suggestion on sound technical grounds (even better as patch), but "i want it that way" is not sound nor technical