Flash was the first broken site I ever encountered, some restaurant had an all-flash webpage. Never did end up going to that restaurant. Why bother? If they render content inaccessible behind some needless jank like Flash or JavaScript, why bother? Another fun thing to do was to keep a tally of how many "OMG stop the presses!!" security vulnerabilities Flash had racked up over time, which was lots. Many hundreds. Made even a lolfest like Windows look bad. Flash, it was not killed with fire soon enough. Chrome and other such bloatware arguably also need some sort of fire, or at least a diet or trepaning or something, but that's a different rant, though one very much related to the Old Web or the smolweb.
Neural Networks aren't the best solution for every task contrary to popular belief. For Bach in particular I'm sure lots of pre-NN work is much better.
> I'm not a historian and will not comment on this first part of the talk. It doesn't matter much,
Okay.
> What is robust? ... Is it the multi-year uptimes of a plethora of ...
Big uptime systems are dubious. Probably a lack of kernel patches, hardware patches, and who know if, on reboot, the system will actually boot and start the relevant services correctly. A bank once had their mainframe fail, and they were flailing around for a good long while, possibly because it had been about a decade since their last failure and everyone forgot what to do, or maybe Bob had retired. Or how about that host that boots four years into the future and now various things are quite broken? There was NTP, but an unrelated change had broken that on some firewall. "Normal Accidents" are somehow a thing in complex systems, as are black swan events. Quite possibly either or both were involved in the late bronze age whateveritwas, but naturally history doesn't matter much.
> Oh, and garbage collection and functional programming aren't new abstractions. Lisp did both in the late 1950s
PAIP (Norvig) recounts that the garbage collection was so bad it was turned off and the LISP machines were let run until they ran out of memory, at which point they were rebooted. I guess this is a point for improved robustness in certain areas, though there are probably still "/5 * * * reboot-something" type cron jobs out there for services that leak too much memory. No, management did not grant time to fix that service last I had to put in the most recent five minute reboot script. Many don't get such a intimate view of the rusty bowels of the internet.
> open up a Unix-type command line in Linux/MacOS/*BSD/WSL, type "ed" at the prompt and see how far you get with your text editing
Some wacky systems do not install ed, or link it to nano or some other nonsense, so you may need to actually install ed to get the standard editor. If you happen to be stuck on such a system, `busybox vi` is tolerable—vim gussied up with color spam is not, especially the unreadable blue on the black console—though learning enough about ed might be good if you, hypothetically, ever have to fix an old system over a serial line at 3AM in the morning. There isn't much to learn for such cases, "a" to append new lines, "." on a line by itself to end that, "/foo" to search, "c" to change that whole line (and then the "." thing) and then "wq" to save. Great for edits were you don't want other folks seeing the contents of, say, /etc/hostname.wg0. Or sometimes a cat of the file should be done to preserve it in the scrollback buffer, which has saved a non-zero number of configuration files across the internet. Ideally this sort of disaster training should be practiced by some now and then, but that does take time away from other things.
Back to the unloved history thing. A collapse can take a few centuries, which may be a problem given the recent emphasis on the current sprint or how the stock will be doing Tuesday (as opposed to the lease for Hong Kong, though a hundred years is a magnificently short period of time). So a few folks crying wolf or playing Cassandra might be a good thing to help point out past issues and maybe from that future shocks can be made less bad.
Oswald Spengler also wrote stuff in "The Decline of the West", in particular about the rise of Caesar types at particular moments in the lifetime of civilizations considered as organisms that grow, flourish, and decline. On the other hand, Spengler may have been overly enthusiastic in fitting history to suit his narrative. Spengler was not well received by some, particularily those optimists who believe such things as "rain follows the plow", or whatever that goes by these days. The graph goes up and to the right; therefore, Singularity. These optimists may likewise be overly enthusiastic in fitting reality to a particular narrative.
That why it's ironic that some techno-optimists have embraced Nick Land's philosophy, given that his work fundamentally challenges their core assumptions:
Converging upon terrestrial meltdown singularity, phase-out culture accelerates through its digitech-heated adaptive landscape, passing through compression thresholds normed to an intensive logistic curve: 1500, 1756, 1884, 1948, 1980, 1996, 2004, 2008, 2010, 2011 ...
Nothing human makes it out of the near-future. [0]
I would imagine that the Chinese are good at wonton, though wanton outsourcing of wontons may not be in the best interests of local "pork" spending. Maybe if we had more details on how that whole Bronze Age Collapse went down we might have better ideas of what to avoid, but learning from history isn't very popular.
Fresh wontons travel poorly, and excellent fresh wantons are available at reasonable prices, locally made, even in high cost of living areas like the Bay Area.
When the Industrial Age collapses, and no computers work anymore, we should be sure to write down the reasons on something more durable,,,, this time around.
ping(8) has no particular access to the filesystem, and can only do inet and stdio. At least on OpenBSD. I have a modified version of vi(1) that cannot write outside of /tmp or ~/tmp, nor access the internet, nor can it run programs. Other text editors could easily access ~/.ssh keys and cloud them. Whoops? sshd(8) and other daemons use privsep so that the likely to be exploited bits have no particular access to the system, only pipes off to other portions of the OpenSSH complex.
Maybe if rsync were better designed exploits could be better contained; alas, there was a recent whoopsiedoodle—an error, as Dijkstra would call them—and rsync can read from and write to a lot of files, do internet things, execute whatever programs. A great gift to attackers.
It may help if the tool does one thing and one thing well (e.g. the unix model, as opposed to the "I can't believe it's not bloat!"™ model common elsewhere) as then you can restrict, say, ping to only what it needs to do, and if some dark patterner wants to shove ads, metrics, and tracking into ls(1) how about a big fat Greek "no" for those network requests. It may also help if the tool is designed (like, say, OpenSSH) to be well partitioned, and not (like, say, rsync) to need the entire unix kitchen.
Image libraries have had quite a few CVE or whoopsiedoodles over the years, so there could be good arguments made to not allow those portions of the code access to the network and filesystem. Or how about a big heap of slow and expensive formal verification… what's that, someone with crap security stole all your market share? Oh, well. Maybe some other decade.
A non-zero number of people feel that "active content" e.g. the modern web is one of the worst security missteps made in the last few decades. At least flash was gotten rid of. So many CVE.
P.S. web browsers have always sucked at text editing, so this was typed up in vi yielding a file for w3m to read. No, w3m can't do much of anything besides internet and access a few narrow bits of the filesystem. So, for me, web browsers are very much in the "don't want to access the filesystem" category. I can also see arguments for them not having (direct) access to the network, to avoid mixing the "parse the bodge that is HTML and pray there are no exploits" with the "has access to the network" bits of the code, but I've been too lazy to write that as a replacement for w3m.
David Eagleman has done some work with drummers. Granted the audio system might be a bit more accurate than the visual, or maybe drummers are just weird. On the other hand, vim taking 30 milliseconds to start (ugh) and having sluggish cursor motions is why I'm on vi now. Haven't tried Wayland. Maybe in some number of years once it's more portable and more developed? (And how many years has it already been out?)
> “I was working with Larry Mullen, Jr., on one of the U2 albums,” Eno told me. “ ‘All That You Don’t Leave Behind,’ or whatever it’s called.” Mullen was playing drums over a recording of the band and a click track—a computer-generated beat that was meant to keep all the overdubbed parts in synch. In this case, however, Mullen thought that the click track was slightly off: it was a fraction of a beat behind the rest of the band. “I said, ‘No, that can’t be so, Larry,’ ” Eno recalled. “ ‘We’ve all worked to that track, so it must be right.’ But he said, ‘Sorry, I just can’t play to it.’ ”
> Eno eventually adjusted the click to Mullen’s satisfaction, but he was just humoring him. It was only later, after the drummer had left, that Eno checked the original track again and realized that Mullen was right: the click was off by six milliseconds. “The thing is,” Eno told me, “when we were adjusting it I once had it two milliseconds to the wrong side of the beat, and he said, ‘No, you’ve got to come back a bit.’ Which I think is absolutely staggering.”
$50 million?! That's about three orders of magnitude above where I got off the rat race. With any luck it'll hit a four orders of magnitude, though the Timon of Athens problem is not unknown.
reply