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

131–140 of 428 posts

Re: Debian 13 “Trixie”

#131

Post by garbagecoder »

Barrin92 wrote: post #43
josteink wrote: post #23

Earlier quoted context omitted.

> Should his contributions to open-source projects be rejected? As someone whose attitude towards open-source is that it's the code who should do the talking, and not who contributed it (nor the colour of their skin, or their sexual orientation, etc) ... I'd say he should be able to contribute code, as long as the code is good enough. Same rule as every other code-contribution. But the Debian-project has made the dec…

>Even after having served his time, there's still a certain stain there In Western jurisprudence the basis for society enacting punishment on criminals is that the punishment is just. One characteristic of that is it that it is proportionate which means it has an end . Criminals who have done their time don't have "stains" or marks as if they're Cain, they have a right to reintegration, because if they didn't, what e…

[flagged]

Re: Debian 13 “Trixie”

#132

Post by esseph »

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.

Re: Debian 13 “Trixie”

#133

Post by type0 »

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…

If you are making your own distro, creating your own flatpak store is trivial, that's all what matters. Linux Mint doesn't use snap exactly because Canonical forces everyone to use their snap store.

Re: Debian 13 “Trixie”

#134

Post by bayindirh »

superkuh wrote: post #6

Biggest change for me is /tmp behavior. In Debian 13 /tmp become RAM-disk by default (instead of files on the file system) and uses up to 50% of available ram. But as expected of Debian the release notes included an easy fix to restore normal /tmp behavior for people and applications that place many small or large files there. https://www.debian.org/releases/trixie/release-notes/issues.... >"You can return to /tmp be…

This was discussed a ton in debian-devel. First, the tmpfs doesn't take much space already, and /tmp became a folder where persistence should not be expected over the years.

The problem with /tmp was many people and apps used it as an inter-user communication medium and expected persistency there, so it created both security problems and wasted disk space over time.

Since not many packaged apps used the /tmp like that and used the folder the way it should be used, the change was made.

I'm running Debian testing on one of my systems, and the change created no ill effects whatsoever. Not eating SSD write cycles can be considered a plus, even.

However, as I also noted in the relevant thread, the approach might have a couple of downsides in some scenarios.

If you have the time and the desire, discussion starts at https://lists.debian.org/debian-devel/2024/05/msg00014.html

Re: Debian 13 “Trixie”

#135

Post by winter_blue »

tremon wrote: post #84
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…

The maintainer has a short explanation here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10 > The webapp is a nodejs app that requires packages that are not currently in debian. Since vendoring dependencies inside packages is frowned upon in Debian, the maintainer would have needed to add those packages themselves and maintain them. My guess is that they didn't want to take on that effort.

> but several features in ntfy won't be available through debian packaging due to missing golang and nodejs packages

Woah. Shouldn’t Node and Golang be in Debian’s official repos by now?

Re: Debian 13 “Trixie”

#136

Post by raggi »

kasabali wrote: post #128
madars wrote: post #93

Earlier quoted context omitted.

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

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 continued to be so as AWS, GCP and others copied their kernel patch trees and blindly shipped the same problems to users and refused to respond to bugs and emails.

You're right stability comes from testing, not enough testing happens around Linux period, regardless of which branch is being discussed.

It's not easy testing kernels, but the bar is pretty low.

Re: Debian 13 “Trixie”

#137

Post by pss314 »

A new APT sources format "debian.sources" is announced with trixie. The now older "sources.list" format is still supported, but is likely to be deprecated in a future Debian release.

See below:

  APT is moving to a different format for configuring where it downloads packages from. The files /etc/apt/sources.list and *.list files in /etc/apt/sources.list.d/ are replaced by files still in that directory but with names ending in .sources, using the new, more readable (deb822 style) format. For details see sources.list(5). Examples of APT configurations in these notes will be given in the new deb822 format.

  If your system is using multiple sources files then you will need to ensure they stay consistent.
- https://wiki.debian.org/SourcesList#APT_sources_format

- https://www.debian.org/releases/trixie/release-notes/upgradi...

"apt modernize-sources" command can be used to simulate and replace ".list" files with the new ".sources" format.

  Modernizing will replace .list files with the new .sources format, add Signed-By values where they can be determined automatically, and save the old files into .list.bak files.

  This command supports the 'signed-by' and 'trusted' options. If you have specified other options inside [] brackets, please transfer them manually to the output files; see sources.list(5) for a mapping.

Re: Debian 13 “Trixie”

#138

Post by jm4 »

stouset wrote: post #15
heikkilevanto wrote: post #8

Earlier quoted context omitted.

Citation needed. I honestly do not know what you are referring to. Even if I had to take your "sexual predator" at face value, I would still have to balance that against the good stable reliable distro they have been done for so many years.

I too had no idea what he’s talking about, so I did some digging. So, an open-source contributor who works for Canonical on Ubuntu gave a talk at Debconf. He is a convicted and admitted sexual predator who served time in prison for his crimes. This all is pretty well-documented. But… then what? He did the time for his crimes. He’s on the national sex offender registry. What now? Should he be unemployable? Should his…

That's the guy. Fair enough to say he served his time and should not be unemployable. I can agree with that in principle. I would not advocate rejecting his open source contributions. If Canonical wants to employ him after doing their due diligence, that's their business. Inviting him to be a speaker and representative of the project is a bridge too far. Is there no one more qualified?

Re: Debian 13 “Trixie”

#139

Post by baobun »

winter_blue wrote: post #135
tremon wrote: post #84

Earlier quoted context omitted.

The maintainer has a short explanation here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10 > The webapp is a nodejs app that requires packages that are not currently in debian. Since vendoring dependencies inside packages is frowned upon in Debian, the maintainer would have needed to add those packages themselves and maintain them. My guess is that they didn't want to take on that effort.

> but several features in ntfy won't be available through debian packaging due to missing golang and nodejs packages Woah. Shouldn’t Node and Golang be in Debian’s official repos by now?

Yes but not all packages written in those languages are.

Re: Debian 13 “Trixie”

#140

Post by seba_dos1 »

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…

The upstream kernel already backports enough regressions on its own to its stable releases, Debian's kernel team does not help them too much with that.
Post reply on HN