User: Password:
|
|
Subscribe / Log in / New account

The Grumpy Editor's Fedora 18 experience

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

By Jonathan Corbet
January 15, 2013
Delays in Fedora releases are a standard part of the development cycle; users would likely approach a hypothetical non-delayed release with a great deal of concern. Even so, the Fedora 18 release stands out: originally planned for November 6, 2012, it did not make its actual appearance until January 15 — more than two months later. So it was with some trepidation that your editor set out to install the final Fedora 18 release candidate on his laptop. With so many delays and problems, would this distribution release function well enough to get real work done?

Upgrading

Traditionally, in-place upgrades of Fedora systems have been done with the "preupgrade" tool; reports of preupgrade problems have been prevalent over the years, but your editor never encountered any difficulties with it. With the F18 release, though, preupgrade has been superseded by the new "FedUp" tool. Indeed, the project has committed to FedUp to the degree that the Anaconda installer no longer even has support for upgrades; at this point, the only way to upgrade an existing Fedora system appears to be to use FedUp and a network repository. Given that, one would expect FedUp to be a reasonably well-polished tool.

In truth, upgrading via this path required typing in a rather long command line (though that should get shorter with the official F18 release when the repository moves to a standard place). The tool then set off downloading 1,492 packages for the upgrade without even pausing to confirm that this was the desired course of events. Needless to say, such a download takes a while; there are no cross-release delta RPMs to ease the pain here. At the end of this process, after FedUp had nicely picked up the pair of packages that failed to download the first time, it simply printed a message saying that it was time to reboot.

After the reboot one gets a black screen, a pulsating Fedora logo, and a progress bar that cannot be more than 200 pixels wide. That bar progresses slowly indeed. It is only later that one realizes that this is FedUp's way of telling the user that the system is being updated. One would at least expect a list of packages, a dancing spherical cow, or, at a minimum, a message saying "your system is being upgraded now," but no such luck. To all appearances, it simply looks like the system is taking a very long time to boot. At the end of the process (which appears to have run flawlessly), the system reboots again and one is faced with the new, imposing, gray login screen. Fedora 18 is now in charge.

What do you get?

At first blush, the distribution seems to work just fine. Almost everything works as it did before, the laptop still suspends and resumes properly, etc. Nothing of any great significance is broken by this upgrade; there may have been problems at one point, but, it seems, the bulk of them were resolved by the time the Fedora developers decided that they should actually make a release. (That said, it should be pointed out that using FedUp precluded testing the Anaconda installer, which is where a lot of the problems were.)

One should not conclude that the upgrade is devoid of little irritations, though; such is not the nature of software. Perhaps the most annoying of those irritations resembles the classic "GNOME decided to forget all of your settings" pathology, but it's not quite the same. For whatever reason, somebody decided that the modifier key used with the mouse (to move or resize windows, for example) should be changed from "Alt" to "Super" (otherwise known as the "Windows key"). This is a strange and gratuitous change to the user interface that seems bound to confuse a lot of users. The fix is to go into dconf-editor, click on down to org→gnome→desktop→wm→preferences and change the value of mouse-button-modifier back to "<Alt>".

The GNOME developers, in their wisdom, decided that there was no use for a "log out" option if there is only one user account on the system. Modern systems are supposed to be about "discoverability," but it is awfully hard to discover an option that does not exist at all. Another trip into dconf-editor (always-show-logout under org→gnome→shell) will fix that problem — or one can just create a second user account.

Other glitches include the fact that the compose key no longer works with Emacs (a bug report has been filed for this one). This key (used to "compose" special characters not normally available on the keyboard) works fine with other applications, but not in Emacs. Also worth mentioning, in the hope it saves some time for others: the powertop 2.2 release shipped with F18 has changed the user interface so that the arrow keys, rather than moving between tabs, just shift the content around within the window. The trick is to use the tab key to go between tabs instead.

So what does this release have to offer in the way of new features? There is, of course, the usual array of upgraded packages, starting with a 3.7.2 kernel. Your editor, who has been working with Debian Testing on the main machine in recent months, still misses the rather fresher mix of packages to be found in the Fedora distribution.

Beyond that, there is the ability to use 256 colors in terminal emulator windows; your editor has little love for multicolor terminal windows, but others evidently disagree and will be happy with the wider range of color choices. Many users may also be pleased by the inclusion of the MATE desktop, a fork of the GNOME 2 environment. Your editor gave it a quick try and found that it mostly worked with occasional glitches. For example, the terminal emulator came up with both the foreground and background being black, suggesting that the MATE developers, too, are unenthusiastic about the 256-color feature. At this point, though, MATE feels something like a "70's classics" radio station; even if the music was better then, the world has moved on.

Beyond that, Fedora 18 offers features like Samba 4 and a new wireless hotspot functionality. The latter looks like a useful way to extend hotel Internet service to multiple devices, but your editor was unable to get it to work. There is also the controversial placement of /tmp on a tmpfs filesystem; that can be turned off by the administrator if desired. Detection of MDNS devices (printers and such) should work better even with the firewall in place. The internals of the yum package manager have been replaced with a system that is intended to perform better. An experimental version of a yum replacement, intended to provide better performance, is available in this release. The Eucalyptus cloud manager is now available. And so on.

The list of new features is rather longer than that, naturally; see the F18 feature page and the release notes for a more complete summary. But, for most Fedora users, it will be just another in a long series of releases, just later than most. This release's troubled development cycle does not appear to have led to a less stable distribution at the end.


(Log in to post comments)

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 16:19 UTC (Tue) by nevyn (guest, #33129) [Link]

> The internals of the yum package manager have been replaced with a system that is intended to perform better.

This is probably referring to "dnf" which is available in F18, but has not replaced yum in F18.
There are some improvements in yum for F18 (as always), but nothing that could be described as "replacing the internals".

DNF

Posted Jan 15, 2013 16:56 UTC (Tue) by corbet (editor, #1) [Link]

Sigh, yes, I misread the DNF page. Corrected, apologies for the confusion.

DNF

Posted Jan 15, 2013 21:39 UTC (Tue) by cyperpunks (subscriber, #39406) [Link]

Any way, give dnf a try, is faster than yum for sure.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 17:00 UTC (Tue) by quintesse (guest, #14569) [Link]

I'm just getting a message that it can't find the boot images. Looking at what the mirror manager returns it seems that the only fedora-install-18 repository available is for ppc64 arch. Don't see any mention on the fedora website though that they're working on a problem or anything.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 17:14 UTC (Tue) by mattdm (subscriber, #18) [Link]

First I've seen a report like this. Can you give some more details? (Ideally either post to fedora-users list or to http://ask.fedoraproject.org )

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 17:28 UTC (Tue) by nirik (subscriber, #71) [Link]

Yes, there's a known issue with mirrormanager and fedup right now.

Please hang on, we are working hard to fix it. ;)

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 18:07 UTC (Tue) by quintesse (guest, #14569) [Link]

It's not the first time that a new Fedora release has had problems that prevented installation and it's not the first time I've thought that it would be a great idea to have some kind of online service that the upgrader/installer could use to display urgent informational messages.

The simplest thing would maybe be a link to some web page that appears if the installation fails. The web page could list all the currently known installer problems that they found out about after the installer was released.

But especially in the case of the installer where you might actually be trying to install on your only computer (not so common anymore these days with smart phones, but still) so checking the internet might be a problem it would be nice if those problems(hopefully with solutions) might be displayed right in the installer.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 19:22 UTC (Tue) by nirik (subscriber, #71) [Link]

I don't disagree with you. ;) Would be nice to have a single place to update everyone that there's a problem being worked on and then notify them when it's fixed.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 9:22 UTC (Wed) by rvfh (subscriber, #31018) [Link]

It's called Twitter :-P

The Grumpy Editor's Fedora 18 experience

Posted Jan 17, 2013 0:08 UTC (Thu) by voltagex (subscriber, #86296) [Link]

Could be good to include that feed in Anaconda.

The Grumpy Editor's Fedora 18 experience

Posted Jan 18, 2013 13:49 UTC (Fri) by drag (subscriber, #31333) [Link]

that sounds terrible.

The Grumpy Editor's Fedora 18 experience

Posted Jan 25, 2013 10:54 UTC (Fri) by mgedmin (subscriber, #34497) [Link]

Ubuntu did that in their installer. A bit later they discovered some HTML injection vulnerability in the Twitter feed display code.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 19:21 UTC (Tue) by nirik (subscriber, #71) [Link]

fedup should be happy and working for network upgrades again now. ;)

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 21:49 UTC (Tue) by quintesse (guest, #14569) [Link]

Upgrading right now, thx! ;)

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 0:01 UTC (Wed) by quintesse (guest, #14569) [Link]

OMG they made it impossible to disable "suspend on lid close" (they even removed it from the tweak ui and no extension either, this is becoming so ridiculous)

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 0:16 UTC (Wed) by nirik (subscriber, #71) [Link]

It's now handled (by default) by systemd.

Either:

a) edit /etc/systemd/logind.conf and tell it to not do that.

or

b) run systemd-inhibit to prevent it from doing so when you don't want it to.
(something like: 'systemd-inhibit --what=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch sleep NNNNN'

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 0:38 UTC (Wed) by quintesse (guest, #14569) [Link]

I tried editing the logind.conf but it didn't seem to do anything, is there some service that has to be restarted first?

(I also tried systemd-inhibit, but all the examples I find seem to be missing some important part because the command always complains)

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 4:48 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

yes, restart systemd-logind

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 10:44 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]

Should this even have gone in without a way to disable it (preferably the same way it used to be possible to disable)? I think it's a good feature and a reasonable place to put this feature - but some degree of user control shouldn't be optional. I'm rather unhappy not to be able to easily control power management.

Are there hooks for the UI to control this, Lennart?

(I use the feature to disable power management in the battery applet frequently, it's a smart and useful feature which I'd rather not see broken)

I'll surely test this feature for the upcoming openSUSE 12.3 release to make sure I raise a bug if this is an issue there too. I'd rather not have us ship it this way.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 22:50 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

DEs can control the stuff on their own if they wish. logind only does that if no DE is around or if the DE is too simply to do lid switch handling of its own.

With other words: KDE can do whatever it wants, it can tell logind to stay away from the lid switch, or it can leave logind in control, and can even dynamically do that at any time.

GNOME for example tells logind to stay away from the lid switch if an external monitor is plugged in, but otherwise let's logind handle everything.

Joke alert

Posted Jan 17, 2013 18:16 UTC (Thu) by man_ls (guest, #15091) [Link]

What!? You mean to say that systemd doesn't have its own embedded desktop environment yet? Really hope you are working on it! (Disableable of course. Is that a word? Apparently not.)

Joke alert

Posted Jan 18, 2013 10:41 UTC (Fri) by dgm (subscriber, #49227) [Link]

A desktop environment? Why?

I hereby propose that systemd gets merged with Emacs. Think of the possibilities! It would become sentient in less than 24 hours...

:-P

Joke alert

Posted Jan 18, 2013 16:12 UTC (Fri) by man_ls (guest, #15091) [Link]

I hereby propose your message as "LWN comment of the week".

Joke alert

Posted Jan 22, 2013 23:59 UTC (Tue) by DonDiego (guest, #24141) [Link]

That's at least the comment of the month and let's see if anybody gets close in 2013 ;-p

Joke alert

Posted Jan 18, 2013 22:49 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

But whose personality would it have? Stallman's? Lennart's? It's going to have a lot of enemies to start out either way…

Joke alert

Posted Jan 19, 2013 15:52 UTC (Sat) by nix (subscriber, #2304) [Link]

You can already run Emacs as /sbin/init, so *obviously* the solution is to reimplement systemd in Emacs Lisp. (We might need to wait for the concurrency branch to mature, so as not to block for too long.)

My normal arguments about init being critical software and thus being software that should not change too fast (because if it dies the system is useless and instantly panics) is moot here, because if your Emacs dies your system is useless in any case. I mean, what else is an OS for?

Joke alert

Posted Jan 19, 2013 16:44 UTC (Sat) by apoelstra (subscriber, #75205) [Link]

>You can already run Emacs as /sbin/init,

This isn't true, is it? Do people do that?

I'm scared to try because I don't know Emacs well enough to undo it.

Joke alert

Posted Jan 19, 2013 20:10 UTC (Sat) by tom.prince (guest, #70680) [Link]

> I'm scared to try because I don't know Emacs well enough to undo it.

If you just pass init=/usr/bin/emacs on the kernel command line, you shouldn't need to do anything to undo it.

Joke alert

Posted Jan 20, 2013 8:04 UTC (Sun) by apoelstra (subscriber, #75205) [Link]

> If you just pass init=/usr/bin/emacs on the kernel command line, you shouldn't need to do anything to undo it.

That didn't work. Maybe this is a bug in Fedora's initram, because it worked the last time I tried it (several years ago, and with an actual init program).

For those curious, I did manage to do it though, by popping open my initramfs and adding an explicit INIT=/bin/emacs after the code which sets the INIT variable. The result was emacs saying "cannot open /dev/tty" and bailing, and then the kernel panicked.

If only udev had been merged into emacs..

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 0:27 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

HandleLidSwitch=ignore in /etc/systemd/logind.conf

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 7:11 UTC (Wed) by ekj (guest, #1524) [Link]

Is there also "IgnoreIfOnWallPowerOtherwiseSuspend" ?

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 13:34 UTC (Wed) by cortana (subscriber, #24596) [Link]

Perhaps the kernel needs to grow a virtual machine to run a program which can more precisely control the conditions under which the system is suspended.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 13:40 UTC (Wed) by ekj (guest, #1524) [Link]

If you need real flexibility it's better to run a userspace-program when something related to power-status changes, and let that program decide what to do.

But having different rules for what to do when you're plugged in, relative to when you're on battery-power is something that's fairly standard, and something there's a good reason for.

The Grumpy Editor's Fedora 18 experience

Posted Jan 29, 2013 15:16 UTC (Tue) by oblio (guest, #33465) [Link]

Windows has already grown this "virtual machine", since it has different power setting depending on the power source: battery or plugged in.
I doesn't seem to absurd to not make the laptop suspend when the lid is closed while plugged in, since it could use an external display and keyboard. But when it's not plugged in you don't want it chugging along in your backpack, getting fried due to the lack of ventilation.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 15:24 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

Seconded. I find this use case very useful.

When the machine is plugged in, I mostly close the lid to turn off the screen so that it does not disturb me from sleep, but can still be alive finishing a build.

When it's not plugged, I'm probably travelling and I close the lid so that I can carry the laptop in my bag.

This even sounds like a sane default to me and I'll miss the setting terribly if it goes away from my desktop.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 18:45 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

In systemd 196, I added the option of 'lock' to the lid switch, though it appears as though F18 has 195 and probably won't get that upgrade (though a backport should be minimal work/maintenence; I'd certainly love to see it in RHEL7 at least). This causes all sessions to receive a 'lock' signal. If there's a signal for when the lid closes as well, the listener in the DEs could check if they're on AC and suspend if so. I'm writing a minimal Python daemon which does what I want (with flexibility); haven't worked on it for a while though.

The Grumpy Editor's Fedora 18 experience

Posted Jan 17, 2013 8:52 UTC (Thu) by michich (subscriber, #17902) [Link]

F18 is going to get an update to systemd v197. It's in updates-testing now: https://admin.fedoraproject.org/updates/FEDORA-2013-0655/...

The Grumpy Editor's Fedora 18 experience

Posted Jan 18, 2013 22:37 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Ah, I had missed it in Koji because it has a trailing '.1' instead of fc18. Sounds good :) .

The Grumpy Editor's Fedora 18 experience

Posted Jan 18, 2013 9:06 UTC (Fri) by Kamilion (subscriber, #42576) [Link]

Forgive me for sidebusting here, both as a normally ubuntu user and the occasional windows 7 gamer. I've been playing with FC18-lxde in a client project for the last few days, but have been actively lurking the systemd and wayland MLs since they were wee footnotes on LWN, and frowning my little heart out at *ubuntu for keeping upstart over systemd. But hey, least it isn't the tangle of LFS sysv scripts or openrc!

My Asus netbook currently has the exact settings you speak of, under windows 7. If the machine is on AC, display off. If the machine is on battery, suspend. I find myself instinctively pulling the cord out before closing the screen when I'm about to take it somewhere. Just consider it another plus one to the idea, since I think it's Asus's fancy 'superhybridengine' power profiles that seem to invoke this behavior.
Can't complain, since they threw a free windows license in my face, might as well stick steam on it.

On the upside, FC18 ships with systemd 19*, so it'd be pretty sane to send a patch to the ML and expect to be able to build and utilize the resulting fix. (haha, systemd-44 patches? YGTBSM.)

The Grumpy Editor's Fedora 18 experience

Posted Jan 29, 2013 8:15 UTC (Tue) by Duncan (guest, #6647) [Link]

Anybody that's serious about having their laptop run differently on wall power than it does on battery should have a look at laptop-mode-tools.

Originally designed to deal with the kernel's laptop-mode, it now ships a plethora of scripts designed to control all sorts of things. The defaults are sane and reasonable in most cases, but those who feel the need can tweak settings to their heart's content (as naturally I have, being a gentooer =:^)

rpmfind doesn't appear to list any fedora packages, but it does list mandriva/opensuse/sourceforge/mageia/dagfabian-rhel noarch packages, upto 1.61, which is only a version behind the 1.62 that's showing up here on gentoo (and that adds systemd support according to the changelog, so anyone running that will probably want to grab 1.62 from the home page, there's Fedora-specific instructions), and it lists homepages/sites for it as well, so that would appear to be a reasonable place for rpm-based-distro folks at least to start looking for more, if they're interested.

http://www.rpmfind.net/linux/rpm2html/search.php?query=la...

http://www.samwel.tk/laptop_mode/

But you really have to take a look in the tarball to see all the modules it comes with, and thus the configuration options. =:^)

While I don't see a direct lid-switch module in the 1.60 tarball that's what I have on my (slightly dated) netbook install, there's hooks for adding commandlines to execute at plug/unplug, and it'd be simple enough to add the commands above, there.

Duncan

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 22:54 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

We only implement the most basic policy in systemd's logind: We give the user/admin a way to disable logind's built-in lid switch handling entirely, and we give DEs/apps a way to turn it off temporarily. DEs may then build on that and implement a smarter policy, that takes other conditions into account.

GNOME for example turns off lid switch handling if an external monitor is plugged in. If you want a different policy, file a bug against GNOME or hack it up yourself.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 2:58 UTC (Wed) by apoelstra (subscriber, #75205) [Link]

Thanks, done! Wow, that was easy. My DVD drive died since installing Fedora 17, so I was hoping that there'd be such a simple upgrade process for 18.

However, I did encounter a problem: after asking for my disk password, systemd only decrypts my / partition, not my /home, which caused a cascading effect and dropped me into an emergency shell.

Running journalctl showed the original problem as:

Jan 15 18:05:45 titanic systemd-tty-ask-password-agent[527]: open(/run/systemd/ask-password/ask.jgeHtn): Permission denied

I was very impressed with journalctl's verbose output, but it didn't tell me where "ask.jgeHtn" was created (or destroyed, since 'ls' did not find it from the emergency shell). So I had no way to get more detailed information about what was going on.

In the end, I disabled selinux (that's the fix for "Permission Denied" as root, right? ;)) and typed 'systemctl default' to continue booting, which is okay for now. Later I will see how to fix my policy properly.

What is the proper channel to report this?

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 4:47 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

That's a temporary file that is renamed later on to the real name. Sounds like an selinux AVC, and should be reported on rhbz against the selinux-policy package.

The Grumpy Editor's Fedora 18 experience

Posted Jan 17, 2013 13:20 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> My DVD drive died since installing Fedora 17

You can simply dd the ISO to a USB flash drive and boot from it. I have not tested with Fedora 18 yet, but it has worked that way for several releases.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 17:04 UTC (Tue) by mordae (subscriber, #54701) [Link]

For me it's very frequent i915-related gnome-shell crashes, silly offline updates I work around by using yum directly, same change to alt/super-keys as you did and most annoyingly (is that a word?) the gnome keyboard layout switching does not work anymore, unless you ctrl+space to a different input method, which messes up with focus and works only 50% of time.

But it's mostly better, so as long as regressions are fixed eventually...

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 0:17 UTC (Wed) by grunch (subscriber, #16603) [Link]

I *just* took the plunge. This was the cleanest, quickest, dare I say *easiest* Fedora upgrade I've yet experienced (having left it after FC4 and returned at F13). I installed FedUp and off I went. Now running F18. I tried F18-beta on a VM and was pretty unimpressed with the new installer at the time. Time to try it again.

I also noticed the setting for the Alt/Super change under the "Windows" tab in the GNOME Tweak Tool ("Modifier to use for modified window click actions"). So no need to invoke the scary dconf-editor to change it.

No complaints so far! Nice work!

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 9:54 UTC (Wed) by ovitters (subscriber, #27950) [Link]

I use Fedora on a laptop. Upgraded to Fedora 18 yesterday. Really easy, though I think there is still enough room to make it easier.

e.g. slightly more info during the upgrade (you can press escape, but that is way too much info), integrated notification, a GUI instead of a command line application, and no manual steps like "run grub"

IMO the only info I'd want during the upgrade is an ETA, a reminder that it is upgrading and something to know that it isn't stuck.

Still, very easy and was impressed.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 23:31 UTC (Wed) by mordae (subscriber, #54701) [Link]

It came out a lot more whiny than I intended. :-D

The i915 issues have disappeared as soon as I've upgraded to rawhide kernel (the regression that bit me have been fixed in git) and the gnome-shell have been stable ever since.

Layout switching still sucks, although I have found both-shifts-toggle in the tweak tool, switching takes about 1 second to complete, which breaks my work flow when editing technical text.

The Grumpy Editor's Fedora 18 experience

Posted Jan 17, 2013 19:15 UTC (Thu) by proski (subscriber, #104) [Link]

For some reason, the keyboard switching with Alt-Shift survived on one of the three systems I upgraded. No idea why. I'm even thinking of making copies of two systems and "converging" them, making sure the same packages are installed, comparing the /etc directories etc.

Why doesn't GNOME allow layout switching with a combination of modifiers? I'm using Alt-Shift-Space now and it's extremely unreliable. I have to be very careful and check that the layout switching has taken effect before I start typing.

The Grumpy Editor's Fedora 18 experience

Posted Jan 18, 2013 4:33 UTC (Fri) by proski (subscriber, #104) [Link]

Sorry for replying to myself! The fix is

gsettings set org.gnome.settings-daemon.plugins.keyboard active false

LXDE users can simply disable GNOME settings daemon in Preferences->Desktop Session Settings. X needs to be restarted by init 3/init 5 or by reboot. Logout is not enough.

Once again, GNOME comes with a new shiny feature and ships it before it's good enough to replace the existing solution. The developers are aware of it and promise to implement Alt-Shift some day.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 19:54 UTC (Tue) by zlynx (subscriber, #2285) [Link]

I recently upgraded also.

The biggest issue for me so far is that Firefox seems to have a multithreading bug using the GTK libraries. It'll just go unresponsive and hang, then GDB shows that all the threads are stuck in locks, several of them doing GTK operations.

I should file a bug report but I can't reproduce it very often. This never happened in Fedora 16.

I also had a terrible time with the Anaconda installer. For whatever reason, Anaconda would freeze up, also in GUI operations it seemed. Using strace on its threads would unfreeze it.

And when the GUI was working correctly it was less than helpful. I don't know who designed the new disk partitioning but they really could have done a better job. Such as just using gparted instead of their own incomplete buggy thing. I was trying to do a hybrid EFI/BIOS boot on a GPT disk label. I had to eventually give up and manually wipe the partitioning using fdisk before Anaconda would even attempt to work correctly.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 20:08 UTC (Tue) by mbaldessari (guest, #36769) [Link]

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 20:46 UTC (Tue) by zlynx (subscriber, #2285) [Link]

Looks likely. Sounds like they found the problem. I'll try disabling my Java plugin and see what happens.

The Grumpy Editor's Fedora 18 experience

Posted Jan 15, 2013 22:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

> I was trying to do a hybrid EFI/BIOS boot on a GPT disk label

That's... a really bad idea. It's unsupportable (since many systems will absolutely choke on that kind of setup), and so any UI that makes it easy for you to configure a system in that way is actually a UI that makes it easy for people to accidentally configure a broken system.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 16:23 UTC (Wed) by zlynx (subscriber, #2285) [Link]

There isn't any other way to be able to easily switch your system BIOS from standard to EFI.

But that really isn't the point. The partition tool couldn't even manage to write a new partition label. I ended up with two swap partitions and a leftover root partition from the previous install while thinking that I'd managed to remove everything.

Seemed very buggy.

Nautilus

Posted Jan 15, 2013 22:22 UTC (Tue) by jamielinux (subscriber, #82303) [Link]

Been using f18 for weeks now, but command-line is my usual file manager so only just noticed the "close" button has been removed from Nautilus. Is this a sign that "close" buttons are going the way of the dodo, at least for the GNOME design team?

Nautilus

Posted Jan 16, 2013 3:59 UTC (Wed) by liam (subscriber, #84133) [Link]

Assuming that it is fullscreened you have to go to the App Menu (click on the Nautilus icon in the top bar) to close it.
Yeah, I keep forgetting how to close some of these Gnome apps, so...FUN!

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 1:12 UTC (Wed) by cry_regarder (subscriber, #50545) [Link]

Too bad there still isn't fedup for fedora 16.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 1:18 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

This is documented as a current limitation in the fedup wiki page. You can upgrade to Fedora 17 using preupgrade or yum and then fedup to Fedora 18 as a workaround.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 12:48 UTC (Wed) by jwakely (guest, #60262) [Link]

Which is a poor workaround as it involves downloading the entire F17 distro that I have no intention of ever using, just to immediately overwrite it with F18.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 16:27 UTC (Wed) by nevyn (guest, #33129) [Link]

F17 was the release that included /UsrMove ... so _don't_ use yum to upgrade from F16 to it.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 17:28 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Why not? You just follow the steps outlined at

https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum...

The Grumpy Editor's Fedora 18 experience

Posted Jan 21, 2013 15:45 UTC (Mon) by nevyn (guest, #33129) [Link]

If you follow your link there is a giant yellow warning box at the top of the screen telling you not to do what you are recommending.

The Grumpy Editor's Fedora 18 experience

Posted Jan 21, 2013 18:59 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

That's not what the warning says and I have been doing that for years. YMMV.

The Grumpy Editor's Fedora 18 experience

Posted Feb 2, 2013 2:17 UTC (Sat) by vonbrand (guest, #4458) [Link]

This is the first time in many, many years that /usr/bin and /bin are merged, so...

The Grumpy Editor's Fedora 18 experience

Posted Feb 2, 2013 2:31 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Well, thats handled entirely via the dracut module rather than yum.

Other desktop support?

Posted Jan 16, 2013 8:25 UTC (Wed) by eru (subscriber, #2753) [Link]

Our Grumpy Editor seems to have looked at just Gnome and MATE desktops, but as someone who hasn't used Gnome regularly since about 1999 I would have appreciated also some words about how Fedora 18 treats KDE and XFCE. Are they second-class citizens, or a would Fedora be a reasonable choice for their fans?

Other desktop support?

Posted Jan 16, 2013 8:55 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

KDE is ihmo the best DE Fedora ships, the Fedora KDE team is very active and keeps things current at all times. Recommended.

Other desktop support?

Posted Jan 16, 2013 9:06 UTC (Wed) by micka (subscriber, #38720) [Link]

Unlike the Debian one which is stuck at an antiquated version sinces months. I had no incentive to test any other distribution, maybe I should try Fedora.

Other desktop support?

Posted Jan 16, 2013 9:54 UTC (Wed) by jku (subscriber, #42379) [Link]

Wheezy has been frozen for 6 months now. I'm not defending the Debian release policy, I'm just pointing out that KDE is probably not being especially disrespected here: almost everything in Debian is currently several months old.

Other desktop support?

Posted Jan 16, 2013 10:54 UTC (Wed) by micka (subscriber, #38720) [Link]

In fact, I don't really care for Wheezy. I've been using sid/experimental for as long as I can remember (maybe before 2000, I don't know), I've seen many person trying to explain why a testing freeze implies an unstable freeze but never with convincing arguments.

And unlike most other outdated applications, you don't need to rebuild the package with one or two rdeps, you must build a whole pile of pieces.

Other desktop support?

Posted Jan 16, 2013 13:14 UTC (Wed) by juliank (subscriber, #45896) [Link]

It's simple: There are more unstable users than testing users. By freezing unstable, the two remain relatively close; so the chance that a user of unstable catches a testing bug is larger.

Other desktop support?

Posted Jan 16, 2013 13:27 UTC (Wed) by micka (subscriber, #38720) [Link]

I don't see how that's a good argument. Shouldn't the ones that expressed interest in testing becoming stable (having testing as source) be the ones to test testing ?

And if there is not enough people to test testing, maybe it just means that there is not point in releasing stable (and in freezing testing) ?

Other desktop support?

Posted Jan 16, 2013 13:43 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

You appear to have not-universally-accurate assumptions about why people choose to run testing. For example, I run testing because I want a "buffer" between me and the very latest updates, but equally don't want to be running the antiquated versions of things found in stable.

Other desktop support?

Posted Jan 16, 2013 13:53 UTC (Wed) by micka (subscriber, #38720) [Link]

OK, that's why you use testing, that's good enough, I have no problem with that at all.
I have yet to see why this imposes a freeze on unstable, on the other hand.

Other desktop support?

Posted Jan 16, 2013 18:56 UTC (Wed) by vonbrand (guest, #4458) [Link]

Because if they only froze testing, all its users would migrate to unstable...

Other desktop support?

Posted Jan 17, 2013 7:57 UTC (Thu) by DavidS (guest, #84675) [Link]

> I have yet to see why this imposes a freeze on unstable, on the other hand.

Because "unstable" is the place where stuff goes that should be released with the next stable. See Developer Reference 4.6.4.1:

> This development cycle is based on the assumption that the unstable
> distribution becomes stable after passing a period of being in testing.

-- http://www.debian.org/doc/manuals/developers-reference/re...

Other desktop support?

Posted Jan 17, 2013 8:05 UTC (Thu) by micka (subscriber, #38720) [Link]

I was under the illusion that you could change the developement branch of a project without impacting the other one.

Debian freezes

Posted Jan 18, 2013 6:30 UTC (Fri) by DavidS (guest, #84675) [Link]

Tl;dr:unstable is not a development branch, it is a integration branch. Experimental might be considered a development one.

Uploading to unstable publishes packages as "destined for stable". In the case of libraries, that also means that users of this library will start linking against the new binary. This again implies that the two packages now must go to testing together. This quickly leads to situations where significant parts of unstable cannot progress to testing due to issues in central packages (think gtk).
Building new packages against libraries from testing would reduce the formal requirements for testing propagation, but would lead to untested combinations in testing (as unstable users had a different version installed).

Debian freezes

Posted Jan 18, 2013 8:06 UTC (Fri) by micka (subscriber, #38720) [Link]

Experimental is not a branch, it's not self contained (you cannot use only experimental, you need to have unstable as well).

> Building new packages against libraries from testing would reduce the formal requirements for testing propagation, but would lead to untested combinations in testing

But I'd prefer that. I still think that those who care about testing should be the ones testing it.

Other desktop support?

Posted Jan 16, 2013 13:47 UTC (Wed) by pboddie (guest, #50784) [Link]

Can one even install testing in a convenient way? I'm pretty sure I couldn't do it using debootstrap, for example.

It all sounds like yet another cunning plan to second-guess the herd of users and make them do something they don't really want to, instead of making it easy for those who are interested to do something, and encouraging (rather than coercing) others to join them.

As for KDE being the most desirable desktop environment, that's quite a depressing statement on the topic, but not entirely unsurprising given my recent experiences from renewed exposure to KDE 4 (sorry, KDE Plasma), Trinity, GNOME and Unity.

Other desktop support?

Posted Jan 16, 2013 14:49 UTC (Wed) by cortana (subscriber, #24596) [Link]

"debootstrap testing /target http://http.debian.net/debian/" didn't work?

Testing testing

Posted Jan 16, 2013 15:15 UTC (Wed) by pboddie (guest, #50784) [Link]

It was a while ago when I last tried, and I did wonder whether I was mixing up experimental and testing in my mind as I try and recall the details now, but I can try again and see if there's any success.

People being able to try out testing would be one fewer reason to freeze unstable, I think.

Testing testing

Posted Jan 16, 2013 15:58 UTC (Wed) by cortana (subscriber, #24596) [Link]

It's possible that there was a bug in one of the packages that comprised testing at the particular time you installed it, and that may have prevented debootstrap from finishing. Such bugs are pretty rare though--they usually get noticed during the 10 day waiting period between packages entering unstable and transitioning to testing.

Other desktop support?

Posted Jan 16, 2013 21:06 UTC (Wed) by pkern (subscriber, #32883) [Link]

The problem is that direct updates to testing are currently not being tested at all. They are introduced into testing-proposed-updates and nobody has this enabled.

Hence we require updates to flow through unstable. We are not reviewing all what's uploaded to unstable, although many of the uploads there are now voluntarily reviewed to see if they fit the release criteria for migration to testing at this point. Any upload to unstable still ages there, too, just like in non-freeze times. This means that the worst bugs that are introduced by bug fixes are likely to be found by unstable's user base before they hit testing. In turn this makes testing more stable and solid to be used at this point before it's finally released. It also allows some more intrusive RC bug fixes to be accepted under the premise that we'll soon find out if they're flawed.

Other desktop support?

Posted Jan 16, 2013 15:18 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

I'm not very familiar with KDE.
Does it stop working once it's a couple of months old? :)

Other desktop support?

Posted Jan 25, 2013 15:07 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link]

No, why, you saying that happens on GNOME?

LXDE

Posted Jan 16, 2013 22:01 UTC (Wed) by proski (subscriber, #104) [Link]

I can say that LXDE is not treated very well. Fedora 17 shipped with broken alacarte, which is the menu editor for GNOME and LXDE. It has not been fixed in Fedora 17, even though the fix is known. Thankfully, Fedora 18 comes with working alacarte, but the maintainers refused to backport the fix.

Also, switching keyboard layouts (like English to Russian) broke in Fedora 18. For whatever reason, it still works on a system that was installed as Fedora 17, but not on systems that were upgraded from Fedora 16 to Fedora 17 and then to Fedora 18.

There is a way to configure keyboard layout switching in GNOME, but it has no effect in LXDE. What's worse, the is no way to use Alt-Shift, the GNOME configuration requires a non-modifier key (like Space) with modifiers. ibus works in LXDE but has the same limitation. That's a very annoying regression for me. I still need to figure out why one of my systems keeps working properly.

Finally, the systems that used lxdm started using gdm after the upgrade. It turns out the configuration files don't work anymore. systemd is now responsible for the display manager. To enable lxdm, I had to run

systemctl enable --force lxdm.service

That wasn't easy to figure out. Unfortunately, systemd makes a lot of knowledge obsolete.

The Grumpy Editor's Fedora 18 experience

Posted Jan 16, 2013 15:52 UTC (Wed) by duffy (guest, #31787) [Link]

"(That said, it should be pointed out that using FedUp precluded testing the Anaconda installer, which is where a lot of the problems were.) "

Is this really fair to point out when you didn't run through it yourself and experience problems first-hand?

TBH I'm pretty surprised at how few really horrible bugs have been encountered with the new Anaconda - although polishing that was a big reason why the release was so late, so I guess it makes sense it's not full of huge showstopper bugs now. Extra time was spent on it to make sure that wouldn't happen.

Anaconda

Posted Jan 16, 2013 15:56 UTC (Wed) by corbet (editor, #1) [Link]

Yes, I think it was fair (and necessary) to point out that my review passed over an area that, in your own words, was "a big reason why the release was so late." It would have been better to do a full install, of course, but I lacked the time and an available machine; failing that, I felt the need to point out that I had been unable to look at an important piece of the release.

Anaconda

Posted Jan 16, 2013 16:10 UTC (Wed) by duffy (guest, #31787) [Link]

Sure, it's fair to point out you didn't look at it. I guess I must have misread what you wrote, when I read "which is where a lot of the problems were." I did not read: "That is the area that cause much of the Fedora 18 delay" I read: "That's where most of Fedora 18's problems were, not that I saw that first hand."

Anaconda

Posted Jan 16, 2013 17:30 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Yeah. I think the wording on that particular statement was ambiguous.

The Grumpy Editor's Fedora 18 experience

Posted Jan 19, 2013 15:51 UTC (Sat) by drago01 (subscriber, #50715) [Link]

> TBH I'm pretty surprised at how few really horrible bugs have been encountered with the new Anaconda

Bugs aren't the problem (most of them got fixed in time). But the partitioning UI needs a lot of work. The way it works does not make much sense ...

The rest of the UI needs some polish as well but the partitioning screen really stands out as being really bad.

The Grumpy Editor's Fedora 18 experience

Posted Jan 17, 2013 8:05 UTC (Thu) by bni (guest, #27103) [Link]

I am using the default Gnome 3.6 DE on Fedora 18.

A problem I have is that all applications wants to start positioned in the top left corner for some reason. Anyone know I I can change this to "centered" or "smart" placement?

Applications sometimes also wants to start maximized covering the whole desktop. I have to right click and choose "Unmaxmize" from the menu every time this happens.

Some applications is not possible to "Unmaximize" at all. Like the Package install GUI. It does not make sense at all.

All these issues would be minor if only the window placement was remembered between application restarts.

Other than that, its great.

The Grumpy Editor's Fedora 18 experience

Posted Jan 18, 2013 2:45 UTC (Fri) by wagerrard (guest, #87558) [Link]

Gnome apps will usually open full screen. Other apps will maximize if you drag them up so they touch the panel.

Maximized apps can be de-maximized by grabbing their title bar with the mouse and dragging down.

Installing the Gnome Tweak Tools gives you access to the option to add minimize and maximize buttons to windows.

If you Google, you can find instructions to turn off the "go full screen when you touch the panel" behavior. That also turns off Gnome Shell's ability to snap a window to one-half of the screen when you drag it to the right or left edge.

Gnome design standards want us to open new apps in new work spaces, not minimize apps to clear out room. Middle click on an icon in the Dash and it opens in a new work space that's created automatically, and deleted automatically when you close that app.

The Grumpy Editor's Fedora 18 experience

Posted Jan 27, 2013 20:22 UTC (Sun) by Tet (subscriber, #5433) [Link]

After the reboot one gets a black screen, a pulsating Fedora logo, and a progress bar that cannot be more than 200 pixels wide. That bar progresses slowly indeed. It is only later that one realizes that this is FedUp's way of telling the user that the system is being updated. One would at least expect a list of packages, a dancing spherical cow, or, at a minimum, a message saying "your system is being upgraded now," but no such luck. To all appearances, it simply looks like the system is taking a very long time to boot.

That is sadly all too common an experience with Fedora. Much as I don't want to malign the Fedora UI team, I feel they'd probably have done better by letting a room full of drug addled monkeys design the UI instead. As it is, they've made just about every UI mistake possible, particularly during the boot process.


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds