You wouldn't be able to point to it without hideous hacks like the Pentium's 36 bit addressing mode . . .
But yeah, the size of a pointer is the limiting factor there. Though in the case of 64 bit architectures, they typically only use ~40-50 bits of the actual address space (Alpha uses 48 bits, first gen Hammer will use 40 or 48 (I think)), which is still plenty by almost anyone's standards.
Yeah, that's also a plausible reading of it all . . .
Not knowing the man myself I've been going on what other people have said about him, and what I've read of his comments on lkml. He comes across as a rather arrogant but very intelligent man, who might not be perfectly internally consistent but certainly isn't maliciously so. The people who know him personally seem to think fairly highly of him, and he certainly knows what he's talking about. He's also managed to produce a rather good piece of software in bk . . .
I tend to take people at their word unless I've got good reason not to, and so far I haven't seen a good reason not to take Larry at his word. Maybe I'm wrong, but without knowing him personally it's damned hard to say.
And all told, Linus using bk/has/ helped quite a lot, regardless of all the crap people have thrown around about it. So even if Larry's motives aren't as pure as the driven snow, they've led to at least some good things.
If MS approached Linus and offered him $1 billion US to stop developing the Linux kernel, do you think he'd take it?
Yeah, you'll probably say he would - I'd put money on you being wrong.
Larry has already turned down large sums of money in order to develop BitKeeper. I'd put money on him turning down MS, too, unless that was the only way he could possibly make payroll for the next few years, and even then I'd be surprised.
Some people actually/do/ stick by their ethics, even in this cynical world we live in today.
And now you can track every single patch Linus applies, in real time. Before Linus started using bk, you had to wait for him to drop a patch onto ftp.kernel.org, now you can simply cd linux-2.5 && bk pull.
In any case, the general consensus from that thread was that linus/does/ actually merge things faster than he used to, Alan's comments notwithstanding.
Larry's claim is that there isn't a business model that will allow the source to be GPLed and still fund the development from scratch of a BitKeeper type system. The development costs including all the research required, as well - bk breaks new ground in a number of areas, and he doesn't think such work can be funded by any of the GPL-based business models.
Cloning bk, though, would be fairly simple - all the research has been done, and it's just the final functionality that needs to be duplicated. That's what he's afraid of, and with quite good reason. The resulting clone would kill BitMover stone dead, even if it lacked the polish and the full set of features bk supports - free trumps for-cost almost inevitably.
I'd really suggest you think about what you're posting, and perhaps do a little bit of research before you actually hit "submit" - you're comments here are rather offensive to someone who knows what Larry's done, and has an inkling of/why/ he did it.
The thing is, the people who use bk for free/aren't/ his target customers - after all, they're not buying bk. What's more, he explicitly recommends that small groups start out using cvs, until they grow to the point where cvs' limitations get too painful; only at that point would he try and sell you bk.
The people Larry is calling whiners are the people who complain about the BKL, about BitKeeper, or about the decisions Larry made in order to develop BitKeeper. As far as I can tell from reading his comments, he's rather sick of having people complain vociferously without having any understanding of/why/ he did things the way he did. Oh, and all the people who talk about writing something better for free, but never actually get anywhere with it . . . Frankly, that seems perfectly understandable to me - I know I'd probably have lost my temper far more than Larry has over the years.
Linus has/never/ used any source control system, least of all CVS (which he appears to have a very low opinion of). BitKeeper was originally created to provide a source control system that would be able to handle Linux kernel development - Larry McVoy looked at the way the kernel was developed and figured that Linus would end up burnt out and collapse, and decided that the best way he could help prevent that was to develop a source control system that would ease Linus' load. Thus BitKeeper was born . . .
Please, do a little bit of research before posting thoughts on this kind of thing - posting without knowing what you're talking about tends to make you look rather ignorant.
Larry has already received offers, and turned them down. He's already turned down jobs with several other companies that would have made him many millions, so that he could work on BitKeeper. There's quite a good chance there's no real risk of BitMover being bought out, at least not in the near future. Probably the only thing that might prompt that would be if Larry couldn't make payroll for a long time - whether that's a real risk is a difficult question without knowing more about BitMover's finances.
Larry/is/ a good guy, if rather irritating at times (and the word from people who know him personally is that he's very nice in person, though this quite often doesn't come accross). He's doing this as a way to contribute something back to the community he's gained lots from, and though the way he's doing it is controvertial, his motives seem to be pure.
Is such a license acceptable for Linux kernel development? Not at all. Despite the fact that there are Bitkeeper-to-CVS and Bitkeeper-to-Subversion and Bitkeeper-to-tgz-Gateways all over the place now, Non-BK users are second class citizens in Linux kernel development. They do not have realtime access, and they do not have proper access to BK metadata at all. Also, patch submissions that do not come in via BK are treated worse than patches that come in via BK - Linus and friends may say they aren't, or they aren't intentionally, but they are - again matters of convenience and infrastructure working against Non-BK users.
I'm sorry, but this is just plain wrong - Linus will accept patches with as much alacrity as he'll accept URLs for a repository to pull from. As evidence of this, consider the number of patches he's merged from Andrew Morton and Al Viro, neither of whom use BitKeeper. Hell, Linus basically demanded excellent support for importing patches into a repository from Larry McVoy, and got it without the slightest argument.
All told, Linus using BitKeeper has noticeably sped up and smoothed out the development process - he's now merging more patches (particularly trivial patches that often got lost in the noise before), and thanks to his use of BitKeeper you can literally watch every single commit he makes, so you get a far better view of what he's doing. The development process has been helped by this, not suffered, and that's the consensus of all the core people (including ones like akpm who doesn't use bk for philosophical reasons).
Go and actually/read/ lkml for a few months, and then come back and tell us all that things are terrible and the development process is collapsing.
The day Larry changes the format to be incompatible with SCCS is the day the kernel developers stop using BitKeeper. Larry knows this, and he's not likely to shoot himself repeatedly in the foot by doing that.
You might ask yourself why BitKeeper is still using the SCCS file format. The answer is for exactly this reason: they don't want to lock their users in by using a proprietary format.
What might be a real risk is if Larry loses control of BitMover and the new owners decided to make such changes. As it stands, that's not even a mid-term threat, and with any luck the Free alternatives would have caught up enough to be usable if it/did/ happen.
If you want lots of general purpose registers, take a look at Knuth's MMIX system. Unfortunately, it's not in silicon, but it's there, and it/could/ be done, if someone wanted to . ..
Yes, that's a performance issue, but it's not a/latency/ issue - the new process is running, and from there on in the latencies are only a few hundred cycles rather than measurable in microseconds. Until the next time the process enters the kernel, or page faults, or whatever. As far as latency goes, context switching is of minimal importance unless you're worried by latencies on the order of less than a microsecond (depending on hardware and the like, of course).
The argument that threads trash cache less than full processes seems fairly bogus to me - the cache trashing will be much more dependant on the size of the working sets of all the running processes, and there's nothing to say that a thread will have a smaller working set than a process. The text segment will be shared, yes, but it's the same with multiple instances of/any/ process, because the program text will be mmapped read only, allowing the memory to be shared, and thus kept in cache. The TLB flush needed would be an added cost, but unless the cache really is being trashed completely by your program it'll be reloaded straight from cache, and that shouldn't be more than a few hundred cycles (I think - don't quote me on that).
In any case, the real performance comparison isn't between multiple processes versus multiple threads, it's between a multithreaded implementation and a single-threaded one. In/that/ comparison threads come last, simply because they/have/ those kinds of cache interactions and so forth, where a single-threaded version won't. They also have overhead due to locking, greater debugging difficulties, and other added complexities. On the other hand, though, you can't make use of more than one processor without having multiple processes, whether they're threads or full processes . . .
I think the biggest thing making threads attractive to people is the fact that a threaded approach will often make things simpler to think about in the design stage. You can make all the independant threads of control in your design/real/ threads of control in the implementation. That comes at a cost, though . . .
Personally, I like the quote from Alan Cox that I've seen in a few people's.sig: "Threads are for people who can't program state machines". It's more complex than that, but it does seem to capture a lot of what motivates threaded designs.
The latency issues that cause mp3 skipping under heavy load in Linux have nothing at all to do with context switching, and everything to do with/scheduling/ latency: how long it takes for a process that has work to do to actually get control of the cpu. Context switching has/nothing/ to do with that.
The low latency patches go through the kernel breaking up areas where spinlocks are held for long periods of time. That's what causes massive scheduling latency in the kernel.
Context switching under Linux/is/ extremely fast - it's actually been measured (a lot), and it's something the kernel developers pay a lot of attention to and optimise very carefully. They literally count cpu cycles in these code paths. Context switching time is a serious performance limiter in many areas, so getting it right is important, and it's something that Linux does/very/ well.
Go do some real research before you accuse someone who's right of karma whoring bullshit.
If you want to do stupid things with your programs, that's fine by the kernel developers. Just don't expect/them/ to bend over backwards to make/your/ stupid design work as well as you want it to. That's your problem, and no one elses.
Alternatively, you might want to consider that Linux's scheduler was very nicely tuned for far and away the most common case - where you have only a small number of running processes.
Likewise, threading support under Linux has been oriented towards what the developers considered sane: a fairly small number of threads. They had good reasons for considering that the right way to do it - for a start, it worked nicely for what they wanted, and it was sufficiently simple that they didn't have to put in lots of complex code. Further, it's almost never a good idea to have a program architecture that requires very large numbers of threads - it generally only shows up in naive code where people simply don't understand the problems it brings. So, as far as the kernel developers were concerned, stupid people hurting themselves wasn't something to put any effort into amelioriating. This has changed recently, as people have started using Linux in areas where this kind of thing/isn't/ insane, and hence these new developments have come along.
You need to understand the reasoning behind a lot of these decisions before you can start complaining about them. First and foremost, you simply/have/ to realise that the kernel developers care about how people actually use the system, rather than crappy benchmarketing numbers. These developments have come about because people needed them, and they didn't happen earlier because no one had needed them before. Go back and read the last few years of the lkml archives, and/then/ come back and talk about this kind of thing, when you understand/why/.
If these boxes are running RH 7.3, they'll likely be using DRI by default, and there's a longish standing bug with that and VT switching (there are fixes available if you follow the DRI development tree, but I doubt they're in the RH packages yet).
Why on earth these lab boxes are running DRI, though, is a different matter - it's known to be very much a beta system, and likely to cause this kind of thing. Don't Do That Then(tm), Mr. Admin.
. . . would there have been the tech explosion in Silicon Valley?
After all, think of the number of startups that formed when someone had a cool idea, left their employer, and started out on their own . . . Companies like Intel, for example.
Personally, I find this kind of thing utterly insane, and really quite disgusting - my thoughts are/mine/, not my employer's. It's up to me to decide whether I want to sell them (which is what I'm doing when I accept a salary for working on ideas); anything else amounts to indentured servitude.
When did it become necessary for evidence to be absolute before you accept that it accurately reflects reality? If that was a real necessity, science would be impossible, since science/never/ discovers absolute evidence of anything, merely evidence within the bounds of experimental or observational error.
Just because/you/ live by a leap of faith doesn't mean that everyone does.
Well, C was (and still is) designed with very low level stuff in mind - operating system kernel implementation, and similar stuff. I'd much rather do/that/ in C than use some 'saner' language which allowed for better optimisation and safer code, because for an OS kernel you/need/ to be able to do insane things, and the assumption has to be that you know what it's going to do.
C should be used as a portable assembly language, for the most part, not as an application development language. There are dozens of better languages for the high level stuff, ranging from Python to OCaml - some of them even perform in the same ballpark as C/C++. But there really isn't another language I'd want to write an OS kernel in, despite it's flaws.
mbox format isn't a standard, it's just a roughly compatible format that's simple and works well enough. That's it's attraction - simplicity.
That's also the big difference between MS file formats and Unix file formats: plain text versus binary, simple versus insanely complex. The fact that things tend to be standardised on the Unix side helps, but it's not entirely necessary.
X actually provides a mechanism for the apps to negotiate what information they give/get in a cut and paste operation, which allows them to cut and paste anything, as long as both sides understand what it is.
The problem is that most apps don't use it, or they only ever the X clipboard for text. Theoreticaly, X can handle things just as well as Windows or MacOS, but too few developers use it.
You'd probably want to ask Jeremy Allison or Andrew Tridgell that -/they're/ the ones who've said that. Somehow, I doubt they're stupid enough to not know what was going on, particularly after spending ten years working on the problem.
I'm sorry, but that's bullshit. The Linux kernel was not started until 1991 - it wasn't even self-hosting until september 1991. The GNU project was started in 1984, but most of the desktop software people use is much much younger than that - gnome and KDE both started around '96.
NT was first released around the time that early versions of Linux were released, but it had been in development much longer, and by a much much larger team.
Slashdot Mirror
Most Samba development is done outside the US, and I believe all the actual reverse engineering work is too, for exactly this reason.
himi
You wouldn't be able to point to it without hideous hacks like the Pentium's 36 bit addressing mode . . .
But yeah, the size of a pointer is the limiting factor there. Though in the case of 64 bit architectures, they typically only use ~40-50 bits of the actual address space (Alpha uses 48 bits, first gen Hammer will use 40 or 48 (I think)), which is still plenty by almost anyone's standards.
himi
Yeah, that's also a plausible reading of it all . . .
/has/ helped quite a lot, regardless of all the crap people have thrown around about it. So even if Larry's motives aren't as pure as the driven snow, they've led to at least some good things.
Not knowing the man myself I've been going on what other people have said about him, and what I've read of his comments on lkml. He comes across as a rather arrogant but very intelligent man, who might not be perfectly internally consistent but certainly isn't maliciously so. The people who know him personally seem to think fairly highly of him, and he certainly knows what he's talking about. He's also managed to produce a rather good piece of software in bk . . .
I tend to take people at their word unless I've got good reason not to, and so far I haven't seen a good reason not to take Larry at his word. Maybe I'm wrong, but without knowing him personally it's damned hard to say.
And all told, Linus using bk
himi
If MS approached Linus and offered him $1 billion US to stop developing the Linux kernel, do you think he'd take it?
/do/ stick by their ethics, even in this cynical world we live in today.
Yeah, you'll probably say he would - I'd put money on you being wrong.
Larry has already turned down large sums of money in order to develop BitKeeper. I'd put money on him turning down MS, too, unless that was the only way he could possibly make payroll for the next few years, and even then I'd be surprised.
Some people actually
himi
And now you can track every single patch Linus applies, in real time. Before Linus started using bk, you had to wait for him to drop a patch onto ftp.kernel.org, now you can simply cd linux-2.5 && bk pull.
/does/ actually merge things faster than he used to, Alan's comments notwithstanding.
In any case, the general consensus from that thread was that linus
himi
Larry's claim is that there isn't a business model that will allow the source to be GPLed and still fund the development from scratch of a BitKeeper type system. The development costs including all the research required, as well - bk breaks new ground in a number of areas, and he doesn't think such work can be funded by any of the GPL-based business models.
/why/ he did it.
Cloning bk, though, would be fairly simple - all the research has been done, and it's just the final functionality that needs to be duplicated. That's what he's afraid of, and with quite good reason. The resulting clone would kill BitMover stone dead, even if it lacked the polish and the full set of features bk supports - free trumps for-cost almost inevitably.
I'd really suggest you think about what you're posting, and perhaps do a little bit of research before you actually hit "submit" - you're comments here are rather offensive to someone who knows what Larry's done, and has an inkling of
himi
The thing is, the people who use bk for free /aren't/ his target customers - after all, they're not buying bk. What's more, he explicitly recommends that small groups start out using cvs, until they grow to the point where cvs' limitations get too painful; only at that point would he try and sell you bk.
/why/ he did things the way he did. Oh, and all the people who talk about writing something better for free, but never actually get anywhere with it . . . Frankly, that seems perfectly understandable to me - I know I'd probably have lost my temper far more than Larry has over the years.
The people Larry is calling whiners are the people who complain about the BKL, about BitKeeper, or about the decisions Larry made in order to develop BitKeeper. As far as I can tell from reading his comments, he's rather sick of having people complain vociferously without having any understanding of
himi
Linus has /never/ used any source control system, least of all CVS (which he appears to have a very low opinion of). BitKeeper was originally created to provide a source control system that would be able to handle Linux kernel development - Larry McVoy looked at the way the kernel was developed and figured that Linus would end up burnt out and collapse, and decided that the best way he could help prevent that was to develop a source control system that would ease Linus' load. Thus BitKeeper was born . . .
Please, do a little bit of research before posting thoughts on this kind of thing - posting without knowing what you're talking about tends to make you look rather ignorant.
himi
Larry has already received offers, and turned them down. He's already turned down jobs with several other companies that would have made him many millions, so that he could work on BitKeeper. There's quite a good chance there's no real risk of BitMover being bought out, at least not in the near future. Probably the only thing that might prompt that would be if Larry couldn't make payroll for a long time - whether that's a real risk is a difficult question without knowing more about BitMover's finances.
/is/ a good guy, if rather irritating at times (and the word from people who know him personally is that he's very nice in person, though this quite often doesn't come accross). He's doing this as a way to contribute something back to the community he's gained lots from, and though the way he's doing it is controvertial, his motives seem to be pure.
Larry
himi
I'm sorry, but this is just plain wrong - Linus will accept patches with as much alacrity as he'll accept URLs for a repository to pull from. As evidence of this, consider the number of patches he's merged from Andrew Morton and Al Viro, neither of whom use BitKeeper. Hell, Linus basically demanded excellent support for importing patches into a repository from Larry McVoy, and got it without the slightest argument.
All told, Linus using BitKeeper has noticeably sped up and smoothed out the development process - he's now merging more patches (particularly trivial patches that often got lost in the noise before), and thanks to his use of BitKeeper you can literally watch every single commit he makes, so you get a far better view of what he's doing. The development process has been helped by this, not suffered, and that's the consensus of all the core people (including ones like akpm who doesn't use bk for philosophical reasons).
Go and actually
himi
The day Larry changes the format to be incompatible with SCCS is the day the kernel developers stop using BitKeeper. Larry knows this, and he's not likely to shoot himself repeatedly in the foot by doing that.
/did/ happen.
You might ask yourself why BitKeeper is still using the SCCS file format. The answer is for exactly this reason: they don't want to lock their users in by using a proprietary format.
What might be a real risk is if Larry loses control of BitMover and the new owners decided to make such changes. As it stands, that's not even a mid-term threat, and with any luck the Free alternatives would have caught up enough to be usable if it
himi
If you want lots of general purpose registers, take a look at Knuth's MMIX system. Unfortunately, it's not in silicon, but it's there, and it /could/ be done, if someone wanted to . . .
himi
Yes, that's a performance issue, but it's not a /latency/ issue - the new process is running, and from there on in the latencies are only a few hundred cycles rather than measurable in microseconds. Until the next time the process enters the kernel, or page faults, or whatever. As far as latency goes, context switching is of minimal importance unless you're worried by latencies on the order of less than a microsecond (depending on hardware and the like, of course).
/any/ process, because the program text will be mmapped read only, allowing the memory to be shared, and thus kept in cache. The TLB flush needed would be an added cost, but unless the cache really is being trashed completely by your program it'll be reloaded straight from cache, and that shouldn't be more than a few hundred cycles (I think - don't quote me on that).
/that/ comparison threads come last, simply because they /have/ those kinds of cache interactions and so forth, where a single-threaded version won't. They also have overhead due to locking, greater debugging difficulties, and other added complexities. On the other hand, though, you can't make use of more than one processor without having multiple processes, whether they're threads or full processes . . .
/real/ threads of control in the implementation. That comes at a cost, though . . .
.sig: "Threads are for people who can't program state machines". It's more complex than that, but it does seem to capture a lot of what motivates threaded designs.
The argument that threads trash cache less than full processes seems fairly bogus to me - the cache trashing will be much more dependant on the size of the working sets of all the running processes, and there's nothing to say that a thread will have a smaller working set than a process. The text segment will be shared, yes, but it's the same with multiple instances of
In any case, the real performance comparison isn't between multiple processes versus multiple threads, it's between a multithreaded implementation and a single-threaded one. In
I think the biggest thing making threads attractive to people is the fact that a threaded approach will often make things simpler to think about in the design stage. You can make all the independant threads of control in your design
Personally, I like the quote from Alan Cox that I've seen in a few people's
himi
The latency issues that cause mp3 skipping under heavy load in Linux have nothing at all to do with context switching, and everything to do with /scheduling/ latency: how long it takes for a process that has work to do to actually get control of the cpu. Context switching has /nothing/ to do with that.
/is/ extremely fast - it's actually been measured (a lot), and it's something the kernel developers pay a lot of attention to and optimise very carefully. They literally count cpu cycles in these code paths. Context switching time is a serious performance limiter in many areas, so getting it right is important, and it's something that Linux does /very/ well.
The low latency patches go through the kernel breaking up areas where spinlocks are held for long periods of time. That's what causes massive scheduling latency in the kernel.
Context switching under Linux
Go do some real research before you accuse someone who's right of karma whoring bullshit.
himi
If you want to do stupid things with your programs, that's fine by the kernel developers. Just don't expect /them/ to bend over backwards to make /your/ stupid design work as well as you want it to. That's your problem, and no one elses.
himi
Alternatively, you might want to consider that Linux's scheduler was very nicely tuned for far and away the most common case - where you have only a small number of running processes.
/isn't/ insane, and hence these new developments have come along.
/have/ to realise that the kernel developers care about how people actually use the system, rather than crappy benchmarketing numbers. These developments have come about because people needed them, and they didn't happen earlier because no one had needed them before. Go back and read the last few years of the lkml archives, and /then/ come back and talk about this kind of thing, when you understand /why/.
Likewise, threading support under Linux has been oriented towards what the developers considered sane: a fairly small number of threads. They had good reasons for considering that the right way to do it - for a start, it worked nicely for what they wanted, and it was sufficiently simple that they didn't have to put in lots of complex code. Further, it's almost never a good idea to have a program architecture that requires very large numbers of threads - it generally only shows up in naive code where people simply don't understand the problems it brings. So, as far as the kernel developers were concerned, stupid people hurting themselves wasn't something to put any effort into amelioriating. This has changed recently, as people have started using Linux in areas where this kind of thing
You need to understand the reasoning behind a lot of these decisions before you can start complaining about them. First and foremost, you simply
himi
If these boxes are running RH 7.3, they'll likely be using DRI by default, and there's a longish standing bug with that and VT switching (there are fixes available if you follow the DRI development tree, but I doubt they're in the RH packages yet).
Why on earth these lab boxes are running DRI, though, is a different matter - it's known to be very much a beta system, and likely to cause this kind of thing. Don't Do That Then(tm), Mr. Admin.
himi
. . . would there have been the tech explosion in Silicon Valley?
/mine/, not my employer's. It's up to me to decide whether I want to sell them (which is what I'm doing when I accept a salary for working on ideas); anything else amounts to indentured servitude.
After all, think of the number of startups that formed when someone had a cool idea, left their employer, and started out on their own . . . Companies like Intel, for example.
Personally, I find this kind of thing utterly insane, and really quite disgusting - my thoughts are
himi
When did it become necessary for evidence to be absolute before you accept that it accurately reflects reality? If that was a real necessity, science would be impossible, since science /never/ discovers absolute evidence of anything, merely evidence within the bounds of experimental or observational error.
/you/ live by a leap of faith doesn't mean that everyone does.
Just because
himi
Well, C was (and still is) designed with very low level stuff in mind - operating system kernel implementation, and similar stuff. I'd much rather do /that/ in C than use some 'saner' language which allowed for better optimisation and safer code, because for an OS kernel you /need/ to be able to do insane things, and the assumption has to be that you know what it's going to do.
C should be used as a portable assembly language, for the most part, not as an application development language. There are dozens of better languages for the high level stuff, ranging from Python to OCaml - some of them even perform in the same ballpark as C/C++. But there really isn't another language I'd want to write an OS kernel in, despite it's flaws.
himi
And "IANALY" means I Am Not A Lawyer Yet.
himi
mbox format isn't a standard, it's just a roughly compatible format that's simple and works well enough. That's it's attraction - simplicity.
That's also the big difference between MS file formats and Unix file formats: plain text versus binary, simple versus insanely complex. The fact that things tend to be standardised on the Unix side helps, but it's not entirely necessary.
himi
X actually provides a mechanism for the apps to negotiate what information they give/get in a cut and paste operation, which allows them to cut and paste anything, as long as both sides understand what it is.
The problem is that most apps don't use it, or they only ever the X clipboard for text. Theoreticaly, X can handle things just as well as Windows or MacOS, but too few developers use it.
himi
You'd probably want to ask Jeremy Allison or Andrew Tridgell that - /they're/ the ones who've said that. Somehow, I doubt they're stupid enough to not know what was going on, particularly after spending ten years working on the problem.
himi
I'm sorry, but that's bullshit. The Linux kernel was not started until 1991 - it wasn't even self-hosting until september 1991. The GNU project was started in 1984, but most of the desktop software people use is much much younger than that - gnome and KDE both started around '96.
NT was first released around the time that early versions of Linux were released, but it had been in development much longer, and by a much much larger team.
himi