All the boys think she's a star.
addie
joined 1 year ago
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.
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.
Mona Lisa is, alas, a terrible example. It's a (small) painting famous for its very finely blended brush strokes, and yet it's behind two layers of protective glass, a barrier about five metres away, and there's generally about ten thousand tourists queuing up to see it. It's something you go to have seen, rather than to see.
Unless you wanted an example of a retro game that you play to have said you've played it, not too actually play, in which case it's a superb example. Plenty of games that were legendary at the time but who's gameplay doesn't hold up any more.
The Louvre has some massive rooms full of Raphael masterpieces and Gericault's "Raft of the Medusa" just down from the Lisa - those are well worth seeing in the flesh, big pictures that reproduction doesn't do justice to.
Nice art, too. I think that scrolling down might ruin the pacing? but that's some beautiful spacing and colouring.
But does that make the game more fun, or does it lower the barrier of entry for smaller studios to make high-quality games?
Arguably, ray-tracing does lower the barrier to entry. You place lights where they really are in a scene, boom, everything is light perfectly. Art assets and tuning up lighting are a huge time cost in current AAA games; making that much easier might benefit gaming in general.
Having improved physics modelling might improve physics-based games, but something like Angry Birds doesn't need a supercomputer anyway, and for most games it's just added prettiness that greatly increases the production cost
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.
That looks worse, though. It's enhanced the printing on the other side of the page so that it's more visible.