Linux Kernel Exploit Affecting Linux 3.3 To Linux 3.8

[gilboa]

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

[johnc]

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.

[gilboa]

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

[Luke_Wolf]

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

[gilboa]

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

[Detructor]

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.

[Luke_Wolf]

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.

[dee.]

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.

[JS987]

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?

[dee.]

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.