We're reaching a revolution from moving from x86 to ARM and I think the more Microsoft positions themselves like this, the less likely they are to be left in some weird compatibility limbo.
As weird as this sounds, I feel more confident with Microsoft being able to do a successful transition to ARM than Apple at this point.
"Disc contains code to run on Windows NT-compatible x86, Pentium, MIPS, R4x00, Alpha, PowerPC and Pentium Pro systems"
Seeing what was coming with cloud and making .NET cross-platform was very well timed.
The most recent efforts are with their Surface Pro X, their SQ1 CPU and pushing Qualcomm to release Snapdragon 8cx CPU for ARM laptops.
But most software development companies didn't care enough to recompile their software for Arm and running X86 software in emulation is not exactly a good experience.
Obviously the Win32 subsystem isn't POSIX compatible, but I'm not sure why we would want that.
GNU/Linux users should be happy that old Microsoft didn't bother to do that much with POSIX subsystem.
Had they actually invested into keeping it up to date, and many of us on PC land would never bothered with FOSS UNIX clones.
Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.
Back when I was in the university, and Linux kernel was still at 1.0, I had the pleasure to write C and C++ code across Xenix, DG/UX, Aix, HP-UX, Solaris, BSD and naturally Linux also.
There is POSIX, there is what each OS actually do for the implementation defined behaviours, then the whole set of APIs that made each UNIX variant unique and were the selling point of the UNIX clone to start with.
Autoconf and friends did not start out of masochism.
That's not necessarily the case. See macOS which is using different GUI libraries, Metal instead of Vulkan etc.
So you can't recompile macOS apps to use them on Linux.
POSIX-certified systems conform to different POSIX standards. And most of them are of no use to the average developer such as AIX, HP-UX, Solaris.
The rest are largely compatible which means they are not compatible. And yes, that includes every single one of Linux distributions and FreeBSD.
We need better operating systems metaphors.
I feel like the non-GUI userland in Linux is best in class and is effectively a given for any server deployment. But all the developers I know cobble together a mediocre Linux-like environment on macOS so they can have a first-class desktop environment and an okay development environment.
On the other hand I read about people using Windows as development environment by using WSL.
I feel like Linux will never organically gain critical mass for a desktop environment—substantial source compatibility with some major platform seems like the way to go. How are the Windows APIs vs the Cocoa APIs these days? Assuming source compatibility could help boost desktop Linux’s fortunes, is Windows or Cocoa a better target? Does consideration of iOS change the calculus?
If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now.
I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones.
WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same.
For traditional Windows developers it doesn't really matter. PowerShell + Windows Terminal is where the action is.
For example, take high DPI. You have two primary competing toolkits between GTK/QT. It took a while but QT/KDE finally added HiDPI. Great, so I could get Hi-DPI setup on KDE! Then I open Firefox and it all falls apart because GTK. Extrapolate to any other number of issues. Unfortunately, Windows 10 isn't much better wrt to HiDPI (at least a couple years back when I last used it). I think there are more different UI toolkits on Windows than Linux has. Counterpoint: MacOS has one global toolkit with message passing based objects, it was almost trivial for Apple to add HiDPI and then dark modes. GNUStep/ObjectiveC would've provided similar basis on Linux, but it never took off. Now macOS is slowly loosing cohesion, instead of ObjectiveC 3.0, they made Swift which from my perspective appears to only be good at adding bugs to the terminal app while trying to avoiding message passing (no more user hot-loadable, un-sactioned third party plugins for any program on macOS :/ ).
At this point, I vaguely dream that HaikuOS will take off or someone makes a WebOS DE for Linux that has a complete suite of tools... but like peatmoss, I'd settle for a Rust/winRT on Linux.
One thing I’ve also thought is that if Linux had managed a first-class GNUStep environment with a compelling alternative to macOS in terms of dev tooling, it could have been great leverage in terms of keeping Apple focused on the core developer experience in macOS.
Rather, individual distributions of Linux are Operating Systems. As are the other Unices, e.g. the BSDs, Solaris/Illumos, all the old ones like IRIX, etc. And all of those, at first, built their own Desktop Environment from the ground up, just like Windows and macOS did.
As it happens, through the power of FOSS, many of these Desktop Environment projects were gradually merged, or the various distributions dropped their own DE in favor of someone else's.
But the historical path-dependence is still there, and the political lines are still mostly clear.
Don't think of KDE as "a Linux Desktop Environment." It's both not just for Linux (you can run it on FreeBSD, too!) and also isn't available for every Linux distro. KDE is still fundamentally, in some sense, "SUSE's Desktop Environment."
Same with GNOME: it might have been created by GNU, but it was mostly funded by RedHat and IBM for many years, even if Debian et al eventually picked it up as well.
Same with CDE: that's HP's desktop environment.
If you think of each of these companies as providing their own Operating System with a GUI composed solely of the graphical applications written for their own DE, the continued non-merging of these DEs makes a lot more sense. There's no more reason for them to merge with each-other than for them to merge with e.g. Android. (These OSes all happen to be based on Linux, but that doesn't really mean anything. macOS is based on BSD; should the macOS DE therefore merge with some DE that runs on BSD?)
† Defining "Operating System" here as "a software ecosystem that tries to deliver a cohesive user experience to the people who deploy it."
---
The thing that makes POSIX DEs different from the ones on Windows and macOS, is that you can install multiple DEs' libraries, and then run applications from one DE "under" another DE.
Except for special one-off internal provisions for their own legacy DEs (Carbon; WoW) you can't run software written for another DE "directly" on Windows or macOS. You can only virtualize such software using e.g. Wine, or an X11 server that runs as a window under your DE.
But the fact that Linux can do this, doesn't mean that the software was designed with this in mind. There's no "Linux integrated GUI experience" that all these applications are trying to target (FreeDesktop is forum for "meet in the middle" consensus solutions to be generated when required, not a working group for creating an encompassing standard for everyone to converge toward.) There's just the individual Operating Systems' GUI experiences (plural), where a given GUI app will fit in with the OS it was written for—and maybe with any other OS that happens to share its DE as the primary DE that the system is cohered around.
tl;dr: there is no "Linux." There's just RedHat, Debian, Canonical, openSUSE, Slackware, etc. all with their own goals. And also FreeBSD, NetBSD, Illumos, and whatever wacky proprietary Unices are still in play, who all also run and support these same DEs on very different substrates, with their own even-more-different goals. Each corporate player delivers you their own experience. There's no intent, between these companies, to try to commodify that experience into the same experience. Where would these companies/projects be, if they did?
Do you know many people that used to do this with macOS and are now using Windows ?
Like, oh boy, I tried, but after 4 months I ended up back with macOS.
So I've seen Mac users who work in these areas get sick of the issues and limitations and switch to Win 10 + sometimes WSL.
The people remaining with Macs are executive suite (who go for iPad pros) and account execs who do sales where it looks cool to go pull out a Mac. However even there people are increasingly looking dumb when they want to present something and go on 5 min dongle troubleshooting hunt because Mac killed HDMI and VGA ports and start their presentation appearing incompetent. Sometimes over web screen shares, only the desktop shows and not the applications.
By refusing to focus on hardware/software quality and power users, Apple has lost the game on high end.
This is what I do and works perfectly. My dev machines are 82 cores xeon platinums with Terabytes of RAM or nodes with 8 V100 GPUs attached, etc.
I don't know of any workstation, much less laptop, that could be a replacement for any of that.
For the stuff I do on the laptop itself (Word/Powerpoint/Outlook, web browsing, using an editor to edit files remotely, etc.), more power wouldn't hurt, but my macbook is a macbook air 2013... so I can't imagine that a 2020 macbook would be underpowered.
And it isn't just Gtk and Qt, outside of a very very small set of libraries (e.g. libcurl and Cairo), most other libraries do the same thing and most developers do not even seem to see that as a problem - except if you sit down and consider how much time is wasted in total by the users of those libraries (ie. the people who would actually make the desktops and the desktop applications) it should be obvious how much of an issue is (and even then, because many programmers prefer theoretically "clean" code and believe that the only way to do that is to rid existing working code and replace it with new -and unknownly broken- code, they have a very strong bias against even trying to accept this).
A very big reason Windows is dominant is because when something lands on the OS itself, chances are you'll be able to use it decades later. macOS much less so, but they have an army of engineers to keep up and even then as time moves on you see many people disliking how macOS breaks things (see the latest 32bit disaster).
Outside of a few influential outliers, like Linus himself or Keith Packard (who works on Xorg and Cairo) there aren't many that care about not breaking things. And IMO it is a bit disconcerting that it seems to be mainly the "old guard" of Linux developers that seem to care about this. I hope this is only because they've been around enough to realize that unnecessarily breaking things isn't a good idea, otherwise we can only expect things to become more broken over time (and Linus had this stance for decades, so it might not have anything to do with wising over the years).
Honestly, the move fast and break things culture that the web has fostered doesn't work for anything that has to do with other stuff people rely on.
But this is most likely also why you do not see that issue as much in the non-GUI world: most of the non-GUI stuff on Linux are either very long running projects (e.g. Bash, Perl, etc) that just do not break or very young projects that are mainly used for web work that will be thrown away in a couple of years or so, so any breakage wont be felt as much (and people working on those are used to broken things anyway). Any exception to that has ramifications that are felt for a long time - see Python2 vs Python3 as an example (...of what not to do - and note how many will even consider such breakage as natural and unavoidable, as if it was some sort of force of nature).
Unless this mentality and culture of breakage changes so that we can build stuff on solid foundations, things wont change.
Indeed. https://media.ccc.de/v/ASG2018-174-2018_desktop_linux_platfo...
It looks to be a pretty extensive codegen hook, generating bindings to the referenced runtime components on the fly based on the module metadata it finds on the system.
Apparently the C++ version uses IDL and an explicit codegen step instead: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
So, neither cargo nor the compiler really know of the paths, and cannot accordingly rebuild the sources when they change.
Perhaps they can only change when a corresponding version cargo does know about changes, anyhow, bypassing the build/module system with a proc macro is probably not something to be done lightly.
I was totally forgetting rerun-if-changed! This is indeed a barrier in the general case. I think that it doesn't affect this crate, but I am not 100% sure. Regardless, thank you!
I remember VB6 was also exceptionally good at this.
.NET was going to be what UWP is now, an evolution of COM, but then Java happened, and they went with something similar instead.
There are some references to how this all happened in the story of F# evolution, given that Don Syme was part of the team since the early days.
> If you are familiar with Rust, you will notice this looks far more like Rust than it looks like C++ or C#. Notice the snake_case on module and method names and the ? operator for error propagation.
Developing on and now for Windows just keeps getting better.