32 is ASCII space, the highest number you need is 114 for r (or 122 for z if you want to be generic), that’s a range of 82 or 90 values.

The target string has 13 characters, a long long has 8 bytes or 16 nibbles – 13 fits into 16 so nibbles (the (x >>= 4) & 15) it is. Also the initial x happens to have 13 nibbles in it so that makes sense. But a nibble only has 16 values, not 82, so you need some kind of compression and that’s the rest of the math, no idea how it was derived.

If I were to write that thing I’d throw PAQ at it it can probably spit out an arithmetic coding that works, and look even more arcane as you wouldn’t have the obvious nibble steps. Or, wait, throw NEAT at it: Train it to, given a specific initial seed, produce a second seed and a character, score by edit distance. The problem space is small enough for the approach to be feasible even though it’s actually a terrible use of the technique, but using evolution will produce something that’s utterly, utterly inscrutable.

Blender changed it to just start typing one or two minor versions ago. There’s certainly stuff I have no idea how to find in the menus because F3 is way more convenient than remembering things (just be aware that you still need to be in the right mode for stuff to show up).

Calling Terry racist is ableist. He was very much equal opportunity, applying the hard r to pale white CIA agents (imagined or otherwise).

One of the issues I have with C++ is the standard library source seems to be completely incomprehensible.

AAAAAAhhh I once read a Stroustrup quote essentially going “if you understand vectors you understand C++”, thought about that for a second, coming to the conclusion “surely he didn’t mean using them, but implementing them”, then had a quick google, people said llvm’s libc++ was clean, had a look, and noped out of that abomination instantly. For comparison, Rust’s vectors. About the same LOC, yes, but the Rust is like 80% docs and comments.

Half the reason why I bought an RTX GPU was for the video enhancement features like SDR to HDR conversion and AI upscaling

Neither of those things have anything to do with raytracing. Well the tensor cores used for denoising in RT workloads are suitable for all kinds of AI workloads and thus also upscaling, but really it hasn’t got to do anything with raytracing. Or AI in particular any GPU can do convolutions.

I don’t own an nvidia card and honestly few linux users do because their driver support sucks, I’d say if nvidia advertised those features and their linux drivers don’t have them your complaints should be directed at nvidia. They won’t care.

Meanwhile, mpv does inverse tone mapping natively. They don’t integrate AI upscaling but there’s various projects providing glsl shaders which mpv can use, here’s the configs for Anime4K. There’s also frame interpolation around somewhere but I haven’t used it in ages because variable refresh rate is the best solution to odd frame rates.

Development of X halted, the few patches that are still landing concern xwayland, don’t expect anything to happen there. KDE 6.0 ships with experimental HDR support on wayland, you might not need to wait five years go give a live USB stick a spin. Arch wiki has some pointers (not that I’d be recommending arch but I am recommending their wiki).

Hmm. Actually you prompted me to dig a bit deeper: tar goes all the back to Version 7 UNIX, 1979, but the command line syntax is shared with tap, included in Version 1, man page dated to 1971-11-03. Development of C started 1972. Might’ve been written in B, you’d have to unearth a source archive I bet it’s around somewhere. But anyway if you look through the other Version 1 commands a lot of them don’t take hyphen commands, ls does, e.g. rm doesn’t on account of only taking file names as arguments.

dd is actually younger, Version 5, 1974, the syntax apparantly comes from IBM’s JCL.

Admittedly, that’s all before my time.

Both BSD and GNU tar take hyphens, I don’t really have any experience with anything else but a short stint with Solaris in the early 2000s (very emphatically before Sun got gobbled up by Oracle) and I don’t remember hyphens tripping me up. Much unlike killall. And I’m apparently not alone in that.

Nope, tar spec doesn’t say anything about a help message. The man spec OTOH requires at least syntax documentation for all standard utilities to be present on the system.

POSIX. POSIX didn’t get designed but documented behaviour that was portable between different UNIX flavours and was then declared a standard.

If you’re annoyed by it just consider the xvf in tar xvf to be a subcommand as pull is in git pull. Tar simply has a fancy subcommand syntax. At least it’s not dd.

GNU tar, at least a modern one, that is the one that happens to come with my system, won’t try to read from /dev but stdin and then complain that it’s a terminal and refuse.

Quoth POSIX on the f flag:

Use the first file operand […] as the name of the archive instead of the system-dependent default.

That is GNU is compliant, here, the default is system-dependent. f - is required to be stdin, though, so you can bunzip2 foo.tar.bz2 | tar xf - or such in a portable manner, don’t have to rely on tar having a z option (which is nonstandard) or it auto-detecting compression (even more nonstandard). What is not standard either is tar -x: Tar doesn’t take leading hyphens. Tar is one of those programs so old its command line syntax got standardised before command line syntax standards were established. OTOH it’s not nearly as bad as dd, you can interpret how tar does things in the same way as git pull: It’s a subcommand, not a flag.

Altavista. Back when keywords still meant something.

No the second is still 9192631770 hyperfine transitions of Cs-133 on the moon and that’s the same length of time at least unless you want to severely annoy physicists by implying that the laws of nature aren’t constant throughout the universe. It’s just that from our perspective it looks like time is flowing differently there.

That was kinda the situation in the past: Every town would have its own time, synced to the local noon every once in a while as the precision of the church or townhall clock demanded. That stuck around until railroad operators and passengers got sick and tired of dealing with the timetables that produces.

That sounds… iffy. Thing is that UTC lags more and more behind TAI as UTC takes the earth’s rotation into account, introducing leap seconds so that all the timezones don’t slowly drift across the globe. Moon people care preciously little about the earth’s rotation around its own axis, more relevant is its own day/night cycle which (because tidal lock) is an earth month. The system might just be stable enough so that UTC can simultaneously sync to that, you’d have to ask an astronomer.

Actually, no, forget it: The moon moves quite fast relatively to the earth’s surface, more than enough for relativistic effects to apply – they also apply to GPS satellites, stuff simply wouldn’t work if those things ran on Newtonian maths. Sooner or later it’s going to need adjustments due to that.

The ironic part here is that NixOS and Steam don’t really play that well together: Nothing is where pre-built binaries expect it to be on NixOS, including ld.so, so pre-built binaries simply won’t run without patching. NixOS can do that for Steam… but as Steam is also downloading binaries, essentially being its own package manager, those binaries then run into the same issue.

OTOH you can just run the whole shebang in a chroot, exposing exactly what Steam expects (couple of libraries and the graphics drivers) which is what NixOS does and I never had any issues.

Another hurdle would be that NixOS is not end-user friendly. It just hasn’t been a focus, Valve would need to write a graphical configuration/package management utility. NixOS also doesn’t tend to go easy on disk space and network bandwidth which might be considerations, OTOH probably not an issue if they manage their own release channel. Things like flatpack also aren’t an issue they get the same treatment Steam does.

Remember what I said about the vim out of the box experience and configuration nightmare? Yep that’s why.

If you want to stick with (n)vim over helix head over here, which is going to take away like 90% of the pain. You’ll still need to go “yep I want this and this and this” but it’s much more like browsing through the VSCode store and hitting “install”. Quick start guide, general IDE, Java IDE should do it. There’s actually more end-user type documentation for spacevim as compared to vim (which is a giant heap of hysterical raisins noone writes beginner intros for) or helix (which is too young to have actually good docs). Both are more opinionated than plain vim+whatever plugins but at least as far as I’m concerned I don’t care which of the fifty available fuzzy file finder plugins I’m using: I just want one that works. Spacevim makes a default choice for you, helix has one built-in. Same goes for LSP integration.

Also you don’t necessarily need to dive in at the deep end. As said most of the difference vs. your usual IDE isn’t in feature set but how you interact with the thing, editing markdown should suffice to get a good idea, with or without LSP support in the case of markdown it’s really optional, I think it’s mostly about helping you to not have broken links.

Blog post! Blog post!

Take Git for example,

Git is simple in its operations, but utterly complex in the stuff you might need to do because the operations aren’t mathematically clean. Things like git rerere should plainly not exist because states which require using it should be impossible to reach. And the likes of vim, or pre-2.8 blender, kinda ended up there as they grew organically, the more you tack on the more likely it is that different things don’t work well with each other. Which is why I recommended helix: It’s a clean-slate redesign. E.g. helix’ command language is consistently <selection><action> while vim is all over the place, you end up learning things by rote instead of really exploiting the combinatorics. On the VCS side darcs is sane in principle but it’s patch theory didn’t really have efficiency in mind and there’s a very nasty complexity explosion you can run into, pijul fixes all that: It has both a vastly superior interface without surprises (such as patches not being associative) and it’s fast.

We’re talking about things I might do a couple of times a month.

The most striking difference between the likes of VSCode and Helix are not things that you do once a month, but stuff that you do all the times: Navigating and basic editing. Within the first couple of pages of going through the tutorial you’ll know if navigating with hjklwWbB etc. is a thing that would save you time, whether it’s worth making the interface modal, having to type i (or various other options) before actually writing text. I certainly still haven’t really gotten my head around Helix’ multiple cursors because I don’t need it that often but VSCode wouldn’t be any faster at those kind of things, either.

I’ll look into LSP on my PC, but I might just forget I have it by the time I try to figure out what to do with it.

Language Server Protocol. Actually started out on VSCode, it’s how language integration works: The compiler writers (or whoever) provide functionality such as “give me docs for a certain identifier”, “rename this identifier” etc. and the editor/IDE simply offers those options, display the docs in-line, etc. It quickly caught on everywhere, 20 years ago you certainly wouldn’t have seen me advocate writing Java in vim because the likes of Eclipse were just way better at wrangling the language, but the times of those language-specific functions not being available in good ole code editors are over.

I can write regex to replace variable names in a matter of seconds despite not needing to do it very often

You can write a regex to replace a string in a matter of seconds. And so can I. What neither of us can do is write it such that the replacement is limited to the identifier we want to rename (because pumping lemma), that needs syntax if not semantics-aware editing and that’s exactly what LSP is for.

You’re using a screwdriver as a hammer. Does it work, sure, is it advisable? Even if you don’t have a hammer it might be easier and quicker to drive to the hardware store and buy one, depending on the particular nail you’re dealing with.

Meanwhile in IntelliJ or VSCode I just find the menu and if I want to be super quick, next to the menu item is the keyboard shortcut

Helix: <space>? opens function search, enter “rename”, “rename symbol” will be the first hit and it’ll also tell you that it’s bound to <space>r.

Blender: F3 instead of <space>r. Get out of here with clicking through menus. I have no idea where to find recalculate normals in the menus and I don’t care. “face” in edit mode, probably. Nope, just checked: Edit mode, mesh->normals->recalculate [inside, outside]. Kinda makes sense while normals are a property of faces you can’t calculate them without reference to a mesh as you wouldn’t be able to tell outside from inside, only stuff like “face camera”.

This isn’t so much about gui or not gui thing, both IntelliJ and VSCode come from the windows school of GUI design which says “discoverable without a manual, hotkeys are available for power users”. Blender, OTOH, follows the UNIX philosophy of “RTFM, start working like a pro from the beginning it’s worth it, the interface is just a suggestion, adjust it to your workflow”.

Maybe I could eventually even get faster, but could I ever recoup that time investment?

How would you know without giving them an honest spin? Personally I wouldn’t recommend vim, btw, lots of hysterical raisins and inconsistencies to be found there and configuration is a PITA which wouldn’t even be that bad if the out of the box experience was good. Helix cleans up both the command language and the whole configuration shebang (just make sure that LSP servers are installed and you’re good to go) while definitely sticking to the vi/blender style of interface design.

Regex solves any mass-operations

No it doesn’t not after you’ve used LSP-enabled identifier renaming. But that’s the thing: Emacs, vim, helix, all have LSP integration, they’re actual code editors they aren’t lacking any feature that you’d expect from an IDE.

Where “intuitive” means “shows important shortcuts on the bottom of the screen”.

It’s sufficient as a basic text editor, in the sense that it allows me to edit configuration.nix to include helix (a couple of years ago, nvim) without having to learn it because the commands to save and quit are, as said, displayed on the bottom of the screen. That’s about the extent of nano’s feature set, anyway, it’s a text editor, and a simple one as that, doesn’t even try to be a code editor.

When it comes to actually being intuitive though I vastly prefer the old DOS-style editors. The editor that shipped with it, as well as the likes of Turbo Pascal. “Press and release alt to get to the menu bar” type of interface: It allows you to have an at least half-way adequate feature set without requiring people to learn shortcuts. If Turbo Pascal displayed all its functions and their shortcuts at the bottom it’d take up more than half of the screen.

Really, “intuitive” when it comes to UI generally means “dumbed down, featureless”. Once a program actually has features things quickly become complicated and it’s counter-productive to keep things usable for users which aren’t willing to set at least a modicum amount of time aside to learn the very basics. The Blender Fundamentals series is what two hours of video. Text editors can get away with less as the feature set isn’t as broad but you should be willing to go through at least half of of the tutorial which is going to take 15 minutes or so, both for vimtutor and hx --tutor.