Live data from Hacker News

Is CBL-Mariner going to become Microsoft Linux?

boxofcables.dev

221–230 of 242 posts

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

#221

Earlier quoted context omitted.

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 is bad. > You mean the tons of online articles and communities trying to get you to purchase spyware? Linux has a substantial amount of communities and support, and with systemd things are getting pretty routine there isn't…

I assume you haven’t been new in a while, you should be aware that none of that is true.

Haven't been new? It is absolutely true. Linux has a great community compared to Windows. I think Windows users prefer ignorance over reality.

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

#222
post #217

Earlier quoted context omitted.

RPM is antiquated. New package managers like apk & pacman have had great success due to their simplicity and attracting a lot of maintainers that are able to maintain more stable packages than other distros.

This is totally false, and compares package managers in incomparable categories (pacman's counterparts in the RPM-based package management world are Zypper and dnf, not rpm). Arch Linux itself has very few packages— ~10k, around half of what you find Fedora, an RPM-based distro. The DEB packaging format and tools related to it are way more convoluted, and still Debian has several times as many packages as Arch and ma…

False.. Arch Linux and Alpine maintains significantly more stable packages (meaning up-to-date) than other DEB and RPM-based distros. Zypper and dnf still use RPM BTW.

Also, Alpine certainly does have a JVM so that statement is flat out false and now sure where you're getting your misinformation from.

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

#223
post #190

Earlier quoted context omitted.

Well, maybe you should listen to “everybody” a bit more, the way you’re piling on more dislikes and grim figures of speech into what wasn’t an argument is exactly why I never replied to any of those e-mails.

Well, seeing the actions of "Greater Microsoft" drowns out the actions and words of people who work inside the machine (aka "everybody"). Seems like we're not so different in the amount of history we have accumulated about these things called computers, so we have possibly seen many (if not all) of the big events shaped the industry. I'm not grim or angry, but have generous reservations for the company and its motive…

In my 40-year petrochemical career I enjoy working most with the oustanding individuals that are employed by oil & chemical companies but who recognize they can afford to not operate as toxically as they used to do.

They are working from within to make it more sensible for the rest of the world, but progress is hindered by the overwhelming momentum in the opposite direction remaining from those who are not on the same page at all.

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

#224
post #61

Earlier quoted context omitted.

From what I understand, most of the package-level tools (dpkg, rpm, etc.) will technically work on any Linux system; you just wouldn't be able to share dependency management with whatever the native package management system is, so as mentioned elsewhere in the thread, dealing with file conflicts would be one annoying issue. I think using the repository-level tooling (apt, yum/dnf, etc.) on distros they're not the de…

If you are neither using the distro's packages nor the distro's native tooling then in what way is it based on that distro?

My point is that using non-native tooling might conflict with the native tooling which presumably still exists and is managing some non-trivial portion of the system (at the very least, the base installation, but probably a bunch of other packages as well), so whether or not that conflicts with an external package manager is likely to vary by distro.

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

#225
post #220

Earlier quoted context omitted.

> Microsoft has arranged things so that actual open-source builds of VSCodium will always be lacking in comparison to their proprietary product. Errm, this is also my point, written in a slightly ironic form. This is why I use neither, too.

Oh, my apologies! I'm not tuned properly to pick up irony about that on HN since I've read so many posts overlooking the real difference. Hopefully my comment will be useful as a starting point to someone who hasn't really looked into the issue before.

Hey, no worries. Of course it will be.

Cheers!

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

#226
post #82

CBL-Mariner from Microsoft: the only linux distro to build on Ubuntu but work with RPM packages.

it's not built on Ubuntu.

I did not say based or built on ubuntu. I said that it builds on Ubuntu, which it does and has for many people.

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

#227
post #203
post #73

Earlier quoted context omitted.

Imagine being ok with trillion dollar companies using opensource code you wrote, for free. Imagine if the people who work at those companies aren't your enemy. But instead are potential customers and potential collaborators, who see value in your work and want it to succeed. Imagine if there was a good implementation of some idea, expressed as code. And we can all share and contribute to that single good implementati…

>Why shouldn't big businesses use my code? The better opensource companies (Google, new Microsoft, Facebook, etc) contribute back to the community in all sorts of ways; and I consider that a net positive on the world. Because free software is in a constant battle for relevance, and they will use your code to make their proprietary offerings strictly superior to the free ones. What do you think would happen if Autodes…

> Blender would die, is what.

You know, I don’t think it would? If autodesk depended on blender, and the core of autodesk was blender, I think autodesk would throw gobs of money at making sure blender flourished. They’d probably try and hire lots of blender devs too - just to get them to work on core blender features so they could make autodesk better.

There’s plenty of examples of this happening in the wild. Is FreeBSD dead because macos is built on top of a lot of its code? Is redis dead because of redislabs’ proprietary offerings? No.

Is SQLite hurt by all the projects built on top of it? No. The opposite - it’s strengthened by being used.

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

#228
post #197

Earlier quoted context omitted.

> We see what they have done with GitHub, for a start. Provide free hosting for countless FOSS projects?

> Provide free hosting for countless FOSS projects? and provide the resulting source code to anybody regardless of the source and target license w/o consent via Copilot. Also, it was free for FOSS even way before Microsoft, so that part doesn't even count.

> and provide the resulting source code to anybody regardless of the source and target license w/o consent via Copilot.

That is one opinion. Mine is they used the code as allowed under the Github terms of use and/or the principles of fair use. Ultimately it doesn't matter what either of us think. A court will decide.

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

#229
post #195

Earlier quoted context omitted.

If you have a machine running ubuntu 19.something today, you cannot upgrade to any other release without messing with your sources first.

Any Ubuntu 19.something hasn’t been supported for years…

I am not sure what that has to do with anything.

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

#230
post #217

Earlier quoted context omitted.

This is totally false, and compares package managers in incomparable categories (pacman's counterparts in the RPM-based package management world are Zypper and dnf, not rpm). Arch Linux itself has very few packages— ~10k, around half of what you find Fedora, an RPM-based distro. The DEB packaging format and tools related to it are way more convoluted, and still Debian has several times as many packages as Arch and ma…

False.. Arch Linux and Alpine maintains significantly more stable packages (meaning up-to-date) than other DEB and RPM-based distros. Zypper and dnf still use RPM BTW. Also, Alpine certainly does have a JVM so that statement is flat out false and now sure where you're getting your misinformation from.

You're right, I misremembered some detail about Java packaging on Alpine. There's an Alpine-based Docker image I've set up to build for a Java application at work where I have to manually pull down some binary that I expected to be packaged, but I don't recall all of the details.

As for the substance of your reply:

> Zypper and dnf still use RPM BTW.

Yes, this is what I said. Zypper and dnf are high level package management tools comparable to Pacman. RPM is not.

> stable packages (meaning up-to-date)

That's not at all what the word 'stable' means, but

> Arch Linux and Alpine maintains significantly more [up to date packages] than other DEB and RPM-based distros

This is also false. Look at the numbers: https://repology.org/repositories/statistics/newest

Debian Unstable has > 18k up-to-date packages. Fedora Rawhide has > 14k. openSUSE Tumbleweed has > 9k. Arch has fewer than 9k up-to-date packages.

Arch has fewer up-to-date packages than any of the most prominent RPM-based or DEB-based rolling release distros. It does have a larger percentage of its (relatively very small) total package collection at the latest versions from upstream: https://repology.org/repositories/statistics/pnewest

On that front, the difference between Arch and Alpine is greater than, e.g., the difference between Alpine and openSUSE. Debian Unstable about matches up with the AUR on that metric.

Not to mention that Nixpkgs, whose tooling is pretty much the polar opposite of Pacman's KISS philosophy, has more packages than Arch and the AUR combined and has more packages which are up-to-date than both combined.

I am sure that the simplicity of the PKGBUILD format has been important in the personal journeys of many package maintainers for Arch Linux. But the notion that this means that Arch has attracted so many maintainers that is capable of keeping a greater number of packages up-to-date is absolutely unsupported by the facts. The further claim that this (fictional) superiority reflects fundamental technical virtues in its package management system that make it a better base for enterprise Linux distros than something like Fedora or Debian or openSUSE is a huge leap and a non-sequitur.

Post reply on HN