Why? I don't see that. To switch threads in user space you push all the registers onto the stack, save the stack pointer, load the stack pointer of the next thread and pop its registers from the stack. It's just a few cycles, maybe 20 or so. If your thread is using floating point you've got more work to do - you have to save the FP context if another task was using it and load the FP context of the new thread. This isn't expensive because it doesn't happen often. (You do need to do some fancy dancing to detect automatically which threads are using FP and which aren't) You don't have to enter the kernel anywhere in this process, and that's a huge win. To make the user space task switches happen you sprinkle calls to a yield() function throughout the code, and at I/O points. This just doesn't eat much CPU time, compared to the enormous, odious cost of crossing into the kernel, killing the cache at a cost of several hundred cycles. And again when you cross back out. For Java, this approach is ideal because the VM has complete control of the code that gets executed - at load time it can insert the required yields as it sees fit.
Unless I misunderstood your post, you've saved some kernel time and made a solution that is completely unscalable. The reason for kernel threads is to allow scaling on multiple processors. In a user space implementation, your single process with multi threads gets scheduled to run it's course. Only, instead on each thread getting n-ticks, each threads may get n/threads ticks. This assumes that each thread can execute in n/threads duration. Furthermore, it only executes on a single CPU, which means the process will only be scheduled once on a CPU and will never run concurrently.
The kernel thread implementation, from what I've read, is pretty good. Not to mention, it's implementation was thought out with much debate. This isn't the first time I've heard about the scheduler needing attention. Currently, I don't see that the scheduler is going to fix very much when there are still device drivers and parts of the kernel that require fine grained locks. Targets like this are obvious and the reason why Microsoft loves to benchmark Linux with multiple NICs. Plain and simple, fix what's broken and then see what else needs to be optimized (e.g. scheduler).
I would also like to time a moment to point out that Linux's context switch time is, in most cases, 20-30% less than most real time OS's, and in some cases 1/2 to 1/3. Having said that, I don't really have a problem with threading. I don't really remember the exact times (I've slept since then), but Linux's context swithes were tipically two to three times faster than NT's (this was 3.51 days if I recall). NT actually does scale well for what it is. To repeat, let's fix what's broken and increase the level of concurrency (this is why NT has some advantages) in the kernel. Then, worry about scheduling.
Correct me if I'm wrong, but I believe that there is what is commonly referred to as the spirit of the law. It's sole purpose is to create or capture a slightly vague idea or notion on paper. My understanding is that the spirit of the GPL is well understood. As such, parties that use products that are bound by the GPL would have a hard time trying to find a technical loophole since the ideology is pretty well understand/documented and expressed in the GPL license. I think it does a pretty good job of explaining its intent. As such, I believe that any action taken to circumvent the GPL would be viewed for what it was.
Just how legal is it to sell hardware which is known not to be fully functional?
I don't think they have anything to worry about. The hardware they are selling is doing what it was advertise to do. As long as it is able to do it reliably, I don't think it can qualify as defective. Unlike the recent defective floppy drive case, I don't see this as being the same.
"The MPAA is striking a blow today in defense of the future of American movies. We have filed suit in federal court to stop internet hackers from distributing the software designed to circumvent the encryption technology that prevents the unlawful copying of DVDs."
I assume then that they plan to provide: 1) A extra copy of every DVD that I purchase so as to allow me my right to make legitimate copies. 2) The right to mail or phone in and request a completely free copy in the event that I lose, misplace, or otherwise destroy any of the copies obtained via step 1. Thus, extending the protection that I legally have to make a copy for my self.
If they do not intend to provide the above services, are they not blocking my legal right to make a copy for my self? Isn't this illegal? Wouldn't that be the same thing as a car dealer selling me a car and then taking me to court to prevent me from making copies of my keys?
They know all the Laws about technology and such very well.
That's fine. I completely agree with that statement. However, it's a BIG difference between knowing the laws on technology and knowing technology. If I understand things correctly, experts come in to "teach" the technology during their deposition, etc. This means the courts understanding of technology is only as good as has been explained to them. Ack, even more basic, it's only as good as the ability of the people to understand the explanation of the technology in question. Furthermore, I recently learned that you can be a complete idiot and qualify as an expert on a topic. Furthermore, once you've been accepted as an expert in the eyes of the law, you may become the defacto expertise on the subject for further cases, merely because you are now an "expert."
I currently see no evidence that the current situation is anything other than mediocre at best. I have known, worked for, and worked with several layers. To date, I've met none that I would trust to make a competent technology decision. That's not to say that the right decision won't be reached, but rather I have no faith that it will.
Not to take away from your comments, but I think the majority of the people are referring to the junk that nuts have been spewing about planes falling from the sky, power turning off at the first coo-coo of the clock, and pintos blowing up when looked at wrong (well, okay, the first two are exaggerated).
A better way of looking at it is like this. You go to your dentist whom tells you that you need a root canal. You mention this to a buddy at work. The next thing you know, everyone is getting your next of kin information because surely you're going to die from this terrible ordeal. It doesn't change the fact that they're all idiots, but it still needs to be done and isn't going to be fun. IMOHO, this pretty closely mirrors the idiots that feared Y2K while pointing and screaming revelations.
Personally, the only concern I had of Y2K was the people factor. It's like someone yelling "fire" and having dozens of people killed in the stampede when in reality, there wasn't a fire; just some kid yelling, "wolf." I was hoping this would not be the case in the market. It doesn't look like it was.
DVDRip should be a much greater concern to the MPAA than DeCSS. I think that they are just upset that their "trade secrets" were so easily rendered useless.
I think it's more likely that they are concerned that there would be players available that they have no control over. I assume that money is generated for ever licensed player. With the availability of a freely available player, a source of revenue would suddenly disappear. In short, this seems more of an issue of protection of revenue hidden behind a farce of "trade secret."
Most recently, with the Mustang, it's advertised at about 310 HP, but people who have bought them, and hooked them up to Dynos (after losing drag races), found out that most 99 Mustangs are putting out somewhere in the 270-285 HP range.
I know this is off topic, but many people are starting to use pressurized dyno rooms to get a denser air volume. This, in many cases, is where the difference really is. Keep in mind, the engine really did produce that much HP, just not on the street!
It should be well understood that writes do and always will have a higher overhead than reads. This can not be stressed enough. Writes must have parity information calculated and written. This has a higher cpu load (local or off board) and results in more physical data being written to disk. If you can not measure a difference, it is possible that you are not saturating your disk and/or controller. Likewise, it's also important to stress the importance of RAID controller selection. The actual delta between reads and writes can vary greatly depending on the vendor and implementation details. Also, something that people seem to forget is that if you choose a RAID solution that has onboard cache, make sure it has onboard battery too (diagnostics of onboard battery state is highly recommended). It is also highly recommended to have a UPS too. Without these, verifing the state of the write cache can be questioned in the event of an untimely shutdown. Of course, let's not forget that while multi-channel controllers are good, having multiple mutli-channel controllers are even better from a performance and reliability perspective.
I have use Mylex controllers with 32MB and battery. We found that they worked very well. I would like to point out that there are other good solutions too. Be sure to do you vendor and product homework!
It's important to remember that the OS only allows applications to scale. There is nothing magic in a given OS that scales applications well on it's own. In other words, applications have to be written to scale well on SMP systems.
An example of this to help illustrate. I was at a customer that has a HP9000/8-CPU with 2G RAM. It was running Oracle. Their programmers wrote an application that performed well enough on a small scale, but when it came time to run in production, they killed it after running three days non-stop. I rewrote it to better take advantage of the multiple CPUs. It now finishes in 8-12 (10-average) hours.
What's my point? Well, it's well known that stability and configurability is what Apache is known for. Performance has never been a major priority. This was pointed out after their first release of crap. I always wondered why they didn't use Squid+Apache. Squid is thread based and I would think would scale well. If I recall, there were several other options to try too. Of course, this doesn't address the multi-NIC and known SMP problems (TCP stack).
While I truly believe Linux is Good Stuff(tm), I also believe that a large part of it's growth is because MS has been forced to behave more than they would normally since they've been under the never-blinking- eye. In short, competition is starting to happen because MS has been forced to play more fair than they normally would. Without the government, I think we'd be seeing a different picture.
Here's one picture for you. Name Linux as threat knowing that it will grow somewhat on it's own. Start a mud slinging contest and sponsor benchmarks here and there showing how Linux is competing and that they are actively engaging Linux. Then, say, "LOOK! We have competition." I expect, they never expected Linux to take off like it has or to be received as well as it has in F500 and overseas.
1) The company does need to be broken up! The logical lines would seemingly be, OS, applications, services, games, and commerce. Whereby, the GUI and IE would fall under applications, while IIS would fall under commerce. You get the idea. 2) All API's must be published. Any sharing of API information between the newly created entities must be publicly published. 3) All file formats must be publicly published (Excel to Access). 3) IE must be removed from the OS and distributed independently of any MS (or partner) product. 4) IE (or equevilent product) must be sold at a premium price of $40-60 per license for the the next two years. There after, they should be prohibited from saling it for anything less than the lowest priced commercial offering for the following two years. At that point, they should be on a competitive field. 5) They should be prohibited from acquiring any new entities for the next four years. 6) Prohibit software donation of any type to government or education facilities. 7) Prohibit the pre-announcement of any product prior to 30-days of it's release. This should include all alpha, beta, and public betas. In the event that the release is missed, impose fines of $1M per day that the product is late, perhaps doubling every 30-days. Perhaps, a sliding scale can be applied to prevent the fine from being looked at as a simple cost of doing business.
The main effect of journalling, the thing that is really important about it, is that it guarantees that metadata updates are kept consistent. That is, journalling is primarily supportive of making sure that filenames, directory structures, permissions, and such are kept consistent even when moderately catastrophic things happen.
This is true, however, (J)RFS does do journaling of datablocks (non-meta) when files grow. I just finished reading this on their web site. There is some criteria that has to be hit prior to this occuring, but nontheless, there are cases that cause datablocks to be journaled as well.
It is not obselete. If it were not for this case, I believe that Linux would of had a lot more friction getting were it is today. Now that the market is starting to change, is no reason to believe that Microsoft isn't waiting to go back to their ways.
I've been thinking of reasonable actions that can and should be done as an outcome to this trail. One of the obvious things that need to be done is the breakup of Microsoft. Microsoft OS needs to be made clearly distinct from Microsoft Applications (whereas, this is where the GUI/web interface resides). Furthermore, they need to prohibit Microsoft from pre-announcing ANY product (OS or application) prior to 30-days of it's availability for the next 5-15 years. This should include betas, public betas, and any other form of public testing that Microsoft may use to circumvent this. In the event that the product is not release on said schedule, they should be hit with heavy fines. I would think that millions per day of delay should fit Microsoft's budget. This type of restriction had a profound impact on IBM in it's day and has proven to work well. I see no reason why this shouldn't be imposed against Microsoft as well.
Something that I always though was strange is that Americans fully endorse the use of violence. We go out of our way to reflect this in movies, commercials, stories, writings, and art. We've been told to embrace something that isn't healthy. In fact, it's plain out destructive. On the other-side, we've been told that sex is bad, evil, and if you enjoy it, you're a pervert or a sexual deviant.
Does anyone else think it strange that something that is natural, healthy, and required for our procreation is wrong (sex) and something that shouldn't be actively practiced (violence) is socially acceptable in almost all forms.
A good example of this is, two kids in school start to fight. Which do you think happens:
A) The majority of the kids rush to stop the fight? B) The majority of the kids make room and begin cheer to smash a nose or eye. Hint: If you picked A, you're not living on the same planet as the rest of us.
It's not that it comes naturally for most of us, it's because it's expected of us by our peers and society at large.
I see what you are trying to get at but the point is that you *rarely* have the bandwidth yourself. Once you have maxed out your connection that's it. You can't go any faster by saving CPU cycles. Servers still have much more CPU power than bandwidth. The original poster's argument still holds true. Another point I want to make is that things like DB speed can also have a big impact on DB centric CGIs. This reduces any gain from coding in a lower level language too.
You seemed to of ignored the primary focus of this thread and then reiterated my own point with a more specific example. I clearly stated that it was based on the assumption that bandwidth is available. I was specifically thinking of situations whereby, real work was being done via a web interface versus simply generating dynamic pages to paste the current date and time on it. In the event that the work being done is non-trivial, suddenly the CPU:bandwidth ratio changes significantly. In short, it really doesn't matter if the work unit is DB centric or analyzing geographic data from memory mapped files. The point is, this is an area that tends to be ignored/forgotten, or simply overlooked in exchange for ease of implementation. This fact, usually ignores the best tool for the job.
The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance. Using a faster language isn't going to help that, so typically web-folk go for the easiest solution.
I've had people tell me this before. This assumption can be an illusion. While it's true that you are limited on a per connection basis in many cases, it's also true that the number of requests that can be processed at a given instant in time is also a bottleneck at that instant. So, if you expect to be processing large volumes of hits in a finite window, it's important to have an optimal solution. This point seems to be frequently ignored or forgotten. What does this mean? Well, assuming you have the bandwidth, let's say an optimal implementation can support 50r/s versus 30r/s (these are numbers pulled from my back pocket). Assuming these numbers, that means that you are able to respond to 60% more requests in a timely manner. This directly reflects quality of service. For some web sites, it's critical to keeping their customers happy. Another way of looking at it is that you can grow in volume 60% more before you have to upgrade hardware which can be realized as a cost savings. It's important to remember that this counter does not address the ease of implementation. Which, for some, is thee deciding factor.
I've seen it done on a regular basis (as so far as the dealings I've been involved with). NDA serve to protect. It is standard business practice. Any good laywer will tell you that. Those not wishing to sign NDA should be pushed away and kept at arms length. They generally are the ones that can lead to problems. There is nothing that prevents them from signing an NDA; other than perhaps ethics (er...lack of them). Not signing an NDA does not prevent them from being liable or sued. In short, NOT signing one provides NO added protection for them. All it does it confirm that the product was disclosed, when, and why. If anything, if offers shelter for both parties. Again, if you have people not wanting to sign an NDA, this should immediately be cause for concern.
Can we please not post kernel releases unless the change log is also attached? Without this, I fear that we are pushing the "you must upgrade" mentality that MS users are used to. This way, we may also help cut down on the number of downloads that are done and free up some bandwidth for those people that may actually need the fix.
I have participated in a number of IDG surveys before I refused to answer any more. IDG is the most biased suvey that I can imagine. At that point in time, I was already extreemly weary of ZD stuff, but still hoped that other groups would do the right thing. Their suveys would not allow for anything out of the box (OS/2, Linux, lesser brand UNIX, e.g. Consensys). When they report their findings, they make bold statements like, "NT clearly is building up steam. Other OS's are not even a blip on the screen." Well, of course they are not, you never even checked for them.
Having said that, I must admit that I too play the survey game with people. No matter how irritating it is, people seem to beleave something that in print even if the should know better. So, when I find something that supports common sense of experience, I point at it. This is very annoying.
I know people that consider me to be extreemly Linux biased. I explain to people this is because I've used both (Microsoft products even longer) and have nightmares getting the same results with more downtown from NT. I honestly don't have a problem with NT in a departmental role. On the other hand, I'm happy to supply bullets for people that want to use it for an enterprise solution.
Why is this relevent? Well, questions like, "Does NT crash more of less often than Win95?" Then, they report, "NT is preceived as extreemely relable my IT departments and managers."
As you can tell, I have a very low opinion of the big survey companies (IDG, Gartner, etc). As one person pointed out their studies are paid for by someone. The end result is that the results are not tarnished, rather, the questions and stated results are. Enough said.
"Standards... well then tell me the standard way to install a package that works across all Linux distributions?"
What is the standard way to install across UNIX? What about NT. You're dreaming if you think there is a standard in any way, shape, or form on any OS. I know that Win is typically "setup", but notice the word, "typically". In other words, even in the "standard" winWorld(tm), there's no such thing.
Can you tell me the standard way to uninstall an application across WinWorlds? No, you can't, because there isn't a standard way. Some applications support this, some don't. Furthermore, some uninstalls don't even do it correctly.
Slashdot Mirror
Why? I don't see that. To switch threads in user space you push all the registers onto the stack, save the stack pointer, load the stack pointer of the next thread and pop its registers from the stack. It's just a few cycles, maybe 20 or so. If your thread is using floating point you've got more work to do - you have to save the FP context if another task was using it and load the FP context of the new thread. This isn't expensive because it doesn't happen often. (You do need to do some fancy dancing to detect automatically which threads are using FP and which aren't) You don't have to enter the kernel anywhere in this process, and that's a huge win. To make the user space task switches happen you sprinkle calls to a yield() function throughout the code, and at I/O points. This just doesn't eat much CPU time, compared to the enormous, odious cost of crossing into the kernel, killing the cache at a cost of several hundred cycles. And again when you cross back out. For Java, this approach is ideal because the VM has complete control of the code that gets executed - at load time it can insert the required yields as it sees fit.
Unless I misunderstood your post, you've saved some kernel time and made a solution that is completely unscalable. The reason for kernel threads is to allow scaling on multiple processors. In a user space implementation, your single process with multi threads gets scheduled to run it's course. Only, instead on each thread getting n-ticks, each threads may get n/threads ticks. This assumes that each thread can execute in n/threads duration. Furthermore, it only executes on a single CPU, which means the process will only be scheduled once on a CPU and will never run concurrently.
The kernel thread implementation, from what I've read, is pretty good. Not to mention, it's implementation was thought out with much debate. This isn't the first time I've heard about the scheduler needing attention. Currently, I don't see that the scheduler is going to fix very much when there are still device drivers and parts of the kernel that require fine grained locks. Targets like this are obvious and the reason why Microsoft loves to benchmark Linux with multiple NICs. Plain and simple, fix what's broken and then see what else needs to be optimized (e.g. scheduler).
I would also like to time a moment to point out that Linux's context switch time is, in most cases, 20-30% less than most real time OS's, and in some cases 1/2 to 1/3. Having said that, I don't really have a problem with threading. I don't really remember the exact times (I've slept since then), but Linux's context swithes were tipically two to three times faster than NT's (this was 3.51 days if I recall). NT actually does scale well for what it is. To repeat, let's fix what's broken and increase the level of concurrency (this is why NT has some advantages) in the kernel. Then, worry about scheduling.
Correct me if I'm wrong, but I believe that there is what is commonly referred to as the spirit of the law. It's sole purpose is to create or capture a slightly vague idea or notion on paper. My understanding is that the spirit of the GPL is well understood. As such, parties that use products that are bound by the GPL would have a hard time trying to find a technical loophole since the ideology is pretty well understand/documented and expressed in the GPL license. I think it does a pretty good job of explaining its intent. As such, I believe that any action taken to circumvent the GPL would be viewed for what it was.
According to this C|NET article, they were advertising the software on their website as DVD cracking software...
So, if I advertise car theft equipment, which are in fact my car keys, am I breaking the law?
Just how legal is it to sell hardware which is known not to be fully functional?
I don't think they have anything to worry about. The hardware they are selling is doing what it was advertise to do. As long as it is able to do it reliably, I don't think it can qualify as defective. Unlike the recent defective floppy drive case, I don't see this as being the same.
"The MPAA is striking a blow today in defense of the future of American movies. We have filed suit in federal court to stop internet hackers from distributing the software designed to circumvent the encryption technology that prevents the unlawful copying of DVDs."
I assume then that they plan to provide: 1) A extra copy of every DVD that I purchase so as to allow me my right to make legitimate copies.
2) The right to mail or phone in and request a completely free copy in the event that I lose, misplace, or otherwise destroy any of the copies obtained via step 1. Thus, extending the protection that I legally have to make a copy for my self.
If they do not intend to provide the above services, are they not blocking my legal right to make a copy for my self? Isn't this illegal? Wouldn't that be the same thing as a car dealer selling me a car and then taking me to court to prevent me from making copies of my keys?
I assume you mean USB????
NOT IN OREGON Judges do not have to go to law school. I could become a judge if enough people voted for me (and I have NO law experience).
It's the same in Texas too.
They know all the Laws about technology and such very well.
That's fine. I completely agree with that statement. However, it's a BIG difference between knowing the laws on technology and knowing technology. If I understand things correctly, experts come in to "teach" the technology during their deposition, etc. This means the courts understanding of technology is only as good as has been explained to them. Ack, even more basic, it's only as good as the ability of the people to understand the explanation of the technology in question. Furthermore, I recently learned that you can be a complete idiot and qualify as an expert on a topic. Furthermore, once you've been accepted as an expert in the eyes of the law, you may become the defacto expertise on the subject for further cases, merely because you are now an "expert."
I currently see no evidence that the current situation is anything other than mediocre at best. I have known, worked for, and worked with several layers. To date, I've met none that I would trust to make a competent technology decision. That's not to say that the right decision won't be reached, but rather I have no faith that it will.
Not to take away from your comments, but I think the majority of the people are referring to the junk that nuts have been spewing about planes falling from the sky, power turning off at the first coo-coo of the clock, and pintos blowing up when looked at wrong (well, okay, the first two are exaggerated).
A better way of looking at it is like this. You go to your dentist whom tells you that you need a root canal. You mention this to a buddy at work. The next thing you know, everyone is getting your next of kin information because surely you're going to die from this terrible ordeal. It doesn't change the fact that they're all idiots, but it still needs to be done and isn't going to be fun. IMOHO, this pretty closely mirrors the idiots that feared Y2K while pointing and screaming revelations.
Personally, the only concern I had of Y2K was the people factor. It's like someone yelling "fire" and having dozens of people killed in the stampede when in reality, there wasn't a fire; just some kid yelling, "wolf." I was hoping this would not be the case in the market. It doesn't look like it was.
Enjoy! Happy New Year!
DVDRip should be a much greater concern to the MPAA than DeCSS. I think that they are just upset that their "trade secrets" were so easily rendered useless.
I think it's more likely that they are concerned that there would be players available that they have no control over. I assume that money is generated for ever licensed player. With the availability of a freely available player, a source of revenue would suddenly disappear. In short, this seems more of an issue of protection of revenue hidden behind a farce of "trade secret."
Most recently, with the Mustang, it's advertised at about 310 HP, but people who have bought them, and hooked them up to Dynos (after losing drag races), found out that most 99 Mustangs are putting out somewhere in the 270-285 HP range.
I know this is off topic, but many people are starting to use pressurized dyno rooms to get a denser air volume. This, in many cases, is where the difference really is. Keep in mind, the engine really did produce that much HP, just not on the street!
It should be well understood that writes do and always will have a higher overhead than reads. This can not be stressed enough. Writes must have parity information calculated and written. This has a higher cpu load (local or off board) and results in more physical data being written to disk. If you can not measure a difference, it is possible that you are not saturating your disk and/or controller. Likewise, it's also important to stress the importance of RAID controller selection. The actual delta between reads and writes can vary greatly depending on the vendor and implementation details. Also, something that people seem to forget is that if you choose a RAID solution that has onboard cache, make sure it has onboard battery too (diagnostics of onboard battery state is highly recommended). It is also highly recommended to have a UPS too. Without these, verifing the state of the write cache can be questioned in the event of an untimely shutdown. Of course, let's not forget that while multi-channel controllers are good, having multiple mutli-channel controllers are even better from a performance and reliability perspective.
I have use Mylex controllers with 32MB and battery. We found that they worked very well. I would like to point out that there are other good solutions too. Be sure to do you vendor and product homework!
It's important to remember that the OS only allows applications to scale. There is nothing magic in a given OS that scales applications well on it's own. In other words, applications have to be written to scale well on SMP systems.
An example of this to help illustrate. I was at a customer that has a HP9000/8-CPU with 2G RAM. It was running Oracle. Their programmers wrote an application that performed well enough on a small scale, but when it came time to run in production, they killed it after running three days non-stop. I rewrote it to better take advantage of the multiple CPUs. It now finishes in 8-12 (10-average) hours.
What's my point? Well, it's well known that stability and configurability is what Apache is known for. Performance has never been a major priority. This was pointed out after their first release of crap. I always wondered why they didn't use Squid+Apache. Squid is thread based and I would think would scale well. If I recall, there were several other options to try too. Of course, this doesn't address the multi-NIC and known SMP problems (TCP stack).
While I truly believe Linux is Good Stuff(tm), I also believe that a large part of it's growth is because MS has been forced to behave more than they would normally since they've been under the never-blinking- eye. In short, competition is starting to happen because MS has been forced to play more fair than they normally would. Without the government, I think we'd be seeing a different picture.
Here's one picture for you. Name Linux as threat knowing that it will grow somewhat on it's own. Start a mud slinging contest and sponsor benchmarks here and there showing how Linux is competing and that they are actively engaging Linux. Then, say, "LOOK! We have competition." I expect, they never expected Linux to take off like it has or to be received as well as it has in F500 and overseas.
1) The company does need to be broken up! The logical lines would seemingly be, OS, applications, services, games, and commerce. Whereby, the GUI and IE would fall under applications, while IIS would fall under commerce. You get the idea.
2) All API's must be published. Any sharing of API information between the newly created entities must be publicly published.
3) All file formats must be publicly published (Excel to Access).
3) IE must be removed from the OS and distributed independently of any MS (or partner) product.
4) IE (or equevilent product) must be sold at a premium price of $40-60 per license for the the next two years. There after, they should be prohibited from saling it for anything less than the lowest priced commercial offering for the following two years. At that point, they should be on a competitive field.
5) They should be prohibited from acquiring any new entities for the next four years.
6) Prohibit software donation of any type to government or education facilities.
7) Prohibit the pre-announcement of any product prior to 30-days of it's release. This should include all alpha, beta, and public betas. In the event that the release is missed, impose fines of $1M per day that the product is late, perhaps doubling every 30-days. Perhaps, a sliding scale can be applied to prevent the fine from being looked at as a simple cost of doing business.
The main effect of journalling, the thing that is really important about it, is that it guarantees that metadata updates are kept consistent. That is, journalling is primarily supportive of making sure that filenames, directory structures, permissions, and such are kept consistent even when moderately catastrophic things happen.
This is true, however, (J)RFS does do journaling of datablocks (non-meta) when files grow. I just finished reading this on their web site. There is some criteria that has to be hit prior to this occuring, but nontheless, there are cases that cause datablocks to be journaled as well.
It is not obselete. If it were not for this case, I believe that Linux would of had a lot more friction getting were it is today. Now that the market is starting to change, is no reason to believe that Microsoft isn't waiting to go back to their ways.
I've been thinking of reasonable actions that can and should be done as an outcome to this trail. One of the obvious things that need to be done is the breakup of Microsoft. Microsoft OS needs to be made clearly distinct from Microsoft Applications (whereas, this is where the GUI/web interface resides). Furthermore, they need to prohibit Microsoft from pre-announcing ANY product (OS or application) prior to 30-days of it's availability for the next 5-15 years. This should include betas, public betas, and any other form of public testing that Microsoft may use to circumvent this. In the event that the product is not release on said schedule, they should be hit with heavy fines. I would think that millions per day of delay should fit Microsoft's budget. This type of restriction had a profound impact on IBM in it's day and has proven to work well. I see no reason why this shouldn't be imposed against Microsoft as well.
Something that I always though was strange is that Americans fully endorse the use of violence. We go out of our way to reflect this in movies, commercials, stories, writings, and art. We've been told to embrace something that isn't healthy. In fact, it's plain out destructive. On the other-side, we've been told that sex is bad, evil, and if you enjoy it, you're a pervert or a sexual deviant.
Does anyone else think it strange that something that is natural, healthy, and required for our procreation is wrong (sex) and something that shouldn't be actively practiced (violence) is socially acceptable in almost all forms.
A good example of this is, two kids in school start to fight. Which do you think happens:
A) The majority of the kids rush to stop the fight?
B) The majority of the kids make room and begin cheer to smash a nose or eye.
Hint: If you picked A, you're not living on the same planet as the rest of us.
It's not that it comes naturally for most of us, it's because it's expected of us by our peers and society at large.
I see what you are trying to get at but the point is that you *rarely* have the bandwidth yourself. Once you have maxed out your connection that's it. You can't go any faster by saving CPU cycles. Servers still have much more CPU power than bandwidth. The original poster's argument still holds true.
Another point I want to make is that things like DB speed can also have a big impact on DB centric CGIs. This reduces any gain from coding in a lower level language too.
You seemed to of ignored the primary focus of this thread and then reiterated my own point with a more specific example. I clearly stated that it was based on the assumption that bandwidth is available. I was specifically thinking of situations whereby, real work was being done via a web interface versus simply generating dynamic pages to paste the current date and time on it. In the event that the work being done is non-trivial, suddenly the CPU:bandwidth ratio changes significantly.
In short, it really doesn't matter if the work unit is DB centric or analyzing geographic data from memory mapped files. The point is, this is an area that tends to be ignored/forgotten, or simply overlooked in exchange for ease of implementation. This fact, usually ignores the best tool for the job.
The same can be implemented for any language. It is not a language feature.
The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance. Using a faster language isn't going to help that, so typically web-folk go for the easiest solution.
I've had people tell me this before. This assumption can be an illusion. While it's true that you are limited on a per connection basis in many cases, it's also true that the number of requests that can be processed at a given instant in time is also a bottleneck at that instant. So, if you expect to be processing large volumes of hits in a finite window, it's important to have an optimal solution. This point seems to be frequently ignored or forgotten. What does this mean? Well, assuming you have the bandwidth, let's say an optimal implementation can support 50r/s versus 30r/s (these are numbers pulled from my back pocket). Assuming these numbers, that means that you are able to respond to 60% more requests in a timely manner. This directly reflects quality of service. For some web sites, it's critical to keeping their customers happy. Another way of looking at it is that you can grow in volume 60% more before you have to upgrade hardware which can be realized as a cost savings. It's important to remember that this counter does not address the ease of implementation. Which, for some, is thee deciding factor.
I've seen it done on a regular basis (as so far as the dealings I've been involved with). NDA serve to protect. It is standard business practice. Any good laywer will tell you that. Those not wishing to sign NDA should be pushed away and kept at arms length. They generally are the ones that can lead to problems. There is nothing that prevents them from signing an NDA; other than perhaps ethics (er...lack of them). Not signing an NDA does not prevent them from being liable or sued. In short, NOT signing one provides NO added protection for them. All it does it confirm that the product was disclosed, when, and why. If anything, if offers shelter for both parties. Again, if you have people not wanting to sign an NDA, this should immediately be cause for concern.
Can we please not post kernel releases unless the change log is also attached? Without this, I fear that we are pushing the "you must upgrade" mentality that MS users are used to. This way, we may also help cut down on the number of downloads that are done and free up some bandwidth for those people that may actually need the fix.
I have participated in a number of IDG surveys before I refused to answer any more. IDG is the most biased suvey that I can imagine. At that point in time, I was already extreemly weary of ZD stuff, but still hoped that other groups would do the right thing. Their suveys would not allow for anything out of the box (OS/2, Linux, lesser brand UNIX, e.g. Consensys). When they report their findings, they make bold statements like, "NT clearly is building up steam. Other OS's are not even a blip on the screen." Well, of course they are not, you never even checked for them.
Having said that, I must admit that I too play the survey game with people. No matter how irritating it is, people seem to beleave something that in print even if the should know better. So, when I find something that supports common sense of experience, I point at it. This is very annoying.
I know people that consider me to be extreemly Linux biased. I explain to people this is because I've used both (Microsoft products even longer) and have nightmares getting the same results with more downtown from NT. I honestly don't have a problem with NT in a departmental role. On the other hand, I'm happy to supply bullets for people that want to use it for an enterprise solution.
Why is this relevent? Well, questions like, "Does NT crash more of less often than Win95?" Then, they report, "NT is preceived as extreemely relable my IT departments and managers."
As you can tell, I have a very low opinion of the big survey companies (IDG, Gartner, etc). As one person pointed out their studies are paid for by someone. The end result is that the results are not tarnished, rather, the questions and stated results are. Enough said.
"Standards... well then tell me the standard way to install a package that works across all Linux distributions?"
What is the standard way to install across UNIX? What about NT. You're dreaming if you think there is a standard in any way, shape, or form on any OS. I know that Win is typically "setup", but notice the word, "typically". In other words, even in the "standard" winWorld(tm), there's no such thing.
Can you tell me the standard way to uninstall an application across WinWorlds? No, you can't, because there isn't a standard way. Some applications support this, some don't. Furthermore, some uninstalls don't even do it correctly.
In short, you've not convinced me.