If you don't like Debian, pick an open source distribution that is not backed by a business and begin sending the money you would've dumped into subscriptions as donations.
If you don't like Debian, pick an open source distribution that is not backed by a business and begin sending the money you would've dumped into subscriptions as donations.
Despite Debian being phenomenal in many ways, it doesn't offer up a head for the chopping block to replace yours if things go wrong in a corporate application. Good luck getting IT folks to deploy anything that doesn't offer them an out.
Using CentOS knowing that it is downstream from RedHat but that RedHat would step up and fix things in a semi-timely manner was good enough for many enterprises....at least until IBM got involved.
Ubuntu is also a weird choice generally speaking because Ubuntu just uses Debian's testing repo as a base and really only significantly varies in the kernels that they roll for various products/services.[cloud,live patching,etc.] They used to maintain their own desktop[Unity] and service management[upstart] and a bunch more variances from Debian...but that ain't really the case today.
https://threatpost.com/how-debian-openssl-bug-almost-spawned...
Here's the mailing list email that inspired the bug:
https://marc.info/?l=openssl-dev&m=114651085826293&w=2
I kind of doubt that some guy that thinks he "knows better than the OpenSSL developers" is saying things like this on their mailing list:
> What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.
The result was something like 32k sources of entropy which is not enough.
Here's the bug Kurt was trying to fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
I was always a little confused by how popular Ubuntu became. Canonical never did much to add value, often replacing more standard tools with strange canonical replacements that didn't survive the test of time.
If you use Ubuntu now, give Debian a try. The stability and community are really second to none. For all my personal use I run Arch, but I would not hesitate to run Debian in production instead of a commercial distribution.
By comparison I never fully understood the Debian versioning story. I have no idea when the next version will become stable, or how stale the versions are in stable, whether I could install it without driver issues on my desktop, etc.
With Ubuntu I could take a break for a few years and know there will be an LTS release in April or 2022, that the previous LTS release was 20.04, and 18.04 was the one before that, etc. That each will be supported for 5 years and so on.
When I started using Linux a couple decades ago, "we ship when it's ready" was the dominant FOSS approach, and I thought it was the most sensible approach.
Then I got my first job and experienced the realities of enterprise support and planning. Today I wish more projects were as predictable as Ubuntu, and I'm gratefully for every one that is.
Ubuntu is far from my favorite distro technically, but the predictability of its LTS releases makes it my recommendation for most uses.
I think if debian augmented the toy story names with dates, that might help.
Before that I was on FreeBSD, and before that I was in Slackware. All were always fine
What does “difficult to install” even mean?
Besides, last time I ran a GUI on linux was probably over 20 years ago.
Stable is too stable for the average desktop user - often kernel is missing drivers for newer hardware models, or system libraries are too old for newer applications.
Testing works most of the time but is not stable enough. Most recent example; zfs, which is on 0.8.x, is completely broken in testing since the kernel upgrade to 5.10 in December. zfs has not (and prob will not) backported 5.10 compatibility to 0.8.x. Last I heard, the Debian maintainers were still not decided on if they are going to backport the 5.10 fix to their own fork of zfs 0.8.x, or if they're going to do the upgrade to zfs 2.0 already.
I had a couple of servers where I had stupidly enabled unattended-upgrades, which broke the filesystems and required recovery to make services start again. Annoying, but it was my mistake.
This kind of situation is completely expected and there's really no one at fault. But it is a good example of why vanilla Debian is not suitable for many users and use-cases. Mint does seem like a better Ubuntu, though.
They do not have the time and resources to figure out every inevitable configuration, and they end up supporting a mishmash of unsupportable software.
Backported ZFS just brings fear in my eyes, these filesystems have to have many decades of testing before people are comfortable with it, and Debian finds it acceptable to make a custom patched version. Not cool.
If you want to store all your data on that configuration then by all means, but I'm afraid I won't run a distro that plays games to avoid changing a version number.
> the backporting part was just hearsay that it was under debate
I guess if it is just hearsay then thats something else. Does Debian have guidelines about what they wouldn't backport?
They employ a number of people who maintain core Debian packages to work on Debian packaging full time and generally to land improvements in Debian.
I do agree that Canonical never did much to add value to Ubuntu beyond what they added to Debian, but they certainly added value to Debian, and ironically you don't even need use their distro for that, let alone pay them!
Second, it would be nice if the package manager had an actual database behind it capturing everything that the rpmdb does. Instead you have a flat file with some of the data in it, and log files with other data (where the log files can be rotated out eventually). I want to be able to do things like "rpm -qa --last" on Debian. Or "yum history".
How difficult would it be to write a version of the apt suite of tools that uses an sqlite db? Would that break other items in Debian? It sounds like an interesting project to take on.
https://wiki.debian.org/Teams/Dpkg/RoadMap https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
Personally I vastly prefer the flat file version, it is much easier to inspect and modify and maybe less likely to get corrupted.
I wish Linus had veto'd the binary logfiles of systemd.
How is that as useful to you personally as a support subscription? You can't replace a support contract with wishful thinking and a donation.
It's great to support open source projects, but lets not mix concerns here.
"Software in the Public Interest, Inc. is a tax-exempt non-profit corporation based in the United States of America, founded by Debian people in 1997 to help free software/hardware organisations."
It owns the various Debian trademarks, etc.
You can argue that Ubuntu provides a counter model to RHEL where only services and select products require a subscription but the OS is otherwise free.
https://wiki.debian.org/Teams/Treasurer/Organizations https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteri...
If you pay for software, like we do in VFX/Animation, then RHEL is basically the standard and what's supported best.
^ This is what I have been told by my older colleagues; I wasn’t around for this. My current employer danced around with RHL and Fedora Core before moving to CentOS 6 (now 7, and looking at what to do with 8). Pretty much all studios using Linux in this industry are running RHEL/CentOS, with a very small handful operating on Ubuntu. Home users will do whatever they want and deal with whatever incompatibilities arise ;)
While most hobby level video software is targeted at windows or Mac, the truly powerful stuff (houdini, maya, nuke, blender) are first class citizens on Linux. Currently one of the few artist programs that aren't available for Linux is the adobe suite which is mostly used by editors (for timelines) and photo editing (for promotional material) and most of that happens on Macs, usually in the editing department.
Something to keep in mind is that many VFX shops are kind of specialized and will work on very specific portions of a movie or TV show. For example, the company that owns the final product (Disney, Fox, MGM, etc) will pay company A to shoot the movie, then company A will send the footage for a 30 second scene to company B to rotoscope everything, then it gets sent to company C for VFX elements, then to company D for 3d conversion, then to company E for lighting and finally to company F for audio and final stitching. This is repeated (often with different companies A-F) for each scene since different scenes required different levels of expertise in different areas such as crowd generation, fire simulation, raindrop removal (yes, it's as painful as it sounds), background replacement, CG helicopters, etc. Because of this, the few steps that require windows are typically handled by 1 or 2 companies so the rest only need enough Mac/Windows machines for their local editors to stick timelines together for daily reviews.
An interesting side effect of the above is that almost every company you see in the credits of a movie had no idea what the dialog was because audio is one of the last things that gets added and completely bypasses 90% of the VFX houses involved.
People tried selling Enterprise Support for Debian back even before Red Hat went commercial, if I remember correctly, but somehow Red Hat timed their effort right and became the defacto replacement for UNIX in these environments.
https://www.debian.org/support https://www.debian.org/consultants/
Ubuntu, Red Hat and SUSE are owned by companies. That ownership is more than just trademarks. The own the trademark and are the sole decision makers.
Personally, I used to support a $25m/yr business on a cluster of Debian servers, which itself supported about 1000 remote field installations, also running Debian.
Let me tell you, Debian was the least of my troubles in that job. It really did just work
Updating a personal server every 6 months may be easy, but in a mature business it often makes sense to wait 5 years or more before upgrading certain infrastructure so that time and effort can be invested in other areas instead.
The days of having a fleet of servers that were carefully hand-crafted and evolved over the years are hopefully coming to a close.