Announcement

Collapse
No announcement yet.

Linux Kernel Exploit Affecting Linux 3.3 To Linux 3.8

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

  • #31
    Originally posted by kraftman View Post
    So, they use shit to make even worse and slower shit than winblows is?
    Well yes theoretical Microkernels and Managed Languages are slower than a theoretical monolithic kernel and non-Managed languages, however speed isn't everything. Microkernels bring features like being able to switch out drivers at runtime and resilience against drivers crashing, and ultimately they're more a natural expression of the Unix philosophy than these big kernels have ever been. Making it in a managed language is an interesting twist particularly one like C#, they say they're using attributes for instance as part of their driver development set up, Microsoft's Midori is also interesting from the standpoint that they're somehow running a microkernel in a single large address space, and it looks like there's discussion for MOSA to do the same, I'm guessing somehow .NET has features that allow them to actually pull that off safely in the manner (apparently however they're pulling off what they're calling Software Isolated Processes) that split address spaces normally would but I need to do more research in that regard to understand what they're doing. That all said it's going to be interesting to see how those two, MINIX3, Genode, and HelenOS turn out here a few years down the line.
    Last edited by Luke_Wolf; 02-26-2013, 04:04 AM.

    Comment


    • #32
      Originally posted by johnc View Post
      I was just going to say that C has got to be the worst language imaginable.
      "It is better to keep your mouth shut and appear stupid than to open it and remove all doubt." *Hint.
      DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
      SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
      BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
      LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

      Comment


      • #33
        Originally posted by Luke_Wolf View Post
        Well yes theoretical Microkernels and Managed Languages are slower than a theoretical monolithic kernel and non-Managed languages, however speed isn't everything. Microkernels bring features like being able to switch out drivers at runtime
        Which you can already do with kernel modules...

        Comment


        • #34
          Originally posted by dee. View Post
          Which you can already do with kernel modules...
          yeah you kinda can, but I've had more than one kernel panic when trying to switch between drivers while the system is running like that. Even removing and reloading the driver has done it to me before on some drivers (in particular some Ralink drivers from around 2.6.32 or so when they were still in an early state and didn't really work right)

          Comment


          • #35
            If you rewrite Linux in C# garbage, you can kiss your freedom goodbye.

            Originally posted by gilboa View Post
            Originally posted by johnc View Post
            I was just going to say that C has got to be the worst language imaginable.
            "It is better to keep your mouth shut and appear stupid than to open it and remove all doubt." *Hint.
            Correct.

            C, in fact, is outdated. But C# garbage is the last thing one would consider as substitution. Write your home-brewed stuff in this garbage, so when Microcrap "suddenly" revokes its promises or asks for fee - both of which already happened, you loose your home brew, BUT NOT A FREAKING OPERATING SYSTEM.

            Originally posted by Luke_Wolf View Post
            Well yes theoretical Microkernels and Managed Languages are slower than a theoretical monolithic kernel and non-Managed languages, however speed isn't everything. Microkernels bring features like being able to switch out drivers at runtime and resilience against drivers crashing, and ultimately they're more a natural expression of the Unix philosophy than these big kernels have ever been.
            We have HURD.

            Originally posted by Luke_Wolf View Post
            Making it in a managed language is an interesting twist particularly one like C#, they say they're using attributes for instance as part of their driver development set up, Microsoft's Midori is also interesting from the standpoint that they're somehow running a microkernel in a single large address space, and it looks like there's discussion for MOSA to do the same, I'm guessing somehow .NET has features that allow them to actually pull that off safely in the manner (apparently however they're pulling off what they're calling Software Isolated Processes) that split address spaces normally would but I need to do more research in that regard to understand what they're doing. That all said it's going to be interesting to see how those two, MINIX3, Genode, and HelenOS turn out here a few years down the line.
            Particularly C# is a pile of garbage, particularly because its microsoft.
            Midori is a hoax. They do rewrite whole toolchain in order to link it to windowsrt, but nothing more. In the end, you will have rebranded Java.

            Only Hurd has chance to replace Linux as an outgoing evolution, the rest is either hoax, unserious or outright dangerous to use.
            Last edited by brosis; 02-26-2013, 05:03 AM.

            Comment


            • #36
              Yeah writing any OS components in C# (or any other .net language) is plain moronic.

              If you wanted to write a kernel in a managed language, I think Vala or D would be the best options.

              Comment


              • #37
                Originally posted by nightmarex View Post
                Jeez was this a server or something, that's a good leap there!
                Personal workstation. I've long given up on upgrading kernels regularly. Usualy not worth the hassle. I only upgrade if I need some specific improvement or some other component forces me to (typicaly X drivers).

                Comment


                • #38
                  Originally posted by Cthulhux View Post
                  Well, how do they say? "Open source is more secure because more people can see what's going on". Hahaha. Great.
                  Right, because if it were ms or appleturd, not only would they know about the bug, they would do NOTHING about it, and deny its existence.

                  Comment


                  • #39
                    Originally posted by brosis View Post

                    - bunch of rubbish and lies not worth even quoting -
                    right, and now that hex and luke_wolf have completely showed you up as a liar who makes up stories about Mono runtine libraries taking 300mb on a stock Ubuntu install, you come here to spread more nonsense.
                    Last edited by Sonadow; 02-26-2013, 08:22 AM.

                    Comment


                    • #40
                      Originally posted by gilboa View Post
                      "It is better to keep your mouth shut and appear stupid than to open it and remove all doubt." *Hint.
                      You're right -- somehow Lisp slipped my mind.

                      All kidding aside though, for many, many projects C is the best language to use for the task, but it's still the worst language imaginable. It inspires so many of us to want to break things and hurt people.



                      (Note that I'm excluding PHP from consideration since PHP isn't actually a programming language but rather a big turd wrapped up in a disguise of a programming language.)

                      Comment


                      • #41
                        Originally posted by johnc View Post
                        You're right -- somehow Lisp slipped my mind.

                        All kidding aside though, for many, many projects C is the best language to use for the task, but it's still the worst language imaginable. It inspires so many of us to want to break things and hurt people.



                        (Note that I'm excluding PHP from consideration since PHP isn't actually a programming language but rather a big turd wrapped up in a disguise of a programming language.)
                        You're missing the point. Given the inherit requirements of in-kernel development (reentrant code, execution context, huge limitation on stack size, memory footprint and read/write order, impossible to debug, etc), C - not even C++, is the *ideal* language for (monolithic) kernel development.
                        Automated garbage collection? when? at what CPU context? at what stack context? who gets to decide it? the compiler?
                        If you ever found STL to be almost-impossible-to-debug in user-land, trying debugging it by looking at asm callstacks.
                        Take the new allocator. Which memory does it use? user? kernel? with or without sleep? At which memory range?

                        In many ways the Linux kernel developers managed to achieve C++ like OO design *without* sacrificing the strict control on code generation.
                        Trying to achieve the same using C++ would have far more difficult.

                        EDIT: Really, take the same to do some reading about the Linux kernel. Once you're done, come back and tell me that C isn't the right tool for the job.

                        - Gilboa
                        Last edited by gilboa; 02-26-2013, 09:31 AM.
                        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                        LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                        Comment


                        • #42
                          Originally posted by gilboa View Post
                          You're missing the point. Given the inherit requirements of in-kernel development (reentrant code, execution context, huge limitation on stack size, memory footprint and read/write order, impossible to debug, etc), C - not even C++, is the *ideal* language for (monolithic) kernel development.
                          Yup, and I've never said any different.

                          EDIT: Really, take the same to do some reading about the Linux kernel. Once you're done, come back and tell me that C isn't the right tool for the job.
                          It's definitely the right choice for a kernel (and many other things), but that doesn't change the fact that it's the worst language imaginable.

                          Comment


                          • #43
                            Originally posted by johnc View Post
                            Yup, and I've never said any different.
                            It's definitely the right choice for a kernel (and many other things), but that doesn't change the fact that it's the worst language imaginable.
                            Guess we will have to agree not to agree

                            - Gilboa
                            DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                            LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                            Comment


                            • #44
                              Originally posted by brosis View Post
                              We have HURD.

                              Only Hurd has chance to replace Linux as an outgoing evolution, the rest is either hoax, unserious or outright dangerous to use.
                              I've already addressed the C# stuff elsewhere, but HURD brosis? HURD is the one microkernel that is going nowhere fast, particularly with them still being tied down to Mach. At the very least go with one of the viable ones like HelenOS, nothing against the HURD developers but they killed their project when they tied themselves down to Mach and haven't been able to switch over to a modern microkernel like L4 since, and unless that changes Hurd just isn't viable...

                              Comment


                              • #45
                                Originally posted by brosis View Post
                                Only Hurd has chance to replace Linux as an outgoing evolution, the rest is either hoax, unserious or outright dangerous to use.
                                Without going into the micro-vs.-monolithic kernel debate, Hurd is dead jack.
                                Its development is so far behind its unlikely it'll ever be used outside a *very* small group of developers and devoted users.

                                The only possible threat to Linux in the non-MS world is *BSD, but currently I simply don't see the 10-100bn$+ company that will back it up with all its might.
                                (On the other hand, Linux has Samsung, Intel, Google and IBM, just to name few).

                                - Gilboa
                                DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                                SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                                BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                                LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                                Comment

                                Working...
                                X