It probably has Linux inside, seeing as it just has PowerPC processors. Linux would be the obvious platform for the "host" part of the system, running the web/telnet interface or whatever. The hard work is probably done by some non-Linux embedded code on separate processors.
My advice is to wait five or ten years and get one at a fire sale, then pull it apart.
Google have a hand-rolled filesystem and hardware, supporting several petabytes of data. (Exactly how many is anyones guess, but reckon on tens of thousands of servers × hundreds of gigabytes each.)
Kernel hackers... who don't mind being mentally polluted so that they can never work on either a open kernel or any commerical OS other than those owned by Sun.
I guess if you're really set on getting hired by Sun it might be worthwhile. Watch out for the mass layoffs in Dec 2005 though.:)
I might point out that Apache 2 is roughly four years late, and has been roundly criticized for introducing so much additional complexity in the threading model.
Trying to introduce threads has been an enormous disruption to the development model they had around 2000, and relatively few new features have gone in since then.
I'm not a big fan of 2.0 right now. It works as a stand-alone server, serving static pages, but the multi-threaded model [which runs] on UNIX is not quite there in many cases. Individual applications that don't rely on a whole slew of different third party libraries can be written to be very thread safe, very nice and very fast. But general-purpose stuff like PHP and PERL which tie into so many different libraries [are more of a concern because] we don't know if those libraries are safe or not. My concern with PHP and Apache 2.0 right now is that if we go Apache 2 with a threaded MPM at this point, there is a lot of stuff that will break. I don't think there is a compelling reason to switch to Apache 2.0 at this point, there is no killer feature. Apache 1.3 does the job. There are some killer features in the pipeline, when they get completed, and when they work, we will make all this stuff work under Apache 2.0, but right now it's a lot of work with very little benefit. It will take a couple of years still before Apache 2.0 and PHP will work well.
Maybe getting a Windows port was worth all that suffering, but for Apache Unix users threads have been a catastrophe.
So creating a thread that immediately exits is faster than creating a process that immediately exits. Woo-hoo.
A more interesting case is if they keep running together. In the thread, everything is shared: there must be a locks on the heap to synchronize access, so you pay a price on every malloc and free[*]. (It should not be necessary to point out that these are far more common than creating threads.) There are similar issues for per-process in-kernel structures such as the file table. Because more data is shared, there is more likely to be contention between threads from the same process on different CPUs.
Some of tridge's benchmarks show that on $vendor Unix, using threads can be twice as slow for a server-side tasks as using processes. On Linux, threads are only slightly slower.
Shared-everything is often a slower model, not faster.
[*] OK, it doesn't have to be a lock, but the heap does have to be thread-safe, which makes it slower or more complex or both.
All this shows is a realization that HP-UX and Tru64 is becoming irrelevant on the desktop, so there is no point spending time and money updating to a new desktop.
How many people do you know buying new HP-UX desktops? How many of those people actually use it as their "productivity" desktop, rather than having a Windows (or maybe Linux) machine on the side? People who would buy them have existing applications that run well under CDE, and their life would not be improved by switching to GNOME; they'd probably rather not switch. The remaining future for all the proprietary Unixes is in the machine room, not on the desktop.
GNOME on Linux desktops makes far more sense, and HP is doing at least some work there; for example in supporting the Debian/GNOME-based Ubuntu distribution and in the hp441 multi-user desktop. (Don't know if that runs GNOME or not.)
Of couse not, but it has a different spin to American outlets. By comparing the stories from the two, you can get a kind of triangulation on the "true" events.
Certainly reading Al-Jazeera is likely to get you a more different second perspective than watching two US commercial stations.
fork()||exec() was a great idea for its time, but recently the overhead of page table duplication has meant that supporting that model slows down or adds much complexity to operating systems.
Do you really have numbers for performance? I had thought that the relative performance of fork was going up over time, not down, because less and less data is copied. In particular for the case where the child execs without doing anything else then very little will be copied.
And this copying is relatively small compared to the work of starting a new process: loading the program and any libraries it needs, dynamic linking, program startup...
As far as complexity: well, it makes a (highly-tuned) kernel more complex than just having spawn(), but it makes the applications a lot simpler. Imagine how many parameters spawn() would need to have to support the flexibility of doing things in the child process before exec'ing.
Anyhow, it's not like you could remove much complexity of fork() -- assuming that you want multiprocessing or multithreading there is always going to be a need to copy an mm.
If wikipedia ever runs into a major cash crunch, it might be helpful to have a second source for those articles around.... an out-of-date, non-editable mirror, run by people apparently without any interest other than making a quick buck. OK, better than losing the material altogether, but not much better.
But seriously, creat(2) should have been deleted altogether, as it's redundant with open(2). I'd prefer to have rmdir(2) go away too, instead having unlink(2) suceed on empty directories.
No, contracts do not need to be signed on paper to be legally binding. (In general, there may be specific exceptions in local laws.)
If you accept an offer to rent a house, take the key, and move into the house, then you have accepted the conditions. Even if you didn't sign anything, you still need to pay rent or be sued and/or evicted. Contracts are written on paper for the sake of clarity, not because written contracts are necessary.
(Selling houses is actually one case where many local laws do require particular formalities, just because it is such a big transaction for most people.)
Interesting idea, but I don't think that could be the problem. I can imagine the ADC causing some blurring between consecutive pixels, but I don't see any way for it to cause blurring from one frame to the next. It would cause smudging rather than lag.
OK, so I'm not a monitor engineer. But could the connector really make a difference to refresh or rise-fall rates? Surely there can be little difference in the low band below 100Hz that could cause lag in a mouse pointer.
Tubgirl is truly a triumph of free speech. I defend their write to say it, even if I wish I could avoid it.
But I think many governments do feel compelled to ban it -- they just can't easily do it. If there were a single switch that said "stop porn on the internet", both the US and Australian governments (at least) would come under heavy pressure from wowsers to flip it.
Just as a point of information: last time I tried checking the kernel tree into Darcs, simple operations took a fraction of a minute to complete. Which is fairly slow, and probably much slower than Bitkeeper, but I think not ridiculously slow. Bearing in mind that just untarring a tree takes several seconds, it's not completely unreasonable. It's OK for a product that's pre-1.0, and a few years younger than BK.
Bitkeeper (last I looked) requires the user to explicitly mark files as "edited" -- obviously this makes diffs quicker, but it's a bit annoying and error prone. To my mind it's an overoptimization.
I like Arch and Subversion a lot. However, I have to say that probably neither of them is sufficiently well-proven at the moment for such a large environment.
They work pretty well, but they do have glitches from time to time (e.g. Subversion database recovery) and if there were hundreds of developers waiting on them the pain might be too high.
In the long term, Arch might handle merging far better than Perforce, and of course it avoids having everybody depend on a single server. So I'd suggest trying it out for a small project, with a view to maybe trying it commercially in a year or two.
The gcc bug is that it records the directory where cc1 was run, not the location of the source file, which is what we really want to know. See the distcc and gcc list archives for more details.
This can still bite you under Clearcase, though it's less likely. Consider, for example, having two identical files in different directories or in different projects.
Slashdot Mirror
It probably has Linux inside, seeing as it just has PowerPC processors. Linux would be the obvious platform for the "host" part of the system, running the web/telnet interface or whatever. The hard work is probably done by some non-Linux embedded code on separate processors.
My advice is to wait five or ten years and get one at a fire sale, then pull it apart.
Google have a hand-rolled filesystem and hardware, supporting several petabytes of data. (Exactly how many is anyones guess, but reckon on tens of thousands of servers × hundreds of gigabytes each.)
Apparently they're pretty happy with it.
Google.
Kernel hackers... who don't mind being mentally polluted so that they can never work on either a open kernel or any commerical OS other than those owned by Sun.
:)
I guess if you're really set on getting hired by Sun it might be worthwhile. Watch out for the mass layoffs in Dec 2005 though.
I agree.
The guy above saying that threads are faster to create because of page table copying is completely missing both the good and bad points of threads.
Trying to introduce threads has been an enormous disruption to the development model they had around 2000, and relatively few new features have gone in since then.
See for example this Interview with Rasmus Lerdorf last year:
Maybe getting a Windows port was worth all that suffering, but for Apache Unix users threads have been a catastrophe.
So creating a thread that immediately exits is faster than creating a process that immediately exits. Woo-hoo.
A more interesting case is if they keep running together. In the thread, everything is shared: there must be a locks on the heap to synchronize access, so you pay a price on every malloc and free[*]. (It should not be necessary to point out that these are far more common than creating threads.) There are similar issues for per-process in-kernel structures such as the file table. Because more data is shared, there is more likely to be contention between threads from the same process on different CPUs.
Some of tridge's benchmarks show that on $vendor Unix, using threads can be twice as slow for a server-side tasks as using processes. On Linux, threads are only slightly slower.
Shared-everything is often a slower model, not faster.
[*] OK, it doesn't have to be a lock, but the heap does have to be thread-safe, which makes it slower or more complex or both.
All this shows is a realization that HP-UX and Tru64 is becoming irrelevant on the desktop, so there is no point spending time and money updating to a new desktop.
How many people do you know buying new HP-UX desktops? How many of those people actually use it as their "productivity" desktop, rather than having a Windows (or maybe Linux) machine on the side? People who would buy them have existing applications that run well under CDE, and their life would not be improved by switching to GNOME; they'd probably rather not switch. The remaining future for all the proprietary Unixes is in the machine room, not on the desktop.
GNOME on Linux desktops makes far more sense, and HP is doing at least some work there; for example in supporting the Debian/GNOME-based Ubuntu distribution and in the hp441 multi-user desktop. (Don't know if that runs GNOME or not.)
1. Release WS-Pants.
2. ???
3. Profit!!!1!
Nobody's stopping you running DOS 5.0 and QuickBASIC/TurboC. I hear they run pretty damn fast on a 2GHz PC...
Of couse not, but it has a different spin to American outlets. By comparing the stories from the two, you can get a kind of triangulation on the "true" events.
Certainly reading Al-Jazeera is likely to get you a more different second perspective than watching two US commercial stations.
fork()||exec() was a great idea for its time, but recently the overhead of page table duplication has meant that supporting that model slows down or adds much complexity to operating systems.
Do you really have numbers for performance? I had thought that the relative performance of fork was going up over time, not down, because less and less data is copied. In particular for the case where the child execs without doing anything else then very little will be copied.
And this copying is relatively small compared to the work of starting a new process: loading the program and any libraries it needs, dynamic linking, program startup...
As far as complexity: well, it makes a (highly-tuned) kernel more complex than just having spawn(), but it makes the applications a lot simpler. Imagine how many parameters spawn() would need to have to support the flexibility of doing things in the child process before exec'ing.
Anyhow, it's not like you could remove much complexity of fork() -- assuming that you want multiprocessing or multithreading there is always going to be a need to copy an mm.
If wikipedia ever runs into a major cash crunch, it might be helpful to have a second source for those articles around. ... an out-of-date, non-editable mirror, run by people apparently without any interest other than making a quick buck. OK, better than losing the material altogether, but not much better.
Not everything that is legal is ethical.
Ha ha.
But seriously, creat(2) should have been deleted altogether, as it's redundant with open(2). I'd prefer to have rmdir(2) go away too, instead having unlink(2) suceed on empty directories.
Of course it's too late now.
That ought have to be
Content-type: audio/x-stolen
Of course by now the idea of stolen music is no longer experimental, so the IETF ought to remove the x- prefix altogether.
Even better, for the DE locale you can use this mime type for a delicious Xmas treat!
No, contracts do not need to be signed on paper to be legally binding. (In general, there may be specific exceptions in local laws.)
If you accept an offer to rent a house, take the key, and move into the house, then you have accepted the conditions. Even if you didn't sign anything, you still need to pay rent or be sued and/or evicted. Contracts are written on paper for the sake of clarity, not because written contracts are necessary.
(Selling houses is actually one case where many local laws do require particular formalities, just because it is such a big transaction for most people.)
Debian and Ubuntu ship binary kernels for various different chips...
Interesting idea, but I don't think that could be the problem. I can imagine the ADC causing some blurring between consecutive pixels, but I don't see any way for it to cause blurring from one frame to the next. It would cause smudging rather than lag.
I have to say I particularly using the parameters as a terse way to get two locals. I have to remember to use that in production code tomorrow. :)
OK, so I'm not a monitor engineer. But could the connector really make a difference to refresh or rise-fall rates? Surely there can be little difference in the low band below 100Hz that could cause lag in a mouse pointer.
Tubgirl is truly a triumph of free speech. I defend their write to say it, even if I wish I could avoid it.
But I think many governments do feel compelled to ban it -- they just can't easily do it. If there were a single switch that said "stop porn on the internet", both the US and Australian governments (at least) would come under heavy pressure from wowsers to flip it.
Thankfully, with the Internet, I have access to information I never dreamt existed a decade ago.
Tubgirl?
Just as a point of information: last time I tried checking the kernel tree into Darcs, simple operations took a fraction of a minute to complete. Which is fairly slow, and probably much slower than Bitkeeper, but I think not ridiculously slow. Bearing in mind that just untarring a tree takes several seconds, it's not completely unreasonable. It's OK for a product that's pre-1.0, and a few years younger than BK.
Bitkeeper (last I looked) requires the user to explicitly mark files as "edited" -- obviously this makes diffs quicker, but it's a bit annoying and error prone. To my mind it's an overoptimization.
I like Arch and Subversion a lot. However, I have to say that probably neither of them is sufficiently well-proven at the moment for such a large environment.
They work pretty well, but they do have glitches from time to time (e.g. Subversion database recovery) and if there were hundreds of developers waiting on them the pain might be too high.
In the long term, Arch might handle merging far better than Perforce, and of course it avoids having everybody depend on a single server. So I'd suggest trying it out for a small project, with a view to maybe trying it commercially in a year or two.
The gcc bug is that it records the directory where cc1 was run, not the location of the source file, which is what we really want to know. See the distcc and gcc list archives for more details.
This can still bite you under Clearcase, though it's less likely. Consider, for example, having two identical files in different directories or in different projects.