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

321–330 of 428 posts

Re: Debian 13 “Trixie”

#321

Post by rbanffy »

JackeJR wrote: post #212
rbanffy wrote: post #152

Earlier quoted context omitted.

The only thing I can say against Debian is that it tends to start new server software immediately after install, before I have a chance to configure it properly. Defaults are sane for most packages, but, still, it scares me a little. In that I like the Red Hat approach of installing and leaving it off until I decide to turn it on.

Just have sane firewall rules and you are good. E.g. if I install openssh-server and it auto starts, it doesn't make it out of my machine because my nftables does not allow inbound on port 22. It's just knowing the default behaviour and adjusting your practices for it.

A sane firewall won't protect you from privilege escalation from a local attacker. While unlikely, this is one more breach that could be exploited.

Re: Debian 13 “Trixie”

#322

Post by rbanffy »

Linux-Fan wrote: post #300
rbanffy wrote: post #152

Earlier quoted context omitted.

The only thing I can say against Debian is that it tends to start new server software immediately after install, before I have a chance to configure it properly. Defaults are sane for most packages, but, still, it scares me a little. In that I like the Red Hat approach of installing and leaving it off until I decide to turn it on.

It is a well-known issue with probably less well-known solutions, cf. https://unix.stackexchange.com/questions/723675/debian-ubunt... > echo exit 101 > /usr/sbin/policy-rc.d chmod +x /usr/sbin/policy-rc.d I think this is the recommended way to avoid autostarting services on Debian.

Good pointer. I remember learning it, and then forgetting it. Probably more than once.

Still should be the default behavior.

Re: Debian 13 “Trixie”

#323

Post by sgarland »

pss314 wrote: post #137

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

DEB822 was available from at least Buster [0]. I think Bullseye was the first release I used it in.

[0]: https://manpages.debian.org/buster/apt/sources.list.5.en.htm...

Re: Debian 13 “Trixie”

#324

Post by sgarland »

__david__ wrote: post #195
pss314 wrote: post #137

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

> apt modernize-sources Oh nifty, I hand converted all mine a couple years back. It would have been nice to have that then (or know about it?). I do really like the new deb822 format, having the gpg key inline is nice. I do hope that once this is out there the folks with custom public apt repos will start giving out .sources files directly. Should be more straightforward than all the apt-key junk one used to have to…

Same. It took me a little bit to get used to it; my initial snap judgment was “this will be more annoying to create via scripting,” but then Ansible added deb822_repository [0] in 2.15 (shortly before Bookworm was released), and then it was no longer a concern.

[0]: https://docs.ansible.com/ansible/latest/collections/ansible/...

Re: Debian 13 “Trixie”

#325

Post by tremon »

avhon1 wrote: post #147
tremon wrote: post #125

Earlier quoted context omitted.

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)

I have AMD Geode hardware circa 2007 (18 years old) that only has partial support for i686. Requires a true 3/4/586 kernel.

Not sure why you are downvoted, I guess people don't believe this is true. To confirm: The AMD Geode LX was a https://en.wikipedia.org/wiki/Amd_geode#AMD_Geode

It was used in the OLPC XO-1. The Cisco ASA line of firewalls also used Geode processors at least at some point in its lifetime.

Re: Debian 13 “Trixie”

#326

Post by the_why_of_y »

npteljes wrote: post #286
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…

>They just have more success on getting their NIH babies accepted as the standard by everyone else. This depends on the phrasing. We could also say that Red Hat produces actually useful software, in contrast with Canonical, whose developments don't seem to provide value over existing solutions. We could also say that Canonical tries really hard to do exactly what Red Hat does, but in a slightly different space, and n…

A major difference is that Canonical projects have copyright assignment policies, while Red Hat projects don't - this probably explains a lot of the difference in adoption dynamics.

Re: Debian 13 “Trixie”

#327

Post by bayindirh »

rbanffy wrote: post #321
JackeJR wrote: post #212

Earlier quoted context omitted.

Just have sane firewall rules and you are good. E.g. if I install openssh-server and it auto starts, it doesn't make it out of my machine because my nftables does not allow inbound on port 22. It's just knowing the default behaviour and adjusting your practices for it.

A sane firewall won't protect you from privilege escalation from a local attacker. While unlikely, this is one more breach that could be exploited.

Debian bundles AppArmor profiles for most services. This will prevent an attacker from accessing outside the perimeter drawn by the AppArmor profile.

Re: Debian 13 “Trixie”

#328

Post by Paianni »

UncleSlacky wrote: post #318
Paianni wrote: post #5

The Devuan version may end up being the last that GNOME will run on...

You say that like it's a bad thing.

I don't like GNOME's engineering or license, but as far as the UI and design are concerned I don't think anyone has topped it (minus the hot corner I guess).

Re: Debian 13 “Trixie”

#329

Post by sgarland »

b112 wrote: post #12
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…

Also watch out for surprise file deletes in /tmp and /var/tmp at 10 and 30 days. This too can be turned off.

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

Re: Debian 13 “Trixie”

#330

Post by zahlman »

jjgreen wrote: post #307

I've been on Debian forever and love it to bits. But in an act which can only be described as batshit insanity, they have chosen to patch Python's pip3 in a manner which breaks the --prefix option. On Debian pip3 install --prefix=/usr/local will install into /usr/local/local, so one has to use the prefix /usr. The same command on, say, OpenSuSE will install into /usr and break your system. Barking mad. https://source…

> python3.7

Certainly a terrible UX, but the motivation is clear: they're trying to get PEP 668 protections for older versions.

Virtual environments work a lot better anyway, honestly. (With a properly crafted `pyvenv.cfg`, it should be possible to convince Python that your /usr/local is a virtual environment, but I can't be sure offhand if there are any serious negative consequences of that.)

Post reply on HN