Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian 13 “Trixie”

debian.org

Post reply on HN
Print view View original

181–190 of 428 posts

Re: Debian 13 “Trixie”

#181

Post by heresie-dabord »

ACS_Solver wrote: post #25

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…

Debian is my foundation. I keep servers on Old Stable and test new release features on an ephemeral system.

I learned nftables with Bookworm and labwc with Trixie.

labwc supports Wayland with Openbox configuration.

Re: Debian 13 “Trixie”

#182

Post by champtar »

b112 wrote: post #48

For those worrying about the NIC change with systemd, this comes from the release doc: https://www.debian.org/releases/trixie/release-notes/issues.... # example: udevadm test-builtin net_setup_link /sys/class/net/eno4 2>/dev/null ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link ID_NET_LINK_FILE_DROPINS= ID_NET_NAME=eno4 Here's a one-liner, excluding a bond interface and lo. Gives a nice list of pre and post…

Hopefully the last breaking change.

enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.

ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.

Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)

Re: Debian 13 “Trixie”

#183

Post by WD-42 »

raggi wrote: post #136
kasabali wrote: post #128

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…

One of the unsung praises of Arch is that it's turned thousands of users into testers. Before someone says "that shouldn't be the user's responsibility" I'm going to say I'm not so sure. We're all in this together. I'd rather deal with a bug or two on my desktop at home if it means it gets fixed before appearing in a distro that gets used for servers at work and causes issues there where the consequences are much higher.

Re: Debian 13 “Trixie”

#184

Post by yjftsjthsd-h »

homebrewer wrote: post #175
sofixa wrote: post #150

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…

> systemd 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' sy…

>> podman, buildah

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

NIH packages are generally expected to be less popular, yes. They have some technical merit, though in my opinion that's mostly trade-offs rather than one being strictly better than the other. I would be surprised if everybody using them is using them because of technical merit as opposed to it being pushed by the distro.

Re: Debian 13 “Trixie”

#185

Post by yjftsjthsd-h »

esseph wrote: post #132
binwiederhier wrote: post #30

Thank you to all the Debian volunteers that make Debian and all its derivatives possible. It's remarkable how many people and businesses have been enabled by your work. Thank you! On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked fo…

It might be a better idea to release this as a container (if it isn't already) to take care of the dependencies.

https://docs.ntfy.sh/install/#docker

> The ntfy image is available for amd64, armv6, armv7 and arm64. It should be pretty straight forward to use.

Re: Debian 13 “Trixie”

#186

Post by ACS_Solver »

sofixa wrote: post #150
npteljes wrote: post #65

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…

Red Hat builds really good stuff. NIH is sometimes right because nobody invented the stuff at all. Standard Unix tools are great but they don't solve everything, so we've ended up with most distros having "the Debian way" or "the Red Hat way", the main difference of course being deb/apt/dpkg vs rpm/yum/dnf. When building an embedded system with Yocto, the basic choices are also Debian or Red Hat style, though you can of course do anything.

Special mention goes to NetworkManager, which has become the de facto standard way to configure networking because it's good. And with nmcli I can even remember how to connect to wifi from single user mode.

Re: Debian 13 “Trixie”

#187

Post by yjftsjthsd-h »

Narishma wrote: post #74

> Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. What I did is switch to NetBSD.

In the abstract I'm a big fan of supporting me old machines forever, but I have to ask out of curiosity - what hardware is practical to run these days and only has a 32-bit processor?

Re: Debian 13 “Trixie”

#188

Post by ants_everywhere »

bayindirh wrote: post #54
mmcnl wrote: post #49

Earlier quoted context omitted.

I don't really understand why this is such a big problem. You don't have to use snaps.

You're right. You don't have to use snaps. Ubuntu migrates packages slowly in behalf of you. Using apt to install some packages installs snap plumbing and downloads the package as a snap automatically. You don't have to install it manually. There's no malicious intent though, it's made to "impose a positive pressure on the snap team to produce better work and keep their quality high" (paraphrased, but this was the of…

Installing the inferior snap packages when you apt get is one of the worst cases of a Linux distro refusing to respect the user's intent that I've experienced.

Re: Debian 13 “Trixie”

#189

Post by winrid »

accrual wrote: post #17

> i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. Impressive that i386 support made it all the way to A…

Man, I thought I was behind using a P3 in like 2007 lol. You can get something 100x faster for $1 :D

Re: Debian 13 “Trixie”

#190

Post by fhdnfjf »

I'm too impatient to use a non-rolling release distro like Debian as my main OS, that, by my standards, already starts a new distro version with some outdated packages. I admire Debian though and it is my favorite server OS.
Post reply on HN