Preventing the Collapse of Civilization [video]
youtube.com
youtube.com
I now expect my computer to stay on for months without issues. I expect to be able to put it to sleep and open it in the same state it was. I expect that if a website or a program errors, my OS simply shrugs and closes it. I expect my OS to be robust enough so that if I enter a usb or download a file I'm not playing Russian roulette that it might contain a virus that would destroy my computer.
In the past I would close my computer at the end of every day because otherwise it will simply crash some time in the night. I would run de fragmentation at least once a month. Memory errors and disk errors were common, and the OS had no idea how to overcome it. Crashes were so common, you just shrugged and learned to save often.
DOS was rock solid, at least around the era of DR-DOS. DESQView 386 was absolutely stable too. The BBS software I ran on them in those days was a wobbly piece of shit though.
I also recall Borland's Turbo Pascal compiler and the accompanying text-mode IDE being ultra reliable.
After DOS I've used OS/2 which was also extremely stable, although suffered from limited hard- and software availability.
Mac OS X used to be rock solid too in the heydays of the Powerbooks and earlier Intel Macbooks. Every now and then there were hardware design flaws though, and now the quality of both soft- and hardware seems to have taken a tragic turn for the worse.
You still do play Russian roulette whenever you plug a USB device into your computer, see "USB Rubber Ducky".
DOS was rock solid because it did nothing. Many programs, particularly games and anything that did networking, didn't even use DOS interfaces—they bypassed them entirely and worked with either the BIOS or hardware directly. There was no memory protection, no multitasking, and, on a higher level, no permissions nor sandboxing. So while maybe it "just worked", I wouldn't call it robust.
Modern OSes can run arbitrary binaries, but they can pretty much run arbitrary non-adversarial binaries - problematic binaries have to be intentionally written to exploit the system (as opposed to DOS, where non-problematic binaries had to be intentionally written to not break the system).
It's a dramatic improvement.
Mostly. Modern OSes strive to run abdersarial binaries, but where they can do it safely or not is still in question, IMO.
Since 2008, it's been a dramatic departure.
Boy, that's not how I remember DOS. I remember playing with all kinds of variants of driver load order in config.sys and passing obscure arguments into himem.sys to avoid odd hardware conflicts and crashes.
This hypothetical 32 bit DOS could've had memory protection and multitasking too. Obviously device drivers would add complexity, but it doesn't need to be as complex as it's become.
On the other hand, the stuff that takes "gigabytes of disk and memory" isn't even part of the operating system kernel, so there's no need to start from DOS to get rid of that stuff. It's possible to run linux from a few megabytes of ram.
You're missing the point. There is no single file operating system for desktop users (maybe VxWorks or some other embedded OS falls into that category, but those aren't really for desktops). Modern operating systems sprawl all over the disk. Memory protection and multitasking are not large features, and CS undergrads all over the world routinely implement them in less a semester.
> It's possible to run linux from a few megabytes of ram.
A few megs of ram and a directory in /etc filled with startup stuff and config files. Clearly you don't appreciate it, but there was something really nice about being in the root directory and seeing only command.com and config.sys. The entire rest of the machine was yours to setup however you liked. The things most people hated about DOS really had more to do with the 16 bit address space and segmented architecture.
DOS had other files besides those, but they were hidden https://en.wikipedia.org/wiki/List_of_DOS_system_files
You could theoretically make a linux kernel will all the drivers you need linked + basic FS stored as a drive image so you would have fewer files on an image
http://wiki.freedos.org/wiki/index.php/Main_Page
The "rubber ducky" attack is, of course, also possible with PS/2, XT, and even ADB keyboards, because none of them were authenticated.
It pales into insignificance compared to what I have to do to keep a desktop Linux box behaving normally today. Every few weeks I'm having to paste a wodge of lines into a range of config files to fix whatever driver oddity or system resource issue has caused something to break this time. That is pretty unimaginable without the internet.
The nightmare started again with Windows XP, then I switched to Ubuntu which was reminiscent of Windows 2000.
A funny thing and proof of solid interfaces in Windows 3.1/3.11 and Windows, is that people were making their own versions by removing/adding components and sometimes even changing their content with hexadecimal editors.
There is still a fandom for old Windows versions out there.
And you could catch viruses literally by hand by looking in kernel files, checking their size, and checking what was loaded in memory.
I remember that time with great pleasure.
The only reason why Windows was so buggy for you is that you were using the home editions. At the same time that you were experiencing blue screens in Win 9x. My NT workstation was rock solid without any of the issues you described.
In the subsequent months/years with NT 4, the situation did not improve. It was a sad day when they replaced the HP/UX section of the lab with more NT machines. They were faster but they crashed a lot. It really took until Vista before NT was reliable.
Most notably: graphics and printer drivers, which are not typically written the highest standard.
Big iron vendors don't really have that problem, since they typically control their hardware as well. Microsoft had to rely on component vendors to provide driver software and couldn't plausibly test all permutations under all conditions (even though they test very, very many).
>> At the same time that you were experiencing blue screens
>>> first time I used Windows NT 4
For the 3.11/95 period, I was talking about NT 3.51 not 4.
Yes, NT 4 had well known issues with poor quality graphics drivers. For this reason many of us stayed with 3.51 until the graphic driver problems were ironed out.
You can cherry pick unstable OS's from any time period. But there is nothing special about today's OS's or programs. I've seen DOS, multiple forms of UNIX in the 80's and 90s that are just as stable as today's Win 10 or OS X.
The early 90's Sun's and SGI's didn't crash much either - though in a dev shop, sure we could push them to panic from time to time. The bigger iron just ran indefinitely, often until OS upgrade. :)
Now obviously this talk is game related, but even my previous Amigas were more reliable for uptime if you stayed within Workbench - often passing into months - than DOS and Windows. The mostly undeserved reputation of Amiga for constant crashing was from games hitting the hardware direct and those guru messages instead of silent freeze or pretty random colours that other platforms gave.
All were online, though not much web yet - mainly ftp, newsgroups and dial up BBS's.
I still have the habit of constantly hitting cmd-s everywhere, it’s a reflex I’ll probably never unlearn. I also cringe when I see people working on a bunch of files which have not been saved for a while or, god forbid, not at all. Completely irrational but it’s what I’ve been programmed to do for years ;)
Today, I can reliably crash my Mac (10.13.x) by switching Spaces twice in a row quickly.
A decade ago JavaScript developers had little or no trouble working cross browser, writing small applications, and churning out results that work reasonably well very quickly. It isn't that cross browser compatibility had been solved, far from it, but that you simply worked to the problem directly and this was part of regular testing.
That older generation did not have the benefit of helpful abstractions like jQuery or React. They had to know what the APIs were and they worked to them directly. The biggest problem with this is that there weren't many people who could do this work well. Then shortly after the helpful abstractions appeared and suddenly there was an explosion of competent enough developers, but many of these good enough developers did not and cannot work without their favorite abstractions. These abstractions impose a performance penalty, increase product size, impose additional maintenance concerns, and complicate requirements.
The ability to work below the abstractions is quickly becoming lost knowledge. Many commercial websites load slower now than they did 20 years ago despite radical increases in connection speeds. To the point of the video this loss of knowledge is not static and results in degrading quality over time that is acceptable to later generations of developers who don't know the proper questions to ask.
I am not saying that out of arrogance or some uniformed guess at my radical superiority. I am saying this out of experience. It isn't because I am smart or a strong programmer. This has proven true for me, because when writing vanilla JS I am the bottleneck and the delay. I am not waiting on tools, performance delays, code complexity, or anything else. If there is bad code its because I put it there and I am at fault, and so I have nothing to blame but myself. Knowing this, and I mean as a non-cognitive emotional certainty, means I can solve the problem immediately with the shortest effort necessary or it isn't getting solved ever and that changes my priority of effort. It also means not tolerating a slow shitty product since you are fully in control (at fault).
When people go through project management training I tell them there are only two kinds of problems: natural disasters and bad human decisions. When you can remove blame from the equation the distance between you and the problem/solution becomes immensely shorter.
to me, this sounds like the NIH syndrome, and that those who are tasked with creating new stuff is either lacking in comprehensive education, as well as the "old guards" not transmitting the knowledge in a more permanent form (like a book).
> many of these good enough developers did not and cannot work without their favorite abstractions
i would argue that those were not "good enough", but is "barely know enough". My mantra for using a library is - if you could've written the library yourself, then use it. Otherwise, you dont know enough and using it as a blackbox is certainly going to lead to disaster in the future (for you or some other poor soul).
That is largely my attitude to using any package/library - if the entire dev team gets hit by a bus tomorrow can I maintain this (i.e. keep it working reliably in production), if the answer is no then I nearly always avoid it and if I can't I wrap it in my own layer so that I can replace it later.
I've been an enterprise developer for a long time so my worldview is shaped by "this will likely stick around twice as long as anyone expects minimum" though.
Well, I have to admit he's smart, but the software he writes outside of work is some of the worst I've ever used. Furthermore, I was able to crack his RSA implementation with a straightforward timing attack.
Some things shouldn't be reimplemented.
Perhaps he could have implemented them, then used something else? True, but that's a hard sell.
Between Ajax and JQuery we can build things that are perfectly reactive and come with the added benefit of being extremely easy to debug. They can’t run offline, and if we need to build something that does, then we’ll turn to something like angular/react/ (typically Vue, because we actually use Vue components in our MVC apps from time to time, but which one is beside the point).
When we interview junior developers about this, they often think we’re crazy for not having access to NPM, but we’re the public sector, we need to know what every piece of our application does. That means it’s typically a lot easier to write our own things rather than to rely on third party packages.
It’s several times more complicated to debug something that runs on the clients device than something that runs on your server.
And I also don't think that Jquery is the problem. Jquery just made JS worth learning. Before you had to spend an insane amount of time just working out implementation specifics that changed every few months.
However, the point where I do agree with you is that we have a performance issue with JS. And I am not talking about slow JS engines. I am talking about developers who are not aware of how costly some operations are (e.g. loading a bunch of libraries). Yes, that is an issue that naturally arises with abstractions, but to conclude that abstractions themselves are the problem is wrong.
I think the problem is more about being aware of what happens in the background. You don't have to know every step for every browser and API, but loading 500KB of dependencies before even starting your own scripts is not going to be fast in any browser.
I wrote this following tool in less than 90 minutes 5 years ago because I had some time left over before presentations at a company hack-a-thon. I updated it recently at about another 90 minutes of time.
https://github.com/prettydiff/semanticText
That tool was trivial to write and maintain. It has real utility value as an accessibility tool. I could write that tool because I am familiar with the DOM, the layer underneath. Many developers are not even aware of the problems (SEO and accessibility) this tool identifies much less how to write it. jQuery won't get you the necessary functionality.
I find it frustrating because I do think you have plenty of valuable stuff to say, but you're consistently presenting it in a rather unappealing package and I don't really understand what you get out of that.
I am away from home on a military deployment at this time and I am constantly thinking about what I should do when I return to the real world. I am actively investigating career alternatives by dumping software development, because I honestly believe my career is limited by the general unwillingness of my development peers to address actual engineering concerns out of convenience and insecurity.
I could not agree more.
https://jackmott.github.io/programming/2016/07/22/making-obv...
Notice "Javascript map reduce (node.js) 10,000ms" vs "Javascript imperative (node.js) 37 milliseconds"
I've seen the map reduce way defended as being "more readable and maintanable", with plenty of agreement to it. When I contested it, mental gymnastics ensued and did not let up. Nobody dislikes performance, not really, but I think some don't like reflecting on how they arrived at their opinions. That's the bit they're really invested in.
And in general, "what does this abstraction stand for?" is a very dangerous question, if you ask it about computer stuff, you might also ask it about other things, and there more groups that don't like that than there are people in the world. Not to make this too political, but I think the pressure against thinking for yourself is way, way bigger bigger than the demand for performance. Just think of Ignaz Semmelweis.
Another issue is that many things are hard for us to visualize, as Grace Hopper explains: https://www.youtube.com/watch?v=JEpsKnWZrJ8
Working with the dom in JS wasn't hard, it was just time consuming and required lots of boiler plate code.
JQuery made it quick and easy and cross-browser even if FF was still a small %.
JavaScript itself didn't change AT ALL for years before and after jQuery came out, so I have no idea what you are talking about. Plus HTML 5 was years after jQuery, with html 4 released in the 90s, you've got the wrong recollection of history.
The lack of change was part of what made jQuery so ubiquitous.
So yes, the standards didn't really change during that period, but the real world implementations did. And jquery gave you a way to learn just one thing and don't care about what all those browser vendors were doing.
AFAIK the big thing in IE7 was that it had tabbed browsing, like FF. And slightly improved js performance, that V8 put to shame a couple of years later.
The actual split between IE6/7 and FF was mainly in the Ajax syntax, not the dom, etc.
My impression from what you're saying is that you didn't program js in the 2000s, did you? I did.
Lack of inter-generational knowledge transfer doesn't cut it. Most of the people who rolled this stuff are still alive. And as for the whipper-snappers: people don't get very far writing programming languages/video games/operating systems without knowing their stuff.
The real boogeyman is feature combinatorics. When making a tightly-integrated product (which people tend to expect these days), adding "just" one new feature (when you already have 100 of them) means touching several (if not all 100) things.
Take OpenBSD for example: When you have a volunteer project by nerds for nerds, prioritizing getting it right (over having the fastest benchmark or feature-parity with X) is still manageable.
Bring that into a market scenario (where buyers have a vague to non-existent understanding of what they're even buying), and we get what we get. Software companies live and die by benchmark and feature parity, and as long as it crashes and frustrates less than the other guy's product, the cash will keep coming in.
moved from phone to computer to argue but it was too late
I was having a conversation with somebody the other day about a privacy concern they were addressing, where a company was offering to monitor cell signals for some retail analytics purpose; and it was genuinely surprising to them that mobile phones broadcast and otherwise leak information that can be used to fingerprint the device. I think it's rather shocking the amount of ignorance people allow themselves to have when it comes to things like this. Furthermore, the way she was talking about it, it seems she thought it was the responsibility of basically anyone but the owners of these devices to consider things like this, or even ask the questions that would tell you something like this exists.
Do they? It was my impression that the recent evolution of user-facing software (i.e. the web, mostly) was about less integation due to reduced scope and capabilities of any single piece of software.
> adding "just" one new feature (when you already have 100 of them) means touching several (if not all 100) things.
This sounds true on first impression, but I'm not sure how true it really is. Consider that I could start rewriting this as "adding 'just' one new program when you already have 100 of them installed on your computer"... and it doesn't make sense anymore. A feature to a program is like a program to OS, and yet most software doesn't involve extensive use, or changes, of the operating system.
The most complex and feature-packed software I've seen (e.g. 3D modelling tools, Emacs, or hell, Windows or Linux) doesn't trigger combinatorial explosion; every new feature is developed almost in isolation from all others, and yet tight integration is achieved.
Plugin minimization is mandatory IMO.
Also, core plugin system evolves and majority of the time does not support "older" plugins.
I had this problem in basically any software I used with plugins be it Winamp, Redmine, FL Studio or whatever.
Having plugins means anybody should be able to create one.
I remember vagrant has support for all historic plugins versions no matter the current API version. This is rare goodness but prevents only one type of problem - inability to update the core.
Turns out when you chnage the words of a statement, it changes the meaning of that statement.
https://www.facebook.com/notes/daniel-colascione/buttery-smo...
Same story for speeding up WSL.
https://devblogs.microsoft.com/commandline/announcing-wsl-2/
Or, just think about your phone. If I put my head to the speaker, a sensor detects that, and the OS turns off the screen to save power. If I'm playing music to my Bluetooth speaker, and a call comes in, it pauses the song. When the call ends, the song automatically resumes.
KT's UNIX 0.1 didn't do audio or power management or high-level events notification.
This was a corner case. What I meant is the couple dozen packages I have in my Emacs that are well-interoperating but otherwise independent, and can be updated independently.
> Or, just think about your phone. If I put my head to the speaker, a sensor detects that, and the OS turns off the screen to save power. If I'm playing music to my Bluetooth speaker, and a call comes in, it pauses the song. When the call ends, the song automatically resumes.
These each affect a small fraction of code that's running on your phone. Neither of them is e.g. concerned with screen colors/color effects like night mode, or with phone orientation, or with notifications, or countless other things that run on your phone in near-complete independence.
Most emacs plug-ins aren't operating at that level of interdependence. This one is working on a text buffer at t0, and that other one is working on a text buffer at t1. Of course, the whole thing can be vastly simplified if we can reduce interdependence, but that is not the way the world works. Typical end user doesn't want emacs. Typical end user wants MS Word.
Even if I accepted the replacement of my word "feature" with your word "program" (not that I do), one only needs to look at Docker's prevalence to see the point still holds. Interdependence is hard, and sometimes unavoidable.
I think he means generations in terms of the workplace/politics where you can have a generation change every few years. Meaning that most old guys go and new guys come. Technically you could ask the old guys because most are still alive but it doesn't happen for a lot of different reasons.
I don't agree on his conclusions. The real source of problem is that now we have maybe x100000 more software than we had in 70s. It's that many more programmers, so not just the 1% smartest greybeards as before. We need more abstractions, and yes, they will run slower and have their issues.
Also, not everybody is sitting at the top of hierarchy of abstractions. Some roll up their sleeves and work on JIT runtimes and breakthrough DB algorithms.
All those blocks of software need to communicate with the platform and between them. IMO the way out is open source. Open platforms, open standards, open policies. Every time I found a good piece of code in company's huge codebase, it was open source library. Every time. You have to open up to external world to produce well engineered piece of software. The lack of financial models for open source is the obstacle. We should work on making simple and robust software profitable.
The greybeards from the 70s weren't much smarter than today's programmers. They were the same curious hackers from today, with the advantage of being born in the right place at the right time, when the technology was still developing, so they were forced to build their own tools and operating systems.
> We need more abstractions, and yes, they will run slower and have their issues.
I disagree, and side with Jon Blow on this: abstractions (if done well) create the illusion of simplicity and more often that not hide the apparent complexity of lower levels. Sometimes this complexity is indeed too difficult to work with, but often it's the problem itself that needs to be simplified instead of creating an abstraction layer on top.
I think as an industry we've failed to make meaningful abstractions while educating new programmers on the lower level functionality. A lot of today's programmers learned on Python, PHP, Ruby, JavaScript, etc., which are incredibly complex tools by themselves. And only a minority of those will end up going back and really learning the fundamentals in the same way hackers in the 60s and 70s did.
> IMO the way out is open source. Open platforms, open standards, open policies.
Agreed. But education and simplification are also crucial.
Regarding abstractions, I feel you are talking about leaky abstractions - systems that offer a simplified interface but still manage to burden you with all the implementation details. It's hard to identify such poorly engineered building blocks until it's too late. Thus layers get built on top of them and it becomes too costly to go back and rework the stack. This is a problem with development processes favoring new features over paying the accumulated tech debt.
Still, good building blocks can exist. You can (and often must) have complexity if it's properly isolated and does not leak. I'd say JVM is great example of abstraction that is slower and internally more complex than SW done native, but brings much to the table as a platform to build on. Other examples: BeamVM, ZeroMQ, Lua (leaky, but at least very simple). Browsers unfortunately are too burdened with legacy and security issues.
I feel my formal education has failed to teach me how to design proper interfaces between systems. Instead we are taught pointer arithmetic and mainstream OOP ("cat IS an animal").
I pick on Chrome because the data is available. And because I regretfully have about 8 copies that code on my computer. But I bet we'd see the same curve with lots of modern software. The LOC numbers for microsoft windows have become so large that I can't really comprehend how so many programatic structures can do so little.
I once heard this architecture pattern referred to as a pile of rocks. Piles of rocks are really simple and elegant - you can always add features to your pile of rocks. Just add rocks on the top until its tall enough! Piles of rocks are really easy to debug too. Just shake the pile (unit tests), and when anything collapses, add rocks until the hole is filled in (= patch that specific issue). Then rinse and repeat. You don't need to bother with modelling or proofs or any of that stuff when working on a pile of rocks.
Look at those Haskell programmers over there building aqueducts using archways. Peh. they should get jobs writing real programs.
Ahem.
[1] https://www.openhub.net/p/chrome/analyses/latest/languages_s...
The day after I watched the talk I was compelled to watch the mentioned Apollo 11 documentary. For me this was a great talk, but feel free to disagree.
Was the documentary "When We Left Earth"?
My personal guess at why civilisations can collapse so slowly (100s of years for the Romans, for example) is that the people who maintain the political systems do too good a job, and so the safeguards are forgotten.
For example, after WWII the Europeans learned some really scary lessons about privacy. The Americans enjoyed greater peace and stability, so the people with privacy concerns are given less air time in places like Silicon Valley or Washington. The two-step process at work here is that when things are working, standards slip and the proper response to problems are forgotten. Then when things don't work, people don't know what to do and the system degrades.
Basically there are norms and unwritten understanding, deeply understood ideas about what is not acceptable. Rulers don't push their power to full extent. Then someone comes along and starts to push them and gradually what is acceptable changes.
I was just at a workshop about https://en.wikipedia.org/wiki/Design_thinking. The whole premise was that you don't actually need to hire an (expensive, inflexible) expert, who understands how something is done, but rather what you need to do is to "observe" an expert.
But imagine what happens when everybody does that! Everybody gets rid of their experts, assuming that the client (who they are supposed to provide the service for) has the actual expertise. And they are assuming the same about their clients and so on. The end result is complete disregard for expertise.
So expertise is a positive externality, in an economic sense. Nobody is incentivized to keep it more than neccessary. This leads to losses over time.
Seems like it was a physical engineering and business problem and software was added to (inadequately) compensate.
My IDE stopped providing menus. It’s open source so I just shrug and track the issue in Github.
Portable Apps on Windows are a hedge against some of the angst he describes. (E.g. the part about updates changing a lot of things around or causing failure-to-launch problems).
E.g., I still use WinAmp to play mp3's. It's a portable version, doesn't need installation (so I can use it on my locked-down work computer). The UI hasn't changed in 20 years. Newer file-formats can be played after adding plug-ins.
I've put together a whole bunch of Portable Apps, and nowadays I first try to find a portable version of an app I need before a non-portable version.
I think the real reason software may be more buggy is that good quality software takes too long to develop. There is a big commercial advantage in being first to market.
Constant updates over the web also mean that you don't need to test so much before shipping. You can always send a patch later. This was different when software was shipped on disks.
Would love to see more things in this direction, but, I agree that the market doesn't want it. Most users will gladly accept an infrequent bug for an earlier release, or lower cost version of a product.
Of course you can't do everything, but a good full-stack language could cover perhaps 80% of software needs using well written DSLs. The simple fact that we have so many languages targeting the same thing is a waste and duplicative effort (Java, C#, Kotlin, Scala, Clojure, F#...etc) for business apps and (Python, Matlab, Julia, R, and Fortran) for data science and scientific programming. Also systems languages like (C, C++, Ada, Rust).
On one side it is good to have purpose built languages, but on another it puts a big barrier to entry.
Note that I'm advocating for abstractions, but far fewer languages. Yes, abstractions add complexity, but actually make the code more readable. I shudder to think of humanity having to maintain and support ever increasing levels of software.
That seems like a very healthy evolutionary approach to me.
This is a bit of a contrived and exaggerated example, but it serves to prove my point which is that these things really do scale linearly: you give up the same amount you get back by going up a layer of abstraction (in understanding/productivity, not talking about performance yet). Low-level programming languages aren't more productive than high-level programming languages. Low-level programmers are more productive than high-level ones because it takes more discipline to get good at low-level programming so the ones that make it in low-level programming are likely to be more skilled or, at least, to have acquired more skill. Think about the story of mel[2]. Does anyone honestly think, with any kind of conviction, that mel would have been less productive had he programmed in python and not thought about how machine instruction would be loaded?
As I've mentioned, I have done, and gotten reasonably good at, low-level programming, and yet my current favourite language is perl6. A language that is about as far from the cpu as it gets, on a par with javascript or haskell. Why? Because nothing is lost. Nothing is lost, and quite a lot is gained. There are things I can do with perl6 that I cannot do with c—but, of course, the reverse is also true. And I think that jon blow's perspective is rather coloured by his profession—game development—where performance is important and it really does pay, sometimes, to think about how your variables are going in memory. He has had, I'm sure, negative interactions with proponents of dynamic languages, because he sees their arguments as (maybe that's what their arguments are, I don't know) "c is useless, javascript is good enough for everything." Maybe the people who truly think that have lost something, but I do not think that mel, or jon blow, or I, would lose much by using perl6 instead of c where perl6 is sufficient.
About the second one, performance should be crucial everywhere, if some application eats all the resources then I can't have other applications working in the background doing their stuff. That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc.
Going back some years ago, I was able to run Skype, AQQ, IDE, Chrome browser and Winamp at the same time on archaic (in today's standards) i3-350M and 4 GiB of RAM.
Again, this is a problem with programming design, not programming language. It is very possible to make good, performant programs in fancy dynamic languages, and awful, leaky, slow ones in 'high-performance' compiled languages. The impact of the language itself is really not as high as it's made out to be. Yes, python is 100x slower than c at multiplying numbers, but so what? Your program doesn't spend most of its time multiplying numbers. If you design a python program in a non-stupid way, for an application like a chat app, the performance hit compared to c is negligible.
It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module).
The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware.
This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.
Yeah I think that's part of what he was trying to say
Backwards compatibility and overengineered solutions like SMM or ACPI then UEFI with a confusing standard and an even more confusing landscape where most manufacturers will just write whatever makes Windows XP boot and ship it
It seems to me that there are two different notions here that are being conflated:
. A rotting of knowledge over time.
. A variant of Moore's Law. In this case, the idea that the value of technology, in a particular area, has a decreasing value on the margin.
It's kind of like the notions you see in cliodynamics, that there are a few interacting sine waves (or some other function) in mass human behavior.
I suppose that the main concept of importance is how it all might mess with your own personal situation. Personally, I think that the West is in decline, but that doesn't have a whole lot to do with the quality of software on internet websites.
Wikipedia for example has one nine availability in my life. Because when I sleep my phone is still on.