All the boys think she's a star.

If that bag is about the same size as her head, which for girls averages ~50 cm circumference, then there's about 2 litres of uranium there. Uranium's density is 19g / cm3, so that's about a 40 kg bag she's lifting in one hand. Strong girl!

We can also determine that that's a bag of U-235, because the critical mass of U-233 is only 15 kg, and she'd be in the middle of a mushroom cloud otherwise.

Having had one of the old Windows phones with a keyboard dumped on me at an old workplace, can confirm it's completely possible for a phone to have a keyboard and be a complete piece of shit.

A good phone with a good keyboard may have some use cases. If you do a lot of writing but not any more computing power or screen space than a phone has, plus you want to be doing that on the move, then yeah. For me, can shitpost on forums using my phone in my spare time, and dealing with on-call work issues - having multiple tabs of Jira and Slack open, for instance - just isn't really practical on a small screen.

If your job is very email-centric, then yeah, sure. Blackberry were very good for just having the stuff you need - email, vpn, 'corporate' office documents - in a form that worked.

Also interesting is the notion of 'Kolmogorov Complexity' - what is the shortest programme that could produce a given output? Worst case for a truly random sequence would just be to copy it out, but a programme that outputs eg. a million digits of pi can actually be quite short. As can a programme that outputs a particular block cypher for an empty input. In general, it is very difficult to decide how long a programme is needed to produce a given output, and what the upper limit of compression could be.

https://en.m.wikipedia.org/wiki/Kolmogorov_complexity

True. Although Calvin looks to be only rotating the paper by 90°, which would work as long as the original line is continuously increasing on both axes. Not so much "upside down" as "right-side up", tho.

Nice art, too. I think that scrolling down might ruin the pacing? but that's some beautiful spacing and colouring.

Assuming that these have fairly impressive 100 MB/s sustained write speed, then it's going to take about 93 hours to write the whole contents of the disk - basically four days. That's a long time to replace a failed drive in a RAID array; you'd need to consider multiple disks of redundancy just in case another one fails while you're resilvering the first.

True. Although given how easy it is to cast void pointers to the wrong damn thing, it would be nice if you did, makes refactoring much easier. Makes me appreciate std::any all the more.

Writing in ASM is not too bad provided that there's no operating system getting in the way. If you're on some old 8-bit microcomputer where you're free to read directly from the input buffers and write directly to the screen framebuffer, or if you're doing embedded where it's all memory-mapped IO anyway, then great. Very easy, makes a lot of sense. For games, that era basically ended with DOS, and VGA-compatible cards that you could just write bits to and have them appear on screen.

Now, you have to display things on the screen by telling the graphics driver to do it, and so a lot of your assembly is just going to be arranging all of your data according to your platform's C calling convention and then making syscalls, plus other tedious-but-essential requirements like making sure the stack is aligned whenever you make a jump. You might as well write macros to do that since you'll be doing it a lot, and if you've written macros to do it then you might as well be using C instead, since most of C's keywords and syntax map very closely to the ASM that would be generated by macros.

A shame - you do learn a lot by having to tell the computer exactly what you want it to do - but I couldn't recommend it for any non-trivial task any more. Maybe a wee bit of assembly here-and-there when you've some very specific data alignment or timing-sensitive requirement.

Why buttplug for tachyons?

Yeah. Doesn't take much optimising of disk writes to make things run much better on a Pi; they're quite capable machines as long as disk i/o isn't your limiting factor. Presumably the devs have been doing some tidying up.

My workplace is a strictly BitBucket shop, was interested in expanding my skillset a little, experiment with different workflows. Was using it as a fancy 'todo' list - you can raise tickets in various categories - to remind myself what I was wanting to do next in the game I was writing. It's a bit easier to compare diffs and things in a browser when you've been working on several machines in different libraries than it is in the CLI.

Short answer: bit of timesaving and nice-to-haves, but nothing that you can't do with the command line and ssh. But it's free, so there's no downside.