981–990 of 1001 posts
Earlier quoted context omitted.
Extraordinary claims require extraordinary evidence.
I’m mostly talking about their iPhones, where new updates sometimes make older models worse. I know a lot of people whose iPhones started lagging after iOS updates.
Earlier quoted context omitted.
I have never owned an Apple product that didn't slowly get worse over time. After a couple iPads and MacBooks, I'm almost certain they are intentionally updating their operating system to slow down older products. Even worse is the removal of access to certain applications for older hardware in the name of security or compatibility. Meanwhile my Linux laptop continues to get faster every year as the operating system…
This may be true (not perceptible w/ my apple silicon Macs), but the important thing is that they get slower more slowly than my wintel gets slower (I blame disgruntled Windows and/or nvidia drivers devs....)
I know they are a phone company, but I think they should focus on local models software, not only hardware.
their strength has been hardware for over 30 years now
Apple still has the best hardware so I moved to it for the last few years, but the closed software ecosystem is terrible for taking advantage of it. I wasn't able to debug network errors (restartin my Mac worked), Metal was missing low level disassembly / debugging tools (there is some hard to use UI), but the worst thing was the inflexible windowing system. Even getting all the window handles on all screens/desktops…
I don't understand how absolutely basic things are not possible on Mac OS. Switching between two windows easily, displaying hidden files in the finder... These things would be way easier to solve than building the next generation hardware.
Between windows in a program is command+~
Earlier quoted context omitted.
> a little sluggish > surprised by how quick it felt Aren't these properties of the (G)UI rather than of the processor? I've been using systems 20 years ago that were super snappy. The same software would still be snappy today obviously. But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish. In principle you don't need 32-core GHz CPUs to…
> " the software has become bloated " Casey Muratori has a 20 minute talk on YouTube called "Clean code, horrible performance"[1]. Using an oft-repeated example in C++ he rewrites it uncleanly and then benchmarks. Removing Classes/subclasses/polymorphism: 1.5x faster. That overhead was like reducing an iPhone 14 to an iPhone 11 performance. Replacing Encapsulation with a table-driven calculation: 10x faster. That ove…
Software is a tool working within a socio-technical system. Some systems have low user workflow diversity and a low rate of change - a game being a perfect example. Games get patched, but the diversity is purely in user data, not in feature use - everyone uses the same engine, the same textures, the same game logic. Some systems have high user workflow diversity - such as business software.
Pair that with the fact that games, due to the nature of the system, have to optimise for low latency AND they run on the edge - and it's natural that the primary optimisation will be for CPU cycles. For business software, for which distributional advantage of running it through web + the high rate of feature change that is a result of the specification being opaque and a moving target - means you have plenty networking latency that can hide your CPU latency for long after it becomes a true problem for you.
Not to mention that "clean code" optimises for developer churn and business priority shift (which is a luxury games which are an upfront investement don't have) as a result of accelerating industry of software technology and greater saturation of developers.
Had software remained the domain of the same number of practitioners such as I'll leave as exercise for the reader what pushing AI into the software development equation does for the system and inevitable hardware throughput implications.
Earlier quoted context omitted.
They aren't a phone company, and haven't been ever. They're a hardware company first
More like an "ecosystem company". It's the Hardware, Software and Services in combination. None would work without the other (to reach the scale apple is)
Earlier quoted context omitted.
I agree with you that this is a noticeable effect, but I have a hard time figuring out why it is, especially on Macs with the sealed system volume (which should make the operating system files bit-for-bit identical between a freshly set up Mac and one you've been using for years). Certainly it could come from the accumulation of cruft in /Library and ~/Library, but you can clean that up too.
One reason is the ssd. A heavily used ssd is just slower than a new one.
Phase change thermal pads help with this, extending that timeline out beyond 5+ years but still will eventually degrade.
There's all kinds of other hardware things we don't usually think about that can start having an actual performance impact after ~3-5 years too. Battery, obviously, as it degrades can limit your peak wattage, the power delivery capacitors lose capacitance over the years and develop more resistance impacting maximum clock states, fan bearings wear out, you get vacuum leaks in copper heat pipes, and micro-fissures in soldering.
Granted, most of it is going to be software but its easy to forget that hardware degrades, and degrades relatively quickly especially in higher power systems.
This is why repairability and user serviceability is so important. If you can't open up and swap parts in your machine easily, a $10 consumable turns it into $2,000+ ewaste.
Earlier quoted context omitted.
> In principle you don't need 32-core GHz CPUs to move a window around on a screen without it feeling sluggish I think the snappiness is less this, and more about the speed to open a file, how quickly chrome pops open when you open it etc. I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too.
> I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too. That is exactly what I'm talking about. Sorry, you are completely off. My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window. What does this have to do with SSD? Or an SOC? It's all because the software is incredibly bloated, a…
I never understand what people exactly mean by claims like this. I very vividly remember double clicking some executable, and then immediately hearing the HDD start to spin, and waiting with baited breath to see if it will spawn a window or silently fail, as programs on Windows 98 (the only option for personal computers at the time) often did.
So what exactly was snappy? Nothing that runs off a HDD is ever snappy.
Earlier quoted context omitted.
> a little sluggish > surprised by how quick it felt Aren't these properties of the (G)UI rather than of the processor? I've been using systems 20 years ago that were super snappy. The same software would still be snappy today obviously. But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish. In principle you don't need 32-core GHz CPUs to…
> " the software has become bloated " Casey Muratori has a 20 minute talk on YouTube called "Clean code, horrible performance"[1]. Using an oft-repeated example in C++ he rewrites it uncleanly and then benchmarks. Removing Classes/subclasses/polymorphism: 1.5x faster. That overhead was like reducing an iPhone 14 to an iPhone 11 performance. Replacing Encapsulation with a table-driven calculation: 10x faster. That ove…
Does my web browser feel slow because of pointer indirection or virtual function calls? Or is it because I have to download 15 MB of Javascript to load this page, which then goes out to 35 other domains to fetch other Javascript and ads and CSS?
In the insanely tight compute loop that he's looking at all of those things definitely make a difference, but a lot of software is slow not because it's inefficiently written (which it probably is) but because it's inefficiently designed and it's doing too much.
In a game engine, where you have 16ms to do 100% of your simulation work, update all your state, and then send all the data out to be rendered, definitely this sort of thing is an issue. In an Electron app? There are a thousand other things that are wasting far more of your time and responsiveness than the misguided 'cleanliness' of your code.