
Announcing the release of Fedora 28 - rbanffy
https://fedoramagazine.org/announcing-fedora-28/
======
Blackstone4
>The headline feature for Fedora 28 Server is the inclusion of the new Modular
repository. This lets you select between different versions of software like
NodeJS or Django, so you can chose the stack you need for your software.
Interested? Check out the documentation for using modules [LINK BELOW]. Also
of note: 64-bit ARM (Aarch64) is now a primary architecture for Fedora Server.

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/fesco/en-US/Using_Modules.html)

~~~
sgallagh
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.

------
sandGorgon
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)

~~~
forapurpose
> 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?

~~~
sandGorgon
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.

~~~
forapurpose
> 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.

------
ajross
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.

~~~
rgbrenner
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/Fedora_Release_Life_Cycle)

[https://fedoraproject.org/wiki/End_of_life](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.

~~~
ajross
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.

~~~
rgbrenner
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).

~~~
pfranz
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.

------
LeoPanthera
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](https://docs.fedoraproject.org/f28/release-notes/index.html)
)

~~~
gtirloni
[https://news.ycombinator.com/item?id=16874061](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."_

~~~
mattdm
There is a Copr for it — [https://copr.fedorainfracloud.org/coprs/rhawalsh/dm-
vdo/](https://copr.fedorainfracloud.org/coprs/rhawalsh/dm-vdo/). (Looks like
not yet built for F28, but I expect that to be updated shortly.)

------
madengr
If I can easily try Nvidia binary drivers, and recover without trashing my
system, this is big news.

------
bluedino
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?

~~~
yebyen
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.)

~~~
twic
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.

~~~
yebyen
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.)

