Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 67

Thread: Linux Kernel Exploit Affecting Linux 3.3 To Linux 3.8

  1. #41
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Quote 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 at 09:31 AM.

  2. #42
    Join Date
    May 2011
    Posts
    1,440

    Default

    Quote 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.

  3. #43
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Quote 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

  4. #44
    Join Date
    Jun 2011
    Posts
    821

    Default

    Quote 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...

  5. #45
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Quote 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

  6. #46
    Join Date
    Sep 2008
    Posts
    263

    Default

    Quote Originally Posted by Luke_Wolf View Post
    Actually doing that is a rather interesting way to do a microkernel and there's this project http://www.mosa-project.org/ and Microsoft Midori doing a managed microkernel in C#. I'll definitely be interested to see if either of those actually goes anywhere.
    for every idea one has...there's someone out there who already realized it.

    *edit

    I never programmed any Kernel stuff, I'm a (or is it 'an'? 'an' would sound strange here but it'd be right...I guess) application developer and to me the difference between C# and C/C++ is that with C#, you got all tools you'll ever need to build your nice house (aka program). In C/C++ you got...two pebbles and a stick. Before you can actually build your nice house, you've to first build all your tools (for example: build a string class).

    So...if you are really good with C/C++ you'll beat a C# program any time any day when it comes to things like performance. But you need more time to develop stuff and your code will be harder to understand/read/change for other people, because you only got those tools YOU needed and you used them the way YOU needed to.

    Also you actually can build your own tools on a level that is completely alien to a C# developer. And you can do stuff that is not even possible in C#. (at least not without calling C libs)

    Sometimes when I boot up Linux, look at it and ask myself how it is even possible that such a large amount of C code, cludged together by many different people, just...works. That's mostly the time when my XServer decides to forget my graphic card or some other weird thing happens.
    Last edited by Detructor; 02-26-2013 at 01:20 PM.

  7. #47
    Join Date
    Jun 2011
    Posts
    821

    Default

    Quote Originally Posted by Detructor View Post
    I'm a (or is it 'an'? 'an' would sound strange here but it'd be right...I guess) application developer and to me the difference between C# and C/C++ is that with C#, you got all tools you'll ever need to build your nice house (aka program). In C/C++ you got...two pebbles and a stick. Before you can actually build your nice house, you've to first build all your tools (for example: build a string class).
    Well actually we have a string class in C++ but I get your point... however... we do have a very very nice toolkit called Qt you might want to familiarize yourself with http://qt-project.org/ it will make your life in programming C++ so much easier.

  8. #48
    Join Date
    Jan 2013
    Posts
    1,443

    Default

    Or you could code in Vala, which is basically syntactically identical to C# but it compiles to C/GObject. Then you can develop GTK apps.

  9. #49
    Join Date
    Sep 2012
    Posts
    319

    Default

    Quote Originally Posted by dee. View Post
    Or you could code in Vala, which is basically syntactically identical to C# but it compiles to C/GObject. Then you can develop GTK apps.
    Does Vala have something like Qt Designer, which can create GUI as XML file, which is converted using uic to C++ code, which is compiled to machine code?

  10. #50
    Join Date
    Jan 2013
    Posts
    1,443

    Default

    Quote Originally Posted by JS987 View Post
    Does Vala have something like Qt Designer, which can create GUI as XML file, which is converted using uic to C++ code, which is compiled to machine code?
    You can create GTK GUIs with Glade, which are saved as XML files, which are then used by the C code that Vala produces - or if you want I guess you can embed the XML file in the C code although doesn't it make more sense to keep it as separate XML so you don't have to recompile every time you make an interface adjustment? - which is then compiled to machine code.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •