Here is what appears to be a different version of the article with a little more info. No actual performance numbers, but a description of the test at least.
Open source projects are freed from the time == money constraint
Ah, but don't forget this is Microsoft we're talking about here. Microsoft has no shortage of money or programmer time. Given the fundamental limitations described in "Mythical Man-Month", I see why they can't just throw 10 times more programmers at Windows and expect it to come out 10 times better, but it seems to me like they could do something different. They could develop five or ten versions of Windows in parallel, each competing against the others for the privelige of being released as the next public version. Or maybe when it's time to release the best parts of each version could be integrated together. When you have as much money as Microsoft, regular software development practices don't need to constrain you any more. I don't understand why Microsoft hasn't realized this.
Well, disk accesses take power too, so if the cpu can reduce the number of those, then overall battery usage could stay the same or even go down. It's pretty much impossible to say without testing.
I think Reiser4 is for the most part a long way away from blocking for lack of CPU cycles. Sure, it takes more CPU than conventional filesystems, but conventional filesystems use a totally negligable amount of CPU. All things considered, the amount of CPU Reiser4 needs isn't that much, especially given Moore's law.
For desktop usage, trading CPU for disk efficiency is almost always going to be a good tradeoff. Most of the time on a desktop system when you're accessing the disk the application is blocked waiting for the results, and the user is sitting there waiting for the application. Any decrease in disk wait time is going to get those results to the user faster.
For a CPU-bound application doing lots of non-time-critical asynchronous I/O, Reiser might not be a good choice. But I think that's not a very common situation. Things like compilers don't do asynchronous I/O, they block. In a blocking situation, faster response time is better since you're just wasting CPU cycles anyway during the blocking period. If you do all your compiling in parallel you can use those CPU cycles, but most people don't.
You might think that just based on the amount of red in Reiser4's row, but if you look all the way over to the right, you'll notice something interesting: Reiser4 often completes the benchmark in significantly less time than the other filesystems. Reiser seems to be caching a lot of flak for the CPU usage (certainly it gets a lot of red boxes in this benchmark because of it). Personally, though, I've got CPU to spare. Disk seek times aren't changing drastically anytime soon, unlike CPU speeds. If I can trade some CPU cycles for less wasted disk seek time, I think that's a great trade.
There's no reason bytes can't be a special case. Do you have some sort of religious devotion to the metric prefixes that prevents you from ever using them in a way that might not be exactly the same for every unit? In fact, bytes already are a special case, and this proposal is simply acknowledging the fact. It's a great idea, certainly much better changing to dorky-sounding "mebi"-type prefixes, which would require everyone to change every reference to kilobytes or megabytes in everything they've ever written or typed. It's hard to even pronounce those stupid things so that everyone realizes what you're saying!
Certain properties of the x86 architecture make it a hard chip to "virtualize" (sort of partition the processor into two virtual processors), which is what VMWare does. Chips can be designed specifically to be easily virtualizable, making applications like VMWare almost trivial to code while being much, much faster. If Intel does somehow retrofit virtualization capabilities onto a x86 chip, it could be a big boon for Linux. An open-source VMWare clone could be written quite easily, and it would run Windows almost as fast as it would run natively.
Yes, but when you turn it on, does it ask you to choose a name and automatically register itself as "name".axentra.com? No? Then the type of people who don't know what a dynamic DNS service is or why they want one (which would be a large part of the target market of this box) won't ever get a permanent DNS name for their server, and the box will be that much less useful to them. It's all about ease of use.
Right, and what is the reason people put up with TOS like this? It is exactly because almost nobody cares about running a server, because they see the Internet as nothing more than a way to browse webpages and get email. Only us geeks care. But if running a small server becomes popular, so that it becomes one of the main reasons people buy Internet service, people will start to take notice of things like this, and the ISPs will have no choice but change their TOS to allow servers, and make their services more server-friendly. That's the kind of thing I want to see in an ISP. The Internet is unrestricted 2-way communication for everyone, not HTML and Flash downloaded from "content providers."
This seems like a pretty cool little device. Maybe with appliances like these more people will start to get interested in hosting their own website on their DSL/Cable connection, or doing other "server" type stuff. I really dislike how the Internet today is seen as just a place to visit web pages. Maybe with a simple server appliance people will get the idea that they can publish stuff on the web and share stuff with their friends and family that way. They could even have it run things like a jabber server. Wouldn't that be cool? What this company would do if they were smart is automatically give everyone who buys one of these a dynamic DNS account, so your little server could have its own permanent address with no configuration necessary.
Beats me. Talk to the guy who made the comment I replied to, he's the one who said IBM's init scheme was bad. I've never used it myself, I was just refuting his argument.
It is trying to innovate past the ancient Unix ways, and it shows a willingness to look toward the future instead of stagnating in the past.
IBM tried once and failed, but that doesn't mean everyone should just give up. One of the several open-source init replacements available today (or in the planning stages) will eventually turn out to be better than kludgy old Unix init, and it will be replaced, as it should be.
Personally, I hope that within 10 years Linux will hardly even be recognizable as a Unix anymore. If Linux stays exactly like Unix forever, it will never be able to become the next-generation operating system we all want to use. Unix isn't the best possible operating system, and Linux has the potential to become more than Unix ever was.
Because Microsoft is a humongous company and the Research branch (which is the part of Microsoft doing the sponsoring) is a completely separate entity from the Windows branch. When I say this is "exactly what Microsoft doesn't want", I am talking specifically about the Windows and Office parts of Microsoft, and not the Research, MSN, XBox, hardware, or Expedia branches, or any other branch. These branches are all run by different people who may not always be working in perfect harmony. It's kinda like the fallacy of the single Slashdot poster: People often assume that everyone on Slashdot shares the same opinion about everything, which is not true. Likewise, people often assume that companies are single entities that always act in a coordinated, logical manner. Instead companies (especially large ones) are a mishmash of smaller departments, each governed by a different set of people, who may have different opinions and goals which may conflict.
I don't know why my post was modded informative, because it contained very little factual content, mostly opinion. But graphics card companies do get prerelease binaries of new graphics engines. I don't have any specific information about this, but it wouldn't be too far fetched for partial source to be given as well, to help with optimizing and fixing drivers. But now that I've actually seen what was released, it seems to me like this is more code than Valve would have given ATI. As far as I can tell, it's basically a snapshot of most, if not all of Valve's code. If Valve did release source to ATI, I would expect it to be a stripped down version for testing. That's what I would do if I were Valve, at least.
Mod parent up, insightful. They leaked Doom III didn't they? They probably had access to the code, didn't they? Probably someone at ATI let his friend see it, and they let their friend see it, and suddenly poof, it's all over the Internet. Heads are going to roll for this one...
I don't see what this technology can do for Microsoft. They don't want you to be able to run Windows on Linux, because that would make it easier to switch to Linux. They don't want you running Linux on Windows because they'd rather you just ran Windows. Xen can't run Windows on Mac OS, or vice versa. The only way I could see Microsoft using this technology is as a way to run multiple copies of Windows at the same time. That might be useful for developers or people who want sandbox systems for security reasons, but it seems to me like these uses are much less compelling. Xen just makes more sense as a way to run multiple different operating systems at the same time, which is exactly what Microsoft doesn't want.
Well, why not? It's definitely a replacement for user-mode linux, given the performance stats on their site, and it can replace VMWare for running Linux, if that's what you do with it. They say they have a port of Windows almost complete, but it'll be a cold day in hell before Microsoft lets them distribute it. So you can't run that last application that's tying you to Windows, or your games. But it can replace VMWare for quite a few other applications, or even play new roles that VMWare couldn't for performance reasons. (Remember that Z/OS virtualized Linux server thingy IBM was doing a while back? This could do the same thing only on Intel).
Ah, I see. I was reading this amendment wrong. I thought it was amending current law, but it is only amending a proposed law. I agree that this proposed law, even as amended, does appear to authorize a lot of software patents.
I'm rather confused. If you read the article, you see people claiming "The aim of this directive is neither to abolish nor to extend the patentability of pure computer programs", and if you read the directive itself, it does not appear to make it any easier to patent software. In fact, most of the stuff I read was simply clarifying existing statements that "computer-implemented inventions may be patented" (not software itself, but inventions that incorporate a software component), adding additional clarification on when it would not be appropriate to consider pure software or business methods "computer-implemented inventions". To me, this amendment only makes it harder to patent software, algorithms, and business methods.
An example: some inserted text reads:
"Computer-implemented inventions must be claimed with reference to
either a product such as a programmed apparatus, or to a process carried out
in such an apparatus. Accordingly, where individual elements of software are
used in contexts which do not involve the realisation of any validly claimed
product or process, such use will not constitute patent infringement."
Remembering that "Computer-implemented inventions" are quite clearly already patentable under current law, this passage only restricts their applicability. The amendment itself is full of such restrictions, and doesn't add any new ways of patenting computer programs that I can see. "The open-source community" is mentioned specifically in a part of the amendment. There is even a new passage making it legal to implement patented methods for the sole purpose of software interoperability, and protecting reverse engineering! Where exactly is the problem with this legislation? You might disagree with the fact that it is possible to patent "computer-implemented inventions" at all, but you can already do that now. This amendment only makes it harder. If you want to strike this concept out of current law, you should lobby for a different amendment and leave this one alone.
qmail and djbdns are written and managed by one person who is obsessive about security and doesn't use the standard libraries that everyone else does. If everyone coded like him, we wouldn't need to worry about buffer overflows. But people don't, and we shouldn't have to expect them to. The language can and should protect us from most stupid mistakes. We should be able to put a reasonable amount of trust in open-source code that has been modified by many people, some of whom aren't experts in security or even experienced coders.
Java is just an example. I'd be perfectly happy with a form of protection for C, as long as it was complete, 100%, guaranteed protection against buffer overflows and the like. Anything less than that is just asking for trouble.
My point is that both VB and JS don't allow stack smashing. Still they're at the root of numerous security breaches.
That's because you download untrusted code and run it in a sandbox! There may be holes in the Java applet sandbox, just like there are holes in the Javascript sandbox. A sandbox is a large, complex thing that is hard to do correctly. But a sandbox for applets is totally irrelevant for trusted application code, which is what a network server is. A hole in the Java applet sandbox has no effect on Java's security as a language for writing servers.
How do you know that? By what measure?
Code Red? Blaster? They were (and still are) huge. If you look at those papers on honeypots that get posted to Slashdot every now and then, you'll see that almost all the exploits used by script kiddies to compromise the honeypot boxes are due to some sort of typical C bug that would be impossible in Java. I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.
Stack smashing is a big problem. [...] But there is no solution.
What? Are you sure you're thinking straight? Do you not agree that there are no stack smashing exploits for the JVM? Obviously, stack smashing has a solution, and it is Java. You may not like it for other reasons, but it does prevent stack smashing.
The scary part isn't when the box gets hacked. It's when the process gets hacked.
Having complete control of a box allows you to hack further into the system and disrupt "the process". "The process" should include making it as hard as possible to hack the box in the first place. Java makes it a lot harder.
given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)
What are you talking about? VB and Javascript are client-side scripting languages with sandboxes. I'm talking about implementing network services here. Not scripting language sandboxes. Many of the recent Microsoft worms have been made possible by exploits in network services that would not work if Windows was written in Java, and the past few Linux vulnerabilities reported on Slashdot (OpenSSL, sendmail, OpenSSH, this lsh hole) have been the same way.
I realize that Java isn't a magic bullet to eliminate logic bugs from your application or prevent social engineering attacks, but usually buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks. If network services were written in Java, a large percentage of today's attacks simply would not work. The benefit would not be negligable as you suggest.
You can argue that [...] no cost is too high to prevent even the most innocent and trivial exploit.
The kinds of exploits that Java prevents are not innocent and trivial, they are the worst possible kinds of exploits; i.e., those that lead directly to code execution. I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.
Slashdot Mirror
Here is what appears to be a different version of the article with a little more info. No actual performance numbers, but a description of the test at least.
Ah, but don't forget this is Microsoft we're talking about here. Microsoft has no shortage of money or programmer time. Given the fundamental limitations described in "Mythical Man-Month", I see why they can't just throw 10 times more programmers at Windows and expect it to come out 10 times better, but it seems to me like they could do something different. They could develop five or ten versions of Windows in parallel, each competing against the others for the privelige of being released as the next public version. Or maybe when it's time to release the best parts of each version could be integrated together. When you have as much money as Microsoft, regular software development practices don't need to constrain you any more. I don't understand why Microsoft hasn't realized this.
Well, disk accesses take power too, so if the cpu can reduce the number of those, then overall battery usage could stay the same or even go down. It's pretty much impossible to say without testing.
For desktop usage, trading CPU for disk efficiency is almost always going to be a good tradeoff. Most of the time on a desktop system when you're accessing the disk the application is blocked waiting for the results, and the user is sitting there waiting for the application. Any decrease in disk wait time is going to get those results to the user faster.
For a CPU-bound application doing lots of non-time-critical asynchronous I/O, Reiser might not be a good choice. But I think that's not a very common situation. Things like compilers don't do asynchronous I/O, they block. In a blocking situation, faster response time is better since you're just wasting CPU cycles anyway during the blocking period. If you do all your compiling in parallel you can use those CPU cycles, but most people don't.
worst: reiser4/reiser4_extents
You might think that just based on the amount of red in Reiser4's row, but if you look all the way over to the right, you'll notice something interesting: Reiser4 often completes the benchmark in significantly less time than the other filesystems. Reiser seems to be caching a lot of flak for the CPU usage (certainly it gets a lot of red boxes in this benchmark because of it). Personally, though, I've got CPU to spare. Disk seek times aren't changing drastically anytime soon, unlike CPU speeds. If I can trade some CPU cycles for less wasted disk seek time, I think that's a great trade.
There's no reason bytes can't be a special case. Do you have some sort of religious devotion to the metric prefixes that prevents you from ever using them in a way that might not be exactly the same for every unit? In fact, bytes already are a special case, and this proposal is simply acknowledging the fact. It's a great idea, certainly much better changing to dorky-sounding "mebi"-type prefixes, which would require everyone to change every reference to kilobytes or megabytes in everything they've ever written or typed. It's hard to even pronounce those stupid things so that everyone realizes what you're saying!
Certain properties of the x86 architecture make it a hard chip to "virtualize" (sort of partition the processor into two virtual processors), which is what VMWare does. Chips can be designed specifically to be easily virtualizable, making applications like VMWare almost trivial to code while being much, much faster. If Intel does somehow retrofit virtualization capabilities onto a x86 chip, it could be a big boon for Linux. An open-source VMWare clone could be written quite easily, and it would run Windows almost as fast as it would run natively.
Yes, but when you turn it on, does it ask you to choose a name and automatically register itself as "name".axentra.com? No? Then the type of people who don't know what a dynamic DNS service is or why they want one (which would be a large part of the target market of this box) won't ever get a permanent DNS name for their server, and the box will be that much less useful to them. It's all about ease of use.
Right, and what is the reason people put up with TOS like this? It is exactly because almost nobody cares about running a server, because they see the Internet as nothing more than a way to browse webpages and get email. Only us geeks care. But if running a small server becomes popular, so that it becomes one of the main reasons people buy Internet service, people will start to take notice of things like this, and the ISPs will have no choice but change their TOS to allow servers, and make their services more server-friendly. That's the kind of thing I want to see in an ISP. The Internet is unrestricted 2-way communication for everyone, not HTML and Flash downloaded from "content providers."
This seems like a pretty cool little device. Maybe with appliances like these more people will start to get interested in hosting their own website on their DSL/Cable connection, or doing other "server" type stuff. I really dislike how the Internet today is seen as just a place to visit web pages. Maybe with a simple server appliance people will get the idea that they can publish stuff on the web and share stuff with their friends and family that way. They could even have it run things like a jabber server. Wouldn't that be cool? What this company would do if they were smart is automatically give everyone who buys one of these a dynamic DNS account, so your little server could have its own permanent address with no configuration necessary.
Beats me. Talk to the guy who made the comment I replied to, he's the one who said IBM's init scheme was bad. I've never used it myself, I was just refuting his argument.
It is trying to innovate past the ancient Unix ways, and it shows a willingness to look toward the future instead of stagnating in the past.
IBM tried once and failed, but that doesn't mean everyone should just give up. One of the several open-source init replacements available today (or in the planning stages) will eventually turn out to be better than kludgy old Unix init, and it will be replaced, as it should be.
Personally, I hope that within 10 years Linux will hardly even be recognizable as a Unix anymore. If Linux stays exactly like Unix forever, it will never be able to become the next-generation operating system we all want to use. Unix isn't the best possible operating system, and Linux has the potential to become more than Unix ever was.
Because Microsoft is a humongous company and the Research branch (which is the part of Microsoft doing the sponsoring) is a completely separate entity from the Windows branch. When I say this is "exactly what Microsoft doesn't want", I am talking specifically about the Windows and Office parts of Microsoft, and not the Research, MSN, XBox, hardware, or Expedia branches, or any other branch. These branches are all run by different people who may not always be working in perfect harmony. It's kinda like the fallacy of the single Slashdot poster: People often assume that everyone on Slashdot shares the same opinion about everything, which is not true. Likewise, people often assume that companies are single entities that always act in a coordinated, logical manner. Instead companies (especially large ones) are a mishmash of smaller departments, each governed by a different set of people, who may have different opinions and goals which may conflict.
I don't know why my post was modded informative, because it contained very little factual content, mostly opinion. But graphics card companies do get prerelease binaries of new graphics engines. I don't have any specific information about this, but it wouldn't be too far fetched for partial source to be given as well, to help with optimizing and fixing drivers. But now that I've actually seen what was released, it seems to me like this is more code than Valve would have given ATI. As far as I can tell, it's basically a snapshot of most, if not all of Valve's code. If Valve did release source to ATI, I would expect it to be a stripped down version for testing. That's what I would do if I were Valve, at least.
Mod parent up, insightful. They leaked Doom III didn't they? They probably had access to the code, didn't they? Probably someone at ATI let his friend see it, and they let their friend see it, and suddenly poof, it's all over the Internet. Heads are going to roll for this one...
I don't see what this technology can do for Microsoft. They don't want you to be able to run Windows on Linux, because that would make it easier to switch to Linux. They don't want you running Linux on Windows because they'd rather you just ran Windows. Xen can't run Windows on Mac OS, or vice versa. The only way I could see Microsoft using this technology is as a way to run multiple copies of Windows at the same time. That might be useful for developers or people who want sandbox systems for security reasons, but it seems to me like these uses are much less compelling. Xen just makes more sense as a way to run multiple different operating systems at the same time, which is exactly what Microsoft doesn't want.
Well, why not? It's definitely a replacement for user-mode linux, given the performance stats on their site, and it can replace VMWare for running Linux, if that's what you do with it. They say they have a port of Windows almost complete, but it'll be a cold day in hell before Microsoft lets them distribute it. So you can't run that last application that's tying you to Windows, or your games. But it can replace VMWare for quite a few other applications, or even play new roles that VMWare couldn't for performance reasons. (Remember that Z/OS virtualized Linux server thingy IBM was doing a while back? This could do the same thing only on Intel).
http://perso.freelug.org/legway/LegWay.html
The hard part is probably just scaling it up and making it safe.
Thanks for the explanation. I can see why interpreting this junk is a full-time job.
Ah, I see. I was reading this amendment wrong. I thought it was amending current law, but it is only amending a proposed law. I agree that this proposed law, even as amended, does appear to authorize a lot of software patents.
An example: some inserted text reads:
Remembering that "Computer-implemented inventions" are quite clearly already patentable under current law, this passage only restricts their applicability. The amendment itself is full of such restrictions, and doesn't add any new ways of patenting computer programs that I can see. "The open-source community" is mentioned specifically in a part of the amendment. There is even a new passage making it legal to implement patented methods for the sole purpose of software interoperability, and protecting reverse engineering! Where exactly is the problem with this legislation? You might disagree with the fact that it is possible to patent "computer-implemented inventions" at all, but you can already do that now. This amendment only makes it harder. If you want to strike this concept out of current law, you should lobby for a different amendment and leave this one alone.qmail and djbdns are written and managed by one person who is obsessive about security and doesn't use the standard libraries that everyone else does. If everyone coded like him, we wouldn't need to worry about buffer overflows. But people don't, and we shouldn't have to expect them to. The language can and should protect us from most stupid mistakes. We should be able to put a reasonable amount of trust in open-source code that has been modified by many people, some of whom aren't experts in security or even experienced coders.
Java is just an example. I'd be perfectly happy with a form of protection for C, as long as it was complete, 100%, guaranteed protection against buffer overflows and the like. Anything less than that is just asking for trouble.
That's because you download untrusted code and run it in a sandbox! There may be holes in the Java applet sandbox, just like there are holes in the Javascript sandbox. A sandbox is a large, complex thing that is hard to do correctly. But a sandbox for applets is totally irrelevant for trusted application code, which is what a network server is. A hole in the Java applet sandbox has no effect on Java's security as a language for writing servers.
How do you know that? By what measure?
Code Red? Blaster? They were (and still are) huge. If you look at those papers on honeypots that get posted to Slashdot every now and then, you'll see that almost all the exploits used by script kiddies to compromise the honeypot boxes are due to some sort of typical C bug that would be impossible in Java. I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.
Stack smashing is a big problem. [...] But there is no solution.
What? Are you sure you're thinking straight? Do you not agree that there are no stack smashing exploits for the JVM? Obviously, stack smashing has a solution, and it is Java. You may not like it for other reasons, but it does prevent stack smashing.
The scary part isn't when the box gets hacked. It's when the process gets hacked.
Having complete control of a box allows you to hack further into the system and disrupt "the process". "The process" should include making it as hard as possible to hack the box in the first place. Java makes it a lot harder.
What are you talking about? VB and Javascript are client-side scripting languages with sandboxes. I'm talking about implementing network services here. Not scripting language sandboxes. Many of the recent Microsoft worms have been made possible by exploits in network services that would not work if Windows was written in Java, and the past few Linux vulnerabilities reported on Slashdot (OpenSSL, sendmail, OpenSSH, this lsh hole) have been the same way.
I realize that Java isn't a magic bullet to eliminate logic bugs from your application or prevent social engineering attacks, but usually buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks. If network services were written in Java, a large percentage of today's attacks simply would not work. The benefit would not be negligable as you suggest.
You can argue that [...] no cost is too high to prevent even the most innocent and trivial exploit.
The kinds of exploits that Java prevents are not innocent and trivial, they are the worst possible kinds of exploits; i.e., those that lead directly to code execution. I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.