91–100 of 126 posts
I've largely made my living off CentOS software. I hope this new friendship doesn't cause CentOS to become diluted or eventually shuttered. Great project run by a very small number of very dedicated supporters. Best of luck to them.
Earlier quoted context omitted.
Red Hat is one of the most prolific single-entity contributors to open source in the history of open source. I find it really odd that some FOSS people regard Red Hat as some sort of evil corporation that should be the target of said FOSS people's flung shit. By the way, what did Firefox do to live down its IceWeasel[1] infamy? [1] http://en.wikipedia.org/wiki/GNU_IceCat
The Firefox trademark dispute is not the same thing. Red Hat was attempting to keep their product from the open-source homebrew market -- they wanted to charge money for their software, and did this as far as the license would allow. Red Hat was as hostile as legally permissible to anyone trying to circumvent this, like CentOS. Mozilla simply claimed that the Firefox trademark cannot be applied to any codebase that M…
It is for this reason that I moved to Oracle Linux about a year ago when deploying a bunch of new machines. I am certainly no fan of Oracle the company but they were getting security updates out much quicker than CentOS.
Earlier quoted context omitted.
The Firefox trademark dispute is not the same thing. Red Hat was attempting to keep their product from the open-source homebrew market -- they wanted to charge money for their software, and did this as far as the license would allow. Red Hat was as hostile as legally permissible to anyone trying to circumvent this, like CentOS. Mozilla simply claimed that the Firefox trademark cannot be applied to any codebase that M…
"Red Hat was attempting to keep their product from the open-source homebrew market " Nothing would make Red Hat happier than having every hacker under the sun using Red Hat - what they were attempting to do was keep the enterprise customers, who were currently paying $1000+/CPU (or so) go with a free alternative and kill their company. Simply removing three things allowed them to do that: (1) No RHN/Up2Date available…
This is evil, because the law is supposed to allow referential use of trademarks as a fair use.
Otherwise, RedHat's existence is highly beneficial to Linux.
Earlier quoted context omitted.
Note that having patches from upstream doesn't stop Mozilla from being willing to license the "Firefox" trademark — they will still license it provided they are happy with all the patches. The bigger issue in the Debian case is that while they could distribute a modified version as "Firefox" (under license), some downstream couldn't then take that, modify it, and still call it "Firefox".
Ubuntu, meanwhile, was willing to accept this tradeoff and distribute blessed Firefox, as Ubuntu also has trademarks that downstream modifiers (like Mint) need to remove. It would be nice if it was easy to remove said trademarks by something as simple as uninstalling a package, however unfortunately most marks are spread throughout the archive.
In the beginning, there was Red Hat Linux[1]. It was sold in boxes at stores such as CompUSA (remember?) but was also available for free download from Red Hat. Then, Red Hat decided they could make more money by spinning off Red Hat Linux into a separate enterprise-only product called Red Hat Enterprise Linux (RHEL), which they declined to make available for free in a ready-to-install binary form. Fedora[2] was also…
I believe RedHat would get a lot more followers, and a lot more support money if they did two things: - have support contracts that make sense, and trust their customers. Let their customers choose which server they want to put under contract etc... - have more software in their default repo (like, I don't know... Ubuntu) They managed to corner the market for pay-for software (to a certain extent, Suse has managed to…
It's sad, but this wasn't at a .com rev3 company, this was an old-school hedge fund with billions under management. IT support is just something that gets neglected if there isn't a contract that is enforceable. Clearly the company could afford a thousand systems worth of support, and could make it worth the money (autofs bugs galore!). There is a something missing in making the social contract of open source pay for the people needed to maintain open source.
I hope this will make it easier for me to use CentOS at NASA. They only want us to use Linux distributions that are actively supported with security fixes and for some reason they don't think CentOS qualifies, since it's not a "real" company. They prefer us to use RHEL, Ubuntu, or Suse. But if this new arrangement increases the perception of timeliness for updates, then maybe we can start using it and save some money…
Earlier quoted context omitted.
The Firefox trademark dispute is not the same thing. Red Hat was attempting to keep their product from the open-source homebrew market -- they wanted to charge money for their software, and did this as far as the license would allow. Red Hat was as hostile as legally permissible to anyone trying to circumvent this, like CentOS. Mozilla simply claimed that the Firefox trademark cannot be applied to any codebase that M…
'...were modifying the Firefox source to contain malicious code and calling it "Firefox" ' - You put a little load in there. Not every Firefox patch is obscure, malicious or both.
Earlier quoted context omitted.
This was true in 1998. Cowardly companies that insisted on being able to pay support for anything they deployed were able to hand over $$$ to RedHat then tick the box of 'support'. However, as we all know, you get a Linux user/expert to fix the server, you don't call RedHat. Due to the success of Ubuntu you have user/experts in small to medium sized companies that have 'given Linux a go' and got some good experience…
From someone who's day job it is to manage thousands of Linux servers and has professionally worked with SLES, RHEL, Fedora, Debian, Ubuntu, and a custom Linux from Scratch internal Linux distribution, you couldn't be farther from reality if you tried. """Due to the success of Ubuntu you have users/experts in small to medium sized companies that have 'given Linux a go' and got some good experience of Ubuntu""". I'm s…
I have no idea why one arrangement of /etc/ is preferable to another, for example. Is it just security, isolation, and better package management?
Earlier quoted context omitted.
Just to provide a similarly brief and pointless argument: I strongly prefer yum/RPM to apt-get/deb, both as a package maintainer (for tens of thousands of users) and as a system maintainer with dozens of servers to maintain.
Not my experience. I hope it has improved, but the missing dependencies were always a total pain.
My preference stems from the following:
1. yum repos are so simple to create and maintain! One command, one directory, no files except the packages themselves. Contrast this with apt-get...it literally took me weeks to figure out how to create an apt-get repo. It requires several configuration files, which are generally human maintained (as far as I can tell, the docs for maintaining a repo separate from the Debian repo are awful and leave more than half of the process out completely, to be guessed and googled...they assume you only want to add a package to the Debian repo, not create a new one). It is also inefficient as hell. Generating our Debian/Ubuntu repo meta-data takes an order of magnitude longer than the yum repos.
2. Packaging RPM is much nicer, IMHO. If you don't need patches, it's just one file, the package-name.spec, plus the tarball. If it's a standard "./configure; make; make install" process, your spec file can be almost empty. The spec file is well-documented (Epoch is tricky, and a couple of the macros aren't immediately obvious, but in general, I can answer my questions by reading the docs). Debian requires several directories full of files for every package, and the documentation is obtuse. Again, it took me a long time to figure out how to package for Debian, and there's no good source for what tools you use to create and maintain packages. Wanna sign those packages or repos? Good luck! There are three or four different ways documented, and it was not at all clear which was the right way. I had to dig into the Debian repos to see how they did it, and try to replicate it. I think I'm doing it right.
3. As a user, I dislike apt-gets tendency to want to remove packages based on dependencies no longer existing...so, if Apache were installed to satisfy a dependency in another package, and you remove that other package, apt-get will (with some configurations, seemingly the default) ask if you want to remove Apache. Even if you have a hundred VirtualHosts configured and rely on Apache for everything! I find some of apt-gets other defaults alarming.
4. yum has mock. mock is amazing. Building packages for any RPM/yum-based distro with one command and one configuration file (and maybe a custom repo, if there isn't already one) is so awesome. As a package maintainer, this would be enough to win my heart forever. apt-get has some kind of fake root thing, or something, but I can't figure it out, so I have to maintain a VM for every Debian/Ubuntu version we support. This sucks and is tedious as hell.
But, if I had to live with apt-get, I certainly could. They are, honestly, both amazingly great technology, and I can't imagine life without a good package manager. I hate Windows and Mac for this very reason. I can't believe people think Mac OS X is acceptable, given the awfulness of package management on the platform. Even Windows has better package management than Mac OS X.
Some amazing things about both:
yum has groupinstall and apt-get has tasks. Super cool! Install a huge swath of packages, for achieving a specific goal (like "Development Tools" or "Gnome Desktop") with one command. Brilliant.
Easily install all the dependencies you need to build a source package, based on it's specified build dependencies. How amazing is that? Not only can you install the source code and the config files, patches, and data files you need to replicate the package from source, you can also replicate the needed build environment easily. (Add mock on yum-based systems, and you have packager heaven.)