Debian 10.7 Released | Hacker News Reader

Debian 10.7 Released

debian.org

114 pointsjbergstroem44 comments

Still no chromium update. It should just be removed if there is no interest in updating the browser.

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.

If you don't have the manpower then don't. It's that simple.

Debian's policy stands in direct contrast to Google's so you're fighting an uphill battle against $number developers.

Debian prefers dynamic linking: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#...

Whereas Google wants everything vendored: https://opensource.google/docs/thirdparty/chromium/

This is a common problem that also apply to K8s, LWN recently have this article: https://lwn.net/Articles/835599/

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.

Have you considered that the benefits might outweigh the costs?

i know i know, we all want things to be easy, i get it, yeah. static linked stuff is definitely that.

You may be interested in the discussion on bug #972134 [0].

[0]: https://bugs.debian.org/972134

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.

For getting chromium you have a couple of options:

* You can use chromium flatpak version from Flathub

* You can add the Linux Mint repos, and install the chromium package from there (untested)

* You can install the chromium snap (not recommended due to slow launch times)

Sure, but if those are the options then having an old version in the main deb repos is at best unhelpful and confusing.

I use ungoogled-chromium https://github.com/Eloston/ungoogled-chromium

Tho the .deb binary is not up to date yet https://ungoogled-software.github.io/ungoogled-chromium-bina...

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).

https://iridiumbrowser.de/downloads/

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!

You can safely put newer libraries in /usr/local/lib.

https://packages.debian.org/search?searchon=sourcenames&keyw...

buster (misc): 83.0.4103.116-1~deb10u3

bullseye (misc): 83.0.4103.116-3.1

sid (misc): 83.0.4103.116-3.1

experimental (misc): 84.0.4147.105-1

https://tracker.debian.org/pkg/chromium

Why is a snap slower than a flatpak?

Because of its use of a compressed backing store, requiring decompression before launch (IIRC).

If it's important to you, you should help with the work that's needed.

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.

https://bugs.debian.org/972134

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?

GP has a point. Removing it would be better than having a way outdated browser in the repos.

I remember Debian keeping Chromium up-to-date, what changed?

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.

Ubuntu moved to snaps, maybe just less manpower on building chromium dpkg's?

That's not the reason, Ubuntu still build deb chromium updates for 18.04, this is just a Debian policy or something else Debian specific

Or perhaps Firefox. All the haters say it's a Chrome copy anyway, right? But seriously, why Chromium?

Though is easy to get Firefox linux from mozilla, Debian stable repos only have Firefox-esr.

Important to note that this is just a patch release with bugfixes, not a new major version.

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.

English version direct link:

https://www.debian.org/News/2020/20201205.en.html

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.

https://www.devuan.org

The current release is Beowulf, corresponding to buster.

The website says Devuan let's you "reclaim control over their system by avoiding unnecessary entanglements", what's wrong with systemd?

Please let's not start this discussion again, when it's been done to the death in other easily-searchable places on the internet before.

The (IMHO) best critique I'm aware of is at https://blog.darknedgy.net/technology/2020/05/02/0/ (discussed https://news.ycombinator.com/item?id=23062072 )

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.

At this link: https://hn.algolia.com/?q=systemd

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.

Not much, but Unix purists would argue that systemd violates the Unix philosophy. https://lwn.net/Articles/777595/

> what's wrong with systemd?

It was written by a cowboy coder and issues have cropped up that indicate no serious code review has been performed.

Reply on news.ycombinator.com