My company maintains a medium set of Rust programs deployed on embedded Linux systems. Most of the time the migration is automatically done for you by Cargo itself with the command `cargo fix --edition`.
I don't know where you got this impression but our switches from 2018 to 2021 and now 2024 editions went very smootly. Rust hasn't broken backwards compatibility in any bigger way since 1.0.
WPF is pretty complete and used widely in various engineering, finance and corporate applications. It is HiDPI compliant. It is mature (developed since pre-Vista). It supports modern look too (can even look like Win-11, they officially support it!). Some of the beloved Microsoft late programs like Windows Terminal are written in it. If they use it and keep improving it, it has a huge potential.
But no. We cannot have nice things. Microsoft has lost the ability and management capability to release nice things. For some reason, Microsoft is trying to reinvent the wheel with UWP (aka WinUI2) and WinUI3. They are trying to replace everything with these half-arsed libraries when very complete and well-thought, future proof stuff already exists in Windows' DNA. They are shitting on the work of their earlier engineering.
If Microsoft didn't kill it, lack of YouTube and other Google services would. That was the primary difference. With iPhone you had access to Google-owned stuff, Google never allowed other platforms like Symbian/MeeGo/Windows Phone to ever use its online services.
The game was broken from the start. Microsoft had no chance.
Maybe being not laid off along with other long-term staff and being part of easy-to-hire easily expendable army of JavaScript / TypeScript developers? XAML etc. are specific skills the developers are rarer and usually paid better than JS/TS devs.
I don't think the usual distros care about the desktop experience as holistically as a long-term consumer company that Valve is. Otherwise one would expect Linux distros would be much better than what they were even 10 years ago.
Um, this is exactly what happened in the previous wars. Even modern ones. Auto plants are full of general purpose robots. They can make military stuff with some relatively low-cost changes.
There's something about showing up to fight the previous war. Tanks were scary from WWII to Desert storm, and still are to me, as a civilian. But militarily are they still? I have no idea what I could to do fight against one that magically showed up in front of my house, but Ukraine War videos suggests the age of tanks has passed. They're still something you'd need to make, but more important it seems is the ability to make tiny electric motors for drones and injection molding for plastic fans, and some 3d printing. You'd want a manufacturing base that was able to make cellphones, not tanks.
Looks to me that flexible industry is the new super-weapon.
That means standard components, flexible robots (3d printing are some, but there are many kinds), low retooling time. And yes, nothing at all like a car factory.
If Russia wanted to invade Ukraine, it wouldn't matter. Ukraine isn't NATO.
US was involved in Bosnia and Kuwait. If they pleased they would be involved in Ukraine. But US got the fascist mind virus.
It WAS US policy to play the protector role for EU and other West Aligned nations. Such that they traded with US and bought weapons from the US. If US pulls out, they will be replaced by other players in the game.
What other players in the North American Treaty Organization are you thinking of that are waiting on the benches to pick up the slack? We're looking at the same world map, right?
> Android uses Linux as it kernel and runs on billions of devices with heterogeneous cores. Linux had this capability for way longer than Windows did; Windows for the most part did not run on devices with heterogeneous cores until the Intel Alder Lake (12th gen) CPUs.
The extra capabilities of Android come from custom patches from Qualcomm kernels. They are so far diverged from the mainline, it is really really hard to merge it back. They not only add drivers but patch the kernel itself. Windows NT can have hints for thread scheduling from the userspace since they control Win32. Now the question becomes is there a way to patch Glibc and all other system libraries on Linux to give equal information to Linux kernel. Of course Linux kernel can guess but it is a lossy information channel.
As a previous Arch user I don't understand what you mean by "best of both worlds"? The point of Arch is to be mutable to a great extent and shipping vanilla packages.
For example, it is quite annoying to have a sane font setup due to Arch shipping vanilla. Fontconfig sucks, it has bad documentation and Arch Wiki examples go only so far. Among the entire distro universe only Fedora has sane configs. So an immutable Arch goes against immutability.
Moreover OSTree requires a server to receive updates regularly, are you going to put the effort to building the OSTree multiple times a day? Why should we trust a single person?
Ostree and immutable distros in general are seeing a renewed interest lately for mostly security reasons but they have been and are still widely used for appliance-type devices.
I could see someone wanting to build an arch based firmware with OTA updates use this as a proof of concept. Yes, they would have to customize it and operate some infra but that does not make it useless.
exactly. plus i mean, this particular build is quite boring because it's, like i said, silverblue. vanilla gnome and all that. but one can go quite wild and make vastly different builds. building locally takes very little since it's basically decompressing a bunch of packages, moving some files around and building an initramfs, so the infrastructure one actually needs is minimal (especially if said upgrades happen silently).
i must say that even though this tech has been around for a while it's still very much WIP. much of the ostree command line is undocumented, some commands are hidden and even though there is significant overlap between rpm-ostree, ostree and bootc, they do quite different things and some things are easy with one tool and outright impossible with the other. but personally i think this is the future of "mainstream" linux, and even though "immutable linux" has been often associated to locked platforms (e.g. android), it's been fun to showcase how you can do it yourself too, with whichever distro you like.
Of course, SteamOS is an immutable Arch spin, so it's not as if this isn't an idea that's been had before, but Arch is indeed on the surface sort of a weird distro to implement as immutable.
this one technically doesn't have an ostree server because it would require dedicated infrastructure, but if you decide to either try out images (they're in ghcr) or fork the project and build your own, you can schedule nightly builds (as it's being done now) and use bootc rather than ostree. the problem is that you'd always have to pull a 2GB image rather than incremental updates.
reply