Announcing the release of Fedora 28(fedoramagazine.org)
fedoramagazine.org
Announcing the release of Fedora 28
https://fedoramagazine.org/announcing-fedora-28/
38 comments
For those interested in Node.js, Fedora 28 currently ships with 6.x, 8.x and 9.x versions available and I am building 10.0 at this very moment. It should be available in the updates-testing repositories by tomorrow.
This is great news! This is one thing that eats at me when I work on most distros not being able to just run the latest of a language. At least Rust has rustup but I wish rustup was an official package on my distro at the very least?
It's certainly pretty cool to have this support built into the distribution. I think we will have to wait and see how timely updates are in general. Of course, it's all volunteer-based so help is welcome.
https://docs.fedoraproject.org/fedora-project/subprojects/fe...
We've been using NodeSource's RPM packages with good results.
https://docs.fedoraproject.org/fedora-project/subprojects/fe...
We've been using NodeSource's RPM packages with good results.
Fedora has taken over being my desktop OS for over 3 years now after spending nearly a decade on Ubuntu. And I have never been happier.
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)
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 has always seemed forced with its attitude of resigned acceptance towards systemd, Gnome and Wayland.
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.
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.
> 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
Aren't you contributing by beta testing Red Hat's products for them?
Aren't you contributing by beta testing Red Hat's products for them?
ha ha... but people need to eat. my startup and I are willing to pay for more. We love Fedora and Linux. I want to support more initiatives here. I would rather pay for something that is as good as OSX that billions of kids in India's villages can use for free.
Also - Fedora + Gnome + Dell XPS 13 has been the first laptop package that has gotten envious looks from macbook owners.
Also - Fedora + Gnome + Dell XPS 13 has been the first laptop package that has gotten envious looks from macbook owners.
> I would rather pay for something that is as good as OSX that billions of kids in India's villages can use for free.
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.
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.
One way you can help is by sponsoring someone's travel to Flock, our annual contributor conference. I don't think we have the details on how to do that yet for this year, but watch https://flocktofedora.org/
You could always buy a subscription to RHEL Workstation.
well I wanted exactly the same thing but for Fedora. With focus on consumer side of things - video, audio, multiple desktops, thunderbolt, bleeding edge hardware, etc etc
It's a somewhat sad statement on the maturity of modern linux distros that my greatest excitement on seeing this announcement is knowing that I managed to install F28 off the beta track this cycle and thus I'm guaranteed not to get caught with a stale distro for a full year this time.
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.
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.
Hey, Fedora mag also has a post detailing the major changes in F28 workstation, here: https://fedoramagazine.org/whats-new-fedora-28-workstation/
Hope you find this helpful.
Hope you find this helpful.
Fedora supports every release for just over 1 year. So if you upgraded immediately after a release, then it's always a full year before you need to upgrade again. Since they release every 6 months, that means skipping 1 release.
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.
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.
EL has actually been deploying updates to GNOME and other desktop software. See e.g. https://access.redhat.com/documentation/en-us/red_hat_enterp...
For clarity: I know all that stuff. I've been working on a Linux desktop full time for literally more than 20 years, and on Fedora specifically for about 8.
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.
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.
But if the new features aren't exciting to you, why not just use CentOS then? I mean, how many major changes can these releases make when they're only 6 months apart. They just made a release in November. I don't think anyone would be interesting in using a distro that radically changes every 6 months.
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).
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).
Just because the OS is still supported it doesn't mean your software or new hardware you want is. I've been using RHEL or CentOS at my job on workstations for 10+ years. During that entire time it's been a struggle to get a "modern" browser working for longer than 6mo to a year (it was even harder when Flash was in the picture). I don't think I'd even bother trying to install it on a brand new laptop.
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.
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.
Is there specific innovation you are waiting for or are you just grouching?
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.
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.
> Is there specific innovation you are waiting for or are you just grouching?
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.
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.
I'm curious why you think this is sad. As a desktop user myself, I generally find it a good thing. It's settled into "get out of my way and let me do my work" and makes upgrades generally non-disruptive.
Mildly disappointed that 28 Server doesn't include VDO. VDO is going to be a completely killer feature for storage servers in the future.
(Also, the link to the release notes leads to a 404: https://docs.fedoraproject.org/f28/release-notes/index.html )
(Also, the link to the release notes leads to a 404: https://docs.fedoraproject.org/f28/release-notes/index.html )
https://news.ycombinator.com/item?id=16874061
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."
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."
There is a Copr for it — https://copr.fedorainfracloud.org/coprs/rhawalsh/dm-vdo/. (Looks like not yet built for F28, but I expect that to be updated shortly.)
In my current experience, VDO is awesome for VM storage. I'm at around 80% deduplication and compression with minimal overhead. I also tried it with a bunch of Media files (uncompressed MKVs) and it was unable to do anything with it.
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 think in 6 months when people start to improve it it will be great, but at the moment I think the usefulness is limited.
If I can easily try Nvidia binary drivers, and recover without trashing my system, this is big news.
What do you do if you want to use Fedora, but the version of some language that it ships with is newer then your project? Do you go with an older Fedora? Aren't releases only supported for 6-12 months?
Looks like a sibling comment, https://news.ycombinator.com/item?id=16968312 , discussing the new "Modular Repos" feature, has an answer -- looks like Fedora 28 lets you switch easily between different versions of released software.
This may not be a popular opinion (or maybe it's the most popular opinion), but if I'm using pretty much any language for anything that is in development or in any way home-baked (so, it didn't itself come from a distro package)...
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.)
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.)
If you're lucky, this can be "carefully, but still automatically".
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.
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.
The Docker approach is IMHO the most reasonable approach, but the fact is that "in a container" is still regarded as a bad word in many places. We're talking about containers but mostly still embargoed from using them for anything serious.
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.)
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.)
Depends on the size of your business and other factors, but in my experience I feel like if a tool (language, runtime, or application) is core to your business it pays to decouple it from the OS. My industry does a lot of Python work and CentOS uses Python in a lot of their install and management tools. There are more than a few stories about people manually updating /usr/bin/python and ruining their OS. Being able to upgrade the OS independent of our code base is huge weight off our shoulders. Perhaps this even more so applies to Python libraries.
13 months, not 6-12, but, yes, this is _exactly_ the point of the modularity initiative we're launching with F28.
[deleted]
Maybe a Nix or Guix derivation?
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...