That is to say, a theoretically ideal OS running on the A16 could run every mainframe program in existence until the late 1970s, simultaneously.
I still regularly use old systems for fun. I grew up with Macs, so that’s the point of reference. When I use these old systems, I pine for a few specific things I’m used to on newer systems—but it almost feels like nitpicking.
The things that I really want from a computer are pretty basic. Like good, consistent copy/paste and drag ’n’ drop, good autosave, good file browser, that sort of thing. It seems like new, half-baked stuff got dropped in our laps before the basics really got perfected.
It also kind of drives me up the wall when you see what was being done on computers in the 80's and 90's on sub 100Mhz processors and realizing just how much efficiency has been lost in the name of ease. Excel shouldn't need to use all 12 threads of my CPU and visibly take time to sort less than a 1MB of data but here we are.
I have been working on an essay regarding Permacomputing for the last few weeks and it can be kind of difficult to summarize at times. The closest I can get is that it is part retrospective about want worked in the past but with the direct goal of implementing the goals long term sustainable systems that do not require large external inputs.
Maybe there is the possibility to trim down a package like that into something akin to what we had in the 90's but, funnily enough, there is a lot of that 90's legacy that was stacked onto, it looks like there is just too much legacy in it to make that a viable path.
Microsoft gets pressure from their hardware partners to keep up the hardware replacement cycle, and they themselves of course get a cut of that via OS licenses.
Phone manufacturers seemingly invented "Always On Displays" to also cause people to start to think they needed a new phone or battery just a year/18 months into owning their device. Christ what a waste of power for such little value delivered! My wife said her new S23+ would barely last a day - so I turned off the always on display option, and now it lasts 2.5/3 daysish of normal usage.
It's a slightly different story with laptops, where battery life is an important feature. You'd think battery life would be important for phones too.
Also nice that they've finally added an option on Samsung phones to only charge to 85%, but it would be nice if it had smarter options like on iOS. Eg, an option to charge up to 100% just before you expect to wake up, so you have the full charge but it doesn't sit at 100% all night degrading the battery.
Upgrades will be forced via software obsolescence rather than hardware performance.
This is why I think the Linux/Free-Libre software folks would do well to focus a bit more on optimizing performance as there is a lot of room for improvement that will not need to be forced onto people.
Instead of their high-powered development machine with the latest CPU, tons of high speed memory, and the fastest SSD; they would get to experience what many of their customers have to endure on slower hardware with capacity constraints.
Nothing spurs optimization like seeing first hand how your code creeps along on slow hardware.
We had few surprises when some newbie dev noticed that the site doesn't work quite as well outside of 1Gbit connection with 1ms ping to the app server...
I5 Gen 3, 500g HDD and 8gig of ram.
Yes, outlook runs fine for the secretary, visual studio not so fine for debugging.
What I was saying that if the developers ONLY run their software on their high-powered computers and never try it on slow hardware, they generally resort to the 'it runs fine on my machine' response when customers start complaining about performance.
That is exactly what I do with my desktop product. I test it on really crappy hardware first.
On the Ps3 side, I had completely forgotten just how hamstrung it was in terms of memory, the OS and the load times on games are SLOOOOOW! And yet, they got Uncharted 3 and Crysis 3 out of that thing.
One of the most impressive feats I have seen would have to be Daytona USA 2 in the arcades. That thing is running on a single 166Mhz PowerPC 603 and a Real3D GPU that still needed all the polygon setup done on the CPU. How they got that out of that hardware is just beyond me. It is optimised to the max!
I guess you would get a similar state in some embedded systems. The folks at NASA working on the Mars Rovers have a set target and are usually targeting mid 90's MIPS or PPC processor so they have to be fixated on speed and performance.
Like it or not, computation is cheap and developers are expensive. Code isn't worth optimizing until it either becomes a bottleneck, or you are running it on thousands of machines.
Can’t you write closer to optimal code to begin with? With experience can’t you start with learnings of the past? A lot of things are easy and convenient to do now but people like you just parrot about not needing to optimize so as to not do it at all.
Maybe instead of thinking if it’s expensive or cheap think about actually wanting to do something decent? Or is everything fake and just a transaction?
The problem is programs that are running on thousands or millions of machines but don't get optimized, because the customer runs the program and pays the costs and it's hard for them to blame any program in particular.
This is a well-known fallacy. There's no guarantee your performance problems have a single bottleneck. In fact, more often than not, your entire program is poorly thought and the only way to fix it is a full rewrite, with the associated risks.
> When I was teaching, I often used this metaphor: suppose you’re writing some system, you decide that you should avoid premature optimization, so you take the usual advice and build something simple that works. In this metaphor let’s pretend that your whole program is a sort. So you choose a simple sort that works. Bubble Sort. You try it out and it functions perfectly. Now remember Bubble Sort is a metaphor for your whole program. Now we all know that Bubble Sort is crap, so you have to eventually change to Quicksort. Hoare likes you more now. So how do you get there? Do you just, you know, “tune” the Bubble Sort? Of course not, you’re screwed, you have to throw it all out and do it over. OK, except the greater-than test, you can keep that. The rest is going in the trash.
> But you got valuable experience, right? No, you didn’t. Anything you learned about the Bubble Sort is worthless. Quicksort has entirely different considerations.
> The point here is that a small bit of analysis up front could have told you that you needed a O(n*lg(n)) sort and you would have been better served doing that up front. This does not mean you have to microtune the Quicksort up front. Maybe down the road you’ll discover that part of the sort (remember this is a metaphor) should be written in ASM because it’s just that important. Maybe you won’t. There will be time for that. But getting the right key choices up front was not premature. There is a suitable amount of analysis that is appropriate at each stage of your product.
https://ricomariani.medium.com/hotspots-premature-optimizati...