Tweet
Great, just disable everything that makes Linux good, first it was soft scrollback, now this? What's next? Remove Nouveau because it's "full of bugs"?
-
-
-
-
Those don't make Linux any good. From what I've gathered, the console FB drivers suck no matter which vendor you use. The whole subsystem is a kludge. If you need any higher res than 80x25 or 80x50, you should be using Wayland or X. Most hardware uses the simple FB driver anyways. If you need kernel crash dumps, learn to use serial dongles. FB drivers don't work nicely with multiple monitors. They're slow, buggy. Having the scroll code in user-space is a lot better than having it in the kernel space.Originally posted by hax0r View PostComment
-
If you think the closed source development model in companies is any better, well I have news for you..........Originally posted by birdie View PostComment
-
-
To summary, everything in single address space monolithic kernel written in C is a kludge and anything written in safe an modern languages in user-space is a lot better than having it in a single address space monolithic kernel written in C. ;-)Originally posted by caligula View PostComment
-
That is a little strong! :-)Originally posted by rene View Post
I hope you manage to write your microkernel, but I suspect you'll find a significant performance disadvantage, even if you could ever catch up feature-wise. Wouldn't you be better off improving Hurd?
Monolithic kernels are certainly more vulnerable to poor subsystem code, certainly from a system stability point of view, although to some degree a kernel panic or oops does get developer attention! ;-) I think it's good that Linux has gradually been moving towards removing kernel subsystems which work fine in userspace, console/terminal emulator should fall into that category, but the value add of previous implementations hasn't been sufficient to displace the kernel console. Maybe now it's completely useless that will change.
I do find it funny that "nobody" uses the console, or scrollback... okay... Just me then???
Comment
-
You've got nothing but a joke. Sorry. And you're also cheap as fuck because we're talking about one thing and you suddenly decide to talk about something completely different. There's a proof right in front of your eyes, that open source does not protect from glaring security issues - while every open source fan stance is that OPEN SOURCE IS A GUARANTEE THERE ARE NO BUGS, OR BACKDOORS OR ANYTHING LIKE THAT. LMAO.Originally posted by sandy8925 View PostComment
-
Sorry no this is you drawing way too much rope and just hung yourself. Little question has that code been enabled in Distribution kernels for the past 10 years. The answer is no it has not been enabled. So incomplete code has been sitting in the kernel with no body using it and no body updating it.Originally posted by birdie View Post
Horrible reality is sometimes code that is open source is full of bugs because in reality it has no users.
Open source does not 100 percent say no bugs but it does allow third parties(distributions) to review and disable parts that are too bad that in a closed source environment this cannot happen.
Sorry not every open source fan has the point of view that open source is no bugs.
In software development, Linus's law is the assertion that "given enough eyeballs, all bugs are shallow".
Linux open source fans follow the idea of Linus's Law and that does apply to this frame buffer console dropping accelerated from mainline and was kept shallow because the feature was optional build that distributions have not been enabling. So only parties going out their way were being exposed to this stack of flawed code.
Comment
Comment