171–180 of 428 posts
https://www.debian.org/donations
Not affiliated, just a happy user for a long, long time.
Earlier quoted context omitted.
Defaults matter a lot, and snaps are the default in Ubuntu. The topic is not whether snaps are avoidable or not, but the Ubuntu is going downhill. And snaps are purported to be part of that downhill, which would be Ubuntu's NIH syndrome. As far as I know, Ubuntu's only successful development is Ubuntu itself - the other projects have all failed over the years, and snap, while ongoing, is not winning any popularity co…
> which would be Ubuntu's NIH syndrome Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.) They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some…
Earlier quoted context omitted.
To what end? Outside of sheer nostalgia if you are running ancient hardware, you probably have a bespoke application which requires that environment. Either you cannot change for hard technical, compliance, or just fear of the unknown. Firewall it from the internet and continue to run whatever release last worked. I am not happy about unnecessary ewaste, but an i386 almost certainly has and order of magnitude less ho…
My Linux machine is very modern, but I still need i386 architecture support installed, because Steam requires 32-bit support. And Steam requires 32-bit support so people can play 15-year-old games. (Admittedly, the 32-bit support Ubuntu ships is less than a full OS and you can't install Ubuntu on a 32-bit machine these days)
Writing this from my Debian system, it's a great distro that has been excellent to me as a daily driver. I switched to Debian 6 after Ubuntu went way downhill and haven't had cause to regret it. I like Debian's measured pragmatism with ideology, how it's a distro of free software by default but it also makes it easy to install non-free software or firmware blobs. I like Debian's package guidelines, I like dpkg, I lik…
> after Ubuntu went way downhill and haven't had cause to regret it. In what way Ubuntu went downhill?
Earlier quoted context omitted.
Defaults matter a lot, and snaps are the default in Ubuntu. The topic is not whether snaps are avoidable or not, but the Ubuntu is going downhill. And snaps are purported to be part of that downhill, which would be Ubuntu's NIH syndrome. As far as I know, Ubuntu's only successful development is Ubuntu itself - the other projects have all failed over the years, and snap, while ongoing, is not winning any popularity co…
> which would be Ubuntu's NIH syndrome Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.) They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some…
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
> like systemd-resolved and timed
They're not forced on anybody, they're not required by systemd, and many distributions use more feature-rich alternatives (including, afaik, RHEL — last time I looked at it, they used dnsmasq and chrony). They're also often shipped as separate optional packages:
$ apt search 'systemd-timesyncd|systemd-resolved'
systemd-resolved/testing,now 257.7-1 amd64
systemd-timesyncd/testing 257.7-1 amd64
Still not anywhere near as popular as Docker. Although technically they're far better than Docker, and if anyone is using them, it's for that reason.
> dnf
Only used by RHEL and its upstream Fedora?
---
All of this makes very little sense.
Earlier quoted context omitted.
> which would be Ubuntu's NIH syndrome Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.) They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some…
Canonical did their own NIH init daemon called Upstart which failed due to the fundamental design and the implementation being plain bad. Redhat builds better software which is why their NIH gets more adoption.
Earlier quoted context omitted.
> Debian's heavy patching of kernel in Debian stable Needs citation. Debian stable uses upstream LTS kernels and I'm not aware of any heavy patching they do on top of that. Upstream -stable trees are very relaxed in patches they accept and unfortunately they don't get serious testing before being released either (you can see there's a new release in every -stable tree like every week), so that's probably what you've…
LTS has had major breaking changes in various areas in recent times too, virtio was badly broken at one point this year, as was a commonly used netlink interface. Hat tip to the Arch kernel contributors who helped track this down and chase upstream, as we had mutually affected users. The debian and ubuntu bug trackers were a wasteland of silence and user contributions throughout the situation, and frustratingly conti…
The wiki has more info on this.
Earlier quoted context omitted.
Well, isn't there an additional year or so of support for old stable? So beyond 2025.
Buster is supported until June 2028.
https://www.debian.org/releases/
Buster has not been supported by Debian for many years.
Buster LTS was EOL last summer. Note that LTS is supported by volunteers via a non-profit, not Debian (though they do a good job).
ELTS is paid support, again not by Debian.
Do look at Debian's wiki for more info on support timeframes, and what LTS and ELTS means.
Earlier quoted context omitted.
Isn't this the feature of /tmp? I set my default download location in Firefox to /tmp exactly for this reason, so that all the junk gets automatically removed after some time. Also, whenever I need a temporary Python script or test a package, I create a venv under /tmp.
On boot has been the standard for a long time and is still the most common. I am personally surprised to hear that now Debian and some distros do it via various automated ways at time intervals.
Earlier quoted context omitted.
Hopefully i386 (or perhaps a new i386-like port with added support for 64-bit time values) can move to the unofficial Debian Ports infrastructure for Debian 14 (forky) or Debian 15 (duke). Debian Ports has a m68k port, so supporting one for i386 shouldn't be a huge problem.
To what end? Outside of sheer nostalgia if you are running ancient hardware, you probably have a bespoke application which requires that environment. Either you cannot change for hard technical, compliance, or just fear of the unknown. Firewall it from the internet and continue to run whatever release last worked. I am not happy about unnecessary ewaste, but an i386 almost certainly has and order of magnitude less ho…
The goal of universal compatibility that separates the Debian project from commercial software and even other open-source projects.
The legacy x86 architecture is still far more popular than some that platforms that Debian advertises as having official support for and there has been x86 based processors manufactured for niche applications until recently, eg, AMD Geode and others.
I find it really unfortunate Debian Project is removing official support for new x86 installations. The silver lining is it seems like they'll be an unofficial port and it's likely niche distributions like MX Linux and AntiX will maintain their own builds.
It would be ideal if open-source can develop stronger mechanims to keep support for the large numbers of these relatively niche architectures (eg, through increased usage of emulation over real hardware).