no shit, sherlock! in other news, CDs are still beating every aspect of floppies. did you really expect USB to beat firewire? how? why? wtf?
USB 2.0, of course, has a higher theoretical top bandwidth than Firewire 400. When USB 2 first came out, benchmarks showed that it was slower than Firewire; I attributed USB's inferior performance to its newness and immaturity of the disk controllers, just like early Firewire disks were hampered by their disk controllers, which were merely ATA bridges. Although I'm not an expert in this stuff, I figured that USB 2 would eventually surpass Firewire 400 as the disk controllers matured. It looks like that hasn't come to pass, and probably never will at this point.
The most interesting aspect of the review is that Firewire outperformed USB for every drive in every aspect of the testing. I guess some things don't change.
No, he's complaining about the article's conclusions. For example:
As far as "straight-out-of-box" conditions go, both Microsoft's Windows and Apple's OS X are ripe with remotely accessible vulnerabilities.
To most people, "straight out of box" means "without screwing around with things." That is not the sense in which they are using it. In fact, they plainly state about OS X that "the issues were not remotely accessible" earlier in the article.
And to most people, "straight out of the box" doesn't mean "a box you bought a year ago." There was no excuse for testing a pre-10.4.8 version of Mac OS X Server, but no equally old versions of Linux. If you buy a boxed version of Mac OS X or Mac OS X Server, you get 10.4.8.
Finally, the use of the intensifier "ripe" [sic - I'm guessing they mean "rife"] and plural "vulnerabilities" also doesn't jive with their claim that "Nessus found only a user enumeration vulnerability in the HTTP server." Would you consider a system that allows someone to test whether a given username has an account, but is otherwise secure, to be "ripe with vulnerabilities?" I wouldn't.
Richard Stallman is against the existence of commercial software, and he gives very good reasons for why he thinks it is bad for society. But I'm not sure he is against the existence of commercial software businesses.
Splitting hairs, I'd say - in any case, I think we agree that it's hard to reconcile "commercial software should not exist" with "I want to sell commercial software." As to 'judging the code on its merits,' I wouldn't want to buy from someone who didn't want me as a customer, even if the price were zero. If nothing else, I'd worry that they would be less likely to accept patches, fix bugs that were important to me, interact on mailing lists, and in general provide support. It's not necessarily a deal breaker, but it's a factor to consider. In large organizations, procedural issues can dominate the technical ones.
And - no offense intended - 'judge the code on its merits' is not practiced by the FSF community (if you'll permit me to generalize from RMS), who believe that, for example, schools should use exclusively free software, regardless of any technically superior proprietary alternatives. For RMS, too, procedural issues dominate the technical issues.
From Wikipedia I see your Wikipedia and raise you one Merriam Webster: shill b : one who makes a sales pitch or serves as a promoter
If you were in the business of selling software, would you feel comfortable using code written by folks who are philosophically opposed to the existence of your business? If you're going to blame the commercial software shills, you also have to acknowledge the impact of the open source shills.
Managers are under the mistaken impression that if i just use spring or Jakarta Commons, the company MUST open up the whole project in which it is used (like a proprietrary trading system) to Open Source.
Use how? What if one of the engineers needs a snippet of code, copies it from Spring, and incorporates it into their product without attribution? Suddenly, that company is legally vulnerable.
You only need to open up if and when you modify Spring framework with your own code
No, that is not correct - the Spring framework does not require you to distribute your changes. You just proved the point: licensing mistakes are easy to make. If you were developing a program that incorporated Spring, and mistakenly believed that it required you to license your source, you would cost your company a great deal of money by doing so. That is why the fear is legitimate.
Open source hacks is another fear they have: the fear that somehow using open source tools will make their client sue them.
And that's a reasonable fear. If I sell code that violates a license to a client, that client becomes legally vulnerable and might sue me. Because open source software is so accessible, it becomes easier to inadvertently violate a license.
Leak Back: Managers fear developers, in their zeal to promote open source, will incorporate company's code into open source for 'benefitting' others.
I doubt very much that's a concern. No developer is going to risk their job for open source warm fuzzies, and conversely, no open source project is going to accept leaked patches. Any project that did would open itself up to huge legal liability. Corporate espionage and bribery is a much bigger worry.
You mentioned maturity, but I think you have it backwards - corporations have developed strict, mature processes for keeping themselves on firm legal footing, and licenses are reviewed and vetted by the legal teams. The wide availability of license-encumbered code means that engineers have the opportunity to play lawyer. That's bad, and if you're a manager, you should be scared by that.
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency
Well, certainly you won't be able to get a square root through in one clock cycle, but many/most of the simple integer arithmetic, bitwise, and MOV SSE instructions on the Core 2 really do have single cycle latency. source. None do on the AMD64, which supports the theory that SSE128 means more "new for us" than "new for everyone." Not to put AMD down - many of the other features sound promising (but the article is long on breathlessness and light on details, alas).
SSE+ operations up until now were operated on 64 bit at a time within the processor
Hmm...do you mean specifically on AMD's hardware? That stopped being true for Intel starting with the Core, which has 1-cycle latency on SSE instructions.
'cause it's says some things that just ain't so. Let's take a look:
"...the technological aspect is that DRM implies that the software, or even worse -- hardware -- should be manufactured not for the highest stability and performance, but rather for the best copyright protection possible.
This is just wrong. The fact that a product implements DRM doesn't mean that DRM somehow becomes the Prime Directive and all other considerations are secondary. Does iTunes have the "best copyright protection possible?" No; there's plenty of known workarounds. (The point is just that - they're workarounds. They take work.) "Best possible" is unnecessary.
Besides, every feature you add compromises stability and performance in some way. It does not follow from this that all features are bad.
This means, that we -- the users -- are supposed to pay more money for a product that is defective (does not allow certain functionality for non-technical reasons)
"Does not allow certain functionality for non-technical reasons" is NOT the definition of "defective." If software has a bug that breaks a feature, that's clearly a defect...but according to the author, that's not defective since software bugs are "technical" reasons?
Look, in all other uses, a defect is when something works differently than intended. "Defective by design" is a rhetorical device, just like "trusted computing." Buy into both, or neither, but don't go using one while complaining about the other. That's hypocritical.
"In the world of DRM, it turns that we cannot do whatever we want with the legally purchased products (like software, music, videos or text documents)."
News flash - you can't do that TODAY with your legally purchased products. I can't buy a DVD and start charging crowds to come in and watch it. I can't make photocopies of that book I just bought and distribute it to all my friends. Those things are illegal. So you haven't lost the ability to do "whatever you want" unless you've been willing to break the law - and then why are you whining about DRM when you acknowledge later on that it's easy to get around?
I'm not an apologist for DRM purveyors, but I have no patience for articles like this one.
>> A good language strives to find a few constructs that solve multiple problems.
> D does this.
It does not. Look at it the author's own language comparison and tell me that D doesn't take the kitchen sink approach. The author does not ascribe to the "small number of flexible constructs" philosophy, and he is obviously proud of that.
> You are looking past the dozens of examples where D has cleaned up problems that have been plaguing programmers for years to grasp at a chance to make a piece of code as messy as possible. Maybe you are comfortable working with C/C++ and don't want to deal with another language.
Cleaned up? Not only has D failed to address C++'s complexity, it adds a whole new dimension of pain. Let's consider this piece of code:
someFunction(x, y++);
What can we say about it as C, C++, and D code?
In C, x and y cannot be modified by someFunction, and y will be increased by 1. We know exactly what values x and y will have afterwards.
In C++, x may be modified by someFunction (if it takes a reference type), but y cannot be otherwise modified and will be increased by 1. We at least know what value y will have.
In D, x may be modified by someFunction if it takes an inout type, and y may be increased by 1, 2, 3, 4, or more, or by nothing at all, if someFunction takes a lazy type. We no longer know what value either of those variables has.
See how (needlessly) featureful D is? It is the most confusing and the messiest of the three. This is not a good language.
The largest problem with C++ is its complexity, which causes the language to fragment into partially intersecting sublanguages representing each programmer's comfort zone. D does not address this problem; in fact, it makes it much worse. Example? C++ has seventy some keywords, but D has more than ninety. Another example? See if you can guess what this means in D:
0XA1_2_C35_4_5_6_5P6_Li
Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."
A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?
> People have n money available to them. They spend it optimally - at least, more optimally than anyone else can spend that money on their behalf, because they know most about themselves, more than anyone else. > When the State appropriates money and decides what to spend it on, that money is AT BEST spend as efficiently as it would have been otherwise (in the case where the State spends it exactly at the individual would have).
That is not true at all! Imagine a city full of people who each have a dollar to spend. Each person can spend it on a Big Mac or towards the city's street lights. Everybody would rather have street lights instead of a Big Mac. However, the individual marginal street light gain from a single dollar is negligible - how many street lights does a dollar buy, after all? So the optimal choice for each individual person is to buy the Big Mac, even though everyone would prefer the lights. The state, by appropriating the dollar, can spend that money more efficiently by buying street lights, and everybody becomes better off.
Locally optimal choices do not necessarily imply a global optimum! Investment in infrastructure is exactly the sort of public good where locally optimal choices can lead to poor global decisions.
I'm not quite sure how a raster image can be "rendered using vectors" (and any more information you had on this would be nifty), but whatever hoops Vista jumps through internally, it still can't allow an image that starts out as 256x256 raster to be scaled up "as big as you want" with no loss in quality.
The author seems rather confused about what "GUI" means. The GUI is the graphical user interface - what the user sees and interacts with. The article mentioned almost nothing about the actual user interface of Vista - only the developer-targeted APIs. Nearly all of the apps that ship with Vista do not use WPF and therefore the actual GUI will not be like what the author describes.
And the author is simply wrong when he says that "With WPF, everything is drawn with vectors, so you can scale windows and icons as big (or as small) as you want, and the objects will display with no loss in quality." In fact, icons in Vista are generally 256x256 bitmap images. Artists normally prefer bitmaps because it gives them more control over the artwork.
you do not allow me access to the source code and thereby prevent me from studying and adapting software, then that is an example of you imposing your will upon me.
You insist that I give you my source code, but you think I'm the one imposing my will on YOU? How rich!
I bought the Intellimouse Explorer, the first mass market optical mouse, when it came out, and I used it for years. It truly was and is a great mouse, but I'm not kidding anyone - it's an ugly little rodent.
Mac OS X gives you control over which packages get installed. You can leave out the language packs, throw in X11, etc. If the Vista install disk is just a big image, how do you control what gets installed?
What relevant gains does firewire have that justifies its higher cost over USB 2.0 for the average consumer?
I didn't realize that was the criteria. Is everything YOU use something that the "average consumer" needs?
I think one port as the standard, being USB 2.0, which is "good enough" and cheaper is much better than having firewire ports as the standard
Bizarre dichotomy. I have both and I'm glad of it. I don't understand why a person that wants to "custum build my own computer myself" would be in favor of fewer choices.
but now that USB 2.0 is the norm firewire is just about pointless and I hope it disappears fast
Firewire is much smarter, faster, more featureful, and less CPU intensive than USB 2. Why do you want superior technology to "disappear fast?" Is it because it's more expensive?
I will keep spending my money on much cheaper hardware
>If your objection to piracy is based in morality rather than legality, the term falls short.
No it doesn't. It doesn't say it's a bad thing, but it doesn't say it's a good thing either. It's a neutral term.
Assume, for the sake of argument, that allofmp3 was found to be legal, and that it also did not pay any money to the artists or labels. Then downloading from allofmp3 would not be "illegal copying," but would still be subject to the same objections. That's the sense in which "illegal copying" is a poor term - it may very well include legal activities. Conversely, ripping your purchased DVDs to your computer so you can watch them on your laptop might be illegal copying - but I would not include that activity in whatever-we-end-up-calling-piracy.
I sympathize with your point, but copyright law is a balance between conflicting rights. A good name will, by necessity, presuppose that the balance at least exists.
Slashdot Mirror
Tabbed UI, Apple Lisa, circa 1980. Screenshots, story.
did you really expect USB to beat firewire? how? why? wtf?
USB 2.0, of course, has a higher theoretical top bandwidth than Firewire 400. When USB 2 first came out, benchmarks showed that it was slower than Firewire; I attributed USB's inferior performance to its newness and immaturity of the disk controllers, just like early Firewire disks were hampered by their disk controllers, which were merely ATA bridges. Although I'm not an expert in this stuff, I figured that USB 2 would eventually surpass Firewire 400 as the disk controllers matured. It looks like that hasn't come to pass, and probably never will at this point.
The most interesting aspect of the review is that Firewire outperformed USB for every drive in every aspect of the testing. I guess some things don't change.
To most people, "straight out of box" means "without screwing around with things." That is not the sense in which they are using it. In fact, they plainly state about OS X that "the issues were not remotely accessible" earlier in the article.
And to most people, "straight out of the box" doesn't mean "a box you bought a year ago." There was no excuse for testing a pre-10.4.8 version of Mac OS X Server, but no equally old versions of Linux. If you buy a boxed version of Mac OS X or Mac OS X Server, you get 10.4.8.
Finally, the use of the intensifier "ripe" [sic - I'm guessing they mean "rife"] and plural "vulnerabilities" also doesn't jive with their claim that "Nessus found only a user enumeration vulnerability in the HTTP server." Would you consider a system that allows someone to test whether a given username has an account, but is otherwise secure, to be "ripe with vulnerabilities?" I wouldn't.
Splitting hairs, I'd say - in any case, I think we agree that it's hard to reconcile "commercial software should not exist" with "I want to sell commercial software." As to 'judging the code on its merits,' I wouldn't want to buy from someone who didn't want me as a customer, even if the price were zero. If nothing else, I'd worry that they would be less likely to accept patches, fix bugs that were important to me, interact on mailing lists, and in general provide support. It's not necessarily a deal breaker, but it's a factor to consider. In large organizations, procedural issues can dominate the technical ones.
And - no offense intended - 'judge the code on its merits' is not practiced by the FSF community (if you'll permit me to generalize from RMS), who believe that, for example, schools should use exclusively free software, regardless of any technically superior proprietary alternatives. For RMS, too, procedural issues dominate the technical issues.
From Wikipedia I see your Wikipedia and raise you one Merriam Webster:shill b : one who makes a sales pitch or serves as a promoter
If you were in the business of selling software, would you feel comfortable using code written by folks who are philosophically opposed to the existence of your business? If you're going to blame the commercial software shills, you also have to acknowledge the impact of the open source shills.
It is not the quality of the software that is scary to management, but the unknown legal implications of incorporating it into their own offerings.
Managers are under the mistaken impression that if i just use spring or Jakarta Commons, the company MUST open up the whole project in which it is used (like a proprietrary trading system) to Open Source.
Use how? What if one of the engineers needs a snippet of code, copies it from Spring, and incorporates it into their product without attribution? Suddenly, that company is legally vulnerable.
You only need to open up if and when you modify Spring framework with your own code
No, that is not correct - the Spring framework does not require you to distribute your changes. You just proved the point: licensing mistakes are easy to make. If you were developing a program that incorporated Spring, and mistakenly believed that it required you to license your source, you would cost your company a great deal of money by doing so. That is why the fear is legitimate.
Open source hacks is another fear they have: the fear that somehow using open source tools will make their client sue them.
And that's a reasonable fear. If I sell code that violates a license to a client, that client becomes legally vulnerable and might sue me. Because open source software is so accessible, it becomes easier to inadvertently violate a license.
Leak Back: Managers fear developers, in their zeal to promote open source, will incorporate company's code into open source for 'benefitting' others.
I doubt very much that's a concern. No developer is going to risk their job for open source warm fuzzies, and conversely, no open source project is going to accept leaked patches. Any project that did would open itself up to huge legal liability. Corporate espionage and bribery is a much bigger worry.
You mentioned maturity, but I think you have it backwards - corporations have developed strict, mature processes for keeping themselves on firm legal footing, and licenses are reviewed and vetted by the legal teams. The wide availability of license-encumbered code means that engineers have the opportunity to play lawyer. That's bad, and if you're a manager, you should be scared by that.
I did. Best decision I ever made.
Also, nerf Pallys.
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency
Well, certainly you won't be able to get a square root through in one clock cycle, but many/most of the simple integer arithmetic, bitwise, and MOV SSE instructions on the Core 2 really do have single cycle latency. source. None do on the AMD64, which supports the theory that SSE128 means more "new for us" than "new for everyone." Not to put AMD down - many of the other features sound promising (but the article is long on breathlessness and light on details, alas).
SSE+ operations up until now were operated on 64 bit at a time within the processor
Hmm...do you mean specifically on AMD's hardware? That stopped being true for Intel starting with the Core, which has 1-cycle latency on SSE instructions.
Anyone know what "SSE128" means? SSE registers have been 128 bit from day one.
"...the technological aspect is that DRM implies that the software, or even worse -- hardware -- should be manufactured not for the highest stability and performance, but rather for the best copyright protection possible.
This is just wrong. The fact that a product implements DRM doesn't mean that DRM somehow becomes the Prime Directive and all other considerations are secondary. Does iTunes have the "best copyright protection possible?" No; there's plenty of known workarounds. (The point is just that - they're workarounds. They take work.) "Best possible" is unnecessary.
Besides, every feature you add compromises stability and performance in some way. It does not follow from this that all features are bad.
This means, that we -- the users -- are supposed to pay more money for a product that is defective (does not allow certain functionality for non-technical reasons)
"Does not allow certain functionality for non-technical reasons" is NOT the definition of "defective." If software has a bug that breaks a feature, that's clearly a defect...but according to the author, that's not defective since software bugs are "technical" reasons?
Look, in all other uses, a defect is when something works differently than intended. "Defective by design" is a rhetorical device, just like "trusted computing." Buy into both, or neither, but don't go using one while complaining about the other. That's hypocritical.
"In the world of DRM, it turns that we cannot do whatever we want with the legally purchased products (like software, music, videos or text documents)."
News flash - you can't do that TODAY with your legally purchased products. I can't buy a DVD and start charging crowds to come in and watch it. I can't make photocopies of that book I just bought and distribute it to all my friends. Those things are illegal. So you haven't lost the ability to do "whatever you want" unless you've been willing to break the law - and then why are you whining about DRM when you acknowledge later on that it's easy to get around?
I'm not an apologist for DRM purveyors, but I have no patience for articles like this one.
> D does this.
It does not. Look at it the author's own language comparison and tell me that D doesn't take the kitchen sink approach. The author does not ascribe to the "small number of flexible constructs" philosophy, and he is obviously proud of that.
> You are looking past the dozens of examples where D has cleaned up problems that have been plaguing programmers for years to grasp at a chance to make a piece of code as messy as possible. Maybe you are comfortable working with C/C++ and don't want to deal with another language.
Cleaned up? Not only has D failed to address C++'s complexity, it adds a whole new dimension of pain. Let's consider this piece of code:
someFunction(x, y++);
What can we say about it as C, C++, and D code?
See how (needlessly) featureful D is? It is the most confusing and the messiest of the three. This is not a good language.
0XA1_2_C35_4_5_6_5P6_Li
Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."
A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?
> People have n money available to them. They spend it optimally - at least, more optimally than anyone else can spend that money on their behalf, because they know most about themselves, more than anyone else.
> When the State appropriates money and decides what to spend it on, that money is AT BEST spend as efficiently as it would have been otherwise (in the case where the State spends it exactly at the individual would have).
That is not true at all! Imagine a city full of people who each have a dollar to spend. Each person can spend it on a Big Mac or towards the city's street lights. Everybody would rather have street lights instead of a Big Mac. However, the individual marginal street light gain from a single dollar is negligible - how many street lights does a dollar buy, after all? So the optimal choice for each individual person is to buy the Big Mac, even though everyone would prefer the lights. The state, by appropriating the dollar, can spend that money more efficiently by buying street lights, and everybody becomes better off.
Locally optimal choices do not necessarily imply a global optimum! Investment in infrastructure is exactly the sort of public good where locally optimal choices can lead to poor global decisions.
I'm not quite sure how a raster image can be "rendered using vectors" (and any more information you had on this would be nifty), but whatever hoops Vista jumps through internally, it still can't allow an image that starts out as 256x256 raster to be scaled up "as big as you want" with no loss in quality.
The author seems rather confused about what "GUI" means. The GUI is the graphical user interface - what the user sees and interacts with. The article mentioned almost nothing about the actual user interface of Vista - only the developer-targeted APIs. Nearly all of the apps that ship with Vista do not use WPF and therefore the actual GUI will not be like what the author describes.
And the author is simply wrong when he says that "With WPF, everything is drawn with vectors, so you can scale windows and icons as big (or as small) as you want, and the objects will display with no loss in quality." In fact, icons in Vista are generally 256x256 bitmap images. Artists normally prefer bitmaps because it gives them more control over the artwork.
The blobbing windows and the cube make GREAT demos, but not so great products. The constant effects get tiresome quickly.
You insist that I give you my source code, but you think I'm the one imposing my will on YOU? How rich!
I bought the Intellimouse Explorer, the first mass market optical mouse, when it came out, and I used it for years. It truly was and is a great mouse, but I'm not kidding anyone - it's an ugly little rodent.
Mac OS X gives you control over which packages get installed. You can leave out the language packs, throw in X11, etc. If the Vista install disk is just a big image, how do you control what gets installed?
What relevant gains does firewire have that justifies its higher cost over USB 2.0 for the average consumer?
I didn't realize that was the criteria. Is everything YOU use something that the "average consumer" needs?
I think one port as the standard, being USB 2.0, which is "good enough" and cheaper is much better than having firewire ports as the standard
Bizarre dichotomy. I have both and I'm glad of it. I don't understand why a person that wants to "custum build my own computer myself" would be in favor of fewer choices.
but now that USB 2.0 is the norm firewire is just about pointless and I hope it disappears fast
Firewire is much smarter, faster, more featureful, and less CPU intensive than USB 2. Why do you want superior technology to "disappear fast?" Is it because it's more expensive?
I will keep spending my money on much cheaper hardware
Guess so!
No it doesn't. It doesn't say it's a bad thing, but it doesn't say it's a good thing either. It's a neutral term.
Assume, for the sake of argument, that allofmp3 was found to be legal, and that it also did not pay any money to the artists or labels. Then downloading from allofmp3 would not be "illegal copying," but would still be subject to the same objections. That's the sense in which "illegal copying" is a poor term - it may very well include legal activities. Conversely, ripping your purchased DVDs to your computer so you can watch them on your laptop might be illegal copying - but I would not include that activity in whatever-we-end-up-calling-piracy.
I sympathize with your point, but copyright law is a balance between conflicting rights. A good name will, by necessity, presuppose that the balance at least exists.