Jóhann B. Guðmundsson wrote:
> "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.
I haven't seen anyone arguing that Fedora
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.
I fail to imagine what
On Thu, Apr 14, 2022 at 09:29:27PM +, Jóhann B. Guðmundsson wrote:
> >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
>
On 15/04/2022 00:53, Jóhann B. Guðmundsson wrote:
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
On 15/04/2022 03:51, Nikolay Nikolov wrote:
But I'm still surprised that Fedora by default downloads and updates
proprietary firmware, downloaded from the Internet.
1. Fedora itself doesn't download anything. The user must manually allow
installation of such update.
2. Vulnerable firmware is
On 15/04/2022 01:25, Nikolay Nikolov wrote:
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?
> Am 15.04.2022 um 00:24 schrieb Nikolay Nikolov :
>
> If you want to deprecate legacy boot on new installs on UEFI-capable BIOS-es,
> that's another story. E.g. if the installer detects that the BIOS is modern
> (e.g. later than 2017-2018) and UEFI capable, but is running in legacy boot
>
On Thu, Apr 14, 2022 at 11:39 AM Kevin Kofler via devel
wrote:
> I am also worried that this is just a delayed retirement, as it was for 32-
> bit i686, where the SIG was very quickly declared a failure, without even
> being given time to organize.
Well, presumably, if you are a member of the
On 4/15/22 04:01, Jóhann B. Guðmundsson wrote:
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,
On 4/14/22 15: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
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
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
Justin Forbes wrote:
> The i686 SIG was given multiple releases to organize. The original
> proposal which triggered the SIG to form was for F27, the proposal to
> finally kill it and declare the SIG inactive was F31.
But, the way I remember it, the SIG was declared inactive just because of
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
Jóhann B. Guðmundsson wrote:
> No but it does mean that they cant run indefinitely
Only if the spare parts that are not available actually fail (and if you
cannot find the spare parts through less official channels, such as buying
another broken computer where the part you need is still
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
Jóhann B. Guðmundsson wrote:
> 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".
How is it against "First" to continue providing the future also for hardware
of the
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
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
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
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
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
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
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,
On Thu, Apr 14, 2022 at 12:18:12PM +, JadoNena via devel wrote:
> All of this discussion waves a red flag at us.
[...]
> But only a few people are talking about the real costs to users.
Please don't read too much into everything you see in big mailing list
threads like this, especially as you
On Thu, Apr 14, 2022 at 6:39 AM Kevin Kofler via devel
wrote:
>
> Ralf Corsépius wrote:
> > 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.
>
> I
On Thu, Apr 14, 2022 at 2:29 PM Peter Boy wrote:
>
>
>
> > Am 14.04.2022 um 20:20 schrieb Chris Adams :
> >
> > 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
>
That’s a step into the right direction, but needs some corrections:
> Am 14.04.2022 um 20:02 schrieb Robbie Harwood :
>
>
> The overall goal of the SIG needs to be to reduce load on existing
> bootloader contributors. If it is not doing this, it needs to be
> dissolved.
The first overall goal
Hi Robbie,
On 4/14/22 20:02, Robbie Harwood wrote:
> Hans de Goede writes:
>
>> What I envision for the SIG is:
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be
> Am 14.04.2022 um 20:20 schrieb Chris Adams :
>
> 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
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
Hans de Goede writes:
> What I envision for the SIG is:
>
> 1. I'm not sure if it is possible to setup group ownership
> of pkgs in pagure? So to keep things simple the few packages which
> are only necessary for BIOS boot can be handed over to me and then
> I'll just add other people willing to
On Thu, Apr 14, 2022 at 2:08 PM Vitaly Zaitsev via devel
wrote:
>
> On 14/04/2022 15:31, John Reiser wrote:
> > Some of them even have "without data loss" in the page title.
>
> Without moving data to another physical drive this operation is too
> dangerous.
>
> I tried on my testing VM and lost
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,
It happens that way in some places but not everywhere. I believe someone
earlier mentioned how this whole discussion is security theater - some
companies know this to be true and have fiscal policies that reflect that.
I have direct experience working for a large organization where 3-5 years
Hans de Goede writes:
> On 4/13/22 21:27, David Cantrell wrote:
>
>> OK, given this proposal, I'd like the original change proposal
>> amended to essentially say "transfer legacy BIOS boot support to
>> newly formed Legacy BIOS SIG" or something like that. The logistics
>> at that point can be
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
> 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
On 14/04/2022 16:21, John Reiser wrote:
Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print)
command (then 'q' to quit),
both before and after the attempted conversion.
I no longer have legacy BIOS configurations. VMs have been reinstalled
from scratch after trying to convert
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
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
On Thu, Apr 14, 2022 at 5:09 PM Hans de Goede wrote:
>
> Hi Michel,
>
> On 4/13/22 22:29, Michel Alexandre Salim wrote:
> > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >>
> >> 1. I'm not sure if it is possible to setup group ownership
> >> of pkgs in pagure? So
Hi,
On 4/13/22 23:11, Matthew Miller wrote:
> On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
>> If that proves acceptable for change owners here that would perhaps take
>> care of the short term problem. What about longer term though? Would the
>> thought be that the BIOS sig would
Hi Michel,
On 4/13/22 22:29, Michel Alexandre Salim wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for
Hi David,
On 4/13/22 21:27, David Cantrell wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/13/22 18:07, David Cantrell wrote:
>>> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
On Wed, Apr 13 2022 at 10:54:01 AM -0400, David
Am 14.04.22 um 13:39 schrieb Kevin Kofler via devel:
Ralf Corsépius wrote:
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.
I am also worried that
On 4/14/22 07:07, Vitaly Zaitsev via devel wrote:
On 14/04/2022 15:31, John Reiser wrote:
Some of them even have "without data loss" in the page title.
Without moving data to another physical drive this operation is too dangerous.
I tried on my testing VM and lost all data from that VM.
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.
Thanks,
> On Apr 14, 2022, at
On 14/04/2022 15:31, John Reiser wrote:
Some of them even have "without data loss" in the page title.
Without moving data to another physical drive this operation is too
dangerous.
I tried on my testing VM and lost all data from that VM. Restored snapshot.
--
Sincerely,
Vitaly Zaitsev
On 4/14/22 02:01, Vitaly Zaitsev via devel wrote:
On 13/04/2022 23:11, Matthew Miller wrote:
It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
I don't think it's possible because the MBR -> GPT conversion will destroy all
partitions on the original drive.
An
On Thu, Apr 14, 2022 at 8:58 AM JadoNena wrote:
>
> Hello,
>
> > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa
> > wrote:
>
> Thank you very much for your reply. You are one of those several people that
> we have been reading has some good sense for users!
>
> > First: do not panic!
>
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
Hello,
> On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa
> wrote:
Thank you very much for your reply. You are one of those several people that
we have been reading has some good sense for users!
> First: do not panic!
Of course panic is a bad idea.
I am just observing this largest
On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel
wrote:
>
> > The question is: how many users do we want to leave behind? Or: how many
> > users must we leave behind because we can’t do the job.
>
> We are just users. Our expert development is for other professions than
> writing drivers and
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
> Am 14.04.2022 um 14:05 schrieb 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
On Thu, Apr 14, 2022 at 01:42:26PM +0200, Kevin Kofler via devel wrote:
> Jóhann B. Guðmundsson wrote:
> > In this case that SIG would be created for no good reason since the
> > outcome is inevitable.
>
> I still do not see what is inevitable about the outcome. Keeping legacy, no
> longer
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
> The question is: how many users do we want to leave behind? Or: how many
> users must we leave behind because we can’t do the job.
We are just users. Our expert development is for other professions than
writing drivers and operating systems.
My company has about 200 Fedora user PCs around
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
> 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
>
Jóhann B. Guðmundsson wrote:
> In this case that SIG would be created for no good reason since the
> outcome is inevitable.
I still do not see what is inevitable about the outcome. Keeping legacy, no
longer changing, interfaces working forever should require next to no
effort.
> For how long
On 13. 04. 22 22:29, Michel Alexandre Salim wrote:
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
Hi,
1. I'm not sure if it is possible to setup group ownership
of pkgs in pagure? So to keep things simple the few packages which
are only necessary for BIOS boot can be handed
Ralf Corsépius wrote:
> 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.
I am also worried that this is just a delayed retirement, as it was for 32-
bit
On Wed, Apr 13, 2022 at 9:12 PM Matthew Miller wrote:
> It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
> That might be something interesting for the SIG to do. But, I don't think
> that's really a small project!
This is mostly off topic, and while I have not
carefully
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
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
On 13/04/2022 23:11, Matthew Miller wrote:
It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
I don't think it's possible because the MBR -> GPT conversion will
destroy all partitions on the original drive.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
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
On Thu, Apr 14, 2022 at 12:38 AM Kevin Kofler via devel
wrote:
>
> Matthew Miller wrote:
> > We've got a 300+ message thread in just one week, with 66 different
> > participants. This handily beats discussions systemd-resolved,
> > btrfs-by-default, and even switching the default editor to nano.
Neal Gompa wrote:
> The binary RPM for grub's BIOS boot code is grub2-pc (and
> grub2-pc-modules), not grub2.
Oh, it used to be just grub2 until F26 (included), I had either forgotten or
not noticed at all that it had been renamed back in F27 already. (It used to
be the case for years that
On Wed, Apr 13, 2022 at 8:45 PM Kevin Kofler via devel
wrote:
>
> Hans de Goede wrote:
> > As the Source0 provider for the packages and then next to:
> >
> > https://src.fedoraproject.org/rpms/grub2
> >
> > Add a:
> >
> > https://src.fedoraproject.org/rpms/grub2-bios
> >
> > And moving the build
Hans de Goede wrote:
> As the Source0 provider for the packages and then next to:
>
> https://src.fedoraproject.org/rpms/grub2
>
> Add a:
>
> https://src.fedoraproject.org/rpms/grub2-bios
>
> And moving the build of all sub-packages which are
> only necessary for BIOS support to the second
Matthew Miller wrote:
> We've got a 300+ message thread in just one week, with 66 different
> participants. This handily beats discussions systemd-resolved,
> btrfs-by-default, and even switching the default editor to nano.
>
> Clearly there's a lot to talk about here. Would it be useful to have
On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
> If that proves acceptable for change owners here that would perhaps take
> care of the short term problem. What about longer term though? Would the
> thought be that the BIOS sig would remain around for the forseeable
> future
On Wed, Apr 13, 2022 at 03:27:14PM -0400, David Cantrell wrote:
> > FWIW, ATM I think everything which can be said about
> > this has been said and I'm not sure if having a video
> > call about this will add anything new.
> Agreed.
Works for me -- I just wanted to put the option there in case it
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> Hi,
>
>
> 1. I'm not sure if it is possible to setup group ownership
> of pkgs in pagure? So to keep things simple the few packages which
> are only necessary for BIOS boot can be handed over to me and then
> I'll just add other
...snip bios sig plan...
Thanks for that Hans!
If that proves acceptable for change owners here that would perhaps take
care of the short term problem. What about longer term though? Would the
thought be that the BIOS sig would remain around for the forseeable
future maintaining BIOS boot? Or
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/13/22 18:07, David Cantrell wrote:
> > On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
> >> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
> >> wrote:
> >>> The core issue still comes down
Hi,
On 4/13/22 18:07, David Cantrell wrote:
> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
>> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
>> wrote:
>>> The core issue still comes down to having resources to continue
>>> maintaining
>>> BIOS boot support in
On Wed, Apr 13, 2022 at 09:34:18AM -0700, Samuel Sieb wrote:
> On 4/13/22 07:54, David Cantrell wrote:
> > The core issue still comes down to having resources to continue maintaining
> > BIOS boot support in Fedora and so far no one has come forward to work on
> > that.
>
> As far as I can tell
On 4/13/22 07:54, David Cantrell wrote:
The core issue still comes down to having resources to continue maintaining
BIOS boot support in Fedora and so far no one has come forward to work on
that.
As far as I can tell from the responses in the other thread, there is
not currently an issue with
On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
> wrote:
> > The core issue still comes down to having resources to continue
> > maintaining
> > BIOS boot support in Fedora and so far no one has come forward to work
> >
On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
wrote:
The core issue still comes down to having resources to continue
maintaining
BIOS boot support in Fedora and so far no one has come forward to
work on
that.
It's not true, although you can be forgiven for missing it in such a
On Tue, Apr 12, 2022 at 07:20:52PM -0400, Matthew Miller wrote:
> We've got a 300+ message thread in just one week, with 66 different
> participants. This handily beats discussions systemd-resolved,
> btrfs-by-default, and even switching the default editor to nano.
>
> Clearly there's a lot to
We've got a 300+ message thread in just one week, with 66 different
participants. This handily beats discussions systemd-resolved,
btrfs-by-default, and even switching the default editor to nano.
Clearly there's a lot to talk about here. Would it be useful to have a
high-bandwidth, moderated
86 matches
Mail list logo
