Live data from Hacker News

Debian 13 “Trixie”

debian.org

401–410 of 428 posts

Re: Debian 13 “Trixie”

#402

Earlier quoted context omitted.

I don't think it is? Or at least, it only was on some particular older Debian release.

I think that was the version the patch was introduced, it's certainly in-place on Trixie (which has 3.13).

Oh. If it's still there, I guess nobody's given them any impetus to revisit it...

Re: Debian 13 “Trixie”

#403

Earlier quoted context omitted.

I can’t fathom why anyone would be surprised that a directory named “tmp” is ephemeral.

It could be the 20+ years of using linux where it was standard for it to only have files there deleted on boot. Temp in this case means it's temporary for that boot. Recent redefinitions are surprising unless you've only come to linux recently or from unix 40 years ago. I am going to assume you are used to tens of days wipings of /tmp. Imagine suddenly it was decided that the wiping needed to happen every tens of sec…

No, I misunderstood the comment I was replying to, and thought they were assuming they could use /tmp as an un-curated dumping ground that was never deleted.

I also am used to it being wiped on boot.

Re: Debian 13 “Trixie”

#404
post #9

I can't believe we've come to such a high number, and a particularly lucky one at that Alas it's still not suitable as a daily driver for the average home user and probably never will be. It is unfortunate that Ubuntu has to reign supreme in that regard.

You can install debian and ubuntu with same DE and you'd be hard pressed to find a difference apart from the theme unless you are a power user who knows what snap is. In fact, Ubuntu has never been an especially user friendly distro. At the beginning it was just a debian that was installed with debian's experimental installer before they decided to use it in stable. Nothing more, nothing less. If you wanted to find a…

Or unless the capacity of you harddisk is limited, filling up with huge snap packages.

Or you need something that is broken by snap. I helped a user after thunderbird after an upgrade could no longer open PDF-s in okular. It turned out that the thunderbird dpkg had been replaced with a snap and I spent quite some time trying getting it to work, filed bug reports, etc, before giving up and installing from Mozilla until I replace it all with Debian.

Re: Debian 13 “Trixie”

#405

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something: > 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System…

Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to suppor…

How and why is this relevant to debugging?

Also, like it or not, the word "tainted" bears a negative connotation. It's hard to imagine that it was chosen arbitrarily.

Re: Debian 13 “Trixie”

#406

Earlier quoted context omitted.

Debian is not cautious with the dependencies. Debian breaks a lot of what they ship, sometimes flagrantly like removing a whole feature, sometimes insiduously by introducing new bugs. I don't really care that Debian doesn't view it as breaking things. From my point of view, users trying to get my product get subpar experience in a way which is far from explicit. I personally wouldn't use Debian but people are free to…

Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos. I don't want to install an app that downloads and executes 500 node packages that I don't know what they do. Those packages should already be vetted and in Debian. If not, then I'm not interested. Side stepping the distro repos for dependencies for software in the repos leads to unexpected behavior.

> Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos.

For a definition of cautious I don't personally share.

Debian doesn't vet packages. Debian maintainers are less competent than the "upstream" they question approximately all the time, which is why they keep breaking stuff in more or less severe way (OpenSLL anyone?). And let's not even talk about the insane stuff like when maitainers decide to support a fork they like instead of the piece of software users actually want (Libav anyone?).

> If not, then I'm not interested.

And that's your choice. That doesn't mean developers should care, nor that it is actually a good idea.

Re: Debian 13 “Trixie”

#407
post #354

Earlier quoted context omitted.

Linux mint technically still does, perhaps because they’re lagging behind Debian. AntiX does but that has its own tradeoffs. With full potential respect for your situation, if you’re not able to obtain 64 bit hardware, there’s nothing that wrong with not upgrading your OS for now

Bookworm will get updates for another year if I have read the Debian Wiki correctly so perhaps there is no need for immediate action as Bookworm becomes oldstable? In addition to Mint and AntiX there is also Slackware (I use xfce rather than KDE) but adding software outside the (large) base install is not an 'apt-get thing' process. Salix Linux, based on Slackware, does have package repositories with a reasonable sel…

I also use xfce, my computer is an Acer Aspire One, limited in ... well everything, I did upgrade the storage to an SSD, but it's still an Atom CPU, so whatever is the lightest is the best.

Re: Debian 13 “Trixie”

#408
post #385

Earlier quoted context omitted.

Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.

Oh thanks, I totally missed that distinctions. You’re right. My first thought is to wonder: why would systemd care about this then? Any idea? My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during b…

> with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin?

There really isn't any, the sysmlink being for compat. Early boot is nowadays taken over by an initrd/initramfs. Some say what you say sbin was for were actually the root /bin (early boot) and /usr/bin (elsewhere) but it was all just so arbitrary and no-one could actually agree on what is for what actually.

Some say sbin is for static binaries, others for superuser binaries and either destinction really doesn't make sense nowadays as earlyboot is initrd and a lot of "superuser binaries" actually also are fine to use unprivlidged in certain scenarios (e.g. `mkfs.*` for making disk images) so having them in a separate dir is just arbitrary (e.g. `cat` can also fail if I cat the shadow file).

Re: Debian 13 “Trixie”

#409

> The overall disk usage for trixie is 403,854,660 kB (403 GB), and is made up of 1,463,291,186 lines of code. This makes Debian Trixie about 32 times larger than Windows XP with approximately 45 millions lines of code, arguably the best Windows OS ever. Debian Trixie is released about 24 years after Windows XP.

> Windows XP with approximately 45 millions lines of code, arguably the best Windows OS ever.

Naah. Early(ish) Win7, or maybe even late Vista.

Post reply on HN