I’d frankly be surprised if you were able to muster the talent/willpower for something like this.
1. Most of the people able to do this sort of thing probably work in Linux/FreeBSD/etc land.
2. You’re really working doubly against the tide here. You have proprietary stuff on the Mac and on the Windows side.
3. (Personal opinion) Dear God that sounds like a lot of work for something that is a fairly unfriendly experience on a few levels.
At least they have Linux/BSD people trailblazing here (they acknowledge as much).
If they can actually pull this off without changing something deeper than a what’s already exposed to kernel driver developers without horrible hacks or inefficiencies, I would be surprised.
I feel like there should be a common etiquette rule on HN where if you don't care about a particular project / technology / initiative that you skip commenting and move on. For example, your comment says that this initiative will not work out. Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Even if there is a convincing argument that this initiative could theoretically be successful, would that convince anyone to use the technology? No, it would not.
I would be with you except for the "Disclaimer: Not really a kernel dev of any sort." bit at the end. Skepticism from people not in the field is far less meaningful (as is booster-ism, for that matter).
You’ll only know by doing it. It is especially blind because, as you say, it’s bringing two black boxes together. It’s a sufficiently major point of interest to such a large number of people that I hope people feel motivated to try.
I feel that this is "rule" would be either incredibly harmful or effectively empty.
The post you are criticizing is quite obviously not an example of "don't care", nor is your "summary" anywhere close to accurate. Yet you want to remove such posts? Do you want to remove all constructive criticism or debate while you are at it? Only echo chambers allowed?
hey, I'm the person embarking on the project, thanks for checking it out!
one of the big reasons I started this project is that I've really been wanting to work on a project that deals with bootloader and kernel level code, and doing Windows bringup on the M1 seemed like a really interesting thing to tackle.
While initial progress might be slow, it is indeed happening, I'm planning to post an update tonight actually, but I realize you're busy so feel free to check the website whenever you have a free moment. (It's basic I know i'm not a web person lol)
Unfortunately, I was born little after NT was already introduced :)
It indeed is really an impressive feat of engineering, but really almost all existing OS platforms are essentially from pre-2000s. Even fushcia's magenta (iirc LK was inspired by BeOS, the author worked at Danger prior).
Next Steps: Get the Windows GUI + Win32 APIs + backwards compatibility layer to run on WSL2. Port the best parts of NT to the Linux kernel.
Final Step: Replace NT+WSL2, with the Linux kernel. Use the current devs/tests/etc working on NT for better ROI (from a business customer perspective the NT kernel is no longer a positive differentiation).
I know where you’re coming from, but the reality is MSFT no longer has that ability.
1. Desktop/laptop OS based revenue is in decline. There is no reason for it to go up again. Between Chromebooks on the cheap end, MacBooks on the expensive end, and iOS and Android supporting an increasing number of productivity and content creation apps “with a free OS”, there is not much room for new and soon old companies to pay for OS licenses (other than legacy custom code - being “actively” migrated to Azure).
2. Because of Azure competing with AWS and GCP with a Linux distribution, MSFT already has teams with Linux expertise and working on improvements. This can’t get “extinguished” people just migrate Linux workloads elsewhere.
This leaves us with:
> Wonder what would come next
Likely more improvements to the Linux kernel from MSFT. Maybe even a big push of Linux to Rust (with Amazon and Google as partners). A bigger push from MSFT to get hardware manufacturers to build open source drivers into the kernel directly (so MSFT doesn’t need to fund the work for each of them). Maybe even “Windows” over Wayland. Basically windows/linux rather than gnu/linux.
Likely more applications built on DirectX + Linux native (ie without Win32). Maybe even Office without Win32. A Windows compat layer for gtk or qt or Flutter or whatever is good at the time. Even if only for new application creation.
Likely, given the direction of gaming at MSFT, DirectX (or whatever they call it) competes with Unreal for cross platform game stuff. For the next big revenue stream for MSFT from game devs (including their internal studios).
Are those final two steps (next, final) pure speculation on your part? I'd be surprised if Windows threw out NT and moved to Linux kernel, and yet at the same time, it sounds like a great idea IMO (WSL2 + Docker is already a great experience for software development).
Not the parent commenter but this isn’t as far fetched as it seems. Since much is abstracted by the Win32 and other APIs, they could write something to do exactly this.
This seems unlikely to me. For example, the threading model (non-forking) and file system semantics (locking, permissions, etc.) are wildly different. You’d need a complex compatibility layer and effectively two classes of applications (legacy and linux-y).
If they can build WSL2, and WINE can be built without MSFTs help, I’m not sure what is left to doubt.
At that point the only question is “Is the one time cost of building the compat layer less than the ongoing cost of improving NT? Building windows specific drivers? Etc”. “One time cost” is always going to win the negotiation in the long run.
1. Most of the people able to do this sort of thing probably work in Linux/FreeBSD/etc land. 2. You’re really working doubly against the tide here. You have proprietary stuff on the Mac and on the Windows side. 3. (Personal opinion) Dear God that sounds like a lot of work for something that is a fairly unfriendly experience on a few levels.
At least they have Linux/BSD people trailblazing here (they acknowledge as much).
If they can actually pull this off without changing something deeper than a what’s already exposed to kernel driver developers without horrible hacks or inefficiencies, I would be surprised.
Disclaimer: Not really a kernel dev of any sort.