Just tried to install that on my pixel 9, and the option is there (Linux development) and the Terminal app is there, but it seems to freeze on launch, when it asks for permission to get Location. Bummer I was looking forward to this!
3,794 karma · joined April 29, 2015
But still, it gets installed, trying to justify its existence.
I'm a STRONG believer in tapes!
Even LTO 5 gives you a very cheap 1.5TB of clean, pretty much bulletproof storage.. You can pick a drive (with a SAS HBA card) for less than $200, there is zero driver issue (SCSI, baby); the linux tape changer code is stable since 1997 (with a port to VMS!).
Tape FTW :-)
So I ended up writing my own of course; no need for all the fancy features, just PLEASE let me receive email over SMTP and deliver them locally with 'dma'. Pfew.
But again, if you don't like the generated code, you can take the generated code and tweak it, and use that; I did it quite a few times.
And stare at the generated code!
More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide your own vector source/destination type -- you can do a lot by 'styling' your C code while thinking about what the compiler might be able to do with it -- for example, use extra intermediary variables, really break down all the operations you want etc.
Worst case if REALLY the compiler isn't clever enough, this give you a good base to adapt the generated assembly to tweak, without having to actually write the boilerplate bits.
In most case, the resulting C function will be vectorized as good, or better than the hand coded one I'd do -- and in many other cases, it's "close enough" not to matter that much. The other good news is that that code will probably vectorize fine for WASM and NEON etc without having to have explicit versions.
For example, pseudo code in a sub-function:
if (that) write_field('that'); if (these) write_field('these');
With messagepack you have to go and apply the logic to count, then again to write. And keep a state for each levels etc.
+ The Object and Array needs to be entirely and deep parsed. You cannot skip them.
+ Object and Array cannot be streamed when writing. They require a 'count' at the beginning, and since the 'count' size can vary in number of bytes, you can't even "walk back" and update it. It would have been MUCH, MUCH better to have a "begin" and "end" tag --- err pretty much like JSON has, really.
You can alleviate the problems by using extensions, store a byte count to skip etc etc but really, if you start there, might as well use another format altogether.
Also, from my tests, it is not particularly more compact, unless again you spend some time and add a hash table for keys and embed that -- but then again, at that point where it becomes valuable, might as well gzip the JSON!
So in the end it is a lot better in my experience to use some sort of 'extended' JSON format, with the idiocies removed (trailing commas, forcing double-quote for keys etc).
With 865 dependencies pulled in by cargo :-)
Seems you need to know the exact keycodes, or names, or whatever key you want to use. Like XF86_MonBrightnessUp. Want to add a combo? not sure how to do that either.
* No support for ACPI sleep. In 2024. Seriously. * No support for 4 and 3 pins fans. 3 pins are 100% speed all the time. * IPMI web interface straight out of 2010. * NVME placement prevents you from using heatsinks. * Tons of opaque jumpers on the board, with no board labelling.
The ASRock Rack equivalent board is amazing in comparison.
I always thought it was insane. Perhaps it was a good idea 30 years ago when we were actually building for dozens of 'unstable' variants of UNIX with a dozen compilers, but these days?
And yes, MOST projects can be compiled just fine with a 2 pages Makefile, more often than not with -j for parallel build, and as a bonus, won't keep around a dozen turd files.
Oh also, it is supposed to help 'portability' but MOST of my time is wasted trying to fix autotools configs when it invariably break in some new interesting and arcane ways.
I find it quite horrifying in many ways to see how much resources are used for so very little in terms of user benefits. Not just 'UI' per se, but just general functionality.
And the 'reasons' are always the same too, 'it is more maintainable' (read: it is not, in 2 weeks time the new version of your stack will break your 'code'.), 'it is easier to read for a newcomer' (read: no, not at all, it is just this week's fancypants trend), 'it is more secure' (read: just because we don't actually KNOW what it's doing, and rely on hopefully someone else for it) etc etc.
Last (big) pass was the text editor, which isn't totally finished and polished but I had to release something for the deadline ;-)
The price you had to pay for lickable UIs :-)
But it is actually pretty easy to switch to Chicago in the library -- apart from the clone you mention, there is also a 'plain' TTF version of the original Chicago floating around...
Because it allows you to /cancel/ the action.. click, 'oops don't want that' drag mouse/finger out and release. No action taken. User is in control. Amazing.
I tried a few times to see if I could get any advantage using tmux but always revert back to none at all. To me the scrollback that works 'as expected' without having to remember key combos, and also work with the mouse are a key feature!