Self Introduction: John M. Harris, Jr.
I'm a developer, currently working on a project called OpenBlox. To that end, I have packaged a library used by both my project and a project which is already packaged in Fedora. You may find that review request at the link below: https://bugzilla.redhat.com/show_bug.cgi?id=1308367 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GPG2 as default /usr/bin/gpg
Unless there are any issues with gpg, and to my knowledge there aren't, I can't see any important reason to default 'gpg' to 'gpg2', at least not for f24. I will say that if this is done, we need to be able to use the normal alternatives system (update-alternatives) to change what's used, without user changes worrying about being in conflict with package updates. On February 17, 2016 12:52:45 AM EST, Christopher wrote: >I just ran into this: >https://bugzilla.redhat.com/show_bug.cgi?id=1309175 >It's not a huge deal (and there are several workarounds, for git and >for >other tools which default ot using 'gpg'), but it highlights the >mismatch >between the default /usr/bin/gpg running gpg1, when other tools, like >gpg-agent, are tailored for gpg2. > >RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least >sometime in >RHEL6. >I'm not saying we shouldn't continue to ship gnupg1, but can we at >least >rename it, so gnupg package is version 2, and gnupg1 provides >/usr/bin/gpg1 >instead? This seems overdue. Is there any reason not to do this? > > > > >-- >devel mailing list >devel@lists.fedoraproject.org >http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Sent from my Android device. Please excuse my brevity. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Linux Presentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I would start by separating the idea of kernel and operating system. Linux is the kernel, and the GNU operating system is normally used. On February 23, 2016 9:26:49 AM EST, Jules Bashizi wrote: >Hi Guyz of Devel ! > >I am to present Linux to Intellectual lecturers and students at >University >, i am looking for good material where to write my slide from . > >My aim in this presentation will be to demistify Linux Operating System >and encourage more people to use the OS . > >If by any means , you know any material i can use from or any idea >please >send it to me . > >Thanks, > >Irenge B. Jules >MSC student @ Liverpool University >email : jbi.oct...@gmail.com >Tel No 07405834974 >U.K. > > > > >-- >devel mailing list >devel@lists.fedoraproject.org >http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org - -- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd Sent from my Android device. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJKBAEBCgA0LRxKb2huIE0uIEhhcnJpcywgSnIuIDxqb2hubWhAb3Blbm1haWxi b3gub3JnPgUCVsxsqwAKCRBPjwPGS7OP/fylD/9bQuNQPWMNN86ZMNZGnHaMxN0Y //FTG/5EywsPB5gQzEEQbTpAfmdGETpcQyCmY8JA78+H/0cYxlWO4UhsPcG89T96 BQFwK8OcHyrjsT2ZcPNS7eUjG+3QaZ28vcR91NnCGY6gWD7dZ+MNLRpNQp6hrZQz mnECtMpKmQgi+KicRZ3y38lmBlLHOR67x4EMjNmNEcoMNxELMT3gf8c38OnTmAeB 2xviqczjcepWR9Bk0RxmYMHSxr30UbPfBc2FBkkYzipGM4llPgLokEFi97DQ2SfP qJFHZJN3Ybzu0BtwXXJZjeRApOMWd7mpX+qGgHTK2XxQ5vcSga5xlpP5ldZLc36H tjMBNj5rBrrzbvL5/QpI1k3cgGXEQ+ZZaxj/5HpNJ2oAWyDRHUSE5QLf8a1rY4Df N6BfW0TW94siDlhKMXD7dnKUP13XA3yYqPoo8CHL2zpWq4I0ubXYMAGeGxaEvx6B 9lUPOQPVybEp2bLJU91AvOx4bNeI1UDy3eoxPNWhb9Kk6vGcq7gS5+5MoPMsalev m7gxI4lqmbYxqZYb4XnItnHofPsG2bwBUGtV0VJFB+iSysHgs3ugQkiu6jGSEL5v jHeSTM4hhtMEhTR0gzh25vsqjyprCwIuVqlrjbElSDNw0SX0zo+RLGKH4n/UiB6O ALrej5ixS8D9JF7GCw== =f59J -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 3D printing SIG
On Thu, 2016-03-17 at 17:14 +0100, Miro Hrončok wrote: > On 17.3.2016 16:08, Miro Hrončok wrote: > > > > Hi Fedorains, > > > > I was thinking about creating a 3D printing SIG in Fedora. Would > > anyone > > be interested in that? > > > > Miro > I've created a wiki page here: > > https://fedoraproject.org/wiki/SIGs/3DPrinting > > Feel free to add yourselves and improve the page in any way. > As I see it, the logical next step is to create an article for the Community Blog. If you would like to coordinate on this, we can discuss this on IRC in #fedora-3dprinting. -- John M. Harris, Jr. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 3D printing SIG
On Thu, 2016-03-17 at 16:08 +0100, Miro Hrončok wrote: > Hi Fedorains, > > I was thinking about creating a 3D printing SIG in Fedora. Would > anyone > be interested in that? > > Miro > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org I'm definitely interested. I have added my information to the wiki page. -- John M. Harris, Jr. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On Friday, May 29, 2020 1:24:30 AM MST Igor Raits wrote: > On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote: > > > On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote: > > > > > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit : > > > > > > > Please do not drop mod_php. It is NOT the case that "php-fpm is > > > > already > > > > used but most users of httpd and nginx without any issue." > > > > > > php-fpm is the default configuration for httpd and nginx for few > > > versions > > > > > > nginx ONLY uses php-fpm > > > > > > mod_php is httpd only and prefork mode only > > > so without threaded MPM and without http2 support > > > > > > Please describe issues, I don't have any bug report about this. > > > > > > Remi > > > > Yes, nginx only uses php-fpm. But that has nothing to do with > > mod_php. > > > > The default doesn't matter, there's absolutely no reason to take away > > the > > sysadmin's choice here. There are at least 40 servers I personally > > am > > responsible for where I see no reason to move from mod_php to php- > > fpm, for > > example. If you don't want to maintain it, I'd be happy to do so. > > Many third > > party packages expect mod_php, and nearly all documentation for > > configuring > > httpd for Fedora, CentOS and RHEL goes through the use of mod_php. > > There is > > just no reason to break this. People who want php-fpm will stick with > > it, and > > others will continue to use mod_php as we have for the last decade+. > > Many > > servers do not need http2, or other new features. Many of us have > > something > > that works, and we'd like to keep it working. > > That's what CentOS / RHEL is for. Are you saying that you believe Fedora is not suitable for long-term use? I really don't know why that would be, other than yanking out packages while they still work. However, this will have an affect on CentOS / RHEL as well, if it's removed from Fedora, it'll likely be removed there upon the next release. With that in mind, that's yet another reason this package should not be removed from Fedora. It'll break configs of the hundreds/thousands of users of Fedora's downstream projects, as well as a few hundred Fedora users. This is a change that will seriously break a lot of peoples' config during their next system-upgrade, absolutely needlessly. That it's not the default already negates any perceived security issues. -- John M. Harris, Jr. Splentity ___ 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: Fwd: Re: late generation of assemble code
On Friday, May 29, 2020 4:02:40 AM MST Paul Dufresne via devel wrote: > had forgotten to reply also to the list... doing it now: > > [cut the part where it was suggested to make package that contains LLVM > Intermediate Representation bitcode rather than CPU specific assembler] > > > On 2020-05-29 1:01 a.m., John M. Harris Jr wrote: > > > Paul, > > What benefit do you see in the overhead of LLVM IR, compared to standard > > packages? > > > John, > > Where do you see overhead in the distribution of LLVM IR? See below responses. > Advantages: > > * more space on the hard disks of the servers, because they contains > repositories only for LLVM IR packages rather than one by supported > architectures This may be a valid point, but I'm not sure it's really all that important. I'm currently mirroring 3 different arches of the Fedora repos, and the total disk space is 495G. That's not a lot of storage space these days, at least not for servers. Additionally, there are a number of packages that cannot be LLVM IR, which are needed to support running LLVM IR. Please also consider how initramfs would be handled. Statically compiled software or LLVM IR and the supporting software? > * less use of the CPU time of the servers because they don't optimize > code for specific CPUs Not handling this on the build servers means doing it on the end system, every time the program is run. > * very reduced cost for supporting more architectures, as code is > client-side generated Does LLVM IR have a way of handling arch-specific code? > * faster code on clients with recent CPUs, because code is optimized for > them, and was not in the old way of doing because you had to distribute > for a common base CPU How does LLVM IR accomplish this? Would it be slower on older CPUs, or does it specifically compile for the host CPU's micro-arch? > * CPU specific code generation and optimizations can be done on idle > time of the clients... there is not much idle time of the servers If it's going to be done on idle time of client systems, this is definitely not going to work in Fedora in general. Perhaps in Silverblue or other systems not designed to be a general purpose operating system? It actually might even work in Fedora Workstation, but then you'd have to separate Workstation from the base distro, assuming GNOME doesn't eat CPU idle time. -- John M. Harris, Jr. Splentity ___ 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: Fwd: Re: late generation of assemble code
On Friday, May 29, 2020 1:56:16 PM MST Colin Walters wrote: > > Perhaps in Silverblue or other systems not designed to be a general > > purpose operating system? > > What, where did you get that? Silverblue is general purpose. Well, Silverblue is mostly GNOME. It's not meant for servers, etc. > Anyways, my 2c on this topic: Once WebAssembly supports threads (it's > coming) there's going to be a lot of interesting discussion about > potentially using it in places where we compile native code in the > operating system and applications today. Err, what does WebAssembly have to do with real programs? > IOW, it doesn't make sense to invest much in LLVM IR versus WebAssembly. WebAssembly is just in web browsers. It's not for normal software you'd install with your package manager. Unless I'm missing something? -- John M. Harris, Jr. Splentity ___ 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: Supporting hibernation in Workstation ed., draft 1
On Friday, May 29, 2020 3:58:26 PM MST Chris Murphy wrote: > Hi, > > Fedora Workstation working group has been investigating the working > state of hibernation (suspend to disk) for about four months, and has > produced a draft status report on the findings so far. Present status, > impediments to support, and importantly, the specifics of how to > address those impediments, are described. > > This is a draft, to reflect on-going work in this area. It's intended > to be short and consumable. Suggestions welcome. I include the > synopsis below for better visibility and list search. > > https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md > > --- > > Synopsis: > > The Fedora Workstation working group recognizes hibernation can be > useful, but due to impediments it's currently not practical to support > it. This is a recognition of the current state of affairs, but the > working group wishes hibernation could be relied upon, and thinks > there is a viable approach for limited support of hibernation in the > future. We encourage interested parties to pursue the needed > improvements. In the meantime, given that hibernation isn't currently > viable, the workstation WG decides that technical decisions will not > be constrained by it. Decisions about Workstation's 'out of the box' > configuration might conflict with the requirements of hibernation. > There are desired enhancements to performance and security that are > hindered by the status quo. The working group will re-evaluate when > the significant impediments have been adequately addressed. > > We will support an install time means of enabling hibernation retained > via Custom partitioning. If the user chooses to create a swap > partition, the installer will include a resume=UUID kernel parameter > hint so that the kernel can find the hibernation image. I'm sorry, but this makes absolutely no sense. You can test hibernation right now, and it will work. When you boot back up, it'll have everything just as you left it. What systems is it broken on, those with Secure Boot? Is there something in GNOME that has changed in the past few releases which broke it? I've just taken a Lenovo T500, installed GNOME Workstation and gone into hibernation. It took about 30 seconds to boot back in, but I was right where I left off. What exactly is broken, and for what portion of users? -- John M. Harris, Jr. Splentity ___ 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: Supporting hibernation in Workstation ed., draft 1
On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote: > On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr > wrote: > > > > > > I'm sorry, but this makes absolutely no sense. > > > Disliking the story is not the same thing as it not making sense. > There isn't much I can do about the former, but if you have a specific > area where there is a lack of clarity, I'll try to clear it up. It's not that I don't like anything about this, it just doesn't seem to match the reality of the situation. > >You can test hibernation right > > now, and it will work. When you boot back up, it'll have everything just > > as you left it. What systems is it broken on, those with Secure Boot? > > Not broken, disabled. That's the policy both upstream and in Fedora. Then why not just re-enable it? Why in the world is it disabled? If it's disabled, why did it work when I ran `systemctl hibernate`? Why does it work with KDE Spin out of box? > > I've just taken a Lenovo T500, installed GNOME Workstation and gone into > > hibernation. It took about 30 seconds to boot back in, but I was right > > where I left off. What exactly is broken, and for what portion of users? > > > I don't know the Lenovo T500 firmware setup defaults. If it conforms > to Microsoft Windows (8 or later) hardware certification > specifications, then UEFI Secure Boot is enabled by default. And it > mean you changed the defaults to get the results you're experiencing, > thereby disabling a significant feature the Fedora invested > significant resources to explicitly support. The Lenovo T500 is one of the first or second generation EFI devices. The only settings that have been changed is the disabling of PXE and setting a boot settings password. I have access to some newer hardware that has Secure Boot that I can test with. I'll go and snag one of those now, and get a test install of Workstation going. I asked above, but it wasn't answered, and your answer to this has me a bit confused. Is Secure Boot the issue that is blocking resume from working properly? If so, I can ensure that Secure Boot is enabled on the hardware that supports it, and try hibernation there. Regardless, if that's the case, wouldn't it make more sense to keep hibernation available in the UI where it's supported well, the systems without Secure Boot? A trivial check for that could be false if BIOS, and false if efivars doesn't show that it was booted with secure boot. -- John M. Harris, Jr. Splentity ___ 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: Fwd: Re: late generation of assemble code
On Friday, May 29, 2020 5:15:45 PM MST Colin Walters wrote: > On Fri, May 29, 2020, at 8:01 PM, John M. Harris Jr wrote: > > > > WebAssembly is just in web browsers. It's not for normal software you'd > > install with your package manager. Unless I'm missing something? > > > You are indeed missing > > https://webassembly.org/docs/non-web/ > https://wasi.dev/ > > More random links, and I'm sure others have better ones: > > https://github.com/enarx/enarx/wiki/WebAssembly-(Wasm) > https://deislabs.io/posts/introducing-krustlet/ > https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ > https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html > https://hacks.mozilla.org/2019/08/webassembly-interface-types/ How does this compare to LLVM IR in terms of performance? What software do you believe it would make sense to ship as WebAssembly? Would it actually be beneficial compared to shipping software normally? With WebAssembly, it's getting to the point where I really just have to ask "Why?" when this sort of thing comes up. It seems that we're just looking for ways to overcomplicate things at this point, pulling in "Web" technologies for things that are surprisingly simple. Web browser vendors continue to surprise me with how overcomplicated these things are getting. I remember when web browsers didn't need gigabytes of RAM to function properly, when they didn't need to run in multiple processes. -- John M. Harris, Jr. Splentity ___ 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: Supporting hibernation in Workstation ed., draft 1
On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote: > On Sat, May 30, 2020 at 9:26 PM Tony Nelson > wrote: > > > > > > > On 20-05-30 21:02:11, Chris Murphy wrote: > > > > ... > > > > > Full disk encryption doesn't adequately secure the hibernation image > > > either. Authenticated encryption (signing as well as encryption) is > > > needed to verify the image hasn't been tampered. > > > > > > > > What can an attacker do other than corrupt the data? It is encrypted. > > > You don't know, and neither do I. That's the problem. We do know. Nothing, really. > > > > With tamper detection, does a single bit changed deny the use of the > > hibernated image? > > > I expect so. Even at a far lesser level of integrity, e.g. non-crypto > crc32c used by dm-integrity and Btrfs by default, a single bit flip is > detected and you get EIO on reads. > > > > In either case, what can an attacker accomplish? > > > I have the same question, exposing me as (a) not a very good attacker, > and (b) not a cryptographer. Nevertheless I'm persuaded by the > argument that if I've signed up for signature verification of the > kernel and kernel modules at the start (UEFI Secure Boot), that it's a > bad idea to enable a loop hole where unauthenticated data is executed. > It doesn't matter if it's encrypted. It provides no error detection > mechanism. Such a loop hole in effect is an attack on the Secure Boot > paradigm. > > And for now it's a difficult problem with limited resources committed > to resolving it. There are other ways to go about it, that also aren't > exactly easy but they might turn out to be more viable than AE > hibernation images. > > > > > The upstream work, cited in the document, gets into the details, > > > and what additional work is needed for the next revision. > > > > > > > > Which reference is that? #5? It seemed short. > > > I only provided a link to the most recent status. You need to click on > that link to get to the lkml email, and click on the link in there > too, and follow it to the patch set and ~18 email discussion. It's > short because it needs more work and the developer hasn't found enough > time to get back into it yet. > > -- > Chris Murphy A good option until then is to just take unsigned hibernation images and work like literally every other system. There's no reason to take away this functionality. -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Saturday, May 30, 2020 12:36:46 AM MST Chris Murphy wrote: > On Fri, May 29, 2020 at 9:12 PM John M. Harris Jr > wrote: > > > > > > On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote: > > > > > On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr > > > > > > > > > >You can test hibernation right > > > > > > > > now, and it will work. When you boot back up, it'll have everything > > > > just > > > > as you left it. What systems is it broken on, those with Secure Boot? > > > > > > > > > > > > Not broken, disabled. That's the policy both upstream and in Fedora. > > > > > > > > Then why not just re-enable it? Why in the world is it disabled? > > > It's a security risk that is incompatible with having UEFI Secure Boot > enabled. > The entire point of UEFI Secure Boot is to ensure cryptographic > verification that the kernel you're running is in fact a Fedora built > and signed kernel. Since resuming from hibernation completely replaces > memory contents with that of the image, if the hibernation image isn't > cryptographically signed too, it's an attack vector that permits > arbitrary code execution, including even in the kernel. > > I will add a footnote clarifying this in draft 2. > > The proper enhancement is signed and encrypted hibernation images. If > people want this to work, it's highly recommended they look into > picking up the stalled work in this area. There is hardware attrition > under way. And that means hibernation is getting tested less and less, > with fewer kernel and desktop bug reports. And testers. It's a real > going-concern problem. > > > >If it's > > > > disabled, why did it work when I ran `systemctl hibernate`? Why does it > > work with KDE Spin out of box? > > > Your system doesn't have UEFI Secure Boot or it isn't enabled. With > Secure Boot enabled, hibernation is one of many things that is subject > to kernel lockdown across all of Fedora products including KDE. > > https://lwn.net/Articles/706637/ > > > > I asked above, but it wasn't answered, and your answer to this has me a > > bit confused. Is Secure Boot the issue that is blocking resume from > > working properly? If so, I can ensure that Secure Boot is enabled on the > > hardware that supports it, and try hibernation there. > > > UEFI Secure Boot does not do the blocking. But it is used to enable > the kernel lockdown policy, and the lockdown policy inhibits various > things including hibernation. Specifically it will block both > hibernation entry and resume. > > [0.850908] Lockdown: swapper/0: hibernation is restricted; see man > kernel_lockdown.7 > > $ sudo systemctl hibernate > Failed to hibernate system via logind: Sleep verb "hibernate" not supported > > Which also results in this: > [109941.217325] Lockdown: systemd-logind: hibernation is restricted; > see man kernel_lockdown.7 > > > > > > > > Regardless, if that's the case, wouldn't it make more sense to keep > > hibernation available in the UI where it's supported well, the systems > > without Secure Boot? A trivial check for that could be false if BIOS, > > and false if efivars doesn't show that it was booted with secure boot. > > > I don't know whether or when there will be any changes to UI. I think > it's already conditional now. The option to hibernate appears in the > GUI on my test system that can hibernate and doesn't appear on the > systems it's not supported on. > > > -- > Chris Murphy In what way is it incompatible with UEFI Secure Boot? If the kernel and initramfs are signed, and the resume image is for that kernel, how is this an issue? What if swap is on LUKS? If kernel lockdown is what disables this, we should look at fixing kernel lockdown so that it doesn't break hibernation. This is definitely a security decision that we shouldn't be imposing on the masses needlessly, in my opinion. -- John M. Harris, Jr. ___ 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 Self-Contained Change proposal: Drop mod_php
On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote: > On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek > wrote: > > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote: > > > > > == Detailed Description == > > > By default php-fpm is used for a few versions. mod_php is not > > > supported for threaded modules. mod_php usage also increases security > > > risk, sharing the same process than httpd. > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > "prefork" mode, which will also use php-fpm. > > > > > > php-fpm is already used but most users of httpd and nginx without any > > > issue. > > > > > Based on the replies downthread, it seems that some people are still > > using it and want to keep it... > > > If the existence of non-zero user demand blocked removal of defunct > technology in Fedora I guess we'd still be shipping SysV init. > > We made the switch from forked-httpd + mod_php to threaded-httpd + > php-fpm by default in Fedora 27, so we've spread this transition over > six full release cycles. We've had AFAIK *zero* bug reports about > making the default switch. > > > > Is mod_php a maintainance burder and/or a noticable installation > > overhead when not used? And if it is, would additional help with the > > maintainance that was offered make it easier to keep? > > > I'm not seeing any technical argument in this thread to support keeping > mod_php. If there were, that would be interesting, but otherwise I > think the package owner should be trusted and empowered to make this > change. > > Regards, Joe If it's dropped, it wouldn't really be possible for me to make a mod_php package to replace it due to the integration, so I can't really see a way of keeping a compat package if it's removed, and keeping it around doesn't break anything. -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > I would expect that using an encrypted partition for swap should be > > sufficient to allow it though. > > > Unfortunately not. Encryption provides no integrity or authenticity. > The original set of patches for signed and authenticated hibernation > images called for the use of an HMAC for signing, and upstream > considered this insufficient and asked why not use AES-GCM to provide > a real AE (authenticated encryption) model. In what way do you believe it's not sufficient? > Not only is encryption alone inadequate, the signature verification > model should ensure that the hibernation image being restored was > created by the computer it is being restored to. Why? > I am not a cryptographer. And I can't do a better job of explaining > it. But it's a problem. And my disappointment isn't relevant to the > security issue. It's relevant from a UX perspective I suppose. It's a severe UX issue that you cannot use a standard feature of normal systems, hibernation. > But, I've also just spent two days trying to track down a new > hibernation bug, resulting in fatal hibernation entry. Even without > the Secure Boot issue, hibernation can be a problem that requires > resources that are not finite. I had this working reliably several > months ago, and I've exhausted my time and interest for now doing > kernel regression testing and have literally no idea why it's > consistently failing now. On three machines (one is a VM). I did > report it upstream, I haven't gotten a reply yet (normal). > > There are two emails, bottom one is the first. > https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4 > hf1nk...@mail.gmail.com/ > > -- > Chris Murphy -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote: > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr > wrote: > > > In what way is it incompatible with UEFI Secure Boot? > > > Secure Boot does boot verification. Hibernation right now doesn't. And > that makes it a Secure Boot loophole. And that makes it incompatible > with Secure Boot. > > It's not a new idea, it's been this way for a while. And so have the > complaints. https://lwn.net/Articles/523367/ > > > > initramfs are signed, and the resume image is for that kernel, how is this > > an issue? > > > The initramfs is not signed. > > > > What if swap is on LUKS? > > > No signature. No integrity. It is a net reduction in the protection > provided by Secure Boot - e.g. it can't detect intentional corruption > that could crash the system or even cause more corruption and eventual > data loss as the system runs. > > > > If kernel lockdown is what disables this, we should look at fixing kernel > > lockdown so that it doesn't break hibernation. This is definitely a > > security decision that we shouldn't be imposing on the masses > > needlessly, in my opinion. > > > Instead you propose imposing a loophole for attackers to easily deploy > malware needlessly. Do you really not see how this is an untenable > position for Fedora? In my opinion, the threat model you're proposing here is absurd. If people can create a valid kernel image that will be loaded from a LUKS container, we have bigger problems. -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 12:06:19 PM MST Simo Sorce wrote: > On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > > > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > > > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb wrote: > > > > > > > > > > > > > > I would expect that using an encrypted partition for swap should be > > > > sufficient to allow it though. > > > > > > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > > The original set of patches for signed and authenticated hibernation > > > images called for the use of an HMAC for signing, and upstream > > > considered this insufficient and asked why not use AES-GCM to provide > > > a real AE (authenticated encryption) model. > > > > > > In what way do you believe it's not sufficient? > > > AES GCM Is generally *not* a good algorithm for disk encryption so I am > not sure why this is being brought up, HMAC is sufficient to verify > integrity. I was asking why encryption itself would not be sufficient, nothing to do with AES-GCM, just to clarify. > In any case the problem is that adding integrity protection cannot be > done w/o losing some space on the disk, as you need to save the > integrity tag/hmac. > > As to why just encryption is not sufficient that is because you can > easily play a number of replay attacks, corruption attacks, and > potentially even sectors-wap attacks with naive encryption schemes. > > This can be sufficient to generate an attack vector in certain > circumstance once the machine boots up again. > > (As an hypotetical if the attacker is able to observe which sector > contains the passwd file and can corrupt it or replace it with other > content that effectively gives it access with a known secret or a blank > password or whatnot, or maybe it can create corruption in the kernel in > such a way that it causes the machine to display a OOM that reveals > encryption keys, or... the possibilities are endless). All of these are possible through many other methods, but all of these require physical access. Once you're talking about physical access, the threat model changes entirely. > > > Not only is encryption alone inadequate, the signature verification > > > model should ensure that the hibernation image being restored was > > > created by the computer it is being restored to. > > > > > > Why? > > > Evil maid attacks. > > Because without a signature you could replace the whole image with a > completely functional one that you fully control. This sounds like legitimate functionality that may be desired. Am I wrong? > Boot the system with a hybernation image generated on identical > hardware but with your own data, give your own decryption key, presto, > as soon as the hybernation image is restored the system is running your > image. From there you could be able to use, for example, keys stored in > the TPM or simply you capture the real password for the real image as > soon as the user returns to the machine to unlock it and transmit it, > and now you have access to the original disk image and all its > contents... > Again, possibilities abound. > > > > > > I am not a cryptographer. And I can't do a better job of explaining > > > it. But it's a problem. And my disappointment isn't relevant to the > > > security issue. It's relevant from a UX perspective I suppose. > > > > > > It's a severe UX issue that you cannot use a standard feature of normal > > systems, hibernation. > > > A way to deal with hybernation o secure boot would be to *measure* the > hybernated image as the last action of hybernation and store the > measure in TPM. Fail to restore on boot if the TPM fails to check the > measured image. (Measure here effectively ends up being running an HMAC > on the whole disk image you want to restore and storing the results in > TPM). The larger UX issue is that hibernation is disabled for ALL users just because it doesn't work for users with Secure Boot, which are probably a minority when it comes to those running Fedora, CentOS or RHEL, and I'm saying this as a CentOS/RHEL sysadmin and Fedora user. I'd like to see some data on that before saying for sure, of course. > > > But, I've also just spent two days trying to track down a new > > > hibernation bug, resulting in fatal hibernation entry. Even without > > > the Secure Boot issue, hibernation can be a problem that requires > > > resources that are not finite. I had this working
Re: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote: > On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr > wrote: > > > > > > On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote: > > > > > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr > > > > > > > > > > If kernel lockdown is what disables this, we should look at fixing > > > > kernel > > > > lockdown so that it doesn't break hibernation. This is definitely a > > > > security decision that we shouldn't be imposing on the masses > > > > needlessly, in my opinion. > > > > > > > > > > > > > > > Instead you propose imposing a loophole for attackers to easily deploy > > > malware needlessly. Do you really not see how this is an untenable > > > position for Fedora? > > > > > > > > In my opinion, the threat model you're proposing here is absurd. If people > > can create a valid kernel image that will be loaded from a LUKS > > container, we have bigger problems. > > > Disk encryption isn't enabled by default. The no encryption case > obviously has to be considered. In my opinion, it's already considered. With no disk encryption, it could work just as it does on every system without Secure Boot. > And if it's enabled, the more likely attack vector is sabotage to > induce a crash or corrupt user data, rather than malware injection. > Since you don't know the nature of the attack, and neither do I, > neither one of us knows when the corruption manifests or how. That would require physical access to begin with, and there are much more interesting things you can do once you have physical access. On all desktop systems I've used both personally and in enterprise rollouts, there are pins you can short to give yourself access to the firmware configuration. Even where there's "intrusion detection" and similar here, you can just delete those records after getting in. At that point, you could replace any point of the boot process, even potentially putting something like your own ME/AMT in. Laptops often have pads that function in the same way. The physical access requirement to abuse this means that it'd only affect specific enterprise clients, and generally would not be in the threat model of end users of Fedora. Once you have physical access, you can do a lot with any system. > I also don't know all of the threat models the upstream developers are > accounting for. Did you read all of the referenced lkml emails? Do you > understand why there's a preference for AES-GCM, why they want to > secure the encryption key in the TPM, and why they want to use TPM > localities? And why they wanted it all simplified as well? Which, I > think is sortof funny actually because none of it is very simple. If > you understand those concerns and still have questions, you might > consider directing your concerns upstream. I don't understand why, or where, there's a preference for AES-GCM. If you're talking about using that for the boot image, you're just putting another key the user is going to have to enter in front of them, which you've previously complained about. Simply placing the key in the TPM is a bad idea, because that leads to the exact same issue described above with physical access. While it's true some implementations wipe the TPM when you reset the boot firmware's settings, most do not. At that point, you've got the key from the TPM, you've got the key needed to decrypt the image and you're now able to get to the data on that system. -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote: > UEFI Secure Boot doesn't prevent you from gaining access to firmware > setup. It can cause some options in firmware setup to become > unavailable, e.g. compatibility support modules for presenting a > legacy BIOS. I'm skeptical that pin shorts permit you to gain access > to such things - but if so, it's clearly a vulnerability that should > be reported. This is by design. Generally, there's a marking on the silkscreen with something like "PWD" or "PASSWD" to mark it. -- John M. Harris, Jr. ___ 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: swap on zram
On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: > Ben Cotton wrote: > > > Swap is useful, except when it's slow. zram is a RAM drive that uses > > compression. Create a swap-on-zram during start-up. And no longer use > > swap partitions by default. > > > > == Owner == > > * Name: [[User:chrismurphy| Chris Murphy]] > > * Email: chrismur...@fedoraproject.org > > > I do not think it is safe to assume that zram is sufficient to completely > replace disk swap. We do not know how much RAM is actually available on all > users' machines, and the compressibility of RAM contents depends on the > individual user's workloads. > > So, I am opposed to this change as is. > > > > # Install systemd rust-zram-generator† package. This does not enable > > swap-on-zram, it only makes the generator available. > > > Also -1 to adding something to the core system that is written in a language > for which we do not even have dynamic linking support. Or even real > static linking support, as opposed to packaging libraries as source code. > Kevin Kofler Agreed. Besides, GNOME already has this enabled, right? It's definitely not right for servers, as I brought up the last time this was thrown around. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 3:20:30 AM MST Kamil Paral wrote: > On Thu, Jun 4, 2020 at 10:32 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > == Summary == > > > > Swap is useful, except when it's slow. zram is a RAM drive that uses > > compression. Create a swap-on-zram during start-up. And no longer use > > swap partitions by default. > > I haven't tested it personally on my system yet, but I've read the proposal > carefully (it's very well described, thank you!) and it sounds like a good > change, so thumbs up at the moment. This might offer much better system > interactivity under heavy RAM workloads compared to alternative OSes which > don't use RAM compression (e.g. Windows). I like that. If /dev/zram0 really > dynamically scales up and down and occupies no real memory when swap is not > used, I can't see any disadvantages there. The only thing is that it will > prevent using hibernation by default, but that's a whole different topic > that is dealt with separately and I understand it's sadly a very broken > feature at the moment anyway. At the moment, it seems that hibernation is only broken on systems with Secure Boot enabled, because of a kernel lockdown anti-feature. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel > wrote: > > > > > > > On 04.06.2020 22:30, Ben Cotton wrote: > > > > > Swap is useful, except when it's slow. zram is a RAM drive that uses > > > compression. Create a swap-on-zram during start-up. And no longer use > > > swap partitions by default. > > > > > > > > I'm strongly against this, because zram will replace disk swap and > > disable hibernation, which is very useful on laptops. > > > Already discussed in the 'support hibernation' thread. > > Most laptops today have UEFI Secure Boot enabled by default and > therefore hibernation isn't possible. And even when the laptop doesn't > have Secure Boot enabled, there's a forest of bugs. It works for some > people and not others. It was working for me on one laptop in > February, consistently doesn't work now and I haven't gotten a reply > yet from upstream about the problem. It may be true that most laptops have "Secure Boot" enabled, but not those running Fedora. We don't have numbers to support that claim, and most devices require "Secure Boot" to be disabled, or to have the mode changed so that it accepts new keys, to install Fedora. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 11:12:10 AM MST Neal Gompa wrote: > On Fri, Jun 5, 2020 at 2:09 PM John M. Harris Jr > wrote: > > > > > > On Friday, June 5, 2020 10:49:52 AM MST Chris Murphy wrote: > > > > > On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On 04.06.2020 22:30, Ben Cotton wrote: > > > > > > > > > > > > > > > > > Swap is useful, except when it's slow. zram is a RAM drive that > > > > > uses > > > > > compression. Create a swap-on-zram during start-up. And no longer > > > > > use > > > > > swap partitions by default. > > > > > > > > > > > > > > > > > > > > > > > > I'm strongly against this, because zram will replace disk swap and > > > > disable hibernation, which is very useful on laptops. > > > > > > > > > > > > > > > Already discussed in the 'support hibernation' thread. > > > > > > > > > > > > Most laptops today have UEFI Secure Boot enabled by default and > > > therefore hibernation isn't possible. And even when the laptop doesn't > > > have Secure Boot enabled, there's a forest of bugs. It works for some > > > people and not others. It was working for me on one laptop in > > > February, consistently doesn't work now and I haven't gotten a reply > > > yet from upstream about the problem. > > > > > > > > It may be true that most laptops have "Secure Boot" enabled, but not > > those > > running Fedora. We don't have numbers to support that claim, and most > > devices require "Secure Boot" to be disabled, or to have the mode > > changed so that it accepts new keys, to install Fedora. > > > > > > > This is not true. Fedora installs perfectly fine on Secure > Boot-enabled systems without any change to the enrolled keys. Our shim > package is signed by a key that has been required to be trusted for > virtually all x86 PCs for the past several years. > > The *only* case where Secure Boot must be disabled for the proper > functioning of a PC today is if you use the NVIDIA proprietary > drivers, because nobody is helping RPM Fusion set up a mechanism to > sign their driver and load the key into the kernel for trust. Most of the "Secure Boot" hardware I've gotten my hands on have been early generations, up to some produced in 2015. I've had to change the mode to "deployment" on some HP ProDesk systems in order to get it to install Fedora, for example. I can't speak for the most recent generations, but I remain skeptical due to the "lockdown" functionality breaking everything. Other times you'd need to do so are when you'd like hibernation support, any out of tree modules such as ZFS, kexec, hot patching.. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro > wrote: > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > wrote: > > > > > That is the plan, otherwise the swap-on-zram device probably never > > > gets used. And then its overhead, which is small but not zero, is just > > > a waste. > > > > > > > > I thought the plan was to get rid of the disk-based swap partition, > > since it has an unacceptable impact on system responsiveness? > > > Default new installations, yes. No disk-based swap partition. > > For upgrades, there's no mechanism to remove an existing > swap-on-drive. And the installer will still permit swap-on-drive being > added in custom partitioning. Both of these paths results in two swap > devices. > > We could ask Anaconda, if a custom installation creates swap-on-disk, > to remove /etc/systemd/zram-generator.conf. And in that case, users > will not get swap-on-zram. And we could also forgo the change being > applied on upgrades. It may be best to respect the user's decision, and not add a zram device on upgraded systems. This would lead to less unexpected behavior. I'd support that, for sure :) -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr > wrote: > > > > > > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: > > > > > > Also -1 to adding something to the core system that is written in a > > > language for which we do not even have dynamic linking support. Or > > > even real static linking support, as opposed to packaging libraries as > > > source code.> > > > > Kevin Kofler > > > > > > > > Agreed. Besides, GNOME already has this enabled, right? It's definitely > > not right for servers, as I brought up the last time this was thrown > > around. > > In discussions with both cloud and server folks, their use cases often > do not even create disk-based swap at all. A small swap-on-zram > provides all the benefits of inactive anonymous page eviction, > including reducing reclaim of file pages, without the black hole > performance problems of swap-on-drive. > > So yes it's well suited for these cases and the proposal does include > them. If they wish to be left out, that's up to those working groups. > It's possible to make sure /etc/systemd/zram-generator is not present. That doesn't seem to reflect reality. If you download the Server image right now, and go with its automatic partitioning scheme generation, it'll give you a swap partition on LVM. This is correct for most servers, not necessarily the LVM part, but having swap on disk. It really seems like this is wrong for most of Fedora, but that individual parts, such as Fedora GNOME or IoT, should be left to make the decision for themselves, without affecting the rest. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr > wrote: > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro > > > wrote: > > > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > > > > > > > wrote: > > > > > > > > > > > > > > > > > That is the plan, otherwise the swap-on-zram device probably never > > > > > gets used. And then its overhead, which is small but not zero, is > > > > > just > > > > > a waste. > > > > > > > > > > > > > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap partition, > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > swap-on-drive. And the installer will still permit swap-on-drive being > > > added in custom partitioning. Both of these paths results in two swap > > > devices. > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > > will not get swap-on-zram. And we could also forgo the change being > > > applied on upgrades. > > > > > > > > It may be best to respect the user's decision, and not add a zram device > > on upgraded systems. This would lead to less unexpected behavior. I'd > > support that, for sure :) > > > Contra argument: It also leads to fragmentation of the user base. Most > users use a distribution because they trust the decisions. And while > it is only a preference, not a policy the Workstation Product > Requirements Document says "Upgrading the system multiple times > through the upgrade process should give a result that is the same as > an original install of Fedora Workstation." > > There is a balancing act here that should be considered because a > large percent of Fedora users upgrade rather than reprovision. It > might even be the majority case. Well, that's for the GNOME stuff. This is a system-wide change proposal, is it not? Additionally, you could still be meeting that requirement here, as a new install with the same options selected, that is, to have a swap partition, would disable the zram device. That'd be a nice middleground for users like myself that don't have enough RAM to waste on a zram device. I'm writing this email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of my RAM to zram would kill my system's performance, if not quickly cause OOM. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr > wrote: > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > In discussions with both cloud and server folks, their use cases often > > > do not even create disk-based swap at all. A small swap-on-zram > > > provides all the benefits of inactive anonymous page eviction, > > > including reducing reclaim of file pages, without the black hole > > > performance problems of swap-on-drive. > > > > > > > > > > > > So yes it's well suited for these cases and the proposal does include > > > them. If they wish to be left out, that's up to those working groups. > > > It's possible to make sure /etc/systemd/zram-generator is not present. > > > > > > > > That doesn't seem to reflect reality. If you download the Server image > > right now, and go with its automatic partitioning scheme generation, > > it'll give you a swap partition on LVM. This is correct for most servers, > > not necessarily the LVM part, but having swap on disk. > > > The proposal recommends changing this. Cloud and Server folks will > decide what's best for their use cases, not me. In that case, would you be open to changing this proposal to only affect Workstation? -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote: > On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote: > > > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote: > > > > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr < > > > joh...@splentity.com> > > > wrote: > > > > > > > > > > > > > > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro < > > > > > mcatanz...@gnome.org> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That is the plan, otherwise the swap-on-zram device > > > > > > > probably never > > > > > > > gets used. And then its overhead, which is small but not > > > > > > > zero, is > > > > > > > just > > > > > > > a waste. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap > > > > > > partition, > > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > > swap-on-drive. And the installer will still permit swap-on- > > > > > drive being > > > > > added in custom partitioning. Both of these paths results in > > > > > two swap > > > > > devices. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap- > > > > > on-disk, > > > > > to remove /etc/systemd/zram-generator.conf. And in that case, > > > > > users > > > > > will not get swap-on-zram. And we could also forgo the change > > > > > being > > > > > applied on upgrades. > > > > > > > > > > > > > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram > > > > device > > > > on upgraded systems. This would lead to less unexpected behavior. > > > > I'd > > > > support that, for sure :) > > > > > > > > > > > > > > > Contra argument: It also leads to fragmentation of the user base. > > > Most > > > users use a distribution because they trust the decisions. And > > > while > > > it is only a preference, not a policy the Workstation Product > > > Requirements Document says "Upgrading the system multiple times > > > through the upgrade process should give a result that is the same > > > as > > > an original install of Fedora Workstation." > > > > > > > > > > > > There is a balancing act here that should be considered because a > > > large percent of Fedora users upgrade rather than reprovision. It > > > might even be the majority case. > > > > > > > > Well, that's for the GNOME stuff. This is a system-wide change > > proposal, is it > > not? Additionally, you could still be meeting that requirement here, > > as a new > > install with the same options selected, that is, to have a swap > > partition, > > would disable the zram device. That'd be a nice middleground for > > users like > > myself that don't have enough RAM to waste on a zram device. I'm > > writing this > > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where > > giving half of > > my RAM to zram would kill my system's performance, if not quickly > > cause OOM. > > > Either you did not read the page or I misunderstand how zram works. It > will take 3G of your memory and call it a SWAP. With a compression. So > essentially, if the starts will be aligned you will end up with 9G of > memory. Of course, if that is not enough, you can add on top of that > swap on the disk. How in the world would I end up with 9G of memory? That's not how this tech works, at all. Compression doesn't magically mean you get 2x the amount of memory as you reserve for it. Compression rates even for plaintext aren't normally that high. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 12:39:05 PM MST Igor Raits wrote: > On Fri, 2020-06-05 at 12:19 -0700, John M. Harris Jr wrote: > > > On Friday, June 5, 2020 12:16:36 PM MST Chris Murphy wrote: > > > > > On Fri, Jun 5, 2020 at 1:10 PM John M. Harris Jr < > > > joh...@splentity.com> > > > wrote: > > > > > > > > > > > > > > > > > > > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > > > > In discussions with both cloud and server folks, their use > > > > > cases often > > > > > do not even create disk-based swap at all. A small swap-on-zram > > > > > provides all the benefits of inactive anonymous page eviction, > > > > > including reducing reclaim of file pages, without the black > > > > > hole > > > > > performance problems of swap-on-drive. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So yes it's well suited for these cases and the proposal does > > > > > include > > > > > them. If they wish to be left out, that's up to those working > > > > > groups. > > > > > It's possible to make sure /etc/systemd/zram-generator is not > > > > > present. > > > > > > > > > > > > > > > > > > > > > > > > That doesn't seem to reflect reality. If you download the Server > > > > image > > > > right now, and go with its automatic partitioning scheme > > > > generation, > > > > it'll give you a swap partition on LVM. This is correct for most > > > > servers, > > > > not necessarily the LVM part, but having swap on disk. > > > > > > > > > > > > > > > The proposal recommends changing this. Cloud and Server folks will > > > decide what's best for their use cases, not me. > > > > > > > > In that case, would you be open to changing this proposal to only > > affect > > Workstation? > > > I think it is fine to have the proposal as it is. Those groups will > chime in if they do not like this approach. Having things consistent > across editions (in this regard) makes more sense to me tbh. What makes sense for desktops doesn't necessarily make sense for servers, or other environments. Fedora isn't just a desktop distro. Additionally, what GNOME folks believe to be best is normally not the best for other desktop environments. -- John M. Harris, Jr. ___ 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: Supporting hibernation in Workstation ed., draft 1
On Friday, June 5, 2020 4:32:55 PM MST Przemek Klosowski via devel wrote: > On 6/4/20 1:36 AM, John M. Harris Jr wrote: > > > On Wednesday, June 3, 2020 9:05:22 PM MST Chris Murphy wrote: > > > >> UEFI Secure Boot doesn't prevent you from gaining access to firmware > >> setup. It can cause some options in firmware setup to become > >> unavailable, e.g. compatibility support modules for presenting a > >> legacy BIOS. I'm skeptical that pin shorts permit you to gain access > >> to such things - but if so, it's clearly a vulnerability that should > >> be reported. > > > > This is by design. Generally, there's a marking on the silkscreen with > > something like "PWD" or "PASSWD" to mark it. > > I seem to remember reading that resetting the firmware away from secure > modes also wipes the secure TPM storage, so that you effectively wipe > the machine to factory-fresh state. On some systems, that is the case. I've found that it's pretty rare, but I don't have any real data to base that on, it's anecdotal. That doesn't matter for Fedora, you can still boot the same system you installed with Secure Boot enabled without it enabled. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 5:19:55 PM MST Kevin Kofler wrote: > Chris Murphy wrote: > > > So yes it's well suited for these cases and the proposal does include > > them. If they wish to be left out, that's up to those working groups. > > It's possible to make sure /etc/systemd/zram-generator is not present. > > > Also, why does this have to be a systemd generator? As a user administrating > his own systems, I find those to be extremely annoying, because they do > stuff behind my back that I never asked to happen and I have to mask them > (and/or uninstall them completely) to get rid of the unwanted behavior. > E.g., the systemd generator that tries to automount partitions not listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap > partition I have on my SSD in case I ever need it, which is normally NOT > mounted to avoid wearing out the SSD). So why does systemd want to > second-guess me and mount that partition behind my back unless I go out of > my way to mask the magic generator? > > So why can this zram feature not be a line in fstab, a parameter passed > through the kernel CLI, or some other solution that is easily tweakable and > that will definitely not affect upgrades of existing installations > (unlike yet another systemd generator, if it happens to get installed for > whatever reason)? > > IMHO, the only systemd generator that should ever mount partitions of any > kind (including virtual ones such as zram) is the systemd-fstab-generator. > If you want more stuff mounted, it should be added to /etc/fstab, that's > what that file is for! Completely agreed, going about it this way would also address most of my concerns with this change, as it would mean it's easy for people like myself to opt out. -- John M. Harris, Jr. ___ 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: swap on zram
On Friday, June 5, 2020 11:57:50 PM MST Samuel Sieb wrote: > On 6/5/20 11:43 PM, John M. Harris Jr wrote: > > > Completely agreed, going about it this way would also address most of my > > concerns with this change, as it would mean it's easy for people like > > myself to opt out. > > > If you don't want it, then disable the generator or uninstall it. I > don't understand why you're so against this. It's not even really new. > Is it because you don't understand it? Try it, you'll like it. It made > such a big difference on my laptop. I'm going to be activating it on my > other computers and servers as I get time. Most of the servers have > enough RAM to not need swap, but it makes a nice safety net with > virtually no overhead. On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why people seem to be repeating what seems to be the result of a placebo, saying that their system "feels more responsive" with swap on zram. People seem to be forgetting why swap on zram came up to begin with, it has nothing to do with system "responsiveness", which wasn't an issue. It had to do with dealing with OOM. Swap on zram isn't even a solution to that, it just changes how specifically it affects systems. For servers, swap is useful regardless of the amount of RAM. Swap is very nice for use as buffer/cache, and leaves space in RAM for whatever the server is running. For example, I always configure a 4 GiB swap partition on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit different depending on the workload, but it sets a very nice starting point. -- John M. Harris, Jr. ___ 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: swap on zram
On Saturday, June 6, 2020 3:37:13 AM MST Igor Raits wrote: > On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote: > > > Igor Raits wrote: > > > > > The change says it will use 50% of user’s RAM size, but not more > > > than > > > 4G. > > > > > > > > But if the machine has only, say, 4 GiB of RAM, then the amount of > > extra RAM > > you get that way might not be sufficient to avoid OOM. > > > > > > > > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > > > > > > > Also -1 to adding something to the core system that is written in > > > > a > > > > language > > > > for which we do not even have dynamic linking support. Or even > > > > real > > > > static > > > > linking support, as opposed to packaging libraries as source > > > > code. > > > > > > > > > > > > This is not fair. It is a programming language that is safer than C > > > and > > > is already used by some projects that we ship. rpm-ostree, firefox, > > > librsvg2 and others. > > > > > > > > 1. librsvg2 and firefox are not really core system components. They > > are > >UI-related packages (an image processing library and a web > > browser), > >which is at least one layer higher. > > 2. rpm-ostree is only a core system component if you use an ostree- > > based > >installation. In the default Fedora system, it is not. > > 3. I think that it is a bad enough precedent that even these packages > > are > >using Rust. We do not have a reasonable way to package software > > written > >in Rust. Packaging libraries as source code is not reasonable in a > > binary > >distribution. (And yes, I was opposed to the Go packaging > > guidelines from > >day 1, and the Rust packaging guidelines copy the same broken > > concepts, > >so I am opposed to those as well.) As a result, shipping Rust > > software in > >Fedora is very painful, because everything is essentially > > statically > >linked (actually compiled on demand at application compile time > > and then > >statically linked into the application). > > > Why is it painful? You have all dependencies packaged that follow > semver (not like Go) and it is quite easy to build those packages. > > Another example here could be nodejs, even though it does not link > statically it is just PITA to package since ecosystem is just full of > very small libraries that do not really like to cooperate so you need > to have tens of different versions of a lib in a repo. I consider this > much bigger problem than the Rust has in Fedora. > > > > 4. The Rust toolchain is also inherently foreign on Fedora because it > > is not > >based on GCC (but on LLVM). > > > That way you can say that mesa is foreign because it uses LLVM. If > there is ever alternative compiler to Rust that is based on GCC and has > feature parity, we can definitely consider trying it out. But the > referene compiler works just well. > > > > > > > > Core system components should be written in C. The higher layers (UI, > > extra > > CLI tools, etc.) can use C++ as well. IMHO, any other programming > > language > > is just a pain. > > > We also have Fedora CoreOS that uses > https://github.com/coreos/afterburn and > https://github.com/coreos/zincati that are written in Rust as well and > those are core system utilities. Sure, but Fedora CoreOS is not Fedora. Err, not Fedora, the distro. This is yet another example of how throwing all of these toys under the Fedora umbrella can sound confusing. -- John M. Harris, Jr. ___ 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: swap on zram
On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: > On 6/6/20 12:42 AM, John M. Harris Jr wrote: > > > On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, > > enabling swap on zram led to increased CPU usage (Always above 13% where > > normally idling at 6%!), and my entire system freezing after about 30 > > minutes. In all fairness, I don't know why my system froze, as I couldn't > > get anything over netconsole and sysrq wasn't working, but I think I'm > > going to leave it disabled. Swap on disk is more than fast enough for > > buffer/cache and hibernation/resume on my system. > > > I don't know why you had problems with it, but it's working on fine on > every system I've tried it on. It's not increasing my CPU usage. It's > probably actually lower due to less swap thrashing. There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my 8 GiB of swap. This is most likely the case for most casual users, those not compiling complex software on their system. This is with Firefox, Konversation, KMail, virt-manager and a few Konsole sessions open. > > I don't know why people seem to be repeating what seems to be the result > > of a placebo, saying that their system "feels more responsive" with swap > > on zram. People seem to be forgetting why swap on zram came up to begin > > with, it has nothing to do with system "responsiveness", which wasn't an > > issue. It had to do with dealing with OOM. Swap on zram isn't even a > > solution to that, it just changes how specifically it affects systems. > > > See, this is a clear indication that you don't understand what it is > doing and weren't listening to the various people trying to explain it. > It is definitely not a placebo. I gave zram 5G out of the 12G I have > and my laptop is performing way better now. It's not thrashing the disk > (SSD) every time I switch desktops or windows. Due to the number and > size of applications I'm running, I normally have to close Thunderbird > when I want to run Chrome. But now I can start Chrome up with no > problem. I converted my running system with no reboots and I didn't > change anything else about how I'm using the laptop. > > # zramctl > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lz4 5G 5G 1.7G 1.8G 4 > > 5GB of swap space that normally would be on disk is now taking less than > 2G of RAM. Instead of the usual 6G in the disk swap, now I have less > than 2. > > > > For servers, swap is useful regardless of the amount of RAM. Swap is very > > nice for use as buffer/cache, and leaves space in RAM for whatever the > > server is running. For example, I always configure a 4 GiB swap partition > > on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 > > GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a > > bit different depending on the workload, but it sets a very nice starting > > point. > > Swap is never used as buffer or cache, that doesn't even make sense. > Buffer is storing data before writing it to disk and cache is keeping > hot data somewhere with fast access. Why do you use so much swap on > your servers? The linear correlation with RAM is an obsolete idea and > was only somewhat valid when memory sizes were smaller. If you're using > any significant fraction of that swap space, your server is in trouble. It's not used for kernel buffer/cache, that's correct. -- John M. Harris, Jr. ___ 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: swap on zram
On Saturday, June 6, 2020 3:55:42 PM MST Chris Murphy wrote: > On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones > wrote: > > > > > > But let's say we also add a lower priority disk swap, then my next > > question ... > > > > > > > > > > Also does the swap partition on disk contain compressed pages, or > > > > uncompressed pages, or a mix of both? > > > > > > > > > > > > With zram there is no partition on disk, or was this question about > > > something else? > > > > > > > > ... means: Does this secondary swap partition (on disk) contain > > swapped out zram pages? Or uncompressed pages? (Or maybe the > > question just makes no sense, I don't really know.) > > > (ZRAM) > Compression is intrinsic to just the /dev/zram device. The swap code > doesn't share pages between swap devices. The higher priority device > is favored first until full. Once full, pages don't go through the > zram module, thus are not compressed, on their way to the > swap-on-disk. > > (ZSWAP) > So yeah, the swap-on-disk scenario might be better suited to a > generator that could use zswap instead, which uses an existing swap > partition and adds a write back cache (zpool) rather than a separate > device. I'm pretty sure (not 100%) that cached page are decompressed > on their way to the swap device. Also, the zpool memory cache is > preallocated, unlike zram devices. > > (I am not going to envy any who decide to implement zswap on a system > with ZFS. Wait wait wait, which zpool are you talking about?!) Which zswap are you talking about? Swap on compressed zvol has been called zswap at times. ;) - - John M. Harris, Jr. ___ 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: swap on zram
On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote: > On 6/6/20 10:41 AM, John M. Harris Jr wrote: > > > On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: > > > >> On 6/6/20 12:42 AM, John M. Harris Jr wrote: > >> > >> > >> > >>> On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, > >>> enabling swap on zram led to increased CPU usage (Always above 13% > >>> where > >>> normally idling at 6%!), and my entire system freezing after about 30 > >>> minutes. In all fairness, I don't know why my system froze, as I > >>> couldn't > >>> get anything over netconsole and sysrq wasn't working, but I think I'm > >>> going to leave it disabled. Swap on disk is more than fast enough for > >>> buffer/cache and hibernation/resume on my system. > >> > >> > >> > >> > >> I don't know why you had problems with it, but it's working on fine on > >> every system I've tried it on. It's not increasing my CPU usage. It's > >> probably actually lower due to less swap thrashing. > > > > > > There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my > > 8 GiB of swap. This is most likely the case for most casual users, those > > not compiling complex software on their system. This is with Firefox, > > Konversation, KMail, virt-manager and a few Konsole sessions open. > > Great, then it probably wouldn't benefit you, but it also would not harm > you at all either. In my case, my laptop was constantly thrashing the > swap and now it isn't, so I'm very happy about it. What was causing it to be constantly thrashing? Instead of breaking traditional systems even further, and ignoring the users' choice during upgrade, why don't we address the actual cause of the problem that some seem to have which led to the suggestion of using zram? -- John M. Harris, Jr. ___ 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: swap-on-ZRAM by default
On Sunday, June 7, 2020 11:51:38 AM MST Konstantin Kharlamov wrote:
> Hello! I see a proposal to enable zram by deafult¹. If I correctly
> understand this is the thread where it's being discussed. I have a few
> questions, answers to which probably would be nice to add to the
> proposal.
>
> 1. It says ZRAM gets enabled on upgrade. What's gonna happen to systems
> with ZSWAP is enabled? I guess it doesn't make sense to keep them both.
> 2. I was a bit shocked to see comparison to a system with 16GB of RAM.
> I admit the more the better, but most people still have only 8GB on
> their laptops/PCs, and sometimes there's just 4GB of RAM.
>My question is: given people with 4GB of RAM, are you sure that
> handing 2GB over to ZRAM gonna improve their experience?
>
> The third question touches the paragraph "Why not zswap?". The only
> point it mentions is that swap-device is not encrypted. Fair enough,
> although I wonder why this never has been regarded as a problem before.
An important consideration is that zram is *also* not encrypted. If that's
enough to rule out zswap, it should be enough to rule out zram too.
> I have an actual user experience which suggests ZSWAP might be a better
> choice. My gf is using Macbook with Fedora, with 4GB of RAM and an SSD
> device. She loves opening lots of tabs in a browser, and as you can
> expect RAM gets quickly exhausted.
>
> With 2GB of SSD SWAP she was getting lags sometimes ("sometimes", SWAP
> on SSD is much faster than on HDD). 3-4 months ago I enabled 1GB of
> ZSWAP, and lags are gone.
>
> Would your proposal with ZRAM help here? Sadly no, there's more to the
> story. The 2GB of SWAP turns out not to be enough, it gets regularly
> exhausted. I even had to create a script that pops up a warning when
> SWAP is low on space, so she'd close some tabs² (for some boring reason
> it's a bit hard to increase SWAP space there).
>
> Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> enough! The moral of this story is that you can't get away with only
> ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
> SWAP, ZSWAP fits more nicely there as a compressing buffer before the
> data finally spills over to disk.
>
> 1: https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap.3F
> 2:
> https://github.com/Hi-Angel/scripts/blob/master/warn-on-low-memory.pl
Zswap sounds like an excellent idea to look into instead of zram. Not only
that, but it'd allow traditional entry in fstab to configure it, instead of
some systemd magic that nobody knows about.
--
John M. Harris, Jr.
___
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: swap-on-ZRAM by default
On Monday, June 8, 2020 5:40:56 AM MST Dridi Boukelmoune wrote: > > Zswap sounds like an excellent idea to look into instead of zram. Not > > only > > that, but it'd allow traditional entry in fstab to configure it, instead > > of some systemd magic that nobody knows about. > > > In that case most of everything that happens on my system is magic, I > don't have comprehensive knowledge about everything I (possibly > indirectly) installed. > > But I am a happy zram-swap user, and while I don't remember the magic > incantation I do know that I found it either in release notes or > before the relevant Fedora release on this list as a self-contained or > system-wide change. > > It turns out to be even less magic than I would expect, I can easily > inspect the systemd part: > > $ systemctl cat zram-swap.service > > It turns out I can break the magic spell even one step further: > > $ file /usr/sbin/zramstart > /usr/sbin/zramstart: Bourne-Again shell script, ASCII text executable > > So the zram.noarch package is for the opposite of magic, and it is > very composable. All I needed to do was to install the package, > configure how much RAM I want to allocate for that purpose and enable > one service. > > In my mind fstab isn't composable because it requires concurrent > modifications in this scenario, and is (for my limited skills) harder > to keep track of who gets to touch it. > > I can't compare to other solutions, but I insist as someone who is not > knowledgeable in this area: following instructions when the > zram.noarch package landed and peeping a bit deeper felt like the > opposite of messing about with black magic. > > Now the difficulty for me was to remember how I set it up "back then" > (I don't even remember when) but after a quick search I was able to > find what I was looking for thanks to a boring straightforward name: > > $ systemctl | grep zram > > And with my findings: > > $ rpm -qf /lib/systemd/system/zram-swap.service > zram-0.4-1.fc32.noarch > > Only then did I realize that it was already mentioned in this thread's > first email... But well, my memory is as persistent as my zram. > > I was also aware of zram-generator but it doesn't look as polished in > terms of integration or documentation. Well, that's really the point. The one you're using is one of the (4? 5?) other zram implementations. It seems a bit more straightforward than the systemd one for sure. -- John M. Harris, Jr. signature.asc Description: This is a digitally signed message part. ___ 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: swap on zram
On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote: > Lennart Poettering wrote: > > > Well, if you don#t want that behaviour don't use the partition type > > UUIDs from the "discoverable partition spec" for your partitions. > > > > It's how these type uuids are defined: > > > > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > > > By using these partition type uuids you basically say: "please > > automatically mount me, thank you". > > > Uh, no. Any tools that create a partition table will use that UUID if I > create a swap partition. That's all that UUID really means: "this is a > GNU/Linux swap partition". You unilaterally redefined it to mean that the > partition should be automatically mounted even if I deliberately keep it > commented out in /etc/fstab. That conflicts with the original definition of > that UUID, which is followed by all the partitioning tools out there. > I have had the systemd-auto-gpt-generator masked on all my systems for years > (ever since I found out about its existence), and it will remain that > way, sorry. > > I was really angry back when I looked at the KSensors statistics, noticed > that the swap space was twice as large as expected, and realized that > systemd has decided to mount my spare swap partition on my SSD behind my > back and hence been using up my SSD behind my back for months. Thankfully, > the SSD still works years later, looks like I caught it early enough. (You > can be glad that you have that warranty disclaimer in the license, in any > case…) Ever since, systemd-auto-gpt-generator is masked. I wonder if we could get that masked in Fedora Server and KDE Spin, potentially along with homed, userdb, repart (Who in the world thought this was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've got to be kidding with these generators.. that's the DE's job, not the init system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd things thrown into an init system. These things are not discoverable at all. This stuff really needs to stop trying to guess what the user/sysadmin wants to do. -- John M. Harris, Jr. ___ 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: swap on zram
On Tuesday, June 9, 2020 2:24:02 AM MST Kevin Kofler wrote:
> John M. Harris Jr wrote:
>
> > I wonder if we could get that masked in Fedora Server and KDE Spin,
> > potentially along with homed, userdb, repart (Who in the world thought
> > this was a good idea?), resolved, networkd,
> > systemd-xdg-autostart-generator (you've got to be kidding with these
> > generators.. that's the DE's job, not the init system), systemd-sysusers,
> > systemd-growfs, and an ever growing list of absurd things thrown into an
> > init system.
>
>
> Are all those things enabled in Fedora by default? repart and growfs sound
> particularly scary to me. How do they even decide what partitions they want
> to create or grow? I definitely do not want systemd to mess with my
> partitions, even if it does not delete anything!
>
>
> > These things are not discoverable at all. This stuff really needs to stop
> > trying to guess what the user/sysadmin wants to do.
>
>
> Yes, I think this is going too far lately. I think the first generation of
> systemd modules, where the main idea was replacing ugly shell scripts with
> fast native C code, was a good idea, and systemd initially actually made
> things easier to configure (so I have never understood those systemd
> haters), but these days, the feature creep is adding complexity instead of
> removing it.
I completely agree. For example, I really like systemd as it is in RHEL7. Past
that, it's an ever growing list of things that have nothing to do with the
init system. Instead of being a fairly elegant init system, it's got more and
more cruft thrown in on top.
Contrary to what is repeatedly claimed, these do still run even if there's no
config, even if they don't do anything, which isn't the case. systemd-homed
was mounting /home where it was explicitly listed as `noauto` last time I
checked. See the output of `systemctl status systemd-homed` or `systemctl
status systemd-repart`. What's even more wild is that you can't easily disable
it. Even though it's supposed to be disabled ("vendor preset: disabled") it's
actually built into systemd, as a static unit.
To quote Lennart on one of these, userdb specifically, "not sure I get this?
why disable this at all? it's a tiny daemon, and shouldn't matter at all..."
> This reminds me more and more of that proprietary operating system which
> does lots of complex and controversial things without asking you and where
> you have to hunt down obscure registry keys in an attempt to hopefully stop
> it from doing those things.
Agreed on this as well, and that's making life hell for sysadmins and users
alike.
--
John M. Harris, Jr.
___
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: Datacenter move day 2
On Thursday, June 11, 2020 9:25:41 AM MST Ben Cotton wrote: > On Thu, Jun 11, 2020 at 12:08 PM Kevin Kofler > wrote: > > > > > > FYI, claiming the badge for the elections does not work, > > badges.fedoraproject.org spews an error 500 Internal Server Error. > > > > > > The badge claim URL should be valid for a few days beyond the end of > the voting period. If anyone is unable to claim the badge, they can > open an issue at https://pagure.io/fedora-project-schedule/new_issue > and I will manually award badges when the system is back online. > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis Ben, This has actually happened before the move started. It may be an issue with the Badges app. I mentioned this in #fedora-admin when I voted on the 28th of last month. (I later got the badge with the URL generated by voting for a different position) -- John M. Harris, Jr. ___ 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: Datacenter move days 3 and 4
On Thursday, June 11, 2020 9:09:53 PM MST Kevin Fenzi wrote: > We are working on getting this install moved over to recent > fedora or rhel, but for now it's rhel7 and python34. RHEL7 is better than RHEL8 anyway. ;) I'm planning to skip RHEL8 entirely, it's totally b0rked. -- John M. Harris, Jr. ___ 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: Datacenter move days 3 and 4
On Friday, June 12, 2020 2:26:43 AM MST Igor Raits wrote: > On Thu, 2020-06-11 at 21:24 -0700, John M. Harris Jr wrote: > > > On Thursday, June 11, 2020 9:09:53 PM MST Kevin Fenzi wrote: > > > > > We are working on getting this install moved over to recent > > > fedora or rhel, but for now it's rhel7 and python34. > > > > RHEL7 is better than RHEL8 anyway. ;) > > > > I'm planning to skip RHEL8 entirely, it's totally b0rked. > > > Good to know. Please avoid posting such messages to the mailing lists. > Thanks. Why? It was a somewhat sarcastic statement with an emoticon following, followed by an anecdote. I somehow don't think that email would upset the Red Hat overlords. They're well aware that many companies and projects won't be moving to RHEL8. -- John M. Harris, Jr. ___ 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: Regarding behaviour of Gnome and Fedora members
On Friday, June 12, 2020 3:50:59 AM MST Ty Young wrote: > Hi all, > > > Gnome recently has stirred up controversy lately and aren't taking other > people's opinions very well, to say the least. So far they've locked > three threads: > > > https://www.reddit.com/r/gnome/comments/gz6fks/we_must_all_speak_up/ > > https://www.reddit.com/r/gnome/comments/h107as/i_agree_with_the_we_all_must_ > speak_up_and_the/ > > https://www.reddit.com/r/gnome/comments/h0ml37/distrotube_has_posted_a_disgu > sting_video_calling/ > > They have engaged in racism and censorship in their subreddit's comment > sections and, just recently, banned me for posting this article, which > I've made: > > > https://medium.com/@youngty1997/gnome-needs-to-be-better-2151965fd663 > > > You may read it for yourself. In it I cite violations of Gnome's Code of > Conduct by members of the GNOME foundation or the GNOME > foundation(gnome.org email address), both on their subreddit and from > fedora-devel list. I tried to cite as much as possible but Gnome > moderators refused to hand over the moderation logs for when they locked > a thread for reporting a bug when asked. I'm confident that they know > what I'm talking about but just refuse to hand it over. > > > Keep in mind that, in Gnome's subreddit rules, it's perfectly OK to > criticize GNOME in GNOME's subreddit. It's even in the sidebar, which > you cannot see on old reddit(something I've told them about multiple > times, but they've ignored repeatedly to fix): > > > "We do not shy away from criticism, in fact, we encourage it!" > > > GNOME members have recently said that "This mixing of ideas from a wide > range of backgrounds is something that has improved free and open source > software, and it should be highly valued." > > > However, their actions by locking threads and now banned me for sharing > an article I had made goes against this statement. To be crystal clear > here, the opinions shared in the article are not *just* my own. You may > also read people who agree with my opinions in comment sections of the > GNOME subreddit and Fedora subreddit which I shared it to: > > > https://www.reddit.com/r/Fedora/comments/h7de62/gnome_needs_to_be_better/ > > https://www.reddit.com/r/gnome/comments/h7ddom/gnome_needs_to_be_better/ > > > Gnome did not say that any new threads on the topic could be made nor > was there any rule breakage that I could find. I would have loved to > cite more things but alas, I don't have access to the information. > > > Sadly the moderators of each respective subreddits have censored the > threads, and not even snew shows them for some reason. I've tried > contacting the fedora subreddit moderators but I have a feeling they > won't ever answer. > > > I was planning on fileing a Code of Conduct violation, but GNOME refused > to turn over the requested moderation logs, so I couldn't do so and, > Gnome's Code of Conduct hints as what the result will be anyway. I have > zero confidence that anything will be done, so here I am sending an email. > > > So, could anything be done about any of this? The projects themselves don't care what we actually support, it's the views of a very vocal handful that get thrown onto those sorts of things. Not a whole lot we can do about it, Ty. -- John M. Harris, Jr. ___ 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: Datacenter move days 3 and 4
On Friday, June 12, 2020 12:04:06 PM MST Michael Catanzaro wrote: > On Fri, Jun 12, 2020 at 9:47 am, John M. Harris Jr > wrote: > > > Why? > > > John, this was a thread about a data center move. There was no need to > change the topic. :) That wasn't a change to the topic, as I see it, it was very much in line with what was said in the previous email. It was just a response to the version of the OS it was running on is all. It is, however, a change of topic that we're now discussing a quip that didn't warrant this level of discussion. -- John M. Harris, Jr. ___ 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: swap on zram
On Wednesday, June 10, 2020 2:50:55 AM MST Kevin Kofler wrote:
> John M. Harris Jr wrote:
>
> > What's even more wild is that you can't easily disable it. Even though
> > it's supposed to be disabled ("vendor preset: disabled") it's actually
> > built into systemd, as a static unit.
>
>
> Have you tried masking the units? Disabling tends to have only limited
> success (because it only disables the unit loading by itself, but not it
> getting loaded by other units), masking is more effective.
I'm aware, and I have had success with masking the ones I've had issues with
so far.
--
John M. Harris, Jr.
___
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: RHEL 9 and modularity
RHEL and you > > do not plan to develop it *for Fedora*, but rather *for RHEL in > > Fedora*? > > > I wouldn't say that, nor do I personally think that. I think there is > value for Fedora as well. Matthew Miller has often given a common > example of having two streams of software that can build across RHEL, > Fedora, CentOS, etc. This is value for end user consumption, and > having older software available in Fedora is a usecase modularity can > help address. However, I would prefer to avoid discussing value to > Fedora in this thread. There are so many other threads debating that > already :) > > > > > Hopefully that provides some context and helps FESCo and the wider > > > community understand where Red Hat is headed with modularity on the > > > Enterprise side. > > > > > > > > Sadly no. It helps to understand your plans, however it does not help > > to understand the reasons behind, whether you can't change UX in the > > RHEL 9, or you think that technology is good enough for your use-cases > > or any other reasons. > > > The base requirement is that the UX remain largely the same. As I > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have > commonality so that our customers are not forced to learn something > entirely different to adopt RHEL 9. Improvements in the underlying > functionality are of course welcome and planned, but we are not going > to do something like replace modules with a different artifact type, > or add separate discrete repos per Application Stream, etc. Why is this a concern for RHEL9, where it wasn't for RHEL8? Moving to Modularity has certainly hurt RHEL7 migrations for exactly that reason, customers are forced to learn something entirely different to adopt RHEL8, and figure out undocumented issues with Modularity. > > > Basically this email just says "We decided for Modularity in RHEL 9 and > > we would like to do it in Fedora Infrastructure first". > > > Mostly, yes. We were told there was ambiguity on whether modularity > would be used in RHEL 9 or not. Very clearly it will, so I wanted to > get ahead of that. That's unfortunate, and definitely isn't in line with what I've been told in response to emails asking me to move my RHEL6 and RHEL7 systems to RHEL8, where I responded that we would wait for the next product. I can see how that may be out of line with your views, but I can't say it was really expected in this way. Thank you for clarifying. Has a stable Enterprise Linux product been considered, like RHEL5,6,7, perhaps moving Modularity to its own product for the few that have a use for it? -- John M. Harris, Jr. ___ 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: RHEL 9 and modularity
On Thursday, June 18, 2020 12:22:08 PM MST Josh Boyer wrote: > On Thu, Jun 18, 2020 at 1:59 PM John M. Harris Jr > wrote: > > > > > > On Thursday, June 18, 2020 6:24:46 AM MST Josh Boyer wrote: > > > > > > > The base requirement is that the UX remain largely the same. As I > > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have > > > commonality so that our customers are not forced to learn something > > > entirely different to adopt RHEL 9. Improvements in the underlying > > > functionality are of course welcome and planned, but we are not going > > > to do something like replace modules with a different artifact type, > > > or add separate discrete repos per Application Stream, etc. > > > > > > > > Why is this a concern for RHEL9, where it wasn't for RHEL8? Moving to > > Modularity has certainly hurt RHEL7 migrations for exactly that reason, > > customers are forced to learn something entirely different to adopt RHEL8, > > and figure out undocumented issues with Modularity. > > > Actually, it was a concern for RHEL 8 in many ways. The introduction > of default module streams was a direct result of wanting to help > customers that are used to running 'yum install mariadb' still be able > to do that. The fact that it is packaged in a module is transparent > for that usecase. Customers wanting to use non-default Application > Streams will indeed need to learn some new commands and concepts, but > they still have some analogs to other technology we use in RHEL 7, > like SCLs, where newer content is accessible in different channels via > different tools. By having modules be implemented in yum itself, > those concepts become more central and common to the distribution > overall. > > As with any new major release, there is always a need to introduce new > features or technology that causes some disruption. It is often the > only time we can do so in an Enterprise distribution. We try to > balance that with ease of use and adoption, which are always a top > concern. If you have issues with RHEL 8 and modularity, I would > encourage you to file a case in the Customer Portal. Getting that > feedback helps ensure we're addressing customer concerns. > > > > > > Basically this email just says "We decided for Modularity in RHEL 9 > > > > and > > > > we would like to do it in Fedora Infrastructure first". > > > > > > > > > > > > > > > Mostly, yes. We were told there was ambiguity on whether modularity > > > would be used in RHEL 9 or not. Very clearly it will, so I wanted to > > > get ahead of that. > > > > > > > > That's unfortunate, and definitely isn't in line with what I've been told > > in response to emails asking me to move my RHEL6 and RHEL7 systems to > > RHEL8, where I responded that we would wait for the next product. I can > > see how that may be out of line with your views, but I can't say it was > > really expected in this way. Thank you for clarifying. Has a stable > > Enterprise Linux product been considered, like RHEL5,6,7, perhaps moving > > Modularity to its own product for the few that have a use for it? > > > If you have problems with the RHEL 8 packages and functionality they > offer, please follow up through the support channels you have as a > RHEL customer. The distribution itself is quite stable, and in some > cases almost twice as performant as RHEL 7. I'd like to keep this > thread focused on Fedora, ELN, and modules if we can. The issues I've seen so far affect both Fedora and RHEL, but have gotten a bit better in Fedora. For example, a major concern that has been much worse in Fedora than RHEL, for obvious reasons: One month you can do a fresh install, install a package that, as it turns out, is a module for some reason. Then you install a fresh system the next month, install the same package. Perform a dnf update on the previous system, and you'll find that you have a different version of the package installed, because you're tracking a different version of a default stream. -- John M. Harris, Jr. ___ 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
On Monday, June 15, 2020 5:24:54 PM MST Kevin Kofler wrote: > Ben Cotton wrote: > > > == Summary == > > All retired packages are obsoleted by `fedora-retired-packages`. > > > > == Owner == > > * Name: [[User:msuchy| Miroslav Suchý]] > > * Email: msu...@redhat.com > > > Absolute -1! > > IMHO, removing working packages from users' systems just because the new > release no longer ships them is entirely unnecessary and a total disservice > to users. Agreed, this Change would irrecoverably harm users' systems upon an upgrade, entirely unnecessarily. -- John M. Harris, Jr. ___ 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: RHEL 9 and modularity
On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote: > TL;DR benefits of modularity for Fedora: > > * Automating build chains for producing artifacts > * Straightforward mechanism of producing non-rpm artifacts using our > existing tooling (modules -> flatpaks/containers/etc.) Both of these have nothing to do with Modularity, and can be done with existing RPMs. > * Path to provide alternative versions of stacks that don't natively > multiversion (Nodejs, Perl, PHP, etc.) Modularity doesn't support installing multiple versions of the same software. It's one of the key issues with the tech. -- John M. Harris, Jr. ___ 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: RHEL 9 and modularity
On Saturday, June 20, 2020 2:40:48 PM MST Neal Gompa wrote: > On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr > wrote: > > > > > > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote: > > > > > TL;DR benefits of modularity for Fedora: > > > > > > > > > > > > * Automating build chains for producing artifacts > > > * Straightforward mechanism of producing non-rpm artifacts using our > > > existing tooling (modules -> flatpaks/containers/etc.) > > > > > > > > Both of these have nothing to do with Modularity, and can be done with > > existing RPMs. > > > > > > > They have everything to do with Modularity, because that layer is > where that stuff was implemented. Modularity was the result of the > efforts involved with Factory 2.0, which gave us a lot of improvements > in our build infrastructure tooling for the first time since 2007. > Most of that rolled out in 2017, a full ten years after the last > revamp of our infrastructure. As far as I'm aware, flatpacks can be created without any Modules. Containers certainly can, we've been doing that for over a decade now without them. > > > * Path to provide alternative versions of stacks that don't natively > > > multiversion (Nodejs, Perl, PHP, etc.) > > > > > > > > Modularity doesn't support installing multiple versions of the same > > software. It's one of the key issues with the tech. > > > > > > > Modules can be designed to be parallel installable if the underlying > software natively supports that. For example, Python works that way > now, and thus in RHEL there are parallel versions of Python shipped as > modules. It doesn't change the nature of the software. > > But it makes it easier to make multiple complete, yet conflicting, > collections of a language stack. Where the underlying software already supports it, you don't need Modules to do that, just regular old packages. See Python, for example. Modularity is not a requirement for that. -- John M. Harris, Jr. ___ 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: RHEL 9 and modularity
On Saturday, June 20, 2020 4:37:06 PM MST Stephen John Smoogen wrote: > On Sat, 20 Jun 2020 at 17:42, Neal Gompa wrote: > > > > > > > On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr > > wrote: > > > > > > > > > > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote: > > > > > > > TL;DR benefits of modularity for Fedora: > > > > > > > > > > > > > > > > * Automating build chains for producing artifacts > > > > * Straightforward mechanism of producing non-rpm artifacts using our > > > > existing tooling (modules -> flatpaks/containers/etc.) > > > > > > > > > > > > Both of these have nothing to do with Modularity, and can be done with > > > existing RPMs. > > > > > > > > > > > > > > They have everything to do with Modularity, because that layer is > > where that stuff was implemented. Modularity was the result of the > > efforts involved with Factory 2.0, which gave us a lot of improvements > > in our build infrastructure tooling for the first time since 2007. > > Most of that rolled out in 2017, a full ten years after the last > > revamp of our infrastructure. > > > > > > > I think that John and others aren't aware of how a module is built > enough to understand what you meant by > * Automating build chains for producing artifacts > compared to how it is done normally. > > In normal times, a packager goes through a list of packages, updates > spec files with new tags and rebuilds them one by one as needed.. > sometimes multiple times because of bootstrapping or finding out that > the order you tried was wrong. A made up example from my days of doing > this for a different place (this isn't what is needed anymore but long > ago I had something similar): > bison > flex > gcc [options 1] > bison > flex > gcc [options 2] > glibc > bison > flex > gcc > > do them in one order and the apps came out working... do them in the > wrong order and it might not. Rust, Java and other language stacks > have similar loops. A packager may have to coordinate with multiple > people to do this several times. > > In a module, you write that all down in the manifest with the order > that you want packages built in and if you need to loop through them > with different options. Then MBS does the builds in an automated > fashion and it is repeatable. To me this is the biggest win here as > for various groups of mass-rebuilds it cuts down errors when order > matters and you have to do multiple ones to get from package set A to > package set A+1. > > Making it easier to make flatpacks and stuff also is built into the > tools which came with modularity. The tools which were doing it for > the Fedora buildsystem before this were 'fragile'. > > Yes a packager or system administrator can build these things without > the modularity build system but trying to do it in scale in Fedora > ended up needing the tools which came with MBS. While the tooling came at the same time, it doesn't necessarily need Modularity. See Ken Dreyer's example in the above subthread. We don't need Modules to do a lot of things that happened to drop around the same time, or that were created to work with Modularity. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Thursday, June 25, 2020 10:18:59 AM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > == Summary == > > Let's make Fedora more approachable, by having a default editor that > doesn't require specialist knowledge to use. As an alternative, I would like to recommend we make Emacs the default. Emacs does not require "specialist knowledge", but is much more powerful once you do learn how to use it properly. It's also not as hard to use as nano. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Thursday, June 25, 2020 2:38:13 PM MST Jan Kratochvil wrote: > On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote: > > > I'm not sure why you think end-users can't use a free OS. > > > First steps of end-users is to install Chrome, Spotify and VirtualBox. > So there is left no advantage of a Free OS. > > > > > I've run with SELinux enabled for years, rarely if ever causes problems > > for typical stuff. > > > Sooner or later something does not work. I do not want to open this can of > worms whether SELinux yes or not, it may be a good idea but IMNSHO it is > not for a development machine. I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Friday, June 26, 2020 12:51:32 AM MST Jan Kratochvil wrote: > I feel blind when I do not see what is happening and I feel scared it will > lock up again and I will be unable to debug it. Besides that it is much > more pretty to see what is happening and it makes the waiting time > shorter. > All pros and no con. Yes, it is a personal preference. Yes, I understand > most of computer users prefer "rhgb quiet". I have some doubts most of > _Fedora_ users really prefer it. There are lots of Fedora users, not just developers or "power users". Not many of them have any interest or knowledge of kernel or dracut debugging, especially now that systemd is part of the boot process. Those users who know how to debug that also know how to disable those cmdline options. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Friday, June 26, 2020 1:19:45 AM MST Jan Kratochvil wrote: > It does not as I have shown. Moreover it takes so much time to do dnf > command completion and one always has to ctrl-c it anyway. That is because > dnf should use cached results updated by cron and do not contact network > during interactive cache queries. If one really wants most fresh data there > is --refresh for that. This used to be the case, and then something broke it a few releases ago. 3-4 releases ago, you even had to explicitly install sqlite to get dnf completion to work, but that has been fixed as far as I'm aware. For me, dnf completion went from taking a few seconds to several minutes. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Friday, June 26, 2020 5:50:01 AM MST Markus Larsson wrote: > I like to think that I am part of everyone and I would love if we could > deliver smart solutions that doesn't needlessly change default behaviour > under the guise "advanced users will know how to configure this". We're getting to the point where there are so many things that "advanced users will know how to configure", it's absolutely absurd. You spend the first week with a fresh install customizing all the little things that used to be defaults, back when defaults were sane. -- John M. Harris, Jr. ___ 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: swap on zram
Of course more feedback and testing is needed, and it will be > taken into consideration. > > Note that the kernel zram doc says an excessively sized zram device > does come with overhead. Users's can increase the size easily > post-install, a capability they don't easily have with swap-on-drive. > The goal for Fedora 33 is a default that's useful and safe for the > vast majority of use cases. > > > Why not zswap? > > Zswap† is a similar idea, but with a totally different implementation. > It is swap specific, uses a RAM cache, and requires a conventional > swap partition existing already. It might be true certain workloads > are better suited for using zswap. But swap-on-zram depends only on > volatile storage. This is simpler and it's more secure. Whereas zswap > "spills over" into swap-on-drive and will leak user data if that swap > device isn't encrypted. Some workloads may do better with zswap, and > it's a valid future feature for a new generator, or possibly extend > zram-generator to support it via the configuration file. Maybe the > generator could favor zswap when swap-on-drive already exists; and > fallback to swap-on-zram? > > † > [https://www.kernel.org/doc/Documentation/vm/zswap.txt kernel.org > zswap.txt] > > == Benefit to Fedora == > > * significantly improves system responsiveness, especially when swap > is under pressure; > * more secure, user data leaks into swap are on volatile media; > * without swap-on-drive, there's better utilization of a limited > resource: benefit of swap without the drive space consumption; > * complements on-going resource control work, including earlyoom; > * further reduces the time to out-of-memory kill, when workloads exceed > limits; * improves performance for both "no swap" and "existing swap" > setups; > > > == Scope == > > * Proposal owners: > ** add zram-generator package to comps and kickstarts as appropriate > ** obsolete zram package (used by Fedora IoT) > ** means of per edition/spin configurations, if needed > ** coordinate a test day > > * Other developers: > **Anaconda are agreeable to deprecating their built-in implementation > in favor of swap-on-zram > **RFE's for zram-generator: users are not worse off if they don't > happen. Open request for help, to make it possible. It's much > appreciated. > [https://github.com/systemd/zram-generator/issues/10 RFE: should be > able to set a cap on zram device size #10] > [https://github.com/systemd/zram-generator/issues/8 RFE: should set priority > #8] > * Release engineering: [https://pagure.io/releng/issues #9495] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > > == Upgrade/compatibility impact == > > Add Supplements:fedora-release-common to zram-generator to pull it in > on upgrades. > > Existing systems without swap will have swap-on-zram enabled. > > Existing systems with swap-on-drive, will also have swap-on-zram > enabled (two swap devices), with higher priority for the zram device. > Existing swap-on-drive will not be removed. > > 'zram' package contains zram-swap.service and associated bash scripts, > and is currently used by Fedora IoT and ARM spins. It will be > obsoleted to avoid conflicting/duplicative swap-on-zram > implementations. > > > == How To Test == > > Any hardware. Any version of Fedora. > > # dnf install zram-generator > # cp /usr/share/doc/zram-generator/zram-generator.conf.example > /etc/systemd/zram-generator.conf > # Edit the configuration > # Reboot > # Check that swap is on a zram device: zramctl, swapon > # Detailed check: journalctl -b -o short-monotonic | grep 'swap\|zram' > # Check that priority is higher than existing swap if two or more are > listed. ## (Enhancement is needed for this.) > > Suggested configuration file values: > [zram0] > memory-limit = none > zram-fraction = 0.5 > > Feel free to run your usual workloads more aggressively or in > parallel. Suspend-to-RAM and suspend-to-drive are expected to continue > to work too (or at least hit all the same bugs as without zram being > used). > > Also, you can see the actual compression ratio achieved with the > following command: > zramctl > > > Test Day > > [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to > discover edge cases, and tweak the default configuration if necessary > to establish a good one-size-fits all approach. > > > == User Experience == > > The user won't notice anything displeasing. If their usual workload > causes them to dread swap t
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
#x27;t be created between > subvolumes. From this perspective, subvolumes start looking more like > a separate file system. But subvolumes share most of the other trees, > so they're not truly independent file systems. They're also not block > devices. > > == Benefit to Fedora == > > Problems Btrfs helps solve: > > * Users running out of free space on either / or /home > [https://pagure.io/fedora-workstation/issue/152 Workstation issue > #152] > ** "one big file system": no hard barriers like partitions or logical > volumes ** transparent compression: significantly reduces write > amplification, improves lifespan of storage hardware > ** reflinks and snapshots are more efficient for use cases like > containers (Podman supports both) > * Storage devices can be flaky, resulting in data corruption > ** Everything is checksummed and verified on every read > ** Corrupt data results in EIO (input/output error), instead of > resulting in application confusion, and isn't replicated into backups > and archives > * Poor desktop responsiveness when under pressure > [https://pagure.io/fedora-workstation/issue/154 Workstation issue > #154] > ** Currently only Btrfs has proper IO isolation capability via cgroups2 > ** Completes the resource control picture: memory, cpu, IO isolation > * File system resize > ** Online shrink and grow are fundamental to the design > * Complex storage setups are... complicated > ** Simple and comprehensive command interface. One master command > ** Simpler to boot, all code is in the kernel, no initramfs complexities > ** Simple and efficient file system replication, including incremental > backups, with btrfs send and btrfs receive > > == Scope == > * Proposal owners: > ** Submit PR's for Anaconda to change default_scheme = > BTRFS to the proper product files. > ** Multiple test days: build community support network > ** Aid with documentation > > * Other developers: > ** Anaconda, review PRs and merge > ** Bootloader team, review PRs and merge > ** Recommended optimization chattr +C set on the > containing directory for virt-manager and GNOME Boxes. > > * Release engineering: [https://pagure.io/releng/issue/9545 #9545] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Change will not affect upgrades. > > Documentation will be provided for existing Btrfs users to "retrofit" > their setups to that of a default Btrfs installation (base plus any > approved options). > > == How To Test == > > '''''Today''''' > Do a custom partitioning installation; change the scheme drop-down > menu to Btrfs; click the blue "automatically create partitions"; and > install. > Fedora 31, 32, Rawhide, on x86_64 and ARM. > > '''''Once change lands''''' > It should be simple enough to test, just do a normal install. > > == User Experience == > > Pros > > * Mostly transparent > * Space savings from compression > * Longer lifespan of hardware, also from compression. > * Utilities for used and free space, CLI and GUI, are expected to > behave the same. No special commands are required. > * More detailed information can be revealed by btrfs > specific commands. > > Enhancement opportunities > > [https://bugzilla.redhat.com/show_bug.cgi?id=906591 updatedb does not > index /home when /home is a bind mount] Also can affected rpm-ostree > installations, including Silverblue. > > [https://gitlab.gnome.org/GNOME/gnome-usage/-/issues/49 GNOME Usage: > Incorrect numbers when using multiple btrfs subvolumes] This isn't > Btrfs specific, happens with "one big ext4" volume as well. > > [https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/88 GNOME Boxes, > RFE: create qcow2 with 'nocow' option when on btrfs /home] This is > Btrfs specific, and is a recommended optimization for both GNOME Boxes > and virt-manager. > > [https://github.com/containers/libpod/issues/6563 containers/libpod: > automatically use btrfs driver if on btrfs] > > == Dependencies == > > None. > > == Contingency Plan == > > * Contingency mechanism: Owner will revert changes back to LVM+ext4 > * Contingency deadline: Beta freeze > > * Blocks release? Yes > * Blocks product? Workstation and KDE > > == Documentation == > > Strictly speaking no documentation is required reading for users. But > there will be some Fedora documentation to help get the ball rolling. > > For those who want to know more: > > [https://btrfs.w
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
using btrfs" like one commentator > at Reddit wrote. > The btrfs-check is also a massive can of worms and it cannot be safely run. > At least not without reading pages upon pages of manual and becoming an > expert in understanding how btrfs works. Expecting every Fedora end-user to > do this is unrealistic in many different ways. > The btrfs has no native encryption to my knowledge. However alternatives > such as zfs already has a trusted and reliable encryption used in numerous > FreeNAS installations around the world. > And much of these issues and many more are straight up mentioned in btrfs' > own wiki pages at kernel.org where one of the most shocking admissions is: > "So, in general, it is impossible to give an accurate estimate of the > amount of free space on any btrfs filesystem. Yes, this sucks." > Source: > https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complicated > .3F > And these are the brains before btrfs admitting this that there is no > solution for this. No amount of userspace tools developmen and UX/DE > integration is going to solve this for the end-users. > Please, don't switch to btrfs. It is not mature. It is not well-understood. > It is not properly "battle-tested". It can still die on its own. It's just > a ridiculous meme file system. At this point it would take me some decade > of smooth sailing at OpenSUSE side to start believing that btrfs is ready > for prime time in my own personal Fedora systems. Even 5 years of smooth > sailing would give more faith in it. But as it stands I have to strongly > oppose btrfs. It's too much of a headache with no relief in-sight. > > -- > Antti (Hopeakoski) > > P.S. Sorry for this emotional nature of this message. But I really, really > like my Fedora and I really, really dislike btrfs due past highly negative > experiences with it (some of them happening to me as recently as last > year). Another way to consider this would be that we can stop arguing against these changes, let the GNOME folks run the ship aground, and hope that the user backlash will act as a wakeup call when it comes to these changes. I agree that btrfs is far too unstable to be made a default, and I also agree that ZFS would be a much better option. However, there is always going to be pushback on ZFS. If you want the best, there's a price to pay, and that's licensing headaches in this case. In the end, it doesn't really matter what we say. All of the arguments in this thread are likely to be ignored by FESCo, as they have in other recent change "proposals" (more like change announcements, in this case). So, perhaps we should just watch this fail, and use that failure to push a sane default in the next release. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Friday, June 26, 2020 8:22:49 AM MST Matthew Miller wrote: > On Fri, Jun 26, 2020 at 11:15:24AM -0400, Michael Watters wrote: > > > Why not zfs? > > > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is not > really intended for the laptop use case. Has that actually been explored? How does Canonical get around the legal issues with OpenZFS' licensing? -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote: > On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote: > > I definitely agree on taking out "rhgb quiet", that's annoying as all > > hell, > > not knowing what's going on during the boot process. > > > Why does the user need to know what's happening when system boots? So that they know what goes wrong, when something goes wrong. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Saturday, June 27, 2020 9:50:20 AM MST John M. Harris Jr wrote: > On Thursday, June 25, 2020 10:18:59 AM MST Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > > > == Summary == > > > > Let's make Fedora more approachable, by having a default editor that > > doesn't require specialist knowledge to use. > > > As an alternative, I would like to recommend we make Emacs the default. > Emacs does not require "specialist knowledge", but is much more powerful > once you do learn how to use it properly. It's also not as hard to use as > nano. > -- > John M. Harris, Jr. Please don't take this seriously. I wrote that email to show that text editor preferences are subjective, and that different people have different ideas of "simple". -- John M. Harris, Jr. ___ 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: swap on zram
On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote: > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > is really getting out of hand. > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > there are at least of few of y'all who feel strongly about some of these > defaults. I encourage you to make a spin that caters to that experience. Whoops, I forgot we can have spins with different defaults from the entire distro now. That wasn't the case last time I looked into that, and I was going to create a Remix. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Thursday, June 25, 2020 1:27:06 PM MST Michael Catanzaro wrote: > On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney > wrote: > > > Are you sure this will work? I just ran a test, and putting a new > > config file inside /usr/lib/environment.d only works for Gnome, and > > doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal > > in the respective session and examining the environment variables). > > From what I gather in [1], systemd is not a standard way of > > interacting with the user's environment variables, and only Gnome has > > decided to use it. So this method of implementing this change seems > > to be making the default editor for Gnome be nano and not changing > > the defaults for anyone else. > > > Erm... well, no. Plan foiled? > > The goal of using /usr/lib/environment.d was to avoid setting more > environment variables in random places in various shell scripts. But if > that only works in GNOME, I guess it's not a great solution after all. Actually, that may be the perfect solution.. This way, it'd be a self contained change to the GNOME spin, and wouldn't affect the rest of Fedora. I'd be +1 on that. -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Friday, June 26, 2020 11:09:31 AM MST Matthew Miller wrote: > On Fri, Jun 26, 2020 at 12:50:52PM -0500, Michael Catanzaro wrote: > > > That actually works really well, and we should seriously consider > > doing it. Or at least suggesting it to upstream. > > > > It doesn't even take extra space. Only uses the bottom row that > > would otherwise be empty. > > > Fine :) https://github.com/gwsw/less/issues/72 See Markus Larsson's comment on this above... -- John M. Harris, Jr. ___ 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: Make nano the default editor
users or gain new Fedora users and developers? Fedora doesn't have a > business interest in users being forced to learn vi like Apple does with > users learning to use the App Store. > > > >Would that be a possibility here? I've upgraded my fedora workstation so > >many times, I'm not sure what our firstboot screens look like anymore, > >but would it be worthwhile to present users with some text, or a guide > >wizard, to point out files like their ~/.bashrc file with some commented > >text that shows clearly what some useful environment variables are, and > >how they might set them to customize their experience? Its not very 'just > >press the button to do something you may or may not understand', but it > >targets new users as part of firstboot, and introduces them in a somewhat > >friendly way to how things look under the covers, so they can make > >adjustments as their needs dictate. Even if they don't do it immediately, > >they will have a reference to something they can recall if they find later > >that their choice of editor is not something they are comfortable with. > > > Sounds like something suitable for gnome-initial-setup. I think /etc/motd > with that info would be useful on the non-workstation releases. Slackware > always installed a "welcome" email to the root user with similar info. > OpenBSD has 'man afterboot'. There's a lot we can do here. The common > thing appears to be helping guide the user. For text editing, nano does > that better by default than other text editors. > > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT Please keep in mind that there is more to Fedora desktop than the GNOME Spin. There's nothing like gnome-initial-setup for KDE Spin, or any of the other desktops. -- John M. Harris, Jr. ___ 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: swap on zram
On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote: > > > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > > is really getting out of hand. > > > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > > there are at least of few of y'all who feel strongly about some of these > > defaults. I encourage you to make a spin that caters to that experience. > > > I'm a fan of spins too, but making a spin to do > 'touch /etc/systemd/zram-generator.conf' seems a bit much. Far from just that: - Mask/disable systemd-homed - Mask/disable systemd-userdb - Mask/disable systemd-sysusers - Mask/disable systemd-repart - Mask/disable systemd-resolved - Mask/disable systemd-networkd - Mask/disable systemd-timesyncd - Disable systemd-xdg-autostart-generator - Remove the privacy anti-feature of using Google DNS when none are configured - Disable fstrim.timer - Disable EarlyOOM - Not set a default EDITOR - Not use btrfs or XFS as the default filesystem - Have no modular repos by default From this list, I know it might look like I'm calling out systemd. Well, that's just because it's become so bloated. -- John M. Harris, Jr. ___ 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: User experience issue on btrfs
On Sunday, June 28, 2020 6:45:24 PM MST Alexandre de Farias wrote: > *snip* > > At this point, I'm fine with what I have and BTRFS usage would be > strictly for testing. Also, is there any reason as to why RHEL went > with XFS as a default and Fedora stayed with ext4? I mean, if it was a > conscious choice, the rationale then seems to be the exact opposite of > the rationale for making BTRFS the new default. XFS proved to be troublesome, and still is up to the latest of RHEL7. It's not uncommon to have to run xfs_repair on smaller XFS partitions, especially / boot. I'm not sure if btrfs has the same issue there? -- John M. Harris, Jr. ___ 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: User experience issue on btrfs
On Sunday, June 28, 2020 6:06:06 PM MST Michael Catanzaro wrote: > 3. Users should not be expected to customize anything or use the > command line, ever, period. So for the purposes of figuring out what's > causing this performance issue, it sounds very useful to test different > mount options. But an actual solution must not require any > customization. If you really believe that, I really don't understand why are you in favor of all of these changes with the justification being "People who don't like it can just change it." -- John M. Harris, Jr. ___ 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: User experience issue on btrfs
On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote: > Once upon a time, John M. Harris Jr said: > > > XFS proved to be troublesome, and still is up to the latest of RHEL7. It's > > not uncommon to have to run xfs_repair on smaller XFS partitions, > > especially / boot. I'm not sure if btrfs has the same issue there? > > > [citation needed] > > I haven't run xfs_repair in probably 15 years (and so never on Fedora or > RHEL/CentOS). I haven't had time to figure out why the RHEL systems I have that are (mistakenly I assume, though they were created before I was hired) using XFS run into that issue, after about a month, they report 100% disk space utilization on /boot, and I've gotta run xfs_repair in order to fix that. In the unlikely event that I have the time to figure out why, before I just re- install them (which is already planned), I'd be happy to follow up with a citation. :) -- John M. Harris, Jr. ___ 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: Make nano the default editor
On Sunday, June 28, 2020 7:51:40 PM MST Matthew Miller wrote: > On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote: > > > > Fine :) https://github.com/gwsw/less/issues/72 > > > > See Markus Larsson's comment on this above... > > > Yeah, but as Michael points out, that doesn't really apply: it takes up > literally zero additional screen space. The bottom row is normally just as large as the file name, or is even just blank, in the case of streams, and doesn't distract from the file/stream content. Adding that text is unnecessary clutter. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Sunday, June 28, 2020 11:31:15 PM MST Mark Otaris wrote: > The master branch for cp now defaults to copy-on-write on filesystems > that support reflinks, which should make copies more efficient if > Fedora starts using btrfs: > https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25725f9d41735d176 > d73a757430739fb71c7d043. > Dolphin and KIO also seem like they will start doing this: > https://bugs.kde.org/show_bug.cgi?id=326880, > https://invent.kde.org/frameworks/kio/commit/c2faaae697f11ee600989b67b440698 > 1838ae628. > Beyond these recent changes, there are many other reasons to use > btrfs, such as that Podman has a btrfs driver that might make > containers more efficient, that ostree makes limited use of reflinks > when they are available, that many filesystem options can be changed > and new features and better defaults used even after the filesystem > was initially created, that resize operations can be done online, and > that there are uniform checksums on all metadata blocks, giving > guarantees against corruption. > > XFS also has reflinks, but lacks many features of btrfs, and switching > from ext4 to XFS would mean losing cgroup writeback. XFS would mean > no transparent compression too. > > Switching from ext4 to OpenZFS, even putting aside license concerns > from Red Hat, risks kernel releases being delayed or Fedora not being > able to release with recent kernels. It makes kernel updates in Fedora > dependent on the OpenZFS community releasing new versions compatible > with recent kernels fast enough. And this is a concern, because many > upstream kernel maintainers indicated they have little interest > in avoiding breaking OpenZFS or doing any extra work to get it to > work. (See, notably, https://lkml.org/lkml/2019/1/10/733 > and https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841.) > I appreciate that Fedora’s kernel maintainers release new kernels quickly > and think this is something that works well in Fedora. > Supporting any out-of-tree modules in Fedora repos, including > filesystems, would endanger this. > > Also, in general, I think it is not a good idea to use things that > your upstreams are not interested in, do not want to support, and do > not recommend using. > > Staying on ext4 means not having reflinks, transparent compression, > online resize, deduplication, strong guarantees against corruption, > and that improved filesystem defaults or new features can be used only > by recreating the filesystem and reinstalling Fedora. In consideration > of that, I am favorable to the change proposal targeting btrfs > in Fedora. For the best filesystem ever created, ZFS, I can't say that I agree with your assessment of that value. Having ZFS in Fedora would throw Fedora over the top as being the best Linux distro, hands down. I can count the number of times that having root on ZFS has led to me waiting on kernel updates over the past three years on one hand, and could still do so if I had half as many fingers! -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Sunday, June 28, 2020 5:14:14 PM MST Gerald Henriksen wrote: > On Sun, 28 Jun 2020 09:59:52 -0700, you wrote: > > > >Has that actually been explored? How does Canonical get around the legal > >issues with OpenZFS' licensing? > > > For a start they aren't a US company, and unlike Red Hat they aren't > the same tempting target for a lawsuit. I fail to see how being a US company or not would have much bearing on this. As for being a "tempting target", they're both big tech companies providing a Linux distro as their primary product, working on a support model. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: > On 6/28/20 11:35 PM, John M. Harris Jr wrote: > > > For the best filesystem ever created, ZFS, I can't say that I agree with > > your assessment of that value. Having ZFS in Fedora would throw Fedora > > over the top as being the best Linux distro, hands down. I can count the > > number of times that having root on ZFS has led to me waiting on kernel > > updates over the past three years on one hand, and could still do so if I > > had half as many fingers! > > How many times are you going to keep mentioning ZFS? It's completely > off the table, not allowed, never happening. (I consider the chance of > Oracle doing something reasonable to be immeasurably small.) See the relevant section of Mark's email. I also don't see how it'd require Oracle to change anything in order to get OpenZFS into Fedora. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote: > On 6/29/20 12:27 AM, John M. Harris Jr wrote: > > > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: > > > >> On 6/28/20 11:35 PM, John M. Harris Jr wrote: > >> > >> > >> > >>> For the best filesystem ever created, ZFS, I can't say that I agree > >>> with > >>> your assessment of that value. Having ZFS in Fedora would throw Fedora > >>> over the top as being the best Linux distro, hands down. I can count > >>> the > >>> number of times that having root on ZFS has led to me waiting on kernel > >>> updates over the past three years on one hand, and could still do so if > >>> I > >>> had half as many fingers! > >> > >> > >> > >> How many times are you going to keep mentioning ZFS? It's completely > >> off the table, not allowed, never happening. (I consider the chance of > >> Oracle doing something reasonable to be immeasurably small.) > > > > > > See the relevant section of Mark's email. I also don't see how it'd > > require Oracle to change anything in order to get OpenZFS into Fedora. > > > You were mentioning ZFS, not OpenZFS. However, it's still the same > problem. OpenZFS is CDDL which won't be accepted. The only way that > can be changed is if Oracle does something. And as long as OpenZFS is > an out-of-tree module, it won't be in Fedora. ZFS, in terms of Linux support, is generally OpenZFS. You will note that Mark also simply said "ZFS". Yes, OpenZFS is under CDDL. That's not really a problem. See https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html. Ubuntu's solution is wouldn't work for us, and it is a GPL violation (https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/), but it's also not necessary. The package for OpenZFS could be provided as a kmod package instead, which would *not* be a GPL violation. I don't understand the attitude against this particular out-of-tree module, as it's readily available for every kernel within days of release. The longest lulls have been around holidays, where it took up to 5 days to get support for the latest stable kernel. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Monday, June 29, 2020 12:54:02 AM MST Igor Raits wrote: > On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote: > > > On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote: > > > > > On 6/29/20 12:27 AM, John M. Harris Jr wrote: > > > > > > > > > > > > > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: > > > > > > > > > > > > > > > > > On 6/28/20 11:35 PM, John M. Harris Jr wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For the best filesystem ever created, ZFS, I can't say that I > > > > > > agree > > > > > > with > > > > > > your assessment of that value. Having ZFS in Fedora would > > > > > > throw Fedora > > > > > > over the top as being the best Linux distro, hands down. I > > > > > > can count > > > > > > the > > > > > > number of times that having root on ZFS has led to me waiting > > > > > > on kernel > > > > > > updates over the past three years on one hand, and could > > > > > > still do so if > > > > > > I > > > > > > had half as many fingers! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How many times are you going to keep mentioning ZFS? It's > > > > > completely > > > > > off the table, not allowed, never happening. (I consider the > > > > > chance of > > > > > Oracle doing something reasonable to be immeasurably small.) > > > > > > > > > > > > > > > > > > > > See the relevant section of Mark's email. I also don't see how > > > > it'd > > > > require Oracle to change anything in order to get OpenZFS into > > > > Fedora. > > > > > > > > > > > > > > > You were mentioning ZFS, not OpenZFS. However, it's still the same > > > problem. OpenZFS is CDDL which won't be accepted. The only way > > > that > > > can be changed is if Oracle does something. And as long as OpenZFS > > > is > > > an out-of-tree module, it won't be in Fedora. > > > > > > > > ZFS, in terms of Linux support, is generally OpenZFS. You will note > > that Mark > > also simply said "ZFS". Yes, OpenZFS is under CDDL. That's not really > > a > > problem. See > > https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html > > . Ubuntu's solution is wouldn't work for us, and it is a GPL > > violation > > (https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/), but > > it's also not necessary. The package for OpenZFS could be provided as > > a kmod > > package instead, which would *not* be a GPL violation. > > > > > > > > I don't understand the attitude against this particular out-of-tree > > module, as > > it's readily available for every kernel within days of release. The > > longest > > lulls have been around holidays, where it took up to 5 days to get > > support for > > the latest stable kernel. > > > First of all, Fedora is packaging not only latest stable kernel. Fedora > is building kernel from git in rawhide almost daily. Secondly, kmods in > Fedora are not allowed. The Times They Are a-Changin'. It wouldn't be the first radical change in Fedora recently. I don't see how building the kernel daily would be an issue here. Yes, it wouldn't work against some of them once every few months, and then it'd be fixed within a week. An exception could be made for this particular kmod, and it'd be well worth it for our users. -- John M. Harris, Jr. ___ 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: User experience issue on btrfs
On Monday, June 29, 2020 1:09:16 AM MST Markus Larsson wrote: > On 29 June 2020 08:26:21 CEST, "John M. Harris Jr" > wrote: > >On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote: > > > >> Once upon a time, John M. Harris Jr said: > >> > >> > >> > XFS proved to be troublesome, and still is up to the latest of RHEL7. > >> > It's > >> > not uncommon to have to run xfs_repair on smaller XFS partitions, > >> > especially / boot. I'm not sure if btrfs has the same issue there? > >> > >> > >> > >> [citation needed] > >> > >> I haven't run xfs_repair in probably 15 years (and so never on Fedora or > >> RHEL/CentOS). > > > > > >I haven't had time to figure out why the RHEL systems I have that are > >(mistakenly I assume, though they were created before I was hired) using > >XFS run into that issue, after about a month, they report 100% disk > >space utilization on /boot, and I've gotta run xfs_repair in order to fix > >that. In the unlikely event that I have the time to figure out why, before > >I just re- install them (which is already planned), I'd be happy to follow > >up with a citation. :) > > > That is very odd. I haven't seen it once in over a decade in an environment > with thousands of machines. Very interesting though, I think I will have > to try to replicate this. Is there anything special about them like odd > partition layout etc? I can't confirm at the moment, but I'm pretty sure /boot is a 1GiB (maybe 2GiB) XFS partition. I've marked your message as "TODO" in my client, so I can get you more info tomorrow if you're interested. -- John M. Harris, Jr. Splentity ___ 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: swap on zram
On Monday, June 29, 2020 12:58:30 AM MST Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote: *snip* > > - Mask/disable systemd-homed > > > Doesn't do anything unless you create some users with homectl. There's no reason for it to be there, wasting resources. > > - Mask/disable systemd-userdb > > > That's just a proxy service to provide user records as json. On its > own it doesn't really do much. That's awful, and the above applies there as well. > > - Mask/disable systemd-sysusers > > > Well, various packages make use of systemd-sysusers so if you disable > systemd-sysusers, they won't get a user created and will likely not > work. Also doesn't do anything if there's no configuration. But knock > yourself out. I don't think that's the case, since that Change required that `useradd` (or was it `adduser`?) be used. It'd be worth a try to remove the systemd bloat. > > - Mask/disable systemd-repart > > > Doesn't do anything unless you provide a configuration file. So it has no reason to be there. > > - Mask/disable systemd-resolved > > > That's trivially disabled. The Change page lists a few mechanisms. It's one of the many things in this list. Each one may be "trivially disabled", but it all adds up. > > - Mask/disable systemd-networkd > > > Doesn't do anything unless you provide configuration files. And, so, it shouldn't be there, wasting resources. > > - Mask/disable systemd-timesyncd > > > Chrony is the default choice in Fedora, so until you uninstall chrony > and enable timesyncd, you're safe. Same as above, it's unnecessary bloat. > > - Disable systemd-xdg-autostart-generator > > > That's a mechanism for gnome and kde to spawn apps. Right now it's not > used yet, but it might in the future... I guess your best bet is not > to use gnome or kde. TWM would be a safe choice ;) systemd has no place doing the DE's job. That's why I have a DE, instead of systemdOS. :) > > - Remove the privacy anti-feature of using Google DNS when none are > > configured > > In general people seem to prefer to have a functional network without > manual configuration. So we want to pick *some* default. Google DNS > seems to be not better or worse than other major providers. But if > you'd rather prefer to have no DNS if none is configured, it's still a > one line config to "fix" the issue. Generally, if there are no configured servers, people expect that.. there are no DNS servers in use. That's how it should be. I don't expect the system to outright subvert my intentions to run off to Google, and I'm sure others don't either. See the systemd-resolved Change "proposal" thread for more information on that. > > - Disable fstrim.timer > > - Disable EarlyOOM > > - Not set a default EDITOR > > > All those are trivially done with a single command or one-line file. That'd be the purpose of the Spin, so that users don't have to keep track of all of the things that need to be fixed. > > - Have no modular repos by default > > > This one will soon be trivially done with a single command. Yes, and that'll make it all the more simple to add it as an excluded package in the Spin's kickstart! ;) > > - Not use btrfs or XFS as the default filesystem > > > Pick a different default when installing... Hey, that's my line! Seriously though, that wasn't really a fair thing for me to write. At the time, I was of the attitude of "I don't really care if it breaks users' systems", and to "let those folks make a mockery of Fedora with that default". Sure, folks who are in the know will pick their own partitioning scheme and filesystems of choice. However, that doesn't solve the UX of a new user. > > From this list, I know it might look like I'm calling out systemd. Well, > > that's just because it's become so bloated. > > > I'd say "useful", but that's just words. Anyway, each of the items on > this list can be easily disabled. I guess you could provide a simple rpm > in a copr repo somewhere that does this. I don't see why it'd need to be copr, I actually like mattdm's suggestion above. Some of these may need a bit more consideration, such as sysusers, but it'd have a lot of value to Fedora users. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Monday, June 29, 2020 9:26:09 AM MST Matthew Miller wrote: > On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote: > > > > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is > > > not really intended for the laptop use case. > > > > Has that actually been explored? How does Canonical get around the legal > > issues with OpenZFS' licensing? > > > I can't really speculate on Canonical's legal stance and I encourage > everyone else to also not. > > I can point to Red Hat's, though: the knowledge base article here > https://access.redhat.com/solutions/79633 says: > > * ZFS is not included in the upstream Linux kernel due to licensing > reasons. > * Red Hat applies the upstream first policy for kernel modules (including > filesystems). Without upstream presence, kernel modules like ZFS cannot > be supported by Red Hat. > > and "due to licensing reasons" links to > https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ which is quite > interesting and quite long. If you have just time to read one section, the > two paragraphs at the end under "Do Not Rely On This Document As Legal > Advice" seem like the _most_ interesting to me. I've both read that page, and linked to it further down in this thread. Yes, I believe that Canonical's implementation is a GPL violation, but it doesn't need to be. So long as the source is in a separate package, and it's packaged as a kmod, it wouldn't be a GPL violation. It's worth considering, in my opinion, whether or not it'd be available for RHEL. It wouldn't be the first package RHEL doesn't have, but Fedora does. :) -- John M. Harris, Jr. ___ 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: NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
gt; NetworkManager.conf configuration. The biggest effect of this change > is that new profiles will now preferably be persisted in keyfile > format. This changes behavior for users who expect NetworkManager to > write ifcfg-rh files, or who have scripts or tools that expect that. > What will still work is that existing ifcfg files are loaded after > upgrade. Users who only use the D-Bus API (via one of the client > applications like nmcli or the GUI), shouldn't notice the difference. > > As before, users still can explicitly configure the settings plugins > in NetworkManager.conf. This only affects the default, but it affects > existing installations if the user didn't explicitly configure > NetworkManager's `"main.plugins"` option. > > The Change will be implemented by changing the compile time default, > instead of dropping a configuration snippet. The reason is that it is > preferably that the installation of NetworkManager avoids extra > configuration. The default behavior should be achived without any > configuration. During package update there would be the possibility to > drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that > preserves the previous behavior. However, I don't think that is > necessary. After upgrading NetworkManager, it will still read ifcfg-rh > file so for the user it is less necessary to preserve the previous > behavior. Also, dropping configuration snippets during package upgrade > has its own downsides because new installations behave different than > upgraded systems. > > > == How To Test == > You can already test the effect by explicitly configuring the setting > which will become the default. For example, add a file > `/etc/NetworkManager/conf.d/99-main-plugins.conf` with content > > [main] > plugins=keyfile,ifcfg-rh > > == User Experience == > NetworkManager now preferably uses the keyfile format (INI files). > This format is probably easier to understand to users and also has a > closer resemblance to how the profile is presented in nmcli. > > If the user is using NetworkManager tools that use the D-Bus API (like > nmcli or the GUI), then the used storage plugin and format is usually > of no concern for the user. > > == Dependencies == > None > > > == Contingency Plan == > The `"main.plugins"` option exists for a long time in NetworkManager. > All that changes here is the default of this option. > > * Contingency mechanism: revert the change > * Contingency deadline: beta freeze > * Blocks release? No > > == Documentation == > I am not aware of documentation that gets affected by this. > > > == Release Notes == > NetworkManager now prefers the keyfile settings plugin over ifcfg-rh > plugin when writing new connection profiles to disk. Existing ifcfg-rh > files are still handled as before. If there's a benefit to this, beyond being more in line with Fedora experiments such as CoreOS, I'm all for it. As long as I users can continue to specify their network configuration in ifcfg-rh format files, I can't imagine anyone will have issues with this Change. :) -- John M. Harris, Jr. ___ 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: NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 11:35:55 AM MST Samuel Sieb wrote: > On 6/29/20 9:40 AM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_i > > fcfg_rh > > == Summary == > > Change the default settings plugin of NetworkManager so that new > > profiles will be created in keyfile format instead of ifcfg-rh format. > > > Is there any easy way to convert profiles from ifcfg-rh to keyfile? I don't think that'd be a good idea. The Change shows that ifcfg-rh formatted files will continue to be supported, so it's not required, and there are many people that only know the ifcfg-rh formatted configuration, such as myself. Additionally, there's a lot that could go wrong in yanking config files from one format to the other. Maybe an alternative option would be to store as a keyfile instead of ifcfg-rh if modified by one of the NetworkManager dbus clients, but otherwise leave ifcfg-rh? -- John M. Harris, Jr. ___ 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: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 1:04:48 PM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst > ationLiveCD > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will be done from the livecd. This > means that any package which is part of the livecd will be part of the > default install for most users. > > device-mapper-multipath is 1 of only 2 packages in the default install > which still Requires the long obsoleted systemd-udev-settle.service, which > waits for all device-detection to be done + some extra waiting just to be > sure. This significantly slows down booting on various systems. > > Multipath support is only necessary for installations in data-centers or > other enterprise setups, as such having device-mapper-multipath on the > livecd is not really necessary. For installations which do actually need > this device-mapper-multipath the server installation iso can be used and > this is a better fit for such installations. > > == Owner == > * Name: [[User:jwrdegoede| Hans de Goede]] > * Email: hdego...@redhat.com > > == Detailed Description == > > device-mapper-multipath is 1 of only 2 packages in the default install > which still Requires the long obsoleted systemd-udev-settle.service. The > other package is dmraid see [[Changes/DisableDmraidOnFirstRun|Disable > dmraid.service on first run]]. > > Multipath support is only necessary for installations in data-centers or > other enterprise setups, as such having device-mapper-multipath on the > livecd is not really necessary. For installations which do actually need > this device-mapper-multipath the server installation iso can be used and > this is a better fit for such installations. Actually, multipath is used outside of datacenters and enterprise setups. A better solution would be to use Anaconda to include it when configured, and leave it out otherwise.. -- John M. Harris, Jr. ___ 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: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 1:57:55 PM MST Michael Catanzaro wrote: > On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro > wrote: > > > We might need to explicitly disable systemd-udev-settle.service > > during the system upgrade to turn it off? > > > Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' > and rebooted again, and it's still running. I tried 'systemd-analyze > plot' and I see it takes 11 seconds during boot! I think the culprit is > dmraid-activation.service (not dmraid.service). Did you get the name of > the service wrong in the change proposal, or have I misunderstood? > > Unrelated: looking at my systemd-analyze plot, other startup time > offenders are NetworkManager-wait-online.service (9.5 seconds, seems > egregious, I wonder why this is necessary?) and grand prize winner > abrtd.service (requiring an amazing 30 seconds!) Well, disabling it on upgrade might be fine, so long as you check that it's not actually in use. Please keep in mind that dmraid is required for, for example, Intel firmware RAID, and so simply disabling this would mean that users' workstations or servers using firmware RAID wouldn't be able to boot.. -- John M. Harris, Jr. ___ 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: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 4:03:06 PM MST Neal Gompa wrote: > > Actually, multipath is used outside of datacenters and enterprise setups. > > A better solution would be to use Anaconda to include it when > > configured, and leave it out otherwise.. > > > Anaconda live install architecture does not support post-installation > package installs based on user requests or configuration selected at > install time. So this would not be possible. Would it be possible to write a plugin to support that, or does Anaconda live install just install every package the live image has? If that wouldn't be trivial, it may be best to just disable it if it's unused, which would leave the functionality for those who use it, without affecting the boot times of those who don't use it. -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Monday, June 29, 2020 3:40:57 PM MST Markus S. wrote: > It's not a GPL violation. OpenZFS works under Linux through a compatibility > layer called SPL, the Solaris Porting Layer. SPL is licensed under GPL. > Torvalds himself said that a non-GPL file system that was written for > another OS cannot be considered a derivative of the Linux kernel: > https://yarchive.net/comp/linux/gpl_modules.html > SPL is a derived work from the Linux kernel because it's designed for the > Linux kernel. SPL is therefore under GPL. ZFS is designed for Solaris and > therefore a different license is fine. > Dell, a friggin huge US company, wouldn't distribute Ubuntu with their > laptops if they as the distributor did something illegal. That's a good point, I didn't think about that. Additionally, having the context from Linus is very useful, thank you for that! -- John M. Harris, Jr. ___ 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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote: > Hi > > On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > > Thanks, I am well aware. That wasn't really the topic here. > > If there is a repeated feeling that anyone has that a particular edition > isn't what they are looking for, figuring out how to make a different set > of choices is and perhaps forming a community around their preferences is > pertinent. This isn't addressed just to you. Having said that, what do > you consider is the topic? > > Rahul The possibility of the start of the Grumpy Old Neckbeard Spin (actual name TBD). -- John M. Harris, Jr. ___ 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.
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? > 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. Good for them. That just means that, on those next-generation systems, once they're out, people will be using UEFI boot. > 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. What does BIOS boot have to do with 32 bit operating systems? RAID HBAs will also continue to work, though you may not be able to boot from them. Network cards will *also* continue to work, you just might not be able to PXE. > 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. So that people can continue to boot their systems, and so that users and cloud providers can still boot Fedora VMs. Why in the world would GRUB2 be dropped? > 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. This would mean that every single one of the systems that I own, every system on Linode, DigitalOcean, and most other cloud providers would cease to be able to boot Fedora. I'm very much against this proposal. -- John M. Harris, Jr. ___ 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.
On Tuesday, June 30, 2020 7:00:00 AM MST 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. It's possible, and actually surprisingly simple, but not in virtualization hosts based on RHEL7. I'm not sure about RHEL8, but in Fedora, you can install edk2-ovmf, if it's not already installed, to get UEFI support. -- John M. Harris, Jr. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
cy Plan ==
>
> * Contingency mechanism: (What to do? Who will do it?) Owner reverts
> changes
> * Contingency deadline: Final freeze
> * Blocks release? No
>
> == Documentation ==
> * {{code|man earlyoom}}
> * https://github.com/rfjakob/earlyoom
> * https://www.kernel.org/doc/gorman/html/understand/understand016.html
>
> == Release Notes ==
> The earlyoom service is now enabled by default in Fedora KDE.
>
> The earlyoom service monitors system memory usage. If free memory falls
> below a set limit, earlyoom terminates an appropriate process to free up
> memory. As a result, the system does not become unresponsive for long
> periods of time in low-memory situations.
>
> The following is the default earlyoom configuration:
>
> * If both RAM and swap go below 10% free, earlyoom sends the SIGTERM signal
> to the process with the largest oom_score.
> * If both RAM and swap go below 5% free, earlyoom sends the SIGKILL signal
> to the process with the largest oom_score.
>
> For more information, see the earlyoom man page.
Please do not make this Change, or change the values from 10% and 5% to 1% and
0%, so that it won't kill our software at times of high memory usage.
--
John M. Harris, Jr.
___
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.
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? -- John M. Harris, Jr. ___ 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: Make btrfs the default file system for desktop variants
On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote: > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro > wrote: > > > > > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher > > wrote: > > > > > For the record, as this directly affects the Workstation deliverable, > > > I will be voting -1 until and unless the Workstation WG votes in > > > favor. > > > > > > > > > > > > Yes, it's a large set of Change owners, but since only two of them are > > > Workstation WG members, they are not representative of that group. > > > > > > > > Workstation WG hat on: > > > > > > > > I don't think there's any need to vote -1 for that reason alone. The > > Workstation WG has discussed the change proposal at several meetings > > recently (really, we've spent a long time on this), and frankly we were > > not making a ton of progress towards reaching a decision either way, so > > going forward with the change proposal and moving the discussion to > > devel@ to get feedback from a wider audience and from FESCo seemed like > > a good idea. Most likely, we'll wind up doing whatever FESCo chooses > > here, but unless FESCo were to explicitly indicate intent to override > > the Workstation WG, we would not consider a FESCo decision to limit > > what the Workstation WG can do with the Workstation product. At least, > > my understanding of the power structure FESCo has established is that > > the WG can make product-specific decisions that differ from FESCo's > > decisions whenever we want, unless FESCo says otherwise (because FESCo > > always has final say). That is, if FESCo were to approve btrfs by > > default, but Workstation WG were to vote to stick with ext4, then we > > would stick with ext4 unless FESCo were to say "no really, you need to > > switch to btfs" (which I highly doubt would happen). So I don't see any > > reason to vote -1 here out of concern for overriding the WG. > > > > > > > The problem is that the request as discussed reads as "FESCo says use > it for workstation" vs "FESCo has no problem with Workstation saying > they want btrfs" or "FESCo says use btrfs as default". Yes it says > "desktop variants" but only 1 variant really counts and that is > Workstation. So yes, either Workstation agrees to it or it isn't > getting voted on. If Workstation can't come to an agreement on it, > then the proposal is dead. Anything else is an end-run and a useless > trolling of people to see how many rants LWN counts in its weekly > messages. Well, it's not only Workstation that this proposal is trying to throw btrfs on, but the other desktops as well, such as KDE Spin. -- John M. Harris, Jr. ___ 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.
On Tuesday, June 30, 2020 1:20:18 PM MST 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 ). Sure, gummiboot is more lightweight than GRUB. It also doesn't support a lot of the features that GRUB does, such as full disk encryption (with stub in MBR). > It already integrates with the service management framework (systemd). That's one of the problems with it. What does an init system have to do with the bootloader? > More user friendly than Grub ( has lilo like interface easier to change > kernel entry, which goes nicely with the default editor change ) I'm pretty sure GRUB has a much more user friendly interface than systemd- boot.. Additionally, you can even drop to a cmdline if needed, in GRUB. > 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). GNOME related changes.. to a bootloader? Sorry, I haven't heard of any of those. Can you point me to a thread or page describing that kind of thing? That sounds a bit.. odd, to say the least. Regardless, if that's going to be a thing, it'd be perfectly fine, in my opinion, for Workstation to use systemd-boot on UEFI by default, and GRUB only on BIOS boot systems, while the rest of Fedora continues to use the more powerful bootloader. > Could help further adapt UEFI and secure boot which the industry is > moving towards which helps keep Fedora moving along with it. GRUB2 supports UEFI, quite well in fact. > Grub discourages users who have tried sd-boot from coming/returning to > Fedora [1]. How's that? If you mean that users that have used GRUB prefer it over systemd- boot, I'd be inclined to agree, but I don't see how it'd prevent people from returning to Fedora. > 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. I have to disagree. The more systemd bloat that gets thrown into the mix, the more concerned I become with this path. We already have a powerful and mature project in GRUB2, which supports UEFI well, and is known to be stable. -- John M. Harris, Jr. ___ 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.
On Tuesday, June 30, 2020 2:55:42 PM MST 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. It's really simple with GRUB. You just alter /etc/default/grub, and then rebuild your config. With systemd-bloat, you do.. what? -- John M. Harris, Jr. ___ 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.
On Wednesday, July 1, 2020 11:26:48 AM MST Jóhann B. Guðmundsson wrote: > 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. GRUB2 is not a "boot manager OS", it's a fairly simple, but modular, single threaded boot management application. GRUB2 supports UEFI well, probably better than systemd-bloat. At the same time, it's much more flexible in other aspects, providing users with the ability to boot their system in a number of situations that systemd-bloat doesn't support, as well as providing a recovery console in the event that there are issues loading the kernel and initramfs. GRUB2 also supports Secure Boot. Does systemd-bloat? -- John M. Harris, Jr. ___ 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.
On Wednesday, July 1, 2020 6:32:15 AM MST Marcin Juszkiewicz wrote: > W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze: > > > > If you mean migration of existing guests, then you need to repartition > > them and reinstall the bootloader. I doubt anyone has a practical > > idea of how to do that either manually or automatically. > > > Add second drive with 32-64MB size. Create ESP partition there. Install > grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi. > > Much easier than with real hardware machines where you indeed need to > play with partitions. On my laptop I have space available in /boot/ > partition so could shrink it and create ESP from there. But already have > ESP so no need. It's not that simple, in many cases. For example, both the virtualization setup I use at work, and my home virtualization setup, employs iSCSI so that I can migrate VMs between my various virtualization hosts. In order to create a new drive, I'd have to create a new LUN just for a 32-64MiB block device.. Not impossible by any means, but not as simple as the above. This would be similarly "more complex" in OpenStack environments. -- John M. Harris, Jr. ___ 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.
On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote: > On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote: > > > > I'm not in the bootloader-team, but I do work very closely with them, > > so I have only one question: who is going to pick up the extra > > maintenance load this is going to cause ? > > > There are distros already using it. And so far we have been pretty OK > with supporting it upstream and downstream. At least upstream I am not > aware of any big issues left open. > > Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain > Turing complete programming languages, module loaders, file system > drivers, storage stacks and such. There's simply not that much to > maintain! > > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > anaconda will need to be adjusted, kernel-install scripts will need to > > be adjusted, etc. > > > kernel-install itself is actually maintained in the same repo as > sd-boot: systemd upstream. They are developed along the same lines > already. > > > > Also I wonder, if you are not proposing to completely drop grub2 on > > x86_64 what does offering sd-boot in addition to grub2 actually > > offer as advantages? > > > Primarily simplicity, and that it implements the boot loader spec > correctly. > > it automatically discovers windows and Macos installations at each > boot, without any userspace involvement. You can talk to it very > nicely, i.e. implement trivially "boot-into-windows" buttons and such > in GNOME and so on. It makes things very robust, since you don't need > a script that generates a script that generates a script (yeah, that's > how grub is hooked up). it just works on its own. You drop in boot > menu items, and that's it. You don't need to regenerate stuff, and you > never have to run an interpretor for a turing complete language. > > By using sd-boot, you can do stuff like "systemctl reboot > --boot-loader-entry=windows", you can do "systemctl reboot > --boot-loader-menu=0", you can do "systemctl kexec" and it boots the > right thing, and so on. > > It also implements boot time assessement that is simple and just works > (i.e. automatic revert to previous boot menu choice when the one > selected doesn't work). > > Oh, and it as support for seeding the Linux random seed pre-boot > already, in a safe and simple fashion. > > Moreover, it communicates which ESP is used to the host OS, so that > the host can automatically discover what other partitions to mount. > > And the list goes on and on and on. > > All these features are very simple individually, but put together they > are just a much nicer and expose a much more integrated behaviour > than Grub ever did. > > > > sd-boot is simpler and a bit tighter integrated with systemd, which would > > mean it is less work to maintain if we use it instead of grub, but if we > > use it next to grub then all those advantages fall away. IOW if we use > > it next to grub then all I see is a whole lot of extra work, with very > > little gain. > > > Well, you appear to believe in the race to the bottom, i.e. that the > lowest common denominator should be where the future is. I am pretty > sure it's the wrong approach: pick the simple contender that can do > all the nice things, and has the nice integration, and use it as a > blueprint for the other archs where Grub is still needed, and make > them catch up. > > I mean, I understand you are interested in exotic platforms that lack > modern things like UEFI, but it kinda sucks to hold the boot loader > hostage due to that, and just stick to the terrible ways of yesteryear > because of it. > > > > AFAIK this (lot of extra work, very little gain) is exactly why we have > > been sticking with grub2 so far. We need to maintain it anyway, at which > > point we want to use it in as much cases as possible so that we can have > > unified code and documentation for dealing with the bootloader. > > > I don't see "very little gain". I see a lot of gain, and all while > things become simpler. Much simpler. > > Lennart > > -- > Lennart Poettering, Berlin Lennart, We don't need more systemd-bloat just to boot our systems. However your bootloader works, it doesn't really matter if it's not up to snuff with GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and several filesystems, then it'll be more of a viable option, and I still wouldn't recommend having yet another systemd compo
Re: The future of legacy BIOS support in Fedora.
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote: > On 7/2/20 12:55 AM, John M. Harris Jr wrote: > > > > > > > > Lennart, > > > > We don't need more systemd-bloat just to boot our systems. However your > > bootloader works, it doesn't really matter if it's not up to snuff with > > GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and > > several filesystems, then it'll be more of a viable option, and I still > > wouldn't recommend having yet another systemd component as a core part of > > our systems. At what point is systemd large enough that you'll stop > > adding more cruft? > > > Can you please stop calling features of systemd you don't like > "systemd-bloat" at every given opportunity? It is not being respectful > to those who work on the project and doesn't help your argument. It works well with this one. It's part of systemd, for some reason. It's bloat. It's one letter off from the actual name of the software. It doesn't need to be part of systemd to integrate with it. We don't need to make our system more exclusive to make use of some systemd features, we can just use the more powerful bootloader, GRUB2, and implement what it needs to make use of these systemd "features". -- John M. Harris, Jr. ___ 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.
On Thursday, July 2, 2020 5:08:31 AM MST Peter Robinson wrote: > On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov wrote: > > > > > > > On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote: > > > > > 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. > > > > > > > > > > > > > > Just in case if someone is not aware: syslinux (pxe, ext) shipped with > > Fedora is in very good state - form about 2016 I am using the package > > > I suppose "very good state" is a relative term, upstream hasn't seen a > release since 2016 so is essentially "unmaintained", not sure it > supports secure boot, probably has a bunch of CVEs (see point about > maintenance). I think it only lives on in Fedora is because I think > it's used for some (.iso?) install method, AFIACT it's eventually > glued back together when it fails to build and is generally ignored. It's used for ISO boot by Fedora itself, and is the preferred PXE method, the alternative being GRUB. It's a powerful bootloader, I don't see anything that needs changing in it. -- John M. Harris, Jr. ___ 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.
On Wednesday, July 1, 2020 2:28:39 PM MST 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.
5-10 years? A better estimate would be 15-20 years. People aren't going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to something that is still supporting BIOS, if they
don't write their own installer and just continue using Fedora, given that
this is an entirely artificial limitation.
--
John M. Harris, Jr.
___
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
