movq

www.uninformativ.de

No description provided.

The GPG signatures of my software tarballs have been wrong for years (because I’ve been using rsync wrong, funny enough, it wasn’t a GPG issue) and nobody ever noticed. (They still are wrong at the moment, because I haven’t pushed the fix, yet.)

This confirms that this is just a total waste of time. Nobody ever checks this. Maybe this matters if you’re a distro, but why even bother as a single person …

⤋ Read More
In-reply-to » After around 3 years, I managed to make my "smallest recognizable canine", even smaller. So here's the all new, smallest recognizable canine 2.0: Media

@thecanine@twtxt.net Wow. I’m not an artist in any way, but I have tried to make icons for programs or fonts every now and then. Making something that is still recognizable at so few pixels is hard. Hats off!

⤋ Read More
In-reply-to » A cargo train ripped off several hundred meters of catenary and during construction they found a WW2 bomb. If I had gone to the office today, I would not have made it home for two reasons. https://www.swr.de/swraktuell/baden-wuerttemberg/stuttgart/bombenfund-in-stuttgart-untertuerkheim-100.html

@lyse@lyse.isobeef.org Oh dear. 🙈 So glad that WfH is a thing now. Imagine how utterly annoying it would be if they expected you to still come in despite this …

⤋ Read More
In-reply-to » You can explicitly use colors in manpages. I saw this in the apt manpage of Ubuntu recently, which, for some reason, uses blue text in one place:

Ah, so apparently they don’t like writing manpages anymore and instead use XML:

https://salsa.debian.org/apt-team/apt/-/blob/main/doc/apt.8.xml

And then they use XSLT on top and what not:

https://salsa.debian.org/apt-team/apt/-/blob/main/doc/manpage-style.xsl.cmake.in

It’s not even explicitly blue:

https://salsa.debian.org/apt-team/apt/-/blob/main/doc/apt.ent?ref_type=heads#L17

Abstractions upon abstractions upon abstractions.

⤋ Read More
In-reply-to » Speaking of manpages:

You can explicitly use colors in manpages. I saw this in the apt manpage of Ubuntu recently, which, for some reason, uses blue text in one place:

https://movq.de/v/de5ab72016/s.png

Makes little sense to me. I’m glad that most manpages don’t do this. I wouldn’t want unicorn vomit all over the place.

Using colors can be done using the low level commands \m and \M:

.TH foo_program 3
\m[blue]I'm blue\m[], da ba dee.
\m[red]\M[yellow]I'm red on yellow.\m[]\M[]
This is quite horrible.

https://movq.de/v/394282ec75/s.png

⤋ Read More
In-reply-to » Speaking of manpages:

@kat@yarn.girlonthemoon.xyz On the one hand, all these programs have a very long history and the technology behind manpages is actually very powerful – you can use it to write books:

https://www.troff.org/pubs.html

I have two books from that list, for example “The UNIX programming environment”:

https://movq.de/v/c3dab75c97/upe.jpg

It’s a bit older, of course, but it looks and feels like a normal book, and it uses the same tech as manpages – which I think is really cool. 😎

It’s comparable to LaTeX (just harder/different to use) but much faster than LaTeX. You can also do stuff like render manpages as a PDF (man -Tpdf cp >cp.pdf) or as an HTML file (man -Thtml cp >cp.html). I think I once made slides for a talk this way.

On the other hand, traditional manpages (i.e., ones that are not written in mandoc) do not use semantic markup. They literally say, “this text is bold, that text over here is italics”, and so on.

So when you run man foo, it has no other choice but to show it in black, white, bold, underline – showing it in color would be wrong, because that’s not what the source code of that manpage says.

Colorizing them is a hack, to be honest. You’re not meant to do this. (The devs actually broke this by accident recently. They themselves aren’t really aware that people use colors.)

If mandoc and semantic markup was more commonly used, I think it would be easier to convince the devs to add proper customizable colors.

⤋ Read More
In-reply-to » Speaking of manpages:

@lyse@lyse.isobeef.org @kat@yarn.girlonthemoon.xyz Colorized manpages have been a thing for a very long time:

https://movq.de/v/81219d7f7a/s.png

Problem is, hardly anybody knows this, because you configure this by … drumroll … overwriting TERMCAP entries of less in your ~/.bashrc:

export LESS_TERMCAP_md=$'\e[38;5;3m'      # Bold
    export LESS_TERMCAP_me=$'\e[0m'           # End Bold
export LESS_TERMCAP_us=$'\e[4;38;5;6m'    # Underline
    export LESS_TERMCAP_ue=$'\e[0m'           # End Underline
export GROFF_NO_SGR=1                     # Needed since groff 1.23

⤋ Read More

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)

⤋ Read More
In-reply-to » “Wayland Will Never Be Ready For Every X.Org User”

I wasn’t really aware until recently that programs can’t choose their own window’s position on Wayland. This is very weird to me, because this was not an issue on X11 to begin with: X11 programs can request a certain position and size, but the X11 WM ultimately decides if that request is being honored or not. And users can configure that.

But apparently, this whole thing is a heated debate in the Wayland world. 🤔

⤋ Read More
In-reply-to » Do I buy a new monitor or do I live with the burn-ins all the time? It’s getting annoying. When I edit images in GIMP, I have to double check if something is a pixel or a burn-in.

This is just the universe telling me to reduce my screen time.

⤋ Read More
In-reply-to » Do I buy a new monitor or do I live with the burn-ins all the time? It’s getting annoying. When I edit images in GIMP, I have to double check if something is a pixel or a burn-in.

@lyse@lyse.isobeef.org To be fair, I did first notice this a while ago. But no monitor I ever had showed burn-ins like this (be it TFT or CRT), so I didn’t know that I should have sent it back. And then it got worse over time and now I see ghost images after 20-30 minutes. :(

⤋ Read More

Stuff that nobody needs:

systemctl uses ANSI escape codes to underline text (\e[4m) and then it also uses special escape codes – that Wikipedia classifies as “not in the standard”, but I haven’t looked it up – to change the color of the underline. That color change is barely noticeable in the first place.

Some terminals don’t support this and now my systemctl output is blinking because of that.

⤋ Read More