1:45 p.m.
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
2:29 p.m.
On Tue, Jul 21, 2020 at 2:46 PM Jóhann B. Guðmundsson <johannbg(a)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.
11:32 p.m.
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
11:32 a.m.
On Wed, Jul 22, 2020 at 4:32 am, Jóhann B. Guðmundsson
<johannbg(a)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.
2:01 p.m.
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(a)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?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:56 p.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:23 p.m.
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
9:25 a.m.
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/RemoveDeviceMapperMultipathFromWor...
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
9:37 a.m.
I think a change to remove chronyd in favor of timesyncd might be
accepted for Workstation.
11:43 a.m.
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro <mcatanzaro(a)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.
--
Chris Murphy
12:03 p.m.
On Wed, 2020-07-22 at 10:43 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 8:37 AM Michael Catanzaro <
mcatanzaro(a)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).
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
12:46 p.m.
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim
<michel(a)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(a)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.
--
Chris Murphy
12:47 p.m.
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*
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:17 p.m.
On 7/22/20 1:46 PM, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim
<michel(a)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(a)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.
2:11 p.m.
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(a)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(a)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 :/
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:25 p.m.
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(a)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(a)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
4:46 p.m.
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson
<adamwill(a)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.
--
Chris Murphy
6:40 p.m.
On Wed, 2020-07-22 at 15:46 -0600, Chris Murphy wrote:
On Wed, Jul 22, 2020 at 1:11 PM Adam Williamson
<adamwill(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:42 p.m.
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(a)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
9:10 p.m.
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(a)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?
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
9:18 p.m.
On Wed, Jul 22, 2020 at 8:11 PM Michel Alexandre Salim
<michel(a)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(a)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.
--
Chris Murphy
9:45 p.m.
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(a)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
2:21 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)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...
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
6:52 a.m.
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 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?
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 thus
such 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
9:37 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)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...
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
2 p.m.
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(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:40 p.m.
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(a)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
3:39 p.m.
On Wed, Jul 22, 2020 at 1:46 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Wed, Jul 22, 2020 at 11:04 AM Michel Alexandre Salim
<michel(a)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(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
6:07 p.m.
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
8:07 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:37 p.m.
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
7:04 a.m.
On Wed, Jul 22, 2020 at 10:37 PM Jóhann B. Guðmundsson
<johannbg(a)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!
8:07 a.m.
On 23.7.2020 12:04, Neal Gompa wrote:
On Wed, Jul 22, 2020 at 10:37 PM Jóhann B. Guðmundsson
<johannbg(a)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
2 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:42 p.m.
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
2:24 p.m.
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 |
11:34 a.m.
On Tue, Jul 21, 2020 at 6:45 pm, Jóhann B. Guðmundsson
<johannbg(a)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.
1:55 p.m.
On 23.7.2020 16:34, Michael Catanzaro wrote:
On Tue, Jul 21, 2020 at 6:45 pm, Jóhann B. Guðmundsson
<johannbg(a)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
1370
days inactive
1372
days old
desktop@lists.fedoraproject.org
37 comments
11 participants
participants (11)
-
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