Hi all.
Sorry I haven't gotten out a MuQSS and -ck release for linux-5.8. Some of you have been emailing me to check on my well-being in this crazy world. I appreciate the concern, and apart from family issues, I've been fine. It's fair to say that my motivation for keeping up with linux kernel development has been flagging for some time now and the current world situation is not helping. Hearing the news extol the virtues of linux-5.8 being the "biggest release ever" does not particularly aid my situation. If it were just a massive drop of new drivers I could understand that, but usually it just means yet more rewrites of major infrastructure within the kernel in the quest to "make it better." Personally I don't think it's such a great thing, but that's a debate best left for elsewhere. I do plan to stay in sync with 5.8 and future kernel releases, but I'm not sure when I'll be motivated to resume that resyncing process. My biggest concern with the massive churn is me screwing something up in a way that leaves users of my code open to security issues or fatal data corruption at some stage because I haven't been careful enough to protect against this happening. For this reason I've often considered abandoning the code entirely but some supportive individuals have stated they find comfort in the relative stability and continued utility of MuQSS's code in the increasingly volatile kernel churn world which is reassuring and encouraging enough for me to at least plan to stay in sync.
As time goes on and more and more features get added to the scheduler that have nothing to do with ordinary desktop and mobile platform usage, at some stage distributions will be tempted to become dependent on one or more of those features and if I don't develop MuQSS much further to incorporate my own version of those features, it will become redundant. Given the completely different scheduler architecture of MuQSS versus CFS means I can't simply just port over the code most of the time; I have to write my own complete feature equivalent version and these are far from trivial. The accounting code is completely different, most of the CGROUP features aren't even implemented, and deadline scheduling is not available at all for example. If more of these appear in the future and eventually become showstoppers, then unless some miracle happens to make me find the motivation to work on them, it will be the death of it.
Cheers all. Stay safe and well,
-ck
Is there a way for a non kernel dev to support you? Don't give up!
ReplyDeleteHello, I use your kernel since I discovered them. I installed it on my wifes's computer and her father's too. It works great, I love it. I really understand you, though. It takes time to maintain software. I would be sad if you stop -ck kernel releases. But it is your choice, I respect that. Anyway, I send you a thousand thanks for the work you have done so far.
ReplyDelete+1
DeleteI'm using it for gaming otherwise it takes ages for the mouse to respond. Thanks Con.
+1
DeleteYour patches make Linux usable (for real efficient work) on the desktop.
Without them the kernel is just too "laggy".
Many thanks for making Linux enjoyable to me.
I understand.
Thanks again.
I have been using and enjoying your patches since kernel version 3.12.x or something.
I cannot say thanks enough.
Thanks.
In order to keep compatibility with backports, LTS is still needs to be maintained
ReplyDelete5.9 will be probably LTS.
ReplyDeleteCheers to you con! **You** stay safe & well!
ReplyDeleteI'm older than you and... feel exactly the same.
Older... I stopped at 4.19!
You know better than me what death means but ideas never die.
Thank you a lot for 10+ years spent on my core 2 duo thanks to your ideas. CFS will necessarily need to be rewritten from scratch some day or another, I wish a whole bunch of all brand new ideas to those who will be in charge of that but be certain that no one capable of this will ignore your contribution to the world of scheduling.
Just wanted to affirm what everyone else is saying and say I really appreciate your work! With the regular kernel my desktop is nearly unresponsive when I have several processes with high-CPU usage open. With your kernel it runs like butter.
ReplyDeleteI understand your concerns... and with added features to CFS, backporting said functions is not as trivial as to just rebase the current code.
ReplyDeleteMuQSS has been fairly stable and not prone to huge failures, so its sad to not have an alternative... but it would be equally crap if lets say some code utilizing CGROUPS or whatever would missbehave too... so i would rather have stability > "rebase just to get it out".
Keep safe. Once (if?) the world gets back to normal, you could always revisit the code and come back stronger with MuQSS 2.0, rather than let this get in the way of life & happiness :)
Hmmm, as an engineer, been getting abit skeptical about this potentially-perpetual "make it better" thinking for a while. How much is this to the benefit of mobile/desktop arena ?
ReplyDeleteCould it be at some point that realisation of a pragmatic desktop/mobile linux kernel can only occur with a hard-fork of the kernel, say {Matthew Garrett, Con Kolivas, et al.}
contributing to a pragmatic-Linux-kernel for mobile/desktop arena or even taking up a "void linux" like approach (i.e. bloat-free-linux-from-scratch-no-systemd-approach) and directed towards
laptop/desktop arena.
I feel the true "sleeping giant usage scenario" for linux is mobile/desktop arena for linux.
Yes, linux in server space is admirable.
But capturing the full potential of the mobile/desktop arena
would be like the "holy grail".
The "1%" linux numbers on Valve's "Steam" gaming platform is very telling ...
With the years that have passed and knowledge gained since the mid-1990's, it should not be this way.
Could uber-fragmentation be a double-edged sword ?
Recently, I had made an important change to my C++/scripting software-development workflow
that reminded me of that notion that sometimes "need to go backward in order to go forward".
This relates to replacement of BASH (since mid 1990's) with OOREXX (about 1.5 years ago).
My god, what a difference it has made.
OOREXX stems from REXX (object oriented additions to REXX).
REXX is the grand-daddy of script/shell languages and has interesting/pragmatic design decisions to the point that it put's many features of future shell languages
(e.g. sh/bash/etc.) to shame. The seriousness of this stance is coupled with my "toy idea" of taking Void linux and stripping out bash/etc. language and replacing
with a single OOREXX scripting language .... just to see if it's workable.
The software-development paradigm I have learned to accept years ago was one where the operating system (through {terminal, custom fltk-dialog} instances) acts as the integrated-development-evironment (IDE) instead of a single main-window acting as an IDE.
REXX (i.e. OOREXX) acts as an effective/simple "glue" language allowing rapid development of aspects of the "operating-system-is-the-IDE" paradigm. A rich/custom/intuitive OS-based IDE is obtainable through scripting, as it should be.
Many years ago, I noticed Amiga (fun computers back in the 1980's) had a REXX implementation (ARexx) and I had a subtle suspicion that this must have been a "good"
idea but never really looked into that theme.
Now I realise why Amiga use rexx, and good on them.
I JUST WONDER .....
Is it time for a serious evaluation of future/potential of mobile/desktop linux
to the point that some BACKWARD steps are required in order to go FORWARD ?
Regards,
Andreas.
Dear Con,
ReplyDeleteYou write : "My biggest concern with the massive churn is me screwing something up in a way that leaves users of my code open to security issues or fatal data corruption at some stage because I haven't been careful enough to protect against this happening"
Wy worrying ?
You have been producing the best solution money can't buy for enabling reliable low latency small systems.
Today, when I consider that the best thing I can do on my tiny system in order to keep latency under indecent values is to boot nopti a (RETPOLINE=[n] && SLAB_FREELIST_HARDENED=[n] &&...) kernel... then... you know... if something wrong happens I won't blame you for whatever possible security breach into the ck patchset...
Anyway, still under 4.4 running BFS-467 on a 10+ years core2 duo based system, I would like to thank you for the time&money you spent saving mine, for the courage you have shown in sad moments of your life and for everything I can't even imagine and for which you definitely deserve respect.
Stay safe, you and all those you care about.
noooooooooooooo ;(((((((((((((((
ReplyDeletewhy 4.19? plis ;D
ReplyDelete