Brilliant Hardware in the Valley of the Software Slump

Spectre/Meldown & friends are just the tip of an iceberg. We have layers & layers of indirection/abstraction everywhere. We have hardware that lies and tells you that it has certain properties when in reality it doesn't (example: sector sizes in hard drives/NVMs, processors still pretending that they behave like PDP-11), we have hardware that is flat out broken. We try to fix those issues in software.

But in the software, we have another dump of workarounds, dependencies, abstractions with a sprinkle of backward compatibility. We are now creating "minimalist" applications with a fraction of functionality of the software from 30 years ago but using so many layers that total amount of code used to make it work is many orders of magnitude larger than what we had back then.

I know that most of the programmers did not work with systems where it's very, very easy to debug the whole stack and you can learn it in a short period but it's amazing when you have knowledge about EVERY part of the system in your head.

There are some good things going on (like strive to replace C with something which has similar performance characteristics but without its flaws) but it's not enough.

Here are two things worth watching:

https://www.youtube.com/watch?v=pW-SOdj4Kkk - Jonathan Blow - Preventing the Collapse of Civilization

https://www.youtube.com/watch?v=t9MjGziRw-c - Computers Barely Work - Interview with Linux Legend Greg Kroah-Hartman

Running on an Atom-based SBC I had on the workbench, it's even more responsive.

Yes, building native apps requires at least a basic knowledge of C++. No, it won't seamlessly run the latest React SPAs as well as Chrome. The driver situation isn't as good as (say) Linux or FreeBSD.

And yet, the focus on providing a productive environment for normal computing tasks instead of endless up-selling to an app store, countless background updaters, and vendor-bundled crapware is like a breath of fresh air.

This is what we've lost in the move to impose ever more layers of services, unique per-app GUIs, and ubiquitous (even gratuitous) packaging of "webapps" in lieu of targeted, native apps.

To be clear: this isn't a unique property of Haiku. A nice clean install of FreeBSD or Debian has many of the same properties, and I have reason to believe that a Windows 10 "distro" based on something like Server Core could be similarly light and responsive.

Unfortunately, the major platform providers seem deeply uninterested in building systems that don't push you aggressively towards newer hardware, loads of subscription services, and "strategic" software bundles no one asked for.

My #1 frustration as a Windows user is that every so often an applications or the whole system freezes up for a few seconds. I use MacOS sometimes and also Linux and I don't think either one is much better.

For instance when I launch a command prompt often it is up in <1s, but sometimes it takes 10s. That's a very simple program, but often there are security checks involved; even ssh logins to a linux server on a LAN have a long-tail distribution in time-to-prompt because maybe some daemon was swapped out.

I would be satisfied I had some visual indication that progress was happening (ALWAYS AND <100ms LATENCY) and some insight into the process (e.g. real progressbars... if hadoop can do it, why can't pandas?)

We don't want to trouble people with details, but what's the harm in telling the user we are waiting on a 30 second timeout?

I think this trend will continue, sadly, until a crafty company is able to steal 1B of revenue from a flaky incumbent by building a reliable and fast version of a core utility.

I am reminded of the early google.com homepage. I can remember setting it as my default homepage in IE because it got to the point that Yahoo would take MINUTES to load, if not just crash the browser.

Or maybe we need hardware to just suck again, to force the issue.

If you're trying to move your full desktop workflow to a platform that only added the option to work that way recently and as an afterthought compared to its original use-case, you're going to be catching bugs for quite a long time. If you're unlucky, your particular use-case for that hardware will never catch on enough for the value of working out those kinks to outweigh the cost.

I know techies like most of us on here love to be early adopters, but you have to draw a line between using tech as a toy and using it as a tool. If you're using something that you don't expect to be stable 99.9% of the time, odds are that it's a toy and you should hold your expectations a hell of a lot lower for any sort of productivity.

Startups are incentivized to move fast and break things, and then to keep adding to their broken prototype instead of rebuilding the product, because it's more affordable.

OS vendors benefit from lock-in and hardware is fast enough that the vast majority of consumers don't notice. If something breaks, you just take it to the Apple store and they reset it. It's cheaper for everybody involved.

Online ad vendors have no incentive to create a less-than-terrible web experience because it's not their site that's being trashed.

On top of it all, there's no regulatory or institutional quality standard. It's left to be a race to the bottom.

I don't know what the fix is, or whether there is one at all, but we should at least stop being surprised. We shouldn't really be blaming it on "kids these days" either, which is an all-too-common refrain. There simply isn't a business incentive to invest in quality.

I feel both angered and embarrassed at software inefficiency. Trivial Electron "apps" require 1-2GB + of ram. Seconds of Input latency like typing on the keyboard or when pressing a button. Not to mention the gigawatts of electricity and gigatons of CO2 being wasted server-side on poor code , logging, encode-decode & other nonsense.

My desktop experience peaked on Windows 2k and has been declining rapidly for the last 10 years.

> What baffles about these software moans is that Apple’s hardware is ever-more refined. While far from flawless, the entire lineup is now (finally) largely free from these “foundational” issues you see in software.

The answer to this is very simple (at some level): It is impossible to produce mechanical designs that are the equivalent of the software engineering abominations the world is stuck with today.

Going back to iPhone 3 days, I remember coding a genetic solver in Objective-C that was an absolute dog. I optimized as much as I could and could only squeeze so much performance out of it.

I finally gave up and re-coded the entire thing in clean C++. The code was somewhere in the order of 290 times faster. Objective-C was an absolute dog because, at a minimum, every data type you had to use was an object oriented mess. This was absolutely unnecessary, the proof of it being that my C++ equivalent performed exactly the same function and lacked nothing. In fact, it was so fast that it allowed the use of this genetic solver in real time in the context of this app. Objective-C, er, objectively speaking, had no reason to exist. Yet, it did, and lots of people believed it had to exist and likely many do today. They are wrong.

Another way to look at this is that the clean solution used somewhere in the order of 200~300 times less energy. This is something hardware engineers are keenly aware of. Software consumes energy and badly written software is even worse. Think of it this way: A bit transition costs energy. Inefficient code requires more bit transitions per unit time, therefore, more energy and more power dissipation.

Imagine the mechanical engineering equivalent. Some monstrosity where, instead of using a simple screw and a nut one ends up using a complex fastener that has layers upon layers of mechanisms and unnecessary complexity. A screw with the ability to grow and shrink to any length and diameter, including all the wrenches, tools, nuts, washers and devices needed to install, tighten and test them. Very quickly a simple product that could mechanically fit in the palm of your hand would quickly become the size of a car.

And so, in this way, mechanical and industrial design is always "low level", like always coding in assembler (not proposing we do that). Sure, materials and manufacturing techniques improve, yet, at the most fundamental level, excellent mechanical and industrial design is clean, uncomplicated, easy to understand and easy to manufacture. It's machine language, or C. Not Objective-C.

Software engineers who are not exposed to this reality, through no fault of their own, are not aware of these issues. I don't blame them. If most of what someone sees in school amounts to Python, their view of reality will be skewed.

My son is studying Computer Science at one of our top universities and has less than a year to graduate. He is home now for both the summer and due to the virus. I've been working on several embedded projects and showed him a few tricks to improve performance. He was amazed to see how you could optimize code for execution speed (with sometimes dramatic results) by making simple high level choices. For example, a down counter in a "for" loop ("i=10; i!=0; i--") is generally faster than the typical up-counter: "i=0; i<10; i++". This is due to the fact that processors have instructions like "DJZ" or "DJNZ" (Decrement and Jump if Zero / Decrement and Jump if Not Zero) that don't require loading a comparison value and engaging the ALU and sometimes even fetching that value over and over again from memory.

Software engineering doesn't have the same physical constraints found in mechanical engineering unless someone is coding for an application and a domain where excess really matters. One example of this is writing code for space hardware, where, aside from reliability, you have to be aware of the fact that every bit you are flipping will cost a quantum of energy and you might not have enough to be careless about it. Energy quickly translates to mass in the form of large cooling radiating surfaces that must be launched into space along with the hardware.

It's an interesting problem this issue of bad or bloated software. Not sure if there's a solution. There won't be until there's a forcing function that requires a change in perspective and approach.

EDIT: To be clear, my point isn't to pick on a specific language or languages but rather than use easy examples to highlight one of the problems that has been building up since the introduction of object-oriented programming. I remember the early days of OO. It was a mess. Much like the early days of desktop publishing where people loaded-up documents with every font they could find.

For home office I pretty much use their software constantly: Office 365, Teams, SharePoint, VSCode, and it’s not just rock solid, but pretty enjoyable as it is rock solidly integrated together.

Would never have thought I’d say MSFT having rock solid anything, nevermind on a Mac, but credit where it’s due.