I really understand why Ubuntu migrated Chromium to snaps only. Splitting all the code it embedded back to the original libraries is certainly a nightmare.
It's really a pity vendoring & static linking has become so widely accepted, so prevalent.
It allows such drift from upstream, freedom from responsibility to maintain yourself as something modern. It increases both the size of what you have to distribute, and the memory profile. And it means that when a security update is necessary, each library consumer has to be responsible & on-time with delivering updates rapidly.
It feels like it was created out of such petty, small needs & wants. It's convenient to be able to copy a binary around anywhere, & have it just work. It's convenient to stand off, on your own, ignorant of the world you exist in. But it's so contrary to me to good healthy engineering practices, enables such radical irresponsibility & divergence. I don't see a lot of push back to static linking, but it feels like a modern & popular plague to me. Go, rust, the whole world software development world seems to be increasingly less interested in systems, & more interested in itself.
The counter point from an application developer point of view is that it requires a lot of resources to distribute an application across the many Linux distros. Given it is just one of the 3 major desktop operating systems an application is targeting (Windows, Mac), one cannot push the work back to the application. Applications should do what makes sense to them, distros should either put in the work or perhaps, standardize the mechanism to specify dependencies across distros so the work can be done once.
To your point about security patches in dependencies, Chrome auto updates itself to patch vulnerabilities. Their users on Windows/Mac appreciate this behavior. Switching to a different model for Linux is work on their part, isn't it?
Static linking based distribution like snaps might also achieve most of the goals listed above if the file system can share relevant file blocks across applications in a seamless manner. So Chromium could bring in its own glibc or use glibc file blocks already pulled in by another application.
Hi, are there missing security updates in Debian chromium or such risks? I use Debian because bandwidth is precious, and avoided chromium for fears of chromium's fast development leading to Debian missing some important patches. I don't care about newest version anyway.
You can also install the Iridium Browser fork, which I believe is not far from the original chromium. It integrates nicely to the apt ecosystem (and others too).
I haven't been paying attention to debian packing of chromium, but I am wondering, is the situation on testing or unstable any better?
I used debian on desktops and laptops spanning several decades and IMO a typical desktop user probably doesn't want to stay on stable, that's been my experience anyway. Machines I don't use interactively I've kept on stable though.
I use Debian stable my primary desktop OS and for servers. I just stick to flathub, backports, install from vendor or build from source if needed/easily done. Works well enough for me, although I can see it may not be for everyone.
This makes sense. In recent years I had so many problems compiling things on Debian that needed newer libraries that I caved and went to Ubuntu. But I still run in to library conflicts and I have long felt like I am abusing my system when I try to force some slightly unsupported libraries on to my system to compile someones github code at 3am.
I suppose if I lean more on containers for development and flatpack etc for programs it would be easier to maintain a Debian stable system. Debian has been great for me aside from having older libraries!
Well, you can try to help, but there is no guarantee that your help is welcome. You will have to do the work, then convince the maintainer to accept it. If the maintainer is unresponsive, you may work for nothing. This seems the case here: we don't know why the maintainer is unresponsive. And people can't casually upload a new version due to strong ownership culture.
Would the stable release managers not accept a non-maintainer upload? I agree the strong ownership culture is a serious problem, but it mostly affects unstable, right?
Chromium is maintained by only one person in Debian. This person is currently unavailable. Debian does not have good procedures to handle unavailable maintainers. There are also older reasons why there is only one person. In the past, it was a two-person effort.
Yes, but also with new updated installation media images.
Historical context: It wasn’t always like this; Debian 3.1 was a major release after Debian 3.0, and Debian 6.0 had minor releases up to 6.0.10. This did not change until Debian 7 (which was called 7, not 7.0, and had a minor release numbered 7.1). Therefore, many people might still assume that an increase of the first minor version number is a major release, even though it is not true anymore.
Consider using Devuan, the Debian variant which removes systemd. It is basically in sync with the current Debian, with only a minimum of packages changed for the systemd removal.
As others have said - I don't want to hijack this thread in favor of a systemd-yes-or-no argument. In fact, I made it a point not to use derogatory or inflammatory language in my post, and still got a bunch of downvotes.
you will find stories involving systemd here on HN over the past several years. I and many others oppose various aspects of systemd, but more importantly, we oppose its being a nearly-inescapable default on Debian. It's not like you can just remove it if you want something else.
