Thank for finding that, yes that's the one. It was incredibly accurate.
I'm in two minds about the fact it's down.
1. It's probably a good thing that it isn't super-easy to quickly find everyone's alternate accounts.
2. The capability is clearly there and the technology is out there, but now in the hands of the few people who bother to re-implement it.
It was a useful tool for highlighting the naivety of believing that throwaway accounts were a real possibility when stylometry analysis is so relatively cheap to do.
Can they eventually throw away Android and replace it with Fuchsia? In the reporting about Fuchsia that I read ages ago, it sounded like it was intended to be an Android replacement but, looking into it again just now, it seems more like an embedded OS for other non-smartphone hardware -- maybe with some (aspirational?) claims of utility on smartphones and tablets.
Fuchsia has components for running APKs (Android Runner) and Linux binaries (Starnix), but that probably isn't what you meant.
The problem with replacing a UI toolkit - any toolkit - is that any change to the toolkit requires modification of all software, including third-party software. Typically, when an OS wants to provide a new toolkit, they wrap the existing toolkit in new code. For example, on macOS, UIKit wraps AppKit, and on all Apple platforms SwiftUI is a wrapper around AppKit and UIKit (depending on platform). On Windows, every UI toolkit ultimately is creating "windows" as they are understood by USER[0], which creates corresponding objects in CSRSS and/or the NT kernel, which can then be used to draw on or attach to a GPU. The lowest level UI abstraction either OS provides is the objects supported by their oldest toolkit, and the lowest level programming language you can write apps in is whatever can call it.
Linux is a bit different, because it inherits its windowing model from X11. X shipped with no default toolkit and a stable window server protocol that apps could program against directly, in an era where most GUI OSes[1] didn't have 'servers' or 'protocols'. You populated resource files and called the relevant function calls to make things happen, and those function calls became sacrosanct. Even Windows NT couldn't escape this; it still used USER despite USER being years older than NT.
The best you can do is shim the library - write something more lower level than the old junk and then rewrite the old library in terms of the new one. This is what Xwayland does to make X apps work on Wayland; and it's what Apple did (mostly) with Carbon to give a transition path to Mac OS 8/9 apps on OS X. Google could, say, ship a new Android toolkit that doesn't use Java bindings, and then make Android's Java toolkit a shim to the new native toolkit. However, this still means you have to keep the shim around forever, at least unless you want to start having flag dates and cut-offs. For context, Apple didn't kill Carbon until macOS 10.15 Catalina, and if they hadn't refused to ship Carbon on 64-bit Intel, it probably would still be in macOS today.
[0] An interesting consequence of this is that disabling "legacy input" in games turns off the ability to move the application window since all that code is intimately coupled to every app that has to open a top-level (i.e. not a widget) window.
[1] At the time that would be XEROX Star, the Lisa, and the Macintosh
[2] This is also why Apple will never, ever ship an iPad that can run macOS software in any capacity. Even if they were forced to allow root access and everything else macOS can do. The entire point of the iPad is to force software developers to rewrite their apps for touch, and I suspect their original intent was for the Macintosh to go away like the Apple ][ did.
Correct, tl;dr roadkill. I don't mean to be disrespectful, someone anonymous picked a bitter fight about this once. But to your point, its clear there was a larger context that Fuchsia was born from, and the ambitions and commitment to it are greatly different than they were at some previous juncture.
It sounds like GP would benefit from satellite internet bypassing the firewall, but I don't know how hard the Chinese government works to crack down on that loophole.
In the US, HIPAA grants you the right to access your own health information [0]. I recommend asking providers to burn the DICOMs to a DVD (or send your images to you via an online portal, if they and you prefer) whenever you have medical imaging done.
For anyone wanting a better image of the "Modern model of the Lehmer Bicycle Chain Sieve" than what is embedded in TFA, it can be seen on page #4 of the Spring 1983 Computer Museum report (which is also a PDF):
> there is a pretty famous former M$ performance engineer who worked on Xbox and bunch of other large projects, he has webpage about how he tracks down bugs and performance issues, don't it have it handy unfortunately.
Cool project! I'm very interested in accurate preservation of the behavior of these old systems (chip decapping and scanning, FPGA reimplementation, accuracy-focused emulators) and using Ghidra to reverse engineer old games, especially on the 6502 and m68k architectures. Just an enthusiastic spectator at this point, but I hope to contribute something to the field eventually.
A sidenote: the action at 0:19 in the 50x-speed demo is intriguing. I've played many hours of Super Mario Brothers and watched various tool-assisted speedruns of it, but I don't recall seeing a Goomba reverse direction like that instead of just plowing into Mario. Is that a game glitch that you intended to show off with your recorded keyboard inputs? I haven't played in a long time, so I also wouldn't be surprised to hear that such behavior is common. I didn't find an obvious reference to it in the TAS info here [0].
Edit: there is precedent for that Goomba behavior [1].
I think that goomba bumped into the squished goomba Mario had just squished. Mario was just a bit to the left so the flat goombas hit box stuck out to the right a bit and the other goomba hit it.
I was researching the Armatron last weekend and was surprised to learn then about the single-motor operation. It's quite a complex system of linkages and transmissions [0] to enable the six degrees of freedom. I suppose that explains why the toy is so noisy. I had no idea that was how it worked, must not have taken mine apart when it broke or I outgrew it or whatever happened.
It also highlights an interesting change in engineering and product development that has happoned in my lifetime.
It used to be, when this Armatron was made, electronics and computers were magic and mechanical engineering, real complicated kind of mechanical stuff, was common and the slillset to do it was similarly common. In that world it makes sense to have the whole robot arm powered by one motor that constantly spins, with mechanical clutches and linkages deciding what moves when. That's because electronics and mechatronics like motors and encoders were still expensive and new.
Now its the opposite. In general, if given the choice between a complicated mechanical solution and a "simple" electronic/computer solution we choose that. Simple is in quoted because modern electronics and computers are far from simple. The manufacturing of a modern semiconductor rivals the Manhattan project. But is seems simple because we can just buy it at best buy and program it to do things. You can easily find lots of engineers to do something with code or an arduino, but finding someone who can design a fly ball governer, or even know what that is and why it matters, is rare.
Now days there are tons of cheap robot arms that have a servo motor for each joint, because servos are cheap and complex mechanics are not.
>Now days there are tons of cheap robot arms that have a servo motor for each joint, because servos are cheap and complex mechanics are not.
Servo motors aren't cheap at all.
Encoders aren't cheap either, in what universe do you live? The RC toys don't count by the way, because the cheap RC servos are terrible.
A fly ball governer? Is this some kind of joke? How are you going to operate it in any orientation other than upright? Why would you even want to?
There are probably ways to build a control loop with discrete electronics components that is cheaper than a mechanical system like that. Heck, it is probably cheaper to build an entire CPU with discrete components and then program that.
The reason nobody knows this crap is because it is useless. Your pseudo nostalgia for an age that existed before your time is ridiculous.
> For example Target used to not include groceries until recently.
There was a span of time where many of them didn't, but I was surprised to learn recently that the first ever Target store included groceries. See this 1962-05-03 advertisement[0] for the grand opening.
[0] https://news.ycombinator.com/item?id=33755016