Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Your calculations have to be off; I’m pretty sure there are way more than 100 Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard minimum: https://linux-hardware.org/?view=gpu_vendor=Fedora. I think there are at least tens of thousands of Fedora users with a Nvidia GPU. It’s not a majority, is all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> However, the majority of Linux PC users *must* step out of the happy path > to get their hardware working for two cases: > > * NVIDIA graphics > * Broadcom wireless In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13% AMD, 5% other. I don’t think Broadcom wireless is that common either. So it’s a lot of people, but not a majority of Linux PC users, probably less than 25%. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)
I don’t agree with this change, as it seems obvious that many users who do not want proprietary software installed do not want repositories with proprietary software in them installed either (whether or not these repositories are enabled) and would want to have to opt-in to that too. Additionally, disabled repositories show up from time to time, bugs allowing, so they are not as inactive as the name implies. Not having them installed serves as a safeguard. Also, users who use some software from the third-party repositories likely *do not* want all of them enabled. The stated benefit of the proposed change (“the removal of the state where the user has opted in to third party repositories but they are not actually enabled”) is not the benefit; the actual benefit that is wanted is an improvement to the user experience that is made easier to provide by installing the repos by default. That said, the problems here are more on Council than FESCo, and Council already approved this, and people don’t agree with me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: x86_64-v2 in Fedora
For Fedora, linux-hardware.org says 78% use EFI and 16% have Secure Boot enabled. Not a very good data set, though Fedora telemetry wouldn’t be either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Btrfs by default, the compression option
Maybe Workstation could provide Déjà Dup in the default system to make it discoverable and encourage users to create backups. It has to be an installed application (can’t be a website), and most users would benefit from having backups. ___ 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
That’s one fewer reason not to use XFS then. It seems Documentation/admin-guide/cgroup-v2.rst was not updated and still says only ext2, ext4, and btrfs have writeback implemented. ___ 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
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=25725f9d41735d176d73a757430739fb71c7d043. 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/c2faaae697f11ee600989b67b4406981838ae628. 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=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. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
I intended to demonstrate that cgroups can be used to cause the kernel OOM killer to react appropriately and fast enough, implying that replacing the OOM killer is not necessary and that replacing it by a userspace OOM killer that does not account for cgroups can be undesirable. The exact same controls set with my example commands, and others, can be set with scopes as well, so this should be applicable. > https://lore.kernel.org/linux-fsdevel/20200104090955.gf23...@dread.disaster.area/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f Okay, interesting. But that’s a statement from just one person, and it has to be interpreted in the context of what it is confirming; that is, that the OOM killer is “mainly concerned about kernel survival in low memory situations”, which is weaker than your claim that “their concern with kernel oom-killer is strictly with keeping the kernel functioning”. I don’t know if the OOM killer’s main purpose is to keep the kernel alive (Michal Hocko appears to think so, maybe others disagree), but it is in any case not an abuse of the OOM killer to also use it to keep userspace responsive, and there is no reason to think that kernel folks are not interested in helping achieve this goal. The only advantage I see to earlyoom so far is that it sends SIGTERM before taking further steps that will kill processes. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
> For now, kernel developers have made it clear they do not care about > user space responsiveness. At all. Their concern with kernel > oom-killer is strictly with keeping the kernel functioning. This is false. The stated purpose of the OOM killer is not only to keep the kernel alive. Nor does the fact the kernel has not solved userspace responsiveness yet imply that kernel folks do not care. Rather, it means that they will not solve it on their own because the kernel does not have all the information it needs. Kernel folks do care, or we wouldn’t have PSI or cgroups. A userspace solution is needed, but does not need to replace the OOM killer; cgroups are also a userspace solution. If earlyoom breaks them, it can make things worse than the status quo. > Can it be done with cgroupv2 and PSI alone? Unclear. Of course it can. Just run 100 instances of every stress-ng memory worker in a podman container with a cgroup memory limit. The system will not hang. Do the same without the memory limit. The system will hang within seconds and never recover. Thus demonstrating that cgroups work and do the things they were intended to do. Try it. With a memory limit, podman run --rm -it --memory=1G fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' will use CPU but keep your system responsive. Without the memory limit (this will hang your system), podman run --rm -it fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' the system hangs and doesn’t recover after 15 minutes. Same thing with `tail /dev/zero`: podman run --rm -it --memory=1G fedora tail /dev/zero activates the OOM killer after three seconds, with kernel: Memory cgroup out of memory: Killed process 8814 (tail) total-vm:3141408kB, anon-rss:1042028kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:6336512kB oom_score_adj:0 systemd[943]: libpod-e061e1cb57dde204632531a556d37efbd51c9ab67346a8bc4d5e26c7301c165b.scope: A process of this unit has been killed by the OOM killer.kernel: oom_reaper: reaped process 8814 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB logged in the system journal. You were saying the OOM killer activates too late and rarely kills the right process? Well, here it activates early enough and knows exactly what to stop. It is worth trying with ninja and WebKit too. ___ 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: F30: System-Wide Change proposal: DNF UUID
This change would appear more acceptable if it was combined with removing the Fedora user agent patch for Firefox (https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-fedora-ua.patch), which is simultaneously a worse privacy risk and a worse way to count users than randomized UUIDs. Also, since there is no need for a highly precise count, the UIDs do not need to be so unique. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Better fonts by default?
That would be untrue. https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftsmooth.c?h=VER-2-8-1#n357 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
