Re: Fedora Linux subsystem on Windows machine
by Vít Ondruch
Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
> On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch <vondruch(a)redhat.com>
> wrote:
>
>>
>>
>> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
>>>
>>>
>>>
>>>
>>> And speaking of Wine, how come the Windows 10 Linux subsystem only
>>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
>>> machine?
>>
>> Just FYI:
>>
>>
>> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
>>
>>
>> Vít
>
> I think that doesn't work anymore. But there's this project that
> should work now [0], while being more user friendly and versatile.
>
> [0] https://github.com/RoliSoft/WSL-Distribution-Switcher
Thanks for pointing this out. I knew I saw something more advanced, but
already forgot what it was ;) I am not windows user mysefl ...
Vít
7 years, 4 months
Re: Fedora Linux subsystem on Windows machine
by M. Edward (Ed) Borasky
Nice!!
On Fri, Jan 6, 2017 at 1:47 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>
>
> Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
> > On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch <vondruch(a)redhat.com>
> > wrote:
> >
> >>
> >>
> >> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
> >>>
> >>>
> >>>
> >>>
> >>> And speaking of Wine, how come the Windows 10 Linux subsystem only
> >>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
> >>> machine?
> >>
> >> Just FYI:
> >>
> >>
> >> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
> >>
> >>
> >> Vít
> >
> > I think that doesn't work anymore. But there's this project that
> > should work now [0], while being more user friendly and versatile.
> >
> > [0] https://github.com/RoliSoft/WSL-Distribution-Switcher
>
> Thanks for pointing this out. I knew I saw something more advanced, but
> already forgot what it was ;) I am not windows user mysefl ...
>
>
> Vít
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
How many people can stand on the shoulders of a giant before the giant
collapses?
7 years, 4 months
Re: More than 10% of all Fedora spec files are not POSIX sh compliant
by Nicolas Mailhot
Le 2019-03-25 09:53, Jan Pokorný a écrit :
> Good point, and that's something capable of making upstream
> maintenance cumbersome at times (sed is a common pet peeve),
> but that's an order of magnitude more demanding level when it
> comes to portability, and with Fedora settled firmly just around
> GNU approaches and extensions, there's hardly a pressing need for
> the spec files to come anywhere close (but if so, the restrictions
> should not be limited to shell interpreter alone as remarked,
> since POSIX compliance is a wider topic).
More accurately, what is the point of wasting energy on making a Linux
system POSIX-only today? POSIX was a useful tool to make proprietary
unixes more or less compatible with one another. The situation has
changed since. Linux has taken over most of the marketplace. That means
the common compat layer you need to target to replace it with something
else, is whatever major Linux distributions agree on, and that includes
all the GNU tools with all their non-POSIX extensions.
That's why Microsoft created WSL instead of just fixing its POSIX
subsystem. POSIX is no longer sufficient to gain significant market
traction. Users want their pushds/popds.
Regards,
--
Nicolas Mailhot
5 years, 1 month
Re: Let's talk about Fedora in the '20s!
by Matthew Miller
On Sat, Jan 11, 2020 at 11:19:49AM -0600, Martin Jackson wrote:
> In this vein (as other people have commented on this thread), I
> think it would be great to give Fedora more visibility. Its absence
> as a supported image in Azure, for instance, is particularly
> noticeable, and the whole situation with WSL was regrettable. One
> of the reasons I've used Ubuntu/Debian in some of those situations
> is that they're there and relatively easy to consume. I've come to
> prefer Fedora because it has much better leading-edge stuff, and I
> think that's a huge benefit to the community that definitely serves
> a particular segment.
For what it's worth, we do continue to work on these things. It's difficult
because we really do need to make sure we have solid legal protection.
> Having a few people who talk about Fedora in the ecosystem publicly
> and often might be helpful too. There are a bunch of people who are
> directly and visibly connected with Ubuntu/Canonical that appear all
> the time on the Jupiter Broadcasting podcasts (I know Matt is also
> frequently interviewed but that's not quite the same thing). Having
> people talking about doing things with Fedora makes it "cool" and
> "buzzworthy", and I think that's of value.
I'd love to have more people from across the project on all of these shows,
definitely! Any suggestions on how we could make this easier for people who
are not me? :)
[...]
> One thing I would like to point out, as a sort of editorial comment
> - let's not let the areas we can improve in detract from the things
> Fedora is great at. We have a small-ish, but relatively vocal
> Fedora community where I work, among the sysadmins. I don't think
> Fedora users are quite as vocal, but the engineering in Fedora is
> solid. Sure there are problems occasionally, but the rate of change
> and the usability of Fedora as a daily driver and for some server
> workloads is pretty impressive.
Thanks -- I appreciate the input!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4 years, 4 months
Re: Fedora CoreOS stable stream now rebased to Fedora 34
by Zbigniew Jędrzejewski-Szmek
On Wed, May 19, 2021 at 01:19:25PM +0200, Clement Verna wrote:
> On Wed, 19 May 2021 at 09:24, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
> wrote:
>
> > On Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe wrote:
> > > - DNF Count Me support for Fedora CoreOS [6].
> >
> > Are the count stats visible somewhere?
> >
>
> For FCOS this change is not yet enabled, it is coming in a few months (more
> info [0]).
> But the Count Me support was enabled on Sliverblue and IoT so we should be
> able to get better stats for these now :).
>
> The raw data are available here[1] and
>
> [0] -
> https://fedoramagazine.org/getting-better-at-counting-rpm-ostree-based-sy...
> [1] - https://data-analysis.fedoraproject.org/csv-reports/countme/
Thanks.
>>> set(f['os_name'])
Out[11]:
{'09-Fedora-Gnome',
'Alibaba Cloud Linux',
'AlmaLinux',
'Alpine Linux',
'Amazon Linux',
'Anolis OS',
'Asianux Server',
'BigCloud Enterprise Linux',
'Bottlerocket',
'Broken Fedora',
'CAPS-OS',
'CGS Linux',
'CONFIDENTIAL PREVIEW \\xc2\\xab\\xc2\\xb1\\xc2\\xbb Hybrid Decisions\\xc2\\xae SaferOS\\xe2\\x84\\xa2',
'Cake',
'CentOS',
'CentOS CAPS-OS',
'CentOS Linux',
'CentOS Linux CAPS-OS',
'CentOS Linux release 8',
'CentOS Release ',
'CentOS Stream',
'CentOS Stream v21.021 v21.021 v21.022',
'CentOS Stream v21.027 v21.027 v21.027 ',
'CentOS Stream v21.032',
'CentOS Stream v21.033 v21.033 v21.033 v21.033 v21.033 v21.034',
'CentOS Stream v21.036 v21.036 v21.036 v21.036 v21.036 v21.036 v21.036 v21.036 v21.036 v21.036',
'CentOS Stream v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.042 v21.043',
'CentOS Stream v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057 v21.057',
'CentOS Stream v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.065 v21.066',
'CentOS Stream v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 v21.067 ',
'CentOS Stream v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111 v21.111',
Some strange stuff!
>>> f.groupby('os_name').sum().sort_values('hits').tail(20)
hits sys_age
os_name
Virtuozzo Linux 454 153
Kontron TSN Starterkit 454 151
Private Void Enterprise Linux 522 1275
StaRT Linux 563 195
NCRLinuxC 650 246
Syneto Juno 711 254
UXCloud 1841 1136
SereneLinux 2032 534
Springdale Open Enterprise Linux 2677 529
Rocky Linux 3100 30
Fedora Remix for WSL 9337 2454
NST 11494 1798
CloudLinux 43267 695
Generic 74319 4587
AlmaLinux 93186 335
Oracle Linux Server 316058 1880
CentOS Stream 803710 1429
Red Hat Enterprise Linux 3163541 6736
CentOS Linux 17082049 3929
Fedora 60766448 190704
Zbyszek
3 years
Re: Let's talk about Fedora in the '20s!
by Martin Jackson
On 1/14/20 10:20 AM, Matthew Miller wrote:
> On Sat, Jan 11, 2020 at 11:19:49AM -0600, Martin Jackson wrote:
>> In this vein (as other people have commented on this thread), I
>> think it would be great to give Fedora more visibility. Its absence
>> as a supported image in Azure, for instance, is particularly
>> noticeable, and the whole situation with WSL was regrettable. One
>> of the reasons I've used Ubuntu/Debian in some of those situations
>> is that they're there and relatively easy to consume. I've come to
>> prefer Fedora because it has much better leading-edge stuff, and I
>> think that's a huge benefit to the community that definitely serves
>> a particular segment.
> For what it's worth, we do continue to work on these things. It's difficult
> because we really do need to make sure we have solid legal protection.
I definitely understand the need to button down the legal stuff. But
dang. What about WSL2 makes it easier, if that's something you can
address here?
>> Having a few people who talk about Fedora in the ecosystem publicly
>> and often might be helpful too. There are a bunch of people who are
>> directly and visibly connected with Ubuntu/Canonical that appear all
>> the time on the Jupiter Broadcasting podcasts (I know Matt is also
>> frequently interviewed but that's not quite the same thing). Having
>> people talking about doing things with Fedora makes it "cool" and
>> "buzzworthy", and I think that's of value.
>
> I'd love to have more people from across the project on all of these shows,
> definitely! Any suggestions on how we could make this easier for people who
> are not me? :)
>
> [...]
>
>> One thing I would like to point out, as a sort of editorial comment
>> - let's not let the areas we can improve in detract from the things
>> Fedora is great at. We have a small-ish, but relatively vocal
>> Fedora community where I work, among the sysadmins. I don't think
>> Fedora users are quite as vocal, but the engineering in Fedora is
>> solid. Sure there are problems occasionally, but the rate of change
>> and the usability of Fedora as a daily driver and for some server
>> workloads is pretty impressive.
> Thanks -- I appreciate the input!
You're very welcome!
Thanks,
Marty
4 years, 4 months
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
by Neal Gompa
On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez <jaredz(a)redhat.com> wrote:
>
>
>
>
> On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net> wrote:
>>
>> On 4/7/22 14:51, Jared Dominguez wrote:
>> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
>> > <mailto:samuel@sieb.net>> wrote:
>> >
>> > On 4/7/22 08:02, Jared Dominguez wrote:
>> > > This is a proposal. Nothing has changed yet. The choice is now
>> > whether
>> > > to go forward with it or come together with a cohesive
>> > > alternative, including one of the two listed in the proposal. But we
>> > > need a solution that accounts for the existing maintainers not
>> > having
>> > > capacity to continue maintaining legacy code. I've seen responses
>> > from
>> >
>> > I haven't yet seen a clear answer about what code is "rotting" and
>> > which
>> > legacy code is too hard to maintain. Is there something actually
>> > broken
>> > right now?
>> >
>> >
>> > For one, syslinux hasn't seen an update in 3 years and a release in 7
>> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>> > getting development attention. The current maintainers in Fedora won't
>> > have capacity to continue maintaining legacy boot support in Fedora. As
>> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>> > not to mention non-UEFI ppc64le and s390x), there is added risk of
>> > regressions on legacy x86 boot that won't be getting developer attention.
>>
>> I don't understand why we're still using syslinux instead of grub for
>> legacy boots, especially since I think now you can use the same grub.cfg
>> file for both.
>
>
> It's development and validation work for something that's not a priority for those who are doing bootloader work, and no one else has stepped up to put in the time to do this work. The change proposal being discussed in this thread is calling for community contributors.
>
>> There is always a risk of regressions, but if there is
>> no current problem, then why is there this push to obsolete a lot of
>> active hardware?
>
>
> There is a problem: the current maintainers don't have capacity to support legacy x86 boot anymore. The code is going to bit rot if no one steps up to fill in.
>
>> This is not comparable to the 32-bit removal where it
>> was only a few really old systems. This is going to affect decent
>> systems that are less than 10 years old. I have a work HP laptop from
>> 2012 that has "experimental" EFI support that really doesn't work well
>> and possibly a newer one as well, but I can't check it right now.
>
>
> I'm curious if you've updated your BIOS on that system. If it's really that bad, Microsoft (and HP customers) would have been on HP's case about fixing a bad user experience.
>
Why? It works for Windows, and HP has only done token support for
other platforms over the past decade (see most recent thing promoting
WSL as a good Linux on HP experience[1]). All of my HP computers have
been extremely difficult to get Linux working on properly, which is
why I stopped buying them.
Just because Dell is sometimes good at its job doesn't mean everyone
else is. The reality is that most aren't.
[1]: https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collab...
--
真実はいつも一つ！/ Always, there's only one truth!
2 years, 1 month
Re: Let's talk about Fedora in the '20s!
by Martin Jackson
>> First, I'd like to see Fedora become more of an "operating system factory".
>>
There are a few things that seem a bit out of place, in terms of RH's
messaging/endorsing of Fedora, and Fedora's role as an upstream for RHEL
and an engine of moving the entire Linux community forward.
I think this would be great. I think the ability to make it clear how
to make customized fedora images would be very helpful.
In this vein (as other people have commented on this thread), I think it
would be great to give Fedora more visibility. Its absence as a
supported image in Azure, for instance, is particularly noticeable, and
the whole situation with WSL was regrettable. One of the reasons I've
used Ubuntu/Debian in some of those situations is that they're there and
relatively easy to consume. I've come to prefer Fedora because it has
much better leading-edge stuff, and I think that's a huge benefit to the
community that definitely serves a particular segment.
The addition of the virtualbox guest additions to the installer was a
great step, too - the big question, I think is to find ways to make it
easy to consume fedora, and in some cases that means making images for
Virtualbox, for cloud providers, maybe for CI providers too.
Having a few people who talk about Fedora in the ecosystem publicly and
often might be helpful too. There are a bunch of people who are
directly and visibly connected with Ubuntu/Canonical that appear all the
time on the Jupiter Broadcasting podcasts (I know Matt is also
frequently interviewed but that's not quite the same thing). Having
people talking about doing things with Fedora makes it "cool" and
"buzzworthy", and I think that's of value.
>>
>> Second, we need to figure out how to work with language-native packaging
>> formats and more directly with code that's distributed in git repos rather
>> than as tarball releases.
Some languages make this a lot easier than others. The curation that we
do is valuable, and a lot of my interests involve curations of some of
the really neat things I've found in the Python ecosystem. Python makes
it *relatively* easy but it seems there will always be edge cases.
That said, I love Fedora as a platform to explore the latest/greatest in
curated scripting platforms and development.
I'm working on packaging pipx for Fedora, which is a python tool to
install venvs for applications; maybe including some meta-tooling like
this in the distribution might help bridge some of the gaps (that is,
it's infeasible to package all of pypi/CPAN/rubygems), in making it easy
to consume those environments in Fedora, but giving up some of the
advantages of packaging and curation. I understand people might find
that unsuitable on both sides.
I don't know if things like pipx exist for other scripting languages,
but do other people think that's worth exploring? (Currently pipx uses
tox in what seems like a weird way, and we'd need to package userpath
and tox-venv to make them work - I'm working on those and hope to submit
the specs for review soon).
>> Third, we really need to continue to grow the project as more than coding
>> and packaging.
>>
>>
Maybe some of this falls into the publicity point that's part of the
first point. I think there's a lot of value to having howto's, project
documentation, guides and so on. I do think it's remarkable that with
the pace that Fedora moves that techniques for approaching certain
problems are still valid and useful. (I built a fault-tolerant firewall
system with Fedora using a conntrackd, iptables, and keepalived with a
guide from...f20 or so? I forget. Still works pretty well.)
One thing I would like to point out, as a sort of editorial comment -
let's not let the areas we can improve in detract from the things Fedora
is great at. We have a small-ish, but relatively vocal Fedora community
where I work, among the sysadmins. I don't think Fedora users are quite
as vocal, but the engineering in Fedora is solid. Sure there are
problems occasionally, but the rate of change and the usability of
Fedora as a daily driver and for some server workloads is pretty impressive.
Thanks,
Marty
4 years, 4 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-04-12.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
Add64 orphan 0 weeks ago
CuraEngine-lulzbot orphan 6 weeks ago
ccls orphan 4 weeks ago
connman orphan 3 weeks ago
ctk neuro-sig, orphan 1 weeks ago
cura-lulzbot orphan, spot 6 weeks ago
dssi orphan 0 weeks ago
dssi-vst orphan 0 weeks ago
fbreader orphan 0 weeks ago
fedora-jam-backgrounds orphan 0 weeks ago
fedora-jam-kde-theme jvlomax, orphan 0 weeks ago
fluidsynth-dssi orphan 0 weeks ago
freqtweak orphan 0 weeks ago
gnome-desktop alexl, caolanm, fmuellner, gnome-sig, 0 weeks ago
orphan, rhughes
gnome-guitar orphan 0 weeks ago
grc orphan 4 weeks ago
gsignond orphan 4 weeks ago
gsignond-plugin-lastfm orphan 4 weeks ago
gsignond-plugin-mail orphan 4 weeks ago
gsignond-plugin-oauth orphan 4 weeks ago
gsignond-plugin-sasl orphan 4 weeks ago
gtk-nodoka-engine orphan 0 weeks ago
harmonyseq orphan 0 weeks ago
hexter-dssi orphan 0 weeks ago
jackctlmmc orphan 0 weeks ago
jakarta-messaging orphan 5 weeks ago
jboss-el-3.0-api orphan 5 weeks ago
jboss-jsp-2.3-api orphan 4 weeks ago
jboss-jstl-1.2-api orphan 4 weeks ago
jboss-servlet-3.1-api orphan 5 weeks ago
jmeters orphan, tartina 0 weeks ago
kpassgen orphan 1 weeks ago
lemonpos orphan 1 weeks ago
libaccounts-glib orphan 4 weeks ago
libarcus-lulzbot orphan 6 weeks ago
libinstpatch orphan 0 weeks ago
libunibreak orphan 0 weeks ago
lulzbot-marlin-firmware orphan, spot 6 weeks ago
lv2-c++-tools orphan, tartina 0 weeks ago
lv2-fabla orphan, tartina 0 weeks ago
lv2-ll-plugins orphan, tartina 0 weeks ago
lv2-mdaEPiano orphan, tartina 0 weeks ago
lv2-newtonator orphan, tartina 0 weeks ago
lv2-sorcer orphan, tartina 0 weeks ago
lv2-swh-plugins orphan, tartina 0 weeks ago
lv2-vocoder-plugins orphan, tartina 0 weeks ago
mailman orphan 1 weeks ago
maven-verifier mizdebsk, orphan 5 weeks ago
meterbridge orphan, tartina 0 weeks ago
nightview orphan 1 weeks ago
non-daw orphan 0 weeks ago
openigtlink neuro-sig, orphan 1 weeks ago
pgRouting orphan, pkubat 0 weeks ago
phpwapmail orphan 6 weeks ago
portmidi mjg, orphan, xavierb 0 weeks ago
powermock jerboaa, lef, neugens, orphan 5 weeks ago
python-cocotb orphan 2 weeks ago
python-pytest4 churchyard, mrunge, orphan, python- 5 weeks ago
sig, radez, thm
python-uranium-lulzbot orphan 6 weeks ago
python3-simplepam leonn, orion, orphan 4 weeks ago
pyxtrlock leonn, orphan 4 weeks ago
quick-usb-formatter orphan 1 weeks ago
racoon2 orphan 3 weeks ago
radium-compressor orphan 0 weeks ago
rdkit orphan 0 weeks ago
realTimeConfigQuickScan orphan 0 weeks ago
rnv orphan 3 weeks ago
rubygem-net-ssh-gateway orphan, tdawson 4 weeks ago
rubygem-recaptcha orphan 4 weeks ago
saxpath akurtakov, mizdebsk, orphan 5 weeks ago
signon-glib dvratil, kde-sig, orphan 4 weeks ago
wf-config orphan 0 weeks ago
whysynth-dssi orphan 0 weeks ago
wsl orphan 0 weeks ago
xsynth-dssi orphan 0 weeks ago
zhu3d orphan 1 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-04-12.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
akurtakov: saxpath
alexl: gnome-desktop
andymenderunix: libunibreak
atim: wf-config, dssi
belegdol: portmidi
bsjones: dssi
callkalpa: portmidi
caolanm: gnome-desktop
chimosky: portmidi
chkr: portmidi
churchyard: python-pytest4
cicku: portmidi
dtimms: portmidi
dvratil: libaccounts-glib, signon-glib
filiperosset: saxpath
fmuellner: gnome-desktop
gbcox: libaccounts-glib
gnome-sig: gnome-desktop
heliocastro: libaccounts-glib
imcinerney: portmidi
jerboaa: powermock
jgrulich: libaccounts-glib, signon-glib
jjames: portmidi
jkraehemann: dssi, libinstpatch
jreznik: libaccounts-glib, signon-glib
jskarvad: portmidi
jvlomax: fedora-jam-backgrounds, dssi, fedora-jam-kde-theme
kde-sig: libaccounts-glib, signon-glib
kkofler: libaccounts-glib
lbalhar: portmidi
lef: powermock
leonn: pyxtrlock, python3-simplepam
limb: portmidi, dssi
martinkg: connman, meterbridge
mbarnes: portmidi
mck182: libaccounts-glib, signon-glib
mizdebsk: maven-verifier, saxpath
mjg: portmidi
mkyral: libaccounts-glib
mrunge: python-pytest4
musuruan: portmidi
nando: dssi, libinstpatch
neugens: powermock
neuro-sig: openigtlink, ctk
nonamedotc: dssi, libinstpatch
nucleo: libaccounts-glib
oget: dssi, libinstpatch
orion: python3-simplepam
pbrobinson: portmidi, dssi
pkubat: pgRouting
praiskup: rnv
python-sig: python-pytest4
radez: python-pytest4
rdieter: libaccounts-glib, signon-glib
rhughes: gnome-desktop
rrankin: portmidi
sdz: portmidi, dssi
sergiomb: portmidi
shlomif: portmidi
slankes: libaccounts-glib
spot: libarcus-lulzbot, python-uranium-lulzbot, lulzbot-marlin-firmware,
CuraEngine-lulzbot, cura-lulzbot
suve: connman, portmidi
tartina: jmeters, lv2-mdaEPiano, lv2-sorcer, lv2-swh-plugins, lv2-ll-plugins,
lv2-vocoder-plugins, dssi, meterbridge, lv2-c++-tools, lv2-fabla, lv2-newtonator
tdawson: rubygem-net-ssh-gateway
tejas: libaccounts-glib
terrycloth: portmidi
than: libaccounts-glib
thm: python-pytest4, dssi
thomasfedb: portmidi
tuxbrewr: portmidi
vascom: libaccounts-glib, dssi
verdurin: meterbridge
wolnei: libaccounts-glib
xavierb: portmidi
zbyszek: portmidi
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
3 years, 1 month
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
by Jared Dominguez
On Fri, Apr 8, 2022, 11:52 Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez <jaredz(a)redhat.com> wrote:
> >
> >
> >
> >
> > On Thu, Apr 7, 2022, 19:46 Samuel Sieb <samuel(a)sieb.net> wrote:
> >>
> >> On 4/7/22 14:51, Jared Dominguez wrote:
> >> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb <samuel(a)sieb.net
> >> > <mailto:samuel@sieb.net>> wrote:
> >> >
> >> > On 4/7/22 08:02, Jared Dominguez wrote:
> >> > > This is a proposal. Nothing has changed yet. The choice is now
> >> > whether
> >> > > to go forward with it or come together with a cohesive
> >> > > alternative, including one of the two listed in the proposal.
> But we
> >> > > need a solution that accounts for the existing maintainers not
> >> > having
> >> > > capacity to continue maintaining legacy code. I've seen
> responses
> >> > from
> >> >
> >> > I haven't yet seen a clear answer about what code is "rotting" and
> >> > which
> >> > legacy code is too hard to maintain. Is there something actually
> >> > broken
> >> > right now?
> >> >
> >> >
> >> > For one, syslinux hasn't seen an update in 3 years and a release in 7
> >> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
> >> > getting development attention. The current maintainers in Fedora won't
> >> > have capacity to continue maintaining legacy boot support in Fedora.
> As
> >> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
> >> > not to mention non-UEFI ppc64le and s390x), there is added risk of
> >> > regressions on legacy x86 boot that won't be getting developer
> attention.
> >>
> >> I don't understand why we're still using syslinux instead of grub for
> >> legacy boots, especially since I think now you can use the same grub.cfg
> >> file for both.
> >
> >
> > It's development and validation work for something that's not a priority
> for those who are doing bootloader work, and no one else has stepped up to
> put in the time to do this work. The change proposal being discussed in
> this thread is calling for community contributors.
> >
> >> There is always a risk of regressions, but if there is
> >> no current problem, then why is there this push to obsolete a lot of
> >> active hardware?
> >
> >
> > There is a problem: the current maintainers don't have capacity to
> support legacy x86 boot anymore. The code is going to bit rot if no one
> steps up to fill in.
> >
> >> This is not comparable to the 32-bit removal where it
> >> was only a few really old systems. This is going to affect decent
> >> systems that are less than 10 years old. I have a work HP laptop from
> >> 2012 that has "experimental" EFI support that really doesn't work well
> >> and possibly a newer one as well, but I can't check it right now.
> >
> >
> > I'm curious if you've updated your BIOS on that system. If it's really
> that bad, Microsoft (and HP customers) would have been on HP's case about
> fixing a bad user experience.
> >
>
> Why? It works for Windows, and HP has only done token support for
> other platforms over the past decade (see most recent thing promoting
> WSL as a good Linux on HP experience[1]). All of my HP computers have
> been extremely difficult to get Linux working on properly, which is
> why I stopped buying them.
>
If the experience is buggy with Windows too, HP probably has addressed that
as previously stated, which is why I asked about how up-to-date Samuel's
BIOS is. On several occasions I've seen complaints about firmware issues
that are solved by updating. Firmware is software too.
If not, that sounds like a big in Fedora and possibly Linux in general.
Windows is the reference operating system for most personal computer
manufacturers, whether we like it or not.
Just because Dell is sometimes good at its job doesn't mean everyone
> else is. The reality is that most aren't.
>
> [1]:
> https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collab...
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
2 years, 1 month
