Hi
I have noticed we are installing bunch of "enterprise" tools ( which some might view as bloatware ) with the default Fedora Desktop which leaves whole bunch of service enable which delay boot and eat up cpu/memory and space thus give the end user an overall negative experience on her or his laptop hence I have been wondering if there have been any discussion to provide different "edition" of the Fedora Desktop in similar manner like Windows does [1] as in "Windows 10 Home" which mostly comes pre-installed on the laptops people buy ( stripped down windows no enterprise features ) windows 10 Pro which is mostly used in Office environments where joining a Windows Server domain is required and Windows 10 Enterprise, which is Windows 10 Pro + some enterprise related tools and apps etc.
With Fedora "Home" edition the installer could be simplified drastically and the image size refused to bare minimum sd-boot+ systemd + Gnome ( things like atd chrony along with whole bunch of other advanced storage related things ) skipped and end users not allow to custom configure anything other than their language and keyboard ( targeted at noobs ) while for example "Fedora Pro" would allow for custom partitioning filesystem selections etc and include additional tools, Fedora Developer edition which could include all the developer tools, Fedora Enterprise ( sssd,realmd etc ) so fourth and so on.
JBG
1. https://www.microsoft.com/en-us/windowsforbusiness/compare
On Tue, Jul 21, 2020 at 2:46 PM Jóhann B. Guðmundsson johannbg@gmail.com wrote:
Hi
I have noticed we are installing bunch of "enterprise" tools ( which some might view as bloatware ) with the default Fedora Desktop which leaves whole bunch of service enable which delay boot and eat up cpu/memory and space thus give the end user an overall negative experience on her or his laptop hence I have been wondering if there have been any discussion to provide different "edition" of the Fedora Desktop in similar manner like Windows does [1] as in "Windows 10 Home" which mostly comes pre-installed on the laptops people buy ( stripped down windows no enterprise features ) windows 10 Pro which is mostly used in Office environments where joining a Windows Server domain is required and Windows 10 Enterprise, which is Windows 10 Pro + some enterprise related tools and apps etc.
No comment on Fedora Enterprise, but what tools are you referring to? You don't name anything concrete, so it is hard to comment.
On Tue, Jul 21, 2020 at 06:45:43PM +0000, Jóhann B. Guðmundsson wrote:
experience on her or his laptop hence I have been wondering if there have been any discussion to provide different "edition" of the Fedora Desktop in similar manner like Windows does [1] as in "Windows 10 Home" which mostly comes pre-installed on the laptops people buy ( stripped down windows no enterprise features ) windows
Sure -- the Spins concept leaves lots of room for ideas like this.
On 21.7.2020 19:56, Matthew Miller wrote:
On Tue, Jul 21, 2020 at 06:45:43PM +0000, Jóhann B. Guðmundsson wrote:
experience on her or his laptop hence I have been wondering if there have been any discussion to provide different "edition" of the Fedora Desktop in similar manner like Windows does [1] as in "Windows 10 Home" which mostly comes pre-installed on the laptops people buy ( stripped down windows no enterprise features ) windows
Sure -- the Spins concept leaves lots of room for ideas like this.
Was more thinking it as an Edition rather than a spin.
I have noticed that there has been some talk about Fedora now being or about to be preloaded on laptops will only the workstation be preloaded or will there be other options to choose from?
JBG
On 21.7.2020 19:29, Matthias Clasen wrote:
No comment on Fedora Enterprise, but what tools are you referring to? You don't name anything concrete, so it is hard to comment.
I would say for a "Fedora Home" edition the only application I would remove would be boxee and virtualization altogether and replace it with a password manager if Gnome has one. Component wise anything related to enterprise user management and login, enterprise storage local and remote including clients.
+ I personally would remove atd chrony and probably do few other long over due tweaks and cleanups in the process as well.
One thing that I have never understood over these years and that is which target audience is the workstation group aiming for?
From my POV practically speaking.
If the target end users is "regular" person then in reality that person does not use 2/3 of what's being shipped by default. ( he uses just browser,email client,image app to remove red eyes from family photos, calculator and an office application. )
If the target end user is a technical person he can install it himself if he needs it.
If the target user is the corporate employee then he has to follow corporate policies which more often than not include the IT department having full control over the hardware (laptop/phone/workstation) and the OS images that run on it so Fedora is never used as it comes out of the box so to speak.
So in the year 2020 where are we trying to position ourselves?
Are we aiming for the end user market or the enterprise market?
( which leaves out one over the other )
Are we targeting both?
( which would require 2 different editions, If the answer is yes but with one image we are back to being "generic" and on square one )
JBG
Hi,
On 7/21/20 8:45 PM, Jóhann B. Guðmundsson wrote:
Hi
I have noticed we are installing bunch of "enterprise" tools ( which some might view as bloatware ) with the default Fedora Desktop which leaves whole bunch of service enable which delay boot and eat up cpu/memory and space thus give the end user an overall negative experience on her or his laptop hence I have been wondering if there have been any discussion to provide different "edition" of the Fedora Desktop in similar manner like Windows does [1] as in "Windows 10 Home" which mostly comes pre-installed on the laptops people buy ( stripped down windows no enterprise features ) windows 10 Pro which is mostly used in Office environments where joining a Windows Server domain is required and Windows 10 Enterprise, which is Windows 10 Pro + some enterprise related tools and apps etc.
Not sure what services you are referring to, but I'm working no making the livecd (which is the default download we link people to) drag in less exotic storage services: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst...
Rather then have more flavors I would rather see us spending time on optimizing the Workstation flavor. If you have any specific suggestions for further improvements, please let me know.
Regards,
Hans
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
rngd makes me a bit batty - mainly because I get non-deterministic results between VM, and three real computers, i.e four different behaviors. On each, it runs twice, slightly different results between the two executions almost like it wants to try to run early to see if it can succeed, but on these systems it doesn't so it runs again later too. I have no idea if it's correct but systemd really dings the CPU usage quite heavily.
Jul 10 15:46:15 fnuc.local systemd[1]: rngd.service: Consumed 18.120s CPU time.
That's the worst offender. Most are in the 4-8 second range. On 2 of the 4 systems I've uninstalled rng-tools. I have no idea if it's needed for some purposes.
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
On Wed, Jul 22, 2020 at 11:46:04AM -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
note chrony, not to be confused with cronie. *sigh*
On 7/22/20 1:46 PM, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
I think this may require Anaconda changes for the UI to setup time servers.
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
On 22.7.2020 14:37, Michael Catanzaro wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
Should be transparent change basically we are talking about something like
sudo dnf remove chrony
Enabling and starting systemd-timesyncd
sudo systemctl enable systemd-timesyncd.service
sudo systemctl start systemd-timesyncd.service
And perhaps have NM configure timesyncd to use the NTP servers provided by DHCP on roaming wifi ( switching between work/home/uni/coffeeshop etc ).
sudo cat > /etc/NetworkManager/dispatcher.d/10-update-timesyncd << 'EOF' #! /usr/bin/bash
[ -n "$CONNECTION_UUID" ] || exit
INTERFACE=$1 ACTION=$2
case $ACTION in up | dhcp4-change | dhcp6-change) [ -n "$DHCP4_NTP_SERVERS" ] || exit exec > /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf echo "[Time]" echo "NTP=$DHCP4_NTP_SERVERS" systemctl restart systemd-timesyncd ;; down) rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf systemctl restart systemd-timesyncd ;; esac EOF
sudo chmod 0700 /etc/NetworkManager/dispatcher.d/10-update-timesyncd|Do people think something more would be needed for the workstation to switch to timesyncd? ||What's the paperwork for this change? ||would a ticket in the workstation suffice or are we talking about official change proposal ( which means I would have to act fast if the deadline has not expired already for F33 )?|
|| || ||
|JBG |
On 22.7.2020 19:11, Adam Williamson wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Never take anything for granted ;)
JBG
On Wed, Jul 22, 2020 at 1:46 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim michel@michel-slm.name wrote:
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro < mcatanzaro@gnome.org> wrote:
I think a change to remove chronyd in favor of timesyncd might be accepted for Workstation.
It's much simpler. Off hand I can't think of what Workstation would be missing out on.
That would bring us in line with Ubuntu, so - given that Fedora likely has a newer systemd than Ubuntu (e.g. Ubuntu 20.04 only has systemd 245.4, F32 has 245.6) -- if it works for them, and has been working for several releases, it could be worth a Change proposal for F34.
Wearing my sysadmin hat, this would simplify our logic for configuring NTP clients quite a bit, as basically most of our Linux clients would then be on timesyncd (we try to stick to the distro default but just override the config).
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
On 22.7.2020 20:39, Neal Gompa wrote:
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
?
Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).
Given that a distribution that has a larger desktop user base than Fedora ( Ubuntu ) has had it as it's default for several years now ( since 16.04 ) I cant image why the workstation edition has to be some sort of odd child in this regard since last time I checked there was not a single application that came with it that required some sort of sub-microsecond accurate time to function correctly.
+ I would think that dropping a time snippets into /etc/systemd/timesyncd.conf.d/sample-ad.conf with something like
[Time] NTP=DC1.samdom.example.com DC2.samdom.example.com FallbackNTP=the.same.ntp-server.as.your.dc.points.to one-extra.ntp-server.as.your.dc.points.to
Or like so per network interface
[Network] NTP=dc1.samdom.example.com NTP=dc2.samdom.example.com
Would be a well received administration/infrastructure feature for the "enterprise" part of the workstation...
JB
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
On Wed, 2020-07-22 at 23:07 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 20:39, Neal Gompa wrote:
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
?
Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).
It's in at least the Cloud base image, KDE live install, Server DVD install, Silverblue DVD install and Workstation live install.
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
JBG
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
IIRC the use of chrony on RHEL and Fedora predates systemd existing, so... it's just picked by default, presumably?
On Wed, Jul 22, 2020 at 8:11 PM Michel Alexandre Salim michel@michel-slm.name wrote:
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
IIRC the use of chrony on RHEL and Fedora predates systemd existing, so... it's just picked by default, presumably?
https://fedoraproject.org/wiki/Features/ChronyDefaultNTP
That's soon after systemd, but there was no systemd-timesyncd until well after this.
On 23.7.2020 01:07, Adam Williamson wrote:
On Wed, 2020-07-22 at 23:07 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 20:39, Neal Gompa wrote:
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
?
Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).
It's in at least the Cloud base image, KDE live install, Server DVD install, Silverblue DVD install and Workstation live install.
So it's not on IoT and CoreOS which also means we already have experience of running timesyncd instead of Chrony in the distribution which is good.
On top of that Chrony already has a conflict on timesyncd which means timesyncd stops when chrony has been installed and started.
Timesyncd also has lower priority against Chrony since it's already expected if people install Chrony it's being done on purpose so it's basically just a matter for the Workstation WG ( and others ) to decide to start using timesyncd instead of Chrony and remove it from it's package list.
And realistically speaking the use case for Chrony basically are that you are either running an ntp server or in an IT environment which requires sub-microsecond accurate time ( for example infrastructure at the size of FB ), environment's in which Fedora is seldom run in.
So using an already existing and installed service with smaller footprint makes more logical sense as a default across the spectrum as opposed to install additional component to server niche use cases for 1% of the consumers of the distribution which already have to configure the component for those use cases once the component has been installed.
JBG
On 23.7.2020 02:10, Michel Alexandre Salim wrote:
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
IIRC the use of chrony on RHEL and Fedora predates systemd existing, so... it's just picked by default, presumably?
You are misunderstanding the test cases that Adam referred too have nothing to do with Chrony other than Chrony happens to be the component used to test if a service starts and stops correctly which could just as well be done with a service that is already shipped with systemd thus always available regardless of current or future edition and changes that lies within them ( unless the edition would decide to remove systemd which I'm not foreseeing happening in any near future ).
JBG
You are misunderstanding the test cases that Adam referred too have nothing to do with Chrony other than Chrony happens to be the component used to test if a service starts and stops correctly
Yes, this is exactly what the tests should do. You are also right about the fact that it is actually not very important which service is tested here. I understand Adam's comment as "a sigh".
For F32, we swapped the service already for all our test cases because the original service had been removed from the installation. We chose chrony instead because it looked like a service that would stay untouched for some time - who would want to removea time syncing service, right? If we decide to remove chrony, we will need to rewrite those tests again, which will take us time we could devote to something else and the same can happen anytime soon, which reminds the toil of Sisyphus.
Besides, what good will it do if chrony is removed? It works fine for RHEL, why does it not work for us?
which could just as
well be done with a service that is already shipped with systemd thus
such as ... ?
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On 23.7.2020 07:21, Lukas Ruzicka wrote:
You are misunderstanding the test cases that Adam referred too have nothing to do with Chrony other than Chrony happens to be the component used to test if a service starts and stops correctlyYes, this is exactly what the tests should do. You are also right about the fact that it is actually not very important which service is tested here. I understand Adam's comment as "a sigh".
For F32, we swapped the service already for all our test cases because the original service had been removed from the installation. We chose chrony instead because it looked like a service that would stay untouched for some time - who would want to removea time syncing service, right? If we decide to remove chrony, we will need to rewrite those tests again, which will take us time we could devote to something else and the same can happen anytime soon, which reminds the toil of Sisyphus.
Besides, what good will it do if chrony is removed? It works fine for RHEL, why does it not work for us?
RHEL is just a frozen reflection in time of Fedora so anything that works on RHEL is irrelevant to Fedora.
Fedora reflects the opensource environment at a given point in time and that environment changes it's shape roughly every 6 month or so so, so by the time a component hits RHEL it's already outdated and could have been replaced with something else in Fedora.
Fedora users expect to get the latest greatest Gnome desktop environment with all the bells and whistle it's creators envision which is something that you cant deliver in RHEL right.
Take wpa_supplicant for example it works fine for RHEL right but it's about to be replaced with IWD in distributions and I would say now would be the time to look into that and have it in place for F34 which will benefit both IoT and the Desktop environments. X worked fine for RHEL yet we have replaced it, SysV init worked fine for RHEL yet we replaced it and the list goes on as things continuesly evolve.
Surely you have noticed that when you go to a devconf there in BRNO it's like going to a museum and your like hey we used to do that in Fedora couple releases back how cute they are still working on it and this is going to be hell for them to maintain for 10 years or whatever the lifetime of RHEL is these days.
which could just as well be done with a service that is already shipped with systemd thussuch as ... ?
Well timesyncd would be a good example, resolved another both components that should be relative harmless to restart thus not affect other test running in parallel on the same image.
JBG
On Wed, Jul 22, 2020 at 10:37 PM Jóhann B. Guðmundsson johannbg@gmail.com wrote:
And realistically speaking the use case for Chrony basically are that you are either running an ntp server or in an IT environment which requires sub-microsecond accurate time ( for example infrastructure at the size of FB ), environment's in which Fedora is seldom run in.
I take offense to that as someone who runs and helps support Fedora at my workplace. And I imagine so would Facebook, considering they talked about their very large footprint of Fedora at Flock last year. And as Fedora gets preloaded on laptops that businesses buy, it's entirely possible that usage will continue to rise.
And I've heard of businesses actually eschewing both RHEL and CentOS for Fedora deployments at scale for cloud, server, and workstation deployments because the fresher stack is better. Given that Fedora can *generally* run software intended for RHEL, it tends to work out quite well.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 23.7.2020 12:04, Neal Gompa wrote:
On Wed, Jul 22, 2020 at 10:37 PM Jóhann B. Guðmundsson johannbg@gmail.com wrote:
And realistically speaking the use case for Chrony basically are that you are either running an ntp server or in an IT environment which requires sub-microsecond accurate time ( for example infrastructure at the size of FB ), environment's in which Fedora is seldom run in.
I take offense to that as someone who runs and helps support Fedora at my workplace. And I imagine so would Facebook, considering they talked about their very large footprint of Fedora at Flock last year. And as Fedora gets preloaded on laptops that businesses buy, it's entirely possible that usage will continue to rise.
I myself have built proper Fedora stratum 0 server and I'm not talking about some glued together sbc, It costs around $4k and is better and cheaper than some master clock that's insecure and EOL's and deployed that stratum server in datacenter however all the Fedora host that synced time with it used timesyncd.
What I was referring to was that the environment in which the benefits that chrony provides over timesynd are used are few and far between ( It's an exception rather than a rule ). Those environment typically call for you to use something like RHEL instead. I was not saying that Fedora was not being deployed in a large scale in environments or did not exist in those in the first place.
In anycase regardless of what you might feel the majority of Fedora's user base is not running their own ntp server or requiring sub-microsecond accuracy right and there is nothing in the workstation that requires it and highly unlikely that there ever will be such an requirement for a desktop. Chrony does not come configured to support those specific features out of the box in which the administrator could just as well install it since he needs to configure it in the first place, to take advantage of those feature it has over timesyncd and something that is already install and available ( timesyncd ) used instead.
JBG
RHEL is just a frozen reflection in time of Fedora so anything that works
on RHEL is irrelevant to Fedora.
I rather meant it as "if it is enough to run in professional set-ups, it is probably well programmed and stable".
Fedora reflects the opensource environment at a given point in time and that environment changes it's shape roughly every 6 month or so so, so by the time a component hits RHEL it's already outdated and could have been replaced with something else in Fedora.
I know the release cycle of Fedora. However, this is only one way to see it. When the component hits RHEL, it can well be a matured and stable thing, not outdated. And I do not see a reason why we could not profit from such stability in Fedora, too.
Fedora users expect to get the latest greatest Gnome desktop environment with all the bells and whistle it's creators envision which is something that you cant deliver in RHEL right.
This is just an unfair generalization. Fedora users are not exclusively Gnome users. There are lots of them who use a different spin, or a different DE. Your statement would be incorrect, even if you said "Fedora Workstation users", so let me correct you to "Gnome users expect to get the latest greatest ...". Then let me ask you ... Is timesyncd a Gnome thing? Or a systemd thing? And if the latter, why should Gnome users care?
Take wpa_supplicant for example it works fine for RHEL right but it's about to be replaced with IWD in distributions and I would say now would be the time to look into that and have it in place for F34 which will benefit both IoT and the Desktop environments. X worked fine for RHEL yet we have replaced it, SysV init worked fine for RHEL yet we replaced it and the list goes on as things continuesly evolve.
So why do people keep falling back to "outdated" yet stable solutions quite often? X being a superb example.
Surely you have noticed that when you go to a devconf there in BRNO it's like going to a museum and your like hey we used to do that in Fedora couple releases back how cute they are still working on it and this is going to be hell for them to maintain for 10 years or whatever the lifetime of RHEL is these days.
Now, I totally do not understand what the DevConf content has to do with this topic. It seems like you don't like it. That's fine. There a lots of people who do.
Well timesyncd would be a good example, resolved another both components that should be relative harmless to restart thus not affect other test running in parallel on the same image.
How long is this going to stay before anybody suggests another such change?
JBG _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, Jul 22, 2020 at 4:32 am, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
I would say for a "Fedora Home" edition the only application I would remove would be boxee and virtualization altogether
That is worth considering. I think we want to continue promoting Boxes as our recommended virtualization solution regardless, but it's an open question whether it ought to be part of the default experience.
and replace it with a password manager if Gnome has one.
I reported https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/231 to discuss this a while back. It's a tricky question. I think it'd be good to promote our own password manager, but nowadays users seem to prefer services that offer sync between multiple devices.
Component wise anything related to enterprise user management and login, enterprise storage local and remote including clients.
kerberos, sssd, etc. seem to mostly stay out of the way, and it's nice to have them working for users who need them, right? Also: kerberos is exposed via Online Accounts in System Settings. I think of these like VPN plugins: most users will never use them, but they're small and don't hurt anything and to the extent they're integrated into System Settings, having them installed by default is good.
On Tue, Jul 21, 2020 at 6:45 pm, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
sd-boot
I think the bootloader war is more or less lost to GRUB2. Since sd-boot doesn't support BIOS systems -- and probably many more things we need, I'm not an expert -- and we want to continue supporting BIOS, and we also don't want to have to support multiple bootloaders, I see sd-boot as something for advanced users to configure for themselves rather than something we can teach anaconda to use.
On 23.7.2020 16:34, Michael Catanzaro wrote:
On Tue, Jul 21, 2020 at 6:45 pm, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
sd-boot
I think the bootloader war is more or less lost to GRUB2. Since sd-boot doesn't support BIOS systems -- and probably many more things we need, I'm not an expert -- and we want to continue supporting BIOS, and we also don't want to have to support multiple bootloaders, I see sd-boot as something for advanced users to configure for themselves rather than something we can teach anaconda to use.
This is not a "bootloader war" so it cant be won or lost and we already are supporting multiple bootloaders being used in the distribution and legacy bios ain't going away anytime soon.
What came out of that thread ( which I was planning on summarize when I found the time and do a proper official proposal ) is basically
Do as Javier mentioned.
"Just like Anaconda currently provides an extlinux option to use as the bootloader instead of GRUB for legacy BIOS installs, a sd-boot option could be added to choose using this bootloader for EFI installs."
With an system wide goal of working toward what Lennart mention as in standardize on the boot loader spec.
Work towards fixing the sad state of UEFI in our virtualization stack which Daniel mentioned and other relevant areas that need fixing in UEFI ( I would say try to be done with that no later then 2022 )
Then there was an unanswered question how long we should be supporting hardware.
If I google "how long are computer supported" ( YMMV these days ) I get
"For most desktop PCs, a minimum three-year lifespan should be expected. However, most computers survive anywhere from five to eight years" then in what 2023 legacy bios support could be safely dropped.
In anycase the distribution needs to settle on a number ( whatever that number might be ) so end users and developers ( think: we have to support this for so and so years before we can remove it ) expectation can be adjusted accordingly.
JBG
On Thu, 2020-07-23 at 02:37 +0000, Jóhann B. Guðmundsson wrote:
On 23.7.2020 01:07, Adam Williamson wrote:
On Wed, 2020-07-22 at 23:07 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 20:39, Neal Gompa wrote:
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
?
Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).
It's in at least the Cloud base image, KDE live install, Server DVD install, Silverblue DVD install and Workstation live install.
So it's not on IoT and CoreOS which also means we already have experience of running timesyncd instead of Chrony in the distribution which is good.
I said "at least". I don't know either way about those. I'm not clear if your mail is saying you do, or you're assuming my leaving them out of the list meant I knew for sure they used something else, which would not be a correct interpretation.
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
"it's a reliable service that we can rely on to exist in all tested editions". At least, that was the best candidate we could come up with. We used to use sshd, but that became a problem because some tested image (I forget which) no longer includes it.
I didn't suggest anything internal to systemd because a) it's at least plausible there could be some kind of incompatibility issue which was hidden on systemd-internal services, and b) the set of systemd services we actually include and enable out of the box isn't particularly consistent or reliable.
On Thu, 2020-07-23 at 11:32 -0500, Michael Catanzaro wrote:
On Wed, Jul 22, 2020 at 4:32 am, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
I would say for a "Fedora Home" edition the only application I would remove would be boxee and virtualization altogether
That is worth considering. I think we want to continue promoting Boxes as our recommended virtualization solution regardless, but it's an open question whether it ought to be part of the default experience.
Isn't it included as a remote desktop client, as well as a virt client?
On 23.7.2020 19:00, Adam Williamson wrote:
On Thu, 2020-07-23 at 01:42 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 23:40, Adam Williamson wrote:
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2020-07-22 at 11:46 -0600, Chris Murphy wrote:
Is is possible there's a significant minority who have workflows that explicitly depend on chrony? If it's not possible, then I'd support the working group just making the substitution for Workstation 33.
We literally just got done rewriting https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation (and the automated version of that test) to use chronyd on the basis that it's a reliable service that we can rely on to exist in all tested editions :/
Find and replace? :D
@core services dnf-makecache.timer auditd.service plymouth-start.service
chrony isn't in either @core or @standard groups. It's in server-product and workstation-product (anaconda-tools and system-tools). But it may not be in Cloud, IoT, or CoreOS. I'm not sure.
It's in everything we run the test on. We checked.
You don't get any more reliable service that exist in all tested editions current and in the future other than those that come with the system management framework as in you don't have to worry about specific component being installed which might be subjected removal or being broken due to some change which would break all the test right.
So what made QA choose Chrony in the first place?
"it's a reliable service that we can rely on to exist in all tested editions". At least, that was the best candidate we could come up with. We used to use sshd, but that became a problem because some tested image (I forget which) no longer includes it.
I didn't suggest anything internal to systemd because a) it's at least plausible there could be some kind of incompatibility issue which was hidden on systemd-internal services, and b) the set of systemd services we actually include and enable out of the box isn't particularly consistent or reliable.
I'm not aware of any component of the systemd stack being exclude ( all of them get shipped but might be enabled ) so I'm curious of what they might be?
Timesyncd would be a perfect candidate as I had previously mentioned elsewhere in this thread and this would probably break immediately in Dracut if it would not work ( You probably have noticed now a bunch of deprecation warning emitting in type units that reside in Dracut in the bootup on F33, fixes pending upstream, Harald is probably on vacation since they have not be merged yet ) so QA should be focusing more on testing services that are being shipped in every edition as in if they work or not ( but that ofcourse is much more work ).
JBG
On 23.7.2020 19:00, Adam Williamson wrote:
On Thu, 2020-07-23 at 02:37 +0000, Jóhann B. Guðmundsson wrote:
On 23.7.2020 01:07, Adam Williamson wrote:
On Wed, 2020-07-22 at 23:07 +0000, Jóhann B. Guðmundsson wrote:
On 22.7.2020 20:39, Neal Gompa wrote:
I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.
?
Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).
It's in at least the Cloud base image, KDE live install, Server DVD install, Silverblue DVD install and Workstation live install.
So it's not on IoT and CoreOS which also means we already have experience of running timesyncd instead of Chrony in the distribution which is good.
I said "at least". I don't know either way about those. I'm not clear if your mail is saying you do, or you're assuming my leaving them out of the list meant I knew for sure they used something else, which would not be a correct interpretation.
I assumed you leaving them out meant for sure they used something else I hence stand corrected.
JBG
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Chris Murphy -
Hans de Goede -
Jóhann B. Guðmundsson -
Lukas Ruzicka -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Michel Alexandre Salim -
Neal Gompa -
Robert Marcano