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.
Is CBL-Mariner going to become Microsoft Linux?
221–230 of 242 posts
Re: Is CBL-Mariner going to become Microsoft Linux?
#222Earlier 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…
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?
#223Earlier 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…
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?
#224Earlier 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?
Re: Is CBL-Mariner going to become Microsoft Linux?
#225Earlier 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.
Cheers!
Re: Is CBL-Mariner going to become Microsoft Linux?
#226Re: Is CBL-Mariner going to become Microsoft Linux?
#227Earlier 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…
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?
#228Earlier 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.
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?
#229Re: Is CBL-Mariner going to become Microsoft Linux?
#230Earlier 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.
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.