Icecream95 @ixn@mastodon.xyz

@klaatu the reason why groff(1) outputs x^Hx sequences in titles is to make the characters bold - with paper terminals, it would print the character twice, and so with twice the ink.
less(1) detects this and automatically uses the terminal control character for bold (or for colours, if you have that configured).
groff also uses _^Hx to underline text.

@klaatu
It looks like the zramctl man page should have made it clearer that the block devices it creates are compressed.

Chrome OS uses zram as swap, and it gives a pretty good compression ratio - generally around 50% from my testing, so believe those scammers who tell you how to "Download a RAM stick cheap for free" (provided you don't already have the module).

zram can be used for more than just swap - it can also be used for testing filesystems or lvm in RAM, or as an alternative to tmpfs.

@klaatu
> gWO 13x18: "I don't remember where Scientific Linux is ... I know it's still active."

Are you still in that hole you dug in the ground?
https://www.phoronix.com/scan.php?page=news_item&px=Scientific-Linux-EOL

@klaatu
Also fun is when you mount root with commit=60, but haven't got an IO scheduler such as BFQ set up, so other disk accesses take lightyears (oops, I meant epoch wraparounds).

I've also taken to mounting the pacman cache and /usr/share/locale as tmpfs, and I update ~16 packages at a time, as I don't have much free disk space.

I'll be switching to Slackware as soon as qt5 appears in -current...

@klaatu
By the way, I really hate Arch updates. If you happen to close something while an update is going on, you'll have to wait a few hours until the library versions match up again.

That's really fun when you can't even start X (or wayland, for that matter).

The worst in terms of ABI compatibility (i.e. symlinking between versions doesn't work) is icu, so I've started keeping old versions of libicu in /opt. :)

@klaatu
Or, mlt could have just gone and used png, which would have got them down to 6.4M. I have a feeling they *do* do that, just Arch didn't package it properly.

The strength of using png shows why domain-specific compression algorithms are important - no-one sensible would try to use HuffYUV on audio or vorbis for an image...

Actually, an older version of mlt on Arch was 38M, which is still a lot, but heaps less than 258M.

Someone should probably create a bug report for Arch.

(3/3)

@klaatu
For this specific case, the block size doesn't matter too much unless it's very small (such as the 128k with xz).

When compressing something like source code, the results are obviously going to be very different as the lumas are just simple gradients, and all the files are the same size while source code has a lot of symbols, which are shared between files, and the files are ~~usually~~ hopefully quite short.

(2/3)

@klaatu
An experiment with compression:

MLT has 256M (!!) of uncompressed luma wipes, such as the image on this toot.

Compressing with gz yields 54M for squashfs and 52M for a tarball (zip gives a similar size).

With xz, it compresses to 21M for squashfs but 6.8M for txz. Individually compressing files with xz gives 7.2M.

However, when increasing the squashfs block size to 1M from 128K, xz drops to 8.7M but the result for gzip doesn't change much.

(1/3)

@klaatu
In the shownotes for 13x12, you forgot the / to close a strong tag, which made everything below it bold:

> from the <strong>a<strong> package set

@klaatu https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Desktop-ZFS-Root-Again

I had to restart Chrome due to a problem with the pointer texture on Chrome OS (the mouse pointer was a black block, and whenever I moved the mouse, the whole screen went black), and when I Ctrl-Shift-Alt-F2'd back into Arch, I noticed Firefox had gotten killed.
Coincidence? I don't think so.
This *could* be so that in situations where Firefox would get killed anyway due to Chrome restarting (i.e. Crostini), it gets TERMed nicely, so you don't lose any tabs, but I'm not so sure about that...

> Three vulnerabilities were discovered in systemd's journald: two memory corruption bugs and an information leak due to an out-of-bounds read.
> [These] could enable a local root shell in a matter of minutes.

https://www.phoronix.com/scan.php?page=news_item&px=Systemd-241-Prep-System-Down

#notinmyinitsystem

ChromeOS has an interesting way of making videos play on loop - if you ctrl-click on a video, it will tell you "This video will keep playing until the cows come home."
Do Chromebooks have cow sensors now?

I'm having some problems trying to run #enlightenment 22 (0.22.3-1.1 on openSUSE armv7l) - when running enlightenment_start, it crashes with this:

...
ESTART: 0.93087 [0.00001] - E_Shelf Init Done
ESTART: 0.93090 [0.00003] - MAIN LOOP AT LAST
open: Read-only file system
exit_gdb: 0
E - PID=303, valgrind=0

(Sometimes, I also get `free(): invalid pointer` above the open: line)
Any ideas on what I need to do? (And no, I definitely don't have a read-only FS.)

@klaatu I remember you asking a few months ago if there were any Google Drive clients that supported looking through your "Shared with me" folder.
Maybe a few months late, but I've found rclone (https://rclone.org/drive/) supports it.

The new-look Google Chrome, coming soon to a computer near you:
I mean, they decided to put the New Tab button on the LEFT, despite opening tabs to the right. 😕
If you want to try this new and "improved" look, go to chrome://flags/#top-chrome-md and set it to Refresh or Touchable Refresh, though I think you'll need to be in beta channel.
Note that I would not actually consider using Google Chrome for anything, I just haven't got round to removing Chrome OS yet.

Also coming: cursor motion blur.

I've been having problems with Emacs recently. Maybe I should consider restarting it after updating...