Announcement

Collapse
No announcement yet.

Debian Moves Closer To Voting On Proposals Over Init System Diversity

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by mrugiero View Post
    So? Manpower is distributed around projects. More active projects == less manpower/project. I'd rather have one high quality product than a hundred barely usable (if lucky) ones.
    Again, I think the MS Windows analogy in instructive, here. The lack of alternatives doesn't mean your only viable option is necessarily satisfactory for all needs and purposes.

    Originally posted by mrugiero View Post
    Having multiple inits in a single distro is, in my eyes, part of fragmenting for nothing.
    Heh, you've fallen into the conceptual trap of thinking about systemd as an init system. It's not. It's a growing constellation of userspace services, with service management near the gravitational center. As long as you regard it as an init system, you're missing the point.

    I don't actually care about a distro supporting only one init system. It sounds like an entirely pragmatic choice. I simply choose to believe that it shouldn't lock you out of other choices about your userspace services, which is the practical reality we face.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by coder View Post
    The point about unsupported alternatives and lack of manpower actually go together, as well. If systemd absorbs all the oxygen, then the alternatives stagnate and systemd becomes the only way.
    So? Manpower is distributed around projects. More active projects == less manpower/project. I'd rather have one high quality product than a hundred barely usable (if lucky) ones.

    Originally posted by coder View Post
    The vision you're putting forth is basically that Linux should be an open source Windows. Windows has different userspace services, and one could theoretically replace one with a custom implementation, but people only run the configuration that MS gives them. That might be fine for most people, most of the time, but when you want to push Windows outside its comfort zone, the lack of options can really be problematic.
    The vision I'm putting forth is basically not fragment for nothing, and not expect everyone to work for the few who want to "push Linux out of its comfort zone".
    Having multiple inits in a single distro is, in my eyes, part of fragmenting for nothing.
    Not everyone has to use Debian. Most of the actual valid use-cases not covered by systemd aren't well covered by Debian either way.
    You wouldn't use Debian on a router. You'd use something like OpenWRT, Buildroot or Yocto.
    You would use Debian mostly on desktops (where systemd is appropriate) or on servers (where systemd is also appropriate).
    systemd was also used successfully in some embedded environments, as shown here: https://github.com/profusion/demysti...bedded-systems
    That said, I'm OK with people pushing patches to scratch their itches, and taking up the task to maintain those, as long as that doesn't degrade everyone else's experience.
    I just think they're wasting their time, but it's theirs to waste.

    Leave a comment:


  • coder
    replied
    Originally posted by mrugiero View Post
    To think all of them would use Debian and big desktops (the only ones depending explicitly on systemd facilities that I can recall) is insanity.

    They may be virtues in theory, but fragmentation is a thing, and it wastes man power, of which we have way less than we need to get anything on-par with closed alternatives.
    It also wastes admins time when they have to deal with several disparate distributions that choose to do things differently of each other just because.
    The point about unsupported alternatives and lack of manpower actually go together, as well. If systemd absorbs all the oxygen, then the alternatives stagnate and systemd becomes the only way.

    The vision you're putting forth is basically that Linux should be an open source Windows. Windows has different userspace services, and one could theoretically replace one with a custom implementation, but people only run the configuration that MS gives them. That might be fine for most people, most of the time, but when you want to push Windows outside its comfort zone, the lack of options can really be problematic.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by coder View Post
    You're missing the point. It's not about consumer preference, but the ability to customize system software to suit a particular set of needs. As you'll know, Linux is being used in a vast array of devices and environments, to suit applications with an even greater set of needs and requirements. To think that one userspace blob of services can adequately satisfy them all is beyond hubris - it's insanity.
    To think all of them would use Debian and big desktops (the only ones depending explicitly on systemd facilities that I can recall) is insanity.

    Originally posted by coder View Post
    Maybe not for you, what one thing I always found appealing was its openness and flexibility. I think those have been virtues, and I hate to see ever-increasing parts of the userspace get absorbed by the sytemd borg (maybe that analogy will make more sense to certain individuals of a more interstellar predisposition), eroding away at some of that flexibility as is does.
    They may be virtues in theory, but fragmentation is a thing, and it wastes man power, of which we have way less than we need to get anything on-par with closed alternatives.
    It also wastes admins time when they have to deal with several disparate distributions that choose to do things differently of each other just because.

    Originally posted by coder View Post
    I just wonder how long it'll be, before systemd starts to infect the kernel.
    If we count bus1, right now. But they don't have free reign there, proved time and again by getting stuff rejected loudly.

    Leave a comment:


  • coder
    replied
    Originally posted by Terrablit View Post
    Actually, the end-user benefit of choice is a common fallacy. Consumers always claim to want choice, true. But it's been shown that consumers are actually less satisfied as the number of choices grows.
    You're missing the point. It's not about consumer preference, but the ability to customize system software to suit a particular set of needs. As you'll know, Linux is being used in a vast array of devices and environments, to suit applications with an even greater set of needs and requirements. To think that one userspace blob of services can adequately satisfy them all is beyond hubris - it's insanity.

    BTW, even when you're saying people are less happy with more choices, that doesn't mean they're always happiest with zero choices.

    Originally posted by Terrablit View Post
    Linux is not about choice.
    Maybe not for you, what one thing I always found appealing was its openness and flexibility. I think those have been virtues, and I hate to see ever-increasing parts of the userspace get absorbed by the sytemd borg (maybe that analogy will make more sense to certain individuals of a more interstellar predisposition), eroding away at some of that flexibility as is does.

    I just wonder how long it'll be, before systemd starts to infect the kernel.

    Leave a comment:


  • profoundWHALE
    replied
    I'm sure that I'm late to the party but I think that they should keep systemd as is for now.

    Leave a comment:


  • coder
    replied
    Originally posted by anarki2 View Post
    An init system isn't something that users care about.
    systemd is not an init system. That was just the camel's nose under the tent.

    Originally posted by anarki2 View Post
    whatever cherry picked part in the toolchain having absolutely no impact on my work.
    Sounds like you could probably also just use Windows or MacOS and be just as happy. Good for you.

    Leave a comment:


  • coder
    replied
    Originally posted by starshipeleven View Post
    As a disclaimer, a warning to others.
    Nice try, contrary canary. I know you're neither stupid nor ignorant enough to believe that such a disclaimer or warning is necessary or warranted.

    Troll harder.
    Last edited by coder; 19 November 2019, 01:26 AM.

    Leave a comment:


  • coder
    replied
    Originally posted by starshipeleven View Post
    Not a blob, but a bunch of daemons, see below for list
    That's not a list of daemons - that's a list of where they felt like defining interfaces.

    And when I said "blob", I didn't mean like literally a single daemon, I meant that it's encompassing more and more functionality. Like those old Blob That Ate ... movies, where some giant, gelatinous blob devours everything.

    Originally posted by starshipeleven View Post
    Sorry what? You can mix and match every daemon.
    Even they don't say that! There are plenty of "no"s and "maybe"s in their "Reimplementable Independently" column. And since most lack specific examples, even most that claim "yes" can't be trusted.

    Originally posted by starshipeleven View Post
    pretty much all your post is sugar-coated bullshit, there is no other plausible explanation.
    Yours is deep-fried. But pretty much nobody here expects anything else from you, by now. If I didn't know you such a troll, I might actually be offended.

    Originally posted by starshipeleven View Post
    To change the system architecture you must control the core system components, duh.
    Obviously not.

    There are loads of technical standards where people come together and agree on a standard interface or data format. You don't have to conquer userspace and mold it as you please, and then expose a few interfaces where you find it convenient to do so. That sort of fascist thinking doesn't fit well, in an open source ecosystem.
    Last edited by coder; 19 November 2019, 01:25 AM.

    Leave a comment:


  • trek
    replied
    Originally posted by waxhead View Post
    Bingo, I admit to not knowing the details, but at the same time I would think that a lot of systemd functionality could simply be ignored which would make the implementation easier. E.g. for most things slices (cgroups) that takes care of memory constraints and resource limits, i bet it could be mostly ignored and things would work just fine for most programs anyway.
    that was the unfortunate way elogind people hoped to reimplement stuff, without slices, but then it turned out that libsystemd don't like to work without slices even if logind can... what an incoherent design

    Leave a comment:

Working...
X