Hi,
Workstation working group was tracking this: #241 Re-revisit Fedora Workstation minimums https://pagure.io/fedora-workstation/issue/241
But to answer the questions, I think we need to broaden the conversation, hence this email.
Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/
Minimum hardware requirements is intended to setup some kind of expectation of performance. The goal isn't the hardware requirement, that's just the means of getting to the goal. So what's the goal? For sure folks need to be able to install it plus some breathing room to install additional software and user data. That gets to the minimum storage space angle.
But the CPU, memory, and IO angle are more complex. A completely objective metric would account for the local workload, which we don't know. So we're going to have to come up with a subjective recommendation, i.e. take an educated guess. (I enjoy underscoring that subjective != arbitrary.)
How does the minimum hardware requirement achieve the intended goal? And is it testable? We could ask folks to run some workloads on low-CPU, low-memory hardware, and report 'grep -r . /proc/pressure' whenever they think the system is performing worse than expected? Or what?
Anyway, this is just to kick off a conversation. Let's see where it goes.
Sigh, it is useless to search for Fedora documentation on google ... anything but _current_ Docs will be found.
Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/
And this doubling is not to be found in the Docs [1] in any other aspect than RAM size. The recommended HDD size value is 1/3 bigger than the minimal one.
Also, the minimal CPU speed requirement apparently doubled between F32 and F33, but I don't see any Fedora Change for F33 listing that. [2]
Both of that goes to a question - how are those values decided in the first place ?
To target the Workstation edition regarding those values seems OK. However it seems to be far from the minimal requirements for a headless server, which is surely fine with less than 5GB of disk space.
I believe that there are some technical limitations that we should list. E.g. having a 64-bit CPU with certain instructions / capabilities (at least for the X86_64 architecture family) Everything other than the hard technical limits is just an educated guess or assumption ...
[1] https://docs.fedoraproject.org/en-US/fedora/f34/release-notes/welcome/Hardwa... [2] https://fedoraproject.org/wiki/Releases/33/ChangeSet
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Wed, Oct 13, 2021 at 6:41 PM Chris Murphy lists@colorremedies.com wrote:
Hi,
Workstation working group was tracking this: #241 Re-revisit Fedora Workstation minimums https://pagure.io/fedora-workstation/issue/241
But to answer the questions, I think we need to broaden the conversation, hence this email.
Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/
Minimum hardware requirements is intended to setup some kind of expectation of performance. The goal isn't the hardware requirement, that's just the means of getting to the goal. So what's the goal? For sure folks need to be able to install it plus some breathing room to install additional software and user data. That gets to the minimum storage space angle.
But the CPU, memory, and IO angle are more complex. A completely objective metric would account for the local workload, which we don't know. So we're going to have to come up with a subjective recommendation, i.e. take an educated guess. (I enjoy underscoring that subjective != arbitrary.)
How does the minimum hardware requirement achieve the intended goal? And is it testable? We could ask folks to run some workloads on low-CPU, low-memory hardware, and report 'grep -r . /proc/pressure' whenever they think the system is performing worse than expected? Or what?
Anyway, this is just to kick off a conversation. Let's see where it goes.
-- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, Oct 14, 2021 at 11:25 AM Michal Schorm mschorm@redhat.com wrote:
Sigh, it is useless to search for Fedora documentation on google ... anything but _current_ Docs will be found.
Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/
And this doubling is not to be found in the Docs [1] in any other aspect than RAM size. The recommended HDD size value is 1/3 bigger than the minimal one.
Also, the minimal CPU speed requirement apparently doubled between F32 and F33, but I don't see any Fedora Change for F33 listing that. [2]
Both of that goes to a question - how are those values decided in the first place ?
To target the Workstation edition regarding those values seems OK. However it seems to be far from the minimal requirements for a headless server, which is surely fine with less than 5GB of disk space.
I believe that there are some technical limitations that we should list. E.g. having a 64-bit CPU with certain instructions / capabilities (at least for the X86_64 architecture family) Everything other than the hard technical limits is just an educated guess or assumption ...
We'd have to go with saying what brand processor families are acceptable minimums, because checking for instructions/capabilities is not something I expect people to reasonably do. An example of what I'm talking about is the Windows XP minimum system requirements[1], which listed the Pentium as the minimum because of the ISA requirements.
[1]: https://en.wikipedia.org/wiki/Windows_XP#System_requirements
-- 真実はいつも一つ!/ Always, there's only one truth!
Am 14.10.2021 um 17:24 schrieb Michal Schorm mschorm@redhat.com:
Sigh, it is useless to search for Fedora documentation on google ... anything but _current_ Docs will be found.
Welcome to the club. This has been a nuisance for a long time. I have made several attempts, but so far without response.
Both of that goes to a question - how are those values decided in the first place ?
To target the Workstation edition regarding those values seems OK. However it seems to be far from the minimal requirements for a headless server, which is surely fine with less than 5GB of disk space.
A default installation of Fedora Server Edition occupies about 2.2 GiB of storage and consumes 505 MiB of Ram. An absolute minimum might be 2 G RAM and 5 G storage and additional RAM and storage depending on usage. To make some realistic recommendations you need "rules of thumb“ on specific use cases. What storage and RAM do you need for PostgreSQL managing x.y GiB data? And what processor power do you need to achieve a „reasonable“ performance? Off the top of my head, I don't know any justifiable values.
I can't imagine that justifiable statements about hardware requirements are possible (beyond absolute minimums purely for the system).
Thinking about this more, I always get to a question: "Who are the consumers of that information and what do they actually use it for?"
My personal idea is that the _ recommended _ requirements (of any OS) are seeked by people that 1/ are going to install the system on some hardware on which that OS wasn't previously present 2/ are looking up values with which they expect fluent, smooth, experience both today and few year into the future 3/ _ want _ to install that OS, but have to purchase the HW yet, so they are looking at recommendations on what HW to buy
The _ recommended _ HW requirements could be reviewed periodically also based on the current market offering. The market surely can differ through the world, as well as the average purchase power. However I wouldn't recommend anyone to e.g. go with less than 8GB of RAM today, when considering what new HW to buy or what HW to use for a setup intended to be used for years. Perhaps, we - as a community - might be able to gather our expectations and make some average for those values?
The _ minimal _ requirements on the other hand are IMO seeked by an entirely different group of people that 1/ are looking up the minimal requirements on recent HW for e.g. IOT edition, or other use-cases in which you need to get the most of a not really powerful but recent HW 2/ are looking up whether some HW from a XYZ years or decades ago could run the Fedora Linux
I understand it may be hard to check whether the HW meets the pure technical limitations. Though if we know how to do that, we may automate that and prepare some package, some script purely for the purpose of this check. We would also need to think about where to put it - the server edition maybe, or the net installer, or could we patch the GRUB2 itself with it, providing a custom call which could be selected as a separate boot entry in all the bootable media we provide ?
What do you folks think - does the idea of defining the values based on the use cases of people that are _ actually likely to seek those values _ make sense as I tried to explain it?
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On 10/15/21 5:13 AM, Michal Schorm wrote:
Thinking about this more, I always get to a question: "Who are the consumers of that information and what do they actually use it for?"
My personal idea is that the _ recommended _ requirements (of any OS) are seeked by people that 1/ are going to install the system on some hardware on which that OS wasn't previously present 2/ are looking up values with which they expect fluent, smooth, experience both today and few year into the future 3/ _ want _ to install that OS, but have to purchase the HW yet, so they are looking at recommendations on what HW to buy
The _ recommended _ HW requirements could be reviewed periodically also based on the current market offering. The market surely can differ through the world, as well as the average purchase power. However I wouldn't recommend anyone to e.g. go with less than 8GB of RAM today, when considering what new HW to buy or what HW to use for a setup intended to be used for years.
This is useful for development, however much RAM intensive work can be done on the cloud or in some institutional settings a shared high capacity local server. For most people, largest daily use would come from spreadsheets and internet browsing. Many programs are sufficient on 4Gb of RAM, though many lightweight electron Javascript applications can slow performance compared to similar C/C++/GO alternative applications.
Perhaps, we - as a community - might be able to gather our expectations and make some average for those values?
The _ minimal _ requirements on the other hand are IMO seeked by an entirely different group of people that 1/ are looking up the minimal requirements on recent HW for e.g. IOT edition, or other use-cases in which you need to get the most of a not really powerful but recent HW 2/ are looking up whether some HW from a XYZ years or decades ago could run the Fedora Linux
Main issue is hardware security.
I understand it may be hard to check whether the HW meets the pure technical limitations. Though if we know how to do that, we may automate that and prepare some package, some script purely for the purpose of this check. We would also need to think about where to put it - the server edition maybe, or the net installer, or could we patch the GRUB2 itself with it, providing a custom call which could be selected as a separate boot entry in all the bootable media we provide ?
What do you folks think - does the idea of defining the values based on the use cases of people that are _ actually likely to seek those values _ make sense as I tried to explain it?
It may be better to ask people using/developing different spins what they find works for their spin. Bare OS is probably fine on 512MB - 1GB of RAM. Applications and data used are more important - if you are building software locally, doing image processing, video editing, doing engineering simulation and design, doing communication, browsing the web, gaming, or office applications, your needs will be quite different. Possibly one can measure RAM use during CI tests for the applications.
On Fri, Oct 15, 2021 at 04:13:34AM +0200, Michal Schorm wrote:
Thinking about this more, I always get to a question: "Who are the consumers of that information and what do they actually use it for?"
One consumer is libosinfo. Tools which use libosinfo (of which there are quite a few) will use it for ensuring there is enough space when provisioning VMs. Currently:
https://gitlab.com/libosinfo/osinfo-db/-/blob/226b19fd3e5401c0554ba3df563d49...
Rich.
On 10/14/21 18:30, Peter Boy wrote:
A default installation of Fedora Server Edition occupies about 2.2 GiB of storage and consumes 505 MiB of Ram. An absolute minimum might be 2 G RAM and 5 G storage
This pretty much would require a reinstall on upgrade, because during the regular upgrade the root filesystem needs to contain the old packages, the new RPMS and the space to install them before the old ones are deleted, i.e. the root FS needs to be at least 3x the installed size.
It's OK in many cases, but we should warn people.
On Wed, Oct 13, 2021 at 12:41:17PM -0400, Chris Murphy wrote:
Only Fedora Workstation edition explicitly states minimum hardware requirements: "Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended." https://getfedora.org/en/workstation/download/
Minimum hardware requirements is intended to setup some kind of expectation of performance. The goal isn't the hardware requirement, that's just the means of getting to the goal. So what's the goal? For sure folks need to be able to install it plus some breathing room to install additional software and user data. That gets to the minimum storage space angle.
I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people know and understand that additional resources are required for additional things, and e.g. we don't need to tell them that they need extra 40GB if they have 40GB of photos. People also understand that if they have an 8 year old laptop with 2GB of RAM, it's not going to be as much fun as a new thing. But again, they know this without us explaining it.
Anyway, this is just to kick off a conversation. Let's see where it goes.
Downthread, minimal CPU reqs were mentioned. But in fact those are fairly low — we build everything to a fairly old baseline. It hasn't come up much, and I think we don't need to worry about this too much. If people were not asking if we support 4-year-old hardware 6 years ago, they are even less likely to ask about it now when it's 10 years old. If people have some specific question like support for Intel Atom, we should direct them to ask.fp.o or one of the other venues.
Zbyszek
On Thu, Oct 14, 2021 at 08:09:45PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people know and understand that additional resources are required for additional things, and e.g. we don't need to tell them that they need extra 40GB if they have 40GB of photos. People also understand that if they have an 8 year old laptop with 2GB of RAM, it's not going to be as much fun as a new thing. But again, they know this without us explaining it.
For me, I think the baseline for what we should recommend is: feels responsive when doing everyday desktop tasks. For example, browsing the web with some medium number of tabs open on popular websites, and switching to a video call while that's still open.
I know "feels responsive" is pretty subjective, so, maybe "switching tabs should be < 0.1 second" (from https://www.nngroup.com/articles/response-times-3-important-limits/).
On Thu, Oct 14, 2021 at 06:14:44PM -0400, Matthew Miller wrote:
I know "feels responsive" is pretty subjective, so, maybe "switching tabs should be < 0.1 second" (from https://www.nngroup.com/articles/response-times-3-important-limits/).
Or, perhaps: better than some threshold for Phoronix Test Suite runs some selection of desktop apps?
I think an important question we should ask is who is the target user we're thinking about when we consider 'recommendations'. I used to have a pretty clear picture of what 'recommended/required' meant, and then I did some charity/volunteer work in Namibia back in the early 2000s and realized that what I'd consider less than useful hardware, was to some people their daily driver. I was so used to multitasking that I never even considered that to some that it was a luxury. That's quite different these days as there's been almost 20 years of development since then, but there are plenty of people out there still using hardware that we wouldnt consider using because we have options. That's one of the reasons I initially got involved in PuppyLinux back then. Having seen what people outside of the 1st world country were using and what they had available to them... was rather eye opening. Now, to be clear, I'm not suggesting we target those geographic/demographies over every other. But I dont have a really clear picture of who we're making the recommendations to. Are we primarily focusing on 1st world users? Nothing necessarily wrong if that's who we're targeting Workstation for, but I'm not actually sure. I know about a decade ago I pitched an idea to Matthew in some email, while scheduling him for an interview on LAS, about making a version of Fedora specifically focused on older hardware exactly for those users, but I didn't have the time to really commit to figuring out what would/wouldn't work for it... so it never went anywhere. One of these days I should actually commit to that. But back on point... who is our expected 'Workstation' user?
On Thu, Oct 14, 2021 at 6:15 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Oct 14, 2021 at 08:09:45PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people know and understand that additional resources are required for additional things, and e.g. we don't need to tell them that they need extra 40GB if they have 40GB of photos. People also understand that if they have an 8 year old laptop with 2GB of RAM, it's not going to be as much fun as a new thing. But again, they know this without us explaining it.
For me, I think the baseline for what we should recommend is: feels responsive when doing everyday desktop tasks. For example, browsing the web with some medium number of tabs open on popular websites, and switching to a video call while that's still open.
I know "feels responsive" is pretty subjective, so, maybe "switching tabs should be < 0.1 second" (from https://www.nngroup.com/articles/response-times-3-important-limits/).
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek:
I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people
The smallest device Fedora runs on, will propably be the Pinephone.
ATM..it has 3 GB Ram and a 32 GB storage. A 20 GB base install + taking journald logsizes into account, gives 8 GB of usable space.
I think any new reevaluation of "minimum" should really take mobil devices into account.
Best regards, Marius Schwarz
Marius Schwarz wrote:
Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek:
I think that those numbers (20GB+2GB) are quite reasonable for the stated purpose of "install and run successfully". I think that people
The smallest device Fedora runs on, will propably be the Pinephone.
ATM..it has 3 GB Ram and a 32 GB storage. A 20 GB base install + taking journald logsizes into account, gives 8 GB of usable space.
I think any new reevaluation of "minimum" should really take mobil devices into account.
I think that what really needs to happen is that we stop just accepting and shrugging off that these requirements keep growing over time, all the time.
If you compare with the requirements of Fedora Core 1: https://fedoramagazine.org/celebrate-fifteen-years-fedora/ the minimum RAM requirement has increased by a factor of more than 10 (compared to the minimum for graphical installation – there was also the Anaconda text mode that required 32 times less memory! And once installed, it was actually possible to use graphical desktop environments to some extent with even that).
Disk space requirements have also increased around tenfold (8.33 times if you compare the current "Fedora Workstation" to the old "Workstation", 10.53 times if you compare it to the old "Personal Desktop").
There are several contexts in which bloat is a problem: older hardware, mobile devices, cloud servers, etc., but also simply for the time it takes to download an ISO. Unfortunately, most of the minimization efforts we had so far were focused only on one specific use case (mostly the cloud one) and relied on hacks completely stripping out functionality that other use cases need. Even as far as deleting the RPM database, which is an option only for a throwaway cloud image that never gets updated in place (i.e., a new image gets built instead).
I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy!
Kevin Kofler
On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy!
The top two reasons for this: a significant portion of anaconda used to be downloaded, and now is included on the media; linux-firmware bloat, which is the fastest growing package for the past few years. Front this point there's a bunch of pressure points and trade-offs. This cycle we were over CD-ROM size of 700MiB, and ended up trimming out about 30M from linux-firmware.
-- Chris Murphy
On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy lists@colorremedies.com wrote:
On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy!
The top two reasons for this: a significant portion of anaconda used to be downloaded, and now is included on the media; linux-firmware bloat, which is the fastest growing package for the past few years. Front this point there's a bunch of pressure points and trade-offs. This cycle we were over CD-ROM size of 700MiB, and ended up trimming out about 30M from linux-firmware.
-- Chris Murphy
It's also X based with GUI's, rather than an ncurses based graphical interface. Reviewing a fresh install, there is little to nothing that couldn't be done in a much, much smaller text interface going through a linear checklist with ncurses, and follow Eric Raymond's old guidelines for open source interfaces titled "The Luxury of Ignorance". But some folks like pretty GUIs, even though sophisticated GUI's cost resources to run.
Nico Kadel-Garcia nkadel@gmail.com writes:
On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy lists@colorremedies.com wrote:
On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy!
The top two reasons for this: a significant portion of anaconda used to be downloaded, and now is included on the media; linux-firmware bloat, which is the fastest growing package for the past few years. Front this point there's a bunch of pressure points and trade-offs. This cycle we were over CD-ROM size of 700MiB, and ended up trimming out about 30M from linux-firmware.
-- Chris Murphy
It's also X based with GUI's, rather than an ncurses based graphical interface. Reviewing a fresh install, there is little to nothing that couldn't be done in a much, much smaller text interface going through a linear checklist with ncurses, and follow Eric Raymond's old guidelines for open source interfaces titled "The Luxury of Ignorance". But some folks like pretty GUIs, even though sophisticated GUI's cost resources to run.
They are also much more intuitive to use for your average user/ newcomer to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
Cheers,
Dan
On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
They are also much more intuitive to use for your average user/ newcomer to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
I totally agree. If presented with only a text interface, I believe that new Linux users would perceive the install experience as either too daunting or not up to par with other distros.
Robby
Is it worth paying hundreds of MBytes of installer space, and the new 2 GB minimum RAM to simply install Fedora? I'm not saying "discard anaconda". I'm saying "be aware of some very real reasons the installer has gotten so huge". And keep it in mind for your own projects.
On Sun, Oct 17, 2021 at 4:32 PM Robby Callicotte via devel devel@lists.fedoraproject.org wrote:
On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
They are also much more intuitive to use for your average user/ newcomer to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
I totally agree. If presented with only a text interface, I believe that new Linux users would perceive the install experience as either too daunting or not up to par with other distros.
Robby
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Monday, October 18, 2021, Nico Kadel-Garcia nkadel@gmail.com wrote:
Is it worth paying hundreds of MBytes of installer space, and the new 2 GB minimum RAM to simply install Fedora? I'm not saying "discard anaconda". I'm saying "be aware of some very real reasons the installer has gotten so huge". And keep it in mind for your own projects.
Yes today's hardware is not the same we had at that time. Saving disk space and memory for the sake of saving disk space and memory is to use your words "not worth it".
On Sun, Oct 17, 2021 at 4:32 PM Robby Callicotte via devel devel@lists.fedoraproject.org wrote:
On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
They are also much more intuitive to use for your average user/
newcomer
to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
I totally agree. If presented with only a text interface, I believe
that new
Linux users would perceive the install experience as either too daunting
or
not up to par with other distros.
Robby
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, 18 Oct 2021 at 02:20, drago01 drago01@gmail.com wrote:
On Monday, October 18, 2021, Nico Kadel-Garcia nkadel@gmail.com wrote:
Is it worth paying hundreds of MBytes of installer space, and the new 2 GB minimum RAM to simply install Fedora? I'm not saying "discard anaconda". I'm saying "be aware of some very real reasons the installer has gotten so huge". And keep it in mind for your own projects.
Yes today's hardware is not the same we had at that time. Saving disk space and memory for the sake of saving disk space and memory is to use your words "not worth it".
This conversation is one that seems to happen to computer people as they age. I remember in the early 1990's that the Sun 4.1 installer was incredibly bloated and required too much memory/cpu to anyone who had installed a PDP, IBM 360x, etc. And the arguments we had when the Fedora Core 1 being so bloated to the Red Hat Linux 4 installer. etc etc. The standard ending of these conversations is "coders these days just don't care about memory/cpu/disk space like we had to". [Completely forgetting that was what they were told when they were 20 years younger.]
Of course, if memory/cpu/disk was really important... you could still use that Fedora Core 1 as your daily driver. It would just take some work.
I am going to reply to the parent and grandparent post at once, starting with the parent post:
Stephen John Smoogen wrote:
This conversation is one that seems to happen to computer people as they age. I remember in the early 1990's that the Sun 4.1 installer was incredibly bloated and required too much memory/cpu to anyone who had installed a PDP, IBM 360x, etc. And the arguments we had when the Fedora Core 1 being so bloated to the Red Hat Linux 4 installer. etc
Well, yes, creeping bloat has been an issue all the time, from the beginning. Otherwise, it would not be such a big issue. This is exactly how exponential growth works: the longer you let it happen, the more outrageous the growth ends up being. Hence, pointing out that "it was always like that" is not a valid excuse, it is actually the reason things have become as bad as they are.
etc. The standard ending of these conversations is "coders these days just don't care about memory/cpu/disk space like we had to". [Completely forgetting that was what they were told when they were 20 years younger.]
I take objection to this statement. I was already having this discussion, complaining about the bloat, 20 years ago. (And another 20 years before that, I was not even born yet.) Now, we got another factor 10+ multiplied on top of that.
Of course, if memory/cpu/disk was really important... you could still use that Fedora Core 1 as your daily driver. It would just take some work.
That is not a realistic proposal because that release no longer gets updated, which means: * no security fixes, * no browser support for today's web sites, * no client support for today's network protocols, * no software support for today's file formats, etc.
"Just use the old version" is a standard answer to people complaining about size regressions, but it does not help when only the bloated version is still maintained.
Unfortunately, software is not something that is written once and can then be used forever, but generally needs constant effort to keep working.
On Mon, 18 Oct 2021 at 02:20, drago01 drago01@gmail.com wrote:
Saving disk space and memory for the sake of saving disk space and memory is to use your words "not worth it".
And this attitude is exactly why all the above happens that way.
See my post further up this thread for current use cases in which it is actually worth caring about this issue. I do not wish to repeat myself.
Kevin Kofler
Am 17.10.21 um 22:31 schrieb Robby Callicotte via devel:
On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
They are also much more intuitive to use for your average user/ newcomer to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
I totally agree. If presented with only a text interface, I believe that new Linux users would perceive the install experience as either too daunting or not up to par with other distros.
I think the real reason of my posting got out of sight:
it's not about how big the Installation Medium aka. iso-file is, it's how much stuff lands on the disk after the os is installed.
Of course Fedora primary target is the desktop PC with lots of diskspace and ressources.
In case of the IoT mobility fraction, diskspace is limited and a 20 GB os is not desireable nor really useable on a phone.
i.E. all of the firmwarefiles are unneeded, no grub, no uefi, no printersupport, no wacom-artpadsupport, no colormanagementdemons, and a lot of nice apps for a desktop, but not so practical on a phone i.e. Rythembox are not even the worst things. A "du -sh" showed a huge lot of libs on the system /usr was 2.5g alone. All those icons sets, fonts etc.etc. took a lot of space. journald has no default maxsize, and it does not really help, when pkcon generates it's on caches besides DNF ones.
The mobility has thrown out a lot of packages we don't need here, but thats only a fraction of what could go IMHO. Some folks helped to identify unneeded packages, but a real mininal image in sense of used diskspace, is something else, I think .
IF, like in the dark ages of linux, a list exists of "needed for the os to run" and "os can function without it" would exist, we could throw out so much more.
ATM, i still see a long way to go for Linux on Phones, but Android didn't do it overnight either.
best regards, Marius Schwarz
On Tue, 2021-10-19 at 10:57 +0200, Marius Schwarz wrote:
Am 17.10.21 um 22:31 schrieb Robby Callicotte via devel:
On Sunday, October 17, 2021 3:05:13 PM CDT Dan Čermák wrote:
They are also much more intuitive to use for your average user/ newcomer to Linux in contrast to a text interface (which will put them off when compared to the Windows or Ubuntu installer). Yes, a text interface is much more resource friendly, but imho that will cause more harm than actual benefit.
I totally agree. If presented with only a text interface, I believe that new Linux users would perceive the install experience as either too daunting or not up to par with other distros.
I think the real reason of my posting got out of sight:
it's not about how big the Installation Medium aka. iso-file is, it's how much stuff lands on the disk after the os is installed.
Of course Fedora primary target is the desktop PC with lots of diskspace and ressources.
In case of the IoT mobility fraction, diskspace is limited and a 20 GB os is not desireable nor really useable on a phone.
i.E. all of the firmwarefiles are unneeded, no grub, no uefi, no printersupport,
I actually use printer support on Android quite a lot - I don't think we should regress on that.
no wacom-artpadsupport,
Actually, I regularly use the Wacom One[0] pen display with an Android Tablet & I'm certainly looking forward to using it with a proper Linux distro running mobile device. Actually, even the current PinePhone model has HDMI out support - I need to try connecting my PinePhone the tablet to it to see what happens.
no colormanagementdemons, and a lot of nice apps for a desktop, but not so practical on a phone i.e. Rythembox are not even the worst things. A "du -sh" showed a huge lot of libs on the system /usr was 2.5g alone. All those icons sets, fonts etc.etc. took a lot of space. journald has no default maxsize, and it does not really help,
For comparison journald on Sailfish OS[1] (which is pretty close to a regular Linux distro) is configured to only log to a circular buffer in RAM. Good for storage space use and flash storage longevity, but problematic if you need to debug something and don't manually dump the current journal buffer right away.
when pkcon generates it's on caches besides DNF ones.
I guess you could just configure both to have no caches ? It would make all operations slower but unless both can work with static maximum limits that seems like the only way at the moment.
The mobility has thrown out a lot of packages we don't need here, but thats only a fraction of what could go IMHO. Some folks helped to identify unneeded packages, but a real mininal image in sense of used diskspace, is something else, I think .
Frankly, some mobile platforms seem rather too cut down these days - as long as you don't needlessly spin the CPU (and thus quickyl drain the battery) then storage use is not *that* problematic these days, especially if you need to do a major system surgery.
Also especially as more and more devices can be connected to a monitor and mouse + keyboard, effectively becoming an ad-hoc semi desktop. Same thing for ARM powered light notebooks (PineBook, etc.) or tablets with detachable keyboards. There all the packages cut in the name of *mobile* could be needed but missing.
IF, like in the dark ages of linux, a list exists of "needed for the os to run" and "os can function without it" would exist, we could throw out so much more.
ATM, i still see a long way to go for Linux on Phones, but Android didn't do it overnight either.
Android also started with pretty low baseline - it hardly did usable multitasking initially & had no support for showing more than one app at once, not to mention support for connecting any perifferals. Native app support was also quite poor and is still problematic to this day due to the non-standard bionic c library. No support for widely used GUI toolkits, forcing all apps to write a new UI just for Android. No cross package dependencies, so apps need to bundle half the Internet, etc.
IMHO Android, especially in its early form and largly in the present one its not something we should strive to copy in 2021.
best regards, Marius Schwarz
Best Wishes
Martin
[0] https://www.wacom.com/en-us/products/pen-displays/wacom-one [1] https://en.wikipedia.org/wiki/Sailfish_OS
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Marius Schwarz wrote:
no printersupport
Uh, you can actually attach a printer directly to a PinePhone, either using the convergence dock or USB C directly.
ATM, i still see a long way to go for Linux on Phones, but Android didn't do it overnight either.
I have been using a PinePhone as my everyday smartphone for three months now. (It is not currently running Fedora though, but Manjaro Plasma Mobile.) It is in fact my first smartphone, because I have always refused to use the Android or (worse) iOS (ewww!) walled gardens.
That said, realistically speaking, it will probably remain a niche product just as on the desktop.
Kevin Kofler
Nico Kadel-Garcia wrote:
On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy lists@colorremedies.com wrote:
On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
The Fedora 34 netinst image is still 450 times the size of a floppy!
The top two reasons for this: a significant portion of anaconda used to be downloaded, and now is included on the media; linux-firmware bloat, which is the fastest growing package for the past few years. Front this point there's a bunch of pressure points and trade-offs. This cycle we were over CD-ROM size of 700MiB, and ended up trimming out about 30M from linux-firmware.
It's also X based with GUI's, rather than an ncurses based graphical interface.
IIRC, the boot floppy was actually able to boot into graphical Anaconda, which (including all its dependencies, such as X11) had to be either located on the HDD (early releases used an exploded file tree, later ones an ISO file) or downloaded (netinstall).
Kevin Kofler
On Sun, 2021-10-17 at 15:56 -0400, Nico Kadel-Garcia wrote:
On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy lists@colorremedies.com wrote:
On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted from a floppy (older Red Hat Linux releases even had a fully functioning rescue mode on the floppy, later ones could at least still boot a HDD install from the boot floppy, which is how I installed them, and in that way also boot the rescue mode). These days, the minimum boot image (know known as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image is still 450 times the size of a floppy!
The top two reasons for this: a significant portion of anaconda used to be downloaded, and now is included on the media; linux-firmware bloat, which is the fastest growing package for the past few years. Front this point there's a bunch of pressure points and trade-offs. This cycle we were over CD-ROM size of 700MiB, and ended up trimming out about 30M from linux-firmware.
-- Chris Murphy
It's also X based with GUI's, rather than an ncurses based graphical interface. Reviewing a fresh install, there is little to nothing that couldn't be done in a much, much smaller text interface going through a linear checklist with ncurses, and follow Eric Raymond's old guidelines for open source interfaces titled "The Luxury of Ignorance". But some folks like pretty GUIs, even though sophisticated GUI's cost resources to run.
For the record, Anaconda has a text interface that supports configuring a sizeable subset of what the GUI can configure. It looks like this: https://m4rtink.fedorapeople.org/screenshots/fedora/rawhide_f36/f36_anaconda... https://m4rtink.fedorapeople.org/screenshots/fedora/rawhide_f36/f36_anaconda...
Just append "inst.text" to the installation image boot options to try it out. :)
As for RAM requirements at installation time - it's complicated. :P
As already mentioned, the installation image has grown and in some scenarios its size can directly impact RAM requirements, as the image needs to be downloaded and held in RAM at installation size (PXE boot with HTTP installation source).
In other cases there is no direct impact on RAM via image size - if you boot from say a flash drive or PXE boot with innstallation sorce on NFS, most of the installation image will be streamed to to RAM only as needed.
BTW, there is just a single installation image, that contains all the dependencies needed to run both the graphical and text interfaces. It would be technically possible create quite a bit smaller TUI/kickstart only image without all the GUI deps but AFAIK so far no one was interested in doing that given the additional QA and releng resources needed for yet another Fedora deliverable.
UI also affects resource usage, which is one of the reasons Anaconda has not only the graphical but also the text UI. (The other reason being systems that simply can't boot to GUI for various reasons.)
Additionally Anaconda also sets up zram at installation time, to reduce ram requirements even further via compression.
So in short the best current scenario is Anaconda booted in text mode from a USB stick or via PXE with NFS installation source - that should require the least amount of RAM at installation time.
Still even then, especially with kickstart installations that have elaborate post scripts (that need RAM to run as well!) or install tons of packages (depsolving as well as elaborate RPM scriptlets need RAM!) can still throw a wrench into the works.
And lastly, LUKS2 uses the Argon2 key derivation function that by design requires quite a bit of memory, to make password brute forcing less viable (eq. to parallel password guessing the attacker needs quite a bit of memory per parallel guess run). This can also influence minimum RAM requirements quite a bit.
Best Wishes Martin Kolman
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Hi,
So in short the best current scenario is Anaconda booted in text mode from a USB stick or via PXE with NFS installation source - that should require the least amount of RAM at installation time.
Still even then, especially with kickstart installations that have elaborate post scripts (that need RAM to run as well!) or install tons of packages (depsolving as well as elaborate RPM scriptlets need RAM!) can still throw a wrench into the works.
Also install with just the server repo. The repodata needs memory too, so when adding the "everything" and "updates" repos RAM requirements go up too.
take care, Gerd
On Tue, 2021-10-19 at 07:33 +0200, Gerd Hoffmann wrote:
Hi,
So in short the best current scenario is Anaconda booted in text mode from a USB stick or via PXE with NFS installation source - that should require the least amount of RAM at installation time.
Still even then, especially with kickstart installations that have elaborate post scripts (that need RAM to run as well!) or install tons of packages (depsolving as well as elaborate RPM scriptlets need RAM!) can still throw a wrench into the works.
Also install with just the server repo. The repodata needs memory too, so when adding the "everything" and "updates" repos RAM requirements go up too.
Yes, indeed - I've definitely seen cases where depsolving itself was cuaing OOM - so metadata size, package count and possibly other related factors can influence RAM requirements.
take care, Gerd _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Oct 18, 2021 at 05:23:55PM +0200, mkolman@redhat.com wrote:
As already mentioned, the installation image has grown and in some scenarios its size can directly impact RAM requirements, as the image needs to be downloaded and held in RAM at installation size (PXE boot with HTTP installation source).�
nbdkit!
nbdkit -U /tmp/sock curl https://... nbd-client -unix /tmp/sock /dev/nbd0 # install off /dev/nbd0, image is demand-loaded over HTTP
It even works if the remote disk is compressed.
Rich.