

Desktop version too old and phone version too new to be affected
(•_•)
( •_•)>⌐■-■
(⌐■_■)
Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)


Desktop version too old and phone version too new to be affected
(•_•)
( •_•)>⌐■-■
(⌐■_■)
But it saves the command history to disk.
It makes the exit command redundant, so that is removed from the history, but all other commands in all cases but mistakenly sshing into the wrong machine will still be saved.


ECC ram. Hardware stability was the main factor.
Real Linus mentions spending days hunting an instability bug in the kernel to have it turn out as bad ram on his pc.
I use my mice at over 20k dpi, and for the longest time the sensors got increasingly more accurate but still had the rare wiggle. Especially with cars driving by.
To stop my system waking I first started turning the mouse upside down, but later instead propped it half up on the rim of my keyboard. That latter is really quite convenient, might also work for you.


The year is 2046, the ntfs4g+±next driver is put into maintenance mode as Linux slowly phases out support for the legacy operating system “windows”.


As long as you don’t run out of memory, you can actually insert and lookup in O(1) time for a known space of values (that we have). Therefore we do get the quadratic speedup, that when dealing with bits of keysize or entropy means cutting it in half.
Checking to get a specific uuid takes 128bit, so 2128 draws of a uuid. Putting all previous uuids into a table we expect a collision in 64bit, so 264. We also need about that much storage to contain the table, so some tens of exabytes.


Against a apecific one too. Usually you’d check for duplicates against all previous uuids


In a way that weakens the open source software world by giving companies a way to avoid the GPL license of linux.
For really no reason, this project gains nothing from being MIT instead of GPL.


MIT license :|


I think they mostly are.
Cache is already in .cache/mozilla, so usually there is no change hence I didn’t mention it. They did move the cache to the XDG_CACHE_HOME by default. And yes they are using the XDG variables including the recommended fallback values.
The line between data and config has always been blurred, Most data in the browser is “data” until a user overrides it. Even extension files presence is linked with their configured state of being installed.
For log files I’m not sure anyone follows that. Besides firefox barely has any plain logs, I think having those in the profile is fine.
Currently it’s all in XDG_CONFIG_HOME


I’ve met some from asia and europe


In practice that should mean running mv ~/.mozilla ~/.config/mozilla.
Of course the old directory will still be detected and used if present, probably for a long time to come.
It’s nice but a little janky. For me for example I have to hit ctrl+C twice after closing a session where I started a kde program.
I still use X forwarding.
It works just fine using xWayland, and X forwarding has always been so janky there is no chance to notice any difference caused from using xWayland instead of native.
It will surely take many years and well established wayland native remote tunneling before anyone thinks of ditching xWayland.


Do they work with split apps yet?


I could do a script if I knew what I was gonna do ahead of time, or would write one later if I was gonna do it more often.
A variable in the shell is fine, but I still have to skip over it to change the first command, it still breaks up the flow a bit more than not having that "$file" in there at all.
Also if I interrupt the work (or in this case have to let it run for a while), or if I wanna share this with others for whatever reason, I don’t have to hunt for the variable definition, and don’t run any risk of fetching the wrong one if I changed it. Getting by without variables makes the command self-contained.
And it still maintains the flow of left to right, it’s simply easier to take the tiny well-known packet of cat file and from that point pipe the information ever rightwards, than to see a tail, then read the options, and only then see the far more important start of where the information comes from, to the continue on with the next processing step.
Any procedural language is always as left to right as possible.
If you really want to avoid the cat, I have yet another different option for you:
< /dev/nvme0n1 strings | grep -n "text I remember"
< /dev/nvme0n1 tail -c -100000000000 | head -c 50000000000 | strings | grep -n "text I remember"
< /dev/nvme0n1 tail -c -123456789012 | head -c 3000 > filerec
This ofc you can again extend with ${infile} and ${recfile} if the context makes it appropriate.


It makes the command easier to edit here. Put the various forms across my use next to each other and it becomes apparent:
cat /dev/nvme0n1 | strings | grep -n "text I remember"
cat /dev/nvme0n1 | tail -c -100000000000 | head -c 50000000000 | strings | grep -n "text I remember"
cat /dev/nvme0n1 | tail -c -123456789012 | head -c 3000 > filerec
compare that to
strings /dev/nvme0n1 | grep -n "text I remember"
tail /dev/nvme0n1 -c -100000000000 | head -c 50000000000 | strings | grep -n "text I remember"
tail /dev/nvme0n1 -c -123456789012 | head -c 3000 > filerec
where I have to weave the long and visually distracting partition name between the active parts of the command.
The cat here is a result of experiencing what happens when not using it.
Worse, some commands take input file arguments in weird ways or only allow them after the options, so when taking that into account the generic style people use becomes
strings /dev/nvme0n1 | grep -n "text I remember"
tail -c -100000000000 /dev/nvme0n1 | head -c 50000000000 | strings | grep -n "text I remember"
tail -c -123456789012 /dev/nvme0n1 | head -c 3000 > filerec
This is what I’d expect to run across in the wild, and also for example what ai spits out when asked how to do this. You’ll take my stylistic cats over my dead body


Oh right I misunderstood.
I didn’t do that because I was planning to switch out strings in that line. First inserting the tail and head before it to hone in on the position, then removing it entirely to not delete “non-string” parts of my file like empty newlines.
cat /dev/nvme0n1 | strings | grep -n "text I remember"
cat /dev/nvme0n1 | tail -c -100000000000 | head -c 50000000000 | strings | grep -n "text I remember"
cat /dev/nvme0n1 | tail -c -123456789012 | head -c 3000 > filerec
This would be the loose chain of commands I went through, editing one into the next. It’s nice keeping the “constants” like the drive device that are hard to type static. That way mentally for me the command starts only after the first pipe.
I just don’t update kde very often since it might force me to re-login or restart. I currently have 9 months uptime so that’s the age of kde connect.
(gentoo)