What are you even talking about. Every M1 Mac and earlier runs Linux. Even all the way back to PowerPC.
Granted, the M1 and up are not 100% covered yet (driver-wise), but they aren't EOL either. And if they were, Linux would still run anyway. Take a 20 year old Mac and you'll run Linux just fine. 10 year old Mac, Linux still runs fine. Take an M1 and it's a joy to use with Linux. Taken an M2 and it will boot and you can be pretty sure it will run very well long before it's EOL too. And even if it's EOL, it's not going to prevent you from running Linux later.
As for the PC example: definitely EOL problems there. Try getting your EDK2-based UEFI stack patched on an old computer. At some point you won't be getting certificate updates and if you either forget to install a local override or if the vendor didn't add it, you're SOL, especially on laptops where you can't disable secure boot.
Those local options exist, and have been around forever, but the problem is nobody is doing it without cutting corners and with pay-as-you-go elasticity (and the 'call an API, get a VM instantly' effects that go with it).
Most on-prem deployments were trash and a lot of them still are. Not because it couldn't be better but because it's easier to just have some random hypervisor department do this work manually and not do the work to create it as an internal product. Even VMware with vrealize failed and that's about as 'customisable cloud platform in a box' as COTS enterprise software can get.
Maybe it's because IaC and APIs were just not in the vocabulary of the average system integrator or on-prem operating team (it's still lots of clickops and copy-paste).
Not really, some of the IP is core to the product and it cannot function without it. In theory if you do something like come up with a complete replacement for EUV, you could, but everyone with deep pockets has already been trying to do that without success. Same goes for the supply chains, most companies (including ASML) don't manufacture everything themselves; so components that come out of the US would need non-US suppliers, which don't always exist.
I suppose it's a case of 'technically possible, realistically infeasible'.
A more likely scenario might be either a from-scratch not-as-good machine that you can source locally (supply-chain wise) or a novel finding (which is hard to predict if it will happen and if so, when).
That statement makes no sense. X11 works fine on macOS and running it in rootful mode with Gnome essentially works the same way it would work on an OS that uses the Linux kernel.
Granted, it will not integrate with anything hardware-wise by itself (unless there's a package for it - if not, macOS still handles it, and Aqua/Quartz will keep running in the background anyway), but if what you wanted was something that is KDE or GNOME running with its own WM on its own X11 server, doing the exact same thing you'd get if you're running a Linux distro, that's been natively possible for over 15 years.
If a power user loses their power based on what GUI happens to be in front of them, how much of a power user was the power user to begin with?
There is a major difference between losing your power and having to constantly fight the UI to keep your power. And, for example, window management on Mac is clunky as all hell.
It does, it's called FreeIPA (or RedHat IdM). The only GPO parts it doesn't do are those that are not related to policy in the IAM sense (i.e. configuring some application related thing). There's other systems for that, just like on Windows you practically never run GPO without anything else. On top of that, you can pay RedHat or Canonical to host it all for you on any cloud or non-cloud.
There is a lot of documentation from Apple on how all of this works, but this is indeed expected behaviour. A way to make this smoother would have been:
1. Doing the password reset
2. Reboot straight back into recovery
3. Update your new password back into your old password
4. Boot into macOS, your default keychain will unlock but you'll still have to re-authenticate to iCloud since your machine-user identity combo will no longer match with what iCloud expects. (not sure if this is part of Octagon Trust, but there are various interesting layers to this)
There are a number of much more in-depth technical guides and specs, but just listing out random articles (or the Black Hat talk(s)) would probably rob someone of a nice excursion into platform security.
The article was based on the heat or in the panic of the situation where i need to get work done for which i was being paid and also my search results on the icloud/keychain recovery didnt yield any useful the results.
Oh yeah, you got the same process down pretty much yourself, wasn't an RTFM dig or anything like that. It was more aimed at others who might end up here, more tools, more better!
It's interesting how with some systems/engineering thinking you'll pretty much always get there in the end anyway, which is also why articles like yours are pretty neat. (sadly, not everyone takes the time to write things down and share them these days)
Run it in a restricted VM, which is not joined to AD and cannot talk to it either. PAM will not save you, either will Airlock Digital or something like ATP or anything else like it.
Software for running VMs is free.
> Giving users local admin rights is a massive security risk we can't take.
Sounds like you made your endpoints into pets and bastions, that's an architecture that is guaranteed to fail. Work towards a design where the endpoint no longer matters.
I've been trying out similar things to help internal teams to use systems and languages like Rego (for Open Policy Agent) to have a visual and more 'a la carte' experience when starting out, so they don't have to jump straight to learning all syntax and patterns for a language they might have never seen before.
Thanks, Codex helped to put that together in like 20 minutes. Try feeding your agent the idea about an interactive config builder, give it the upstream URL with your condos, and see if it can whip up something for you.
Granted, the M1 and up are not 100% covered yet (driver-wise), but they aren't EOL either. And if they were, Linux would still run anyway. Take a 20 year old Mac and you'll run Linux just fine. 10 year old Mac, Linux still runs fine. Take an M1 and it's a joy to use with Linux. Taken an M2 and it will boot and you can be pretty sure it will run very well long before it's EOL too. And even if it's EOL, it's not going to prevent you from running Linux later.
As for the PC example: definitely EOL problems there. Try getting your EDK2-based UEFI stack patched on an old computer. At some point you won't be getting certificate updates and if you either forget to install a local override or if the vendor didn't add it, you're SOL, especially on laptops where you can't disable secure boot.
reply