Antiquated Debian Development, what impact for PureOS?


#1

Michael Stapelberg, a Debian package maintainer has written an interesting piece about the atniquated state of development on Debian and the reasons why he is giving up after 10 years of package maintenance.

The closest to “sending out a change for review” is to open a bug report with an attached patch… Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.

Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don’t want to be discussing systemd’s merits 10 years after I first heard about it.

Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference. Granting so much personal freedom to individual maintainers prevents us as a project from raising the abstraction level for building Debian packages, which in turn makes tooling harder.

Given that PureOS is a fork of Debian, I wonder if this is something that developers of PureOS are concerned about and whether this will have any impact on PureOS in the future?


#2

I’ve wondered about the state of deb based distros for a while and eventually jumped from Mint (my first foray into linux) to Fedora for more updated software for development.


#3

Interesting topic and well worth researching. Speaking as someone who works building packages and images for PureOS, that article holds a lot of important points. Software development, particularly GNU/Linux software development, is under constant change and it’s pace and contributions are increasing. I think we try and understand the entire ecosystem as much as possible (Guix, Nix, Yocto, other distros) but our mission of protecting privacy and security is well served by Debian.


#4

the way i see things … debian is just the foundation on which PureOS is built and at any point in time if the situation or external conditions change it can become something more. just because it is based on Debian doesn’t mean it IS debian 100%. it’s just like a parent - child relationship. similar but different simulataneously.


#5

You’re right, PureOS is not simply Debian. We patch some parts and add some packages. The biggest change is the addition of Pureboot but we contribute everything we do so others may use it and that includes contributing changes upstream to Debian.


#6

hi there! :slight_smile:

in this case, anyone could suggest for the debian core team whatever like put indicators on the packages for time they are merged… the deb core team have a big duty, and they take it seriously, so any suggestion is welcome there, or at least i really dare to believe that, but im not there, just seen stuffs around the topics. btw debian and ,deb based distros are still the most popular ones… ive seen debian maintainers around projects, but none from the rpm line. stuffs like void are small. arch is rolling release, so that line is totally not suitable for servers, where stability is the 1st thing of all, so its not that universal like debian, even if we are currently talking about notebooks and phones here. however in case of need to rebase anything, i think the 2nd place is for redhat, but i still feel debian nearer to my hearth, and i think canonical is not the sole reason for the no 1 place of the debian line, but who knows…

an another stuff is that recently ive found some news about systemd, and that its about consuming the boot loader as well, so im asking u, if u know any caveats of this related to pureos?

bests, thx for anything about the systemd stuff! :slight_smile:


#7

Clearly, because that is describing something that has to do with UEFI. It feels like people are constantly on the lookout for something to complain about with regards to systemd, and I can’t understand where the strong emotions are coming from. And I’m pretty sure these are emotional responses to something, because the arguments are rarely sound, and in this case I can’t see how it has anything to do with the conversation up to this point.


#8

I read the opinions of Michael Stapelberg and I agree with some of his, but not with everything. Many things he writes are just his personal taste. E.g. he prefers web forms over email to enter bugs, others don’t and John Goerzen explains, why he prefers the current way of entering bugs:

Also, some points are addressed by the Debian developers since some time, e.g. most package sources are now available via one server, salsa.debian.org, as Lucas Nussbaum explains:

https://www.lucas-nussbaum.net/blog/?p=941

Debian development has, as happens with every project that grows over many years and a considerable size, it’s sluggishness, but there is nothing fundamentelly wrong and I completely refuse to take the personal opinions of Michael as something Purism should worry about.


#9

Indeed. And if Purism was worried, the Debian project lead, who is employed by Purism, might be able to inspire change.


#10

ahh, plz dont get me wrong…

i know those guys well, but im not really in that group! :smiley: (btw i think ur right about them!) actually its about that i have wide gaps in my knowledge about the lower level stuffs. so i know that coreboot can have payloads, like grub, and it can use the config of the grub that is installed onto the disk, so its not necessary to reflash the uefi to change the boot options, while i can have full disk encryption, in case if the grub used as a payload. ive made a partial research on encrypting the /boot partition on debian without encrypting /boot/efi, as i still have a machine with a proprietary uefi, so that could enhance my security a bit more, but i didnt even have time to read about secure boot, like how much trustful it is, and how can i play with it if /boot is encrypted. i already know that me_cleaner could work now on my machine, but i dont even have a device to try to flash it, but its on my list. otoh i know that theres some kinda secure boot stuff for librem13/15 via the heads payload, but i dunno when i will get one of those… and im not even that much paranoid, its more about fun and learning, as i really like to learn stuffs about low level and security.

so back to the topic, i was about to wondering if this systemd-boot stuff would be against encrypting /boot, as i know grub can do that, but i dunno if/how systemd can achieve the same; or against the grub payload+grub on disk combo. i think its not, as if ive read it correctly, then its a compatible thing, but i wanted some confirmation from the experts. <- thats the point! :smiley:

otoh, ive heard stuffs like gnome is already relying on systemd without an alternative way (but mayb im wrong here) and i see no much happy ways for leave behind systemd (in case of need) but stuffs like the kinda outdated devuan and too exotic distributions without the power of the masses, so i wouldnt really like to use these. im not about running away, but im about to keep an eye on this mess around systemd (actually i mean the noise of the ppl around), that is actually somewhat reasonable! even if im not worried, it never hurted me, and i even learned some about its command line and config stuffs, like i actually try to live with it - currently, without any harm.

(sorry for the lengthy msg, and thx for ur time! :slight_smile: )


#11

“This topic,” as it were, seems to be a critique of Debian. It has nothing to do with systemd or bootloaders; I think it might be more appropriate for you to start a new topic rather than take this one in a drastically different direction.


#12

ur right about my 2nd explanation message that gone far, but ive just seen that my original question wasnt that far “so im asking u, if u know any caveats of this related to pureos?” just i forgot about my original intention on the way… however let it go. :slight_smile: