I haven't ever maintained a blog, but since Linux Journal folded and I no longer work at Purism, I miss having an outlet for longer-form thoughts.
Over the last five years or so, I've observed a Renaissance in innovation on the Linux desktop that hearkens back to the Golden Era of the desktop from the mid-1990s into the aughts.
In this (pretty long, likely controversial) post, I talk through the Golden Era, Dark Ages, Renaissance, and what's next.
@kyle I often read "cutting out the middle men" in the context of distributions and packaging, but in a way, it could also be called "cutting out the quality control".
The new model of having self-service shelves where every developer can publish their goods is currently showing its downsides with npm: malware, malware, even more malware.
@patrick There is certainly still a place for curation and recommendation (Bazaar for instance has a feature to allow platforms to recommend certain software), but at least for desktop apps I wonder how much quality control is part of the packaging process in distributions, outside of just ensuring software compatibility with the rest of the system (which isn't necessary if it's in a container).
@patrick I suspect what you may mean is that the process of getting packaged by a distro in the first place is the quality control, as they act as a gatekeeper to what software is valuable enough to be made available to users. I think that constraint might be causing more harm than good.
@kyle It's a protection against the BonziBuddy scheme. But more importantly it protects against devs doing a rug pull in some innocuous-looking update (if the maintainer cares enough to look).
@patrick yeah I wonder just how often distro package maintainers audit source code changes in general, not just for security-relevant changes which they are not likely able to detect anyway (if we are talking intentionally malicious changes that would attempt to obfuscate)
@kyle @patrick I contribute to the projects that I package. I often recognize other distribution package maintainers (whose names I know through repology) contributing too ... often to 'minor'/point releases.
The mentality is "this bug bugs me, I want it fixed before releasing to my [distro's] users", which may result in carrying a downstream patch which is quickly upstreamed, and sometimes encouraging upstream to release a point release with the fix.
