LWN: Comments on "Fedora 20 Beta released"

Fedora 20 Beta released

dashesy — Fri, 22 Nov 2013 20:34:43 +0000

You can use kickstart with local drive, just createrepo locally and refer to it.

Fedora 20 Beta released

pizza — Fri, 22 Nov 2013 20:34:39 +0000

> Kernel-3.10.20 has been released, but Fedora stopped supporting it in F19 at version 3.10.11 and in F18 at version 3.10.14.

Fedora 18 and 19 initially shipped with 3.6.10 and 3.9.0 (respectively) and as new upstream kernels have been released, Fedora has kept up. As I type this, my F18 server is running 3.11.7 and my F19 workstation is running 3.11.8 via Fedora's updates.

> What is needed is an install from local drive in the Add/Remove Programs, where dependencies are checked

You mean something like 'yum localinstall somerandompackage.rpm'?

IIRC if you double-click on a random RPM you've downloaded, the desktop will try to install it for you too (using the same mechanism)

Also, after any installation, Fedora will generate you a kickstart file that will exactly recreate the installation you selected. If you don't want the latest packages installed, then you have the option of disabling it. Alternatively you can do an 'rpm -qa' and paste that list in a kickstart file. Either way you have a guaranteed package set.

(I've been using kickstart for automated, 100% reproducible installations since the RHL7 days..)

Fedora 20 Beta released

rahulsundaram — Fri, 22 Nov 2013 20:33:39 +0000

The kernel release strategy is explained at https://fedoraproject.org/wiki/KernelRebases and https://fedoraproject.org/wiki/Updates_Policy?rd=Package_...

If you have any feedback on that, post to https://lists.fedoraproject.org/mailman/listinfo/kernel

Fedora 20 Beta released

compte — Fri, 22 Nov 2013 19:17:28 +0000

>1) Fedora releases stable kernel updates through the entire life of the distro ...
Kernel-3.10.20 has been released, but Fedora stopped supporting it in F19 at version 3.10.11 and in F18 at version 3.10.14. I remember using F10 with kernel 2.6.27.41, which means 41 revisions instead of just 11 or 14. This kernel was still maintained up to revision 50 something but support for F10 ended there. I could still recompile a source rpm with an updated revision though. See: http://kojipkgs.fedoraproject.org/packages/kernel/
I know, if it's too stable people won't use RedHat, but too unstable not enough experimental users.

>2) kickstart is intended for new system installations, not updates. Use the 'fedup' tool instead, and it will utilize files already present.
Fedup is just for upgrading to a new release and kickstart is loosing it's meaning because it's intended to compile something stable which we never get. What is needed is an install from local drive in the Add/Remove Programs, where dependencies are checked.

>4) Already supported, unless I misread something in the F19 install.
I tried using btrfs in /home directory with others in ext4 when installing without success. I actually have F18 installed in that way but I reused the /home dir during installation.
>5) BTRFS is not default because it is not considered stable, and rightfully so ...
I just don't like LVM because I like having two systems isntalled on the same disk and often diagnose a system from the other. There is probably a way around it but prefer to wait for btrfs.
The rest of the points I can concede.

Fedora 20 Beta released

raven667 — Thu, 21 Nov 2013 22:22:08 +0000

> 1) Fedora releases stable kernel updates through the entire life of the distro [...] When an old kernel is abandoned upstream, they rebase to the current kernel.

This is something I like because the modern kernel development process seems to be providing reliable quality releases, on a schedule, so periodic rebasing on stable releases supported by upstream is much less scary than it used to be. There were very good reasons why the enterprise distros went through all the trouble to backport fixes into their kernel forks for years and years even as that became more and more difficult as upstream diverged farther and farther from their fork but I'm not sure those reasons are as strong today with Linux 3.x than they were with Linux 2.4, the development and testing process has changed since then.

Fedora is doing good work to see how it works out in practice to more closely track the upstream kernel.

Fedora 20 Beta released

pizza — Thu, 21 Nov 2013 21:20:50 +0000

Comments:

1) Fedora releases stable kernel updates through the entire life of the distro -- there have been more than a dozen F19 kernel updates so far, and it's not even through half of its support interval. When an old kernel is abandoned upstream, they rebase to the current kernel. I don't know what more you can ask than that.
2) kickstart is intended for new system installations, not updates. Use the 'fedup' tool instead, and it will utilize files already present.
3) TThis is more of a metadata problem than something to do with Fedora per se, but there are quite likely situations where the Gnome app is better than an equivalent KDE app and may ultimately boil down to user preference.
4) Already supported, unless I misread something in the F19 install.
5) BTRFS is not default because it is not considered stable, and rightfully so -- It's eaten all of my data twice, most recently about three months ago). In any case, BTRFS/LVM/Bare partitions are top-level options when you chose partition layouts/schemes.
6) Your personal preference is not universal.

Fedora 20 Beta released

compte — Thu, 21 Nov 2013 19:15:52 +0000

After F19 I had enough. Things Fedora needs to do to attract/maintain users:

1) Switch to rolling releases or stay more time on the stable kernels. Currently you only get about 10 kernel updates before moving on to the next one.
2) A practical way to update a system with the files you already downloaded. "system-config-kickstart" is too complex and has stopped working.
3) Stir away from some Gnome apps, such as "gnome-chemistry-utils" which only shows some graphs in the periodic table and look at the KDE alternative "kalzium", which gives you information (does not appear in a search with "periodic").
4) Allow btrfs partitions next to ext4 or ext3 ones.
5) Do not have LVM enabled by default, concentrate on btrfs.
6) Have Mate enabled by default.

Fedora 20 Beta released

fandingo — Fri, 15 Nov 2013 18:57:47 +0000

Thanks for the correction. It's easy to lose track of how long some features have been around.

Fedora 20 Beta released

khim — Thu, 14 Nov 2013 17:02:36 +0000

It actually included some GUI libraries, but it's developement was all wrong: instead of asking developers about their needs LSB just packs mature components. Which means that features which developers and users expect to see are just not there. I've already wrote about that: it's basically impossible to build most contemporary applications with just an LSB and if you are pulling distro-specific pieces anyway then what's the point?

Fedora 20 Beta released

khim — Thu, 14 Nov 2013 16:53:39 +0000

Why would I want to write a program (apart from distro tooling) for some specific distribution? Doesn't make much sense, considering the fragmentation of the distro space. What's the supposed benefit over just writing to the APIs of the upstream libraries I want to use?

Most software developers want to ship binaries. Most users want to use binaries (even most FOSS die-hards use binary distributions and not Arch or Gentoo). Which means “writing to the APIs of the upstream libraries” is either not an option or poor option. Couple that with the fact that most software developers out there don't want to ever show sources and you get two alternatives: one poor and another which is even worse.

A cross-distro approach (obviously) would be of far more utility.

Only if it'll be actually usable for software developers.

Why should I prefer it over the tools I like and already know?

Hmm… That's good question. For most developers tools [they] like and already know includes exactly one item and indeed if you explain how to use them to build binaries for all (or at least few major) Linux distributions out there what these tools you may attract some developers. But so far noone managed that feat.

The actual appeal would be a list of interfaces guaranteed to be available on distro X, Y and Z, not some kind of downloadable SDK.

Why? For most developers out there Desktop Linux comes at the fifth place! It was third place, now it's fifth. First four places are Android, iOS, MacOS, and Windows (not necessarily in this order). Well, sometimes it's all about HTML5, but this approach is still hard to use for many types of programs. Linux support is always, always an afterthrough. Yet most distributions act as if they are a kings of the hill and may dictate rules. That's just crazy and irrational.

Ubuntu is the only distribution which finally, finally is playing by rules set by “big boyz” and yes, they achieved some success. There are thousands of applications in Ubuntu's store, for example. Far cry from half million of applications in other big stores, but if you compare the userbase that's quite an achievement.

We'll see how the story will go, but my personal opinion is that Linux Desktop is “on borrowed time”: Android (and ChromeOS) are not quite ready to replace developer's desktop but they are slowly moving in this direction. Situation is quite similar to first 10-15 years of IBM PC (and clones) development. IBM PC killed the workstations and it looks like Android is poised to do the same for PC. After that point there are quite real chance that traditional GNU/Linux distributions will just die off.

Fedora 20 Beta released

mpr22 — Thu, 14 Nov 2013 16:35:46 +0000

That's what I thought, until I fact-checked myself some months back when about to say what you just said. The LSB has included GTK+ since April 2006 (3.1 Desktop), and Qt 4 since January 2008 (3.2).

Fedora 20 Beta released

raven667 — Thu, 14 Nov 2013 14:22:11 +0000

The LSB just never had enough coverage of libraries that applications need to use, it only covered the very basic core C library and system, no GUI libraries or anything. This seems like the right idea but seems to have failed in practice, maybe what will happen is one distro will care enough about binary compatibility and will have the market share to become a de-facto standard which will resolve the issue, at least temporarily.

Fedora 20 Beta released

edgan — Thu, 14 Nov 2013 07:20:42 +0000

I am running Fedora 20 Beta on a Lenovo W530. It is working really well. I am quite happy with it.

The biggest problem I had was getting it to boot into the installer. Unetbootin made an image that wouldn't boot. Fedora USB Live Creator did make an image that booted. Though after it booted it wouldn't read the packages from the flash drive. So I had to give it networking to download the packages from a mirror.

The installer has gotten a little bit better. It still needs some polish.

Once it was installed, it has been good. Another weird issue I had was sound didn't work for a non-obvious reason. I ended up having to boot into Windows, unmute sound, and then boot back into Linux to get sound working.

Fedora 20 Beta released

jdulaney — Thu, 14 Nov 2013 05:15:56 +0000

F20 works fine out of the box headless; I'm running it that way on some ARM h/w.

Fedora 20 Beta released

seyman — Thu, 14 Nov 2013 01:28:55 +0000

> The actual appeal would be a list of interfaces guaranteed to be available on distro X, Y and Z, not some kind of downloadable SDK.

This is the LSB. So few people cared that I don't think it's even around anymore.

Fedora 20 Beta released

sampson — Wed, 13 Nov 2013 23:50:30 +0000

FedUP for 18 -> 19, not working for me.

19 -> 29 Beta works fine last night. I have customer network

The command worked for me:

sudo fedup --network 20 --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/tes...

As my old PC has only 2GB memory left, the first run ended with "cannot allocate memory".

I rebooted and the second run can re-used files downloaded during first run, and everything is fine.

My Network Config for KVM/QEMU are well preserved during the upgrade by FedUP.

Fedora 20 Beta released

nirik — Wed, 13 Nov 2013 22:13:38 +0000

Fedup was actually introduced in Fedora 18. ;)

Fedora 20 Beta released

fandingo — Wed, 13 Nov 2013 21:58:58 +0000

There's no officially supported method for upgrading Fedora before 19.

Fedora 19 introduced the fedup tool, and it handles everything without interaction. A simple

> fedup --network 20

would do the upgrade.

Fedup isn't available for Fedora 18. You could try pointing yum at the Fedora 19 repositories and try a `yum update` that way. (This has been used for years by some people, but was never officially supported or tested.)

The only headless option is PXE, which is easy with Kickstart and Fedora, but that may require BIOS/UEFI and network access that you don't have if it's off-site.

Fedora 20 Beta released

zlynx — Wed, 13 Nov 2013 21:35:21 +0000

So, I've been afraid to upgrade my server running Fedora 18 because I installed it with a screen but it is currently headless.

Does anyone have any data on how risky it is to upgrade to F19 or F20 without a screen or GUI? Is it going to ask questions during the upgrade that no one is there to answer?

Fedora 20 Beta released

lsl — Wed, 13 Nov 2013 21:28:43 +0000

> Ubuntu at least offers an SDK. Not sure how useful it is, but it's first step in the right direction.

Hmm. I don't think an SDK for Distro X is terribly useful. Why would I want to write a program (apart from distro tooling) for some specific distribution? Doesn't make much sense, considering the fragmentation of the distro space. What's the supposed benefit over just writing to the APIs of the upstream libraries I want to use?

A cross-distro approach (obviously) would be of far more utility. But even then, I somehow fail to see the point of it. Why should I prefer it over the tools I like and already know? The actual appeal would be a list of interfaces guaranteed to be available on distro X, Y and Z, not some kind of downloadable SDK.

Fedora 20 Beta released

jspaleta — Wed, 13 Nov 2013 20:25:49 +0000

you missed the point... The Ubuntu SDK is NOT "distribution" wide.

The Ubuntu SDK is tied directly to the Unity8 offering and tied directly to the sandbox security model being introduced with Mir. You cannot and will not be able to safely run applications generated through the Ubuntu app development process on Unity7 desktop. Jono reaffirmed this just today in his video chat.

Apps built through the Ubuntu SDK process which lead to click packages will NOT be in the "distribution" repos that define the Ubuntu "distribution". And will not go through existing "distribution" quality or security review processes like other "disitribution" packages do.

The click packages will live in a new space, and will rely on the sandboxing security model of the click packages which is tied specifically to Mir. People building apps with the Ubuntu SDK, and grinding out click packages via the developer tooling will not have apps that will run securely for any desktop still making use of X... even if running on top of XMir. Only "native" Mir environments sessions will safely be able to run these apps.

The Ubuntu SDK as designed is not a full distribution solution. It is a single interface silo solution which will result in applications that can only be safely run inside that technology silo, again _only_ Mir native enbironments.

Which is fine, as far as it goes... but its not a "distribution" wide solution and will NOT be. The Ubuntu SDK and the processes being spun up around are specific to the Unity _product_, which is much narrower a definition than a "linux distribution". Everything around the Ubuntu SDK is tooled in terms of a UI platform..which is going to be a distinct subset of the Ubuntu distribution whose bounds are defined by the repository structure.

Everything you see with the SDK, is a mobile "platform" push which will morph over into a convergent platform push, if and when Mir is capable of providing a robust desktop. But every other desktop UI available in the Ubuntu "distribution" for install will not be able to use the applications being generated through this new platform app development process.

Its really tiresome actually, how Canonical has overloaded the Ubuntu branding to mean so many different things. Ubuntu the wider community project does not benefit at all from the Ubuntu SDK. Ubuntu the Canonical controlled product...does. The self-inflicted brand confusion between the project space and the product space is really going to really start being a huge pain, once Unity8 is a viable desktop session and the click packaged application start showing up.

Fedora 20 Beta released

khim — Wed, 13 Nov 2013 19:44:33 +0000

That's why I've said that Ubuntu is the only free distribution which thinks about that. Ubuntu is not there yet. It does not yet offers a stable, supported ABI to the application developers and as you've correctly pointed out that it may be a flop. But at least it thinks about ABI issues and tries to offer some coherent story. Other distributions just pack various packages and pat themselves on the back if they break ABI. Apparently the goal is not to make it possible to actually use your distribution for anything but to actively fix all the incompatibilities. Which only works of all the software comes from the distribution. This approach does not scale because locally developerd scripts and programs don't (and should not!) come from the distribution.

Fedora 20 Beta released

mathstuf — Wed, 13 Nov 2013 18:08:25 +0000

IIRC, 1.5 removed some long-deprecated APIs, breaking API compatibility. Not everyone uses semantic versioning, so thinking "oh, minor version change -> no big deal" is not an assumption I'd apply too liberally.

Fedora 20 Beta released

torquay — Wed, 13 Nov 2013 17:34:40 +0000

IIRC the main API/ABI breakage in F20 is libpng 1.6.

Hmm. This would suggest API/ABI breakage in a minor version (F19 has libpng 1.5), which is quite bad practice.

According to the libpng entry on upstream tracker, the differences between libpng 1.5 and 1.6 are one removed symbol and a whole bunch of relatively minor changes (eg. some pointers now have the "restrict" qualifier). These may very well amount to ABI/API breakage, but the upstream tracker is not perfect (ie. it makes mistakes), and/or the changes might be benign (eg. the removed symbol may have been for internal use only, and adding the "restrict" qualifier simply exposes internal assumptions explicitly).

Nevertheless, it would be very useful to produce a report of all API/ABI changes between F19 and F20 based on upstream tracker data. Data with some noise is better than no data.

Fedora 20 Beta released

jspaleta — Wed, 13 Nov 2013 16:40:59 +0000

The SDK for Ubuntu is quite... new... and is part of the mobile push which saw Unity rewritten in qt. The sdk is essential...qt5..and the IDE is just qtcreator. Prior to the Unity rewrite, Ubuntu for years struggled to have a documented API.

That isn't to knock the effort to establish the Ubuntu SDK, but keep it in context. The Ubuntu SDK is part of the mobile push. Positioned to make it possible for people to put together mobile "apps" and publish specialized "click" package payloads..outside of the mainline repository structure.
But the guts of the SDK Ubuntu is standing up...the breadth and scope of it.. to define a coherent usable developer experience is the work being done but the qt upstream. So who's thinking about a solid SDK? The Qt guys and gals. Canonical is leveraging and rebranding that work.

We really do not know if Ubuntu will stick with the Qt SDK or not yet. They move from one technology to another so... "quickly" (pun intended) that it's really hard to say what's going to happen with the Ubuntu SDK and how much vendorification of the Qt APIs it will grow. I expect they'll start significantly diverging the Qt developer experience soon.

Fedora 20 Beta released

khim — Wed, 13 Nov 2013 14:37:16 +0000

Unless I'm mistaken, Ubuntu just inherits that from Debian, no?

Ubuntu at least offers an SDK. Not sure how useful it is, but it's first step in the right direction.

AFAIR Mandrake/Mandriva/Mageia also follows the Debian practice of creating new packages when ABI breakage occurs, avoiding the need to recompile packages depending on the older ABI.

It's not enough to create new package with a new name, you also need to support old one, too. AFAICS only RHEL does that consistently, although later versions of Ubuntu are doing much better than before.

Workaround for broken wifi

cbcbcb — Wed, 13 Nov 2013 13:30:31 +0000

If NetworkManager doesn't recognise your wifi correctly, there is a workaround here

https://bugzilla.redhat.com/show_bug.cgi?id=1015598

Fedora 20 Beta released

salimma — Wed, 13 Nov 2013 10:58:14 +0000

Unless I'm mistaken, Ubuntu just inherits that from Debian, no? And other Debian derivatives share that.

AFAIR Mandrake/Mandriva/Mageia also follows the Debian practice of creating new packages when ABI breakage occurs, avoiding the need to recompile packages depending on the older ABI

Fedora 20 Beta released

hadrons123 — Wed, 13 Nov 2013 10:33:47 +0000

Best Fedora beta ever for me. I 'm using MATE and couldn't be more happier. Tried gnome a bit with alpha but wasn't even able to change adwaita-icon-theme from the default without breaking the shell.

Fedora 20 Beta released

pbonzini — Wed, 13 Nov 2013 08:33:09 +0000

IIRC the main API/ABI breakage in F20 is libpng 1.6.

Beta then upgrade

lkundrak — Wed, 13 Nov 2013 08:01:13 +0000

Yes. If it boots and yum works it's very likely that it will upgrade smoothly.

Beta then upgrade

epa — Wed, 13 Nov 2013 06:59:17 +0000

If you install the beta is it expected that you can smoothly upgrade to Fedora 20 final?

Fedora 20 Beta released

khim — Wed, 13 Nov 2013 06:38:28 +0000

AFAICS Ubuntu is the only free distribution which thinks about that. There are RHEL, of course, but it solves the problem in a different way (with glacial pace of changes). Everything else (including Fedora) don't even have a defined API/ABI, it's more or less defined as "whatever we happen to include in the set of packages and if they are changed they you just need to recompile all your stuff".

Fedora 20 Beta released

torquay — Wed, 13 Nov 2013 05:17:30 +0000

Is there a list of API and ABI changes since Fedora 19 ? It's important to have such a list, as often enough user code written in a Fedora N environment refuses to run or compile under Fedora N+1. (By "user code" I mean stuff that's not part of the distro mud ball).

Avoiding API and ABI breaks would be the obvious solution, but if that's not doable, then at least having a list the API/ABI changes (where and how) can save a lot of development effort.