Managers and security team at google do not have access to your personal phone's data. A number of things in this article simply do not match my previous experience there. This has nothing to do with Epstein at all.
I think all the TinyMUDs I used (CMU and whatever the one in OK was), listened on nonstandard ports.
I had to use a VMS system which had different telnet behavior (staircasing due to CR/LF mismatch) and originally used a locally developed client (TINT mentioned here https://www.linnaean.org/~lpb/muddex/clients.html) then learned C to write a subsequent client (DINK) which supported macros and "portals"- an early way to transit across different MUDs. A few years ago I learned that DINK was forked and improved- my early C code was awfully bad. It's still bad, but it was awfully bad then.
The one funny bit is that I copied TINT's exit command (Control-Y) instead of using /quit which led to several years of email complaints form folks who couldn't exit the mud (in those days, you usually just had one terminal connection, and if you couldn't exit a program, you had to forcibly disconnect the modem).
There's one thing I haven't figured out with netcat- how do you know it connected? (I just looked it up, after many years: the -v flag. Which makes sense because netcat is supposed to be "transparent").
Good stuff- I had to learn most of this on my own.
Pro-tip: most of what you describe and document is already built into Qt, in the Graphics View Framework. It handles all the gunk around coordinate systems, canvas, zoom, scrollbars, and scaling, along with item groups, hit testing, multiple views of the same model, and extensive performance optimizations.
I have recently used Gemini to write an entire 2D CAD system based on this and it worked pretty well (I've already written one by hand).
Much of this stems from Google's original design for its search engine, and borg. Borg was not a batch scheduler, it was a service-keeper-upper with loose relationships between individual containers. Google's design was never friendly to MPI-style jobs (which long ago tended to be highly synchronous, with distributed processes that were extremely long-lived, and servers did not just "come and go").
There are a number of properties of SLURM and other batch systems that are far more convenient for users. Typically a SLURM system will have a large distributed filesystem that can be accessed from all the nodes using normal UNIX commands (GFS and Colossus aren't mountable filesystems and the UNIX tools do not really work against them natively). Reading output logs is often much easier (tail -f, less, etc) but the cost of the filesystem (per byte) goes up exponentially as the number of nodes increases.
I have extensive experience with both systems. My experience with SLURM is that the system is highly predictable, slowly changing, and I can get my work done. Whereas on Google systems, everything was breaking constantly and I had to focus on making my systems resilient to noise. On the other hand, the Google system scaled far larger, for cheaper.
When I joined Google I asked Jeff Dean how page rank was computed and he said it was an iterative mapreduce- I was assuming it was some sort of tightly coupled supercomputer-style job, but for the size of the web, and the link structure, MR made much more sense.
MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even if netcat and many other tools have replaced it.
All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.
Ah, my grandfather was a ham (N4MDB) and he always tried to get me interested in it, but I had to tell him I preferred the internet (this was late 80's, so few people actually had internet). Later when I read Stevens networking books I learned there was a whole Hawaii-based packet radio (ALOHAnet) , and the UC campuses had intercampus microwave networking for a while as well. I actually still remember him telling me about bouncing radio waves off the atmosphere which seemed like magic to me at the time.
Cars, no, but truckers have been damned for not just sacrificing themselves when their brakes failed. There was a recent incident where a truck had its brakes fail on its way into Denver from the Rockies and killed several people. They should have taken an off ramp, but IIRC, both in public opinion and in court it was argued that failing that they should have just committed suicide by going off the road before they hit a family.
There's a difference in expectation between the reactions of a person that has under 10 seconds to react and a truck driver that had minutes of time to plan, including bypassing an emergency ramp designed specifically for runaway trucks.
After passing the Genesee exit, Aguilera Mederos's truck began to smoke as he passed a runaway truck ramp, without taking it, and instead drifted into the left lane nearly clipping a white Chevy Silverado, and passed the next exit as well. For the next few minutes, Aguilera Mederos reached speeds upwards of 100 miles per hour (161 km/h)[6] and passed the next four exits.
Wouldn't it be risky to do that? This is a multi-billion dollar gamble being executed in front of the public, egregiously breaking the law or making back-room deals both risk extreme negative public reaction if exposed.
We know that eventually a self-driving car will hit somebody and kill them. Waymo and other companies are prepared for that.
reply