Re: It’s time to transform the Fedora devel list into something new

[Jóhann B . Guðmundsson]

On 4/26/23 16:04, Vitaly Zaitsev via devel wrote:

On 20/04/2023 23:20, Matthew Miller wrote:

It’s time to transform the Fedora devel list into something new


I think such serious questions should be put to a vote. Not a FESCo 
vote, but a vote for all Fedora contributors (can be combined with the 
next FESCo elections).



Well it's long overdue that the community in whole cant veto via vote 
poor decision making by the appointed and elected official of the 
project including it's leader...



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 12/22/22 15:39, Lennart Poettering wrote:


Well, the thing is: a chain of trust is a*chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.



Well, the thing with a chain of trust is the fact that the only chain 
the user can trust is the one that he himself or the host device he owns 
and operates generated that trust of chain, from link 0 in that chain. ( 
And we all know how browsers handle self signed certificates who are no 
less secure than those issued )


If the user does not generate or otherwise have control over *all* the 
links in the trust chain, that chain cant be considered trusted now can 
it, which in turn begs the question why partake in this industry 
security theater which may brick or otherwise make the end users life 
more miserable or even exclude certain types of devices, if in the end 
of the day, the host or the end user is not  "secure" for it.


Are those efforts truly for the end user or just to meet some 
industry/government requirements ( some governments require backdoor 
entrance(s) from vendors for "lawful inspection", backdoor(s) that might 
be implement or otherwise supported in the trust chain itself if the 
host or user has not full control over that chain ).



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 12/20/22 21:27, Simo Sorce wrote:


Finally, unless this proposal harms Fedora I do not see why oppose it.
If, as you fear, it won't work ... then it won't and we'll try
something else.



You do realize that the day that Lenovo started to sell it's hardware 
with Fedora pre-installed ( as it was convinced to do) , the days of 
Fedora doing somekind of experiments on it's users base to see what 
sticks or making decisions like hey people if this does not work let's 
try something else, were over right? ( atleast for the workstation 
working group ).



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 15.4.2022 00:44, Kevin Kofler via devel wrote:

One of the reasons people use GNU/Linux is exactly to escape the hardware
manufacturers' planned obsolescence treadmill.


True but that does not mean Fedora is the best distro for that + it 
looks like hw vendors are taking lessons from the Apple playbook and 
starting to vendor lock parts for their hw.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 23:25, Nikolay Nikolov wrote:


On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out
I don't think this statement is true, unless Fedora doesn't want 
to be
considered for a bunch of popular VM hosts (e.g. Linode and such) 
that

have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or 
simply via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via 
some plugin in lvfs based on user feedback when their legacy boot 
mode suddenly stops working or is it expected that upstream lvfs 
team looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) 
update it as Gnome notifies them about available update just like 
they do when they receive anyother software update notification.


Really? I didn't know that. At least on my computers, Gnome has never 
notified me about a BIOS update from my motherboard vendor. Besides, 
it's proprietary software, so I wouldn't expect Fedora to be offering 
it by default. Doesn't it need adding an extra software repository?



It's fwup/lvfs [1] and nope you dont need to jump through any additional 
hoops for that, it just work ( or it does not if the vendor is not part 
of lfvs ).








And besides, non-UEFI systems don't normally receive BIOS updates 
that break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.


How I have no clue, which is why I pointed at an potential lvfs 
plugin or the lvfs team.


I think we should check the BIOS date in the installer and deprecate 
(as in, print warnings to the user in the installer) legacy boot on 
newer systems (e.g. newer than 2017 or some other cutoff date, when we 
decide that UEFI becomes more stable), an by deprecate, I mean, show 
warnings to the user and suggest that they continue on their own risk. 
Of course, we should also check for virtual machines, like e.g. 
QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not 
show the warning in them, even if the BIOS date is new (although 
SeaBIOS seems to use an old date - 06/23/99).



That's something that needs to be worked out with the Anaconda team but 
I think Javier already provide the best path forward with regards to 
Anaconda when I started the dialog two years ago but for whatever reason 
that's not part of Robbie's proposal.



JBG

1. https://fwupd.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 15.4.2022 00:38, Kevin Kofler via devel wrote:

Jóhann B. Guðmundsson wrote:

Trying to support that legacy scenario where certain hw may or may not
work is a nightmare for developers, support teams and Fedora since
Fedora is not a distribution with a long term support, LTS distributions
are better suited to support legacy hw then Fedora ever will.

Nobody is asking Fedora to provide support for fixing old hardware if it
breaks. All we are asking for is for Fedora to continue running on old
hardware that is *not* broken.



Yes I got that it's the hw version of "if it builds let's ship it, even 
if upstream is dead" approach.


The thing is we could elimination so much of technical debt in Fedora if 
we would drop the legacy bios support and could move the distro quite a 
bit forward in coming releases if we did but from the looks of it, it 
seems to have been already decided to "form a sig" and drop this 
proposal so meh Fedora 40 then...



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

If people are wondering how it looks like when Fedora's code of conduct 
is violated when people partaking in community discussions and receive 
attacks in private as an result of that here's an example of that.


This individual has already sent at least me death threats ( privately 
), been blocked on other projects ( non fedora related ) mailinglist ( 
not involving me in those ) shown questionable behavior on the ISC 
mailinglist and now two years later he's at it again.


Word of advice when attack like these happen in private the best way to 
deal with it first and foremost try not let it discourage you, secondly 
expose the attacker to the broader community ( which I'm doing with this 
post and did last time as well ) since Fedora CoC is powerless to deal 
with this ( Often these attackers frequently change email addresses ) 
and the attacker knows it, like his response to me in private when I 
exposed him last time here on devel.


"little idiot: the Fedora COC don't apply for pruvate mails just because 
the topic is fedora relevant"



On 14.4.2022 21:46, Reindl Harald (privat) wrote:



Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmundsson:
"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team 
looks into this or what?

are you mentally ill?

there are tons of physical hardware and virtual machines which don't 
give a shit and just work in BIOS mode


and smome are installed that way because UEFI has no fucking way to 
keep /boot on RAID1 over multiple disks



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply 
via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team 
looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) update 
it as Gnome notifies them about available update just like they do when 
they receive anyother software update notification.



And besides, non-UEFI systems don't normally receive BIOS updates that 
break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.


How I have no clue, which is why I pointed at an potential lvfs plugin 
or the lvfs team.



JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 18:29, Peter Boy wrote:



Maybe "legacy BIOS on physical hardware" is on its way out, but it
doesn't seem that it is true across the board in VM environments.

That’s maybe true for desktops, but in the server world any server needs to be 
able to do bios boot, because of the data center requirements.



Interesting I would assume that those data center requirements would 
make it a requirement for example to be using uefi's native http 
protocol to address the shortcomings of traditional (i)pxe, so which 
data center requirement are those and where can I find documentation 
about them?



JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply via 
firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is greyed 
out"


So how do people propose the situation to be handled when firmware from 
vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team looks 
into this or what?



JBG

1. 
https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 16:38, Ben Beasley wrote:

I’m not talking about refurbished parts or new old stock. I’m talking about the 
brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other 
components that are backwards-compatible in systems pushing twenty years old 
(SATA) or older (PSUs, fans). Maybe I misunderstand, but your argument seems to 
be based on the idea that all replacement parts are custom designs tied to OEM 
support policies rather than commodities based on long-lived standards.


I'm talking about the entire hw range in the computer, every single 
component which can break not just the nuts and bolts on the computer 
case, or the PSU fans etc. ( It's interesting how you always avoid 
mentioning motherboard/GPU failures etc ).


As much as people may dislike it, the fact is those long lived standards 
have been replaced with a newer standards and not all replacement parts 
are backwards compatible like for example for a video device to work on 
a motherboard with a legacy BIOS, or in CSM mode, it needs a VGA option 
ROM to initialize the card.


Most video cards/IGPs for the last few years have dropped legacy BIOS 
support and only have UEFI ROMs ( which means they wont work on legacy 
bios or in CSM mode ) so we already are in an era when people are buying 
replacement parts which either needs to be old enough or legacy-friendly 
enough to work on that legacy hardware and as much as I dislike it, 
entering an era of vendor locked replacement parts ( Like AMD epyc CPU's 
getting locked to computer vendors. AMD epyc CPU's from Dell HW wont 
work on Lenovo HW and visa versa even if those are the exact same CPU 
models etc. )


Trying to support that legacy scenario where certain hw may or may not 
work is a nightmare for developers, support teams and Fedora since 
Fedora is not a distribution with a long term support, LTS distributions 
are better suited to support legacy hw then Fedora ever will.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 15:53, Peter Boy wrote:



Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :

It should be quite apparent prevent the hw support lifecycle dialog from ever 
occurring again we need a rigid planned supported hw lifecycle.


Again, the legacy BIOS discussion is not about hardware, as implied by the 
name. It is software and support and management software infrastructure.



Bios is a software that is directly tied to hw lifecycle from vendors so 
it most certainly is (in)directly related to hw support discussion in 
Fedora.


Then there is the fact that clinging to legacy bios is working against 
Fedora's own foundation "First" in which is stated "Fedora always aims 
to provide the future, first".



JBG


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 14:07, Martin Jackson wrote:

In many industrial and retail use cases, 10 years is the low end. 3-5 years is 
an accounting timeline (for depreciation) not necessarily the useful life of 
the asset. If the asset can be used after it’s done depreciating that is a 
bonus for the company using it.



HW security is one reason the companies are replacing their hw after 3-5 
years and in those cases the assets being deprecated are removed from 
the premise.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 13:09, Ben Beasley wrote:
For desktop-class hardware, the parts that are most likely to fail 
around the decade mark are storage drives, power supplies, and perhaps 
fans. All of these are fully standardized and in plentiful supply; 
there is no reason that first-party hardware vendor support should be 
required to keep old desktop systems in service.



We need to actually see some real hard data involving those fail parts 
from the manufactures themselves and or official repair shops since 
there are plethora of "refurbished" hw out there ranging from "cosmetic 
imperfections" to outright "motherboard replacements".  I've experience 
and seen plethora of spectacular computer failures as part of my dayjob 
and in my own hw.





Dropping support for old hardware in Fedora should always be based on 
the costs and benefits, not on a rigid planned lifecycle.



Well here's the thing this is one of these reoccurring long threaded 
discussion ( which means they are stuck in status quo ) that happen 
every once in a while, back in the day it used to be Alan Cox that was 
advocating for lifetimes support of steam powered devices, today the 
dialog involves deprecating legacy bios.


It should be quite apparent prevent the hw support lifecycle dialog from 
ever occurring again we need a rigid planned supported hw lifecycle.


That can be 10 years project wide or simply something that each WG 
tailors for their own target audience ( shorter, longer that's for them 
to decide since they should be doing all the work involving their 
"products" and their maintenance ) but as I said we need a rigid planned 
supported hw lifecycle, leaving this things are one more time just means 
that we will have this dialog again further down the line.



JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 12:18, JadoNena via devel wrote:

But for here we deal with the real world where budgets require plans and 
hardware exists for years.



If you are dealing with the real world with real businesses then you 
should be aware of the fact that businesses are usually on a 3 - 5 year 
hw replacement cycle since it save costs as studies like these have 
found [¹].


After 3 - 5 years those computers are introduced into the re-use/recycle 
ecosystem and re-purposed elsewhere with the hw vendors being forced to 
support that cycle.


With 10 years of hw support in fedora it would fit nicely into that cycle.


That said obviously companies will lose that cost saving if they end up 
having to spend it in a license cost elsewhere, be it Red Hat, Microsoft 
or something else..



JBG


1. 
https://news.microsoft.com/en-nz/2018/10/16/true-cost-of-not-replacing-computers-revealed-in-microsoft-study-more-than-4000-each/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 11:42, Kevin Kofler via devel wrote:

Jóhann B. Guðmundsson wrote:


For example EU has regulation that requires vendors to have spare parts
available for 7–10 years after date of manufacturing so it makes sense
for the project to support hw no longer than a decade from the date of
it's manufacturing. ( which makes the oldest hw being support being
manufactured in 2012 ) and every process,workflows and decision being
bound by that.

Lack of availability of original spare parts does not mean that the hardware
suddenly magically stops working for everybody.


No but it does mean that they cant run indefinitely

And there needs to be a number on this to adjust users expectation and 
10 years is a reasonable number from a business, parts and 
recycle/re-use availability,


What is unreasonable is to be expecting that it's supported indefinitely 
from OS and or HW vendors.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 11:53, Peter Boy wrote:



Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :

For example EU has regulation that requires vendors to have spare parts 
available for 7–10 years after date of manufacturing so it makes sense for the 
project to support hw no longer than a decade from the date of it's 
manufacturing. ( which makes the oldest hw being support being manufactured in 
2012 ) and every process,workflows and decision being bound by that.

Is Fedora an distribution that does not revert but always transforms, rolls out 
and moves forward or is it an distribution that is stuck in the past ( from a 
software and hardware point of view )?

Sorry, you simple didn’t get the point. It is not just about hardware. Some 
Cloud providers doesn’t support UEFI boot at the moment - so said various 
voices from Cloud WG. And some data center insist ob BIOS boot because of 
whatever, presumably management infrastructure. So, the hardware does or does 
not support UEFI, doesn’t matter in these cases.



So you are saying that 3rd party vendors ( cloud providers ) now dictate 
and decide the direction of the project?



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Jóhann B . Guðmundsson]

On 14.4.2022 09:17, Tomasz Torcz wrote:

On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:


Am 13.04.22 um 20:05 schrieb David Cantrell:


The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.

I do not agree with this statement.  Like previous "Legacy SIGs" this is a
red herring to obfuscate RHATs lack of disinterest with topics, which do not
match into their business objectives.

   Really? Fedora is mainly a volunteer effort, someone has to do the work.
SIG is a good solution. RedHat is under no obligation to work on
everything.

Anything that adds to the bureaucracy level of a project or community in 
general is never a good thing since such process gets in the way of the 
people that are actually doing all the work ( more often than not too 
much energy spent on bureaucracy than the actual work itself ).


In this case that SIG would be created for no good reason since the 
outcome is inevitable.


What the project needs to decide upon is...

For how long should fedora support any given hardware ( electric 
components do not last forever ) ?


For example EU has regulation that requires vendors to have spare parts 
available for 7–10 years after date of manufacturing so it makes sense 
for the project to support hw no longer than a decade from the date of 
it's manufacturing. ( which makes the oldest hw being support being 
manufactured in 2012 ) and every process,workflows and decision being 
bound by that.


Is Fedora an distribution that does not revert but always transforms, 
rolls out and moves forward or is it an distribution that is stuck in 
the past ( from a software and hardware point of view )?



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 14.4.2022 02:23, Demi Marie Obenour wrote:

On 4/13/22 17:11, Jóhann B. Guðmundsson wrote:

On 13.4.2022 08:04, David Bold wrote:

It seems I must be missing something? Why should we not care about a
significant number of our users, just because other OSs have more users?
Could you explain that?

First of all this is not significant number of Fedora's users ( or in
the overall desktop ecosystem ) and secondly as David Cantrell already
pointed out downstream distribution should not be expected to jump
through hoops to support hardware vendors that are unwilling to
participate in the open source Linux ecosystem.

What fraction of Fedora users is this?


Is not the question what is an acceptable number in that regard 1 
person, hundred, thousand or 1%,5%, 10% and whether or not we want to 
increase/decrease that number?




   Yes, I agree that Fedora should
not have to jump through hoops to support NVIDIA.  But at the same
time, we need to consider how many users we will be breaking.


Sorry I dont follow, Fedora ( at least to this day ) doesn't come with 
the proprietary nvidia drivers installed, nor tests for it or otherwise 
supports in any official manner so what is there for us to break, end 
users expectations of what we dont ship/support does not work?

**




The consumers of such hardware vendors should either stop buying their
hardware ( like I did decades ago ) or contribute to opensource projects
that provide the required support to be able to use that hardware.

The more likely outcome is that such consumers will switch to a
distribution that makes it easy for them to use the hardware they have.
The vast majority of users lack the skills, resources, or both to
contribute to Nouveau or Mesa.


Is that bad thing?

It most certainly is not a bad thing for the Linux/FOSS ecosystem if you 
think of it as a whole.


What matters to sustain the ecosystem is continues flow of contributions 
upstream which in turn will trickle back down to every downstream.


Where the source of that contribution comes from is completely 
irrelevant since everyone will eventually benefit from it so what 
matters is getting users that will contribute back to the ecosystem one 
way or another so this whole notion/theater of distributions competing 
among themselves for a user base is just ridiculous.


What matters is that there aren't any bottle necks in the downstream 
process ( like endless levels of bureaucracy, which for example Hans is 
proposing to create another level, for a problem that already has a 
fixed outcome since at one point in time legacy bios will be deprecated 
so why yet another SIG )  which reduce or otherwise hinders the flow of 
contributions upstream.


And here's the thing computers were meant to be a tool to make people's 
life easier so in the end of the day people will decide to use whatever 
*works for them* *themselves*, that might be windows, OS-X, any of the 
Linux/*nix distributions or something else.


And the fact is Fedora is not a distribution for novices end users and 
never will be nor will it ever be everything to everyone ( but it did a 
simpler and better job in attempt being just that when it was just 
generic ).



   


And the idea that has been circulated that Fedora is supposed to be
building third-party kernel modules ( since this security nightmare is
being opened why limit it only to nvidia )  and *signing them* without
being able to validate the content it is building is a security risk [1]
that affects all Fedora users regardless if they use a third party
module or not, is just outright ridiculous both from a security point of
view as well as it will hinder participation on the projects that are
trying to provide an opensource alternatives.

Right now, secure boot on Fedora is security theater.



I would rather say Fedora partakes in an industry one.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 13.4.2022 08:04, David Bold wrote:


It seems I must be missing something? Why should we not care about a 
significant number of our users, just because other OSs have more users?
Could you explain that? 


First of all this is not significant number of Fedora's users ( or in 
the overall desktop ecosystem ) and secondly as David Cantrell already 
pointed out downstream distribution should not be expected to jump 
through hoops to support hardware vendors that are unwilling to 
participate in the open source Linux ecosystem.


The consumers of such hardware vendors should either stop buying their 
hardware ( like I did decades ago ) or contribute to opensource projects 
that provide the required support to be able to use that hardware.


And the idea that has been circulated that Fedora is supposed to be 
building third-party kernel modules ( since this security nightmare is 
being opened why limit it only to nvidia )  and *signing them* without 
being able to validate the content it is building is a security risk [1] 
that affects all Fedora users regardless if they use a third party 
module or not, is just outright ridiculous both from a security point of 
view as well as it will hinder participation on the projects that are 
trying to provide an opensource alternatives.


JBG


Ps. cc-ing devel list.


1. 
https://www.bleepingcomputer.com/news/security/malware-now-using-nvidias-stolen-code-signing-certificates/?s=09
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 12.4.2022 20:44, Mark Otaris wrote:

Your calculations have to be off; I’m pretty sure there are way more than 100 
Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora 
users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard 
minimum: https://linux-hardware.org/?view=gpu_vendor=Fedora. I think there 
are at least tens of thousands of Fedora users with a Nvidia GPU. It’s not a 
majority, is all.



Let's give you your tens of thousand of fedora users with Nvidia GPU, 
it's still not even a blimp in the chart of the overall desktop market 
share, let alone a number worth sacrificing core values for.


Fedora only holds a very small % of those 2.36% of the Linux desktop 
market share which is such a small number it wont even be worth raising 
someone's eyebrow at Nvidia...



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jóhann B . Guðmundsson]

On 12.4.2022 00:24, Mark Otaris wrote:

However, the majority of Linux PC users *must* step out of the happy path
to get their hardware working for two cases:

* NVIDIA graphics
* Broadcom wireless

In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% 
AMD, 5% other. I don’t think Broadcom wireless is that common either. So it’s a 
lot of people, but not a majority of Linux PC users, probably less than 25%.



Well it's not like it's affecting a large number of desktop users since 
those 25% are at best 25% of the desktop market share in Linux, which is 
just 2.36% ( excluding Chrome OS which has 2.79% market share on it's 
own, higher than all other Linux distributions combined ( which are 
around 500 ) ...  ).


Then you can further reduce that number by figuring how much % each 
distribution has of those 2.36% which should give you what Fedora has of 
that and that ends up being what 10 people, 100 hundred at best so you 
are sacrificing the core values of Fedora for those 10 - 100 vocal 
people...


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 19.10.2020 17:25, Michael Catanzaro wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis 
 wrote:
I'am also have Thikpads and MSI running BIOS and some of those 
machines  still are the beast in some terms. Dropping BIOS would 
pretty much force me to use something else.

I don't want to lose Fedora.


This proposal was soundly rejected, so don't worry about it. 



Never was an official proposal to begin with so I cant see how it was 
"soundly rejected" but yes the dialog highlighted that there will be 
quite few years before the distribution can get to the point where an 
official proposal can be made. Maybe 2024 would be a target goal for 
such effort. Regardless consensus has to be reached on how long/old 
hardware should be supported so people expectations can be 
raised/lowered accordingly. Arguably something that the Council should 
look at.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 6.7.2020 12:07, Tomasz Torcz wrote:

On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote:

The BIOS provides block device access at sector level, so the boot
loader has little choice but implementing drivers for all kinds of
stuff.  Or use fragile block lists like lilo did in the last century.

With UEFI much more functionality is provided by the firmware and there
is little reason for a bootloader to have tons of drivers.  With the
exception of filesystem drivers in case you want boot from something !=
vfat.  But even that should ideally be implemented as uefi driver not as
grub2 module.

  FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others:
  https://efi.akeo.ie/



Thanks this was very helpful.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 6.7.2020 18:39, Javier Martinez Canillas wrote:

On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
 wrote:

On 5.7.2020 18:34, Javier Martinez Canillas wrote:

On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering  wrote:

[snip]


Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be delighted to add more if they
make sense and that helps.


Thanks. I'll discuss this with the rest of the bootloader folks and
think how the spec could be extended to cover the remaining cases
where variable expansion is still used for GRUB. The new keys could be
generic and even benefit other bootloaders if they implement these
features at some point (e.g: boot entries protection).

Since you are in contact with and thus presumably you are one of the
"bootloader folks" could you clarify who those individual are and what
role they play and which bootloaders they represent in the distribution
and on which arch etc. and where they can be contacted ( mailinglist )
since I don't find any documentation about any bootloader WG existing
within Fedora yet such a team seems to exist since it's being mentioned.


Sure, I meant the members of the Red Hat bootloader team (Peter Jones,
Jan Hlavac and me) and people who are not part of the bootloader team
but work very closely with us and help to improve the boot stack in
general. Mostly Hans de Goede and Christian Kellner but also others.

Peter maintains all the projects in https://github.com/orgs/rhboot and
their respective packages in Fedora. And I help him with that work. We
are also involved in the upstream communities of the bootloaders that
are used in the architectures supported by Fedora. These are:

- GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF)
- Petitboot (ppc64le OPAL)
- zipl (s390x)
- u-boot (armv7).

But for the last two most of the work and the package maintenance is
done by Dan Horák (s390utils-base) and Peter Robinson
(uboot-images-armv7).

All these people can be contacted in the Fedora devel mailing list. I
hope this answers your question, please let me know if you need more
details.


This was precisely the info I was looking for.

Thanks
  JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 5.7.2020 19:31, Solomon Peachy wrote:

On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote:

In terms of physical x86 systems, you are right that UEFI is the
overwhelming majority. But as stated elsewhere in this thread, a lot
of cloud providers and virtualization software default to using BIOS.
So I think Fedora should only start considering dropping BIOS support
once the default is UEFI on most virtualization platforms.

FWIW, I completely agree with this.



As do I.

Hopefully Daniel's response of the poor state those tools are in, will 
raise some red flags within Red Hat in which it starts throwing some 
resources ( money,workforce) to have this addressed before RHEL 9 gets 
released.


Atleast that is what I would do if I was a person in power within Red 
Hat ( or a company that provides or relies on a solution based on those 
tools) and had read his response which described quite the "alarming 
situation" for products within the company in relation where the 
industry is heading.


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 5.7.2020 18:34, Javier Martinez Canillas wrote:

On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering  wrote:

[snip]


Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be delighted to add more if they
make sense and that helps.


Thanks. I'll discuss this with the rest of the bootloader folks and
think how the spec could be extended to cover the remaining cases
where variable expansion is still used for GRUB. The new keys could be
generic and even benefit other bootloaders if they implement these
features at some point (e.g: boot entries protection).


Since you are in contact with and thus presumably you are one of the 
"bootloader folks" could you clarify who those individual are and what 
role they play and which bootloaders they represent in the distribution 
and on which arch etc. and where they can be contacted ( mailinglist ) 
since I don't find any documentation about any bootloader WG existing 
within Fedora yet such a team seems to exist since it's being mentioned.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 2.7.2020 10:16, nick...@gmail.com wrote:

On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:

Solomon Peachy writes:


Even putting that aside, for the past several years CSM/BIOS has
been
slowly bitrotting due to a lack of real testing, as the last few
Windows
releases have mandated use of UEFI for preinstalled systems, plus
the
EOLing of Windows 7 and (especially) XP.

That's only because it's Microsoft.

Note that, even though Microsoft is pushing for UEFI on new systems in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no longer does, so you can install
and run it on even older hardware than Fedora. Even the latest May 2020
update of Windows 10 has a 32-bit retail version that is directly
downloadable from their website:

https://www.microsoft.com/en-us/software-download/windows10ISO

The only Windows that no longer supports 32-bit systems is Windows
Server. So the obsolescence of Windows 7 and XP is irrelevant.

I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
for hardware obsolescence faster than Microsoft in this regard. :(

To be completely fair, I must say that Fedora runs on first generation
AMD64 hardware, while the 64-bit version of Windows no longer does, but
the 32-bit Windows 10 still works on them, and on even earlier CPUs
that are 32-bit only, which Fedora no longer supports.


I think linux distribution started to drop 32bit back in 2015 so Fedora 
has just been following that trend and Microsoft is seemingly dropping 
32bit [1] ( probably no wants to pay for that support anymore supply and 
demand).


"** Beginning with Windows 10, version 2004, all new Windows 10 systems 
will be required to use 64-bit builds and Microsoft will no longer 
release 32-bit builds for OEM distribution."


At one point or another Fedora needs to reach consensus on how old 
hardware should be considered "supported" to set realistic end users 
expectations accordingly as well as not to find it in a situation in 
which an old hw blocks the progress of the distribution or a change of a 
primary architecture ( everything seems to be moving to arm these days ) 
and visa versa ensure that older hw is "supported" for the duration of 
that time that it's promised but that's a topic for an entirely 
different thread.



JBG


1. 
https://docs.microsoft.com/en-us/windows-hardware/design/minimum/minimum-hardware-requirements-overview


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 2.7.2020 01:42, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson  wrote:

On 2.7.2020 01:06, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson  wrote:

On 1.7.2020 23:28, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 7:19 PM Björn Persson  wrote:

Jóhann B. Guðmundsson wrote:

More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )

This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.

Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.


If I ever wanted to switch to another boot manager, I'd seriously like
us to consider rEFInd: https://www.rodsbooks.com/refind/

It's a very nice boot manager that looks good and doesn't suck. And
purportedly is somewhat (if not fully) compatible with bls.

sd-boot is too barebones and unfriendly to use, which makes sense
since it was designed for non-interactive machines and not humans to
use.

If there is this general feel that sd-boots configuration syntax is much
harder to read and the ability of not having to run additional command
once the file has been edited or the ability to be able to easily
maintain and manage multiple kernels or multiple operating systems due
those being a drop-in configuration text files, is considered being too
bare bone and *less* user-friendly than grub, then obviously me creating
a change proposal based on what Javier suggested along with other
cleanups to provide as best user experience as can be had with sd-boot
would be doing the distribution a great disservice would it not?


Oh, I don't care about the configuration syntax. That part would be
the same across grub, refind, and sd-boot anyway.

The user-interactive portion of sd-boot is *awful*. I know our GRUB
looks ugly by default these days too, but it doesn't have to be, and
most distros actually do make it look semi-decent.

But alas, nobody cares about making that part look nice, because they
hope people don't have to go there at all. But even Windows makes
their boot manager not look ugly and relatively easy to navigate. And
obviously Apple has done this forever with macOS.

I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX.

Because the end user should never find himself in the boot manager to
begin with that's why no boot manager invest any time in being "pretty".

The end user should find himself ending up in some form of shiny nice
user friendly rescue environment that helps him troubleshoot his problem
would you agree?


I would, except, we can't have that either, because nobody cares to
make that either.


Well if anything I would have expected atleast the Gnome community to 
care deeply about that and build a a rescue environment consistent with 
the overall Gnome experience.


If we implement sd-boot in conjunction with the automatic boot 
assessment we should be able to boot into such environment if the end 
users boot fails but if people oppose sd-boot and see that as unusable 
root of all evil or there is no interest within the Workstation WG and 
or Gnome community ( Team Anaconda might be the right place for such 
work? )  working on to provide such an rescue environment then obviously 
nothing will change.


JBG


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 2.7.2020 01:06, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson  wrote:

On 1.7.2020 23:28, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 7:19 PM Björn Persson  wrote:

Jóhann B. Guðmundsson wrote:

More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )

This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.

Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.


If I ever wanted to switch to another boot manager, I'd seriously like
us to consider rEFInd: https://www.rodsbooks.com/refind/

It's a very nice boot manager that looks good and doesn't suck. And
purportedly is somewhat (if not fully) compatible with bls.

sd-boot is too barebones and unfriendly to use, which makes sense
since it was designed for non-interactive machines and not humans to
use.

If there is this general feel that sd-boots configuration syntax is much
harder to read and the ability of not having to run additional command
once the file has been edited or the ability to be able to easily
maintain and manage multiple kernels or multiple operating systems due
those being a drop-in configuration text files, is considered being too
bare bone and *less* user-friendly than grub, then obviously me creating
a change proposal based on what Javier suggested along with other
cleanups to provide as best user experience as can be had with sd-boot
would be doing the distribution a great disservice would it not?


Oh, I don't care about the configuration syntax. That part would be
the same across grub, refind, and sd-boot anyway.

The user-interactive portion of sd-boot is *awful*. I know our GRUB
looks ugly by default these days too, but it doesn't have to be, and
most distros actually do make it look semi-decent.

But alas, nobody cares about making that part look nice, because they
hope people don't have to go there at all. But even Windows makes
their boot manager not look ugly and relatively easy to navigate. And
obviously Apple has done this forever with macOS.

I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX.


Because the end user should never find himself in the boot manager to 
begin with that's why no boot manager invest any time in being "pretty".


The end user should find himself ending up in some form of shiny nice 
user friendly rescue environment that helps him troubleshoot his problem 
would you agree?


JBG


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 23:28, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 7:19 PM Björn Persson  wrote:

Jóhann B. Guðmundsson wrote:

More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )

This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.

Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.


If I ever wanted to switch to another boot manager, I'd seriously like
us to consider rEFInd: https://www.rodsbooks.com/refind/

It's a very nice boot manager that looks good and doesn't suck. And
purportedly is somewhat (if not fully) compatible with bls.

sd-boot is too barebones and unfriendly to use, which makes sense
since it was designed for non-interactive machines and not humans to
use.


If there is this general feel that sd-boots configuration syntax is much 
harder to read and the ability of not having to run additional command 
once the file has been edited or the ability to be able to easily 
maintain and manage multiple kernels or multiple operating systems due 
those being a drop-in configuration text files, is considered being too 
bare bone and *less* user-friendly than grub, then obviously me creating 
a change proposal based on what Javier suggested along with other 
cleanups to provide as best user experience as can be had with sd-boot 
would be doing the distribution a great disservice would it not?


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 23:18, Björn Persson wrote:

Jóhann B. Guðmundsson wrote:

More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )

This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.

Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.


What I was referring to was that systemd uses split configuration text 
files which can easily be copy or edited like lilo.conf was but OK.


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 21:50, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson  wrote:

On 1.7.2020 21:00, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
 wrote:

On 1.7.2020 16:10, Solomon Peachy wrote:

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:

I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,

This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.

AMD is "strongly" recommending UEFI for the windows [1]

So Apple dropped CSM in 2006

Intel in 2020

AMD is against it's use

Windows has moved on with the curve...


That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.

KVM guys here are still recommending BIOS.

We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.

Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".

It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.

At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.

Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.

Perhaps it's not that people dont care and more that they are unaware of
those problems  I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.


I suspect you may not be aware because nobody ever bothered to bubble
it up to you.

I think most people are satisfied with the situation, but I'm not. I
despise NVIDIA, but guess what, there's no choice in the marketplace
anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
And no laptop lets you swap GPUs like you can on desktops.

Red Hat probably doesn't care because most server users are not using
UEFI yet. That proportion goes down a lot as people transition from on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.

Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.

On the desktop side, most PC makers shipping Linux are turning UEFI or
UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
shipping Secure Boot on by default, as I suspect Lenovo will with
their Linux laptops, then the NVIDIA drivers will simply fail to
function.

Nouveau obviously works (for some definition of works...), but because
NVIDIA is awful, it is not a useful driver like amdgpu is.

The Fedora Koji Build System is not capable of building kernel module
packages and signing them so that they are trusted. The Koji Build
System *itself* does not make it easy to offer this functionality in
the same way that other build systems (like SUSE's OBS) do. Moreover,
we rely on RPM Fusion to build the driver package, which is fine,
except nobody can get RPM Fusion's Koji system to sign the driver
correctly and have the Fedora kernel trust the RPM Fusion certificate
automatically. Nor is there a straightforward way for packages to get
installed and have their signatures trusted so that kernel modules
that are properly signed will work.

The core of it is that nobody cares. It comes up at least once or
twice every development cycle in the Workstation Working Group
meetings, but there's nothing we can do. Sometimes I'll get bullshit
answers from people. Sometimes they'll just say

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 21:39, Ricky Zhang wrote:

I second your point.

I don't see any upside to discontinue support of legacy BIOS. Even my latest 
machine support legacy BIOS. UEFI caused more headache to me than bringing in 
any real positive user experiences.


What headache exactly? You had bad user experience with UEFI because ?


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 20:31, Ralf Corsepius wrote:

On 6/30/20 3:34 PM, Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream 
changes it beg the question if now would not be the time to stop 
supporting booting in legacy bios mode and move to uefi only 
supported boot which has been available on any common intel based x86 
platform since atleast 2005.
This statement is simply not true - With all due respect, I for one 
consider this statement of yours to be close to a blatant cheat and a 
lie. 


Well I got this from the internet it was not as I intentionally meant to 
cheat or lie. Obviously I did not do a proper research or enough digging 
on Intel website to obtain correct information or this simply was some 
form of marketing speak from Intel, I mean what is "common intel based 
x86 platform"?


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 21:00, Neal Gompa wrote:

On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
 wrote:

On 1.7.2020 16:10, Solomon Peachy wrote:

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:

I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,

This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.

AMD is "strongly" recommending UEFI for the windows [1]

So Apple dropped CSM in 2006

Intel in 2020

AMD is against it's use

Windows has moved on with the curve...


That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.

KVM guys here are still recommending BIOS.

We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.

Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".

It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.

At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.


Based on the feedback here there are atleast 5 - 10 years before we can 
even consider removing it so no worries this wont come up again for a 
looong time but hopefully there are other areas we can improve upon 
which helps us improve the overall UEFI experience in Fedora etc.


Perhaps it's not that people dont care and more that they are unaware of 
those problems  I mean I personally was unaware of those problem and 
probably whole lot of other people here as well so could you list in 
more detail what exactly those user experience problems with UEFI are 
that you are aware of and we can try to compile a todo list to work with.


JBG


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 17:17, Peter Robinson wrote:

The use of legacy or uefi are changes that users have to manually change
themselves in their bios from manufactures default settings. There is no
tool that can do that for them or migrate those settings however users
should be able to change this for hardware around 2010.

The Installer would have to try to detect and make a choise sd-boot ( If
settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending
on it's results.

grub2 supports UEFI, doesn't have to be sd-boot


Javier already has provide the best path forward for now and that is for 
Anaconda to provide an sd-boot option in same/similar manner as extlinux exist 
today so people will have the option to chose to use sd-boot instead of GRUB.

Those who want a simple modern bootloader will then have the ability to use it 
while those need or prefer a boot manager OS and all it bells and whistles it 
brings along with it can continue to use that.

After what one or two releases of Fedora the idea of making sd-boot the default 
for EFI installs can be visited and or WG decide that for themselves.



JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 16:10, Solomon Peachy wrote:

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:

I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,

This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.


AMD is "strongly" recommending UEFI for the windows [1]

So Apple dropped CSM in 2006

Intel in 2020

AMD is against it's use

Windows has moved on with the curve...


JBG


1. https://www.amd.com/en/support/kb/faq/cpu-uefi-mode
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 1.7.2020 09:36, Lennart Poettering wrote:

On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) wrote:


   Hi,


So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.

Right.

Preferably the installer should detect and setup the system either with
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )

I have my doubts that building on sd-boot and drop grub2 is going to fly.

One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).

Nah, that's not true. Hasn't been for quite a while.

sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.

This means installers have two options:

1. Create a large ESP and just use that. Everything is nice and simple

2. If the ESP already exists and there's no interest in growing it,
just add in an XBOOTLDR partition and use that instead.



The latter (2) is presumably what manufactures would want OS and their 
installers to default to.


As in don't destroy or resize ( which could risk destroying it ) the 
existing ESP that comes from the factory and may contain manufacturers 
specific tools instead keep it as it is and place only the boot manager 
( sd-boot ) on the existing ESP while OS specific kernels ( and any 
other stuff the OS might want to place on the ESP ) is placed on a 
separate XBOOTLDR partition.


The above is probably also the best compatibility scenario for dual boot 
or multi boot scenarios.






Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?

sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.


IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI.  Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases:  Use gpt.  Create a bios boot partition, install grun-pc
there.  Create a ESP partition, install grub-efi there.  Create a
partition for the /boot filesystem.  Have both grubs pick up BLS config
from /boot/loader.

My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
not this terrible template language that Fedora now supports in Grub,
which is just the same old grub complexity again. They stole the "Boot
Loader Spec" name and turned it into something that is not related at
all to the real thing.

Supporting the boot loader spec has various benefits, including that
systemd's "systemctl kexec" will just work and understand these tiems.

Yeah I was going to look at that as well ( how far off Fedora is from 
the boot loader specification and where it's going off the rails ) while 
I'm looking at this.



JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 22:38, Kevin Kofler wrote:

Jóhann B. Guðmundsson wrote:

sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).

And that is exactly the problem, systemd-boot has only a small fraction of
the feature set of GRUB. That is what makes it so small. I do not see what
value it would provide over GRUB-EFI.

In addition, as far as I know, systemd-boot is not compatible with the
"Secure Boot" shim.



sd-boot works fine with secure boot but good point I'll add a test case 
for that and check if it's not working.


( This might actually have been one of those case that I might have 
forgotten so good catch )



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 22:31, nick...@gmail.com wrote:

On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote:

On 30.6.2020 21:14, nick...@gmail.com wrote:

On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote:

Grub discourages users who have tried sd-boot from
coming/returning
to
Fedora [1].

Bottom line I think this will be a good move for the distribution
and
a
good time to start looking into and make that move.

JBG

1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/

I read the whole reddit link, but I couldn't understand what's
wrong
with grub. The poster admits to having an obsession with keeping
the
number of packages to a minimum (I don't know what that has to do
with
grub), and doesn't like grub for some unexplained reason. Note that
I
have never used sd-boot. So far, I've used LILO (starting with Red
Hat
Linux 5.0), grub1 and grub2. These days, I don't even notice the
boot
loader. This means it's doing its job properly. :)

Maybe I should try sd-boot in a UEFI VM and see for myself, but can
someone explain what's the difference?

I have one system where I run Fedora Server in UEFI mode and I
haven't
ever had the need to mess with the bootloader. It just shows its
menu
for 5 seconds and that's all that it does. I don't understand how
can
something like that discourage a user from using Fedora? :)

Given that you have not changed an entry in your boot loader for
quite
sometime or perhaps ever it would actually be better that you
yourself
setup Fedora using sd-boot as the boot manager and compare changing
an
configuration entry in sd-boot with doing the exact same thing in
Grub2
and share your feedback and experience of doing so with the rest of
the
community rather then someone provide you with an answer.

I would try it, but I don't know how, since Fedora uses GRUB2. Should I
install ArchLinux in a VM or is there a way to try it with Fedora? Is
there any documentation for how to install it and how to use it?


Good point

I was not planning on doing that until I had some feedback on how big of 
scope this could turn out to be but I see if I cant setup a minimal test 
image you can build locally with mkosi and write some documentation. 
It's almost 23:00 here so it wont be until tomorrow.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 21:14, nick...@gmail.com wrote:

On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote:


Grub discourages users who have tried sd-boot from coming/returning
to
Fedora [1].

Bottom line I think this will be a good move for the distribution and
a
good time to start looking into and make that move.

JBG

1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/

I read the whole reddit link, but I couldn't understand what's wrong
with grub. The poster admits to having an obsession with keeping the
number of packages to a minimum (I don't know what that has to do with
grub), and doesn't like grub for some unexplained reason. Note that I
have never used sd-boot. So far, I've used LILO (starting with Red Hat
Linux 5.0), grub1 and grub2. These days, I don't even notice the boot
loader. This means it's doing its job properly. :)

Maybe I should try sd-boot in a UEFI VM and see for myself, but can
someone explain what's the difference?

I have one system where I run Fedora Server in UEFI mode and I haven't
ever had the need to mess with the bootloader. It just shows its menu
for 5 seconds and that's all that it does. I don't understand how can
something like that discourage a user from using Fedora? :)


Given that you have not changed an entry in your boot loader for quite 
sometime or perhaps ever it would actually be better that you yourself 
setup Fedora using sd-boot as the boot manager and compare changing an 
configuration entry in sd-boot with doing the exact same thing in Grub2 
and share your feedback and experience of doing so with the rest of the 
community rather then someone provide you with an answer.



Thanks

  JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 19:22, Robbie Harwood wrote:

Jóhann B. Guðmundsson  writes:


On 30.6.2020 17:49, John M. Harris Jr wrote:

On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.

This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?


Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting

And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon.

The first step ( The actual change proposal ) would simply be about
replace grub2 with sd-boot for UEFI strictly on the x86 architecture
which has UEFI available and enabled ( is not using legacy bios ) and
see what issue are encountered, solve those then consider moving to
different architectures and further integration if relevant etc. (
baby steps ) Next I would suggest looking at UEFI supported ARM
systems ( but I personally would have to obtain such hardware before
doing so ).

But... why?  It's not like grub2 doesn't work for booting UEFI.  Doesn't
seem like there's a point in running through all the issues that grub2
already solved again.


I think we put different meaning in maintainance,usability and issues if 
you think grub solves anything but I mentioned this elsewhere in the 
thread and justification/selling points usually end up on the change 
proposals but I'll repeat it here ;)


sd-boot is already installed on end users system, is light weight 
compared to Grub ( sd-boot only supports uefi,smaller code size, easier 
to maintain ).


It already integrates with the service management framework (systemd).

More user friendly than Grub ( has lilo like interface easier to change 
kernel entry, which goes nicely with the default editor change )


Gnome related changes such as Hans is proposing might be easier to 
integrate for the desktop team ( less work, problem being fixed where it 
arguably should be as opposed to systemd,grub and gnome for his feature 
to work and more future proof work for the desktop team).


Could help further adapt UEFI and secure boot which the industry is 
moving towards which helps keep Fedora moving along with it.


If correctly implemented ( baby steps and without excluding anyone) 
should be a win win for Fedora, developers and end users alike.


Grub discourages users who have tried sd-boot from coming/returning to 
Fedora [1].


Bottom line I think this will be a good move for the distribution and a 
good time to start looking into and make that move.


JBG

1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 18:32, John M. Harris Jr wrote:

On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote:

On 30.6.2020 17:49, John M. Harris Jr wrote:

On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.

This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?

Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting

And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon.

The first step ( The actual change proposal ) would simply be about
replace grub2 with sd-boot for UEFI strictly on the x86 architecture
which has UEFI available and enabled ( is not using legacy bios ) and
see what issue are encountered, solve those then consider moving to
different architectures and further integration if relevant etc. ( baby
steps ) Next I would suggest looking at UEFI supported ARM systems ( but
I personally would have to obtain such hardware before doing so ).

JBG

Why do you prefer sd-boot over GRUB2? I don't understand how you'd boot from
an SD card on most x86 hardware. ;)

Jokes aside, what's the call for the preference of even more systemd bloat? Do
we not have enough yet?

sd-boot is already installed on end users system, is light weight 
compared to Grub ( sd-boot only supports uefi,smaller code size, easier 
to maintain ).


It already integrates with the service management framework (systemd).

More user friendly than Grub ( has lilo like interface easier to change 
kernel entry, which goes nicely with the default editor change )


Gnome related changes such as Hans is proposing might be easier to 
integrate for the desktop team ( less work, problem being fixed where it 
arguably should be as opposed to systemd,grub and gnome for his feature 
to work and more future proof work for the desktop team).


Could help further adapt UEFI and secure boot which the industry is 
moving towards which helps keep Fedora moving along with it.


If correctly implemented ( baby steps and without excluding anyone) 
should be a win win for Fedora, developers and end users alike.


Grub discourages users who have tried sd-boot from coming/returning to 
Fedora [1].


Bottom line I think this will be a good move for the distribution and a 
good time to start looking into and make that move.


JBG

1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 18:45, Reindl Harald (privat) wrote:

Am 30.06.20 um 20:29 schrieb Jóhann B. Guðmundsson:

On 30.6.2020 17:49, John M. Harris Jr wrote:

On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.

This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?


Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting

And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon

you are the one talking about "why Fedora should still continue to
support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead"

sd-boot requires the kernel and initrd on FAT32 - creep away until you
realized about grub2 even support UEFI

if someoen with a @redhat.com email would have come up with your inital
mail you would have cried fire and conspirancy

to be honest: what is worjng with you?


I was in contact with Hans who is a Red Hat employee and the owner of 
the change proposal whom I reference in my original post to the list 
privately prior to me posting my question to the list in which he 
himself encourage me to go ahead and propose Fedora x86 UEFI installs to 
sd-boot if I was up for it along with another Red Hat employee who was 
relevant to our discussion so I have no idea what you are referring to.




to be clear: if you again refelct a private message on a public forum i
will seek you and i will find you - if you want sue me, but in private!


The best way to deal with individuals like you who are threatening 
people behind the scene, is exposing them, something that I should have 
done when I managed the sysv to systemd feature in Fedora and ask again 
like I did last time you how many mails like this do you send privately 
to persons inside and outside of the Fedora community everyday?


That said I first and foremost suggest you seek help and familiarize 
yourself with Fedora's code of conduct [1] and strongly encourage the 
entity within the Fedora community to take a close look at this.



JBG

1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 17:49, John M. Harris Jr wrote:

On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.

This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?

Such proposal would never be about stop supporting older hardware that's 
just a misconception people are getting


And it's quite evident by the response here that hw that is atleast 2010 
and older is still quite happily being used and that hw does not support 
UEFI and no one is talking about taking that away anytime soon.


The first step ( The actual change proposal ) would simply be about 
replace grub2 with sd-boot for UEFI strictly on the x86 architecture 
which has UEFI available and enabled ( is not using legacy bios ) and 
see what issue are encountered, solve those then consider moving to 
different architectures and further integration if relevant etc. ( baby 
steps ) Next I would suggest looking at UEFI supported ARM systems ( but 
I personally would have to obtain such hardware before doing so ).


JBG



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 17:47, Robbie Harwood wrote:

Jóhann B. Guðmundsson  writes:


On 30.6.2020 13:56, Igor Raits wrote:

On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only
supported boot which has been available on any common intel based
x86 platform since atleast 2005.

Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class
3 and above as in it would remove legacy BIOS support from its
client and datacenter platforms by 2020 and one might expect AMD to
follow Intel in this regard.

So Intel platforms produced this year presumably will be unable to
run 32-bit operating systems, unable to use related software (at
least natively), and unable to use older hardware, such as RAID HBAs
(and therefore older hard drives that are connected to those HBAs),
network cards, and even graphics cards that lack UEFI-compatible
vBIOS (launched before 2012 – 2013) etc.

This post is just to gather feed back why Fedora should still
continue to support legacy BIOS boot as opposed to stop supporting
it and potentially drop grub2 and use sd-boot instead.

Share your thoughts and comments on how such move might affect you
so feedback can be collected for the future on why such a change
might be bad, how it might affect the distribution and scope of such
change can be determined for potential system wide proposal.

I think there are many people still install OS in the legacy mode,
but I don't really have numbers. One thing we should definitely do if
we deprecate legacy BIOS is to properly warn users that still use
this configuration, develop tooling for them if possible for
migration and do not allow upgrades that will simply break their
system.

The use of legacy or uefi are changes that users have to manually
change themselves in their bios from manufactures default
settings. There is no tool that can do that for them or migrate those
settings however users should be able to change this for hardware
around 2010.

The Installer would have to try to detect and make a choise sd-boot (
If settings equall UEFI ) or grub2 ( If setting not equals UEFI )
depending on it's results.

As an example here's the BIOS/UEFI history for Apple hardware.

2012 and older models only support legacy BIOS Mode

2013-2014 models support both EFI and BIOS with the default setting
being set on BIOS

2015 and later models only support EFI

Different manufacturers have different timelines and different default
settings but I think it's safe to presume from this year onwards they
will all drop the legacy support and default to UEFI.

I don't think it contradicts your point that "this stuff is really
complicated", but my desktop is a 2009/2010 MacPro 4,1 running Fedora
booted using EFI.  (I didn't ask it one way or the other - this is how
anaconda installed it for me.)



I was bit surprised by this given that I got that EFI Apple integration 
timeframe from the OS-X forum but further digging through Apple 
documents has revealed that UEFI has been supported since 2006 on Mac 
computers with an Intel-based CPU [1]. So Anaconda did the right thing ;)


JBG


1. https://support.apple.com/en-is/guide/security/seced055bcf6/web
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 17:15, Gerd Hoffmann wrote:

   Hi,


So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.

Right.

Preferably the installer should detect and setup the system either with
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )

I have my doubts that building on sd-boot and drop grub2 is going to fly.


Grub 2 cant be dropped anytime soon.



One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).


Hmm I dont follow people usually use multiple ESP partition for multiple 
os installs on the same hw so the size of one esp partion for one OS 
should not affect the other and there should nothing be preventing that 
from working except maybe some obscure hw bug from manufactures but I'm 
not a dual boot person so I would have to test that for myself to figure 
out any limitations it might have.




Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?


The first step ( change proposal ) would simply be about replace grub2 
with sd-boot for UEFI strictly on the x86 architecture and see what 
issue are encountered, solve those then consider moving to different 
architectures and further integration if relevant.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 14:27, Daniel P. Berrangé wrote:

On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote:

* Jóhann B. Guðmundsson:


Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only supported
boot which has been available on any common intel based x86 platform
since atleast 2005.

Even for virtualization?  Not sure if that can be done.

KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
built from the edk2 project from a technical POV.

The first challenge will be that many mgmt tools still default to
using legacy BIOS when deploying guest OS. We've been trying to
make it easier for mgmt apps to "do the right thing" by having
libosinfo record metadata about whether each guest OS supports
legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
EFI if they see the OS doesn't support legacy BIOS, instead of
requiring users to manually tell them to use EFI.

Historically we've tended to discourage use of EFI on virt because,
unless you wanted SecureBoot for your VMs, it hasn't offered much
in the way of compelling benefits to users. The EDK2 project code
is a much higher maint burden for virt than the seabios was, and
there's no sign that situation will improve.

So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.



Right.

Preferably the installer should detect and setup the system either with 
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI 
) and other tools do the same and all areas deal with any fallout that 
is encountered ( bugs ) before a complete removal could be done so a 
realistic timeframe for a complete removal of legacy support would be 
F36+ I would say but we have to start prepare for the inevitable and 
start sometime and now is as good time as any to start looking into this.



JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 14:18, Tom Hughes via devel wrote:

On 30/06/2020 14:56, Igor Raits wrote:


I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.


Certainly until very recently I have tended to do legacy BIOS installs
even on new machines - it's only really in the last few months that I've
started using UEFI by default instead.



Well I would urge everyone to switch that know and can switch since 
fwupd can only use the UEFI runtime services to schedule system firmware 
update when running in UEFI mode.


In legacy BIOS mode it can only do USB type updates of peripherals.




I assume that we're only talking about new installs here anyway. 



Right


I'm
pretty sure switching an existing install would be something for
advanced users only and might not really be possible in many cases
due to the need to fine space for an EFI system partition.


Yeps

jBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

On 30.6.2020 13:56, Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote:

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot
which
has been available on any common intel based x86 platform since
atleast
2005.

Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client
and
datacenter platforms by 2020 and one might expect AMD to follow Intel
in
this regard.

So Intel platforms produced this year presumably will be unable
to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs),
network
cards, and even graphics cards that lack UEFI-compatible vBIOS
(launched
before 2012 – 2013) etc.

This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.

Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might
be
bad, how it might affect the distribution and scope of such change
can
be determined for potential system wide proposal.

I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.


The use of legacy or uefi are changes that users have to manually change 
themselves in their bios from manufactures default settings. There is no 
tool that can do that for them or migrate those settings however users 
should be able to change this for hardware around 2010.


The Installer would have to try to detect and make a choise sd-boot ( If 
settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending 
on it's results.


As an example here's the BIOS/UEFI history for Apple hardware.

2012 and older models only support legacy BIOS Mode

2013-2014 models support both EFI and BIOS with the default setting 
being set on BIOS


2015 and later models only support EFI

Different manufacturers have different timelines and different default 
settings but I think it's safe to presume from this year onwards they 
will all drop the legacy support and default to UEFI.


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

The future of legacy BIOS support in Fedora.

[Jóhann B . Guðmundsson]

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes 
it beg the question if now would not be the time to stop supporting 
booting in legacy bios mode and move to uefi only supported boot which 
has been available on any common intel based x86 platform since atleast 
2005.


Now in 2017 Intel's technical marketing engineer Brian Richardson 
revealed in a presentation that the company will require UEFI Class 3 
and above as in it would remove legacy BIOS support from its client and 
datacenter platforms by 2020 and one might expect AMD to follow Intel in 
this regard.


So Intel platforms produced this year presumably will be unable to run 
32-bit operating systems, unable to use related software (at least 
natively), and unable to use older hardware, such as RAID HBAs (and 
therefore older hard drives that are connected to those HBAs), network 
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched 
before 2012 – 2013) etc.


This post is just to gather feed back why Fedora should still continue 
to support legacy BIOS boot as opposed to stop supporting it and 
potentially drop grub2 and use sd-boot instead.


Share your thoughts and comments on how such move might affect you so 
feedback can be collected for the future on why such a change might be 
bad, how it might affect the distribution and scope of such change can 
be determined for potential system wide proposal.



Regards

 Jóhann B.


1. 
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 21:44, Solomon Peachy wrote:

"retired" tells you nothing more than "no longer packaged".

"packaged" does not mean "maintained by fedora".  It certianly doesn't
mean "kept up to date with upstream releases" or "kept updated with
security fixes"

And "broken" in this context means nothing more than "failed to
package/build", because "packaged" doesn't mean "it actually
works/runs".


The solution to this problem should be quite evident and that is to 
archive the "retired" components as flatpaks ( if the component is a 
desktop app ) or a as container ( if it's a server application or 
application stack ) using OCI Images and the OCI distribution mechanism 
as a deployment technology( for organization ) that is if the 
application or application stack is of any real, practical or nostalgic 
value to end users or organization which would be worth keeping.


That approach should solve both the package management issues and "if it 
ain’t broken, don’t touch it" or simply keeping it available because 
it's useful to some end user(s) dilemma along with bunch of other 
problems that affect Fedora but people seem to be expecting different 
results using the same old thinking, which lead to the same old 
approaches, to solve the same old problems.


JBG

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 20:22, Gerald Henriksen wrote:

Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.


Unless the process and the approach of "If it builds let's ship it" has 
not been changed over the years then the end user might be getting a 
package that is not actually being maintained in the distribution thus 
already is a security risk ( without it being flagged retired ) to begin 
with so arguably that problem needs to be solved first or at the same 
time as this.


I think people first need to establish what perception and thus meaning 
people put in the words retired,broken,maintained etc. before the proper 
course of action can be taken.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 12:21, Kamil Paral wrote:


I'd like Fedora systems to be transparent and honest. If some packages 
need to be removed, tell me about it, and ideally also tell me why 
(e.g. no longer maintained). If possible, tell me how to avoid it 
temporarily (it might be months or years, but unmaintained software 
will break one day unexpectedly), but be clear about the consequences. 
For general users, this information might involve just "important" 
packages (not libraries etc) - we don't do this well at present.
This approach beats "never ever removing anything, at any cost", at 
least for me.


I whole heartedly agree with your take on this but Kevin concerns are valid.

Based on my experience pushing Fedora as an Fedora ambassador to novice 
end users ( subsequently having to install/setup/and support their 
installation as a result of that ), it was enough for the desktop team 
to rearrange locations of apps in menus to scare novice end users away 
from *using* Linux ( yes not just Fedora but Linux altogether ) and them 
wanting to use windows or os-x again, something that they were 
*familiar* with and did not constantly keep changing ( which is why 
Microsoft had to reluctantly keep the old look and feel of Windows ) And 
I know first hand that the Gnome community in Fedora has never gotten 
this right because seemingly trivial changes like tidying up menu's are 
huge changes to the novice end users that operate on familiar look and 
"click here" memory.


To me this is a question of what is Fedora target audience.

It cant be novice end users since those cant install Fedora and afaik 
people cant buy hw with Fedora pre-installed and even if that option was 
available for the novice end users you would have to be a pretty good 
sales person to convince them to abandon something they are familiar 
with ( talking from a first hand experience doing exactly that ) as in 
windows or os-x. ( Arguably there always has been and still is the 
underlying expectation that Fedora users are atleast somewhat familiar 
with Linux and RHEL, basically RHEL administrators I would say )


This is also a question of what constitutes as an "unmaintained 
software" in the distribution. Is it dead upstream, is it awol package 
maintainer, is it poorly maintained packages like the maintainer that 
only appears when there is a pending RHEL release then disappears, is it 
not responding to bugs filed against his or her component etc.


But the act of removing an unmaintained application/package in the 
distribution wont scare people away from using Fedora no more than ( 
even trivial by every count ) changes that the Gnome community has 
historically done in the distribution thus a less of an issue that Kevin 
makes it out to be and leaving something installed on end users system 
can do more harm than good I would say.


Presumably this is also less of an issue as end users stop installing 
application from the distribution but instead do so with flatpaks and at 
one point application will no longer be provided in the distribution ( 
you have to install it from flatpak marketplace).


Just my 2 cents.

JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jóhann B . Guðmundsson]

On 10/06/2016 03:27 PM, Adam Williamson wrote:

On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote:

So I like the idea, I do propose to simply re-use most of
the blocker bug process for this, rather then inventing yet
another process. I guess this could even be integrated and
the way to get bugs on the list would be to propose them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.

Let me phrase my earlier objection a little more strongly and
personally:

If someone tries to make me spend another three damn hours a week
reviewing 'proposed critical bugs' I'm going to jump out a window and
go start that yak farm. You won't see me for dust.


Interesting to see that now the person responsible for adding additional 
load on the QA community want's to jump out of windows after doing so. 
You reap what you sow...


As I mentioned sometime back in my QA days, QA should just take care of 
the installer/core/baseOS, then each sub community that delivers an 
product of some sort into the hands of an end users needs to take care 
of QA-ing it itself for whatever it builds on top of that and arguably 
the rest of the release process for that product.


Then the release process needs to be scaled from supporting just a 
single product ( which has never reflected what the community has ever 
done since there have always been more then one product in circulation 
from the community )  designed in such manner that product A cant block 
product B or C or F.


I have never understood this whole attitude of always putting all the 
load on QA and Releng which has never had any resources to effectively 
manage it for everybody to begin with.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jóhann B . Guðmundsson]

On 09/18/2016 10:16 PM, Jeff Fearn wrote:


Hi, we might be able to extend the External Trackers extension in RH Bugzilla 
to be able to create as
well as sync bugs.


Between which issue trackers is that supported?

JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24, small backward steps

[Jóhann B . Guðmundsson]

On 09/13/2016 04:41 PM, Bastien Nocera wrote:



- Original Message -


- Original Message -

I'm seeing 24 bugs at:
https://apps.fedoraproject.org/packages/fprintd/bugs/all
including a potential security one: https://bugzilla.redhat.com/1333882

Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
that abundantly clear I think.

I said "garbage fire" when I meant "tire fire". It keeps on burning and I'm
too lazy/busy to handle those bugs downstream when the majority of the work,
triaging and discussions happen upstream.


From the reporters point of view their distribution is seen to them as 
"upstream" so they don't want to run around the internet chasing down 
bug trackers ( which they should not have to do if the distribution 
package maintainers are doing their due diligence ).


From upstream point of view their issue tracker the point of origin and 
they dont want to be chasing down bug trackers in those gazillion 
downstream distribution using their application or application stack ( 
which again they should not have to do if the distribution package 
maintainers are doing their due diligence ).


So basically your are just seeing two sides of the same problematic coin.

And this problem remains unsolvable while bug trackers and policy 
surrounding them is so fragmented in the linux ecosystem.




I should also note that the Red Hat bugzilla is far too coarse for handling
split-up projects like gnome-control-center and gnome-settings-daemon, both of
which are connected to multiple system layers (the kernel, systemd, a lot
of specialised daemons, windowing systems, and their dependencies) and which
have separate maintainers upstream.


Could not agree more.

Mozilla bugzilla is horrific tool in using and trying to resolve this 
issue and even if it was not, it cannot be improved to be made even 
remote usable issue tracker in this scenario due to it not being Fedora 
only.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jóhann B . Guðmundsson]

On 09/14/2016 05:46 PM, Matthew Miller wrote:


What I'd_really_  love to see is a layer separating bug trackers from
end users.


That layer already exist in the form of irc forum and askbot does it not?
( someone from the support sub-community can provide information how 
successful these are )


And from my former QA days I cant recall that end users issues being 
mistakenly reported in bugzilla existed in the first place or was a 
problem for that matter.
( The steps that are necessary to file a report to begin with, act as a 
natural filter that prevents that from happening )
I'm only aware of one bug ( arguably misfiled ) against systemd in the 
distribution that might fall under that category but that is entirely 
due to the fact those changes slipped through the distribution 
documentation and announcement radar ( which arguably should have been 
covered in Gnome ) so end users/administrators simply dont know how they 
are custom to configure things does not work in certain scenarios with 
certain components.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream

[Jóhann B . Guðmundsson]

On 09/14/2016 05:03 PM, Jason L Tibbitts III wrote:


"RC" == Ralf Corsepius  writes:

RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.

A package with a million users is going to get more bugs than a package
with ten regardless of the package quality.  I have a feeling that a
rather large number of people use Gnome.


Most of them would be duplicates ( otherwise Gnome is in serious trouble 
maintenance wise )


When I was exclusively triaging reports against a single components 
systemd for couple of years the report classification was roughly one 
third real bugs, one third RFE's and one third misfiles.
With my former QA hat on and thus involved in the triage process from 
it's inception as well as being the last person along with Mike Ruckman 
( afaik no one else has done it since then)  looking into if the triage 
process could be revived for what the fourth time  I think I can say 
without a shadow of doubt that triaging will never work in the 
distribution due to wide variety of reasons which I will not go into 
details in this response. ( Triaging can be made to work to certain 
extent but not here in Fedora )


In the end of the day it's packager maintainer(s) responsibility to act 
as the liaison between upstream and downstream, triage, test and forward 
bugs upstream if they are not distribution specific and solve them 
downstream if they are.


If the package maintainer does not have the time to do that he or she 
needs to find more co-maintainers to distribute the load of him or 
herself or drop the maintenance of the package in the distribution 
altogether and hope that someone else that has the required time steps 
up to maintain it but that is unlikely if he or she could not find 
co-maintainer(s) to begin with in the distribution to distribute the load.


If the above as in package maintainer(s) for whatever reasons will not 
perform their due maintenance diligence then there is but two 
alternative and that's to drop the poorly maintained packaged ( since 
it's doing the distribution end user disservice ) or redirect reporters 
directly upstream but that has it's own set of pros and cons.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jóhann B . Guðmundsson]

On 09/14/2016 02:44 PM, Jason L Tibbitts III wrote:


I disagree in general; when the bug volume exceeds a certain amount
bugzilla basically becomes useless.  However, it would be really nice if
_someone_  looked at RH bugzilla for those packages and did something
with them.


This responsibility falls under those individuals that have signed 
themselves up with maintaining the component(s) in question in the 
distribution and call themselves "package maintainers"...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: My experiences with KillUserProcesses=yes on F24

[Jóhann B . Guðmundsson]

On 08/31/2016 02:25 PM, Jason L Tibbitts III wrote:

More appropriate place would be to post this upstream either on the 
mailinglist and or as an bug/rfs in the tracker so this issues can be 
addressed properly.


Lingering is a per-user thing so it probably ends up being an per user 
opt in feature/fix


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

[Jóhann B . Guðmundsson]

On 08/02/2016 10:23 AM, Simo Sorce wrote:


I do not actually have to prove anything, in a welcoming community you
give the beneit of the doubt that people researched and know what they
are talking about and you stick to actual fact in whatever they produce,
not to some badge of credentials that can be publicly displayed.

For what I know Jon may have done hundreds of migrations in private.


Or he has done zero.


And FYI Red Hat employees are not only here to contribute but apparently
they also exist here in this community to threaten to out people from
the project if they don't suck up to the Red Hat desktop team.

Perhaps that's just Fedora/Red Hat conference thing.
Please grow up a bit.


Good to know the Red Hat corporate stance that community members that 
have been subjected to bullying by Red Hat employees should "grow up a bit".


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

[Jóhann B . Guðmundsson]

On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote:


It's a burden, usually solved by ignoring one or the other. Since
systemd is always incompatible and always will be incompatible with
anything but relatively modern Linux distrubitutions, guess which
packages never get ported to non-Linux systems.


Actually in many cases upstreams that are targeting different types of 
*nix dont ship initscripts et all but instead have downstream ship those 
instead as an upstream policy ( we had few rejection of type unit files 
from upstream based on that ) so I'm unsure how much of a burden that 
really is.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

[Jóhann B . Guðmundsson]

On 08/02/2016 09:24 AM, Simo Sorce wrote:

On Tue, 2016-08-02 at 09:11 +, Jóhann B. Guðmundsson wrote:

On 07/31/2016 06:29 AM, Parag Nemade wrote:


Kevin has already given a detailed information how longer it took to
retire these packages. Also see this
https://fedoramagazine.org/systemd-converting-sysvinit-scripts/

Take that article with a grain of salt since it's written by somebody
that has not  done any real migration to any extent.

Jóhann,
if there is a factual error in the article point it out, this sniping at
people implying they do not know what they are doing and FUD is really
not welcome in a community, we are all here to contribute.



This article is meant to be about migration and to be able to write such 
article you need to have migrated quite few initscripts so please point 
me to the actual work that the writer has done in that regard.


Then you can cut FUD crap and if you need factual error then the line 
about EnvironmentFiles should not have been mentioned since it should 
not exist in type unit files and if everything would have gone as 
planned an feature would have already been submitted and they cleaned 
out from the distribution at this point in time along with quite few 
other things that got "obsoleted" with systemd.


And FYI Red Hat employees are not only here to contribute but apparently 
they also exist here in this community to threaten to out people from 
the project if they don't suck up to the Red Hat desktop team.


Perhaps that's just Fedora/Red Hat conference thing.

JBG

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

[Jóhann B . Guðmundsson]

On 07/31/2016 03:18 AM, Sérgio Basto wrote:


why such hurry ?


There has been a more than enough time for this migration to happen 
already and now it's existence has started to hinder other changes and 
adoptions in the distribution.


The initial target was for the feature completion was F20 or two years 
for every component in Fedora with an average migration time of 4 hours 
per components including changes to spec files and ( minimal ) testing ( 
and this was done with real submitted work not drive by maintainers 
tagging expecting the components maintainers to do the work for them ) 
but it came immediately clear what would prevent that from happening in 
F15 when we started the migration ( we started it in F14 ) and that was 
package maintainers ( mostly due to same 4 or 5 reasons ) not the 
migration process itself then idiotic decisions making by FESCo and 
bottlenecks in the FPC process itself added additional delays to that 
and other systemd integration work.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

[Jóhann B . Guðmundsson]

On 07/31/2016 06:29 AM, Parag Nemade wrote:


Kevin has already given a detailed information how longer it took to
retire these packages. Also see this
https://fedoramagazine.org/systemd-converting-sysvinit-scripts/


Take that article with a grain of salt since it's written by somebody 
that has not  done any real migration to any extent.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2016-07-15)

[Jóhann B . Guðmundsson]

On 07/15/2016 05:19 PM, Josh Boyer wrote:


   * AGREED: FESCo approves KillUserProcess=yes by default with the steps
 sgallagh has proposed in the ticket (+7, 0, 0)  (jwb, 17:04:58)


"Tier 1 packages must be ported to support operation under 
KillUserProcesses=yes"


Is it safe to assume that FESCo members will do all the porting since 
they where the ones that proposed, decided and agreed upon that condition?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Jóhann B . Guðmundsson]

On 06/06/2016 03:56 PM, Benjamin Kreuter wrote:

  It took me three days to find the problem the last time systemd caused
unexpected behavior on my system.


What was this hard to find unexpected behaviour you encountered?

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Jóhann B . Guðmundsson]

On 06/02/2016 03:13 PM, Stephen Gallagher wrote:


I don't think we need to change Fedora 24 for this. Unless I misunderstood, this
systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
prepping for how to deal with things in Fedora 25.


You should not so easily dismiss and rule out core/baseOS ( and even 
other ) components adapting similar or same updating rebase scheme as 
the kernel community is using as ( and has prove to be working ).


There where upcoming changes in systemd that prevented this back in 2013 
when I wrote this [1] proposal and we discussed it but those road blocks 
are no more afaik hence there is nothing preventing systemd from 
adapting an rebase scheme similar/same to the one that the kernel 
community is using.


JBG

1. 
https://fedoraproject.org/wiki/User:Johannbg/Systemd/systemd-rebase#DRAFT_Systemd_Rebasing

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Jóhann B . Guðmundsson]

On 06/01/2016 02:01 PM, Josh Boyer wrote:


Given the principle of least surprise, it would make more sense to
default with this being disabled out of the box.


I have to disagree with this statement.

Upstream should always reflect how things should be while downstream 
reflects how things are or atleast how things are in relevance to them 
since these things can deviate by factor of how many different 
downstream sources there are.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Kernel plans for Fedora 24

[Jóhann B . Guðmundsson]

On 05/17/2016 05:25 PM, Chris Murphy wrote:


I refuse the premise that the kernel team is going to release a 4.6.x
kernel that isn't ready as a 0 day update.


There is more extensive testing performed before GA release then there 
is in the update process hence what get's shipped in the GA release has 
better testing coverage regardless of people believes in Red Hat's 
kernel team hence it's better to ship the 4.6 in the final then to 
deliver it as an 0 day update.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Jóhann B . Guðmundsson]

On 05/17/2016 04:32 PM, Till Maas wrote:

Your argument sounds like yum.repos.d would be the best name for the
repo definitions that are recognised by the yum parser and other
implementations for this format.


More accurate and more distro agnostic would be system like rpm or npm etc >.repos.d or >.repos.d not package management like yum, dnf, zypper etc could all 
use that repository directory if that would be the case


repos.d is to generic.

It's going to be interesting to see if fesco will be consistent in their 
previous decision making or Red Hat NIH software of zypper will get the 
special Red Hat corporate treatment from them.


JBG

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Kernel plans for Fedora 24

[Jóhann B . Guðmundsson]

On 05/17/2016 04:32 PM, Chris Murphy wrote:

On Tue, May 17, 2016 at 8:57 AM, Jóhann B. Guðmundsson
<johan...@gmail.com> wrote:


On 03/16/2016 04:01 PM, Justin Forbes wrote:

With the 4.5 kernel out and the merge window for 4.6 opened up, we had
to make a decision on what the release kernel for F24 would be.  The
decision has been made to ship F24 with the 4.5 kernel with 4.6
available as an update once it is ready.  Timing wise, 4.6 *should*
release just before the final freeze for F24, but that is cutting it
insanely close. Should Fedora move on as scheduled, and 4.6 have some
delay due to a bug that impacts users, that would be unfortunate.
This means we have a good bit of time to make sure that everything is
working as intended with 4.5 in Fedora.  It also means that any
installer critical fixes will need to be backported to 4.5.


Given that 4.6 is out and current F24 final freeze is not scheduled until
2016-05-31 should not F24 be released with the 4.6 kernel?

I think the original logic is still sound. There have been three
delays for Fedora 24 already, in the original schedule today was to be
GA. I don't think it's worth any risk for another slip.



So you prefer not catching potentially any bugs before final GA release 
but rather expose them to the end users through 0 day update instead?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Jóhann B . Guðmundsson]

On 05/17/2016 02:48 PM, Lukas Zapletal wrote:

With a symlink /etc/yum.repos.d to it.


And for other type repository's
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Kernel plans for Fedora 24

[Jóhann B . Guðmundsson]

On 03/16/2016 04:01 PM, Justin Forbes wrote:

With the 4.5 kernel out and the merge window for 4.6 opened up, we had
to make a decision on what the release kernel for F24 would be.  The
decision has been made to ship F24 with the 4.5 kernel with 4.6
available as an update once it is ready.  Timing wise, 4.6 *should*
release just before the final freeze for F24, but that is cutting it
insanely close. Should Fedora move on as scheduled, and 4.6 have some
delay due to a bug that impacts users, that would be unfortunate.
This means we have a good bit of time to make sure that everything is
working as intended with 4.5 in Fedora.  It also means that any
installer critical fixes will need to be backported to 4.5.


Given that 4.6 is out and current F24 final freeze is not scheduled 
until 2016-05-31 should not F24 be released with the 4.6 kernel?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Jóhann B . Guðmundsson]

On 05/17/2016 02:14 PM, Honza Šilhan wrote:

there are a lot of good suggestions about the path name in the discussion.
`/etc/distro.repos.d` probably wasn't the best chosen path so we've changed
it to `/etc/repos.d` in the proposal. Moreover I've mentioned there possible 
path name
alternatives like /etc/software.repos.d, /etc/vendors.repos.d, /etc/rpm.repos.d,
/etc/rpm-md.repos.d, /etc/system.repos.d. The type of the metadata format could
be defined by `type` option in the file itself like Suse does so we don't need
to have any specifier before `repos.d`.



You do realize that if you are going the "too generic route of repos.d" 
and change it to /usr/lib/repos.d ( as opposed to /usr/lib/rpm.repos.d ) 
then you need to add distinction in file name ending that might be used 
( - .conf ) or use a sub directory within that 
directory like repos.d/rpm which would contain foo.repo or something 
similar or have all package manager to use the same configuration file 
format for all package managers ( rpm,maven, npm, rubygems etc ) that 
migt end up using that "too generic" repos.d directory directly.


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Jóhann B . Guðmundsson]

On 05/12/2016 08:07 AM, Tomasz Torcz wrote:

On Thu, May 12, 2016 at 09:36:32AM +0200, Jan Kurik wrote:

= Proposed System Wide Change: Use /etc/distro.repos.d as default reposdir =
https://fedoraproject.org/wiki/Changes/ReposInEtcDistroReposD

Change owner(s):
* Neal Gompa 
* Jan Silhan 


== Detailed Description ==
For DNF 2.0 in Fedora 25, the DNF team would like to make the default
repository configuration directory /etc/distro.repos.d. In contrast to
/etc/yum.repos.d (current default path), /etc/distro.repos.d path is a
package manager agnostic name and less misleading. The configuration
files are currently used by DNF, PackageKit, and Yum. The proposed
location more accurately reflects the nature of the repositories, and
also implies that other tools can look there for repository
information. Note: current default repository configuration directory
/etc/yum.repos.d will still be supported by package managers but
/etc/distro.repos.d would be preferred default path.

   Shouldn't that be /usr/lib/distro.repos.d (for distribution-provided
data) with usual rules for overriding/masking in /etc/distro.repos.d (for
local administrator)?



More like /usr/lib/rpm.repos.d to be generic, distro and 3rd party 
agnostic but yeah this should reside there these days . . .


JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: No mass rebuild in Fedora 25

[Jóhann B . Guðmundsson]

On 05/02/2016 01:24 PM, Stephen Gallagher wrote:

There is strong engineering value in having two releases per year: release
early, release often. There are many projects that develop through Fedora that
get thrown into disarray when our cycle gets too far out of whack (prominent
examples being GNOME and glibc)


The distribution is made out of 14k+ components most of which of those 
components completely out of sync with the Gnome and Glibc one which 
means components that make up different products are not synced with 
those two components cycle, which means that you cannot have one 
product's release cycle be synced with another or bound to it's release 
cycle.


Even historically QA did not manage to deal with this release cycle when 
distribution was smaller and when it was just one "generic" release but 
despite all the evidence of this not working through the years you still 
push this one forward which means in other words Red Hat wants the 
distribution cycle to be forcefully synced with Gnome and does what it 
takes to do so which is why it's back on Gnome's release cycle despite 
everything indicating it should not be on that cycle at the cost of the 
community and quality of the distribution.


If there is genuine interest of start releasing fedora on time you will 
not achieve that goal by not doing or blocking mass rebuilds, you either 
need to stabilize anaconda development earlier in the cycle or find 
another installer for the distribution that can exist outside the 
distribution release cycles and does not have to be rewritten like 
people are getting paid for it every cycle.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: 4.4 rebase coming to F23 soon

[Jóhann B . Guðmundsson]

On 02/24/2016 05:22 PM, Laura Abbott wrote:

On 02/18/2016 05:51 PM, Laura Abbott wrote:

Hi,

4.4.2 is currently building and should be in updates-testing soon. As 
usual,

please test and give karma appropriately (negative karma for new issues,
not existing issues).

Thanks,
Laura


A use after free bug was found in the 4.4.2 release. Since those can 
cause
unexpected corruption and crashes, I elected to do another release. 
Please

test again and leave karma. Thanks again for testing.


Arguably the regression in 4.4 with drm/i915 that causes screen 
flickering in dual monitor setups needs to be looked at before this gets 
released since it will get tiresome quite quickly for end users trying 
to do some work when suddenly one of the screen turns itself off and 
then on again.


I'll test that release and see if it has been fixed.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unexpected NIC naming f23 firewall implications

[Jóhann B . Guðmundsson]

On 11/10/2015 06:06 AM, Tomasz Torcz wrote:

On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:

em* and p?p? come from biosdevname, which should not be used and is deprecated.

I'm merely observing what happened when I updated a bunch of servers
from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
at any point.

   But you should have.  Biosdevname what deprecated 3 years ago (with Fedora 19
or 20*), you should have migrated your rules to udev's naming scheme and
remove biosdevname.  This was quite long transition period, even longer
than biosdevname usage, which was default between Fedora 15 and 19 (2 years).

   * although I can't find the mention in Release Notes for neither F19 nor F20.
 We may have underdelivered on this :(



Biosdevname has not "officially" been deprecated ( still mentioned in 
the guidelines and still available for download ) and it only got 
removed from comps and Anaconda in F21 ( which is something that should 
have happened in F19 ) and up to that point it was still installed by 
default so machine upgrades from  F21 - F22 -  F23 will still 
have it, clean installs of F21+ should however not ( unverified ).


The WG's or any of the live CD's might still be deliberately shipping it 
( like the serverWG might think it was a good idea to ship it like they 
are still shipping rsyslog etc ) .


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Jóhann B . Guðmundsson]

On 11/08/2015 07:29 PM, Richard W.M. Jones wrote:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.

It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/


The p6p1 and em1 interface names come from ( Dells ) biosdevname not 
systemd and most likely the biosdevname component got removed on upgrade 
or superseded by other udev rules.


Arguably biosdevname component should have been obsoleted in F19 as a 
component and in Anaconda and Dracut when predictable network interface 
names got introduced with systemd in the distribution, to prevent these 
kind of surprises but here we are so "surprise" ...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Jóhann B . Guðmundsson]

On 10/09/2015 02:16 PM, Adam Jackson wrote:

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote:


>I agree - the new wording does appear to give in to poor programming
>practices.

Bundling is_not_  intrinsically poor practice.  Firefox is a good
example of this, there have been several cases where using the system
instance of cairo has been a regression relative to the bundled
version, because firefox relied on the internal details of how a
particular version of cairo worked, and a newer and ostensibly better
cairo would break those assumptions.

Maybe we can argue that firefox was wrong to make those assumptions.
Maybe we can argue that cairo wasn't living up to its own interface
contract.  Who cares?  The result from the consumer's perspective is
that bundling produces a working firefox, and unbundling produces a
broken firefox, so bundling is desirable.  From the firefox developers'
perspective, bundling allows them to ship a product that is known to
actually work, so bundling is desirable.

So from an OS maintenance perspective we have to recognize that
bundling code occasionally does have merit, and that it is incumbent on
us to manage it well.  And from a Fedora perspective, we have to
acknowledge that a prohibition policy ignores that reality, that we
have not consistently enforced it, and that we do ourselves and our
users a disservice to insist on it.


Interesting taking the consumer perspective.

So where does FESCo intend to draw the line now that it has chosen to 
head down this path.


For example is the next step for Fedora to dissociate itself with 
upstream and start implementing "workarounds" instead of fixing things 
where they belong to satisfy the end users needs and expectation as well?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 10/08/2015 12:31 AM, Kevin Kofler wrote:

Jóhann B. Guðmundsson wrote:

>Badges was supposed to be that carrot for the mule's so perhaps there's
>just missing new set of badges for this...
>
>1.https://badges.fedoraproject.org/

Those "badges" are completely useless as a reward


As real as any reward will ever get in a contributed driven community 
and as an means to "lead the mule" it most certainly does it's part all 
the way up to the point the contributor realizes he will never be able 
to collect all the badges.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 10/07/2015 11:21 PM, Stephen John Smoogen wrote:

On 7 October 2015 at 16:41, Kevin Kofler  wrote:

>Stephen John Smoogen wrote:

>>So the next step after that is that we reward people who lower a
>>package's point. Good idea Kevin.

>
>"Reward" how?
>

I was thinking of cookies, but I expect that some sort of system could
be put in place that would help promote moving stuff to less bundling.
Now I understand the whole just use a whip to beat the supposed
packagers into line bit. I don't agree with it, but I can understand
it. I just think that sometimes you need to use a carrot to get the
mule to walk.



Badges was supposed to be that carrot for the mule's so perhaps there's 
just missing new set of badges for this...


1.https://badges.fedoraproject.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/15/2015 08:41 AM, Ian Malone wrote:

On 14 September 2015 at 16:47, Jóhann B. Guðmundsson <johan...@gmail.com> wrote:


They simply have welcomed their new container overlords and are using only
the recommended upstream method for installing for their application (
pip,gem etc since developers can use the upstream support community for
those ) in those container images, followed by a strong attitude of use it (
their produced container/vm image not some downstream shipped/provided
"package" ) or "take your freedom of choice and get lost, we are done trying
to support and play the "X-factor of linux distributions" game. "

And once the "market" has ( started ) taken a stance ( moving away from
downstream provided package of their components since it does not work due
to the fragmentation in the linux ecosystem ) it's irrelevant what I think
or you think or distributions think or implement locally beside providing
the underlying structure to run their application for the sole purpose of
being relevant as an platform for deployment ( which today is basically any
distribution that ships systemd ).


Ultimately that is going to be self limiting, you can only do it while
the most fundamental components are playing by the old rules. I can
think of a few research software packages (in the sense of software
packages, not fedora packages) which are so tied to particular
underlying libraries that getting them to work in the same environment
is a real pain (various ones that bundle underlying libraries and have
their own setups that force that on the whole system because they
can't even get linking right). Now you can containerise that, but
eventually you are going to have to have containers within containers,
and somewhere in there will be a piece of rotting software.



It's self limiting with or without containers is it not? besides there 
is rotting piece of software littered all across the software galaxy 
even in Fedora so that's nothing new.
( which is to be expected for a distribution that has more components 
than the require manpower to maintain them properly, inefficient 
deprecation and clean up procedures etc. )


In the end containers wont solve all the world problems and there exist 
use cases outside it just as it was with virtualization but at the 
moment it's want the market wants.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/14/2015 02:18 PM, Stephen Gallagher wrote:

Also, I'd like to be clear on this: whatever the outcome of this
discussion, I want Fedora packagers to continue to work with their
packages and upstreams to unbundle as much as possible. I think that
this*does*  lead to significant improvements in security, resources
and maintenance. However, I also feel that making it a barrier to
entry is actively harming our ability to bring in new software and new
package maintainers. At which point I would argue that mandatory
unbundling is unhealthy for the Fedora*Project*  while it is clearly
healthy for the Fedora*Operating System*.


I would argue that we should not be packaging and shipping bundled 
components ourselves et all ( whatever they might be called, which 
effectively makes unbundling mandatory ) due to the increased load on 
the project as whole maintaining such bundles.


From patching, to bugs to license issue no matter how you look at it, 
with or without exceptions bundles will be wasting resources in the 
project, resources we dont have.


And FYI during what FC5 or FC6 we made it easier for individuals to add 
components to the distribution and take hard good look at what that has 
got us. Fedora has grown so fat it's collapsing under it's own weight.


Based on the resources we have, people seriously need to start asking 
themselves do we want Fedora to be shipping every know component in the 
universe chasing end users sitting at the end of the rainbow?
Is making it easier to add components to the distribution actually worth 
it and a good thing?


Anyway exceptions or not an clear cut policy surrounding bundles is 
necessary which outlines and explains to the maintainer of the bundle 
that he just signed himself up and is responsible to maintain the entire 
components that make up that bundleotherwise you have effectively added 
the load on already existing maintainers, an load they themselves did 
not sign themselves up to do. ( it's one thing maintaining a component 
in the distribution and it's another having to in addition to that 
maintain it in all bundled components as well )


JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/14/2015 07:08 AM, Josef Stribny wrote:

On 09/12/2015 12:41 AM, Jóhann B. Guðmundsson wrote:



On 09/11/2015 09:09 PM, Orion Poplawski wrote:

What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" 
and "pip

install ipython"?


This indeed is very good question.

I'm not sure how things are elsewhere in the world but in the case of 
gem's on a rock in the middle of the north atlantic ocean , everybody 
is using bundler with nobody wanting to go back to non existing or 
not current gem's in distributions and or having to manually chase 
down components and resolve their dependency's.


They prefer spending that time actually hacking or drinking beer or 
both.


JBG
I would argue that the most valuable thing apart from the security 
tracking is that you can properly specify _all_ dependencies the gem 
actually have. This is a big one for at least few reasons:


1, end-users don't have to go read README to know what to install so 
that the software actually starts working

2, avoids compilation errors due to the missing header files or conflicts
3, installation is faster and more predictable

If someone has a problem with installing a gem, he/she can install 
rubygem-* package on Fedora and it's done (they can easily combine 
them with upstream gems). It's also quite nice that a beginner can 
just dnf install some framework if he just want to quickly try/evalute 
it, but does not want to spend afternoon hunting installation issues. 
This seems less relevant for experience people, e.g. I know how to fix 
problems with Ruby, but when I need to do a little of Python work I 
prefer to install Fedora packages rather than trying to make pip work 
for me.


But generally there are other (small) things as well...you don't need 
to install any junk like -devel packages on your system, you can track 
all your software with rpm/dnf (e.g. you can rollback a transaction), 
the gem can come with man pages, etc.


Perhaps in the past that workflow you point out here above was relevant 
( to the "market" ) but people and companies ( here ) want to deploy 
Rails app to a container ( usually docker ) or a vm which has all of the 
app’s dependencies ( and they are using bundler for that application 
itself ) fully test the app in the container ( or a vm ), then ship the 
container ( or the vm ) to their production host(s) and or make 
available for their customers or the end users to use when they are 
ready and stick to supporting that container ( or vm ) image/setup only 
( which addresses completely your 1,2,3 points there )  not the 
gazillion linux distribution out there and their package management 
system and formats apt, ­ aptitude ­ dselect ­ ubuntu software 
center,dnf,yum,apt-rpm,poldek, up2date, urpmi, 
zypp,slapt­-get,slackpkg,zendo,netpkg,swaret,appbrowser,­ 
conary,equo,pkgutils,pacman ­ petget, ­ pisi,portage ­ smart package 
manager, steam,tazpkg, upkg ( and probably bunch of others that I have 
forgot to mention ) and the downstream distribution policy's that go 
along with them.


Sorry to say but developers and companies here ( perhaps elsewhere as 
well ), have had their fill with Linux, it's fragmentation and it's 
freedoom of choice and trying to support all that ( and I can fully 
understand them ).


They simply have welcomed their new container overlords and are using 
only the recommended upstream method for installing for their 
application ( pip,gem etc since developers can use the upstream support 
community for those ) in those container images, followed by a strong 
attitude of use it ( their produced container/vm image not some 
downstream shipped/provided "package" ) or "take your freedom of choice 
and get lost, we are done trying to support and play the "X-factor of 
linux distributions" game. "


And once the "market" has ( started ) taken a stance ( moving away from 
downstream provided package of their components since it does not work 
due to the fragmentation in the linux ecosystem ) it's irrelevant what I 
think or you think or distributions think or implement locally beside 
providing the underlying structure to run their application for the sole 
purpose of being relevant as an platform for deployment ( which today is 
basically any distribution that ships systemd ).


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 05:51 PM, Adam Williamson wrote:

On Fri, 2015-09-11 at 13:35 -0400, Stephen Gallagher wrote:


As for which components, it's not about specific examples[1]. It's
about solving the question in a generic way. We have quite a lot of
software that isn't packaged for Fedora (either not started or
aborted
when the package review couldn't be passed) that has genuine value.

I can certainly confirm that. I dug through quite a lot of review
requests yesterday to look at how the rules have been applied in
practice, and found several that have been abandoned because of
bundling issues. I'll just link one example -
https://bugzilla.redhat.com/show_bug.cgi?id=836810 - but it's trivial
to find more.



The inclusion of what now 15k components in the distribution is a 
testimony of success of un-bundling against your testimony of ( few ) 
failures of bundling.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 06:10 PM, Adam Williamson wrote:

On Fri, 2015-09-11 at 12:06 -0600, Kevin Fenzi wrote:

On Fri, 11 Sep 2015 10:51:42 -0700
Adam Williamson  wrote:


On Fri, 2015-09-11 at 13:35 -0400, Stephen Gallagher wrote:


As for which components, it's not about specific examples[1].
It's
about solving the question in a generic way. We have quite a lot
of
software that isn't packaged for Fedora (either not started or
aborted
when the package review couldn't be passed) that has genuine
value.

I can certainly confirm that. I dug through quite a lot of review
requests yesterday to look at how the rules have been applied in
practice, and found several that have been abandoned because of
bundling issues. I'll just link one example -
https://bugzilla.redhat.com/show_bug.cgi?id=836810 - but it's
trivial
to find more.

But by the same token, a great deal of upstream projects don't bundle
things and are just fine packaged up in Fedora.

I don't think anyone was advocating a policy that all packages must
have a minimum of 1 (one) bundled library ;)

I agree that the discussion here needs to be more broad-based; see the
other thread fork. I was just providing support for Stephen's
contention that this is not some airy-fairy theoretical problem, there
are multiple examples of real things that people *wanted* to have
packaged that are not packaged because the unbundling process was too
onerous.



Arguably that is a testament of how heavy the bureaucracy in the 
distribution has become not the "bundling" itself.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/10/2015 01:53 PM, Stephen Gallagher wrote:

I assume that subject line got your attention.

I know this is a long-standing debate and that this thread is likely
to turn into an incomprehensible flamewar filled with the same tired
arguments, but I'm going to make a proposal and then attempt to
respond to many of those known arguments up-front (in the hopes that
we can try to keep the conversation on-track).


Why are you continuing pushing this after this has been rejected what 
two or three times already?


What´s your end game here, which components do you so desperately need 
Fedora to ship bundled ( which exception could be made for instead ) and 
why cant RH just do this themselves with RHEL since obviously it needs 
otherwise you would not be pushing this so hard?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/10/2015 07:10 PM, Przemek Klosowski wrote:

On 09/10/2015 09:53 AM, Stephen Gallagher wrote:

The point of software is to provide a service to an end-user. Users
don't run software because it has good packaging policies, they run
software because it meets a need that they have. If they can't get
that software from Fedora, they *will* get it from another source (or
use a different OS that doesn't get in their way). I'll take a moment
to remind people that two of Fedora's Four Foundations are "Features"
and "First". We want Fedora to be the most feature-complete
distribution available and we want to get there before anyone else
does. I would say that holding to our no-bundling policy actively
defeats our efforts on that score.
Those are valid points, but I think that there are alternative 
approaches to address them.
Can containerization it be leveraged to handle the packages which 
require bundling? This way, we could maintain the principled stance, 
and use containers with bundling packages as a temporary measure.


That would be more like a permanent solution since everything is 
evolving into that direction however you would still need a separate 
means of installing that bundle and those means would not be rpm afaikt.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 07:25 PM, Adam Williamson wrote:

In a world where bundling was allowed, the package would likely have
been approved on initial review; the only significant issues found in
review were bundling-related. There are a couple of trivial issues
noted in #c7, but those would have been literally 10-second fixes.


Would have, could have, should have. . .

So let's play that game ;)

If all the related review request had been completed in timely fashion 
he would have never given up on un-bundling it.


I'm not saying you are wrong but I'm not saying that you are entirely 
correct in your assumption either what I'm saying is that there are 
multiple factors at play here.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 07:16 PM, Haïkel wrote:

2015-09-11 21:09 GMT+02:00 Josh Stone:

>On 09/11/2015 10:35 AM, Stephen Gallagher wrote:

>>Actually, the opposite is true. RHEL has fewer limitations in this
>>space. Red Hat's layered projects ship a fair amount of bundled stuff.
>>This problem is entirely Fedora's. Fedora has far stricter rules than
>>RHEL in this regard.

>
>It helps that we have paid maintainers for RHEL.  Bundling is not as bad
>when there's some assurance that it won't stagnate.  But in general with
>unpaid community members, it's harder to be sure things will be actively
>maintained.

Keyword is*some*, there are packages in RHEL that are less maintained than
they are in Fedora.
I'd rather insist that RHEL has a smaller set of packages that makes
it easier that
most of them are better curated.


Right as well as most issues already have been found and fixed in Fedora 
long before those components enter RHEL.


JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 07:59 PM, Adam Williamson wrote:

On Fri, 2015-09-11 at 19:32 +, Jóhann B. Guðmundsson wrote:

On 09/11/2015 07:25 PM, Adam Williamson wrote:

In a world where bundling was allowed, the package would likely
have
been approved on initial review; the only significant issues found
in
review were bundling-related. There are a couple of trivial issues
noted in #c7, but those would have been literally 10-second fixes.

Would have, could have, should have. . .

So let's play that game ;)

If all the related review request had been completed in timely
fashion
he would have never given up on un-bundling it.

I'm not saying you are wrong but I'm not saying that you are
entirely
correct in your assumption either what I'm saying is that there are
multiple factors at play here.

OK, so let's talk about review requests! Clearly, we have more review
requests than we can handle, hence there's a giant backlog, hence
general sadness.


Indeed



How many of those review requests, do you think, are for tiny bundled
libraries that will probably only ever be used by at most two packages
(probably only one)? Wouldn't we have much less of a backlog if we
didn't have to do all those unbundling requests? ;)


I would argue not since the backlog increased into becoming unmanageable 
at the time when the decision was made  to make it easer to submit and 
include components in Fedora ( which was around FC6  )




Again, I don't actually think the answer here is "screw it, let's
bundle everything" - but I do believe it's reasonable to say that the
strict no-bundling policy is causing a lot of fairly pointless work


I hardly call people dedicating their free time into something they 
believe in is the right course of action as pointless work but OK.



(I'm really not sure unbundling tiny crappy PHP 'libraries' that have
no sane upstream maintenance policy in any case has ever actually
benefitted anyone, anywhere, very much), and there are definitely
cases where it is a primary cause of people abandoning review requests
or simply not bothering to submit them because the required unbundling
would be way too much work to be worthwhile. There is a *genuine non-
zero cost* to the unbundling policy, which is all the OP was
suggesting.


There exist cases on both sides but that argument is irrelevant in the 
end since all roads lead to the bigger question which has already been 
answered by the board.
( people will first debate where to draw the line if that discussion 
wont be killed in birth but in the end they end up with the same 
question as has already been answered )


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 06:40 PM, Adam Williamson wrote:

On Fri, 2015-09-11 at 18:27 +, Jóhann B. Guðmundsson wrote:


I agree that the discussion here needs to be more broad-based; see
the
other thread fork. I was just providing support for Stephen's
contention that this is not some airy-fairy theoretical problem,
there
are multiple examples of real things that people *wanted* to have
packaged that are not packaged because the unbundling process was
too
onerous.


Arguably that is a testament of how heavy the bureaucracy in the
distribution has become not the "bundling" itself.

Um. I don't see how you can possibly make that argument.


If you where looking at this from a broader perspective ( which you 
yourself proposed doing ), you would see it is entirely possible to make 
that argument because people have been giving up submitting components 
for inclusion in Fedora due to the fact how long the review process has 
taken , regardless if their submitted component had to be un-bundled or 
not.


If you take a closer look at the sample you provided you should have 
noticed the submitted date of that review request is 2012-07-01 and the 
last comment in which he finally gave up and moved to do other things 
wason 2014-01-26 roughly 18 months later so claiming that he only 
abandoned his review request due to having to unbundle the submitted 
component might not be the ( sole ) underlying cause for doing so ( If 
you are thinking about arguing the case he had to depend on another 
component then I'll point out the time 2009-11-27 when the review 
request for that depended component was submitted ) .


JBG


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 08:31 PM, Adam Williamson wrote:

We certainly agree on that.


>  which has already been
>answered by the board.
>( people will first debate where to draw the line if that discussion
>wont be killed in birth but in the end they end up with the same
>question as has already been answered )

Eh, I'm not sure it's really been fully addressed, and even if it has,
if enough people feel like the topic needs revisiting, it seems wise
to revisit it.


As far as I can tell these are the same people as last time which are 
not satisfied with the outcome of that decision.


And you know as well as I do that people pursuing this will start 
discussing where to draw the line, with the end being why stop there? 
which in turn will lead to having to answer same question again ( what 
the third time, this time around? ).


Now if nothing new is being added to the previous discussions  ( which I 
have yet to see the case for ) and the council would for some reason 
approve, and in doing so looking extremely suspicions if that would be 
the case, people would most likely want community wide vote based on the 
grounds that the changes are being made to the foundation of the 
project, those same foundations which led them to participate in the 
first place.


Now let's wait and see in which direction the discussion will take.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 09:09 PM, Orion Poplawski wrote:

What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and "pip
install ipython"?


This indeed is very good question.

I'm not sure how things are elsewhere in the world but in the case of 
gem's on a rock in the middle of the north atlantic ocean , everybody is 
using bundler with nobody wanting to go back to non existing or not 
current gem's in distributions and or having to manually chase down 
components and resolve their dependency's.


They prefer spending that time actually hacking or drinking beer or both.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Jóhann B . Guðmundsson]

On 09/11/2015 05:35 PM, Stephen Gallagher wrote:

To me (speaking as a user of Fedora, maintainer of Fedora software and
developer of both Fedora and upstream projects), the current situation
is not ideal. In many cases, we're holding so rigidly to the "no
bundling" policy that it is actively harmful to Fedora's Mission:
"The Fedora Project's mission is to lead the advancement of free and
open source software and content as a collaborative community." When
we aren't capable of shipping and working with upstreams that*are*
advancing the FOSS world, we are failing in our mission to be a leader
in that space.


Of whom are you speaking of that advances the FOSS world so dearly ?

Why does you as user of Fedora, maintainer of Fedora software and 
developer of both Fedora ( not sure what developer of Fedora is supposed 
to mean unless you have been developing for the projects support systems 
) and upstream projects, taking their point of view of that argument, 
claiming that the community cannot work with upstream community(s) and 
should change it's shape ( the same community it's members have for the 
past 10 years argued and convinced people to do the opposite of what you 
now propose ) to suit their needs since it's them who are unwilling to 
un-bundle their application or application stack?


And arguably Fedora already has more software than people to maintain it 
so ( continuing ) being without few unwilling to un-bundle upstreams 
would only do the distribution more good than harm.


JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FESCo Meeting Minutes (2015-03-04)

[Jóhann B. Guðmundsson]

On 03/05/2015 02:44 PM, Zbigniew Jędrzejewski-Szmek wrote:

While I would love to see 100% migration, the benefits for leaf packages
aren't that big. We have fairly good compatibility support, and only
a small number of people are using each package.


Nobody can use those leaf packages unless the legacy sysv initscript has 
been renamed in them which is why FESCo could just as well drop those 
package this release cycle and where did you get the statistic that only 
small number was using the remaining unmigrated components?




And there's the problem of who should do the work. I don't think
FESCo members can be responsible personally for the implementation,
and so far nobody has stepped up.


You yourself experience first hand not so long ago how incompetence 
those individuals in FPC regarding the uid/guid where FPC only needed to 
follow their own approved guideline o_O


Something Ovasik would have done blindfolded, holding a beer in one hand 
and typing on the keyboard with the other a while riding a unicycle 
those 8 months back when this request originally crossed his path but no 
someone singular or plural decided in his, her's or theirs infinity 
wisdom to move that process and workflow in the hands of the FPC where 
something went from someone who knows his stuff and would have been done 
in a jiffy to 9 months to be ( semi ) completed!


You have already addended those FESCo meeting which among other things 
they did not regonize you as neither the primary maintainer of systemd 
in the distribution nor lead developer from upstream! ( and this is just 
what has been happening in the year 2015 )



  I'm not volunteering to dive that
deep into the other 95 packages.


I said I would complete the work I started under certain condition on 
that report ( I hate leaving things unfinished ) and as I mentioned 
before to complete this will require 300 man hours then there is another 
1000 manhours work in an cleaning up process ( not talking about removal 
here ) so FESCo needs to decide on what they are going to do  *before* 
someone starts doing this and other related work and on top of that the 
distribution or Red Hat needs to decide what they intent do regarding 
factory reset ( RHEL 8 or not ) .  ( From the looks of that will take 
equal amount of work that replacing the init system has taken. )



So not taking a decision without the
power to have it implemented is better than having it taken and ignored.
If ajax manages to kill the 17 -sysvinit subpackages, that will be a
good first step.


Is it good the majority of FESCo decided to revert their own ( fesco at 
that time  ) ignant previous decision making? no since if they bothered 
to take the time to inform themselves about the topic at hand in the 
first place then they would not have to spend time their and others time 
in undoing previous own work. ( In this case if they would have 
installed those subcomponents that contain legacy sysv initscript to be 
used as an replacement or alternative to the components existing units 
and try to use those legacy sysv initscript in conjunction with existing 
units, through updates etc they would have kicked those packages to the 
curb then and there at that meeting instead of wasting cpu cycle and 
infrastructure space continuing carrying them )


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct