oneplane

This is just a Windows VM with extra tooling. Makes it look slick, doesn't make it "Windows apps on Linux".

Similar projects exist for gaming for example Looking Glass, which also uses a Windows VM on KVM (the "Windows in Docker" thing is a bit of a lie, Windows doesn't run in the container, Windows runs on KVM on the host kernel).

UX wise, this is similar to RAIL.

That's not to say that this isn't neat, but it's also not something new (we still have two flavours: API simulation/re-implementation and running the OS [windows]). If this was a new, third flavour, that would be quite the news (in-place ABI translation?).

You don't need to be in the Apple ecosystem to buy an Apple TV and only use non-Apple services.

The only thing that will probably suck is the lack of things like MiraCast and Google's Casting stuff, but you could use third party AirPlay software (still free IIRC) to stream whatever you want if you want to use screen mirroring.

These days people tend to use their media boxes as App Launchers for other services anyway, so it doesn't really matter that much anymore.

If the long-lived token is actually a private key that is non-retrievable and the secrecy and origin is attested by a HSM, I'm fine with that.

That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.

It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.

AWS has no such thing. It also is not an alternate either way since the owner of the first payment method would have this in an MPA, not in a member account, and in AWS, member accounts are not considered payers and any payment methods are ignored.

The article makes a variety of claims, some of which can be dismissed because they factually do not exist with AWS, and some of which cannot be verified at all. But precedent shows that when your middleman in a savings scheme drops out, you are screwed, and that is what happened here.

That doesn't make this fun, and it would be better if everyone had a personal account manager, but that's not the reality of today.

The article says so:

> AWS blamed the termination on a “third-party payer” issue. An AWS consultant who’d been covering my bills disappeared, citing losses from the FTX collapse. The arrangement had worked fine for almost a year—about $200/month for my testing infrastructure.

He essentially got screwed over by the consultant. Everything else is a side-effect but not material to the cause.

It's not sudden, the account owner disappeared and the account user (the one making all the noise) did not get ownership transferred.

Is this a great situation? No. It's also not "I did everything right and boo hoo AWS did a boo boo". AWS is not your friend, but you also weren't the customer, that was the middleman you gave ownership to.

Both are legacy dinosaurs, it makes sense they start eating each other.

Yep, but you still can't say "compile and link everything in this tree". Technically, the language can, but the framework assumes specific compiler, linker and layouts on the filesystem so at that point you can't. It really wants that editor-related stuff to be part of the framework, and everything else has to bend for it.

It's still stuck in weird formats and monoliths. A lot of GUI-only stuff has been ported to the mega CLI, but it's still the weird Visual Studio format plus XML files that you cannot replace with a simple Makefile. You still can't just compile a bit of C# as-is, it must have the Solution, Project, Assembly etc. chain, the run-as-script feature is nice (lots of cheers when that was presented! even on the live stream), but it's specifically not designed to allow you to assemble a toolchain that works for what you need. There is only one and it has everything, no options.

The question, of course, becomes: when does that matter? For a lot of people who are in to .NET, they see that as a benefit. Look at Go through this lens, and it's similar; the go CLI is the compiler, linker, package manager etc. I suppose the biggest difference is that it doesn't prescribe solutions and projects and file formats to go with them, which enables you to put this in any existing CI, make or other system.

Meanwhile, Citrix has been on fire causing much worse things (you can just grab any session you want and become anyone who's already logged in). Who needs to break into SharePoint when you're becoming someone who's already got access... including to everything else (not just SharePoint)

It's patchable, but it's been two times in a row now, and patching is always slow and incomplete.

TL;DR: not really all that exciting. Apple also publishes a list of domains, ports and protocols and what they are needed for. The side-effects of filtering them usually means something doesn't work right or doesn't work at all (push messages, software updates, buying stuff, anti-theft - which will fail closed!).

> I have been trying to minimize to the extent possible the reach of big tech into my life

That's how integrated services on connected devices work; why the surprise? You can't both have a connected experience that works while also not connecting to hosted services that provide that functionality.

This isn't just Apple, anything that has any connected (cloud or anti-theft or otherwise) will need to function like this.

If your version of big tech is anything that provides managed services, you might as well get off the internet as it doesn't really provide that much value without it. That applies to basic services as well:

- Want email? Either go big or go home since you'll be attacked and spammed so much that unless you essentially learn to become an MSP for email for yourself it's not really feasible (and that includes all the GitHub projects we've seen on self-hosting; it's great as a one-off or hello-world demo, yet maintenance and knowledge is still required - time people aren't willing to invest)

- Want search engines? Extremely expensive to run, so you're going to consume one or not use one at all.

- Want to communicate with other people? They might use scary big tech and there is nothing you can do about it short of not communicating with other people (but that's antithetical to your wish to communicate with others).

- Want to communicate with business services? They might require you use known quantities such as specific operating system versions and configurations, certain apps, or they might not service you at all (banks, insurance, medical, transit etc.)

Can you apply a lot of time and energy to work around all of this? Possibly! But you end up not having much time left to do the things you actually wanted to do in your life. It essentially ends up similarly to what al_borland wrote: most large workflows and processes (regardless of governmental, for-profit businesses etc) don't want to make intensive exceptions just so 0.001% of their customers can be 'different', on one hand because it's not sustainable (you end up having one process for 99.99% of the users and many, just-as-expensive variations to that process for a bunch of individuals), on the other hand because it's not profitable (spending for one flavour and getting all the return on it vs. spending and getting practically no return on it).

Effectively, yes.

Unless Krogers maintains the Xbox software and Xbox servers and Xbox business processes so it can keep functioning.

Do ordinary people side load at all? Assuming most people use the phone to do something else, and not for the sake of using the phone, after you get the apps you want/need, ordinary people are likely to just do the same thing/consume the same apps over and over.

TL;DR: profit (direct and/or indirect).

I don't know if they do, but I do know the universal answer to all of it: because that's what makes the big bucks. While there will always be inefficiencies and weird situations, multinationals that stick around for a long time and make lots of money do so because there are a bunch of people working there who have to figure out how to make money and keep making that money.

Maybe this iteration it won't be a bolt-on, who knows. Because of the origin of C# (Microsoft Java replacement) it's all still very MSBuild/IDe-magic-ish instead of being its own thing where you can decide your own dependency resolution, your own compiler and your own linker.

It's similar to cmd.exe and conhost etc. It's all tied to decades old legacy baselines that Microsoft just won't or can't let go of.

I'm agreeing with you in agreeing that the author is complaining too much. I suppose I could have worded it better.

Imagine writing your own security software when there are proven systems that just take that problem out of your hands so you don't need to complain about it.

It's bonkers if you don't need it, just like JSONx (JSON-as-XML) is bonkers if you don't need it. But standards aren't for a single individual need, if they were they wouldn't be standards. And some people DO need these variations.

Take your argument about order of operations or algorithms. Just because you might not need to do it in an alternate order or use a legacy (and broken) algorithm doesn't mean nobody else does. Keep in mind that this standard isn't exactly new, and isn't only used in startups in San Francisco. There are tons of systems that use it that might only get updated a handful of times each year. Or long-lived JWTs that need to be supported for 5 years. Not going to replace hardware that is out on a pole somewhere just because someone thought the RFC was too complicated.

Out of your arguments, none of them require you to do it that way. Example: you don't have to supply d, dq, dp or qi if you don't want to. But if you communicate with some embedded device that will run out of solar power before it can derive them from the RSA primitives, you will definitely help it by just supplying it on the big beefy hardware that doesn't have that problem. It allows you to move energy and compute cost wherever it works best for the use case.

Even simpler: if you use a library where you can specify a RSA Key and a static ID, you don't have to think about any of this; it will do all of it for you and you wouldn't even know about the RFC anyway.

The only reason someone would need to know the details is if you don't use a library or if you are the one writing it.

I personally don't see the overengineering in JOSE; as you mention, a JWK (and JWKs) is not much more than the RSA key data we already know and love but formatted for Web and HTTP. It doesn't get more reasonable than that. JWTs, same story, it's just JSON data with a standard signature.

The spec (well, the RFC anyway) is indeed classically RFC-ish, but the same applies to HTTP or TCP/IP, and I haven't seen the same sort of complaints about those. Maybe it's just resistance to change? Most of the specs (JOSE, ACME etc) aren't really complex for the sake of complexity, but solve problems that aren't simple problems to solve simply in a simple fashion. I don't think that's bad at all, it's mostly indicative of the complexity of the problem we're solving.

He's not wrong, but he's also not right. I suppose it mostly comes close to screaming into the void and not helping with anything.

The way things are is also a mirror of large society. It takes a lot to keep it all going, combined with nobody has time or wants to care about the technology in their life. At best there are some negative events that makes people think about it for a little while, and for some there will be a bad memory, but in the end it just fades out of focus to the same place where oil changes and filter changes go.

So the hierarchy looks a bit like this:

Top level = Keychain Access.app or the security CLI tool

Mid level = keychains (in flavours of files, core storage, data protection-enabled, and iCloud)

Item level = an entry inside a keychain

There is a sub-level as well, some software stores encoded data as a single item so when it's decrypted it's a bunch of different data, not a single secret, but technically the keychain system isn't aware of that anyway.

Yeah, it's a bit overloaded. There are keychains (.keychain files) and keychain items (secrets inside of them). The keychains are visible in the Keychain Access app, but also available in the 'security' command line. And then there are modern keychains, those are more like SQLite databases and those can have anything from SQLCrypt type of management to Secure Enclave DEKs.

Security is pretty difficult to get right, so many tradeoffs as well.

Yeah so it really depends on the local setup. Here's a wall of text if you're interested:

Say you do software development with a platform engineering and cloud flavour on top, you might be using aws-vault to keep access keys and SSO session keys in a dedicated keychain rather than in plaintext in ~/.aws/. That keychain has an ACL that only allows aws-vault to access it, and has a self-lock timeout of a few minutes. This is great, because it is pretty secure, there is nothing to 'steal' (even from an unlocked machine) and it's still extremely convenient.

However. Say you do this with an external non-TouchID keyboard, when the STS timeout expires and you need to re-authenticate, you also need to unlock the keychain for a few seconds so aws-vault can either read out the SSO session tokens or the static secret for non-SSO usage, and it has to write back the new STS session.

During that window, the keychain unlock from such a keyboard means manual password entry, which in turn means that has to be in memory for a bit. Because a legacy keychain doesn't use data protection (but if you create a new one you do have that option) it's essentially just an AES encrypted file on disk. Because humans aren't likely to remember an AES key, it's derived and wrapped so you have some KDF that uses a user-selected password, which has to be in memory for a bit while the key is unwrapped/derived. The AES key itself has to stay in memory the entire duration of the unlocked state of the keychain, because without the AES key it can't read or write secrets.

Technically, the same happens to encrypted disk images (the AES ones at least, other types I'm not 100% sure). The DEK has to stay in memory while it is in use. It's why Apple started using systems like cryptexes and SSVs so the container disk is almost irrelevant from an integrity point of view. Before that, encrypted disks were an all-or-nothing approach.

TBH this is still possible in some scenarios, mostly when someone isn't using data protection and manually unlocked a local Keychain. It's pretty much the same as dumping LSASS memory on Windows when IOMMU isn't used, and in some cases even when IOMMU is used.

Yes, there was a post recently about moving more and more parts out of Mach. Some of it to L4, some of it to user space.

Technically, this might actually increase the potential attack surface (due to more different components existing together). But more specialised surface would then allow for simplified control and as an effect better protection of that surface.

Proxmox runs fine on M-series Macs. macOS also runs fine with no GUI.

Either way, it wouldn't be a good fit when Ampere exists.

For low power modular compute, the way GitHub and Amazon re-package Mac Minis is not the moest efficient way to get Apple hardware in a rack with remote management (and still no ECC), but it does have a performance per watt and compatibility for macOS CI workers that you can't get any other way.

Ideally, this stops being an issue when the ARM64 ecosystem can build those apps natively. We're pretty close on that one, and it means you can use Ampere and Graviton for that.

Didn't Samsung try to do the same? That'd be a Korean option if amelius has that in scope. Unless they are using Snapdragon for those of course.