Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

blog.jreypo.io

Post reply on HN
Print view View original

71–80 of 123 posts

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#71

Post by snomad »

danellis wrote: post #55
beebmam wrote: post #46

Earlier quoted context omitted.

That's unfortunately their loss in my opinion. Windows has a pretty awesome development story, far better than Apple's authoritarian hold on what software can be run and distributed for that platform. Moreover, gaming is great on Windows, and always has been, and WSL2 is extremely slick.

> Apple's authoritarian hold on what software can be run and distributed for that platform What does that mean? I've never needed Apple's permission to run any software on macOS.

Actually, they had an outage when Catalina was released because Macs phone home before starting 3rd party software.

https://9to5mac.com/2020/11/15/apple-explains-addresses-mac-...

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#72

Post by wsc981 »

vermilingua wrote: post #35

A MS dev writing a blog on building MS’ own distro of Linux on his _Macbook_ must have Ballmer sweating bullets.

> A MS dev writing a blog on building MS’ own distro of Linux on his _Macbook_ must have Ballmer sweating bullets.

Not to mention throwing chairs.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#73

Post by pjmlp »

dividedbyzero wrote: post #67
pjmlp wrote: post #60

Earlier quoted context omitted.

Sinofsky and co. are also to blame for Longhorn sabotage of using .NET, and most likely trying to bring Midori stuff into Windows. Now Project Reunion, sorry Windows 11, is trying to fix the path started with Windows 8.

Longhorn sabotage, Midori, Project Reunion? Could you give a bit more background for those of us like me who aren't up to date with Microsoft internal projects and politics?

To fully get where I am coming from, you have to go back to when .NET was released.

.NET was supposed to be the great reunification of VB, C++ and COM runtimes, then also got a Java touch into the mix and .NET happenend (initially was known as Ext-VOS).

https://docs.microsoft.com/en-gb/archive/blogs/dsyme/more-c-...

Hence why CLR is just like WASM + GC if you prefer a modern comparisasion.

If you go back into web archives, when Visual Studio.NET was released, it was going to be .NET everywhere, across the whole stack.

However a big management mistake happened, .NET was part of DevTools business unit, while C++ was kept under WinDev, up until Satya started to change the culture, it has been pretty much WinDev vs DevTools.

So Managed DirectX comes, eventually gets killed, XNA and Silverlight take over Windows Phone 7, get killed by WinRT and DirectXTK and so on.

Going back to the originally statement, if you Google for why Longhorn did not work out, you will find many .NET blaming.

https://hackernoon.com/what-really-happened-with-vista-4ca7f...

Yet Android, ChromeOS, Midori are examples of what happens when actually everyone works into the same direction bringing an OS into production.

Joe Duffy does some remarks on his two talks, where he hints at why it was a failure to fight Windows culture

"Systems Programming in C# " - https://www.infoq.com/presentations/csharp-systems-programmi...

"Safe Systems Software and the Future of Computing" - https://www.youtube.com/watch?v=CuD7SCqHB7k

Note that for some time the Asian Bing nodes were actually running on top of Midori as production test.

A big decision of Vista, was to replicate the .NET design using COM instead (hello WinDev), hence why all major modern Windows APIs are now COM based.

Windows 8 doubled down on that by introducing WinRT, with AOT compiled .NET and C++/CX using COM as the future Windows runtime, this was a point of friction, as .NET Native isn't 100% compatible with regular .NET, and many C++ devs desliked C++/CX extensions (later C++/WinRT replaced C++/CX, but that is another story).

So to sort out all the adoption chaos, Project Reunion was born, which is basically merging the COM improvments brought by WinRT and app sandbox into Win32, and forgeting the split ever happened.

Even Reunion has had a couple of hicups, it started as XAML islands, it became eventually clear that that alone wouldn't do it, thus Project Reunion.

https://blogs.windows.com/windowsdeveloper/2020/05/19/develo...

And now a year later, it was renamed as Windows App SDK.

https://blogs.windows.com/windowsdeveloper/2021/06/24/what-w...

Note that many System C# features now live in C# 7 and later versions, and were also in the basis of C++ Core Guidelines.

Also note an example of the internal competition with the pleothora of GUIs being done now, Forms, WPF, WinUI, MAUI, Blazor, React Native for Windows.

Maybe if all divisions worked more together in Longhorn, the project would actually happened and Vista wouldn't have been needed, nor the strong emphasis on COM that it started.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#74

Post by AshamedCaptain »

Osiris wrote: post #6
l0b0 wrote: post #4

It seems almost inevitable that Windows will eventually become a Linux distro. Microsoft could replace incredibly resilient cruft like NTFS with EXT4 or ZFS and the registry with human readable configuration files. On the other hand, they could replace Bash with PowerShell and hopefully pressure various orgs to adopt some sensible subset of configuration formats.

I'm not so sure. Windows driver model is vastly different than Linux. Linux drivers have to be compiled for every kernel release. Windows drivers that are more than a decade old can still be installed and work correctly.

any example of a decade old driver that will install? not even the .cat signature algorithm will be the same, and windows enforces signed drivers these days.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#76

Post by goodpoint »

zaptheimpaler wrote: post #5
l0b0 wrote: post #4

It seems almost inevitable that Windows will eventually become a Linux distro. Microsoft could replace incredibly resilient cruft like NTFS with EXT4 or ZFS and the registry with human readable configuration files. On the other hand, they could replace Bash with PowerShell and hopefully pressure various orgs to adopt some sensible subset of configuration formats.

I love the idea of windows registry though, I hope it stays. With linux, i have to to poke around the file system or google "package X config location" and many programs have their own idiosyncratic rules around which config paths take precedence over others. Windows registry as implemented is not the best, but the idea of something like a central sqlite db for config is great.

On the contrary, having configuration in text files allows using different formats depending on the needs of the application.

Also, it allows the use of git to track changes on config files and even replicate them across hosts.

etckeeper for /etc is wonderful.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#77

Post by addicted »

paavohtl wrote: post #62
danellis wrote: post #55

Earlier quoted context omitted.

> Apple's authoritarian hold on what software can be run and distributed for that platform What does that mean? I've never needed Apple's permission to run any software on macOS.

Unless you go out out of your way to disable code signing using the terminal & a root account, macOS will only run code signed by an Apple issued certificate [1]. It will also phone home [2] every time a binary is ran for the first time. [1] https://en.wikipedia.org/wiki/Gatekeeper_(macOS) [2] https://apple.stackexchange.com/a/391399

Doesn’t Apple provide a system preference option to disable gatekeeper completely (set to running signed applications by default, and it also allows you to limit apps to App Store only).

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#78

Post by sudosysgen »

gsich wrote: post #14
sudosysgen wrote: post #7

Earlier quoted context omitted.

DKMS and driver segmentation enables 10 year old drivers to mostly still work on Linux too.

Yes. Sometimes those old drivers can't be compiled with newer headers.

And sometimes old drivers won't work on Windows 10.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#79

Post by carlosf »

beebmam wrote: post #46
azinman2 wrote: post #43

Earlier quoted context omitted.

Meanwhile no one at Apple is using windows unless they have to for very specific software.

That's unfortunately their loss in my opinion. Windows has a pretty awesome development story, far better than Apple's authoritarian hold on what software can be run and distributed for that platform. Moreover, gaming is great on Windows, and always has been, and WSL2 is extremely slick.

+1

During the past three years I went from being my workplace's Windows hater to ditching Linux in my personal machines in favor of Win + WSL2.

Re: A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution

#80

Post by marcodiego »

yjftsjthsd-h wrote: post #38
marcodiego wrote: post #28

Earlier quoted context omitted.

Linux drivers can work for much longer than a decade once they reach mainline. Out of tree drivers are another story.

Right, but Windows drivers are (all?) out of tree and have been for decades; they'll never get every vendor to change that.

And this story that windows drivers work forever is a rosy tinted view of the world. Many drivers (my ltc scanner) stopped working working from win9x to xp. I saw an USB projector driver break when a system was updated from win 7 to 8. The same device worked as a fb device out of the box on my rockpi4. And windows drivers are platfrom dependent, the same driver will nit work on 32/64 systems or arm/x86. Linux is entirely another world.
Post reply on HN