2.7: The lost kernel

[Kenny_Strawn]

I am beginning to doubt if a Linux Kernel 2.7 even existed. It supposedly was proposed, but was aborted. Why? The Kernel deserves a rewrite, in order to trim down bloat, but first, I need your opinion. Please explain your votes.

[the yawner]

A re-write? Uhh... Good luck with that. I'm of the impression that the current kernel is bloated in the sense that it's because it's feature-packed compare to the initial version.

[EnGorDiaz]

torvalds commented on that matter a while ago saying that 2.6 was extremely good already and only minor changes had to be made to it like hardware hooks and certain things to make it more evolved with world software

[Giant Speck]

LET'S DO IT!

I'll get the alcohol and you'll... well, you're too young to consume alcohol, but I suppose you can watch me get really, really drunk while I attempt to rewrite the kernel from scratch. If you're lucky, I'll let you help!

[EnGorDiaz]

LET'S DO IT!

I'll get the alcohol and you'll... well, you're too young to consume alcohol, but I suppose you can watch me get really, really drunk while I attempt to rewrite the kernel from scratch. If you're lucky, I'll let you help!

make sure you get some oatinger i always fell for the german beer

[falconindy]

The Kernel deserves a rewrite, in order to trim down bloat
And you base this on what? Do you know how many SLOC are in the kernel right now? To give you a hint, this is a snippet from Linus's release statement for 2.6.34-rc1:

All in all, about 850 developers involved so far (there migth be a few
dups there, I didn't check too closely), 6500+ files changed, 400,000+
lines added, ~175,000 lines deleted. Too much to really summarize, in
other words.

Are you aware that there is already a mechanism in place to "trim down bloat" before a compile?

[Frak]

Let's do it. I want to see Kenny-Strawn-kernel v2.7. If it can do wireless, I'm hooked.

[KiwiNZ]

I am beginning to doubt if a Linux Kernel 2.7 even existed. It supposedly was proposed, but was aborted. Why? The Kernel deserves a rewrite, in order to trim down bloat, but first, I need your opinion. Please explain your votes.

You need to expand your statements.

How is the current Kernel bloated?
Why does it deserve a rewrite?

The originator of the Kernel believes that the current is very resilient and is still not in need of major update.I am interested to hear why you feel it does.

[phrostbyte]

The next "super-major" version of Linux will probably be 3.0. 2.7 is quite unlikely!

[schauerlich]

You should incorporate your automatic device driver writer in the rewrite of the Linux kernel you're planning.

[KiwiNZ]

You should incorporate your automatic device driver writer in the rewrite of the Linux kernel you're planning.

umm please don't. They are not a good idea.

[Daisuke_Aramaki]

Welcome back Kenny!

[Frak]

I do have to admit, though, when I saw "let's rewrite the Linux Kernel", I knew Kenny Strawn was back.

[ukripper]

Old news - http://www.linuxjournal.com/article/7732

[Bachstelze]

How is the current Kernel bloated?
Why does it deserve a rewrite?

http://linuxhelp.blogspot.com/2009/09/is-linux-kernel-getting-bloated-linus.html

[Tibuda]

Welcome back Kenny!

+1

We missed you Kenny!


EDIT: Ontopic, you can grab the latest kernel source from http://git.kernel.org/

[gnomeuser]

No, no, no.

The old kernel development model of running an unstable tree for a year or two with massive breakage led to the situation of distributions having to backport massive amounts of code to have support for hardware and new features. It was unmaintainable hell and anyone who proposes we go back to that model should have his head examined.

I have been there for 2.0, 2.2, 2.4, I participated in the 2.5 development kernel and I can say with certainty that the model we are following currently is highly optimal for rolling out new features and keeping distributions on a supportable close to vanilla kernel.

Right now you are assured a new kernel release roughly every 3 months, for the first 2 weeks we merge new code then it is fixes nearly all the way. There is also an unwritten rule that allows for any component to be replaced, typically this would be done by allowing for the rewritten system to be replacable on an opt-in basis. An example of this is how libata replaced the ide stack for most distributions. We still carry the old ide stack and it continues to get updates but it is less and less needed as libata has now reached stability.

The current model is excellent on the part of rolling out new features and having a fairly strict stability claim. It is easier to test and deliver a stable dependable product if you do things this way. It delivers great stability, low regression count and dependably tested incrementally improved releases every 3 months.

Going back to a tree that would be mired in development for 1-2 years would be horrible especially for desktop distributions like Ubuntu. It would tax the Ubuntu kernel maintainers a lot to back port fixes to the stable tree and the benefit would be less than zero.

No no no.. ever again.

[Tristam Green]

Kenny, your posts never fail to tickle my funny bone. I'm with Frak - if it can handle wireless straight away, I'm all for it.

[forrestcupp]

Make sure to try to have built in support for transporters.

http://imagecache2.allposters.com/images/MELLO/16080.jpg

[Hwæt]

LET'S DO IT!

I'll get the alcohol and you'll... well, you're too young to consume alcohol, but I suppose you can watch me get really, really drunk while I attempt to rewrite the kernel from scratch. If you're lucky, I'll let you help!

Trying to exploit the old Ballmer's peak, eh?

http://imgs.xkcd.com/comics/ballmer_peak.png

From: xkcd (http://xkcd.com/)

[schauerlich]

umm please don't. They are not a good idea.

But look (http://bazaar.launchpad.net/~mango-k/devicematic/files/files) how far he's gotten! Surely this will be a revolutionary new product. That rectangle struct will definitely come in handy.

[bruno9779]

I think that the OP dislikes Ubuntu's vanilla kernel. What else can he mean?

PS: I am not going to vote, as I cannot see the meaning of the question.

[spupy]

2.6.<odd>: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two).
2.<odd>.x: aim for big changes that may destabilize the kernel for several releases (timeframe: a year or two)
<odd>.x.x: Linus went crazy, broke absolutely everything, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two").


Notice how there aren't 2.6.<odd> kernels? I think they are unstable versions. So will 2.7 be. Maybe while 2.6 is honed to perfection, new work will begin with 2.7; the complete stable features from 2.7 will be released as 2.8.

[Bachstelze]

Notice how there aren't 2.6.<odd> kernels?

What is the current stable version of the 2.6 kernel again?

[bruno9779]

2.6.33

lol

[spupy]

What is the current stable version of the 2.6 kernel again?

Sorry, seems I'm wrong. Guess that Linus quote is too old (2005).

[Kenny_Strawn]

You need to expand your statements.

How is the current Kernel bloated?
Why does it deserve a rewrite?

The originator of the Kernel believes that the current is very resilient and is still not in need of major update.I am interested to hear why you feel it does.

Because even Torvalds stated in an article (I believe on PCWorld) that said he believed it was bloated and he even admitted that he liked Windows 7 better. Emphais:

10 million lines of code, while Windows Vista had 50 million. This may not be bad - except for the fact that the Linux kernel doesn't even have a GUI built in while Windows has a GUI and a DE.

[NCLI]

Because even Torvalds stated in an article (I believe on PCWorld) that said he believed it was bloated and he even admitted that he liked Windows 7 better. Emphais:

10 million lines of code, while Windows Vista had 50 million. This may not be bad - except for the fact that the Linux kernel doesn't even have a GUI built in while Windows has a GUI and a DE.

You're forgetting that the Linux kernel has a huge amount of device drivers as well.

[skymera]

I don't think 2.7 is a "lost" kernel.

I think it's a developmentr kernel, much like 2.1, 2.3 and 2.5.

2.7 will become 2.8, or at least form the basis.

I also agree that the kernel is getting too fat.
Back in 2007 Ubuntu Feisty run GNOME quite happily on 77MB RAM without touching swap. Now? ~600MB.

[Kenny_Strawn]

I don't think 2.7 is a "lost" kernel.

I think it's a developmentr kernel, much like 2.1, 2.3 and 2.5.

2.7 will become 2.8, or at least form the basis.

I also agree that the kernel is getting too fat.
Back in 2007 Ubuntu Feisty run GNOME quite happily on 77MB RAM without touching swap. Now? ~600MB.

Yea, and the 2.7 kernel was aborted way back in 2003. Why? I don't know, but it should have been completed by now.

[Kenny_Strawn]

You're forgetting that the Linux kernel has a huge amount of device drivers as well.

Now this is a valid point - Over 80% of the kernel is device drivers, most of which go unused.

You want to know what I was thinking? A derivative work equally of Linux and the HURD that is not monolithic or a microkernel but hybrid, having both monolithic features and microkernel features.

[Chronon]

Because even Torvalds stated in an article (I believe on PCWorld) that said he believed it was bloated and he even admitted that he liked Windows 7 better. Emphais:

10 million lines of code, while Windows Vista had 50 million. This may not be bad - except for the fact that the Linux kernel doesn't even have a GUI built in while Windows has a GUI and a DE.


Is your point that the Linux kernel needs more bloat?

[descendent87]

Wouldn't the lost kernel be 4.8.15.16.23.42?

I'll get my coat....

[DoktorSeven]

The problem is that the current kernel has become a huge testing ground for any new thing they want to put in.

Before, the "even" kernels were considered the stable ones. Not much changed, and not a lot of development went into the stable ones. The return on this was that you had a kernel that was, in fact, rock solid when it came to stability because you didn't have tons of scheduler rewrites, new filesystems and such going into a mainline kernel like you have with 2.6. Of course, many may argue that "the current kernel IS stable", but I think the capability is there to cause a lot of problems with people who depend on mainline kernel to remain stable AND patched with any security updates without having to worry about backporting any stability patches back to their current kernel version. This is what mostly happened with 2.4, with all of the "crazy" development going into 2.5 and tested extensively without any fear of the current kernel becoming unstable from any extensive changes, then releasing 2.6 when they felt it was sufficiently tested and stable.

I would like to see this development model again. Adding new features and such as you go along might be fine for some desktop app or something, but this is the Linux kernel we're talking about here -- I don't want kernel devs messing around with it just because they think it needs changing for the heck of it. Put any new features you want in 2.7 and release 2.8 sooner rather than later. You can always stick with 2.6 since they continue patching old kernels (2.4 still gets updates!) until you're ready and confident in the next version, and desktop distros and bleeding edge people can go to the new one right away.

It's a much more sane development process to me than what I see as a reckless, chaotic kernel development process they've adopted with 2.6, and I really wish they would go back.

[phrostbyte]

The problem is that the current kernel has become a huge testing ground for any new thing they want to put in.

Before, the "even" kernels were considered the stable ones. Not much changed, and not a lot of development went into the stable ones. The return on this was that you had a kernel that was, in fact, rock solid when it came to stability because you didn't have tons of scheduler rewrites, new filesystems and such going into a mainline kernel like you have with 2.6. Of course, many may argue that "the current kernel IS stable", but I think the capability is there to cause a lot of problems with people who depend on mainline kernel to remain stable AND patched with any security updates without having to worry about backporting any stability patches back to their current kernel version. This is what mostly happened with 2.4, with all of the "crazy" development going into 2.5 and tested extensively without any fear of the current kernel becoming unstable from any extensive changes, then releasing 2.6 when they felt it was sufficiently tested and stable.

I would like to see this development model again. Adding new features and such as you go along might be fine for some desktop app or something, but this is the Linux kernel we're talking about here -- I don't want kernel devs messing around with it just because they think it needs changing for the heck of it. Put any new features you want in 2.7 and release 2.8 sooner rather than later. You can always stick with 2.6 since they continue patching old kernels (2.4 still gets updates!) until you're ready and confident in the next version, and desktop distros and bleeding edge people can go to the new one right away.

It's a much more sane development process to me than what I see as a reckless, chaotic kernel development process they've adopted with 2.6, and I really wish they would go back.

Linux development is still kind of like that, even if it doesn't look that way. Eg: "linux-next" tree where experimental features go, only when they are stable to they get to go to Linus's tree.

Actually, there are many hundreds of trees: http://git.kernel.org/

[Chronon]

wouldn't the lost kernel be 4.8.15.16.23.42?

I'll get my coat....

lol :D

[the yawner]

Because even Torvalds stated in an article (I believe on PCWorld) that said he believed it was bloated and he even admitted that he liked Windows 7 better. Emphais:

[[citation needed]]



10 million lines of code, while Windows Vista had 50 million. This may not be bad - except for the fact that the Linux kernel doesn't even have a GUI built in while Windows has a GUI and a DE.
Bloat shouldn't be measured by a comparison with another OS.

[KiwiNZ]

There is no 2.7 at this point and there is no need fo a 2.7. From memory the latest is 2.6.34-rc1-git6.

[Kenny_Strawn]

Is your point that the Linux kernel needs more bloat?

http://ubuntuforums.org/showpost.php?p=8973751&postcount=31

[Kenny_Strawn]

There is no 2.7 at this point and there is no need fo a 2.7. From memory the latest is 2.6.34-rc1-git6.

There actually was a 2.7 that died, as per another post of mine.

[KiwiNZ]

There actually was a 2.7 that died, as per another post of mine.


errrr which means there is no 2.7

[Kenny_Strawn]

the problem is that the current kernel has become a huge testing ground for any new thing they want to put in.

Before, the "even" kernels were considered the stable ones. Not much changed, and not a lot of development went into the stable ones. The return on this was that you had a kernel that was, in fact, rock solid when it came to stability because you didn't have tons of scheduler rewrites, new filesystems and such going into a mainline kernel like you have with 2.6. Of course, many may argue that "the current kernel is stable", but i think the capability is there to cause a lot of problems with people who depend on mainline kernel to remain stable and patched with any security updates without having to worry about backporting any stability patches back to their current kernel version. This is what mostly happened with 2.4, with all of the "crazy" development going into 2.5 and tested extensively without any fear of the current kernel becoming unstable from any extensive changes, then releasing 2.6 when they felt it was sufficiently tested and stable.

I would like to see this development model again. Adding new features and such as you go along might be fine for some desktop app or something, but this is the linux kernel we're talking about here -- i don't want kernel devs messing around with it just because they think it needs changing for the heck of it. Put any new features you want in 2.7 and release 2.8 sooner rather than later. You can always stick with 2.6 since they continue patching old kernels (2.4 still gets updates!) until you're ready and confident in the next version, and desktop distros and bleeding edge people can go to the new one right away.

It's a much more sane development process to me than what i see as a reckless, chaotic kernel development process they've adopted with 2.6, and i really wish they would go back.

+100

[Chronon]

I see. And this Frankenstein's monster kernel would contain GUI/DE?

[Kenny_Strawn]

I see. And this Frankenstein's monster kernel would contain GUI/DE?

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++, whichI am getting (https://launchpad.net/librgba-c++) better at ('https://launchpad.net/gtk2-module-cube')

[KiwiNZ]

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++, whichI am getting (https://launchpad.net/librgba-c++) better at ('https://launchpad.net/gtk2-module-cube')

Why?

[DoktorSeven]

Linux development is still kind of like that, even if it doesn't look that way. Eg: "linux-next" tree where experimental features go, only when they are stable to they get to go to Linus's tree.

Actually, there are many hundreds of trees: http://git.kernel.org/

Yes, there are of course development versions of the kernel that all get merged into the next main "version", but that still doesn't really solve what I perceive as the main problem -- that we need a long-term, unchanging (relatively), stable kernel and a long, drawn out, extensively tested "testing" kernel like we had before.

This is, of course, all my opinion; I still respect the work done on the kernel and have been impressed with how relatively stable they've been able to keep the kernel with this process. I just don't think it's a particularly wise choice for the long term and it's one that could potentially create problems with those who just want a single kernel line that they can update without fear of significant change.

[Hwæt]

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++

Don't expect any help whatsoever from Linus. (http://lwn.net/Articles/249460/)

[KiwiNZ]

Again from Linus

From: Linus Torvalds [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)



>
> This is the "We've always used COBOL^H^H^H^H" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

Feel free to make up (d).

Linus

[Frak]

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++, whichI am getting (https://launchpad.net/librgba-c++) better at ('https://launchpad.net/gtk2-module-cube')
I am going to give you my opinion on these wonderful examples of your awesomeness by saying absolutely nothing at all.

[Kenny_Strawn]

Why?

GNOME 3, because it will probably be the latest GNOME release when the kernel is final, considering G3 will be released in September. Rewritten from the ground up, because the original C language does not support object-oriented programming, something key to writing good programs in less time, and with less code.

[aklo]

I've read before more than 50% of the people working on linux kernel are paid programmers?

[Frak]

I've read before more than 50% of the people working on linux kernel are paid programmers?
They work for corporations like Novell, Intel or RedHat who work on the kernel to benefit their companies.

[RiceMonster]

I've read before more than 50% of the people working on linux kernel are paid programmers?

it's even higher than that. over 500 companies have contributes to 2.6

[red_Marvin]

GNOME 3, because it will probably be the latest GNOME release when the kernel is final, considering G3 will be released in September. Rewritten from the ground up, because the original C language does not support object-oriented programming, something key to writing good programs in less time, and with less code.

No, why would you want to force a gui into the kernel of, of all things, linux, which has its modularity as a very big selling point.
Should all android phones and headless servers run Gnome 3? And if yes, why not KDE?

Also, C does support object oriented programming, it just does not provide syntactic sugar. OOP is a style, a mindset, a procedure, not something set in the syntax of the language. One could argue that there is some languages that would not support the style, but C with structs and pointers is not one of them.

[ukripper]

. wrong post deleted!

[Bachstelze]

Kenny reminds me of the MultiDeskOS guy. :D

(Semi-private joke, you'd have to be French-speaking and old-ish to get it... Too bad, it was really soemthing.)

EDIT: for those who understand some French, install fortunes-fr then try


fortune -m Jayce fr
fortune -m MultiDeskOS fr

etc.

[nvteighen]

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++, whichI am getting (https://launchpad.net/librgba-c++) better at ('https://launchpad.net/gtk2-module-cube')


GNOME 3, because it will probably be the latest GNOME release when the kernel is final, considering G3 will be released in September. Rewritten from the ground up, because the original C language does not support object-oriented programming, something key to writing good programs in less time, and with less code.

Kenny, please, stop making yourself ridiculous. Your code is not even C++ or, well, the two newer programs at least compile as shared libraries, but are completely useless...

What can I do with a structure like this?


// From gtk2-module-cube: libcube.cpp

struct cube
{
int Left;
int Top;
int Rear;

int Right;
int Bottom;
int Front;
};


There's no library functionality in there that actually makes this set of six integers condensed into the same packaged structures mean a cube. How is this cube drawn? How is this interfacing to GTK+ (besides linking to it)? I can assure you I could use your cube structure as whatever needing six integers...

The thing is that I wonder if you can read something as basic as this C code:


#include <malloc.h>
#include <stdio.h>

typedef struct LIST_T list_t;

extern list_t *list_new(void);
extern void list_free(list_t *);
extern char list_set(list_t *, size_t, int *);
extern size_t list_get_size(list_t *);
extern int list_get_elem(list_t *, size_t);
extern size_t list_search(list_t *, int);

struct LIST_T
{
/* The list structure. Typedef'd as (list_t) in list.h.
*
* (size_t) size: The amount of elements the list has.
*
* (int *) list: An array of integers where to store the data. */

size_t size;
int *list;
};

list_t *list_new(void)
{
/* A function to create a new list. It allocates the memory and initializes
* it, but it doesn't write any data to it.
*
* ARGS: (void)
*
* RET: A pointer to the newly created list. Beware that if malloc() yielded
* an error and returns NULL, this function will return NULL as well. So,
* the return value should always be checked bt the calling code. */

list_t *list_var = (list_t *)malloc(sizeof(list_t));

if(list_var != NULL)
{
list_var->size = 0;
list_var->list = NULL;
}

return list_var;
}

void list_free(list_t *list_var)
{
/* Deallocates a list. It first deallocates list_var->list and only then,
* the structure.
*
* ARGS:
* (list_t *) list_var: The list_t pointer to free.
*
* RET: (void). */

if(list_var->list != NULL)
{
free(list_var->list);
list_var->list = NULL; /* Not necessary. */
}

free(list_var);
}

char list_set(list_t *list_var, size_t size, int *list)
{
/* Sets the size and the list in base to the arguments passed. Actually just
* to enforce encapsulation.
*
* ARGS:
* (list_t *) list_var: The involved list_t pointer.
* (size_t *) size: The list's size.
* (int *) list: A pointer where the integer data has been stored in an
* array. The data is copied to make its allocation totally independent from
* the outside.
*
* RET: 1 if internal error ocurred (calloc returning NULL). 0 if everything
* went fine. */

list_var->size = size;

list_var->list = (int *)calloc(list_var->size, sizeof(int));
if(list_var->list == NULL)
return 1;

size_t i;
for(i = 0; i < list_var->size; i++)
list_var->list[i] = list[i];

return 0;
}

size_t list_get_size(list_t *list_var)
{
/* A function to tell the list's size from the outside. Another fancy
* encapsulation effort.
*
* ARGS:
* (list_t *) list_var: The list.
*
* RET: The list's size. */

return list_var->size;
}

int list_get_elem(list_t *list_var, size_t i)
{
/* This is to retrieve a certain element from the list, located at a known
* index i.
*
* ARGS:
* (list_t *) list_var: The list.
* (size_t) i: The index to access in the list.
*
* RET: The data in the requested slot. */

return list_var->list[i];
}

size_t list_search(list_t *list_var, int key)
{
/* This function searches a certain element matching the key and returns the
* index of its first appearance. This is only useful for lists with no
* duplicated data... Possibly a fix for later.
*
* ARGS:
* (list_t *) list_var: The list in which to search.
* (int) key: The number we're searching in our list.
*
* RET: The first matching data's index in list_var. If no match is found,
* it returns the list's size, which will always be out of the list's range
* (trying to gather something in that location will cause a segfault). */

size_t i;
for(i = 0; i < list_var->size; i++)
{
if(list_var->list[i] == key)
return i; /* Returning immediately to gain some efficiency. To
* continue looping knowing that the data has already be
* found is absolutely pointless. */
}

return list_var->size;
}


Moreover, as you see from my code, structures are C, not C++. Ok, C++ accepts them, but classes are the native C++ way. You keep talking about OOP and there's no evidence of you coding anything with that paradigm. I think you aren't able to read that code, which almost anyone learning programming has written at some point in his life; if you can't understand the flexible array data structure from above nor see that despite being C it's totally OOP, it's highly improbable that you don't understand what are the problems of Computer Science (i.e. the creation of models in formal-logical languages).

And because your code barely compiles you start telling us that you're getting better... Well, you couldn't do it worse, for instance. Programming certainly involves a bit of "magic", ok, but that "magic" comes from positive knowledge about algorithms, computer architecture, logic, etc. etc. etc. A bare C structure isn't going to magically become the last revolution in programming.

The worst is that you sometimes seem like trying to convince people that you're right and we're just a bunch of ignorants that e.g. don't know that OOP is important. Or that GNOME should be in the kernel... And people find you funny, but because there are several years-long experienced programmers here that know precisely what they are talking about... and sometimes a bit of nonsensical code makes some people their day.

Kenny, if you want to be a programmer, you have to be realistic. First, understand what you really know and what you don't know in order to know what to learn. In your case, you lack of all basic knowledge on the topic but are really enthusiastic on proclaiming amazing projects which, when you turn into some code, end up being a totally incoherent bunch of lines that hardly compile and never do anything.

I'm being quite hard at you because I want you to wake up. Otherwise you'll never be a programmer and nobody will ever talk to you seriously. Please, be honest with yourself.

I hope you get this message right. I have nothing personal at you; I just want you to open your eyes so you can really improve by yourself.

[thatguruguy]

Probably GNOME 3, if I had to choose. And it would definitely be rewritten - probably in C++, whichI am getting (https://launchpad.net/librgba-c++) better at (https://launchpad.net/gtk2-module-cube)

cf:


C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. source: http://lwn.net/Articles/249460/

Man, that Torvalds guy knows of what he speaks.