Announcement

Collapse
No announcement yet.

Ubuntu Unity Becoming An Official Flavor With 22.10 Release

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • jo-erlend
    replied
    Originally posted by cl333r View Post

    If Unity doesn't run natively on Wayland then that's a huge problem indeed imho.
    Unity is designed as plugin for Compiz, which itself is specifically designed to overcome limitations of X11, so you would probably have to replace Compiz. I would be nice to have Compiz as a native Wayland compositor, but I'm guessing that's not as easy as it sounds.

    Leave a comment:


  • ferry
    replied
    Originally posted by Classical View Post

    If those are your times on an SSD then you are not faster than Windows 10. Windows 10 does hibernation and therefore it starts up fairly quickly.

    If you want faster boot and login times and the most responsive desktop then Void Linux with XFCE is your best option.

    It's worth switching in your case, Void Linux is fairly easy to install and use, if you try it. You have to make sure that you are doing the partitioning correctly with Void. The rest is relatively simple.​
    You can't conclude this. First Win10 will not run on this system, it is a brainwashed Chromebook. 2nd, my point is even if Kubuntu is slow to boot, I don't care. I just don't boot/login any more, just wake from suspend.

    Leave a comment:


  • Classical
    replied
    Originally posted by ferry View Post

    I just clocked it from power-on Including bios) to login 45 sec. from login to desktop ready 25 sec.
    If those are your times on an SSD then you are not faster than Windows 10. Windows 10 does hibernation and therefore it starts up fairly quickly.

    If you want faster boot and login times and the most responsive desktop then Void Linux with XFCE is your best option.

    It's worth switching in your case, Void Linux is fairly easy to install and use, if you try it. You have to make sure that you are doing the partitioning correctly with Void. The rest is relatively simple.​

    Leave a comment:


  • ferry
    replied
    Originally posted by Vorpal View Post

    Huh, I use KDE, and it only takes a couple of seconds for me, so overall it is a very small piece of the startup time (compared to uefi time). I guess having newer and beefier hardware helps a lot.
    ​​​​
    I just clocked it from power-on Including bios) to login 45 sec. from login to desktop ready 25 sec.

    Leave a comment:


  • Vorpal
    replied
    Originally posted by ferry View Post

    You are missing the point, loading from ssd is a small effect. Starting the kernel is fast enough. Loading user space (up to login prompt) takes much longer, but even that is ok. From login prompt to actually being able to use the machine is long (due to KDE loading stuff). Still way more fast then Win10 of course.
    Huh, I use KDE, and it only takes a couple of seconds for me, so overall it is a very small piece of the startup time (compared to uefi time). I guess having newer and beefier hardware helps a lot.
    ​​​​

    Leave a comment:


  • ferry
    replied
    Originally posted by Vorpal View Post

    Presumably that is not UEFI, as it excludes the firmware and bootloader time. This means the totals at the end are not directly comparable. You would have to measure with a stopwatch to get the correct total.

    Initrd is also missing, meaning your initramfs does not use systemd, that will thus be combined into the kernel time.
    You are missing the point, loading from ssd is a small effect. Starting the kernel is fast enough. Loading user space (up to login prompt) takes much longer, but even that is ok. From login prompt to actually being able to use the machine is long (due to KDE loading stuff). Still way more fast then Win10 of course.

    Leave a comment:


  • Vorpal
    replied
    Originally posted by ferry View Post

    I have on a brainwashed Acer 720P (Haswell chromebook):
    Code:
    ferry@chromium$ systemd-analyze
    Startup finished in 4.625s (kernel) + 12.214s (userspace) = 16.840s
    graphical.target reached after 12.171s in userspace[/FONT]
    ​
    This is not too bad at all.
    However, the long wait if from login to KDE desktop which is not timed by systemd.
    Presumably that is not UEFI, as it excludes the firmware and bootloader time. This means the totals at the end are not directly comparable. You would have to measure with a stopwatch to get the correct total.

    Initrd is also missing, meaning your initramfs does not use systemd, that will thus be combined into the kernel time.

    Leave a comment:


  • ferry
    replied
    Originally posted by Vorpal View Post

    Unfortunately it seems the only real solution to this is to change to a distro that doesn't use snaps. Arch Linux in my case, but other options are available depending on preferences.

    My boot time is quite low (well, at least the part that is under control of the OS). This is on a Skylake era Thinkpad T480.

    Code:
    ~ ❯ systemd-analyze
    Startup finished in 8.713s (firmware) + 6.870s (loader) + 1.273s (kernel) + 6.411s (initrd) + 4.150s (userspace) = 27.419s​
    The main slowdowns here are:
    • Bootloader is high this time because I wasn't paying attention to press enter quickly, and the timeout is set to 10 seconds. I have seen it down in the 1-2 second range if I react quickly.
    • Initrd is high because it is waiting for a password prompt (dm-crypt) and unlocking takes time for security reasons (key derivation to mitigate brute force attacks).
    • In userspace, firewalld needs to be up before network-manager can start. It is slow unfortunately.
    • Also in userspace, optimus-manager (which can handle switchable nvidia graphics on Arch Linux) is unfortunately also slow to start.
    Moving from Ubuntu to Arch made boots so much faster. Also pacman (the package manger) is noticeably faster at resolving, installing etc than apt/dpkg.

    As for KDE, it takes around 2-3 seconds for the splash screen to go away (this is estimated, I have not timed it). Never used kubuntu, so I don't know how that compares.
    I have on a brainwashed Acer 720P (Haswell chromebook):
    Code:
    ferry@chromium$ systemd-analyze
    Startup finished in 4.625s (kernel) + 12.214s (userspace) = 16.840s  
    graphical.target reached after 12.171s in userspace[/FONT]
    ​
    This is not too bad at all.
    However, the long wait if from login to KDE desktop which is not timed by systemd.

    Leave a comment:


  • Vorpal
    replied
    Originally posted by ferry View Post

    I have Kubuntu which is likely even worse in boot and login times. I resolved that by not rebooting so often.

    The firefox snap was indeed terribly slow, fixed that be removing the snap and installing from the ppa.
    Unfortunately it seems the only real solution to this is to change to a distro that doesn't use snaps. Arch Linux in my case, but other options are available depending on preferences.

    My boot time is quite low (well, at least the part that is under control of the OS). This is on a Skylake era Thinkpad T480.

    Code:
    ~ ❯ systemd-analyze
    Startup finished in 8.713s (firmware) + 6.870s (loader) + 1.273s (kernel) + 6.411s (initrd) + 4.150s (userspace) = 27.419s​
    The main slowdowns here are:
    • Bootloader is high this time because I wasn't paying attention to press enter quickly, and the timeout is set to 10 seconds. I have seen it down in the 1-2 second range if I react quickly.
    • Initrd is high because it is waiting for a password prompt (dm-crypt) and unlocking takes time for security reasons (key derivation to mitigate brute force attacks).
    • In userspace, firewalld needs to be up before network-manager can start. It is slow unfortunately.
    • Also in userspace, optimus-manager (which can handle switchable nvidia graphics on Arch Linux) is unfortunately also slow to start.
    Moving from Ubuntu to Arch made boots so much faster. Also pacman (the package manger) is noticeably faster at resolving, installing etc than apt/dpkg.

    As for KDE, it takes around 2-3 seconds for the splash screen to go away (this is estimated, I have not timed it). Never used kubuntu, so I don't know how that compares.

    Leave a comment:


  • bregma
    replied
    Originally posted by Takla View Post
    It's a shame that Ubuntu/Canonical gave up on it just as it was getting very nice to use. Did it depend too much on their own upstart init/service manager system? I forget.
    No. The program was cancelled in early 2017 because it was not a revenue generator and Canonical was cleaning house in preparation for an IPO. As shipped in Ubuntu 16.04 it was integrated with systemd but that was not a requirement, just a practicality.

    Leave a comment:

Working...
X