On Thursday, January 10, 2019 2:45:39 PM EST Rick Stevens wrote: > It's compatibility with _existing_ software that's in question here. Is > Fedora stable? Well, most of the time. Not always. Upgrades sometimes > screw the boot environment or corrupt the initrd or any of may other > issues. Kernel changes (even minor ones) can wreak havoc with some > software. When you refer to "compatibility", do you mean ABI breakage? ABI breakage is a good thing. As far as boot environment changes, this is one issue I can't say I've ever had, and I use dracut in literally very conceivable way over the course of hundreds of systems, with combinations of custom kernels, Fedora kernel and Linux-libre from the Freed-ora project. > When clients are dependent on the systems remaining up, you have to give > them something that doesn't change constantly or at the very least stays > in the same "family". If it's just YOUR stuff, then fine, have at it. > I'm the one that gets poked with pointy sticks if a client's software > isn't compatible with new OSes and it's not pleasant. I completely agree. So you give them Fedora, and don't change to a different distro when an update comes around. > You're being silly. There are MANY cases where existing software simply > will not farking work on newer OSes due to lack of backwards > compatibility, structure changes, default parameters, whatever. When F26 > abandoned webkit1, a lot of user-level web stuff broke. Yep. And we moved on. > The switch from PHP3 to PHP4/5 caused grief. Hold on for the move to PHP7. > Switching from Java 7 to Java 8 broke many things. Sure, but there's a simple fix for this. Install OpenJDK 7 and run with that directly, or even change the default on your systems to OpenJDK 7, using `alternatives`. > Python changes have always been painful. I wish I could say "I wouldn't know", but clients complain about it a lot. I've had to teach several people how to use python3, which, unfortunately, meant learning Python. > When the kernel went from 3 to 4, a HUGE amount of lower-level things broke > (some hardware was no longer supported, drivers couldn't be compiled, etc., > etc.). It was silly for hardware to be dropped, but I don't know what you mean when you say "drivers couldn't be compiled". > Even minor upgrades can cause massive grief. Look at the issues that > occurred when OpenSSH devalued certain ciphers so suddenly you couldn't > log into certain devices that used those ciphers without buggering > your openssh.conf file or re-enabling the ciphers on the command line. This one is mind blowing. I cannot believe you're actually suggesting that you'd rather have insecure systems than upgrade to more secure ciphers. > Again, if they're running YOUR code and programs, you have much more > freedom. The vast majority of us aren't in the same position. I must > supply platforms that support existing code and programs that neither we > nor our customers wrote and that just flat aren't compatible with newer > OSes. I've been in this game >40 years. I know of which I'm speaking. This attitude is precisely why there aren't as many Windows servers as there are GNU/Linux servers. > On top of that, if what you're saying is true then Red Hat should adopt > every single Fedora release as the latest RHEL. Using your criteria, F29 > should be Red Hat 8. It's stable, why not? F30 should become Red Hat 9 > by the same reasoning. So, why does Red Hat wait for major changes to > Fedora to accumulate and stabilize for a year or two before adopting it? > Because they, as I, have to support old stuff and they know (as I do) > that it's not feasible to do so. Red Hat thrives on supporting legacy code, exactly what you suggest you're doing, but in a different context. They provide exactly what is necessary by way of updates, but not much else. RHEL is so far behind, it's not even funny. > How well do your non-upgraded Windows 7 apps run on Windows 10, eh? I wouldn't know, I don't run Windows on anything, but considering Microsoft's big thing has always been legacy support, and they proudly boast that you can run 27 year old code without recompiling, I'd imagine fairly well. > Then talk to Cisco. I can pretty much guarantee it's not going to > happen. IOS does what it does well and they offer CSE status if you're > willing to pay for the training and testing process. I'm not a CSE, just > a poor bloke who was handed the network keys and was told to "keep it > running." Any certification I have is via UHK (the University of Hard > Knocks), from which I've graduated summa cum laude. No, the solution has nothing to do with Cisco. We need to move away from their proprietary hardware, and towards libre solutions such as running our own router software on our on boxes. For example, my home network is a 10G network run from a GA-G41M-ES2L board running coreboot + Fedora with Freed-ora- freedom. Certifications are meaningless. We have access to the internet, anyone that actually tries to solve a problem has the resources to do so. -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> Splentity https://splentity.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
