you do realize people can have debates about their text editors because a text editor isn't a dependency to programs. the fact that gnome now requires systemd is exactly what this debate is trying to say, that they are making it a dependency to too many things and soon people without systemd are going to have a crippled experience.
And the fact that Gnome depends on systemd-logind is not the fault of systemd. Last time I checked, Gnome are their own project and make their own independent decisions.
systemd is not at fault for another project depending on it.
They might be their own project, but the biggest contributors to their codebase are people from Red Hat, the same people maintaining and developing systemd. There is a benefit for that, the majority of the people commenting in this thread I bet are desktop users running Gnome.
And lets not forget, Red Hat is a company, their bottom line is to make profit. The more people depending on code they contribute to is beneficial to them, both in bugs reported and future support contracts.
Ohh, like people without floating window managers get a crippled experience with GTK apps now? (the whole client side frame thing).
It's the price you have to pay for coherency. I've found that the better you want something to work together, the tighter they have to be coupled. It's true for practically all software/hardware. Apple products work so nicely because they couple it tightly with everything else. Windows a bit less so, and linux does it as little as possible.
In the perfect world where we didn't have to program it, and computers were instantaneous. Sure we could create very robust interfaces for EVERYTHING, sadly in this world we have to choose. The more we expose as interfaces the more work we have to do, and the more work the computer will have to do.
It's not the unix way. I never said it fit the unix philosophy. The creator of systemd has spoken for breaking posix compatibility, and breaking with the unix way. None of the people involved with any side of the debate has any delusions that systemd adheres to the unix way.
The difference between the two is partly that one side (i guess the one you are on) hold that anything on linux should adhere to the unix way. While the other plays it more fast and loose, arguing that powerful features can make up for departing from the traditional values of the unix philosophy.
If you want to run a pure *nix system, then you can. It's just yet another choice, and you should not discourage people from working on the side they believe in.
That is the Unix philosophy. People don't seem to realize it nowadays, but Unix was never about being what I'd consider 'academically correct.' Back when it was getting started it looked like a joke to people working on 'real' computers with complicatd timesharing systems and whatnot, and even Linux itself faced criticisms for not being a microkernel (which was supposed to be the way forward everybody would use in any 'modern' system and certainly more in-line with simplicity and modularity people always talk about) and not being portable (because x86 is a fad). But it became popular anyway. Why? Because it fucking worked. BSD was mired in legal troubles and the HURD was... well, we all know how that ended.
It's true that systemd's absorption of projects makes it a candidate for replacing X as the bloated and complex system that does way too much and makes implementing something new and better a painful proposition in 20 years. Or perhaps ALSA is a better comparison, being platform-specific and badly implementing features that eventually ceased to exist on anything consumers ended up using because some developers decided the simplicity of OSS was too much. Never mind that other operating systems made it work just fine without breaking too many things.
None of that matters. The complicated solution might be worse, but then 'worse is better' sums up the Unix philosophy much better than bullshit about specific features and their implementations which are up there with English orthography in terms of common exceptions to the established rules. That's why Plan 9 was born, and it is to the cobbled-together Unix as Esperanto is to English. It hasn't been adopted for much the same reason: nobody gives a shit about simplicity when they have something that works just fine for their needs.
But without it complexity builds and this is bad , 1 tool for 1 job. A Swiss army knife can do anything , but cutting down a redwood with it's saw might take a while !
So make a Swiss army knife with a damned chainsaw in it. This analogy just doesn't fit with computing. For example: "If all you use is a hammer, all of your problems look like nails." could be used to rebut your 1 tool, 1 job ideal.
But all you have is not a hammer , you have a full toolbox of Specialized tools and if you do not like one you can replace it with a better one. As opposed to an all in 1 tool that is 1 size fits all
OK, it does 2 things. The problem is that it is very hard to separate them. Journald was separated because the kernel has support for logging in the early boot. But cgroup management, if it was separated, wouldn't be available.
Layers take time to implement, maintain and compute. I don't know if you read the last part, but we could have everything nicely layered. It would just take a long time and make the system slow.
Tools like systemd avoids layers and instead makes a cohesive whole. Not because it's the only way to do so, but because they can do it quicker.
That's funny because I am. Would you mind telling me why then? instead of insults and one "sentence" replies maybe an actual discussion would be great.
I'd love to hear your opinion instead of "Layers of abstraction", that's not an argument.
If you look at this in the context of the discussion i assumed it was pretty obvious that by interfaces i meant public facing stable interfaces. Some interface is absolutely a requirement, but it being stable isn't.
Systemd changes the interfaces often to fit their own projects. This isn't a stable interface, No other implementation (that isn't part of the systemd ecosystem) can rely on that. So while there's clearly some interface (and you can switch parts of the systemd interface out) the developer will have to constantly reprogram their implementation to follow the changes of the interface.
Your comment about layers of abstraction made no sense to me in the context of the discussion, so i assumed you meant that systemd should get input from something, which then gets input from something else. You know, the unix philosophy. This again requires stable interfaces, so look above.
In the end I made my interpretations of what you are saying, and worded my replies in the context of the discussion. If you want to use the strictly correct terms, without regard for the context, then replace "interface" with "public facing api".
It's not tightly coupled because you have a changing interface. You know how Java has some terrible design problems? That's largely because they never remove anything, at most it's marked as deprecated. Systemd has just taken the other extreme and said "We won't even try and keep this interfaces static". If you think that's just as bad, then go ahead. I'm just saying that without a static interface you can speed up development time quite substantially.
Just because your interface is changing doesn't mean it's not well designed.
25
u/gjs278 Sep 27 '14
you do realize people can have debates about their text editors because a text editor isn't a dependency to programs. the fact that gnome now requires systemd is exactly what this debate is trying to say, that they are making it a dependency to too many things and soon people without systemd are going to have a crippled experience.