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

What to expect from Debian/Trixie

michael-prokop.at

Post reply on HN
Print view View original

181–190 of 211 posts

Re: What to expect from Debian/Trixie

#181

Post by tremon »

b112 wrote: post #85
yehoshuapw wrote: post #72

Earlier quoted context omitted.

I ended up in gentoo mostly just to avoid systemd (used it before, mostly to learn. went to debian for new laptop. gave up after fighting systemd. I'm aware of devuan and artix, but gentoo just worked (after all the time spent))

Debian, at least until bookworm works perfectly without systemd. The easiest way to make this transition, is to installed Debian with nothing but 'standard system utilities' and 'SSH server' (if you want) during install: https://forum.qubes-os.org/uploads/db3820/original/2X/c/c774... Once install is done, login and save this file: /etc/apt/preferences.d/systemd # this is the only systemd package that is required, so…

Note that this will still allow systemd-udevd because it's packaged under its original name, udev.

Re: What to expect from Debian/Trixie

#182

Post by tremon »

hsbauauvhabzb wrote: post #101
tharos47 wrote: post #27

Earlier quoted context omitted.

It was done in Ubuntu a few versions ago. Afaik only the listening port config is ignored and instead is setup in systemd

Which is exactly the problem. It’s not obvious, is misleading and it’s cause is not easily determined just by looking at the config. What else is lurking that you and I aren’t aware of?

The problem is that SSH is usually the admin interface to the system. You don't want unnecessary moving parts between you and your remote shell access when you need to troubleshoot a half-running system.

Re: What to expect from Debian/Trixie

#183

Post by tremon »

tsimionescu wrote: post #68
o11c wrote: post #58

Earlier quoted context omitted.

That actually is a pretty big difference. Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly. If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed…

The sane thing is to have swap enabled. Having swap "disabled" forces your system to swap out executables to disk, since these are likely the only memory-mapped files you have. So, if your memory fills up, you get catastrophic thrashing of the instruction cache. If you're lucky, you really go over available memory, and the OOMKiller kills some random process. But if you're not, your system will keep chugging along at…

Having swap "disabled" forces your system to swap out executables to disk

Read-only pages are never written to swap, because they can be retrieved as-is from the filesystem already. Binaries and libraries are accounted as buffer cache, not used memory, and under memory pressure those pages are simply dropped, not swapped out. Whether you have swap enabled or disabled doesn't change that.

Still, I hope that Debian does the sane thing and sets proper size limits. I recall having to troubleshoot memory issues on a system (Ubuntu IIRC) a decade ago where they also extensively used tmpfs: /dev, /dev/shm, /run, /tmp, /var/lock -- except that all those were mounted with the default size, which is 50% of total RAM. And the size limit is per mountpoint...

Re: What to expect from Debian/Trixie

#184

Post by tremon »

NekkoDroid wrote: post #100
o11c wrote: post #58

Earlier quoted context omitted.

That actually is a pretty big difference. Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly. If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed…

> If /tmp/ fills up your RAM tmpfs by default only uses up to half your available RAM unless specified otherwise. So this isn't really a consideration unless you configure it to be a consideration you need to take into account. (Systemd also really recently (v258) added quotas to tmpfs and IIRC its set by default to 80% of the tmpfs, so it is even less of a problem)

  $ grep tmpfs /proc/mounts
  udev /dev devtmpfs [..]
  tmpfs /run tmpfs [..]
  tmpfs /run/lock tmpfs [..]
  tmpfs /run/shm tmpfs [..]
  tmpfs /tmp tmpfs [..]
  cgroup_root /sys/fs/cgroup tmpfs  [..]
If each of those can take up 50% of ram, this is still a big problem. I don't know what defaults Debian uses nowadays, because I have TMPFS_SIZE=1% in /etc/default/tmpfs so my system is explicitly non-default.

Re: What to expect from Debian/Trixie

#185

Post by hiq »

archargelod wrote: post #161
josephscott wrote: post #5

"The temporary-files directory /tmp is now stored in a tmpfs" - https://www.debian.org/releases/trixie/release-notes/issues.... I am not a fan of that as a default. I'd rather default to cheaper disk space than more limited and expensive memory.

I'm using OpenSUSE Tumbleweed that has this option enabled by default. Until about a year ago, whenever I would try to download moderately large files (>4GB) my whole system would grind to a halt and stop responding. It took me MONTHS to figure out what's the problem. Turns out that a lot of applications use /tmp for storing files while they're downloading. And a lot of these applications don't cleanup on fail, some…

How did you figure that this was the problem?

If it's easily reproducible, I guess checking `top` while downloading a large file might have given a clue, since you could have seen that you're running out of memory?

Re: What to expect from Debian/Trixie

#186

Post by hiq »

dsr_ wrote: post #168

A few months prior to every Stable release, people start raving about how awesome running Testing is, how it has up-to-date packages and fixes their kernel issues and solves world hunger and capitalism. This is because Testing has done a soft freeze, then a hard freeze, then is prepped to become the new Stable. During that process, nothing new can be added to Testing. Then, one day, Stable is released and the floodga…

Good advice!

I'm on stable like 3/4 of the time, until there's some newer package version I want and that happens to be in testing, at which point I switch (using the codename as you suggest instead of Testing). If I don't have a specific need, I tend to switch during the soft or hard freeze, out of curiosity, because I never had problems doing that.

Re: What to expect from Debian/Trixie

#187

Post by tremon »

sugarpimpdorsey wrote: post #35
paulv wrote: post #10

Earlier quoted context omitted.

> Ask me how I know. What problems did you have that made you want to roll back the update?

I had some containerized application software break and start misbehaving in odd ways which was indicative of a deeper incompatibility issue. Possibly GPU related. No time to debug, had to roll it back. This was complicated by the fact that the machine also hosted a MySQL database which could not be easily rolled back because the database was versioned up during the upgrade.

Wait, the containerized application broke because of a host upgrade? That's some leaky container you have there.

This sounds like a business setting, so this sounds like a good opportunity to advocate for testing hardware, a testing budget, a rollout plan, and a sound backup strategy.

Re: What to expect from Debian/Trixie

#188

Post by tremon »

ducktective wrote: post #15

Can anyone experienced with debian package development, point me to some valid, recent and Best Practice™ guides or blog posts explaining how to package stuff for Debian?

Not linked yet is the Debian Packaging Portal: https://wiki.debian.org/Packaging

There's two tutorials/walkthroughs linked from there:

- how to build an existing Debian package: https://wiki.debian.org/BuildingTutorial

- how to package new software for Debian: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html

Re: What to expect from Debian/Trixie

#189

Post by b112 »

mjg59 wrote: post #153
b112 wrote: post #78

Earlier quoted context omitted.

This worked brilliantly in Debian for more than a decade, had almost zero downside, and just did what asked. I went through 3+ dist-upgrades, for the first time in my life, without a NIC change. It was deprecated for this nonsense in systemd. Yes, there were edge cases in the Debian scheme. Yet it did work with VMs (as most VMs kept the same MAC in config files), and it was easy to maintain if you wanted 'fresh'. Jus…

systemd's design choices here were influenced by a lot of bugs Red Hat received where failed hardware was swapped out and interface names changed as a result. Real world enterprise users wanted this, it wasn't an arbitrary design choice.

That's quite the jump.

Some real world users asked for a fix. They did not mean they asked specifically for this fix.

There were other ways to handle this.

With Debian's system, you could wipe the state files, and for example eth0/etc would be reassigned per initialization order. Worked fine.

Even if you didn't like that, pre-Systemd udev allowed assigned by a variety of properties, including bus identifiers.

It was merely that Redhat, as usual, was so lacking in sophistication, unlike Debian.

Post reply on HN