While Microsoft is ending support for Windows 10 completely, Apple is just stopping feature upgrades. Apple usually supports old OS versions for years to come, especially when it's the only supported version for a lot of devices. So no, Intel Macs don't need to be retired.
The most painful parts are (1) it's a bit hot and loud under load; (2) you need to patch modern software like git, likely with little hope to upstream; (3) waiting hours for those "simple" things to compile - which, in the end, tells us something important about what we'd consider "simple" nowadays.
For both retro and previous-generation hardware, security is the most important concern. Patches for PowerPC kept coming until 2011 or so (that's almost 10 years after that particular machine was released). I'd expect the Intel Macs to keep getting official patches until 2030, and in the meantime I wouldn't be surprised to find community efforts to extend that. "Sorbet Leopard" was a thing for PPC Macs, the Hackintosh community is much stronger than back then.
> the Hackintosh community is much stronger than back then
Yeah but they'll be stuck on macOS 26. That's effectively the planned end of that community, they're not interested in running old versions of macOS on PCs.
People are patching newer macOS's to run on older HW (like OpenCore), running older OS's on PCs as they see fit, all Macs allow downgrading (and 10.15 runs on the final 2019 models). I speculate that the community will settle around some version that strikes a decent balance between stability, features, and ease of patching.
Sure, but that community is interested in running the latest version of macOS on a PC. When Apple releases macOS 27 next year, they will have to think long and hard about their next move. Do I buy a Mac to keep my ability to run the latest version of macOS? Or do I tolerate that I'm running an old version of macOS, the first one with the new design that wasn't really finished in that version to boot?
I give it ten years until the websites of that community straight up disappear.
Those are all hobby projects for 20-30yro machines, few of which are left around. There are millions of Intel Macs in excellent shape. Someone will carry the mantle.
We're not talking about Intel Macs. Those are here forever as collectables. I'm talking about the continuing relevance of hackintoshes. Those will soon join the Intel Macs in the annals of history, and disappear as a relevant community.
Only for security vulnerabilities that "Apple is aware may have been actively exploited". And almost never for any bug fixes (and sadly, Apple now tends to push off bug fixes to the next major release/"n+1" rather than fix bugs in the major version in which they were introduced).
I don't understand why I'm downvoted. I don't think it's acceptable to keep a machine with known vulnerabilities "not yet actively exploited" for "most common uses". The defense of Apple here goes too far.
Replayability means something different in this context. First, we do know the backdoor will pass the payload to system, so in general it is like an attacker has access to bash, presumably as root since it is sshd.
Replayability means, if someone were to catch a payload in action which did use the exploit, you can’t resend the attacker’s data and have it work. It might contain something like a date or other data specific only to the context it came from. This makes a recorded attack less helpful for developing a test… since you can’t replay it.
> It might contain something like a date or other data specific only to the context it came from.
In all these modern protocols, including SSHv2 / SecSH (Sean Connery fans at the IETF evidently) both parties deliberately introduce random elements into a signed conversation as a liveness check - precisely to prevent replaying previous communications.
TLS 1.3's zero round-trip (ORT) mode cannot do this, which is why it basically says you'd better be damn sure you've figured out exactly why it's safe to use this, including every weird replay scenario and why it's technically sound in your design or else you must not enable it. We may yet regret the whole thing and just tell everybody to refuse it.
What could be done, I think, is patch the exploit into logging the payload (and perhaps some network state?) instead of executing it to be able to analyse it. Analyse it, in the unlikely case that the owner of the key would still try their luck using it after discovery, on a patched system.
What it does: it's full RCE, remote code execution, it does whatever the attacker decides to upload. No mystery there.
it does whatever the decrypted/signed payload tells the backdoor to execute - it's sent along with the key.
The backdoor is just that - a backdoor to let in that payload (which will have come from the attacker in the future when they're ready to use this backdoor).
You are using someone elses propietary technology, you have to deal with their limitations. If you don't like there are endless alternatives.
"Wrongly denied" in this case depends on your point of view, clearly DALL-E didn't want this combination of words created, but you have no right for creation of these prompts.
I'm the last one defending large monolithic corps, but if you go to one and want to be free to do whatever you want you are already starting from a very warped expectation.
I don’t feel like it truly matters since they’ll release it and people will happily fine-tune/train all that safety right back out.
It sounds like a reputation/ethics thing to me. You probably don’t want to be known as the company that freely released a model that gleefully provides images of dismembered bodies (or worse).
I don't know about importing from Bitwarden, but a normal Keepass-database will work for you. All you need is a way to sync a file between all your devices. KeePassium on iOS is Open Soruce and integrates very well.
> The connection with Firefox (on Linux) regularly breaks.
If the connection breaks, the green button in the username field that fills in your details, turns into a red cross. If you just click the red cross, keepassxc will immediately reestablish the connection. Then click again to fill in. For me, I only have to do this once after unlocking my database.
Sorry, I don't use Linux much, so I don't have a recommendation. But one of the key advantages of a Keepass-Database is that theres loads of clients, so maybe try another.
- Leta is much faster than Startpagw
- Startpage offers a lot more of Google's features, eg date range filter, image search, and so on
I would guess that both differences are due to Startpage not doing any caching.
Startpage also has a neat "Anonymous View" feature where they proxy the request for you, acting as your HTTP client. If you trust Startpage, it's probably a pretty good ad-hoc anonymity tool.
As I used to work for Intel, I can tell you: absolutely not - this would expose Intel to far too great risks on antitrust level.
However they do pay 3rd parties to run parallel benchmarks on both their silicon and competitors, and get access to detailed reports. And probably they will buy silicon off the market when it's available commercially.
I can think of a few simple tricks already. One: Host from the main facebook.com domain, either inserting it in the basic html page response from the server, or from an API / content location that cannot be predicted. (ad calls should be indistinguishable from 'normal' content calls). Two, do the same with content locations, so no 'div id="ad"' or anything like that. Should be easy enough.
If true I believe that this would actually be an important improvement. This removes some plausible deniability regarding malware and other abuse; Facebook (or whomever else adopts this scheme) must guard more carefully against abuse when the content is coming from their own domains, as opposed to some third party.
The efforts I've seen so far from other websites include randomized IDs and class names, and base64 encoded images inlined so the file path/hostname can't be used as a parameter for blocking.
reply