OSX works like GNU/Linux ir any other *nix system. Windows works more like a Nintendo or XBox operating system. The difference is ONLY that on *nix systems (or Windows before they stopped being a shell on top of DOS), there is a choice in graphical environments, and the user can change to what the user likes best, whereas when the graphical environment IS the operating system, there is no choice, it is what it is.
This may be of interest: http://liquorix.net/
What you describe exists above, the Zen kernel project (its just on github now?), and distro kernel maintainers.
sysctl stuff is also well documented and generally sensible, but on a switch with other stuff can you be sure your not just opening up a weakness, denial of service or changing a limit you wont even get close too?
To expand this into the kind of service tweaks I remember from my computer Windows days, this need is filled by distros.
I'm not saying don't do it, but make sure you're not missing out on taking a load of knowledge and ideas from someone who's wanting to share them.
Use the latest kernel with the BFS scheduler. That gave me a slight boost. Install the latest microcode available for your hardware, use BTRFS in conjunction with XFS, compile the kernel from scratch only enabling the modules you need, and that's about it. I'm not sure you can do much more. Use a lighter DE I guess. Overclocking your processor never hurts either... Granted you don't fuck up
Use the latest kernel with the BFS scheduler. That gave me a slight boost. Install the latest microcode available for your hardware, use BTRFS in conjunction with XFS, compile the kernel from scratch only enabling the modules you need, and that's about it. I'm not sure you can do much more. Use a lighter DE I guess. Overclocking your processor never hurts either... Granted you don't blow it up
I have tried both the liqourix kernel and the zen kernel. I have not used Zen in a while, because I thought it was killed off, but then found that it was being hosted in github instead of off their own website and I do not really like to use git as I have to install extra packages to get git to work.
What I like about the guy behind liqourix is that if you ask him what changes he made to his kernel that differs from stock he will tell you. Which I like because he is very open. Not like many Distro creators.
It would be nice of the guys and gals that work for their distro, to release the information like what compile time flags they use in their distro and a page which shows what patches they are using and why they are using them, so that others not using their distro can benefit from them. It is not like the creators of distro's are the Offensive Coordinator of the Green Bay Packers, where they need to keep everything tight lipped. A lot of people when using Linux do not care so much about the speed but the ease of use and the functionality as well as what packages are available to them. In my mind releasing such information can benefit all Linux distro's. And making choosing a distro easier, because performance wise they will all be operating the same.
A while ago I saw a benchmark comparing Fedora and Ubuntu, they were both using the same hardware and Xorg as well as driver versions, but Fedora beat Ubuntu by a couple of points. ( I can not find the benchmark but it was no more then 3 or 4 points that Fedora had won. It was on Phoronix. ) Also in games Fedora pulled out a 2 - 3 FPS lead over Ubuntu. But if they are using the same packages and hardware you would expect them to get the same results right? Everything that is constant or the same that is started should finish the same. But they finished differently. So Fedora has a modified Xorg or GPU drivers, that they do not release to the public in an easily find-able way and in a way so that other distros that are not .rpm based can use them. Or they used custom compile flags. If you are .rpm based you can download their version of X and their drivers to get the performance increase, but if you are using pacman or dpkg, you can not have access to that performance increase. Fedora do release the source for their x11-server package, but compiling a .deb out of a .rpm source package can be a pain in the but. A vanilla release of the code would be more then acceptable.
Of course I see why they do not release or make it easier for other package managers as they are catering towards their package manager which they should and not other side projects which are not of use to them, as they are not using different package managers. But still vanilla packages that can be compiled for other package managers would be nice. And having a page with what patches they are using and why would be something easy and not something that is too hard or to out of the way to do.
And I forget as to whether it were CENT OS or RHEL, that released some cool code that improved network performance. But they include it in their own kernel and not as a patch, so if you want to use that network improvement you have to use their distro. And if you want to install BFS with their custom kernel, you can not because they do not release the kernel source code anymore. The last time that RHEL released their kernel source was on 4/30/08 with kernel 2.16.18.92. So if you would want to use RHEL with its performance modified network with BFS you can not do so.
CENT OS also used to release its kernel source code but now they do not. They do have an article on how to get the kernel source code, and a link to where you can go download it, but that links brings you to a 404 error.
I have heard of people unpacking the .rpm with a tool and then unpacking the source code and then applying whatever patch they want to and then build the package again, but I have not heard or read a lot about this.
Also I kind of think that it is a shame, that if you look at ARM based distro's how fast they are compared to Linux Distro's, and to think that many are running off of an SD card, that can not hand a lot of I/O. Web browsers pop up literally in under 4 seconds, text editors open when called upon and so on and so forth. But when you look at what an ARM cpu is it is one that is putting power savings ahead of performance, I know that that is starting to change but, when ARM becomes more powerful, the guys that are tuning ARM for performance now will still most likely be tuning it when they are already fast. Because if it ain't broke don't fix it. Of course in certain areas as of now ARM Linux is a waste, as the time to do things take more considerable time.
I know that sysctl stuff is very easy to come upon. Under kernel.org if you do some searching you can find every sysctl variable that you can change. I just posted it because it is the easiest for people to put into their computers. And I would not have to write up many paragraphs of documentation. If you can not tell already I am horrible at making things fluid and knowing when to create a new paragraph.
I remember using nvlcock on one of my old GPU's and I made a mess of it and the GPU never functioned the same again. Luckily GPU's were cheap back before mining became popular so I was able to replace it quickly. I do not really game anymore so I do not overclock the GPU as a result. Also I have not heard or seen any active CPU software overclocking tools for Linux. I am in the group of people with the box pc's who have the locked BIOS.
One other thing that I have heard in terms of performance tuning is that increasing the kernel past 1,000 hz improves Desktop performance ( so latency and not really throughput. I had heard of people gaining FPS in video games as a result of getting more interrupts per second.) but Con has not released a new version of his increase hz patch.
Do you mean using BTRFS as the boot partition and XFS for the others?
Use BTRFS for the root partition, fat for the boot partition, and XFS for the home partition.
BTRFS allows for fast compression wich is I available for instances where you may be installing a package via Tyra of your native package manager or compiling from source depending on the route you choose. XFS is amazing compression but lacks a lot of the features found in BTRFS.