4 ms·

I'm OK with making sure the software I'm running is the software I thought I was running. But because trusted boot runs so deep, and is intentionally hard to ge

I'm OK with making sure the software I'm running is the software I thought I was running. But because trusted boot runs so deep, and is intentionally hard to get around, it's vital that the implementation is trustworthy. I don't trust Poetteringware. Poettering's team has a record of foisting technology on users, resulting in the need for e.g. the Devuan fork. I wish this work were being done by just about any other team than Poettering's.

jle17 4y ago
> I don't trust Poetteringware. Poettering's team has a record of foisting technology on users, resulting in the need for e.g. the Devuan fork. They have been developing software, that enough people have deemed useful to include it in their distributions. Some have disagreed, and have made other choices. No one was forced to do anything, there have been no "foisting" and the "need" for Devuan is a subjective opinion. There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development.
- hdjjhhvvhga 4y ago
  > There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development. While I agree with you in general, for some reason this particular developer tends to take decisions that have very extensive consequences and make choice extremely difficult.
  - kevincox 4y ago
    A developer that has been able to make tough choices and drive them well enough to get mass adoption? He definitely isn't perfect but this sounds like quite the feat in Open Source.
    - hdjjhhvvhga 4y ago
      There is a huge difference between a developer who creates a superior project that everybody loves to use so it gets mass adoption and one who makes a product that gets pushed by their employer on everyone whether they want it or not. I don't want to get into details as the subject has been beaten to death but as for Systemd* there was the case of integration with graphical login that made choice difficult. Had the author been more sensitive to this issue and cooperated a bit without being stubborn we wouldn't have had Devuan and all that mess. This is exactly NOT the way to do things in open source. *PulseAudio was simply broken but it's not the fault of the author distros picked up aplha-quality software
      - growse 4y ago
        > This is exactly NOT the way to do things in open source. Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?
        hdjjhhvvhga 4y ago
        For applications, tools, even most libraries - yes. But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.
        Foxboron 4y ago
        >But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited. This isn't very accurate. When Debian decided to switch to systemd, they also agreed to support other inits in the distribution. This wasn't good enough, so Devuan itself was forked before this decision was made. The end result is that Debian had less people to support the init script alternatives. It became a self-fulfilling prophecy. I'm confident Debian could support other inits if there was more Debian devs available to work on it. But because people left for Devuan the pool becomes smaller. Even the last decision on inits from Debian says that the focus should not solely be on systemd. https://lwn.net/Articles/808217/ https://lwn.net/Articles/808217/
  - denton-scratch 4y ago
    I didn't make a personal attack on Poettering; my objection is to the software his team produces. And I wasn't making any technical argument; I don't know enough about TPM and secure boot to do that. My point was a political one, I guess: this is more software that runs very deep in the system, coming from a team that has a record of producing software that is hard to opt-out of. For PulseAudio on Debian, you have to take firm steps to ensure the package manager doesn't reinstall it. Much the same goes for systemd. I assume it will be much harder to opt-out of a secure boot released by that team. I believe that's on purpose: they could have made it easier to run without those packages, if they'd wanted to. I think it's clear that they wanted the opposite.
- lmm 4y ago
  Systemd was designed in a way that was more tightly coupled than the alternatives and made adopting it an all-or-nothing proposition, and other projects (particularly Gnome) were also tightly coupled to it. It was absolutely foisted on people: a lot of people didn't want it but found they were nevertheless obliged to install it. The whole thing abused the goodwill of the free software community: systemd folks added systemd-dependent patches to other software, taking advantage of the norm of accepting such contributions, while refusing patches that made systemd compatible with other systems (e.g. non-Linux). And the end result was a state where you can no longer fork and replace components piecemeal - the whole free software ethos, the very reason GNU was built as a Unix-like system in the first place - which does far more to discourage participating in free software development than any mere internet argument.
  - jle17 4y ago
    The tight coupling, the non-portability, all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers. Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything. People got systemd on their OSes because they chose OSes whose developers chose to move to systemd. It's not like Lennart comes to your home with a gun if you install OpenBSD.
    - dogleash 4y ago
      > all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers The ramifications of those technical choices on the software ecosystem are so well understood [0], that there is no point in discussing "their own merits" in a vacuum. What's most relevant to my professional and waning hobbyist interests are the shape and trajectory of the software ecosystem as a whole. To talk about systemd without talking about how it's developers interact with the software ecosystem is to talk about nothing. [0] I graduated before systemd was a glint in Pottering's eye, but we somehow still covered it in school. Not only coupling vs cohesion in the abstract, but also how various design decisions (including init system arguments of old!) interacted with the ebb and flow of unix-like OS evolution.
- carapace 4y ago
  You are completely missing the point. Please don't fan this flame.
gsich 4y ago
Going back to the init.d clusterfuck is insane.
- public_defender 4y ago
  I was thinking this in a general sense, but I recently tried a distro with openrc and it was quite nice. Maybe things have changed.
- krzyk 4y ago
  Why? It was simple and understandable. systemd has everything and a kitchen sink, it is a big blob of software. Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing that made me question sanity of distro maintainers and author of two worse pieces of software: pulseaudio and systemd. (I was very surprised that it was the same person).
  - vetinari 4y ago
    > Why? It was simple and understandable. Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks. > systemd has everything and a kitchen sink, it is a big blob of software. You can still pick and choose. Systemd is an umbrella project. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver systemd-resolved is exactly one of the things that you can pick and choose. > was the final thing that made me question sanity of distro maintainers And there are good reasons for that: 1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down). 2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.
  - Avamander 4y ago
    > Why? It was simple and understandable. Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...] So you read the comment at the top of the file and that made you question someone's sanity?
selfhoster11 4y ago
I’d trust Poetteringware over any given UEFI implementation that’s supposed to provide a trusted boot chain.

jle17 4y ago

> I don't trust Poetteringware. Poettering's team has a record of foisting technology on users, resulting in the need for e.g. the Devuan fork. They have been developing software, that enough people have deemed useful to include it in their distributions. Some have disagreed, and have made other choices. No one was forced to do anything, there have been no "foisting" and the "need" for Devuan is a subjective opinion. There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development.

hdjjhhvvhga 4y ago
> There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development. While I agree with you in general, for some reason this particular developer tends to take decisions that have very extensive consequences and make choice extremely difficult.
- kevincox 4y ago
  A developer that has been able to make tough choices and drive them well enough to get mass adoption? He definitely isn't perfect but this sounds like quite the feat in Open Source.
  - hdjjhhvvhga 4y ago
    There is a huge difference between a developer who creates a superior project that everybody loves to use so it gets mass adoption and one who makes a product that gets pushed by their employer on everyone whether they want it or not. I don't want to get into details as the subject has been beaten to death but as for Systemd* there was the case of integration with graphical login that made choice difficult. Had the author been more sensitive to this issue and cooperated a bit without being stubborn we wouldn't have had Devuan and all that mess. This is exactly NOT the way to do things in open source. *PulseAudio was simply broken but it's not the fault of the author distros picked up aplha-quality software
    - growse 4y ago
      > This is exactly NOT the way to do things in open source. Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?
      - hdjjhhvvhga 4y ago
        For applications, tools, even most libraries - yes. But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.
        Foxboron 4y ago
        >But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited. This isn't very accurate. When Debian decided to switch to systemd, they also agreed to support other inits in the distribution. This wasn't good enough, so Devuan itself was forked before this decision was made. The end result is that Debian had less people to support the init script alternatives. It became a self-fulfilling prophecy. I'm confident Debian could support other inits if there was more Debian devs available to work on it. But because people left for Devuan the pool becomes smaller. Even the last decision on inits from Debian says that the focus should not solely be on systemd. https://lwn.net/Articles/808217/ https://lwn.net/Articles/808217/
- denton-scratch 4y ago
  I didn't make a personal attack on Poettering; my objection is to the software his team produces. And I wasn't making any technical argument; I don't know enough about TPM and secure boot to do that. My point was a political one, I guess: this is more software that runs very deep in the system, coming from a team that has a record of producing software that is hard to opt-out of. For PulseAudio on Debian, you have to take firm steps to ensure the package manager doesn't reinstall it. Much the same goes for systemd. I assume it will be much harder to opt-out of a secure boot released by that team. I believe that's on purpose: they could have made it easier to run without those packages, if they'd wanted to. I think it's clear that they wanted the opposite.
lmm 4y ago
Systemd was designed in a way that was more tightly coupled than the alternatives and made adopting it an all-or-nothing proposition, and other projects (particularly Gnome) were also tightly coupled to it. It was absolutely foisted on people: a lot of people didn't want it but found they were nevertheless obliged to install it. The whole thing abused the goodwill of the free software community: systemd folks added systemd-dependent patches to other software, taking advantage of the norm of accepting such contributions, while refusing patches that made systemd compatible with other systems (e.g. non-Linux). And the end result was a state where you can no longer fork and replace components piecemeal - the whole free software ethos, the very reason GNU was built as a Unix-like system in the first place - which does far more to discourage participating in free software development than any mere internet argument.
- jle17 4y ago
  The tight coupling, the non-portability, all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers. Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything. People got systemd on their OSes because they chose OSes whose developers chose to move to systemd. It's not like Lennart comes to your home with a gun if you install OpenBSD.
  - dogleash 4y ago
    > all of that are technical choices, that can be debated on their own merit without the need to attribute malevolent intentions to the developers The ramifications of those technical choices on the software ecosystem are so well understood [0], that there is no point in discussing "their own merits" in a vacuum. What's most relevant to my professional and waning hobbyist interests are the shape and trajectory of the software ecosystem as a whole. To talk about systemd without talking about how it's developers interact with the software ecosystem is to talk about nothing. [0] I graduated before systemd was a glint in Pottering's eye, but we somehow still covered it in school. Not only coupling vs cohesion in the abstract, but also how various design decisions (including init system arguments of old!) interacted with the ebb and flow of unix-like OS evolution.
carapace 4y ago
You are completely missing the point. Please don't fan this flame.

gsich 4y ago

Going back to the init.d clusterfuck is insane.

public_defender 4y ago
I was thinking this in a general sense, but I recently tried a distro with openrc and it was quite nice. Maybe things have changed.
krzyk 4y ago
Why? It was simple and understandable. systemd has everything and a kitchen sink, it is a big blob of software. Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing that made me question sanity of distro maintainers and author of two worse pieces of software: pulseaudio and systemd. (I was very surprised that it was the same person).
- vetinari 4y ago
  > Why? It was simple and understandable. Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks. > systemd has everything and a kitchen sink, it is a big blob of software. You can still pick and choose. Systemd is an umbrella project. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver systemd-resolved is exactly one of the things that you can pick and choose. > was the final thing that made me question sanity of distro maintainers And there are good reasons for that: 1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down). 2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.
- Avamander 4y ago
  > Why? It was simple and understandable. Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use. > Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...] So you read the comment at the top of the file and that made you question someone's sanity?

selfhoster11 4y ago

I’d trust Poetteringware over any given UEFI implementation that’s supposed to provide a trusted boot chain.