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

121–130 of 428 posts

Re: Debian 13 “Trixie”

#121

Post by ACS_Solver »

madars wrote: post #111
bayindirh wrote: post #104

Earlier quoted context omitted.

Which GPU, display server and compositor stack are you using?

Integrated Intel GPU and no graphical system, just KMS VT (text console). That's what made it so frustrating - only displaying a console should not result in kernel panics under CPU load! Admittedly, the experience was anecdotal and years ago and I heard Debian is doing less of a RHEL-style "frankenkernel" now.

drm/i915 was a pretty miserable experience for me on one machine. The Intel drivers for that chipset around the 5.3 kernel era weren't good, I recall lots of bug reports at the time. Below is one of the several issues that I was affected by

https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/673

Re: Debian 13 “Trixie”

#122

Post by brirec »

madars wrote: post #93
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…

>I've never had a Debian system break without it being my fault in some way. Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In…

These days all of my “Debian” bare metal systems are technically running Proxmox, which I think is a relatively happy medium as far as the base Debian system goes — the Proxmox kernel is basically the Ubuntu kernel, but otherwise it’s a pretty standard Debian system.

I’ve thought about (ab)using a Proxmox repository on an otherwise stock Debian system before just for the kernel…

Re: Debian 13 “Trixie”

#123

Post by hsbauauvhabzb »

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…

And one of these migrations broke my workflow substantially enough that a dist-upgrade turned into a complete system reformat to Debian and cost hours that I couldn’t afford.

Debian has been a safe haven since.

Re: Debian 13 “Trixie”

#124

Post by npteljes »

Santosh83 wrote: post #75
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…

Snaps per se are no better or worse than flatpak. Canonical's mistake, IMO, was to make their store the only place snaps can be hosted. That is the "proprietary" bit everyone keeps talking about. But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub, so both formats have only one store right now. But flatpak allows a custom store while…

Yes, I agree. Snaps or Flatpak, not much of a practical, technological difference. What sets them apart is the way the distribution is handled, including the open source availability of the backend, which enabled for example Red Hat and Elementary to run their own stores.

Re: Debian 13 “Trixie”

#125

Post by tremon »

munchlax wrote: post #59
zozbot234 wrote: post #22

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.

It still exists but without any official iso or installer. If that's all there's to it, you can still use debootstrap, compile a kernel, and point the root parameter to your shiny new install. If the official i386 arch was built with instructions that your hardware doesn't support, tough cookies.

If the official i386 arch was built with instructions that your hardware doesn't support, tough cookies

While theoretically possible, that would only happen on processors older than 30 years. Debian's i386 architecture still uses -march=i686 as its baseline compiler target, which is the venerable Pentium Pro: https://en.wikipedia.org/wiki/P6_(microarchitecture)

Re: Debian 13 “Trixie”

#126

Post by treve »

perdomon wrote: post #120

How soon can I update my raspberry pi 5 from Bookworm to Trixie? Does PiOS have to initiate that first?

Raspberry Pi OS is a derivative and not straight up debian. It's not a released yet. A beta exists and looks like this one will support an in-place update

Re: Debian 13 “Trixie”

#127

Post by npteljes »

bayindirh wrote: post #81
Santosh83 wrote: post #75

Earlier quoted context omitted.

Snaps per se are no better or worse than flatpak. Canonical's mistake, IMO, was to make their store the only place snaps can be hosted. That is the "proprietary" bit everyone keeps talking about. But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub, so both formats have only one store right now. But flatpak allows a custom store while…

Another problem is, Canonical promised to release server components and enable alternative stores, and just forgot that they made that pledge. Also, rugpulling users and migrating things to snaps without asking their users in order to "create a positive pressure on snap team to keep their quality high" didn't sit well with the users. > But in practice even for flatpak the only realistic place you can publish your fla…

Yes, same. I started with Ubuntu back in the day, because the server I inherited ran Ubuntu, and it was just natural after that for me to run it on the desktop as well. I grew to dislike their NIH over the years, tried distro hopping, and settled on Debian.

Re: Debian 13 “Trixie”

#128

Post by kasabali »

madars wrote: post #93
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…

>I've never had a Debian system break without it being my fault in some way. Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In…

> 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 been bit by.

Re: Debian 13 “Trixie”

#129

Post by rahen »

Eduard wrote: post #60
zvmaz wrote: post #44

Earlier quoted context omitted.

> after Ubuntu went way downhill and haven't had cause to regret it. In what way Ubuntu went downhill?

all the weird proprietary Canonical stuff they try to put into vanilla Debian and have it replace common stuff. snap, lxd (not lxc!), mir, upstart, ufw. It's neverending, and it's always failing.

LXD was forked as Incus, and it’s an absolute delight.

Seamless LXC and virtual machine management with clustering, a clean API, YAML templates and a built-in load balancer, it's like Kubernetes for stateful workloads.

Re: Debian 13 “Trixie”

#130

Post by b112 »

egorfine wrote: post #95
b112 wrote: post #14

You can still use sysvinit, I've already tested servers and desktop builds. From my build box: chroot $MOUNTPOINT/ /bin/bash -c "http_proxy=$aptproxy apt-get -y --purge --allow remove-essential install sysvinit-core sysvinit-utils systemd-sysv- systemd-" There is a weird depends you cannot get around without simultaneously removing and installing in parallel. A Debian bug highlighted the above, with a "-" for systemd…

Wait, sysvinit on debian 13 truly practically works?? as in, one can remove systemd and have a working server OS with sysv init??

Yes.

I run a full desktop too, without it. Multiple variants.

I don't use gnome's Desktop Environment though (although I do run gtk/gnome software), so cannot comment on that.

Post reply on HN