I apologize if there are any mistakes, as I’m Russian and translating with the help of a translator (DeepL) into English.
Just wanted to ask/ask if you are planning to make some kind of completely free and Open Source variant or branch of CachyOS? To have only free, Open Source programs and drivers, a linux-libre or CachyOS-linux-libre kernel, maybe replace Systemd for example with OpenRC and all that?
And also do you plan to make several options/systems of updates: for example it will be possible to switch between stable versions of packages that are updated less often or to the normal mode when packages are always the newest?
Sorry if such questions have already been asked or if they are too trivial )
We really do not plan to provide such a variant, since it would require providing extra repos, cleaning up the other repos from systemd depdencies and so on. This would complicate everything more then it already is and we would also have not the time for it, since we are also working on this project in our free time.
Hi,
Thank you for your reply. I too realize that it would cause a lot of complications and unnecessary actions.
But some people may need it or want to change/customize it and then the question arises - is there any way to do any of this yourself or is it better not to even try as it may break? There are probably already tutorials/guides that describe how to do this, but do you plan to add something like this to your Wiki?
Well…to answer your question about adding things to the wiki, I could certainly provide some of my own unofficial modifications that aren’t native to the distro it self but aren’t too overly complicated to implement either. I am someone who has spent this last year learning about things like kernel parameters, environment variables, ld modules, I have no actual proof that might suggest that my changes will provide any improvements but there are still some reasonable use cases for my personal changes. I am also considering offIering my overall english speaking skills to potentially make their wiki more readable. Granted there are some users who don’t have the best reading skills that don’t live in North America. Are there any particular things that your seeking to gain? There is little room for optimizing Cachy OS beyond where it is already at. I need more details to come up with ideas.
I’m glad that you can help in the development of this distribution even with your own unofficial modifications, it’s good that you keep learning a lot.
Have you tried discussing your changes and modifications with the CachyOS developers like ptr1337? Maybe they would consider adding these changes or translations to CachyOS or just adding it to the Wiki as a recommendation for example for gamification or tweaking the system to suit your needs?
Maybe you could run tests/benchmarks with and without your changes or provide instructions on how to add this to other users so they can try it themselves and share their experiences for further development?
I don’t know exactly what details to suggest, have they tried adding patches from Zen or other modified kernels to their CachyOS kernel? For example they could add the ability for users to easily enable more different daemons like: thermald, preload, irqbalance, tuned, healthd, fail2ban, cpupower, auto-cpufreq, afancontrol (maybe some of these are already present but I don’t know about them) or others, and add a description on the same Wiki for beginners so they can choose what they want and what they don’t want and what are the positives or negatives or something like that. Tell users in which scenarios this or that sched-echt will be better. Why don’t they use LTO by default or am I missing something? And also the ability to apply kernel optimizations to their processor/processor manufacturer’s architecture when installing the system?
There is a lot to unpack with your questions. First off, things like cpupower and auto-cpufreq should only be used in the event that your current processor does not directly have the hardware function. Processors older than zen2 for example, do not have a builtin hardware interface. Even then, cpupower and auto-cpu were developed towards intel. I have never used them as I have never used an old intel computer with linux.
Things like preloading are for the most part, not worthwhile unless you are someone who uses a hard disk drive for storage. healthd, irqbalance and tuned are ones that might have use cases for modern hardware. To answer why they don’t use LTO by default is that in some cases, either one of two negative outcomes are at higher risk of ocurring. Before I go into deeper detail, I need to point out that Cachy os has lto flags set to 3. This means that code is compiled with all available hardware functions being baked into the software. This can lead to the higest performance results, but it is not guaranteed. -O3 optimizations are larger in file size which can in some cases introduce more latency to handlling the given tasks. -O2 is the default on pretty much all linux distros. Now, there is another option that might be the better optimization choice when it comes to weaker and older hardware. That would be -Os, which is -O2 but trimmed down to save space. You generally save a fair bit more space with next to no hit to performance. The reduction in space allows for more application data to be stored in the cpu L caches. It takes up less space in storage and ram too. Now while I say that it makes a big difference in older hardware, it still makes a good difference on modern hardware as well.
I will get to working on creating my own guide with Faq answers locally that I will provide to the forums once it is organized and easy to digest. Might take me a couple of weeks to put it all together.
Thanks for the reply.
Well in that case, regarding cpupower and auto-cpufreq, I would suggest some script that determines whether a processor (intel in this case. There may be similar daemons for Amd) has a direct hardware function or not. And depending on that suggests/recommends or doesn’t suggest/recommend the user to install it when installing or running this script or something similar on an already installed system. In my case it’s an Intel I5-6500 processor if it matters to you.
And about Preload similar to the previous one. If you have HDD then it is installed or the system recommends to install it, and if you have SSD/NVME then vice versa.
But with heathd, irqbalance and tuned it is more difficult to determine whether the equipment is up-to-date or not, but you can just offer the user recommendations and a detailed but easy description so that he can decide whether he needs it if he has up-to-date equipment or not if the equipment is not up-to-date or has some incompatibilities or other problems.
Thanks for clarifying about LTO and flags. You are free to use your own discretion. But I’ll make my own suggestion: You can do the same if the user has old hardware with low RAM, L cache, SSD/HDD/NVME, you can offer O2 or -OS instead of O3, but if the user does not insist on O3, one person (LinuxShef) said that it takes about 2 hours to build a Linux kernel with O3 flags, and without O3 flags it takes 4 hours, that is twice as long, and also said and compared CachyOS with Manjaro and said that the Manjaro kernel must be built, and that building the CachyOS kernel doesn’t give any big advantages, so it can be left as it is without unnecessary builds. Or you could let all users decide what’s best for them depending on their hardware and work scenarios or something like that by providing examples, tips, benchmarks and your hardware performance and stuff like that.
Well good luck with creating your own guide with FAQ answers. Essentially what is needed is some powerful way to define a user’s equipment. It will detect all equipment or prompt the user themselves to answer a few questions about their equipment and usage scenario if it can’t detect automatically. And depending on the results it will offer some recommendations, daemons, customizations, settings and such, rather than just determining if there is a possibility to install V3/V4 repositories or only without them.