-
What I believe would kill such efforts, is Microsoft's dependency on keeping major proprietary software houses and hardware vendors (developing their own drivers) on board. Switching to a more POSIX-like kernel and interfaces would mean they'd have to port their code to that, which would lead to porting to additional systems like Linux (and obviously Mac OS, too) much easier, risking Windows' market share on the desktop in the future.
This is under the assumption Microsoft makes serious money from Windows which is something I doubt. Also keep in mind the entire dot-net ecosystem that Microsoft maintains to develop software for Windows. It could be benificial to let go of a lot of dead weight like that and concentrate on sectors which are actually profitable. Looking at the numbers here, you can see the income from Windows is not significant: https://www.kamilfranek.com/microsoft-revenue-breakdown/ -
Quote
This is under the assumption Microsoft makes serious money from Windows which is something I doubt.
"Loss leader"
It would be about keeping the user in the Microsoft ecosystem. -
I admit I lost track of this thread around a third of the second page of replies. . .
I have noticed that Linux vs Windows threads often end up in bickering. Why is this so? It's almost like religion or politics. This makes no sense. They're just operating systems! -
Anything with subjective views will have fans and detractors, and most fans/detractors have fixed opinions that they must get the other side to accept.
Come to think of it, objective views often go the same way too. Those things that don't end up in flame wars are just things no-one gives a toss about
-
Nonsense — that’s just typical non-fact-based, history-ignoring Apple bashing.without the users objecting to it to an extend that they buy something else.
They will never object regardless of how breaking the change is, because, you know, rounded corners, zero old fart's USB ports, non-existent repairability, and, of course, the logo on the lid... you won't find all those goodies neatly fitted in one package in other products.
(FYI, I was working as a full-time on-site Mac consultant during the transition from Mac OS 9 to Mac OS X.)
The switch to Mac OS X did, in fact, receive significant resistance, with many users outright refusing to switch for yeeeaaaars, and some did in fact jump ship to Windows XP systems. It was a rough transition, with the overwhelming majority of existing apps running only within the “Classic” subsystem (a loosely integrated virtual machine running a complete instance of Mac OS 9), and with the first native Mac OS X ports of many apps being really disappointing. (*cough* Quark Xpress *cough*) Many peripherals never got Mac OS X drivers at all, resulting in the common sight of, for example, a graphic design agency having one old Mac OS 9 system as the “scanning station” for their expensive slide scanner.
While Mac OS X eventually became a very worthy successor to classic Mac OS, it really wasn’t until around 10.2 that it was complete enough to be tolerable as a full-time OS for most people, and until 10.3 that it was mature enough to really be good enough for practically everyone. 10.0 and 10.1 were really more like extended betas, in that they were just missing too many features and third party apps. (One bit of praise, though, is that even the early versions were very, very stable. Even the developer releases were surprisingly devoid of crashes!) It is very telling that it wasn’t until the very end of 10.2’s life that new Mac models lost the ability to boot directly into Mac OS 9.
For really long-time Mac users like me (since 1992 in my case), there are still aspects of classic Mac OS that I sorely miss. (I don’t think any file manager on any platform, including modern macOS, is quite as nice as the classic Mac OS 9 Finder.) Don’t get me wrong, I wouldn’t want to go back to the crashiness of classic Mac OS. But in terms of user interface design, it was really, really good.
Where Apple stands alone, head and shoulders above everyone else, is in changing the hardware platforms their software (including the OS) runs on. The switch, under classic Mac OS, from 68K to PowerPC was very low-friction, and the Mac OS X-era switch from PowerPC to Intel was goddamned seamless, as was the switch to Apple Silicon. I find it really, really impressive that both classic Mac OS and Mac OS X disk images will not only work on different supported models, but across hardware platforms. (I.e. a single install of, say, 10.5 will run on 32-bit PowerPC, 64-bit PowerPC, x86, and x64, running optimized native code on all of them.) Apple has mastered the “fat binary” as no one else has. Mac OS X of course is the direct descendent of OpenStep (née NeXTstep), which itself was born on 68K and then ported to x86.
Microsoft, on the other hand, has been extremely adept at maintaining binary compatibility with very old applications, going to heroic lengths to keep even poorly written apps running well. If Apple can swap out the hardware platform without you noticing, it’s Microsoft that can swap out the core OS without you noticing. The whole “swapping out the NT kernel for Linux is impossibly difficult” people forget that the Win32 APIs have run on at least three disparate kernels: DOS (both in WfW 3.11 and Win 95/98/ME), WinCE, and NT. (And NT is itself basically a reimplementation of the VMS kernel from DEC, which is technically very different from DOS.) I’m not sure if Win16 runs on WinCE, but it did run on both DOS- and 32-bit NT-based Windows.
When I say “heroic”, I’m not kidding: when prepping Win 95, Microsoft found tons of popular apps that relied on undocumented behavior, and in some cases outright bugs, in Win 3.1. Rather than have those poorly written apps fail on Win 95, they actually built in compatibility shims for those apps, one by one, to keep them running. For example, for some popular game, the compatibility shim actually changed how the memory manager worked, to make it reproduce some weird bug in 3.1. The downside to this approach is that it unwittingly encouraged developers to ignore disciplined coding practices. This really came to bite them when Vista came out and tons of apps broke because they were doing things they never should have done. (Apple was, and is, the opposite: their developer docs expressly state to avoid using undocumented behaviors, because those can break compatibility. If you follow the rules it’ll work and/or recompile going forward, but if you break the rules, you can expect your software to break in the future.) -
How the hell does LinkedIn make more than half as much revenue as Windows?!?What I believe would kill such efforts, is Microsoft's dependency on keeping major proprietary software houses and hardware vendors (developing their own drivers) on board. Switching to a more POSIX-like kernel and interfaces would mean they'd have to port their code to that, which would lead to porting to additional systems like Linux (and obviously Mac OS, too) much easier, risking Windows' market share on the desktop in the future.
This is under the assumption Microsoft makes serious money from Windows which is something I doubt. Also keep in mind the entire dot-net ecosystem that Microsoft maintains to develop software for Windows. It could be benificial to let go of a lot of dead weight like that and concentrate on sectors which are actually profitable. Looking at the numbers here, you can see the income from Windows is not significant: https://www.kamilfranek.com/microsoft-revenue-breakdown/
If I’d been asked to guess, I would have assumed that LinkedIn was somewhere under a percent, not 7%!!
-
Creating a new Windows OS based on a microkernel or a BSD-derived kernel, capable of running older Windows binaries (including all current OS APIs/ABIs and services) via virtualization (a derivative of the existing Windows kernels designed for backwards compatibility), now that would be interesting, and technically at least somewhat feasible.
Modern NT kernel already has some elements of microkernel design - for example it can survive graphics driver crash and restart the driver without rebooting OS (and no BSOD of course), also NT design has a concept of executive subsystems which can run concurrently and each provide it's own userland - Win32 API is provided by CSRSS subsystem, which is just one example of such subsystem - AND since those subsystems run as usermode processes (as far as kernel is concerned), OS can simply restart it if it crashes. Think about running multiple different "init" subsystems in parallel in Linux without one getting in the way of another, and having ability to restart any of them on the running system without affecting the rest of the OS. This has been a design feature of NT kernel since the very beginning. -
Yes, Windows NT has been a hybrid kernel right from the start. It got designed at about the same time as Linux, and Andrew Tanenbaum himself thought that it was a better design than Linux. Of course he was somewhat biased by its promotion of microkernels, but the monolithic nature of Linux was never really seen as particularly modern. Linux does work remarkably well in spite of that, and I'm glad it exists, but I wouldn't call its design "modern" by any means.
You'd need to know the Windows NT kernel extremely well to figure out if it's actually worth replacing it with something else at this point, assuming for the same purpose (ie. essentially desktop computing, I'd forget about Windows server, which may be another matter). Very few people, even working at MS, actually now it that well - it's a rather small circle, so I'd be surprised if those here that seem to claim having a definite opinion about it did. Eh, who knows.
But back on track - for this thread - in the end, it looks like the OP's question was mainly triggered by the hiring of Lennart Poettering by MS, and once he stated that point, in turn it triggered some kind of flamewar and insults, which is unfortunate, but it was to be expected. IMO, the very reason this thread was started made it "political" by nature. Just a thought. -
To use the new windows AI Studio tool, you must first install Linux. No, it's not a joke
Never underestimate the importance of Linux, even for windows development.
https://www.windowscentral.com/software-apps/to-use-the-new-windows-ai-studio-tool-you-must-first-install-linux-no-its-not-a-joke
https://marketplace.visualstudio.com/items?itemName=ms-windows-ai-studio.windows-ai-studio&ssr=false#overview
-
The strangeness is that more cross-development isn't done. Developers should be using the best environment for developing, which isn't necessarily the target. I've done ground-up Linux from source on Windows and that worked a lot better than if I'd tried the same from Linux (or, horrors of horrors, on the target device, which is what seems to be the rage). Were I embedded in Linux and comfortable with the tools, I would prefer to target Windows from there. Currently I'm targeting Android from non-Android - perhaps I should be doing it all on a phone.
-
It's not developing for Windows on Ubuntu, but using Ubuntu in WSL to run software components for development for Windows on Windows. I guess it means there is some ML library somewhere which hasn't been ported to Windows yet so they came up with this kludge.
Building Linux on Windows sounds like an exercise in applied masochism. -
Quote
Building Linux on Windows sounds like an exercise in applied masochism.
Tried it? Things have moved on since then, but if I would happily do it again with current stuff (but not current Windwos
). Doing it that way is a bit like doing embedded systems using a standard C compiler as opposed to using the Arduino IDE.
-
I forgot to mention, MS has also released Visual Studio Code for Linux.
https://en.wikipedia.org/wiki/Visual_Studio_Code?useskin=vector
And the list goes on...
-
Quote
Building Linux on Windows sounds like an exercise in applied masochism.
Tried it? Things have moved on since then, but if I would happily do it again with current stuff (but not current Windwos ). Doing it that way is a bit like doing embedded systems using a standard C compiler as opposed to using the Arduino IDE.
I think of it as the opposite, since to me, a standard C compiler is a native GCC or Clang; not MSVC++ or the various GCC/Clang ports to Windows.
I do think of Intel CC as having a standard C compiler also, but building the Linux kernel with it can be iffy.
That said, I've used GNU toolchains so much not even autotools fazes me. In any case, they're just tools: whatever works and works for you is okay in my opinion, even if I myself don't/wouldn't do it with those. -
It was a standard gcc, not Microsoft rubbish.Quote
the various GCC/Clang ports
What's up with a port? They do the same thing, using the same code, producing the same result. -
Case-insensitive file system support, some character set issues wrt. files with non-ASCII characters and so on, wide string constant character set support (UTF-16 is not a valid wide character set), and so on. AIUI the Linux kernel does not currently have files or directories in the same directory only differing by name case, nor any using non-ASCII characters in their name, nor uses wide character strings in the sources, but those won't be true in general.Quotethe various GCC/Clang ports
What's up with a port? They do the same thing, using the same code, producing the same result.
By definition, the behaviour of the toolchain differs.
Note, however, that there is absolutely nothing wrong in using a port, or using Windows. It does mean one has to consider the target OS/arch peculiarities before blaming the project or sources, but that's it. I just perceived your analog as weirdly upside-down compared to my own views and experiences, where Windows is the more Arduino IDE -like system, and Linux/BSDs/POSIXy systems the true tool for basing software development on. Not a value judgement, only my current view, mind you. -
Quote
I just perceived your analog as weirdly upside-down compared to my own views and experiences, where Windows is the more Arduino IDE -like system
The reverse. We did consider running Linux workstations (and, later, a new chap was Linux and useless, but I guess he would have been whatever OS), but our tools which we knew like the back of our hands were Windows and many things we used didn't exist on Linux.
But the primary driver, or rather the decider, was that we didn't want to end up as happened with a previous product where some tool got changed and product support basically had to stop. So building everything on Windows ensured that there was nothing that was dependent on the host OS - with Linux it's a bit like (on Windows) loading a registry branch and trusting that neither will the real registry be affected, nor the new branch being affected by the existing registry. So anything we used - from uboot through the rootfs, apps, kernel drivers and all the tools necessary to create those - was built entirely from source with zero outside dependencies. But we were embedded system developers and the norm was that the target was not the development host.
[Speaking of which, IMO if web developers want to try their stuff out on their development PC they should be forced to use a Pentium.] -
Here's some technical arguments, with software engineer hat on. Robust software systems are designed by partitioning, abstraction and encapsulation of functional layers, with well defined interfaces between them. A set of bricks to build a cohesive whole. At the root of the tree, a single kernel is responsible for managing system resources, such as memory, storage and io devices. Any of the bricks and layers could be replaced with something completely different, so long as the interfaces and functionality between them remained the same. The unix and variant operating systems were designed using such classic software engineering principles. Compact. lightweight and robust, nothing that is not needed, with a complete and visible audit trail right across the system. The downside being that the various parts of the system and their startup, each have their own config files, making it more difficult to setup and manage, without operating system theory awareness.
The issue is of course, that the admin tools and setup files, like the C language unix is written in, are pretty low level and require a level of skill and basic os knowlege to manage them. Some os's, like Solaris and FreeBSD, overlay a service admin layer over the basic system, to make it easier to manage. On Solaris,, that's svcadm and svcs, FreeBSD, the service utility, AIX, smitt and others. The key thing being that those tools are just an added layer on top of what is already there, so it's still possible to manually edit configurations, look at plain text log files etc. Systemd, a kernal managing the kernel, on the orher hand, seems to have it's entrails into every part of the system, from startup, right through to the X desktop. A nightmare to debug. Hence, abusing not only system enginering, but also basic os design principles.
As a cynic, I saw systemd as a power grab to gain more influence into the direction of travel for Linux, but most distros have succumbed to it. I guess those that pay the piper, (funding) call the tune. In summary: Over complex, overblown, and uneccessary...
-
Here's some technical arguments, with software engineer hat on. Robust software systems are designed by partitioning, abstraction and encapsulation of functional layers, with well defined interfaces between them. A set of bricks to build a cohesive whole. At the root of the tree, a single kernel is responsible for managing system resources, such as memory, storage and io devices. Any of the bricks and layers could be replaced with something completely different, so long as the interfaces and functionality between them remained the same. The unix and variant operating systems were designed using such classic software engineering principles. Compact. lightweight and robust, nothing that is not needed, with a complete and visible audit trail right across the system. The downside being that the various parts of the system and their startup, each have their own config files, making it more difficult to setup and manage, without operating system theory awareness.
The issue is of course, that the admin tools and setup files, like the C language unix is written in, are pretty low level and require a level of skill and basic os knowlege to manage them. Some os's, like Solaris and FreeBSD, overlay a service admin layer over the basic system, to make it easier to manage. On Solaris,, that's svcadm and svcs, FreeBSD, the service utility, AIX, smitt and others. The key thing being that those tools are just an added layer on top of what is already there, so it's still possible to manually edit configurations, look at plain text log files etc. Systemd, a kernal managing the kernel, on the orher hand, seems to have it's entrails into every part of the system, from startup, right through to the X desktop. A nightmare to debug. Hence, abusing not only system enginering, but also basic os design principles.
As a cynic, I saw systemd as a power grab to gain more influence into the direction of travel for Linux, but most distros have succumbed to it. I guess those that pay the piper, (funding) call the tune. In summary: Over complex, overblown, and uneccessary...
Abstraction. Encapsulation. Well defined interfaces. Yep, that makes for reliable modules. Each little piece has no confusion about what to do and how to do it.
But ah that downside. All those config files, that require a system expert to understand and manage. So the overall system has the same defects as the spaghetti code that all of these design principals were intended to eliminate. That old spaghetti code was a rice bowl for those who developed the code and therefore the concept was strongly defended by those whose rice bowls were threatened. Same thing seems to be happening here, just the rice bowl has changed.
Some day a genius is going to formalize a theory of complexity which says that complexity is conserved. Eliminating it in one place adds it somewhere else. -
Quote
But ah that downside. All those config files, that require a system expert to understand and manage.
Why? You could have an app that deals with all that stuff - major Linux apps tend to basically be front ends to many sub-apps, after all. The normal user wouldn't need to dick with the config files but just use the config app to manage the config. Hell, it could even be (gasp) a GUI! But those files still exist if a guru wants to roll their sleeves up and surgically excise something.
Someone around here pointed to an open source PDF printer ( https://www.bullzip.com ) and if you look closely it's requires a handful of sub-apps installed in order to work. Why is that any different to managing configs, except in scale (and looking nice)? -
Some day a genius is going to formalize a theory of complexity which says that complexity is conserved. Eliminating it in one place adds it somewhere else.
It is not the complexity of systems, it is the complexity of interactions. Humans do not do "simple".our tools which we knew like the back of our hands were Windows and many things we used didn't exist on Linux.
That's the difference between us: for me, it is exactly the reverse.
(And do note that I was a very heavy Windows user in the '95-NT era, with commercial licenses to several software packages like Photoshop and Macromedia Director. So I'm not saying this as someone looking at Windows from the outside; this is just because of my own experience and having shifted from Windows to Linux in the early noughties.)So anything we used - from uboot through the rootfs, apps, kernel drivers and all the tools necessary to create those - was built entirely from source with zero outside dependencies. But we were embedded system developers and the norm was that the target was not the development host.
Yup. When I did that myself around the turn of the century (for servers I maintained myself, on the same architecture/not cross-compiling), I participated in Linux From Scratch to understand all those dependencies and how to avoid say gcc and glibc "leaking" from the host to the target. Cross-compiling solves that, but for more complex software packages (especially with autotools trying to detect what is available on the target by scanning the host) it is somewhat more work to get right.
Today, it is extremely useful when you target ARM-based appliances (routers etc; OpenWRT cross-compiles everything) and SBCs, using much more powerful many-core x86-64 as a build host, so the skills and understanding are still very applicable. Not many who do such integration commercially understand the issues, though – looking at their SDKs and GPL'd parts of their tree, Asus routers being a particularly painful example – so I do often recommend reading LFS to understand the core basis of Linux integration, and associated issues.[Speaking of which, IMO if web developers want to try their stuff out on their development PC they should be forced to use a Pentium.]
Agreed!
Single- and dual-core SBCs are a good alternative for today; as are Chromebooks and similar. If you look at some of the self-contained examples I've discussed here, like my Finite Impulse Response Analysis page, you'll notice that the calculation work is not done in the event handler, because that would freeze the UI, but in a "background" JS triggered by a timeout. Current JS engines are very efficient and fast, and they prioritize the event handlers over background/timeout events, so it works fine, just slower, even on slow machines. (This was in the context of using browsers for such tool pages, requiring no internet connection, everything contained in a single file that works fine even locally.) -
- MS has implemented SSH client in windows powershell.
- MS will implement the "sudo" command in windows powershell.
https://www.phoronix.com/news/Microsoft-Windows-sudo
https://www.phoronix.com/news/Windows-SSH-Official
I have no doubts about what MS is planning to do...
-
Such a GUI tool will work much better when the config files are stored in a singular entity compared to a whole bunch of seperate files spread across the system which may even change format for no good reason. Gnome already has a configuration file like that.QuoteBut ah that downside. All those config files, that require a system expert to understand and manage.
Why? You could have an app that deals with all that stuff - major Linux apps tend to basically be front ends to many sub-apps, after all. The normal user wouldn't need to dick with the config files but just use the config app to manage the config. Hell, it could even be (gasp) a GUI! But those files still exist if a guru wants to roll their sleeves up and surgically excise something. -
I dunno. That’s basically what the Windows Registry is, and I think that’s proven to be a mistake in the long run. Individual config files, located correctly for the scope they should apply to, seems like the better approach IMHO.