Hacker News new | past | comments | ask | show | jobs | submit login

It has been rumored for years that Microsoft might acquire Ubuntu. This is an interesting move though not proof of any such future merger. All of that said, it would be nice if Microsoft had the same level of cooperation with Fedora and another distro or two as well.

(And where the hell is support for .NET Core on FreeBSD???)




Fedora and Red Hat have offered .NET packages for years. We've worked very closely with those folks and they've taught us a lot about how to work collaboratively with distro maintainers. We meet with them weekly. Notice that Fedora is mentioned in the blog post and here: https://docs.microsoft.com/dotnet/core/install/linux#officia....

Also notice that our default build instructions are for Fedora: https://github.com/dotnet/installer#building.

I'm the post author.


This just puts Ubuntu at the same level as Fedora/RH/Arch were before, am I right? In the sense that this just means .Net is in the official repos (as was the case for Fedora/Arch before)


Yes.

But your list is incomplete! .NET is also part of Alpine's community repository https://pkgs.alpinelinux.org/packages?name=dotnet*&branch=ed... and is also available in Homebrew https://formulae.brew.sh/formula/dotnet

Other distributions are welcome to join: https://github.com/dotnet/source-build/discussions/2803


For FreeBSD support, see the following issue for the porting effort. The community has been working like hell to make it happen since 2015 and at this point we have regular unofficial builds: https://github.com/dotnet/runtime/issues/14537

About 2 months ago they crushed hopes that official FreeBSD support will happen anytime soon by clearly stating that at this point, updating their Quality Assurance process to support FreeBSD would not make business sense for them as they have to put together an extensive test suit and manual testing procedures for every OS. Microsoft folks remain friendly and helpful in the thread though.

The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. This is one of the things that complicates its inclusion in the ports tree. Building .NET for FreeBSD is close to rocket science, the community has worked to make the process way simpler. It is frustrating that the .NET team refuses to take things from there. Providing FreeBSD support is what I would expect from them to strengthen their cross-platform posture. This is the last major platform they need to support, and one being heavily used for servers.


> The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process.

As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavior™ that is likely to get in the way of any distribution (Linux or FreeBSD or macOS or anything else) that follows basic best practices with respect to build sandboxing on their CI/CD systems, build clusters, etc., even if it can eventually be hacked around.

Building software outside of a sandbox with restricted network access is how you get lovely exports like credential scrapers in your setup.py or your NPM install hooks, perhaps running as root. Downloading your dependencies at build time from within the build system without first emitting a manifest with hashsums of what you intend to download is a huge problem for reproducibility, too.


Yeah the FreeBSD team is full of common sense, which is why I use it so much. Also much less likely to drink the corporate Kool-Aid.


> Microsoft might acquire Ubuntu

That would make a lot of sense, despite the backlash it would generate.

Remember when they acquired GitHub, developers were vouching to move over to GitLab. Yet very few did.

The same would probably happen if they acquire Ubuntu. Developers would vouch to move to another distribution, yet few will, because Ubuntu is so much nicer to use than the competition.


I'll be one of the few. Maybe I'll give a try to Debian but probably I'll end up using one of the Ubuntu replacement distroes that will popup. Or Pop!_OS outright.

I'll never trust Microsoft again after all they did in the 2000s. Transitively, I'll never trust any comparably sized company.


Can I ask a Ship of Theseus kind of question? Is there any amount of shot-caller employee turnover possible in the last 15-20 years that would cause you to reset your projections of their ethicality? Relatedly, is there an amount or form of recompense possible on MS's side that could reinstate your doubt? Or is there a general lack of trust in unchecked / unethical capitalism that is insurmountable?


The word you're looking for is "vow".


> Remember when they acquired GitHub, developers were vouching to move over to GitLab. Yet very few did.

GitHub benefits from a powerful network effect: if you want contributions from the greatest number of developers, you need to be on the platform they use and understand.

Ubuntu doesn't have a comparable form of social lock-in. As long as they are popular and until portable and/or containerized package formats for Linux mature, they do exert some network pressure on publishers, but not really end users.

> Ubuntu is so much nicer to use than the competition.

I don't think this has been true for some time. Canonical's server offerings are pretty much coasting on the mindshare that they gained with current-gen Linux sysadmins and developers who grew up experimenting with desktop Linux in the aughts, when the usability delta between Ubuntu and other mainstream distros really was vast.

They still benefit quite a bit from their willingness to bundle proprietary software with the OS, and from sheer inertia on the desktop, where they are still most likely to receive native packages by proprietary software vendors.

But the collection of desktop operating systems that actually attract new users to the ecosystem who will become the next generations of Linux sysadmins is increasingly comprised of distros that are not based on Ubuntu. User-friendly Arch downstreams now have more and more of theml mindshare that Ubuntu did when I was 'growing up.

The most popular Ubuntu-based distribution, which has actually surpassed Ubuntu both in interest from new users and in its reputation for OOTB usability, deviates strongly from Ubuntu in some core technical aspects that make some Ubuntu knowledge non-transferable.

APT is aging poorly, even compared to its RPM-based counterparts. It has recently been at the center of some high profile blowups where package installation triggers a catastrophic cascade of uninstallations that newbies would likely perceive as 'bricking' their installations. This has damaged the reputation of the most popular Ubuntu-based distros, including Ubuntu itself as well at driving home the case for portable/containerized package formats.

The success and growth of these portable package formats, including Snap itself, additionally threaten to undermine Ubuntu's strategic advantage because they work pretty much as well on any distro as they do on Ubuntu.

Moreover, Canonical's own offering in that space is already driving users away from Ubuntu. Snap is slow, clunky, space hungry, and bandwidth hungry, and the way that Ubuntu has chosen to force Snap packages for key software, e.g., Firefox, has had a negative impact even (and perhaps especially) among non-technical users precisely because it has a shitty UX.

Meanwhile Snap has failed to gain much developer interest outside of Canonical, and looks likely to suffer many of the same adoption problems as previous Canonical offerings in the space of core system software like Upstart and Mir. It seems that Canonical has not figured out a way, in the past decade or so, to displace Red Hat as the most influential corporation on projects that require widespread, cross-distro adoption to succeed.

Similarly to the situation witb portable packaging formats, there's a pretty clear trend in the wider Linux world away from relying on old-school package management 'raw' in favor of immutable operating system images. There are Ubuntu derivatives in this space, but the clear leaders are NixOS on the radical side and Fedora Silverblue for the more conservative approach that reinforces/enhances traditional package management tools with OSTree to gain some of the same benefits.

It may be that Canonical's advantage in the server space and among developers is 'sticky', now that Ubuntu is established in those markets, and that it's less ripe for the same kind of play that Ubuntu made by building mindshare first on the desktop. They may also catch up in some of these areas.

But for all of the reasons I outlined above, I don't think Canonical is in nearly as strong a position to retain its relevance as GitHub was, especially in the long term, in the face of one more thing that makes it less attractive to new desktop users for whom much of the appeal of running Linux in the first place is escape from Microsoft.


Folks are working on FreeBSD support: https://github.com/dotnet/runtime/pull/71486


I would have expected .NET's core demographic to be mostly CentOS and RHEL users. But I imagine Microsoft really wants you to run your workloads in Azure instead of on-premise, and Ubuntu fits that model better.


We started with Red Hat. They were our .NET Core 1.0 launch partner (and remain a very close partner). You can run Red Hat on-prem or in the cloud (obviously).


>I would have expected .NET's core demographic to be mostly CentOS and RHEL users.

Why? There is nothing "Enterprisey" about .NET Core. It's a perfect fit for both fast-moving startups and big enterprises.


The "enterprisey" part of .NET is the brand itself. It's well-established in the enterprise, less so outside of it.


I've always thought that a Microsoft Linux distribution would be incredibly interesting. They could give the user experience a new round of polish without being weighed down by the years of legacy support, compatibility, and cruft on Windows.


they have an internal distro on github: https://github.com/microsoft/CBL-Mariner


[redacted]




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: