Announcement

Collapse
No announcement yet.

Linux Frame-Buffer Console To Drop Accelerated Scrolling Since It's Full Of Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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"?

    Comment


    • #12
      Originally posted by rene View Post
      imagine after 30 years of development each time someone looks closer at any given subsystem
      it's not "any" subsystem. it's subsystem nobody uses

      Comment


      • #13
        Originally posted by birdie View Post
        But millions of eyes ... yeah, right. Speaks volumes about the Open Source development model.
        did you try fuzzing closed source kernel, moron?

        Comment


        • #14
          Originally posted by hax0r View Post
          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.

          Comment


          • #15
            Originally posted by birdie View Post

            But millions of eyes ... yeah, right. Speaks volumes about the Open Source development model.
            If you think the closed source development model in companies is any better, well I have news for you..........

            Comment


            • #16
              Originally posted by pal666 View Post
              it's not "any" subsystem. it's subsystem nobody uses
              . lol .

              Comment


              • #17
                Originally posted by caligula View Post

                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.
                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. ;-)

                Comment


                • #18
                  Originally posted by rene View Post

                  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. ;-)
                  That is a little strong! :-)

                  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


                  • #19
                    Originally posted by sandy8925 View Post

                    If you think the closed source development model in companies is any better, well I have news for you..........
                    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.

                    Comment


                    • #20
                      Originally posted by birdie View Post
                      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.
                      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.

                      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.

                      https://en.wikipedia.org/wiki/Linus%27s_law
                      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

                      Working...
                      X