Given that users will experiences some what faster boot with systemd are there any plans to try to speed up the actual user login time as in from GDM to end user desktop?
What's the best method to measure what's taking most of that time?
JBG
On Thu, 2010-08-19 at 20:20 +0000, "Jóhann B. Guðmundsson" wrote:
Given that users will experiences some what faster boot with systemd are there any plans to try to speed up the actual user login time as in from GDM to end user desktop?
What's the best method to measure what's taking most of that time?
The work being done on removing external libraries, and things like dconf should already provide quite a bit of speed-up (in F15), but I don't think anyone has done any work on particular parts of the desktop with that intent in a couple of years.
On Thu, 19.08.10 20:20, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
Given that users will experiences some what faster boot with systemd are there any plans to try to speed up the actual user login time as in from GDM to end user desktop?
Well, with some newer systemd features (that we'll probably enable for fedora in f15 [1]) we are currently measuring bootups of < 7s (and a pid < 500) from grub to panel showing up on the screen. (that's kay's X300 with ssd on a modified opensuse), 5s or so are actually spent in gnome of those. there's definitely room to improve things in gnome. some things we are starting are kinda obvious candidates to make faster. Not going to name names here, but some things show up kinda badly in bootchart, and we are talking to the folks maintaining that to figure out what can be improved here.
In the long run I want to make gnome use systemd for session management, so that the same parallelization techniques we use for system boot can be used for session startup as well. We aren't there yet though and we need to figure a few things out before we go there. That's material for f15/f16.
What's the best method to measure what's taking most of that time?
bootchart.
Lennart
Footnotes:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important. The mount/fsck stuff in C is not entirely complete yet, but we are working to get the necessary work done in util-linux-ng. Note that all of this will show up in f15 only.
On 08/19/2010 10:05 PM, Lennart Poettering wrote:
In the long run I want to make gnome use systemd for session management, so that the same parallelization techniques we use for system boot can be used for session startup as well.
Are other *DE ( KDE XFCE LXDE Sugar etc ) being kept in the loop so they can take advantage of the parallelization techniques ?
What are the plans regarding plymouth since the boot will be so fast? ( Feels kinda pointless having any kind of animation during startup )
JBG
On Thu, 2010-08-19 at 22:32 +0000, "Jóhann B. Guðmundsson" wrote:
On 08/19/2010 10:05 PM, Lennart Poettering wrote:
In the long run I want to make gnome use systemd for session management, so that the same parallelization techniques we use for system boot can be used for session startup as well.
Are other *DE ( KDE XFCE LXDE Sugar etc ) being kept in the loop so they can take advantage of the parallelization techniques ?
What are the plans regarding plymouth since the boot will be so fast? ( Feels kinda pointless having any kind of animation during startup )
Hey, that it takes to boot 2s on ssd disks does not mean there aren't people using a bit older hardware that won't boot under tens of seconds even with systemd...
Martin
On Thu, 19.08.10 22:32, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 08/19/2010 10:05 PM, Lennart Poettering wrote:
In the long run I want to make gnome use systemd for session management, so that the same parallelization techniques we use for system boot can be used for session startup as well.
Are other *DE ( KDE XFCE LXDE Sugar etc ) being kept in the loop so they can take advantage of the parallelization techniques ?
Well, I consider myself a GNOME developer, and that's my focus.
systemd is very generic low-level code, so there shouldn't be a technical barrier for other DEs adopting it too, and I'd welcome this very much. However, there are certain political issues that will make adoption by other DEs difficult: for one, systemd is Linux specific. While in the GNOME world the idea that Linux is the only OS that matters is kinda popular these days I assume that other DEs care much more about niche OSes (hey, and KDE even cares about Windows!).
Also, regardless of the DE there is still that distro with the 3 Us in its name which is unlikely to adopt systemd. Tying systemd into GNOME and the other DEs would probably cement what they are already doing: forking GNOME and maintaining things independently of upstream.
So, in summary, this is something to push forward very carefully, and as of now neither the technical nor the political preconditions have been figured out how to do this best.
What are the plans regarding plymouth since the boot will be so fast? ( Feels kinda pointless having any kind of animation during startup )
Well, if people plug more stuff into their boot, run all kinds of inet servers, and other stuff, or have slower hw/rotating media, or have a crypto fs plymouth will very much be needed.
Lennart
On Fri, 20.08.10 03:52, Lennart Poettering (mzerqung@0pointer.de) wrote:
systemd is very generic low-level code, so there shouldn't be a technical barrier for other DEs adopting it too, and I'd welcome this very much. However, there are certain political issues that will make adoption by other DEs difficult: for one, systemd is Linux specific. While in the GNOME world the idea that Linux is the only OS that matters is kinda popular these days I assume that other DEs care much more about niche OSes (hey, and KDE even cares about Windows!).
Also, regardless of the DE there is still that distro with the 3 Us in its name which is unlikely to adopt systemd. Tying systemd into GNOME and the other DEs would probably cement what they are already doing: forking GNOME and maintaining things independently of upstream.
So, in summary, this is something to push forward very carefully, and as of now neither the technical nor the political preconditions have been figured out how to do this best.
Let me clarify this: if we adopt systemd for the session we need to do that in a way that is acceptable for the other OSes/distros which cannot or don't want to adopt systemd. We don't want to drive them away from contributing to GNOME upstream. It's a tightrope walk between innovating here and not breaking too much glass in the cooperation between th major players in GNOME land.
I do have a few ideas how to do this best, but this needs more thinking. i.e. in the long run we probably want to merge a lot of the CK functionality into systemd, and move some stuff currently done in gnome-session into it. We should do this in a way that Solaris and Ubuntu can still continue to use the current CK implementation and the current code in g-s, and both can still be considered GNOME.
But anyway, I don't like to talk too much about great plans for the distant future, and focus more on what we can do right now.
Lennart
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
On Fri, Aug 20, 2010 at 6:24 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
We should stop doing that, LVM is mostly useless on desktop and pretty much always useless on laptops.
On 08/21/2010 09:30 AM, drago01 wrote:
On Fri, Aug 20, 2010 at 6:24 PM, Adam Williamsonawilliam@redhat.com wrote:
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
We should stop doing that, LVM is mostly useless on desktop and pretty much always useless on laptops.
I so agree, also the possibility of customizing the partitioning scheme in text-mode (eg with systems with <= 512 MB RAM) sounds to me like a great idea. I run systems at work with Fedora 13 on 256 MB RAM with LXDE and it works great. But I don't need LVM on those systems. My 0.02.
On Fri, 20.08.10 09:24, Adam Williamson (awilliam@redhat.com) wrote:
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
Well, I believe Fedora should not do this by default. This just adds complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 8/21/10 11:10 AM, Lennart Poettering wrote:
On Fri, 20.08.10 09:24, Adam Williamson (awilliam@redhat.com) wrote:
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
Well, I believe Fedora should not do this by default. This just adds complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
Lennart
I've got no issues with not doing LVM by default here...
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On 08/21/2010 09:02 PM, Jesse Keating wrote:
Well, I believe Fedora should not do this by default. This just adds
complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
I've got no issues with not doing LVM by default here...
Is this then just a matter of go ahead and make the change?
JBG
On Sat, Aug 21, 2010 at 10:02 PM, Jesse Keating jkeating@j2solutions.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 8/21/10 11:10 AM, Lennart Poettering wrote:
On Fri, 20.08.10 09:24, Adam Williamson (awilliam@redhat.com) wrote:
On Fri, 2010-08-20 at 00:05 +0200, Lennart Poettering wrote:
[1] We wrote C replacements for all remaining shell scripts in the boot and in shutdown, with the exception of LVM, DM, iSCSI and NFS stuff, which are shell orgies. But then again, neither of these features really matter for laptops where fast booting is most important
Fedora uses LVMs by default, so anyone who installs Fedora on a laptop and doesn't customize the partition scheme will have them.
Well, I believe Fedora should not do this by default. This just adds complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
Lennart
I've got no issues with not doing LVM by default here...
I think its needed for LUKS (unfortunately) but I would like to see it non used for the other use cases.
Peter
On Mon, 2010-08-23 at 06:28 +0000, "Jóhann B. Guðmundsson" wrote:
On 08/21/2010 09:02 PM, Jesse Keating wrote:
Well, I believe Fedora should not do this by default. This just adds
complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
I've got no issues with not doing LVM by default here...
Is this then just a matter of go ahead and make the change?
JBG
Here is an older effort to do the same:
On 08/23/2010 02:11 PM, Matthias Clasen wrote:
Here is an older effort to do the same:
Perhaps Will would be willing to shed some light on what prevented his feature to be moved forward?
Cant the live cd be using either ext4 or btrfs while the DVD would still default to lvm?
JBG
On Mon, 2010-08-23 at 08:11 +0100, pbrobinson@gmail.com wrote:
I've got no issues with not doing LVM by default here...
I think its needed for LUKS (unfortunately) but I would like to see it non used for the other use cases.
LUKS works just fine without LVM (LUKS itself uses device-mapper too but that's not the same).
David
On Mon, 23.08.10 06:28, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 08/21/2010 09:02 PM, Jesse Keating wrote:
Well, I believe Fedora should not do this by default. This just adds
complexity, makes boot slower, and offers exactly zero advantages for laptop/desktop users. Also, sooner or later LVM will be obsoleted anyway by btrfs which integrates most of the LVM features into the fs itself. And in contrast to LVM the btrfs userspace is kinda nice.
I've got no issues with not doing LVM by default here...
Is this then just a matter of go ahead and make the change?
I think many people would welcome if this step was done, but this is probably something to discuss with the anaconda people directly? I am pretty sure tehy won't read our little desktop ML. :-(
Lennart
On 08/23/2010 03:13 PM, Lennart Poettering wrote:
I think many people would welcome if this step was done, but this is probably something to discuss with the anaconda people directly? I am pretty sure tehy won't read our little desktop ML.:-(
Well this is something that the desktop SIG needs to reach conscious about + Will was just informing me about the slight problem of the livecd being an lvm snapshot :| so there are some technical hurdle involved making the actual change.
JBG
On Mon, 23.08.10 15:23, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 08/23/2010 03:13 PM, Lennart Poettering wrote:
I think many people would welcome if this step was done, but this is probably something to discuss with the anaconda people directly? I am pretty sure tehy won't read our little desktop ML.:-(
Well this is something that the desktop SIG needs to reach conscious about + Will was just informing me about the slight problem of the livecd being an lvm snapshot :| so there are some technical hurdle involved making the actual change.
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
Lennart
On 08/23/10 12:20, Lennart Poettering wrote:
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
I agree that on laptops LVM is not all that useful. But on desktops it is as it allows easy resizing and reallocation.
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
behdad
Lennart
On Mon, 2010-08-23 at 12:24 -0400, Behdad Esfahbod wrote:
On 08/23/10 12:20, Lennart Poettering wrote:
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
I agree that on laptops LVM is not all that useful. But on desktops it is as it allows easy resizing and reallocation.
Well, I've done precisely this on my laptop... But since I already have it created, I don't care about the defaults myself, and for people who leave the default partitioning untouched, having LVM is probably not needed...
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
+1. But IIRC, last time this was discussed it got stuck up on deciding how much space to use for / and how much for /home...
Martin
Behdad Esfahbod (behdad@behdad.org) said:
On 08/23/10 12:20, Lennart Poettering wrote:
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
I agree that on laptops LVM is not all that useful. But on desktops it is as it allows easy resizing and reallocation.
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
def setDefaultPartitioning(self, storage, platform): autorequests = [PartSpec(mountpoint="/", fstype=storage.defaultFSType, size=1024, maxSize=50*1024, grow=True, asVol=True), PartSpec(mountpoint="/home",fstype=storage.defaultFSType, size=100, grow=True, asVol=True, requiredSpace=50*1024)]
This was changed in F-13.
Bill
On Mon, Aug 23, 2010 at 12:24 PM, Behdad Esfahbod behdad@behdad.org wrote:
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
Sadly, it does now...
However, one doesn't need to take this drastic step, it'd have been far simpler for the installer to just rm -rf all directories except /home.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 8/23/10 10:53 AM, Colin Walters wrote:
On Mon, Aug 23, 2010 at 12:24 PM, Behdad Esfahbod behdad@behdad.org wrote:
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
Sadly, it does now...
However, one doesn't need to take this drastic step, it'd have been far simpler for the installer to just rm -rf all directories except /home.
And it would be far far far slower...
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Mon, Aug 23, 2010 at 12:24:23PM -0400, Behdad Esfahbod wrote:
On 08/23/10 12:20, Lennart Poettering wrote:
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
I agree that on laptops LVM is not all that useful. But on desktops it is as it allows easy resizing and reallocation.
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
This actually happens now on larger disks (bigger than 50 GB, IIRC), as of Fedora 13.
On 08/23/10 14:17, Paul W. Frields wrote:
On Mon, Aug 23, 2010 at 12:24:23PM -0400, Behdad Esfahbod wrote:
On 08/23/10 12:20, Lennart Poettering wrote:
Urks, LVM snapshots!
That said, I am pretty sure you have the consensus of the desktop group now, as nobody defended LVM.
I agree that on laptops LVM is not all that useful. But on desktops it is as it allows easy resizing and reallocation.
What I personally want to see our default auto-partitioning do is to create a separate '/' from /home, such that reinstallations don't wipe out /home.
This actually happens now on larger disks (bigger than 50 GB, IIRC), as of Fedora 13.
Ah, good to know. Thanks.
behdad
desktop@lists.fedoraproject.org