Recently posted comments

Previous 20 comments.

sudo user

Posted Oct 14, 2025 16:17 UTC (Tue) by PhilippWendler (subscriber, #126612)
In reply to: sudo user by taladar
Parent article: Lucky 13: a look at Debian trixie

You just get a shell without password prompt.

Welcome to the future

Posted Oct 14, 2025 15:56 UTC (Tue) by Wol (subscriber, #4433)
In reply to: Welcome to the future by pizza
Parent article: Firefox 144.0 released

Google's BigQuery SQL editor now tries to complete your queries with AI ... :-(

I was surprised. The one time it got it right, it correctly predicted about 4 lines of tricky-to-get-right text.

Unfortunately, nine times out of ten I was typing short stuff which I'd finished, and the predictions simply got me thoroughly confused as to what was going on. I'd much rather the hassle of typing a query where I know what it (should be) doing, rather than trying to get rid of loads of auto-corrupt text and fighting the editor as it tries to add more.

Cheers,
Wol

AI Garbage

Posted Oct 14, 2025 15:11 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: AI Garbage by das_j
Parent article: Firefox 144.0 released

Ladybird[1] is probably our only hope on the horizon at the moment.

[1] https://ladybird.org/

Welcome to the future

Posted Oct 14, 2025 15:05 UTC (Tue) by pizza (subscriber, #46)
In reply to: AI Garbage by das_j
Parent article: Firefox 144.0 released

If Mozilla doesn't add "AI" then it will be held up as yet another example of how they're failing users by not keeping up with <shiny feature that all other browers support>.

Heads or tails, they still lose.

AI Garbage

Posted Oct 14, 2025 14:56 UTC (Tue) by das_j (subscriber, #143082)
Parent article: Firefox 144.0 released

Is there any browser left that doesn't try to push AI into workflows where they are only annoying while not built on the Chromium engine?

Single partition setups

Posted Oct 14, 2025 12:38 UTC (Tue) by Jonno (subscriber, #49613)
In reply to: Single partition setups by MaZe
Parent article: Debian Technical Committee overrides systemd change

On my Debian oldstable system /run/lock is a tmpfs separate from /run, and limited to 5 MiB (i.e. mounted with -O "nosuid,nodev,noexec,size=5120k"), which to my mind solves the DoS concerns (as at least only programs using /run/lock are affected, not any other program using /run). I didn't do anything special to get this, so I'm not sure where it comes from, but somehow reverting to this behaviour sound reasonable to me.

And if there is any problematic tmpfs mount in your typical Linux system it would be /dev/shm, as it has the same fs permissions, but mounted without noexec or any significant size restriction...

Why not a separate tmpfs?

Posted Oct 14, 2025 12:27 UTC (Tue) by gray_-_wolf (subscriber, #131074)
Parent article: Debian Technical Committee overrides systemd change

If the worries are non-priviledged programs filling up /run, why just not make /run/lock a separate tmpfs, with reasonable size limits? Should that not protect against the inodes and space exhaustion while being significantly less nuclear option?

sudo user

Posted Oct 14, 2025 12:19 UTC (Tue) by dskoll (subscriber, #1630)
In reply to: sudo user by taladar
Parent article: Lucky 13: a look at Debian trixie

If you can't log in as root, then you have to fix a broken boot by booting from external rescue media, I guess. Which can be annoying if your machine is remote, but you have a KVM-over-IP box. So I too always set a root password on my machines.

Quota?

Posted Oct 14, 2025 12:16 UTC (Tue) by eru (subscriber, #2753)
Parent article: Debian Technical Committee overrides systemd change

shudder to think of allowing unprivileged programs to fill up a directory

Wouldn't setting a quota for /run/lock be a solution to this concern? Same for other shared directories for temporaries.

Why spend the effort?

Posted Oct 14, 2025 11:53 UTC (Tue) by intelfx (subscriber, #130118)
In reply to: Why spend the effort? by taladar
Parent article: Cuni: Tracing JITs in the real world @ CPython Core Dev Sprint

> Is releasing a buggy initial version really an advantage or are you just making a bad first impression on your customers faster?

You seem to be making a tacit assumption that the initial version is necessarily "buggy" or otherwise "making a bad first impression on your customers". This is not a given. (Or, less charitably, this is a bad-faith argument.)

sudo user

Posted Oct 14, 2025 11:34 UTC (Tue) by taladar (subscriber, #68407)
In reply to: sudo user by josh
Parent article: Lucky 13: a look at Debian trixie

The main use for a root password is for failed boots, isn't it? How does the sudo setup with a password less root user handle this case? I have never really had a system with a root user without a password.

I think this was the right thing

Posted Oct 14, 2025 11:25 UTC (Tue) by taladar (subscriber, #68407)
In reply to: I think this was the right thing by Kamilion
Parent article: Bcachefs removed from the mainline kernel

Most filesystems "can't" drop a disk out of an array before a problem occurs because RAID is completely out of scope for them, that is what mdraid or hardware RAIDs or LVM are used to solve with those.

Single partition setups

Posted Oct 14, 2025 11:14 UTC (Tue) by aragilar (subscriber, #122569)
In reply to: Single partition setups by MaZe
Parent article: Debian Technical Committee overrides systemd change

Same on my Debian systems (with / and /home being different partitions on lvm, which I think is the default, or at least one of the suggested options?).

I think this was the right thing

Posted Oct 14, 2025 11:13 UTC (Tue) by taladar (subscriber, #68407)
In reply to: I think this was the right thing by Nikratio
Parent article: Bcachefs removed from the mainline kernel

Having read many of the discussions on this bcachefs issue here on LWN I have only ever seen Kent be professional while many others seemed to personally attack him.

Should C++ be deprecated?

Posted Oct 14, 2025 10:52 UTC (Tue) by taladar (subscriber, #68407)
In reply to: Should C++ be deprecated? by ras
Parent article: Comparing Rust to Carbon

I would argue that supply side attacks are much easier to run on huge projects that have dozens of developers that don't even all know each other and that half consist of code nobody looked at for the last 5 years.

Why spend the effort?

Posted Oct 14, 2025 10:45 UTC (Tue) by taladar (subscriber, #68407)
In reply to: Why spend the effort? by barryascott
Parent article: Cuni: Tracing JITs in the real world @ CPython Core Dev Sprint

This often comes up in defenses of "dynamic" languages but somehow nobody ever makes the distinction between "time to market" in the buggy initial version vs "time to market" in a version that is actually usable, i.e. the point you get in stricter languages by the time you release from the start. Is releasing a buggy initial version really an advantage or are you just making a bad first impression on your customers faster?

Single partition setups

Posted Oct 14, 2025 9:27 UTC (Tue) by rgb (subscriber, #57129)
In reply to: Single partition setups by MaZe
Parent article: Debian Technical Committee overrides systemd change

On my NixOS setup only /run/keys is ramfs, but good point anyhow.

Single partition setups

Posted Oct 14, 2025 7:59 UTC (Tue) by MaZe (subscriber, #53908)
In reply to: Single partition setups by rgb
Parent article: Debian Technical Committee overrides systemd change

I believe nowadays stuff like this has a tendency to be a dedicated tmpfs mountpoint.
At least on my Fedora, /var/lock is -> /run/lock, and /run is tmpfs.

Single partition setups

Posted Oct 14, 2025 7:36 UTC (Tue) by rgb (subscriber, #57129)
Parent article: Debian Technical Committee overrides systemd change

Aren't now most systems installed with a single unified partition by default anyway, in which case making /var/lock read-only for general users isn't really helping anything at all? Having a reserved disk quota for root should be much more effective. Looks like a storm in a theoretical teacup. But I guess you have to start somewhere.

New Package

Posted Oct 14, 2025 6:59 UTC (Tue) by stephanlachnit (subscriber, #151361)
Parent article: Debian Technical Committee overrides systemd change

I am a bit surprised why introducing a new package which contains the new tmpfiles config file? Then uucp et al can just depend on it and it can be gradually tackled without impacting the systemd package.

Next 20 comments.