Post AxmGcy0nBlFyXULHo8 by phf@mastodon.acm.org
(DIR) More posts by phf@mastodon.acm.org
(DIR) Post #AxmGcvPUrSEeTEsTOi by LaF0rge@chaos.social
2025-09-01T05:16:03Z
0 likes, 0 repeats
So there's a decades-old mechanism (and actual standard) how programs lock serial ports on unix-like systems in /var/lock. it's used in practice even in 2025 and #systemd >= 258 simply breaks it with "we don't care". I am not a systemd opponent, but that kind of behaviour [without a prior community-wide discussion or providing patches for known-affected projects and a grace period] is just alienating users and developers https://github.com/systemd/systemd/issues/38563 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110980 #systemd #debian
(DIR) Post #AxmGcwlrnliuguLqu8 by phf@mastodon.acm.org
2025-09-01T05:48:18Z
0 likes, 0 repeats
@LaF0rge Well, Microsoft never met a standard they didn't intend to ruin. So ... this makes a great amount of sense?
(DIR) Post #AxmGcy0nBlFyXULHo8 by phf@mastodon.acm.org
2025-09-01T06:10:11Z
1 likes, 0 repeats
@LaF0rge That said, I know that at least on Linux serial devices can be locked directly via the API and without creating lock files anywhere. I guess it comes down to what systemd actually wants with serial devices. At first blush, it seems that there's no reason whatsoever to touch them. But that never kept the systemd people from touching stuff they have no purpose touching in the past so... 🤷
(DIR) Post #AxmH3RSsJ1m1Pn6NuK by hanshuebner@mastodon.social
2025-09-01T06:10:54Z
0 likes, 0 repeats
@LaF0rge While I'm in the systemd haters camp, I also tend to acknowledge that the older the legacy gets, the smaller the fun becomes when implementing things in the operating system space. It is hardly fair to tell those who love contributing today that they have to support all the crap that we've learned and lost on the way here.
(DIR) Post #AxmH3SrN7Qxlk3ZSjI by LaF0rge@chaos.social
2025-09-01T07:23:24Z
0 likes, 0 repeats
@hanshuebner if it was a kernel ABI, it would also not be broken. I regret that the same "dont break existing applications" rule does not apply for core parts of userspace infrastructure. Yes, it is annoying to keep compatibility. But IMHO it is a matter of professional pride and courtesy to consider even minority users. In #osmocom we have a rule that old apps always need to work with new libraries. Period. Sure, we only have 17 years of legacy so far, and it's a small community. But still.
(DIR) Post #AxoxjEbT6DPA4zeUYy by pid_eins@mastodon.social
2025-09-01T20:28:33Z
0 likes, 0 repeats
@LaF0rge we are not breaking it, we are just not creating that dir anymore from upstream. Downstreams absolutely can add it again through their own tmpfiles.d/ drop-in, if they want.It's an awful interface (accumulates files, unclear when it comes to symlinked device aliases, requires a writable shared dir below /run/ where relatively unpriv processes can put literally anything, and fill up /run, DoSing the system, it's not compatible with delegating serial port access to namespaced services,
(DIR) Post #AxoxjFEojuse323utc by pid_eins@mastodon.social
2025-09-01T20:32:46Z
0 likes, 0 repeats
@LaF0rge ... or containers, the lifecycle of the lockfiles is just hosed, it's a secondary database and source of truth for the primary one that is maintained by udev, it's has different behaviour or different distros (groups ownership and access mode is quite different for fedora and debian) and so on and so on and so on.Also, note that the original bug was about systemd implementing things fedora style... Given this is distro specific anyway (*and* a bad bad interface) we just decided to...
(DIR) Post #AxoxjFroOw4XzyJ3g0 by pid_eins@mastodon.social
2025-09-01T20:36:33Z
0 likes, 0 repeats
@LaF0rge ... rip it out of systemd and let downstreams manage it, via tmpfiles.d lines *they* maintain in compliance witht *their* policies.Any way I look at this this is a good thing, because it gives Debian an easy way to add this back in without conflicting with systemd's conflicting management of it. I mean, I'd suggest yo them that maybe they rather invest the work in fixing those apps in question to use bsd locks on the devnode, but hey, it's their time, and...
(DIR) Post #AxoxjGSgBrYxqJYV8q by pid_eins@mastodon.social
2025-09-01T20:39:55Z
0 likes, 0 repeats
@LaF0rge ...to some point I can even understand that for Debian traditions and compat with multi decade old stuff trumps the simplicity, security and robustness goals systemd typically has.
(DIR) Post #AxoxjH14814JYxdxjs by Logical_Error@fosstodon.org
2025-09-02T04:23:10Z
0 likes, 0 repeats
@pid_eins @LaF0rge i think a slow migration and communication wouldve been best here. or even a config to opt out and leave the default… well the defaultim not familiar with this, so i cant say what the technical merit is, but from a social view, it seems like a feature that some distros need was ripped out without being communicated in advancei think defaults can and should change, but i think it should be systemd’s responsibility to communicate that
(DIR) Post #AxoxjHbvuwYjPItPCi by pid_eins@mastodon.social
2025-09-02T05:51:44Z
0 likes, 0 repeats
@Logical_Error @LaF0rge Hmm, what? that PR in question *has* *not* *even* *been* *merged* yet. Just greenlit for the v259 release, but at this time we haven't even tagged v258!And we usually *do* tell distros pretty clearly what they need to focus on when taking in the next release of systemd. It's what the "Incompatible Changes" section in the NEWS file for each release is for. And downstreams do watch that.
(DIR) Post #AxoxjI9btjUv5keIhE by pid_eins@mastodon.social
2025-09-02T05:52:56Z
0 likes, 0 repeats
@Logical_Error @LaF0rge the PR qeued for merging in v259 is this one btw:https://github.com/systemd/systemd/pull/38644Frankly, this is a tempest in a teapot.
(DIR) Post #AxoxjIpROCxTBUDhtg by pid_eins@mastodon.social
2025-09-02T05:58:42Z
0 likes, 0 repeats
@Logical_Error @LaF0rge Let me stress this again. The stuff @LaF0rge is complaining about has *not* taken place at all in v258, unlike what he claims – we made zero changes in v258 regarding /run/lock/ management since basically 2016!
(DIR) Post #AxoxjJVyq2zBJQ7gCe by pid_eins@mastodon.social
2025-09-02T06:06:38Z
1 likes, 0 repeats
@Logical_Error @LaF0rge And to add more to this noise about nothing:It's not just that Debian and Fedora disagree about ownership/access mode of the dir. It's also, they disagree where to place those frickin' LCK..* files in the first place!Because on Fedora the dir for that is actually /{var|run)/lock/lockdev/.Hence, fuck this "decades-old standard". It's not even "a standard" at all.