It's doubtful that Microsoft could encourage or coerce Negroponte to put XP on the machine, so whose arms will they twist?
Why is it doubtful? And why the loaded term coerce?
Let's come back to economic reality and suppose that Microsoft gets XP working on XO (nontrivial but not difficult) and offers a pretty good user experience—perhaps even "better" than the Linux experience (for some definition of "better" that you and I may not agree with, but someone will)? Now let's presuppose that Microsoft gives XP to OLPC for free.
Now the question is, how can Negroponte reasonably say no?
If it is free, and "better", what about the children?
The only thing missing: an estimate of when it will hit stores.
It is available now, at least in Boston. I was in a T-Mobile shop last weekend and surprised to hear them pitching the thing. They also sell routers that let you turn your home into a hot stop--in fact, this is how it was described to me; the sales rep did not mention that it would work in any T-Mobile Hot Spot.
Thus another reason to avoid Starbucks: Folks loudly clamoring to make their free cell phone calls.
I would like to hereby announce that I am porting my baby, NetworkManager, to SCO in order to reap the $100,000 offer. We will easily make "best wireless application."
Dude, you are getting your political and economics mixed up. Democracy != Capitalism. Many countries in Europe are, for example, Socialist Democracies. You are correct in saying that property rights form the fundamental basis for capitalism, but not for democracy.
Socialist Democracies value property rights, as does even communism. They just eschew property as an institution. Don't think I put any particular brand of property rights on the phrase "property rights."
Anyhow, I do agree that property rights form a much greater foundation to capitalism than democracy. I should of clarified, but I was impassioned to point out that free speech really isn't the basis of democracy whatsoever.
Could it be that Aspyr/id only made the Doom3 client for Mac with 64 bit code? Would that be the reason to require a "G5 or better"?
Doubtful since the current Mac OS X ABI does not support 64-bits. In other words, G5 systems are still running in 32-bits--both the apps and the OS. Tiger is supposed to provide full 64-bit support.
The only 64-bit support in the ABI right now is storing C99 "long long" types in a single GPR.
"I also pointed out that a pre-emptible kernel is a lot more responsive to a high priority thread," said Russinovich, moving on to his next target. "The Linux kernel 2.6 was made fully pre-emptible."
I can personally promise that the preemptability of Windows was not a factor in the desire to code a preemptive kernel or its eventual design.
As someone who just graduated with both a CS and a Mathematics degree, I would say any (good) CS program is going to require a few semesters of Calculus, a semester of Linear Algebra, some sort of Numerical Analysis class, and a Discrete Math course. Most of these would probably be of the computational/applied variety - e.g., not proof-based. Since I am a Math guy, I would add a second semester of Discrete Math, personally. Maybe one being proof-based and one more applied.
That said, personally I think CS majors should have a strong math background (the Calculus gives you that) but the only relevant Math, unless you are doing something specialized with a specific requirement, is what you learn in a Discrete Math course (what some programs actually call "Math for CS Majors" or similar).
My objection to "an answer to WinFS" is a bit different; I just think it's ill-conceived for a single developer to take on such a task as a side job. It takes years to develop a real filesystem. Maybe ReiserFS, with its new plug-in mechanism, should be the foundation? I don't know, I really don't see a great need for a radically different filesystem anyhow.
Two points.
First, I actually do not intend to work on WinFS, at least right now. In the interview, the items under "other things are important", those are items I feel are important but am not planning on working on right now.
Second, WinFS is not actually a different filesystem. It is a database built on top of NTFS (I think it can work on top of raw Yukon partitions, too). There are no filesystem changes. Or, at least, there need not be.
I was scheduled to give a talk on "The Kernel and the Desktop" at the Desktop Linux Summit and I formally withdrew on Thursday after having a discussion with the involved parties due to the issues discussed in these news articles. The behavior shown - especially the treatment of Bruce - is not acceptable.
I, uh, bet there will be more dropouts over the next couple days - Lindows is not cool.
Yes, right. The big Linux vendors are generally more conservative than Linus. What about changing the VM in the middle of the 2.4 (supposedly stable) kernel series? This is the exact opposite of what "stable" means. Linus admitted he did this so he could get it more thoroughly tested.
Well you picked the one big example over the thousand of counter-examples, but even the VM change was not a stability issue but a performance issue. And today you have every vendor shipping either the 2.4 stock VM (perhaps with Andrea's additional VM patches) or Rik's rmap VM. The kernels before 2.4.10 are considered horrid in page-out performance.
Look at vendor's back-porting 2.5 changes to 2.4 - this is not about stability, it is about improving scalability. We will never merge this stuff into 2.4, but vendors have customers they need to satisfy.
This should all be pretty clear since vendors start with a kernel.org kernel and then add features and patches galore. And this is fine, and what they should do - but do not go around saying its over stability.
In this interview with Robert Love in July, he predicted 18 months before 2.6 gets released(that would make the release early in 2004).
I'm more inclined to go with Robert Love's estimate considering 2.4's late release.
I think I may need to revise that (although I did go on to say a year from then, which would be summer of 2003)... the kernel is remarkably stable at this point and if we can stick to the freeze and get enough testers, I really believe we can have a code freeze in early 2003 and a release not too long thereafter. Five or six months from now seems very doable.
And I really encourage testers. We need you. Part of the VM debacle in 2.4 was we just did not understand the corner-cases because there were not enough testers testing on enough different machines on enough different workloads. We need to know where catatrophic VM failures are, where areas of high latency exist, and in general where the bad behavior is. This kernel is remarkably better in all aspects than 2.4... it is very smooth. But it needs testers to ease us into a stable release.
Why it needs to be larger than one page? The kernel will trap access to page faults due to stack overflow, and will allocate additional stack to it anyway.
It does not need to be bigger than one page, it just is. You are right, the stack is expanded via implicit mmap as it grows... but for performance reasons the default stack is usually measured in megabytes, not pages.
Anything but the simplest of applications would use a page rather quickly. User-space applications are programmed to assume they have any size stack they want. Local variables are huge.
In short, I was just commenting on the default. It can surely be lowered...
No, seriously. Process creation under Linux was time-similar to thread creation on other OSs. That's because Linux was as fast at creating *a process* as other OSs are at creating *a thread*. IIRC, threading was initially implemented in Linux from the process-creation methods, so it was similar in speed
It was and still is implemented by the process creation methods. Threads were (and still are) the same as processes in Linux (to the kernel, anyhow). All process creation is done by do_fork(), which accepts clone() flags that specify what to share between the parent and the child. "Threads" (as opposed to normal processes) just happen to share a few things: address space, signal handlers, open files, etc.
But yah, process creation in Linux is sick. Hold your head high.
Each Linux thread has two things of its own: its own stack, which can be as small as 1 or 2 pages if the code to run is simple enough, and also its own task_struct, which is 1 page including kernel stack for the thread.
This is not true; the kernel stack is two pages in size, i.e. 8KB on i386.
Also, in 2.5 (where these tests were done), the task_struct is no longer allocated on the stack. It is allocated off the slab cache, while the thread_info struct is on the stack. The task_struct slab object is another ~1.7KB per task.
Finally, I do not know what the pthreads default stack size is (user-space? what is that?) but it is certainly larger than one page.
I sent Linus a scheduler patch of some sort and - since I am working on 2.4 and 2.5 O(1) scheduler - I guess I pulled it from my 2.4 tree and it would not compile on 2.5.
Linus sent me the "tssk tssk" email you see and I told him to log the fix under a dematory ChangeLog entry (as you can see) - the result is the above...he has a good sense of humor.
I do not see anything wrong with this. What notion of reality is everyone subscribing to wherein a rebate is a bad thing?
This is not stealing customers, sorry. It is giving a rebate for an upgrade which, as someone else pointed out, is probably due to the savings in technical support by non-newbie customers.
Second, I own RedHat 7.2, now I own RedHat 7.3. I get $10 back. Thanks, RedHat. If they did not give a rebate you would complain it cost too much.
Next, someone complained about ripping up your manual - it is your old manual they want the cover of. Read the directions - "eligable product's manual" and the eligable product is from the list, i.e. old verions of RedHat or SuSE or Mandrake.
Now, RedHat is a business and you just bought a box with paper and CDs in it. Not a religion or a political agenda. Sorry to rain on anyone's parade. I got $10 bucks - yay! If you buy RedHat, you can get $10 bucks back, too. Or not. Have fun.
Finally, the real complaint is why does this version not have the free stickers of previous editions!@!?
Maybe this will encourage new Linux for Dreamcast work with the greater possibilities it presents for a small SH6 based web server?
The Dreamcast is SH4-based, not SH6. The SH5 chip is just about ready to be released.
The MS license says you can't ever change the license to GPL/LGPL - or, in other words, MS must always have the option to copy/buy/(steal?) the code back.
What I license the code as, though, has no bearing on what I can do as copyright holder. I can license code based on the implementation in the GPL or anything else, as well as sell rights to Microsoft under any other license.
First, I wanted to give my view of the results - what they mean and what that means. Note there are multiple notions of latency performance. Average latency and worst-case latency, among others, but those are most important. This test measured worst-case latency. Both are important - for user experience average case is very important and for real-time applications worst-case is very important.
It is not a surprise the low-latency patches scored better, or that the ideal scenario was using both. The preemptive kernel patch is not capable of fixing most of the worst-case latencies. This is because, since we can not preempt while holding a lock, any long durations where locks are held now become our worst-case latencies. We have a tool, preempt-stats, that helps us find these. With the preempt-kernel, however, average case latency is incredibly low. Often measured around 0.5-1.5 ms. Worst-case depends on your workload, and varies under both patches.
Now, the results don't mention average case (which is fine), but keep in mind with preempt-kernel it is much lower. The good thing about these results are that it does indeed show that certain areas have long-held locks and the preempt-kernel does nothing about them. Thus a combination of both gives an excellent average latency while tackling some of the long-held locks. Note it is actually best to use my lock-break patch in lieu of low-latency in combination of with preempt-kernel, as they are designed and optimal for each other (lock-break is based on Andrew's low-latency).
So what is the future? preempt-kernel is now in 2.5 and, as has been mentioned, Andrew and I are working on the worst-case latencies that still exist. Despite what has been mentioned here, however, we are not going to adopt a low-latency/lock-break explicit schedule and lock-breaking approach. We are going to rewrite algorithms, improve lock semantics, etc. to lower lock-held times. That is the ease and cleanliness of the preemptive kernel approach: no more hackery and such to lower latency in problem areas. Now we can cleanly fix them and voila: preemption takes over and gives us perfect response. I did some lseek cleanup in 2.5 (removed the BKL from generic_file_llseek and pushed the responsibility for locking into the other lseek methods) and this reduced latency during lseek operations -- a good example.
Slashdot Mirror
American working culture always looks very strange to me :)
And two months sounds inflexible and costly to me, contributing to an inelastic labor force and higher unemployment. :)
It's doubtful that Microsoft could encourage or coerce Negroponte to put XP on the machine, so whose arms will they twist?
Why is it doubtful? And why the loaded term coerce?
Let's come back to economic reality and suppose that Microsoft gets XP working on XO (nontrivial but not difficult) and offers a pretty good user experience—perhaps even "better" than the Linux experience (for some definition of "better" that you and I may not agree with, but someone will)? Now let's presuppose that Microsoft gives XP to OLPC for free.
Now the question is, how can Negroponte reasonably say no?
If it is free, and "better", what about the children?
It is available now, at least in Boston. I was in a T-Mobile shop last weekend and surprised to hear them pitching the thing. They also sell routers that let you turn your home into a hot stop--in fact, this is how it was described to me; the sales rep did not mention that it would work in any T-Mobile Hot Spot.
Thus another reason to avoid Starbucks: Folks loudly clamoring to make their free cell phone calls.The first 802.11n network?
I have one in my house.
The MSFT/NOVL agreement was not the motivation behind my departure.
I appreciate the postings by those who recognize that the speculation behind my departure is ill-founded and inappropriate.
I would like to hereby announce that I am porting my baby, NetworkManager, to SCO in order to reap the $100,000 offer. We will easily make "best wireless application."
Dude, you are getting your political and economics mixed up. Democracy != Capitalism. Many countries in Europe are, for example, Socialist Democracies. You are correct in saying that property rights form the fundamental basis for capitalism, but not for democracy.
Socialist Democracies value property rights, as does even communism. They just eschew property as an institution. Don't think I put any particular brand of property rights on the phrase "property rights."
Anyhow, I do agree that property rights form a much greater foundation to capitalism than democracy. I should of clarified, but I was impassioned to point out that free speech really isn't the basis of democracy whatsoever.
"Why should free speech trump the rights of an individual or a company to use a contract to keep information private?"
Because free speach is the very basis of democracy and the rule of law?
Actually, no. While we hold those rights very high in the United States, the basis of democracy and capitalism is property rights.
Could it be that Aspyr/id only made the Doom3 client for Mac with 64 bit code? Would that be the reason to require a "G5 or better"?
Doubtful since the current Mac OS X ABI does not support 64-bits. In other words, G5 systems are still running in 32-bits--both the apps and the OS. Tiger is supposed to provide full 64-bit support. The only 64-bit support in the ABI right now is storing C99 "long long" types in a single GPR.
"I also pointed out that a pre-emptible kernel is a lot more responsive to a high priority thread," said Russinovich, moving on to his next target. "The Linux kernel 2.6 was made fully pre-emptible."
I can personally promise that the preemptability of Windows was not a factor in the desire to code a preemptive kernel or its eventual design.
As someone who just graduated with both a CS and a Mathematics degree, I would say any (good) CS program is going to require a few semesters of Calculus, a semester of Linear Algebra, some sort of Numerical Analysis class, and a Discrete Math course. Most of these would probably be of the computational/applied variety - e.g., not proof-based. Since I am a Math guy, I would add a second semester of Discrete Math, personally. Maybe one being proof-based and one more applied.
That said, personally I think CS majors should have a strong math background (the Calculus gives you that) but the only relevant Math, unless you are doing something specialized with a specific requirement, is what you learn in a Discrete Math course (what some programs actually call "Math for CS Majors" or similar).
He probably just went to a hair stylist and made that... thing :-D
No, that is his real hair. He has always had long hair, he just dreaded it about a year ago.
My objection to "an answer to WinFS" is a bit different; I just think it's ill-conceived for a single developer to take on such a task as a side job. It takes years to develop a real filesystem. Maybe ReiserFS, with its new plug-in mechanism, should be the foundation? I don't know, I really don't see a great need for a radically different filesystem anyhow.
Two points.
First, I actually do not intend to work on WinFS, at least right now. In the interview, the items under "other things are important", those are items I feel are important but am not planning on working on right now.
Second, WinFS is not actually a different filesystem. It is a database built on top of NTFS (I think it can work on top of raw Yukon partitions, too). There are no filesystem changes. Or, at least, there need not be.
I was scheduled to give a talk on "The Kernel and the Desktop" at the Desktop Linux Summit and I formally withdrew on Thursday after having a discussion with the involved parties due to the issues discussed in these news articles. The behavior shown - especially the treatment of Bruce - is not acceptable.
I, uh, bet there will be more dropouts over the next couple days - Lindows is not cool.
Yes, right. The big Linux vendors are generally more conservative than Linus. What about changing the VM in the middle of the 2.4 (supposedly stable) kernel series? This is the exact opposite of what "stable" means. Linus admitted he did this so he could get it more thoroughly tested.
Well you picked the one big example over the thousand of counter-examples, but even the VM change was not a stability issue but a performance issue. And today you have every vendor shipping either the 2.4 stock VM (perhaps with Andrea's additional VM patches) or Rik's rmap VM. The kernels before 2.4.10 are considered horrid in page-out performance.
Look at vendor's back-porting 2.5 changes to 2.4 - this is not about stability, it is about improving scalability. We will never merge this stuff into 2.4, but vendors have customers they need to satisfy.
This should all be pretty clear since vendors start with a kernel.org kernel and then add features and patches galore. And this is fine, and what they should do - but do not go around saying its over stability.
I've always thought of Linus' tree as more of a kernel testing ground - even for the "stable" releases.
The vendors are more conservative than Linus? Hah. Yah. Right.
Like RedHat bumping up HZ to give a much smoother desktop experience.
In 2.5.
Redhat is also doing pioneering work on highly efficient kernel threads that will likely show up in their kernel before Linus'.
In 2.5 first.
RedHat's kernel tree resembles the -ac tree moreso than Linus' tree (gee, might that have to do with the fact that Alan Cox works for RedHat?)
What were you saying about conservative?
Linus' tree is not as relevant as it once was.
It is the most relevant thing there is.
In this interview with Robert Love in July, he predicted 18 months before 2.6 gets released(that would make the release early in 2004).
I'm more inclined to go with Robert Love's estimate considering 2.4's late release.
I think I may need to revise that (although I did go on to say a year from then, which would be summer of 2003)... the kernel is remarkably stable at this point and if we can stick to the freeze and get enough testers, I really believe we can have a code freeze in early 2003 and a release not too long thereafter. Five or six months from now seems very doable.
And I really encourage testers. We need you. Part of the VM debacle in 2.4 was we just did not understand the corner-cases because there were not enough testers testing on enough different machines on enough different workloads. We need to know where catatrophic VM failures are, where areas of high latency exist, and in general where the bad behavior is. This kernel is remarkably better in all aspects than 2.4... it is very smooth. But it needs testers to ease us into a stable release.
Why it needs to be larger than one page? The kernel will trap access to page faults due to stack overflow, and will allocate additional stack to it anyway.
It does not need to be bigger than one page, it just is. You are right, the stack is expanded via implicit mmap as it grows... but for performance reasons the default stack is usually measured in megabytes, not pages.
Anything but the simplest of applications would use a page rather quickly. User-space applications are programmed to assume they have any size stack they want. Local variables are huge.
In short, I was just commenting on the default. It can surely be lowered...
No, seriously. Process creation under Linux was time-similar to thread creation on other OSs. That's because Linux was as fast at creating *a process* as other OSs are at creating *a thread*. IIRC, threading was initially implemented in Linux from the process-creation methods, so it was similar in speed
It was and still is implemented by the process creation methods. Threads were (and still are) the same as processes in Linux (to the kernel, anyhow). All process creation is done by do_fork(), which accepts clone() flags that specify what to share between the parent and the child. "Threads" (as opposed to normal processes) just happen to share a few things: address space, signal handlers, open files, etc.
But yah, process creation in Linux is sick. Hold your head high.
Each Linux thread has two things of its own: its own stack, which can be as small as 1 or 2 pages if the code to run is simple enough, and also its own task_struct, which is 1 page including kernel stack for the thread.
This is not true; the kernel stack is two pages in size, i.e. 8KB on i386.
Also, in 2.5 (where these tests were done), the task_struct is no longer allocated on the stack. It is allocated off the slab cache, while the thread_info struct is on the stack. The task_struct slab object is another ~1.7KB per task.
Finally, I do not know what the pthreads default stack size is (user-space? what is that?) but it is certainly larger than one page.
[PATCH] Robert Love likes leather and chains
;-)
I thought I would fill in the story
I sent Linus a scheduler patch of some sort and - since I am working on 2.4 and 2.5 O(1) scheduler - I guess I pulled it from my 2.4 tree and it would not compile on 2.5.
Linus sent me the "tssk tssk" email you see and I told him to log the fix under a dematory ChangeLog entry (as you can see) - the result is the above...he has a good sense of humor.
I do not see anything wrong with this. What notion of reality is everyone subscribing to wherein a rebate is a bad thing?
This is not stealing customers, sorry. It is giving a rebate for an upgrade which, as someone else pointed out, is probably due to the savings in technical support by non-newbie customers.
Second, I own RedHat 7.2, now I own RedHat 7.3. I get $10 back. Thanks, RedHat. If they did not give a rebate you would complain it cost too much.
Next, someone complained about ripping up your manual - it is your old manual they want the cover of. Read the directions - "eligable product's manual" and the eligable product is from the list, i.e. old verions of RedHat or SuSE or Mandrake.
Now, RedHat is a business and you just bought a box with paper and CDs in it. Not a religion or a political agenda. Sorry to rain on anyone's parade. I got $10 bucks - yay! If you buy RedHat, you can get $10 bucks back, too. Or not. Have fun.
Finally, the real complaint is why does this version not have the free stickers of previous editions!@!?
There goes my karma...:)
Maybe this will encourage new Linux for Dreamcast work with the greater possibilities it presents for a small SH6 based web server?
The Dreamcast is SH4-based, not SH6. The SH5 chip is just about ready to be released.
The MS license says you can't ever change the license to GPL/LGPL - or, in other words, MS must always have the option to copy/buy/(steal?) the code back.
What I license the code as, though, has no bearing on what I can do as copyright holder. I can license code based on the implementation in the GPL or anything else, as well as sell rights to Microsoft under any other license.
First, I wanted to give my view of the results - what they mean and what that means. Note there are multiple notions of latency performance. Average latency and worst-case latency, among others, but those are most important. This test measured worst-case latency. Both are important - for user experience average case is very important and for real-time applications worst-case is very important.
... it is going to be fun.
It is not a surprise the low-latency patches scored better, or that the ideal scenario was using both. The preemptive kernel patch is not capable of fixing most of the worst-case latencies. This is because, since we can not preempt while holding a lock, any long durations where locks are held now become our worst-case latencies. We have a tool, preempt-stats, that helps us find these. With the preempt-kernel, however, average case latency is incredibly low. Often measured around 0.5-1.5 ms. Worst-case depends on your workload, and varies under both patches.
Now, the results don't mention average case (which is fine), but keep in mind with preempt-kernel it is much lower. The good thing about these results are that it does indeed show that certain areas have long-held locks and the preempt-kernel does nothing about them. Thus a combination of both gives an excellent average latency while tackling some of the long-held locks. Note it is actually best to use my lock-break patch in lieu of low-latency in combination of with preempt-kernel, as they are designed and optimal for each other (lock-break is based on Andrew's low-latency).
So what is the future? preempt-kernel is now in 2.5 and, as has been mentioned, Andrew and I are working on the worst-case latencies that still exist. Despite what has been mentioned here, however, we are not going to adopt a low-latency/lock-break explicit schedule and lock-breaking approach. We are going to rewrite algorithms, improve lock semantics, etc. to lower lock-held times. That is the ease and cleanliness of the preemptive kernel approach: no more hackery and such to lower latency in problem areas. Now we can cleanly fix them and voila: preemption takes over and gives us perfect response. I did some lseek cleanup in 2.5 (removed the BKL from generic_file_llseek and pushed the responsibility for locking into the other lseek methods) and this reduced latency during lseek operations -- a good example.
So that is the plan