William Hubbs wrote: > Steven J. Long wrote: > > I haven't seen anyone say that in this entire discussion, but I might have > > missed something. "If a user wants to run GNOME, he [can] switch to systemd" > > is clearly not saying that, so we're left with an enigmatic "some" who > > haven't > > posted to this thread, afaics. > > The point I'm trying to make here is that for gnome >=3.8, upstream > gnome does not support running gnome without systemd afaik.
Then I don't know why you think repeating stuff we already know adds anything to the discussion. The point you actually made was: > Some folks want to use gnome without systemd and are putting that under the > gentoo > is about choice banner and want us to support them. And that's what I answered, so my point still stands, in response to what you actually wrote. > > It's clear to me that users have been forced through lots of changes over > > the > > last 5 years, even where we just want to carry on using our machines the way > > we always have. Isn't that what convenience layers are about? So Walter's > > point stands. > > No it doesn't, because Gentoo Linux isn't requiring you to run systemd. Again, you appear to be deliberately misrepresenting the discussion, this time in order to make it just about whether one must run systemd or not. That's not the only concern. Nor have the changes that have been forced upon users by this upstream, to zero tangible benefit afaic but causing an awful lot of pain, been restricted to systemd; the "last 5 years" I referred to. This is the point Walter actually made: >> If a user wants to run GNOME badly enough, he'll switch to systemd. I don't >> see >> why the rest of us (i.e. non-users of GNOME) should have to follow along and >> reconfigure our systems. This is a case of the tail wagging the dog. Your strawman is that no-one is talking about anything but GNOME. Yet in another post we have: > Today the source of all our troubles is just GNOME, I am afraid that tomorrow > it > will expand beyond it. The usual eleventy-eleven nonsense, akin to the nonsense about split /usr being "broken", and here's a load of spurious reasons why from people who never saw the point, so let's change everyone's setup, when /really/ it was just about udev initscripts requiring /usr. And delaying start till after localmount if you have stuff for rootfs builtin (which most of us do after an install: that's how we booted to setup the rest of the system) works perfectly well, without requiring you to throw another point of failure and maintenance into the mix. So, lots of changes foisted upon us, to support corner-cases that aren't even designed very well[1], and will require more changes in the future, since upstream think they know better than everyone else. *Making the simple cases complex, to support the complex ones is simply doing it wrong.* Especially when your idiot-box can't cope with unexpected situations, and instead you rely on rubbishing users' experience, with a patronising "no-one needs that" so you don't even support the complex cases very well. Mainly because you refuse to keep it simple, as you want to display your virtuosity, instead of providing tools that users and other developers can tie together as they see fit. "Tail wagging the dog" sounds exactly right. So Walter's point still stands imo. When you forego modularity, you get a ripple effect of changes. Exactly what we've seen happen more and more over the last 5 years. Providing mechanisms to handle the complex cases, or to allow the user to handle them, is fine. Just don't wag the dog. > > > >> Fabio Erculiani wrote > > > >>> So what do we want to do then? Isolate from the rest of the world? > > Gnome can depend on w/e upstream require. How is that the whole world? > > It's not even the whole Linux ecosystem, and I can't see Qt giving up cross- > > platform independence, just to work with systemd. That was never going to > > happen, so it was never going to happen in KDE either, however enthused a > > few of its volunteers were, since KDE is a showcase for Qt. > > > > Matthew Thode wrote: > > > If upstream gnome has that dep on systemd then I kinda think we should > > > too (technical decision, not one I like personally) > > > > I think we should too: all anyone has said is "Gnome is not Linux". > > Presenting > > its choices as representative of every DE and upstream project is simply > > misleading. > > I haven't done that, and I don't know of anyone else who has. "the rest of the world" and the above comment quoted seem pretty clear to me. So we agree it's only GNOME-3 that has the hard requirement on systemd. KDE, the other big DE, which ime has brought more non-Linux users to Linux than any other, and certainly represents the only one left of the two which still works like a desktop, has no such limitation. Neither do the forks of GNOME-2, nor lxde, and indeed people have original GNOME-2 working without polkit, let alone systemd. > > Claiming that making it easier to use systemd is in everyone's interests is > > clearly untrue as well, since many of us our interests are caught up with a > > modular system we can build and configure how we require. That's why we > > came to > > Gentoo, and why we stay. > > No one is arguing against that. All this thread is about is making > systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as > smooth as possible for someone who wants to switch between the two. I wasn't aware it was a second-class citizen. Both seem fairly equal to my eyes: as people contribute or use them, they evolve in Gentoo. OFC openrc has less evolution to do, since it's more mature, and lets existing software do its job instead of trying to supplant it. This thread started out as suggesting an eselect mechanism that is unnecessary and in fact counter-productive in implementation. The effort should go into making sure the user's system is in a state that can be booted, not into automating the edit of a single file by instead changing symlink and hoping nothing goes wrong. And if it does, the user he thinks incapable of editing a file, will instead have to edit the bootloader config at startup to use a non-standard filename (just what Grandma is good at), and then reset the symlink (or rely on the ill-conceived automated mechanism that got her into the mess), instead of a new option to try the config out, and then confirm the change, or take a successful boot/one-time service startup as confirmation. Is it just me who thinks developer effort and future maintenance for something that is badly designed, is a complete waste of time, and a dead-end? More to the point, why is it so unacceptable for me to question an implementation, on a list designed for that purpose? Anyhow, if you could elucidate on where you think systemd is being treated as a "second-class citizen" and not the same as any other Gentoo software, that would be useful for the issues to be addressed. afaict systemd-udev seems to get far more attention than other software projects in Gentoo, usually when it's breaking existing setups and there's a campaign around how great that is for everyone. An eselect for init symlink being a bad idea is not treating either project better or worse. It's just saying that's a bad way to switch, and why not spend the effort on the bit that matters, ie making sure the system is safe to switch in the first place, since it hasn't even been mentioned *at all*. As you get older, you actually appreciate those moments (which are the aim of this list) for the amount of work they save you. Though by then, you've got used to being wrong, and see the process as more about the mistakes you didn't make, than how much code you produced. Simpler and less code is easier to read, write, maintain, easier to optimise, and runs quicker. When you're young you attach more ego to your output, and get hostile and defensive instead, resorting to insults about the person questioning you, instead of considering what they actually typed, and whether it has any validity, and answering the substance. > > But I'm sure someone will declaim about how systemd doesn't force anything > > on > > anyone (leveraging udev builds against your explicit word, doesn't count, > > nor do > > any of the other changes like requiring an initramfs where none was needed > > before: > > those are just things you should do because we tell you to) and Lennartware > > hasn't already forced major changes and upgrade pain, for no tangible > > benefit to > > the desktop-users it was purportedly aimed at. > > Systemd has nothing to do with requiring an initramfs, so please > de-couple those issues. Yes, the systemd devs are the ones who wrote up > the issues around why an initramfs should be used if /usr is separate, > but systemd itself doesn't care. IOW "because we tell you to." (See above wrt the actual technical issue, which is not about the rest of the ecosystem at all. Tacking on a discussion about the crap linkage in Linux, which is actually due to gmake insanity and should be fixed, doesn't change that. A small proportion of the effort that's gone into keeping up with upstream changes could have sorted out the /usr,root split out far more effectively across distros and projects, not that it is much of an issue in practice, thanks to a sane base-system.) Your argument is disingenuous at best. It's one thing to flag an issue that /might/ affect people, or indeed to use an initramfs in the binary distro you work for. It's quite another to conduct a public campaign to rubbish a partitioning split that was worked out 30 years ago, and is still used by many admins for good reasons (and no, I don't have to enumerate them for them to be valid. You guys are supposed to make our life easier, not harder: and that means accepting we know what we're doing better than you do, since by definition you are not around when the software is in-use.) As Linus said if something's been around for 30 years, it's not a reason to get rid of it: "if anything, damn that thing works." Quite apart from anything else, continually rubbishing a lean rootfs combined with split /usr /var /home et al, makes you sound like a nub to people who've been very successful for decades, with that setup. Irrespective of what Sun did to evade the issue or the reasons they might have had within their setup that simply do not apply to Gentoo users. (no one mentions /usr/xpg4/bin for some reason, but somehow Sun is the model we should aspire to when it comes to laying out our filesystem.) Most especially when your propaganda page in favour of the "new" setup actually resorts to quoting lots of the advantages of that exact same "old" setup. Only this time the initramfs is both the new rootfs we should rely on to recover our systems, and simultaneously a minimal little thing we shouldn't worry our heads about. (Coming from the people who've told us that so many times, yet ended up causing us a lot of worry and admin effort, it's hard to believe.) Or maintain another partition with a whole live-disk in, and keep that up to date as well. Or just ignore the latest "One True Way" and laugh at the fact that it's actually become "N+1 True Way" since history's lessons have to be learnt anew, and the whole point of being young is to reject what you've been told, and make your own mind up. It's all very well to evolve software over time. However, "plan to throw one away, you will anyway" has become "plan to throw _every_ version away, since we can't get a design right, and we're in userspace so we don't have to think about ABI, all good. Can I interest you in a binary log stuffed with XML?" And while every software has bugs, that's not a reason to forego any sort of acceptance-testing with the network admins you claim to want to help, and instead dump half-baked software into the wild, with the immortal words "it's free, c'mon we give you this stuff for free", backed up by a chorus of "the source is out there" and "no we don't want nor need, no steenking modularity, cohesion or portability, that's fusty traditional Unix." Please note: I was in favour of making it easy to switch between openrc and systemd, and still am. I am also in favour of GNOME-3 in Gentoo simply requiring systemd. And I have consistently supported unit files being installed by default, so that sub-thread has got nothing to do with anything I've said. Regards, igli. [1] http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
