Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Improving the Fedora boot experience (linuxgrrl.com)
34 points by DanBC on April 20, 2013 | hide | past | favorite | 10 comments


What I would want is some way to start X before even the tty. For example; on Ubuntu when you boot up you can actually see the tty and a little bit of the init scripts' output. This feels quite "cheap" in my honest opinion. I would much rather see a proper Ubuntu logo and then a smooth transition to the X login screen.


X really can't start that early. It depends on too many other pieces being started first.

But in Fedora we do have early access to the framebuffer. Plymouth uses that to display the animated Fedora logo and to prompt for any encryption passphrases.

The hardware needs to support it though, so you may not see this, especially when running in a virtual environment.

When it works right it looks pretty nice, you get a mostly seamless graphic screen after grub2 until gdm. And you can always hit ESC to see the scrolling systemd startup messages.


What you are seeing/referencing is the output of commands during earlier runlevels; the X server won't start until runlevel 5 (number selected off the top of my head). That said, it'd be good to give users of mainstream Linux distributions like Ubuntu the option to suppress output from the boot scripts.

Year of Linux on the desktop, here we come!


> That said, it'd be good to give users of mainstream Linux distributions like Ubuntu the option to suppress output from the boot scripts.

Haven't major distros been doing this for years? I only see the output if I press escape, and pressing escape again suppresses it. Otherwise I just see a progress bar/animation.


> the X server won't start until runlevel 5

I don't think that the runlevel numbers are sequential. You can switch between levels (and that corresponds to more or less services running) but you pretty much boot directly to runlevel 5.

Within a runlevel, services are ordered, though (either by an arbitrary integer or by dependency).


It's funny how they discuss cosmetics when there are hordes of driver bugs all over the place.

I seems that RH copies Canonical's idea to make something looking "good" and sell it to fans of eye candy who happen to own machines unaffected by bugs.


UI and kernel development is likely done by different people with different skill sets. I don't see a reason why they shouldn't work in parallel.


Please, stop talking about eye candy if you don't have a deep understanding of UI design.

The most important aspects of UI are about presenting information in a way that is comprehensible. Flashing error messages on screen for less than a second is confusing--either the information is important and needs to be visible for longer, or it should be relegated to a log file somewhere.

Upthread, someone said that showing all the output of the init scripts in a tty feels cheap. I agree that it feels cheap--and it feels cheap because it suggest something about the computer. Older OSes spent a lot of time displaying initialization script outputs to the screen because that you had to know about it. At any time, that shit might be broken, and you (or your sysadmin) would have to reconfigure it. That's the wrong message to send to your average Ubuntu user.

So if you thought that complaint or many of the complaints from the initial article were about "eye candy" you were wrong.


I still believe that resources would be better spent on fixing stuff rather than "sending a message" that it isn't broken.

And BTW, I'm a big fan of printing output of init scripts to console, provided that it's nice and concise (as it used to be in most distros few years ago) because it greatly aids debugging when (not if) stuff breaks. It's one of the reasons I left Windows, actually.


I enabled it on my old Mac--because I am a huge freaking nerd. I never once needed it, but it made me happy. However, I think it's definitely a bad default. Make it easy to enable, and the people who need it will enable it. But we should design and build for the normal case first.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: