Debian project leader elections 2023 [LWN.net]

The 2023 election for the Debian project leader looks to be a relatively unexciting affair: incumbent leader Jonathan Carter is running unopposed for a fourth term. His platform lays out his hopes and plans for that term.

From:		Kurt Roeckx - Debian Project Secretary <secretary-AT-debian.org>
To:		debian-devel-announce-AT-lists.debian.org, debian-vote-AT-lists.debian.org
Subject:		Debian Project Leader Elections 2022: Candidates
Date:		Wed, 15 Mar 2023 00:46:36 +0100
Message-ID:		<ZBEHXFyIhgGqNlWf@roeckx.be>
Archive-link:		Article

We're now into the campaigning period. We have 1 candidate this
year:
- Jonathan Carter

The platform is available at:
https://www.debian.org/vote/2023/platforms/


Kurt Roeckx
Debian Project Secretary

to post comments

Debian project leader elections 2023

Posted Mar 15, 2023 18:16 UTC (Wed) by nickodell (subscriber, #125165) [Link] (3 responses)

>But I think we can, and should do more. I would like us to collectively identify the top problems in Debian that give users a hard time, find potential solutions for them, and if it seems plausible, make it a release goal. I'll list two examples from my own personal suffering below, and they're examples, so this DPL vote isn't a vote to override a maintainer in any way, but I'm listing them to give you an idea of what I'm talking about.
>
>On desktop systems, automatically run fsck when a filesystem encounters a problem. On a very regular basis, a contact sends me an email or Signal message containing a photo of their laptop/desktop/server with a busybox prompt with a message above saying something like "filesystem check failed for /dev/sda2". And then I get to be the hero who tells them "Type 'fsck -y /dev/sda2', then reboot!". I can understand that on some servers, some might want to be conservative and intervene manually, but on a desktop system the answer to the user is almost always going to be to run the filesystem check, so why not just do it automatically? The incident can still be reported to the user in other ways after the filesystem is fixed.

I'm glad to see this in jcc's platform. He may not be able to directly do these kinds of things, but being an internal advocate for it is still valuable.

fsck repair is bad advice

Posted Mar 16, 2023 16:04 UTC (Thu) by kilobyte (subscriber, #108024) [Link] (2 responses)

Sorry but running fsck automatically is never a good advice nowadays. In the bad times of ext2/vfat and earlier you had no choice: any unsafe shutdown that happened when the disk was not quiescent caused filesystem corruption -- possibly benign, possibly catastrophic. And, if moderately lucky, you would lose everything stored (but you do have backups, don't you?) -- or you had silent data loss, overwriting good backups with junk, with whatever unbounded consequences propagating false data can have.

A filesystem doesn't get corrupted without a cause. That can be either software or hardware. Software these days still has bugs but they're generally rare enough compared to hardware problems that the likely cause is that your gear is broken. And even if the cause was software, it's likely that you'll trigger the same bug soon again.

For hardware errors, likewise -- faults rarely go alone. If the problem was a legit disk error, you need to look into it. If, worse, the disk error was hidden (dodgy manufacturers like to conceal errors, and tend to lie about flushes in order to cheat on benchmarks) you might have a hard time finding the cause but you do need to know your system is fucked. Then, bad memory without ECC is no end of joy -- again, if it caused an error once it will do that again soon. Or perhaps simply the cable is ill seated. Or something else entirely...

But whatever is the cause, your system is flaky. You may elect to trudge on with marginal hardware but that's ok only as a short term solution.

It's not Windows -- there's no "random crash", there's a heisenbug somewhere that needs to be identified. We must stop forgiving random unexplained faults.

fsck repair is bad advice

Posted Mar 16, 2023 16:34 UTC (Thu) by farnz (subscriber, #17727) [Link]

The difficulty then is how to relay the issue to the user in a friendly fashion. The Debian thing of "dump you at a root prompt, expect a magic string on the console to fix it" isn't user-friendly; the way macOS does it nowadays (where it runs the fsck for you, but tells you on login that your system shut down uncleanly, and you may have data loss) is more friendly.

Ideal would be if you could identify the reason the FS needs an fsck, and tell the user what's going on, but that's hard on consumer hardware which doesn't have RAS features like ECC, or a good way to report things like changes in link training on the SATA cable over time.

fsck repair is bad advice

Posted Mar 16, 2023 19:32 UTC (Thu) by dskoll (subscriber, #1630) [Link]

A compromise could be to offer to run `fsck` for the user, along with the warning that there is a chance of data loss. So require interactive input to run it.