Even completely headless, command line #linux doesn't prioritize #accessibility in any way. Today I had to reinstall an entire #debian system from scratch because a drive listed in my /etc/fstab died. That makes #systemd boot into emergency mode, where you get no SSH, no network, no sound, and no screen reader. There is no quick way to force it to try and boot even though drive 7 of 11 has died, and it could absolutely bring up SSH and the network to let me fix it if it wanted to, just like sysvinit used to do. You can't even force systemd to add SSH and the network to emergency mode because of circular dependencies. nofail will only continue the boot if the drive doesn't exist, but if the filesystem has issues...emergency mode for you. In short: if your drive dies on Linux, fuck you. Be able to see, or reinstall your entire system, because nobody in Linuxland gives a shit about #a11y or your needs.
in reply to Tom

@tripplehelix No, because to boot from that live USB stick, you need to get into the BIOS. If you're blind, you can neither access the boot menu or change boot priority. Reinstalling involves unplugging your system drive, plugging in a USB drive with the installer, getting it to boot off that when it can't find anything else bootable, then plugging in the boot drive again. And the installer offers a screen reader, but it doesn't offer any sound drivers, so the screen reader is not useful. No live Linux images have working sound and a screen reader. I have a installer with a preseed file that I created so it won't ask me any questions, assuming I can time it exactly correct to get it to boot off the USB stick and then plug in the actual drive I want the OS installed on before it starts writing data.
@Tom
in reply to 🇨🇦Samuel Proulx🇨🇦

Sorry, I didn't know you were blind. I'm surprised you got as far as you did. Installers are definitely getting better, but I can definitely see system failures as being a huge issue.

Which distro installers have you tried out of interest? Which ones are best suited to your needs? Hardware plays a huge role in whether the installer would be compatible with sound.

in reply to Tom

@tripplehelix All of them suck, honestly. Debian sucks the least because of preseed, but that only works because I've been running Linux servers for 20 years, have another computer to create the preseed file on and make the custom ISO, and know *exactly* what I need the installer to do. No normal blind human could recover from any type of failure on a Linux system at all, assuming they could even get it installed. There are ways of getting arch and Ubuntu to come up on the live image with sound and speech, but they involve precise timing, memorizing keypresses, and typing commands into the console by wrote.
@Tom
in reply to 🇨🇦Samuel Proulx🇨🇦

@Samuel Proulx I won't boost this, due to the needless vulgarity, but I am quite shocked to hear this. I would think that, since they've been around for decades, Debian, of all distributions, would have such accessibility as a default! I played with it a bit, but I am really a Windows user who is just curious about Linux. And yes, I do need a screen reader as well. Fortunately, mine is within VmWare, so if something goes wrong, it's not serious, just annoying. But if that were my primary machine, that would be horrible!
in reply to Georgiana Brummell

@dandylover1 I also feel strongly that vulgarity is the punctuation to the argument, not the argument itself. It should always be at the end, not the beginning, once you've finished saying your bit, not when you're just starting. Establish your opinion, then hit 'em in the face with the cursing while they're leaning in and listening.
in reply to 🇨🇦Samuel Proulx🇨🇦

You keep saying "cannot" when you mean "does not". It's not that the capability does not exist. It's that it is not set up and configured for this case. That can be changed.

Here are people you can complain to about this:

Systemd: mastodon.social/@pid_eins

Systemd issues:
github.com/systemd/systemd/iss…

Debian systemd: pkg-systemd-maintainers@lists.alioth.debian.org

Debian accessibility: pkg-a11y-devel@alioth-lists.debian.net

in reply to -𝚍𝚜𝚛- (has pronouns)

@dashdsrdash@dandylover1 If I understand systemd correctly, this would require massive changes to multiple units. Because systemd makes the entire file system a single dependency, with no way to depend on only the root partition. Just for ssh, you’d need to change it from wants to requires networking, and then screw around a bunch with the networking unit. I think saying can’t is fair here. Systemd just wasn’t designed to boot at all costs; it’s a fragile dependency graph that breaks if you sneeze at it.
in reply to 🇨🇦Samuel Proulx🇨🇦

I agree with your last sentence, but the project tries to take over everything, so I think it is fair for them also to take responsibility to implement a rescue mode with a screen reader.

Certainly other projects, like the Debian installer, have accomplished it.

Have you considered installing a rescue image as a boot choice? GRML has grml.org/grml-debootstrap/ which includes an ssh-in path.

in reply to -𝚍𝚜𝚛- (has pronouns)

@dashdsrdash@dandylover1 The issue there is that I now have to do strange and undocumented things in grub in order to know when the boot menu comes up, or make it wait for an extremely long time and slow down the boot. Also, sometimes Debian updates add boot choices, risking changing the order of choices, and meaning that pressing down arrow twice and then enter might not boot into the choice I expect.
in reply to -𝚍𝚜𝚛- (has pronouns)

@dashdsrdash@dandylover1 I'd still wind up reinstalling, though, thanks to drive encryption not allowing me to unlock the discs from recovery media. Or at least, if this can be done, I'm unaware of how. If I want to actually fix the problem (in this case, edit /etc/fstab), I need to boot in from the actual system or its emergency mode.
in reply to 🇨🇦Samuel Proulx🇨🇦

It depends on the encryption method you chose, but in general, if you have the encryption keys on the recovery media, you can use them.

Debian's most likely encryption method is LUKS. The way to copy the encryption header is

cryptsetup luksHeaderBackup DEVICE --header-backup-file FILE

and there's an explanatory article here:

lisenet.com/2013/luks-add-keys…

which includes steps for backup and recovery.

I hope that helps in future.

in reply to Freya (it/its)𒀭𒈹𒍠𒊩

@freya Nope. USB images don’t support sound or screen readers. So reinstall involves creating a preseed on another machine, making a custom image, and reinstalling. If I can’t have SSH and network, or sound and a screen reader, reinstall is my only option. And the systemd emergency target denies me both of those things, as do live images.
in reply to 🇨🇦Samuel Proulx🇨🇦

we dunno what machine you're running on, but the integrated speech in the installer for Debian and arch works all the time every time. And again, not sure what hardware you're on, but we've got 3 machines right here with serial consoles and, when they were running Linux, they all worked. They're all running Solaris now but still
in reply to 🇨🇦Samuel Proulx🇨🇦

I haven't seen something that doesn't work with standard HDA sound drivers in... decades? If you're stuck with some hardware that bad, external USB sound device (they're cheap and I've used them for multichannel signal generation stuff separate from system sound) might be a good idea to have on hand. AFAIK they're driverless (standard USB device class driver works for any of them).
in reply to 🇨🇦Samuel Proulx🇨🇦

@serrebi Actually, systemd's emergency mode is broken on some distros even more than that, you end with a locked root account on many distros, so even sighted have to do these repairs from a live medium. But, yes, convincing mainstream adoption of at leas BRLTTY in the initramfs will be a challenge, adding a TTY screen reader will be another challenge (which one you want, for example). Yes, I know, that speakup exists, but some distros (thank you, Fedora), are not building the support, because this infrastructure has basically no maintainer, and they do not want to risk this.
in reply to 🇨🇦Samuel Proulx🇨🇦

From a totally technical standpoint, I think it's pretty difficult to achieve some sort of a nice recovery mode. From what I know Windows would boot into a recovery partition (which does not always exist, so it doesn't always work). I don't think such implementation exists yet in the Linux world unfortunately (in some way systemd would need to fallback to a separate fstab or a separate target that instructs the system to mount and switch-root into a separate recovery rootfs).

Or you could try to include networking and other tools into the initramfs, but obviously that would greatly slow down system boot up times.

I am not so sure how practical the separate fstab thing is, I don't even know if that's supported by systemd currently, but I think that's the only way to have recovery mode implemented properly for both command line and graphical situations.

An alternative approach is to have the bootloader count the number of times the system has not booted up properly somehow, and automatically select a different target or kernel. But again obviously I don't think such implementations exist yet.

in reply to madomado

IIRC the Windows recovery partition is the ESP, so as long as the bootloader partition exists Windows may load.

Also fstab has an option to silently fail mounts, but you need to set a custom mount option (nofail).

systemd has a mount unit feature where you could just write a bunch of separate "services" that mount partitions on the disk, and even most distros depend on it because guess what, systemd actually generates these service files from... the fstab itself!

I think the main issue is probably just distros not having a fallback for failed mounts by default and expecting you to have an always-healthy disk. That and recovery mode being completely lackluster because it's a minimal RAM disk image.

Someone could probably implement a decent recovery mode, but people would be arguing on whether it's even necessary because "bloat".

systemd had and still has that issue with people thinking it's unnecessary and bloated.

in reply to Cappy Ishihara

@cappy@madomado I'm aware of nofail. It skips discs that can't be seen by the system because they no longer exist or because of hardware failure. However, based on the experience I had yesterday, nofail will not skip the disc if it encounters a corrupted filesystem while mounting. And I would completely agree that systemd is unnecessary and bloated; what happened to the Unix philosophy of do one thing and do it well, while having well-documented interfaces and thus being completely replaceable? Systemd does everything, and does it all badly, while also being effectively impossible to replace portions of it, or make changes to parts of their one true design that you disagree with...like, for example, forcing it to boot even on dependency errors. My spicy hot take is that it would be impossible to create a fully accessible boot process while we have systemd, because it's neither modular 'nor easily customized, and the one true systemd way of doing things doesn't take accessibility into account.
in reply to 🇨🇦Samuel Proulx🇨🇦

@madomado@fedi.fyralabs.com Well... Linux was always a monolithic operating system. systemd is not even actually monolithic as most people think. Funnily enough people only think systemd is a big bloated pile of mess because they look at the repo and see all the programs.

systemd-init is literally just a single program. Everything else is just a bunch of separate little pieces of almost-standalone software. Once you look into how systemd actually works, it's not actually even that big.

It's like coreutils, just a suite of tiny little programs working together and doing what it does well that speaks a common language.

That language just happens to be systemd sockets, because it's made by the systemd devs.

in reply to 🇨🇦Samuel Proulx🇨🇦

@madomado@fedi.fyralabs.com

Then why has nobody come up with a sane replacement for systemd-init?


OpenRC, s6-init. Or you can do it the old-fashioned way and write an rc script in Bourne Shell.

I'd be happier on freebsd if only it had decent hardware support, and any screen reader at all.


You do you, people don't usually implement a11y features because it's most of the time an afterthought. It's not even a Linux/UNIX problem it's just able-bodied people forgetting we exist.

Using jails seems exactly like how I use docker for everything today, but better.


You don't even need to use "just" Docker for jails. In fact there's like a million OS-level hypervisor implementations that work just like BSD jails. Sometimes even better because the kernel itself has a thing called namespacing.

Bubblewrap for rootless jails, Flatpak makes heavy use of that.

You want something similar to jails? Ubuntu makes LXC, That already existed. Even systemd has their own thing, it's called systemd-machine. Guess who uses and maintains systemd-machines? Meta. And basically almost every mainstream Linux-based hypervisor distro has some support for LXC (looking at you, Proxmox and libvirt)

Docker/Podman is just an implementation of a standard that people use because it's easy to set up, it's a set-and-forget thing because OCI images are meant to be pre-configured to run a specific service.

in reply to Cappy Ishihara

@cappy@madomado I would say that accessibility *is* a Linux problem. In theory, the Unix way of doing things *should* allow for accessibility support that can be easily customized to meat each person's needs. But Linux has moved so far away from that ideal, with seemingly no interest in returning to it, that accessible Linux is difficult to impossible.
in reply to Moved to https://mk.absturztau.be/@Linux

@madomado@fedi.fyralabs.com Linux was never really about options, tbh. It's about doing what works.

Hence why lots of distros use systemd. It's the better init at the time (at least better than sysv) and we all got stuck with it. It's why some of us stick with X11 (Looking at you, NVIDIA), because UNIX workstations have been using it for years at that point because XDMCP is a thing.

in reply to Cappy Ishihara

@cappy@Linux_Is_Best@madomado This is the key flaw in open source. People only have to work on what they, personally, care about. Well-regulated (not free market) capitalism allows society to force people to spend time on things that don't effect them, in exchange for money. We're never going to have enough qualified blind programmers with the talent, time, and resources to improve Linux accessibility. So the majority of us will be stuck on Windows and mac. I wish there was a way out of this, but I can't find one.
in reply to Mary

@mary The issue is that not only do you need espeak, you also need a metric buttload of sound drivers and so-on. I suspect we'd have better support with getting SSH and network in the rescue image, because we might at least be able to get the people collocating in data centers on-side. Also, network chipsets seem to be more standard than the various flavours of onboard sound, meaning fewer drivers are needed.
@Mary
in reply to 🇨🇦Samuel Proulx🇨🇦

After doing a little research it seems like rescue and emergency mode both happen after the pivot from initramfs, so I was totally wrong in my earlier message. It would seem like the drivers and userspace components for either option (espeakup or ssh) are all there, just not started. If that's the case, I suspect it wouldn't be super tough to make either work if only they could get the dependency ordering thing sorted out (or have a separate "emergency" version of the ssh and networking services or espeakup service if it's impossible to represent the graph any other way).
in reply to 🇨🇦Samuel Proulx🇨🇦

I tried setting up a screen reader once to test my website and concluded that Linux is just not very usable for people who actually need a screen reader to use their computer

it took a lot of effort and getting through a bunch of very confusing setup to get it working at all, and then getting a voice better than barely-understandable was a whole another challenge

I feel like getting this working well and making the setup easy would require having some single organization work on improving every piece of the system to make it all coherent and easy to set up

in reply to Doggie

@lunareclipse Actually, the voice really isn't a huge problem. Espeak is fine, and it's the default in a lot of places. The real problem is getting sound support that both works, and stays working. And giving the user a way to recover when something random fails during boot. And also, of course, Wayland disabled a ton of stuff that screen readers need in the name of security. The best way to use Linux as a blind person right now is via SSH on a Windows machine that's dedicated to the purpose.
in reply to 🇨🇦Samuel Proulx🇨🇦

While the entire way the emergency and rescue modes work really needs to be re-worked taking accessibility into account, until that happens (if ever...) you can disable it entirely by masking emergency.target and emergency.service, (systemctl mask emergency.target emergency.service,) which will make your system keep booting instead. (Though then it becomes extra important to make sure that services requiring those mounts have explicit dependencies on them, so they don't get accidentally started and start doing things on the wrong filesystems.)
in reply to 🇨🇦Samuel Proulx🇨🇦

this is indeed not a great state of affairs

As someone who has used serial ports frequently for remote diagnosis of systems in various bad states (which would be set up in emergency mode), I wonder if braille devices that can behave like a VT100 terminal are still made

I imagine "nice termcap guis" would still be a pain, but at least the emergency mode tools don't use many of those that I've seen?

It strikes me that the design of PC hardware shares almost as much blame for this

in reply to 🇨🇦Samuel Proulx🇨🇦

A bit late, but "x-systemd.automount" should work here by removing the disk from the global fs unit and creating a separate automount unit for it, which is allowed to fail without blocking things.

It basically postpones mounting until anything accesses the path.

It will however fail depended units needing files on that filesystem.

in reply to 🇨🇦Samuel Proulx🇨🇦

"because nobody in Linuxland gives a shit about #a11y or your needs." -- has Debian rejected your patch to fix the issue and told you to screw yourself? What a bunch of dumbass!!

Joking aside, It's frustrating for sure, but no one is trying to get one over you or maximize shareholders' return. No one owe you anything for the free work they are doing.

#a11y
in reply to 🇨🇦Samuel Proulx🇨🇦

You've got a few options here.
1. Serial console on the motherboard, needs support from your motherboard and a cable. You also need to take your computer apart to install it. That's probably your best option.
I don't know if Linux can use a USB to serial adapter that early in the boot process. There's netconsole, but I don't think it supports input.
This would give you bootloader and console, no BIOS though.
2. Buy a real server board. They usually have some kind of remote management in them.
They're expensive and there are very few options, but you should get an accessible BIOS out of it.
3. Write your own thing and hook it into the initrd. If I was going to do this, I would try to have it bring up the network and start some kind of shell.
Getting everything I would need for sound would be too complicated. It might also interfere with things later in the boot process.
4. Capture card, hook it up to AI, or OCR.
in reply to 🇨🇦Samuel Proulx🇨🇦

Red Hat is working on this - everyone knows it's a mess, so they just hired in a blind coder

news.itsfoss.com/red-hat-acces…

in reply to 🇨🇦Samuel Proulx🇨🇦

@Samuel Proulx @tuban_muzuru Hmmm, I am really really surprised the situation is as bad on your side. I do have a little different experience however I like your points related to inaccessible emergency shell access.
I am using single arch linux install from like 2012. Each time I get a new laptop I'll just boot off of live Arch Linux USB by looking up the boot menu keyboard shortcut in the manual of that laptop and OCR the screen once to find out which option is my USB device I have just connected. Every laptop I have used since 2012 had a sound working on the live media with included speakup.
When fully booted into the live USB I connect to the network prefferably via ethernet and use rsync to transfer my install into place regenerating initramfs at the end and adding linux kernel with its efi stub into the uefi partition to boot also setting uefi boot order by using efibootmgr.
I know I am not doing encryption since there is no accessible UI to enroll my own KSK into the bios or at least I don't know about it but I am otherwise used to do all of this on my own with no sighted help. And of course this is my primary system of choice. On those few additions that I broke something during an upgrade I have booted off the live medium again, chrooted into my broken system, fixed it and continued as normal. I must say I very much like this setup that I don't have to reinstall.