Hacker News new | past | comments | ask | show | jobs | submit | mixermachine's comments login

Your Macbooks no longer receive (security) updates. They already have missed three MacOS releases: https://eshop.macsales.com/guides/Mac_OS_X_Compatibility

Please don't do anything security critical with them.

Other OS providers do support the devices longer. At least for core OS updates.


The last security update to Monterey was in July 2024.

9 years of OS support seems pretty good to me.


> Other OS providers do support the devices longer. At least for core OS updates.

Microsoft is abandoning 63% of its user base later this year, with an untold amount of those users unable to update to Windows 11 due to the requirements of a processor released after 2017. Keep in mind that with how the average Windows user buys their device, it's common to see brand new computers with two years old CPUs. With the pandemic having forced everyone to scrape the bottom of the barrel for laptops, there are so many people getting bitten by Microsoft right now.


...so far, yes. But somebody has to pay all of that new network traffic and cpu cycles ;).


I'm sure it's one of the biggest questions asked by the Sonos C-suite: how do we get recurring revenue or make the moat wider. But that goes for every product company in the world.


Reminds me of an old Java Android project I encountered.

EVERY class implemented an interface. 98% of interfaces had one implementation.

Every programmer was applying a different programming pattern. A lot of abstractions seemed incomplete and did not work.

Proguard (mostly used for code obfuscation for Android apps) definitions were collected in the top module even though the project had multiple modules. Half of the definitions were no longer needed and the code was badly obfuscated. Problems were solved by continuesly adding classes and checking what sticks.

The UI was controlled by a stateful machine. State transitions were scatter everywhere in the code with lots of conditions in unforeseen places.

Legacy code was everywhere because no one wanted to risk a very long debugging session of an unforseen change.

No API definitions. Just Maps that get send via REST to URLs.

By biggest mistake was to not directly rewrite this project when I entered the team. We did after one year.


Simple for a developer sure. Just have a look at what entrylevel developers do (no hate, everybody starts somewhere).

This group of people is willing and ready to learn but you still often hear "just checkout the project again" when a problem is encountered.

Most people just use an app and are fine with that functionality. My partner and I use a Google Keep list that is shared between our accounts. Live editing included and it does everything just fine.

There are more elaborate app solutions out there that do more and solve most of the problems.


Got to say, Fritz!Box really makes the setup and maintenance easy. You will hit a wall if you want subnets and stuff but before that everything really works and they support their boxes for 6 to 10 years with updates. Not cheap thought.


Agree. Better stay neutral and not bind software to religion or politics.


Please read the article more careful. The author compares v11 and v10 of the Tesla software. v10 directly displays the defroster button. v11 does hide it behind the temperature control (which is criticised).


I read the article carefully, especially the bit where they discovered after driving it that the UI had changed.

Their initial reaction was on not being able to find the button after five minutes of driving it, which is what my comment is about.


I have driven quite a few different cars, and I have never had trouble finding the button by simply scanning the actual visible controls, except in a Tesla.

(Some cars don’t gave have a defogger, in which case one will obvious never find the button. This is unlikely in a current or remotely recent production car…)


Do you know what kinds of cars exist where you don't have to inspect the UI before you begin driving to make sure critical features haven't moved?

All of them except Tesla.


Most likely you have the Exynos CPU? I upgraded from a S21 Ultra (Exynos) to a S23 Ultra (Snapdragon).

Battery life is so much better. I use the 80% battery protection option and nearly always make it through the day. Only if I constantly watch videos the battery is flat in the evening.

With power saving and 100% battery I can reach 2 1/2 to 3 days. Loving it.


Doesn't have to be Exynos. The US version has the Snapdragon 8 Gen 1, which had heating and battery drain issues. The Gen 2 solved these issues.


The Snapdragon 8+ Gen 1 solved it by switching to a better TSMC node. The Gen 2 increased performance (on the same node) and got again somewhat less efficient.


Popping some cheaper drop in replacement chips in an already existing product sounds quite cost effrctive to me :)


If you use apps that require security (like payment apps) you might run into problems here. My company might need to exclude phones like this one soon because more and more CVEs are coming up. Alternative ROMs are often not the solution here because Play Integrity and Key Attestation no longer work.

For general messaging and browsing this hardware likely work quite well.

Btw I had the Motorola Defy and flashed it every month with a new ROM back in the days :D


I wouldn't use the phrase "require security" to describe such apps, since to fulfill what they actually require, you often end up being less secure. For example, most such apps will be fine with you running them on a phone with 20 critical CVEs from a year ago, but not on a phone that you unlocked the bootloader of to install a version of Android that fixes said CVEs.


The challenge is trust, can you trust that an third party ROM hasn't been tampered with, and that third party maintaining the build for your device is often some guy on the internet you probably only know as a pseudonym. It might be the latest version, it might have some modifications that 'distro' of ROM applies to all their builds, some required per-device changes to make it work, but what degree of confidence is there that nothing else changed and the OS is lying to them?

The same applies to most open source efforts, but I think it's understandable for institutions with consequences to what their apps do (like handling money and bank accounts) to opt out of potentially being undermined by the OS when they have the means. There's also elements of phones being general purpose computers now vs locked down appliances, GPL3 vs tivoization, and so on.


But if you're going to worry that a custom ROM might be compromised, shouldn't you also be worried that you know that the stock ROM contains unfixed critical security vulnerabilities? Wouldn't any reasonable argument to forbid the former also forbid the latter?


There are cases every day where an employee of a company can demonstrate that A is at least as good as B, but trying to get permission to do B is impossible.

There's simply no universe where an employee at a typical F500 company is going to be able to convince the IT team that they should permit custom code on phones even if the logic of the argument is sound. Even if they found the person, persuaded them, got them to persuade their management, in house legal teams, compliance teams etc., I seriously doubt whether the MDM solutions (eg InTune) would even have a checkbox to override the policy on one phone. To say nothing of the ongoing cost of tracking that one employee's specific setting.

This also plays a bit into the argument of why integrating your personal device into the corpo ecosystem of your employer is not a decision to be taken lightly.


> There's simply no universe where an employee at a typical F500 company is going to be able to convince the IT team that they should permit custom code on phones even if the logic of the argument is sound.

That's my point: I know that's how it is today, but the reasons for it being that way are illogical.


I'd say when something like a bank is involved, they need something more substantial to point at for their insurance arrangements if/when something goes wrong. "Our app allowed a $5000 transfer on the user's stock Samsung" is easier to grasp the state of the system they're playing in than a user modified one.

Also knowing what security risks are in play with N year old OS lets them decide if they want to allow the user to proceed or work around. Some applications are more aggressive in what version OS they need and that's a driver for upgrading phones, pushing the OEM to keep a phone in support for longer, or third party ROMs if this catch22 wasn't part of it.


> I'd say when something like a bank is involved, they need something more substantial to point at for their insurance arrangements if/when something goes wrong. "Our app allowed a $5000 transfer on the user's stock Samsung" is easier to grasp the state of the system they're playing in than a user modified one. Also knowing what security risks are in play with N year old OS lets them decide if they want to allow the user to proceed or work around. Some applications are more aggressive in what version OS they need

I've seen plenty of apps need a minimum major version of Android, but never any that have needed a minimum security patch level.


> If you use apps that require security (like payment apps) you might run into problems here

Works fine for me, two banking apps and two digital ID apps running on a Google-free device. About those CVEs, you do realise LineageOS offers OTA updates? Not everyone will install them but the same goes for vendor updates, probably even more so since those sometimes sneak in unwanted 'features'.

If 'your company' 'might need to exclude [my devices]' I will just steer away from 'your company' just like I steered away from the many 'Windows only' companies. I survive, nay I thrive without having to use Windows and the same goes for Google et al.

Nae kings, nae lairds, nae quinns, we are free men!


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: