Live data from Hacker News

Is CBL-Mariner going to become Microsoft Linux?

boxofcables.dev

121–130 of 242 posts

Re: Is CBL-Mariner going to become Microsoft Linux?

#121
post #58

Earlier quoted context omitted.

> Ubuntu is the developer distro after all I'd have assumed Arch and friends.

> > Ubuntu is the developer distro after all > I'd have assumed Arch and friends. I'm a huge Arch (and NixOS) user. But one of the things that I think is difficult about Arch in an enterprise is that by design it is difficult to standardize enterprise tooling around. Ubuntu, on the other hand, has a bunch of defaults that can be more reliably be predicted for in an enterprise. I'm a security engineer and I've thought…

I think I'm smelling what you're stepping in. What made me assume arch was the ease at which everything is 'there' without a snap or ppa via the AUR. Thanks for taking a moment to share a different perspective with me.

I've been trying to have a similar strategy to you with regards to enterprise long-uptime application deployments. I target RHEL and Debian Sid because they move at a almost glacial pace and have quite a bit of documentation.

Do you ever wonder what the trajectory of Microsoft and Canonical looks like with regards to an M&A perspective? It would be a good contender to counter Red Hat's dominance in the enterprise space.

Re: Is CBL-Mariner going to become Microsoft Linux?

#122
post #100

Earlier quoted context omitted.

PRs to improve zstd's embarrassingly slow decoder require you to assign your firstborn to Zuck and new Microsoft is selling me a subscription to use my laundered open source code to generate autocomplete suggestions in their closed-source IDE that pegs 2 cores and needs 4 gigs of memory (on the remote machine only) to edit 50k text files over ssh

Zstd's decoder is very very fast for what it does, what ideas do you have to improve it? It's unlikely to beat lzo family on decompression speed, but that's a different class of compressor entirely. And probably there are still some more tricks zstd can learn from closed-source Oodle leviathan, but i don't think much more can be learned.

I expect any "perform a conversion of some sort on a byte stream" implementation that uses 0 SIMD instructions and is not memory bound is leaving a lot of performance on the table, especially if one is permitted to mess with the design and layout of the input to make it more amenable to vectorized consumption. I cannot confidently claim that we're missing a a >2x speedup in this case though, it may be as low as ~1.3x or something.

Re: Is CBL-Mariner going to become Microsoft Linux?

#123

Earlier quoted context omitted.

I fully disagree with this. WSL has only from my perspective gave Linux Desktop a bad name due to many poor choices and performance. It has gotten better, but you still need someway to deploy Windows and Windows deployment automation sucks and is bloated. Why would a user want to run a lightweight desktop inside a legacy spyware one?

Because Windows is super easy for the vast majority of people to use and desktop Linux isn’t. Windows deployment isn’t bloated, it just has a ton of actual functionality that real users want and that doesn’t come for free. The UX for the admin is also super nice, with tons of online articles and communities with people who are willing to help you do what you’re trying to do, as opposed to tell you why what you want i…

> Windows deployment isn’t bloated, it just has a ton of actual functionality that real users want and that doesn't come for free

A base Windows installation takes up a lot of space mainly because of Microsoft's compatibility commitments and the implementation strategy it uses to maintain them, and to some extent the way libraries are typically distributed. Neither OS features, nor hardware compatibility, nor the selection of included applications has much to do with that. Microsoft delivers some real value through their compatibility commitment, but it's a different thing than functionality.

> The UX for the admin is also super nice, with tons of online articles and communities with people who are willing to help you do what you’re trying to do

This is frankly a stunning claim. From local configuration being the hodgepodge of many generations of GUIs to the incompleteness to the painful slowness of completing a task through visual imitation to the fundamental hostility automation to the slowness and incompleteness of PowerShell to the absolutely anarchic nature of software management on the platform, administering Windows machines is a cumbersome, manual mess.

> communities with people who are willing to help you do what you’re trying to do, as opposed to tell you why what you want is bad.

This is an illusion afforded to those who come to both operating systems with Windows-centric expectations. In this very forum, you can find Windows users who respond to posters who complain about defects that come up with Microsoft's official Windows port of OpenSSH by telling them they never should have tried to use rsync to transfer files between Windows machines.

With any operating system, there will always be people who respond to questions involving solutions that are at odds with the paradigm, strengths, or cuatoms of the operating system with advice to re-think the problem. (And sometimes, they'll be right!)

Re: Is CBL-Mariner going to become Microsoft Linux?

#124
post #70

Earlier quoted context omitted.

> The future of desktop Linux is a VM under Windows. Is there really any demand for this though? What Linux gui apps exist that windows users want/need? Enough that Microsoft sees an addressable market large enough to get roi? The inverse seems to have way more practical use cases that could actually drive revenue - games and legacy business applications (as mentioned in the esr prose).

I got quite excited when I heard about wslG and rushed to install it. Never used it since. I did have the Linux version of dBeaver installed that way but there is little/no difference just running the native Windows install for that. The only use I can really think of is doing cross-platform GUI development, but even then MS will say "hey look, native Linux windowing support in WSL" and also "Not yours, no linux vers…

I use it for running the automated browser tests with my frontend stuff at work. The code is in WSL, and running Cypress or whatever with browsers in Windows with code in WSL seemed to not work. But install Chrome/Firefox in WSL, and it works great with WSLg. Chrome on Linux also attaches to the debugger in VSCode, which doesn’t attach to the Windows version of Edge.

Re: Is CBL-Mariner going to become Microsoft Linux?

#125
post #118

Earlier quoted context omitted.

I have defaulted to Ubuntu for familiarity reasons, but recently I got to learn - the procedure for upgrading to a newer release of ubuntu it you run sed as root to fix your sources.list, then you do-release-upgrade, but it doesn't work because it has an undocumented dependency on pciutils - at this point i should be used to this pciutils thing since ~all software has undocumented dependencies on autoconf, automake,…

>snap will just install broken package updates for you and is incapable of undoing this operation by design I no longer recommend Ubuntu for this reason to people looking to get into Linux for the first time for developer-adjacent reasons. My recommendation is now Mint or Pop_OS, as they are effectively Ubuntu without Snap. Edit: I am not blindly against snap, or against its idea outright. I understand what it is for…

Cracked me up the other day when Ubuntu in WSL2 told me that I needed to install Firefox via Snap if I wanted to use it, but Snap doesn’t work in WSL2 because systemd isn’t being used.

Re: Is CBL-Mariner going to become Microsoft Linux?

#126
post #77

Earlier quoted context omitted.

You can install RPMs on Debian but most probably you will run into filesystem-level conflicts with DEB packages. But if you are rebuilding your own Debian-based distro, nothing prevents you from packaging everything into RPMs instead of DEBs and that's see. Not that I see the point of that, though.

Yeah but Debian’s package repository is all deb based. It would be difficult to translate precisely into RPM - they have different tooling and semantics.

There does exist a conversion tool between them:

https://en.m.wikipedia.org/wiki/Alien_(file_converter)

Re: Is CBL-Mariner going to become Microsoft Linux?

#127

Microsoft employs primary maintainers of the Linux kernel (gregkh) and systemd (Lennart Poettering), among other Linux contributors. (correction: gregkh works for Linux Foundation, Sasha Levin works for MS). Azure Sphere OS for embedded is based on the Linux kernel, https://static.sched.com/hosted_files/ossna19/91/Crossover_E... There's also their NOS for merchant silicon whitebox networking, https://www.linuxfoundat…

Do you have a source on Microsoft employing GKH? First time I've heard of it.

Apologies, I mixed up gregkh (Linux Foundation) with Sasha Levin (Microsoft), https://www.openwall.com/lists/oss-security/2019/06/26/2

DirectX on Linux, https://lkml.org/lkml/2020/5/19/742

Re: Is CBL-Mariner going to become Microsoft Linux?

#128
post #37

Earlier quoted context omitted.

Microsoft is no longer about Windows, it's about being wherever you are, especially if you're a developer

It's been this way for like at least 6 years now. And it's quite comfy. WSL and Windows gives me everything I could want from a dev machine.

You should try tiling WMs

Re: Is CBL-Mariner going to become Microsoft Linux?

#129

No. Microsoft will buy Canonical for Ubuntu and that sweet, sweet developer mindshare. Ubuntu is the developer distro after all. Ubuntu will become Microsoft Linux.

I have defaulted to Ubuntu for familiarity reasons, but recently I got to learn - the procedure for upgrading to a newer release of ubuntu it you run sed as root to fix your sources.list, then you do-release-upgrade, but it doesn't work because it has an undocumented dependency on pciutils - at this point i should be used to this pciutils thing since ~all software has undocumented dependencies on autoconf, automake,…

> the procedure for upgrading to a newer release of ubuntu it you run sed as root to fix your sources.list, then you do-release-upgrade

Are you talking about upgrading an lts release to the next dot.1 lts release, without dodgy third party apt-sources enabled?

Re: Is CBL-Mariner going to become Microsoft Linux?

#130
post #119

Earlier quoted context omitted.

All of this is towards the goal of deprecating the NT-Kernel and work on it. Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++). Rather than windows::nt or gnu::linux, the first "Linux on Desktop" will happen with windows::linux. In 2015 I bet my friends this would happen in 2025. It might not happen exactly that year, but…

> Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++). No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. But they ended up running into issues and limitations that made them change their approach. Now, with WSL2, they just have a virtualized instance of Linux…

> Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs

WSL1 doesn’t implement the Linux syscall interface on top of the user-mode Win32 or NT APIs. Rather, it runs in-kernel; it calls kernel-mode NT APIs (only some of which directly correspond to NT syscalls), and (I assume) also implements some aspects of the Linux APIs internally to itself. Its approach is rather different from that of Wine or Cygwin, both of which translate one user-space API to another; and also from the legacy Windows OS/2 and POSIX/Interix/SFU/SUA subsystems, which implement those APIs mostly in user space, on top of the NT user-space API. WSL1 is essentially unique; the closest analog is probably the Linux syscall emulation in FreeBSD/NetBSD, Solaris10/Illumos LX branded zones, and the old Linux iBCS2 personality - although those are all far easier because there is much less mapping in emulating the Linux API on another POSIX OS than one fundamentally non-POSIX.

> But they ended up running into issues and limitations that made them change their approach.

I don’t think those issues were inherently insurmountable, and solving them in the context of WSL1 would have made Windows a better platform, since many of those issues (e.g. poor filesystem performance) also impact native Win32 apps. But, they made a decision on where to invest their resources. WSL2’s implementation strategy requires less engineering work overall to reach a given outcome.

Post reply on HN