kuhsaft

Well, with Android/Chrome OS they just recently released Jetpack Compose Material 3 Adaptive which is further iteration by Google to try to unify UI development between form factors [1]. And there's the breaking changes with every major version of Android [2]. Then there are the incompatibilities for Android apps for Chrome OS [3].

You can shit on Microsoft all you want, but those listed APIs still work. People expect Microsoft APIs to exist essentially forever, so every breaking change pretty much has to be a new API.

Having a single simple API for developing across different devices and inputs that automatically provides great UX across the board just isn't possible. It's going to be complex and it's on the developer to cater to each device. An API to cater to everything is literally web APIs.

[1] https://chromeos.dev/en/posts/io-2024#android-on-chromeos

[2] https://developer.android.com/about/versions/13/behavior-cha...

[3] https://developer.android.com/topic/arc/manifest

That's memory mapping. This is memory paging [1]. I.e. Windows pagefile.sys, Linux swap, macOS swap files. iOS does not have swap files, only memory compression. If you're on a Mac, open up Activity Monitor, go to Memory, and at the bottom there is `Swap Used`. That doesn't exist on iOS. So, if more memory is used than available, applications will need to free memory or be terminated. Unlike macOS, where some used memory will be swapped to disk to allow other stuff to be loaded into memory.

[1] https://en.wikipedia.org/wiki/Memory_paging

Wow. Never knew about the move to ARCVM. Though the first thing that comes up when I search it is memory and CPU usage issues though :/

Google et al. has put a lot of effort into improving Linux's virtualization capabilities. Goes with being the OS of choice for pretty much all servers I suppose.

> This would lose the security properties of iOS, which is a big part of the value proposition for iPhones and iPads.

Right. Apple is adding more and more security features from iOS into macOS. But, people are going to complain about that too.

> Other operating systems can run in _parallel_ with iOS

Absolutely, but there is a performance hit and memory management becomes an issue. You still need a host OS as well to unify the UX. Also, there needs to be some way for IPC between the applications of different OSes.

> Microsoft implemented WSL

WSL has networking and memory management issues. WSLg sort of works. Its architecture is wild [1]. Display scaling is terrible though. IPC between Windows and WSL guests is limited.

WSL 2 was released in 2020 and it still has issues. It's not a simple problem to solve.

Microsoft has also gone from WinRT, UWP, WinUI, MAUI, and now WinUI 3 trying to unify application development [2]. Again, it's not a simple problem to solve.

I think the only OS that has actually unified application development across all form factors is Android/Chrome OS. But, people complain about how limited Chrome OS is.

[1] https://github.com/microsoft/wslg?tab=readme-ov-file#wslg-ar...

[2] https://www.irrlicht3d.org/index.php?t=1626

I edited my original comment. The "It's a bit jank" part is still true though. When you enable running your app on macOS without compiling specifically for macOS with Mac Catalyst, it still uses Mac Catalyst, but transparently. So, you still get all the issues of Mac Catalyst, but without the compiler warnings. Your application may crash or behave strangely.

As much as I would like macOS on iPads, running macOS applications on an iPad without the Magic Keyboard would suck. Windows can do it though, so it's not really an excuse.

But, in Microsoft's case, it's sort of different. They had Windows 10 Mobile for tablets which is the closest thing to iPadOS, I suppose. Windows 10 Mobile couldn't run Win32 applications, similar to how iPadOS can't run macOS applications. Microsoft killed Windows 10 Mobile...

Implementation-wise though, it's a big effort for Apple. They can't just make macOS applications runnable on iOS. Something like reverse Mac Catalyst for iPadOS wouldn't work due to how complicated and different macOS is compared to iPadOS. It would probably have to be a full on emulation of macOS on iPadOS for applications to run.

So, it would seem like starting with macOS then implementing iPadOS on-top would be better than starting with iPadOS and implementing macOS, which is literally what Mac Catalyst is. So now, Apple has to make sure that all iPadOS APIs work with Mac Catalyst (they don't yet) and they have to do something to make the UX work better when switching between touch and M&K.

Bringing it back to Microsoft and Windows now. It's quite similar actually. Think of Windows 10 Mobile = iPadOS, UWP = iPadOS apps, Win32 = macOS apps. Microsoft killed Windows 10 Mobile and replaced it with full-on Windows 10. Windows 10 can run UWP apps.

Similarly, Apple will likely have to kill iPadOS and fully implement compatibility with iPad apps on Mac for macOS to ever be on iPads.

What would happen to the macOS applications when switching to iOS? iOS applications would be fine in macOS-mode (Mac Catalyst already exists). But, there isn't a good way to make macOS applications usable in iOS-mode.

In this case, the app is running in a sandbox with a user-space that simulates the iOS user-space [0].

> Your apps use the same frameworks and infrastructure that Mac Catalyst apps use to run, but without the need to recompile for the Mac platform.

> Although you can run your iOS apps unmodified on a Mac with Apple silicon, Mac Catalyst lets you build your app specifically for macOS and customize your app’s behavior on that platform.

Mac Catalyst was a multi-year effort by Apple. Doing the same to run macOS apps on iOS would probably be even harder due to how complicated macOS is compared to iOS.

[0] https://developer.apple.com/documentation/apple-silicon/runn...

The hardware was drastically different between Macs and iPhones when iOS was released. That was in 2007. Apple only unified the hardware in 2020. Over the *13* years, the operating systems have diverged so much that unifying them is a massive effort. The linked blog post by Zhuowei Zhang shows some of the differences. The user-space components are just so different that it's not as simple as running a macOS app on iOS.

EDIT: You can run a iOS apps on macOS without recompilation, but it uses Mac Catalyst which is a user-space shim for iOS apps to work on macOS. Even then, not everything works.

They aren’t actually too similar. They both use XNU, but the memory model is completely different. On macOS memory can be paged to/from disk. On iOS it isn’t and applications must free memory when asked or be terminated [0].

iOS applications are sandboxed by the kernel, with no opt out. macOS applications are not sandboxed by default and are opt in.

Then there are the API and UI differences.

EDIT: That linked blog post in the parent blog post also shows how different the userspace is: https://worthdoingbadly.com/macappsios/

EDIT: iPadOS 16 enables virtual memory swap [1]

[0] https://developer.apple.com/library/archive/documentation/Pe...

[1] https://www.apple.com/newsroom/2022/06/ipados-16-takes-the-v...

ICMP is lower-level than what Network.framework provides.

CFSocket would be the Swift/Obj-C API.

https://developer.apple.com/documentation/corefoundation/cfs...

Not sure what you mean. The USDA forced Boars Head to suspend operations at the factory in late July due to a myriad of violations over the course of a year.

https://apnews.com/article/boars-head-listeria-recall-fcde06...

https://boarshead.com/pdf/Boars-Head-NOS-July-2024_view.pdf

Boars Head just decided that it’s better to close the plant indefinitely, since they can’t comply with regulations immediately.

Very PR. They link the USDA findings, but didn’t state that they were forced to stop operations. Instead, they make it sound like it was their choice for concerns towards customers.

https://apnews.com/article/boars-head-listeria-recall-fcde06...

> the end user could be MITM'd already with a root certificate maliciously installed on their device

If a malicious root certificate is installed, then the user’s system is already compromised and signature validation won’t help.

The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload.

EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.

One major usage of services meshes that I’ve come across is for the transparent L7 ALB. gRPC, which is now very common, uses long-running connections to multiplex messages. This breaks load-balancing because new gRPC calls, within a single connection, will not be distributed automatically to new endpoints. There is the option of DNS polling, but DNS caching can interfere. So, the L7 service mesh proxy is used to load balance the gRPC calls without modification of services.

https://learn.microsoft.com/en-us/aspnet/core/grpc/loadbalan...

That is false. Creation of threads/processes is still available within a container. Docker will run the entry point as PID 0 and that process can create as many subprocesses as it wants. If you’re talking about cores, Docker utilizes Linux cgroups which permits usage of multiple cores. You can limit the CPU quota and assign the container to specific cores. See https://docs.docker.com/config/containers/resource_constrain...

But, they do. Any electromagnetic wave can refract.

https://en.wikipedia.org/wiki/X-ray_optics#Compound_refracti...

3Blue1Brown has a very nice series on optics: https://www.youtube.com/watch?v=Cz4Q4QOuoo8

Not a very usable color picker. The this color picker is limited to a slice of the HSV colorspace with a V of 1. Also, the outputs are not copyable.

The HSL/HSV color space also isn’t great for generating color combinations due to the deformation of lightness. A much better colorspace is the OKLCH colorspace which is has uniform lightness. The downside is that the colorspace is not perfectly cylindrical, so some values have no real displayable value. It also supports P3 and Rec2020 colors.

I think, something like https://oklch.com/ with color combinations would be more useful.

https://atmos.style/ is the most useful color tool I’ve used. Unfortunately, it’s not FOSS.

Seems like Fly.io Machines are trying to reimplement Kata Containers with the Firecracker backend [0], but also abstracting away the host hypervisor machine infrastructure.

Kata has a guest image and guest agent to run multiple isolated containers [1].

[0] https://katacontainers.io/

[1] https://github.com/kata-containers/kata-containers/blob/main...

The thing is you might not be adding the sidecars yourself.

Kubernetes has a resource called MutatingAdmissionWebhook that allows mutations of the Pod object before creation.

I think the most common use case is for service meshes. Your Deployment might not have any sidecars, but the service mesh controller will automatically add a network proxy container to your pod via the admission webhook.

Another use case would be OpenTelemetry or some other observability service sidecar injection for auto-instrumentation.

It should discuss what you don’t get compared to the standard behaviors of Kubernetes.

Right, but what is the point of FKS then? It’s no longer Kubernetes if it doesn’t support a core behavior of Kubernetes.

If you only support deploying single containers with single processes on FKS, then you might as well use flyctl.

It’s a solvable issue of course. The virtual-kubelet implementation would need to create a Machine running a container runtime image that would then run a the pod containers to match the pod configuration.

I think that some disclaimers of the limitations of FKS compared to standardized Kubernetes should be present and highly visible.

It’s used widely in the Kubernetes world and is known as sidecars [0].

[0] https://kubernetes.io/blog/2023/08/25/native-sidecar-contain...

Fly.io claims it’s “just a VM”. But, Fly.io Machines are an abstraction of microVMs using Firecracker. Building upon that, the FKS implementation is an abstraction on top of Fly.io Machines. So what I’m asking is how, if even, does the FKS implementation support multiple containers for a pod? Using FKS, the abstraction is no longer a VM.

It seems that Fly.io Machines support multiple processes for a single container, but not multiple containers per Machine [0]. This means one container image per Machine and thus no shared network namespace across multiple containers.

[0] https://community.fly.io/t/multi-process-machines/8375

How does this handle multiple containers for a Pod? In a container runtime k8s, containers within a pod share the same network namespace (same localhost) and possibly pid namespace.

The press release maps pods to machines, but provides no mapping of pod containers to a Fly.io concept.

Are multiple containers allowed? Do they share the same network namespace? Is sharing PID namespace optional?

Having multiple containers per pod is a core functionality of Kubernetes.

I think there’s potential here.

It is Kubernetes since they are running k3s as the control-plane. It’s not just an implementation of the Pod API, it’s an implementation of kubelet which handles logs/exec/etc APIs. The rest of the Kubernetes API is part of the control-plane on k3s.

The only major issue I see is persistent volume support, but persistent volumes in Kubernetes were always a bit flaky and I’ve always preferred to use an externally managed DB or storage solution.

DX might be better I suppose, since you don’t have to fiddle with node sizing, cluster autoscalers, etc.

Someone else linked GKE Autopilot which manages all of that for you. So if you’re using GKE I don’t see much improvement, since you lose out on k8s features like persistent volumes and DaemonSets.

Traditionally, each node is its own machine. virtual-kubelet creates a virtual node that is a proxy to some other pod infrastructure. In the case with FKS, each pod in the virtual node is a machine (a node in the traditional sense), so it’s equivalent of having an anti-affinity on all pods with an infinite node pool.

I think the biggest hurdle would be networking between the pods since they will be running on different cloud providers.