Arrggh! beware the upgrade...

You're mostly correct here. The prob is that anytime you apt install anything the source of the desired pgm is compiled on YOUR box. The dependencies list is part of the info in what you're installing.

But, if you have to replace xxx-2.3.4 with xxx-2.3.5 then all the installers freak out and want to un-install some, or a LOT, of what you already have because it's not "compatible".

This BS is why we see more and more apps distributed as ".run" style code - completely self-contained, requiring NO re-compile. So long as the Linux kernel doesn't change TOO much they'll Just Work. This is not necessarily in the best interests of "open source", but it IS in the bests interests of "I will run fine almost anywhere".

I first encountered this with "Balena Etcher" but just last week I got the much-larger "OpenShot" video-editor ... also a stand-alone executable. I think this is the future - a way AROUND the infinitely- deep dependencies rabbit-hole.

With now SUCH diversity in distros/sub-distros the "compile from scratch on install" model is NOT helping things.

Win does NOT have an inbuilt C/C++ compiler. It relies on an all-compatible core. You install ready-2-go executables and (with a little magic in the background) it Just Works. People LIKE that. No spending hours or days dealing with microscopic dependencies issues.

And yes, Deb installers ARE very picky. They are writ to try and ensure "solidity" and total compatibility. This is most important for BIG concerns ... but most of us aren't Bank Of America or the CIA.

It most certainly is NOT!

Compiling a .deb package is quite complex usually involving a docker based build environment, the source package (which is not the same as the binary package that is normally used and a degree of understanding and patience. We have a number of packages with local source patches so this process is very familiar to me.

It does not happen when you apt install $PACKAGE - that process simply installs the various files binaries, libraries, config etc. along with the dependencies. You can apt install a package on a system without a compiler.

Yes it is and the install operation will fetch any dependencies that you lack and will upgrade anything that is too old. The dependencies can specify the dependent package optionally with minimum and maximum or even specified versions.

The problem is that the universe of packages does not form a coherent set - this is not a problem with FreeBSD or NetBSD packages because they *do* form a coherent set.

This idea is detached from reality. Microsoft are committed to backward compatibility with existing application software, and maintaining that in such a fundamental rewrite is not possible.

Apple have never had the same compatibility goals, and have regularly killed application software backward compatibility.

I'll say it again - this does NOT happen. You have thoroughly misunderstood the root cause of the problem, which is that there the available packages do not form a coherent set in most (all?) Linux distros. Instead it is easy to find yourself installing package A which depends on library L < 1.0 and package B which depends on library L > 2.0.

Windows is not immune to this - in that world it is known as DL-Hell.

This does not happen with FreeBSD packages because they are all built together as a consistent set. The downside of this approach is that the package build takes several days and so the rate of package updates is limited.

For the record dynamic linking happens at runtime not install time, that's what makes it dynamic.

Debian does ensure consistency in this area (at least in stable & testing and I think usually in unstable too).

Trying to mix releases will (obviously) create inconsistency, however, as will taking packages from outside Debian, or deliberately taking an incoherent subset of offered upgrades.

AFAICT the Windows response to the problem is generally to co-install multiple versions of dependencies. Happens in Linux too - you can easily have multiple versions of a runtime library with different sonames, for example.

But that law is regularly broken by Microsoft anyway.

Indeed. Try running Power PC code on an intel platform...

I think you shouldn't be so dismissive.

When you look at what Microsoft is *actually* selling it is mostly a

Later apps will not run on earlier versions. Developers are quite capable of porting apps to a newer platform, if that is what is going to sell the most product.

Look at say Linux Mint. Most casual users would neither know nor care that it wasn't some version of windows. It behaves in a very similar way at user (rather than admin) levels.

What is crucial is that its API is completely different to Windows or OS/X. But look at say MATE. Built on top of Gnome, which is built on top of X-windows.

It is not beyond the bounds of credibility for Microsoft to create an API with exactly the same calls into it as in Windows, and call that Microsoft X Windows or whatever, and *sell* that to run on Linux. Programs would need relinking with that library in order to create linux executables, but that wouldn't be a huge issue for most vendors.

And if that relieves Microsoft of a layer of development they really don't want to do, and allows them to concentrate on what brings in the money, I don't see why they wouldn't.

What would be the worst issue is hardware drivers which would inevitably have to change as I don't think a compatibility shim would really work.

Full backwasswards compatibility for .exes is simply down to providing e.g. Virtualbox as standard equipped with whatever legacy version of windows people wanted. Until Intel chips become obsolete and the whole world goes ARM...

The world is changing, and what looks to be relevant is that ARM based hardware is where consumers are going. And you cant have legacy WINTEL apps on that anyway.

The more interesting question is where industrial computing is going. Apple still hold sway in the graphics and sound processing areas, but when it comes to CAD CAM I don't think windows really has a rival. But that is a real chicken and egg situation. People buy the computer for the application, and if it only ran on Linux, they would buy Linux (or a computer with it preinstalled). Just as they do with IBM .

Many other industrial apps are becoming heavily cloud based - an interface to a large corporate database is probably better dine by a web browser anyway, and who cares what is underneath.

The real issue for me if I was in charge of Microsoft, after the failure to crack mobile phones or fondleslabs is 'where are we going? What do we have that is a unique selling point? And how do we leverage that into future sales?'

Microsoft started out as a BASIC interpreter. Then a character based standardised operating system, where it was clear that the standardisation was far more important than the actual performance, stability or security.

If Microsoft decided that the new standard format was going to be a Windows look and feel window manager and an API stuck on top of a Linux core, I don't think most people would be unhappy about the fact it couldn't run legacy .exes. Most of them are still running XP anyway, because it was 'more than good enough' . And if wrapped in a sandboxed virtual machine, it's also secure enough.

Basically if existing applications could be rapidly re-linked, or recompiled to run on 'Windows on Linux on Intel, with legacy Virtual box' or 'Windows on Linux, on ARM' I think the apps guys would be happy. The hardware guys would be happy too, as all of their kit would be obsolete,so they would just bring out Linux drivers for *new* kit.

It sort of does with kernels ... AIUI the modules are linked at least. Though not necessarily compiled, as such.

Sure you can - and do. SWMBO has an M1 Mini - which of course has an ARM CPU. All her old intel-based software runs with no issues. Of course that means not just having Rosetta, but also all the libs and frameworks have to be supplied in both intel and ARM binary formats. That means twice as much testing at the dev stage for new OS versions too. Which is why at some point a future OS version will only come with the ARM versions, and all your old apps will become history. The alternative would have been to keep frameworks/libs avialable in 32/64 bit versions, and in PowerPC/intel/ARM versions. So, 5 or 6 versions of all libs and frameworks.

Windows is going to face something similar too, if they really want to push moving to ARM.

Definitely not compiled - we build kernels at work with added patches, compiling takes a surprisingly long time. Kernel modules are mostly dynamically loaded and I'm pretty sure are not modified in any way during installation.

It’d be a crazy thing to do. Huge amounts of effort to maintain compatibility, compared to the much easier strategy of just keeping the existing Windows codebase trundling along. Which is, demonstrably, what they’re actually doing.

And for what? The end result would be a Windows API implementation on top of a kernel designed for a completely different application layer.

Microsoft did it the other way around for WSL 1: implement the Linux API on top of Windows. It worked, but performance was bad because the Windows I/O subsystems just aren't performant enough - doing compiles on top of the Windows filesystem API was way slower that doing them on Linux on the same hardware.

For WSL 2 they junked that approach and just ran a Linux VM in HyperV, with some customisation for Windows-compatible graphics etc. This has much better performance. They do the same for Android.

MS are going further in that direction: the primary Windows system is actually another VM on top of HyperV, with secondary VMs for Linux, Android and a secure enclave VM to hold keys, check code signing etc.

So it's up to them how much they want to use Windows, or whether to do the heavy lifting on a different kernel on the same machine. They no longer need to care: run Windows when it makes sense, run Linux when it makes sense, whatever.

Theo

Better yet, it's all been done for them already by volunteers and released under LGPL so they could bundle it into their own proprietary product. It's called Wine, and indeed it's what I used to keep running some Windows software when I switched entirely away from Windows. I didn't have to pay M$ a cent for it either (which probably would be a problem for them, because people would just copy the design of a M$-branded Linux+Wine package to make free/fake alternatives).

There's NDISwrapper, which I've often been tempted to try but always decided it was a better move to find alternative hardware with working native Linux drivers.

Then you could run individual x86 programs via QEMU, which can run a program in emulation on ARM within the same operating environment as native code. I don't see why that wouldn't work with Wine too.

Sure enough, someone's started that for M$ already too:

Indeed CAD software is some that I've used Wine to run in Windows since I switched. I had to pull some original libs from Windows in so as to make 3D graphics work, but that wouldn't be an issue for M$ themselves like it is for the Wine developers.

Occasionally you see commercial Windows CAD programs that are actually _supported_ for running in Linux via Wine by the software company. If that attitude were more universal, Linux might be much stronger competition for M$ in the business sector.

They seem to be preferencing "cloud" stuff that runs on Google's OS, ahem, web browser, called Chrome. Very often on top of Android, which is a Googlified version of Linux. So in a way they're already doing what you propose, by sticking their new products together with lots of Google-glue.

On the cloud, nobody can run old software in the first place.

Would they really? Tell the hardware guys quick then that it all already exists (and has done for decades)!

Apple got away with it. 'Perfect' backward compatibility would be very NICE, but the company went with the sane route for damned good reasons.

This CAN be ok ... IF you offer some kind of 'fix', a re-compiler/port of sorts, to at least get the 'important' software to keep working properly. The CORP should do its best to get everyone over 'the hump' and can then cruise on in serenity.

In any case, I just don't think M$ really has a realistic CHOICE in the short/medium term. Winders is a TOTAL KLUDGE at this point and there's NO closing all the security and functional gaps.

Winders has constantly proven itself highly vulnerable to a variety of attacks. Govt/health, even large corp interests, have been seriously compromised. It's almost become "normal" at this point - though it SHOULDN'T be. M$ keeps greasing its politicians ... but I'm not sure how long that strategy can continue to protect them as this crap escalates out of control. The new, f***ed, world situation is likely to push all this over the edge as more State-funded players get involved.

The US DOD for a long time required all its software to be writ in ADA. I've fooled around with ADA, it's a HORRIBLY anal-retentive language. Managed to get basic list of lists thing to work, but it was NOT clear and easy. No wonder the DOD budget was so extreme.

Maybe Modula-3 ? Strongly-typed, but not so hideously anal. I've always liked Pascal (still write apps in it), but M2/3 is a bit more 'secure'. BTW, can't find ANY good modern M2/3 compilers for Linux that can be installed and work correctly. The Montreal compiler is best bet, but ... well ... it shouldn't be so hard. M2/3 translators, that convert everything to GCC, are NOT real. Gimme 'native' every time.

In any case, I'm gonna say Winders is DOOMED. It HAS to change, or die. Nothing in computerdom is forever.

No More Winders ? Wouldn't hurt my feelings. It's the Ford Pinto of operating systems. Popular, but explodes at the slightest tap :-)

ARM is very good. However x86 is very good as well, and very common. I'd buy an x86 Pi as quickly as an ARM Pi.

IMHO, M$ will mostly stick with x86 for now, with ARM as a side-project.

What M$ has to deal with is that, well, Winders Just Sucks at this point. It's HORRIBLY vulnerable to everything from the script-kiddies on up to State-sponsored super-hacks. Millions, maybe billions, in damages each year. The CHIP isn't the problem, it's Winders.

Time to legally NEGATE those "I Accept" legal protections in Winders. Joe Average, indeed Corp Average, does NOT know what it's agreeing to. Individuals/Corps/Govt deserve umpteen BILLIONS in compensation for its CRAP system.

Years ago, just for the heck of it, I read one of those agreements end to end. (I think it was for XP.) I found a clause that basically said that M$ reserves the right to walk into your machine whenever they feel like it, take a look around, and remove anything which, in their sole estimation, you should not have. Sounds like a back door to me - but then I've always maintained that automatic updates are one of the biggest potential security holes.

It was, now there's SAaS.

Linux and macOS also have a steady stream of vulnerabilities, so did the other Unix platforms when they were still relevant. Your hypothetical rewrite of Windows on a Unix kernel would not solve anyone’s security issues, it would just introduce an extra layer of complexity for vulnerabilities and other defects to nest in.

Widely-discussed estimates in 2019/2020 were that about 70% of vulnerabilities were memory safety issues, so a more realistic option for improving security is to rewrite key components into memory-safe languages. I don’t know what Apple or Microsoft’s (OS-level) response to this is but Linux is experimenting with support for Rust in the kernel, which is pretty promising.

There’s a lot of other OS components than kernels, though, and a lot of vulnerabilities in applications; so don’t expect that 70% figure to fall rapidly even when the kernel situation does start to improve.

That and the fact that W12 or W13 will probably only run from/in the cloud is what made me switch to Linux. Best decision in years software-wise.

-jw-

Yup. See my .sig below.