I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
Thanks
JBG
On Mon, Jun 06, 2011 at 11:08:10 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
For some of these, the issue is more about detecting the attached hardware and only enabling the services on install that are actually usable. When running as a live image, those services should be enabled so that they can use the hardware if it is present.
On 06/06/2011 11:27 AM, Bruno Wolff III wrote:
On Mon, Jun 06, 2011 at 11:08:10 +0000, ""Jóhann B. Guðmundsson""johannbg@gmail.com wrote:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
For some of these, the issue is more about detecting the attached hardware and only enabling the services on install that are actually usable.
That would be the best scenario..
When running as a live image, those services should be enabled so that they can use the hardware if it is present.
Not really from my pov.
I'm not seeing anyone in enterprise environment with enterprise hardware using a livecd/usb and if they are they would not be using fcoe lldpad, iscsi, iscsid, mdmonitor etc for ( a one time ) live bootup and even if they did they would possess the knowledge of enable it in that case .
I'm not aware of anyone that uses a livecd/usb on a hardware with fcoe lldpad, iscsi, iscsid, mdmonitor ( server hw ).
I guess it all falls down to who are we targeting with the livecd/usb.
JBG
On Mon, Jun 06, 2011 at 11:55:21 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
Not really from my pov.
I'm not seeing anyone in enterprise environment with enterprise hardware using a livecd/usb and if they are they would not be using fcoe lldpad, iscsi, iscsid, mdmonitor etc for ( a one time ) live bootup and even if they did they would possess the knowledge of enable it in that case .
I'm not aware of anyone that uses a livecd/usb on a hardware with fcoe lldpad, iscsi, iscsid, mdmonitor ( server hw ).
I guess it all falls down to who are we targeting with the livecd/usb.
I think it is a bad idea for live images to not just work. I wouldn't expect there to be a lot of use on enterprise hardware, but for doing recovery people might want to do this.
The real problem with the services listed was that a few use a significant amount of resources, even when the hardware to be supported isn't present. I think the effort would be better spent addressing that, rather than not supporting that hardware on live images.
Properly handling whether the services should be on or off during install will take significant work, but maybe less than fixing the real problem. The installs are done differently than normal installs, so we can't directly use the method used for normal installs for live installs. But presumably we could borrow ideas from that code.
On Mon, Jun 6, 2011 at 2:27 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 06, 2011 at 11:08:10 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
For some of these, the issue is more about detecting the attached hardware and only enabling the services on install that are actually usable. When running as a live image, those services should be enabled so that they can use the hardware if it is present. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Live media does not make sense for servers at all. When you install a server, you want to control exactly what is going to be installed, which is impossible with live media. Furthermore, the default live media is the Desktop spin, which means - it is for desktop! not servers! You can suggest a server spin if you want.
Most desktop users are not enterprise users, and enterprise users are skilled enough to enable the services they need themselves or create their own live media with the packages and configurations they need for their environment.
I don't see any reason for starting these services. AFAIK the system will boot properly without them on any hardware, so users who has such hardware can simply run su -c 'systemctl start something.service', and that's it. What I mean is, that those services can be *installed* by default on the live cd, but I see no reason for them to be *enabled* by default on the live media or on an installation from the livecd.
-- -Elad.
On 06/06/2011 12:50 PM, Elad wrote:
What I mean is, that those services can be*installed* by default on the live cd, but I see no reason for them to be*enabled* by default on the live media or on an installation from the livecd.
I would think the ideal place we want to be in is..
If hw is present start service if not dont.
Like for example there is no point in starting bluetooth, pcscd, fcoe, lldpad, iscsi, iscsid, mdmonitor cups etc. if the relevant hw is not detected and present on the installed or running system.
ntp and ntpdate should just be enabled and started if the end user has configured it to do so in Firstboot ( arguable this should be removed from firstboot and be handled only in relevant application in the DE ) or System settings --> Date and Time in Gnome or via system-config-date.
All the NFS related services along with avahi should default to off as well and only be activated and enabled if the end user has configured it to do so either manually or via cli or in some app.
Fixing this along with defaulting to btrfs and or ext4 and turning of related service surrounding lvm should reduce the boot time to ca <10s range on a rotating media thus delivering better experience to the novice end user.
Anaconda or Firstboot should also turn off the live system related services after being run.
JBG
2011/6/6 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 06/06/2011 12:50 PM, Elad wrote:
What I mean is, that those services can be *installed* by default on the live cd, but I see no reason for them to be *enabled* by default on the live media or on an installation from the livecd.
I would think the ideal place we want to be in is..
If hw is present start service if not dont.
Like for example there is no point in starting bluetooth, pcscd, fcoe, lldpad, iscsi, iscsid, mdmonitor cups etc. if the relevant hw is not detected and present on the installed or running system.
Cups is needed for network printers, which you can't detect on boot. Starting cups on demand whenever an app wants to access a printer (eg when you open the print dialog in libreoffice) might be a good idea.
ntp and ntpdate should just be enabled and started if the end user has configured it to do so in Firstboot ( arguable this should be removed from firstboot and be handled only in relevant application in the DE ) or System settings --> Date and Time in Gnome or via system-config-date.
All the NFS related services along with avahi should default to off as well and only be activated and enabled if the end user has configured it to do so either manually or via cli or in some app.
Fixing this along with defaulting to btrfs and or ext4 and turning of related service surrounding lvm should reduce the boot time to ca <10s range on a rotating media thus delivering better experience to the novice end user.
Anaconda or Firstboot should also turn off the live system related services after being run.
JBG
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Mon, Jun 06, 2011 at 15:50:11 +0300, Elad elad@fedoraproject.org wrote:
Live media does not make sense for servers at all. When you install a
Sure it does. Live images make nice rescue images.
Most desktop users are not enterprise users, and enterprise users are skilled enough to enable the services they need themselves or create their own live media with the packages and configurations they need for their environment.
Not having live images just work is a very poor experience.
Disabling services that support hardware by default is not the appropriate way forward.
Bruno Wolff III wrote:
Disabling services that support hardware by default is not the appropriate way forward.
I think you misread his email, Bruno.
For example: Most people don't need LLDP turned on, and I can say that with certainty unless there is a huge data center following and we cater exclusively to them. It's things like this that end up polluting Fedora boot over time and /that/ is not the appropriate way forward.
On Mon, Jun 06, 2011 at 10:11:40 -0500, Michael Cronenworth mike@cchtml.com wrote:
Bruno Wolff III wrote:
Disabling services that support hardware by default is not the appropriate way forward.
I think you misread his email, Bruno.
For example: Most people don't need LLDP turned on, and I can say that with certainty unless there is a huge data center following and we cater exclusively to them. It's things like this that end up polluting Fedora boot over time and /that/ is not the appropriate way forward.
Supporting rarely used hardware is hardly catering to exclusive groups. It is actually being more inclusive. Running the services isn't directly a problem. There was a concern, because at least one of these services was using a significant amount of CPU time even when there was no matching hardware attached. These are the kind of issues that need to be addressed.
Bruno Wolff III on 06/06/2011 10:10 AM wrote:
Supporting rarely used hardware is hardly catering to exclusive groups. It is actually being more inclusive. Running the services isn't directly a problem. There was a concern, because at least one of these services was using a significant amount of CPU time even when there was no matching hardware attached. These are the kind of issues that need to be addressed.
Point missed again.
LLDP[1] has nothing to do with hardware support.
[1] http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
On Mon, Jun 6, 2011 at 5:57 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 06, 2011 at 15:50:11 +0300, Elad elad@fedoraproject.org wrote:
Live media does not make sense for servers at all. When you install a
Sure it does. Live images make nice rescue images.
We have anaconda rescue mode for that. again, the desktop spin is not intended for servers. It is intended for desktop, that's why it's called desktop spin.
Most desktop users are not enterprise users, and enterprise users are skilled enough to enable the services they need themselves or create their own live media with the packages and configurations they need for their environment.
Not having live images just work is a very poor experience.
Disabling services that support hardware by default is not the appropriate way forward.
Elad (elad@fedoraproject.org) said:
Live media does not make sense for servers at all. When you install a server, you want to control exactly what is going to be installed, which is impossible with live media. Furthermore, the default live media is the Desktop spin, which means - it is for desktop! not servers! You can suggest a server spin if you want.
FWIW, the *distributed* Live media certainly doesn't make sense for servers. However, I do know of server deployments that run off their own customized live images that are pulled from a central server. Of course, those are likely to be site-specific customziations.
(And this is all pretty far afield for the desktop list...)
Bill
On Mon, Jun 6, 2011 at 8:44 PM, Bill Nottingham notting@redhat.com wrote:
Elad (elad@fedoraproject.org) said:
Live media does not make sense for servers at all. When you install a server, you want to control exactly what is going to be installed, which is impossible with live media. Furthermore, the default live media is the Desktop spin, which means - it is for desktop! not servers! You can suggest a server spin if you want.
FWIW, the *distributed* Live media certainly doesn't make sense for servers. However, I do know of server deployments that run off their own customized live images that are pulled from a central server. Of course, those are likely to be site-specific customziations.
(And this is all pretty far afield for the desktop list...)
Bill
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Yes, that's what I meant. What I'm trying to say is that the *desktop* spin shouldn't have anything that is completely useless on a typical desktop.
Em Seg, 2011-06-06 às 11:08 +0000, "Jóhann B. Guðmundsson" escreveu:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
I believe this problem is mostly fixed with the adoption of systemd, where services are started on-the-fly, as needed.
Evandro
On 06/07/2011 02:23 AM, Evandro Giovanini wrote:
Em Seg, 2011-06-06 às 11:08 +0000, "Jóhann B. Guðmundsson" escreveu:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
I believe this problem is mostly fixed with the adoption of systemd, where services are started on-the-fly, as needed.
Systemd does not magically make all service start when needed.
There is a bit more work that needs to be done on the service and application end to make that happen and last time I checked only few services did so and certainly not all service will...
JBG
Em Ter, 2011-06-07 às 06:52 +0000, "Jóhann B. Guðmundsson" escreveu:
On 06/07/2011 02:23 AM, Evandro Giovanini wrote:
Em Seg, 2011-06-06 às 11:08 +0000, "Jóhann B. Guðmundsson" escreveu:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
I believe this problem is mostly fixed with the adoption of systemd, where services are started on-the-fly, as needed.
Systemd does not magically make all service start when needed.
There is a bit more work that needs to be done on the service and application end to make that happen and last time I checked only few services did so and certainly not all service will...
JBG
Yes, these services and applications would have to be ported over to actually make use of systemd. Sorry I wasn't clear.
Evandro
On Tue, Jun 7, 2011 at 1:56 PM, Evandro Giovanini efgiovanini@gmail.com wrote:
Em Ter, 2011-06-07 às 06:52 +0000, "Jóhann B. Guðmundsson" escreveu:
On 06/07/2011 02:23 AM, Evandro Giovanini wrote:
Em Seg, 2011-06-06 às 11:08 +0000, "Jóhann B. Guðmundsson" escreveu:
I think it's time for the Gnome desktop team to revisit and review which services are enabled by default on the livecd/usb and enable only those that benefit the novice desktop end user.
Alot of services are enabled by default that are aimed at enterprise users and to some extend enterprise hardware usages which would never be used on a regular desktop/tablet/notebook pc like for example fcoe, lldpad, iscsi, iscsid, mdmonitor etc. which administrators should enable encase they use it in their enterprise environment.
A bit of discussion about this is happening in bug 707553
I believe this problem is mostly fixed with the adoption of systemd, where services are started on-the-fly, as needed.
Systemd does not magically make all service start when needed.
There is a bit more work that needs to be done on the service and application end to make that happen and last time I checked only few services did so and certainly not all service will...
JBG
Yes, these services and applications would have to be ported over to actually make use of systemd. Sorry I wasn't clear.
Evandro
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Not all systemd services are started on demand.
desktop@lists.fedoraproject.org
-
Bill Nottingham -
Bruno Wolff III -
Elad Alfassa -
Evandro Giovanini -
Jóhann B. Guðmundsson -
Michael Cronenworth