rrobin
I’ve tried a few times in the past 2 weeks. Using a good email account and also with github, no luck though. Maybe its doing some “smart” heuristics to trigger it.
I just retried now, using that temp mail (but no vpn) and got the exact same phone verification. Maybe my IP address is evil :D
I’m a bit of terminal nerd, so probably not the best person to talk about desktop. I don’t have many thoughts with regards to app development or layout for accessibility. What I really would like is for distros to be accessible from the ground up, even before the desktop is up.
The best example of accessibility from the ground up I saw for linux was talking arch, an Arch Linux spin with speech. Sadly the website is gone, but we can find it in the web archive
in particular there was an audio tutorial to help you install the live cd (you can still ear it in the archive):
Here are a few resources, which are pretty dated but I wish they were the norm in any install:
- your system can boot up talking, using speakup http://www.linux-speakup.org/speakup.html
- even if the desktop is not fully accessible or breaks, your console or the terminal in your desktop can speak using yasr https://yasr.sourceforge.net/
Now going into your points:
How should a blind Desktop be structured?
To be honest I don’t expect much here. As long as context/window switching signals you properly you are probably fine. I have not used gnome with orca in a long time, but this used to be ok. The problems begin with the apps, tabs and app internal structure.
Are there any big dealbreakers like Wayland, TTS engines, specific applications e.g.?
Lots.
Some times your screen reader breaks and its nice to have a magic key that restarts the screen reader, or the entire desktop. Or you just swap into a virtual console running speakup/yasr and do it yourself :D
TTS engines are probably ok. Some times people complain about the voices, but I think it is fine as long as it reliably works, does not hang, responds quickly.
Specific applications are tricky. The default settings on a lot of apps wont work well by default, but that is not surprising.
I do think that a lot of newer apps have two problems
- they are not configurable or scriptable at all, there is only one way to do things and no way to customize it. Opening tickets to patch each and every feature is not feasible.
- They frequently go through breaking release cycles that nuke old features, so you need to relearn all your tricks on the next major release and find new hacks
I can give you two good-ish examples, both Vim and Mutt can work very well with a terminal screen reader, but it is a lot of work to configure:
- with vim you need to disable all features that make the cursor jump around and draw stuff (like line numbers and the ruler)
- with mutt every single string in the screen can be customized, so you even insert SSML to control speech and read email
I think you can find similar examples in desktop apps too.
What do you think would be the best base Desktop to build such a setup on?
no idea to be honest. Gnome use to have support. I suppose other desktops that can be remote controlled could be changed to integrate speech (like i3 or sway).
Would you think an immutable, out of the box Distro like “Fedora Silversound”, with everything included, the best tools, presets, easy setup e.g. is a good idea?
I have never used Silversound. But the key thing for me is to be able to roll back forward to a working state.
How privacy-friendly can a usable blind Desktop be?
I think it should be fine. People with screens have things like those Laptop Screen Privacy Filter, people using audio have headphones. Depending on your machine you can setup the mixer so that audio never uses the external speaker.
I don’t recall the details but you can also have some applications send audio to the external speaker while others use your headphones (provided they are a separate sound card, like usb/bluetooth headphones).
Also, how would you like to call it? “A Talking Desktop”?
Urgh, Shouting Linux.
This is a really nice summary of the practical issues surrounding this.
There is one more that I would like to call out: how does this client scanning code end up running in your phone? i.e. who pushes it there and keeps it up to date (and by consequence the database).
I can think of a few options:
- The messaging app owner includes this as part of their code, and for every msg/image/etc checks before send (/receive?)
- The phone OS vendor puts it there, bakes it as part of the image store/retrieval API - in a sense it works more on your gallery than your messaging app
- The phone vendor puts it there, just like they already do for their branded apps.
- Your mobile operator puts it there, just like they already do for their stuff
Each of these has its own problems/challenges. How to compel them to insert this (ahem “backdoor”), and the different risks with each of them.
Ok not much help there, for what is worth I tried building your recipe here. The full backtrace is not helpful - it just shows that the linker failed to run the binary:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fe6c77 in dl_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
(ins)(gdb) bt
#0 0x00007ffff7fe6c77 in dl_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
#1 0x00007ffff7fe3074 in _dl_sysdep_start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
#2 0x00007ffff7fe4c91 in _dl_start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
#3 0x00007ffff7fe3a98 in _start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
#4 0x0000000000000001 in ?? ()
#5 0x00007fffffffdf31 in ?? ()
#6 0x0000000000000000 in ?? ()
Strangely my ldd shows nothing for the final minikube binary. file does show the guix interpreter though and it looks good:
$ file /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube
/gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2, Go BuildID=aBEWfkldQzf4mlUsITym/a6aHGcy9omlZPRTvR8ta/1-lUpI-DPce979zTpJQy/jMuF_0TfmkRW2e3NFst2, not stripped
readelf is a bit more helpful than ldd:
$ readelf -d /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube
Dynamic section at offset 0x270 contains 21 entries:
Tag Type Name/Value
0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib]
0x0000000000000004 (HASH) 0x2dcbb20
0x0000000000000006 (SYMTAB) 0x2dcc080
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000005 (STRTAB) 0x4003c0
0x000000000000000a (STRSZ) 795 (bytes)
0x0000000000000007 (RELA) 0x2dcb668
0x0000000000000008 (RELASZ) 24 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x3e65300
0x0000000000000015 (DEBUG) 0x0
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2]
0x000000006ffffffe (VERNEED) 0x2dcbaa0
0x000000006fffffff (VERNEEDNUM) 3
0x000000006ffffff0 (VERSYM) 0x2dcba40
0x0000000000000014 (PLTREL) RELA
0x0000000000000002 (PLTRELSZ) 960 (bytes)
0x0000000000000017 (JMPREL) 0x2dcb680
0x0000000000000000 (NULL) 0x0
Another way to check rpath is to use patchelf
$ patchelf --print-rpath minikube
/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib
The one thing that stands out to me there is that runpath lacks glibc. I also don’t know why gcc is in there (but it was in the build recipe).
So I added the libc to the runpath (your paths will be different)
$ patchelf --set-rpath /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib:/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib minikube
and voila
$ ./minikube
minikube provisions and manages local Kubernetes clusters optimized for development workflows.
Basic Commands:
start Starts a local Kubernetes cluster
status Gets the status of a local Kubernetes cluster
stop Stops a running local Kubernetes cluster
(...)
I never used patchelf-plan, so I’m not sure what you should do there, but maybe find other recipes that use it? I see some in nonguix that add glibc there.
Looks like a segfault at the end there. Can you try and get a backtrace with gdb?
Also the SEGV_ACCERR seems to mean permission denied (no idea here, maybe related to the earlier mmap?)
True friendship is indeed to trade ssh keys.
What kind of hardware are we talking about here. Tiny boxes, big boxes? Disks, networking?
If the recipe change is small you can create your own file that imports the existing package and extends it to modify the version.
This is a minimal example that inherits from the existing one
(define-module (mystuffypackages)
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (gnu packages)
#:use-module (gnu packages education)
)
(define-public my-anki
(package
(inherit anki)
(version "2.1.65")
(source
(origin
(method url-fetch)
;; Changed the url to github - could not download from site archive
(uri (string-append "https://github.com/ankitects/anki/archive/refs/tags/"
version ".tar.gz"))
(sha256
(base32 "1s28kdaw864rj6x9zgq5wwwl0gi5cyn2kg91jkq05v1bwgl3f76a"))
;; FIXME 2.1.16 uses a patch - check education.scm - it is not
;; applying
))
;; FIXME currently failing to build due to disable-update-check
))
my-anki
You can call guix build directly to build the package from this file. To be clear this is currently failing for me :D
Check this blog article for a pretty nice overview of how to create your own packages and channel https://guix.gnu.org/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/
Fair point (IP, email, browser session data). Those should not be exposed via the federation in any way. And the existence of the federated network means we could switch instances if we are concerned our instance is a bad actor about this.
I did not mean to suggest the ecosystem is not valuable for privacy. I just really don’t want people to associate federation with privacy protections about data that is basically public (posts, profile data, etc). Wrong expectations about privacy are harmful.
To be fair I do not expect any privacy protections from lemmy/mastodon in general, or from blocking/defederation in particular.
Lemmy/Mastodon protocols are not really private, as soon you place your data in one instance your data is accessible by others in the same instance. If that instance is federated this extends to other instances too. In other words the system can be seen as mostly public data since most instances are public.
The purpose of blocking or defederation (which is blocking at instance level) is to fight spam content, not to provide privacy.
guix pull only syncs the package definitions
To update the packages in your profile use
guix package -u
If you are also running GuixSD you will need to reconfigure your system (guix system reconfigure) to update your kernel.
The getting started doc describes the same process (guix upgrade is an alias to package -u), see:
https://guix.gnu.org/manual/en/html_node/Getting-Started.html