Announcing the release of Fedora 28
fedoramagazine.org
fedoramagazine.org
Modular repos is cool. I love this idea. Especially useful if you work with node.js....as it moves so fast.
[LINK] https://docs.fedoraproject.org/fedora-project/subprojects/fe...
https://docs.fedoraproject.org/fedora-project/subprojects/fe...
We've been using NodeSource's RPM packages with good results.
The polish and seamlessness of Fedora is simply miles ahead than a lot of other distros. It was the first distros to support NVME RAID hardware on the XPS 13 and has always worked seamlessly. Ubuntu has always seemed forced with its attitude of resigned acceptance towards systemd, Gnome and Wayland.
Given that Redhat directly employs most of the kernel and system devs that contribute to Fedora, I wish I could contribute in some monetary way (like a yearly subscription to Fedora with inbuilt DRM+media codecs)
Ubuntu makes risky bets and loses a lot of them. You know how the saying goes: if you never fail, it's because you are not doing the hard stuff.
Aren't you contributing by beta testing Red Hat's products for them?
Also - Fedora + Gnome + Dell XPS 13 has been the first laptop package that has gotten envious looks from macbook owners.
I agree completely.
My point is, isn't Red Hat already paying for it in return for the beta testing that all Fedora users effectively do? Is more money needed? Given the enormous benefit they provide, why shouldn't Red Hat provide that money? A sincere question.
Regarding those kids, your and my money could be spent providing other things they need, such as applications, security and privacy, etc.
Beyond that, and somewhat visible the Firefox version bump, I'd be hard pressed to even tell you what changed from a desktop user's perspective.
I know this can be spun as a "Linux is so mature it's boring" sense, but the truth is I feel very old and lame right now.
Hope you find this helpful.
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
https://fedoraproject.org/wiki/End_of_life
There are other distros you can use if you want long term support. Fedora has a 13 month policy, and RHEL (which is based on Fedora) is the LTS branch. RHEL 7 is fedora 19 + changes from 20. RHEL 8 will be based on F27.
My point was more that for my hour-to-hour work, desktop distros simply aren't showing much real progress these days, and by far the biggest driver of my need to upgrade is the planned obsolescence of the distribution updates and not features I need.
Use an LTS release, then it's 4 years apart... and you'll start getting exciting for upgrades again.
Either that, or run Rawhide (the testing, rolling release version).
We are usually in the middle of update cycles for CentOS. Being an individual will probably make it easier upgrade more frequently. We're currently half 6.7 and half 7.2. We're only now looking to make our second serious push and take everything to 7.4.
Because it sounds like you've just chosen the wrong distro. There is a selection of rolling distros that would better suit your needs. Or even non-rolling distros that are supported for a long time, CentOS/Debian/Ubuntu LTS, etc.
Where do you get that I'm grouching? I thought it was a genuinely interesting point.
Meh. I'll take my downvotes I guess. Folks just wanna do platform flames I guess.
(Also, the link to the release notes leads to a 404: https://docs.fedoraproject.org/f28/release-notes/index.html )
From @chr15p:
"I had a conversation with some of the RH kernel devs a few weeks ago and from my (hazy) memory, this comes from Red Hats acquisition of permabit so it was closed source, its now GPL'd but needs a fair amount of tidying up and bits rewriting to get it into a state that the kernel developers would accept it (they reimplemented some standard kernel features so they didn't have to link to GPL'd code). So it will be upstreamed but it will take time.
In the meantime its released for RHEL only, not even in Fedora. Iirc could be ported to other distros (its 100% GPLed) its just not been."
I think in 6 months when people start to improve it it will be great, but at the moment I think the usefulness is limited.
I always wind up setting up the runtime environment using some form of the "carefully, and by hand" strategy.
Every language that I use (and probably every language that I can think of) has one or more preferred, distro-agnostic ways to install the language SDK and runtimes on a per-user or per-app basis. Go has GOHOME and GOPATH. Ruby has RVM, chruby, rbenv, and bundler. Python has pip and virtualenv.
Pretty much all of these include some sort of 12factor-ish tools and best-practices advice like using a Gemfile for explicit dependencies and environment isolation.
For teams with a platform group or someone who is responsible to run upgrades, with custom apps that were developed for script or interpreted languages: this is also pretty much the only way to ensure that production apps are not automatically broken by some ham-handed apt upgrade, usually being done on a schedule according to protocol, with someone at the keyboard who has no knowledge of the specific applications running on the machine being upgraded.
We have channels for those folks to notify us of impending upgrades, but five times out of seven the timing couldn't be worse, or the notification wouldn't include specific notes about what packages will be changed, so we're left to our own "spidey-senses" and vigilance inside of dev environments to notice these issues before they hit prod...
More often than not though, the issue I've seen has been the reverse: developers would like to start their app with the newest release of the language runtime, to take advantage of the latest features as well as to minimize the pain of upgrading later, but the platform team prefers to use a Stable or Long-Term Support release that has an intolerably old version, and the devs wind up missing the new features and writing workarounds for the lowest common denominator (or worse, remaining ignorant on the pain or postponing the pain of upgrading until some unknown future date.)
Rust lets you specify an exact toolchain to download in a rust-toolchain file; rustup will then download the one you need. For a variety of JVM-based languages, SDKMAN! can install specific versions of the SDK and set them up in your shell; that makes it fairly easy to write build scripts which use a specific version. Where i work, we have packages in our oddball internal dependency management tool which contain the entire GCC toolchain, so i can make sure my C++ projects build with a consistent version.
It would be great if tools like this existed for every language.
Docker offers a semi-reasonable approach to this, too.
I mostly work on Ruby with RVM, where you can specify the exact version of language runtime and every gem dependency in the Gemfile, or let most of the details be inferred by bundler into the Gemfile.lock, and your runtime environment will balk appropriately if it's apparently being asked to run with something other than what you've described there.
It's not as concise as `rustup` but I feel like `rvm install ruby-{version}; bundle install` gets me about 97.5% of the way there, to "still automatically" as you've described, with the remaining 2.5% being the native extensions that may have those external library dependencies (which are not part of Ruby at all.)