> Intel executives believe they can use their considerable software resources to improve the performance > of processing-intensive applications such as VoIP and home entertainment by working with software > application developers to help them understand how Intel's chips process data.
If Intel is dedicating their own resources to helping software vendors meet performance goals on their own chips, it's reasonable to only enable features that require that performance on the chips that have been verified to reach that performance. Presumably, it took some work to reach that performance on Intel's chips, and there's no reason to believe that the unmodified code would run as fast on AMD's chips. Why should Intel go out of their way to help AMD?
Others in this thread are arguing that "it's completely artificial." How do you know that? It's up to Skype to validate what hardware configurations support their software's features so that they know when to enable them - if Intel does that work for them, and AMD doesn't, then it's not surprising that the features are only enabled under Intel's chips.
> One thing I have often wondered is if an object moves fast enough, could its relativistic mass become so large that it > would look like a black hole relative to a laboratory frame?
I don't get why everyone is so down on this story. The Patriot act was temporarily extended in order to allow time for more debate. Bush was pushing for a four year renewal.
To repeat: the choice was not between "Let it die" and "Renew it." The choice was between "Keep it alive for another month so that we can have a real debate about its merits" and "Renew it now or the gubment will be powless to stop the terrists!" Under the circumstances, this is as much of a victory as could be hoped for.
As a side-note, Yahoo is superior to ITMS in every way other than not working with IPods. $5 a month gets you everything.
No it doesn't, not any more. If you want to actually take any of that music with you, it'll cost you $12 a month. If you want to burn a CD, it'll cost you an extra 79 cents per song. And when they inevitably jack up the fees (and they will; $5 a month is a loss leader) and you switch to another subscription service, you'll have to recatalog and redownload all your music; what a hassle! You can have it.
Could? The dual-core Yonah's had better deliver performance better than any of Apple's current laptop lineup. One of the main reasons for the switch to Intel is the sad state of Motorola and IBM's low-power chips.
The irony there is that, if the iBooks went Intel before PowerBooks, a cheap iBook would be faster than a more expensive PowerBook.
Not quite. Without "unsigned," c may or may not be -1, depending on your compiler and its settings. The C standard allows char to be signed or unsigned by default.
It's not an excuse, really, but there are logistical issues with U.S. broadband that also have to be addressed if we are to have any truly comprehensive solution. Frankly I'm not sure which kind of issue will be easier to resolve, but if the slow spread of municipal broadband in rural areas (where big companies can feel comfortable ignoring it) is any indication, we'll get fiber to Anytown, U.S. long before we overcome the greed that prevents us from getting it in urban areas.
That's absurd! That is, it's absurd how right you are.
I live in the heart of Silicon Valley; if any place should have fast broadband, surely it should be here. But I can't get DSL service faster than 600 kbps, so instead I pay about $60/month for 4 Mbps cable, and the only way I can make it not crap out every other minute is with gold-plated cables and a bidirectional coax amplifier.
The movies are encoded using the awesome H.264 codec at 320x240. The resolution is rather low for watching on a TV. But since 320x240 is the iPod's screen resolution, if the videos were any bigger, then they would either have to be reencoded to put them on the iPod (slow!), or put on full-size and scaled down (wasteful of the iPod's space!), or Apple would have to provide the same file in multiple resolutions (confusing and expensive, though perhaps the best long-term solution).
So there you're arguing that C has fewer limitations than, say, Java? Sure, but I wasn't arguing that; I was addressing your claim that "C is actually the most secure language currently."
The argument "C is insecure, we should use [insert odd language here]" is like saying, "Goggles that auto-tint are bad because they're not dark all the time, and you could see a bright flash."
This seems to be a separate point from the one you made previously. You argued that C is the most secure language because it has the slimmest runtime and so the fewest things that can go wrong. I satirized that point. In places that demand C's flexibility, by all means, use C.
I suggest you don't make retorts to peoples' comments unless you actually know what you're talking about
Gladly, but you "what you're talking about" seems to have changed. Beam in your eye first.
Welding without goggles is actually the safest way to weld, AFAICT. Welding goggles open up additional hazard vectors - for example, you might choke on them.
While these "shiny new goggles" may boast "immunity to getting molten metal in your eyes," their approach is still designed around other concepts that may leave holes. Look at their strap and think about it wrapping around your neck. Or maybe you'll have an allergic reaction to the plastic.
So in short, welding without goggles has easily quantifiable hazard vectors, and thus the system can be targeted around those for security. Several such enhancements exist, see "Welding Without Goggles Using Goggles," or "Blindfolded Welding."
Face it. Welding without goggles is the best approach all around for speed, join strength, and safety. Even velcro would more easily fall victim to a "pull apart" type attack; any similar attack is impossible if you weld.
I enrolled at Smartypants U based on its excellent reputation for chemistry, which I had a passion for. I mean a serious passion. I could (can) recite in order the first one hundred elements of the Periodic Table in seventh grade. I got a 5 (out of 5) on the AP chemistry exam without having taken the course, based on what I had taught myself. My high school peers voted me most likely to win a Nobel Prize. Insufferable nerd? Sure, but I loved chemistry.
It took less than a year and a half of college for me to get sick of it. I dropped out of chemistry midway through my sophomore year, because the lab work was unending and tedious and I dreaded every day. I managed to coast through those three semesters based on what I had taught myself, before I switched my major to math.
The math work was a world apart from chemistry tedium. With the exceptions of linear algebra and differential equations, there were no routine problems; every problem involved proving a new, interesting theorem. They all required patience, work, and creativity. I solved one problem while doing crunches in weight lifting class, another while walking to the mall, a third one in a dream (really). Most of the tests were open book and/or take home.
As a result, I can run elliptic curves around most engineers in virtually any math topic. (Which isn't meant as a slight, of course; engineers take lots of courses that I didn't.) I can reason very abstractly (infinite dimensional vector space? No problem!).
No regrets, but it's not all roses. Job prospects are definitely a concern; most math graduates went to grad school, became actuaries (ugh!), or were "undecided" (read: unemployed). I was one of the lucky ones - I graduated with a signed job offer as a programmer, which I also love. Knock on wood.
And, like any major, we had our share of bad, bad professors. No need to get into that.
You can say that Kern wasn't cut out to be an engineer, and maybe he wasn't, and maybe I wasn't cut out to be a chemist. But my own experience has convinced me he's on to something. College turned my six year passion for science sour in a year and a half.
Your criticism of Java for making early, hasty changes is dead on, but I would like to think that the damage was lessened because the changes were mostly confined to libraries - deprecating APIs and the like. Had the changes been to language features, things would have gotten much nastier (as if AWT->Swing wasn't nasty enough!)
But all of these proposed changes are to the C# language proper, not libraries. I think that's an essential difference.
Stroustrup (did you call him "its inventor" because you couldn't spell it either? I had to look it up!) wrote in that link "Library extensions will be preferred to language extensions." Hooray! IMO, it's too little, too late for C++, but I'm happy that he's made that distinction. I hope that the C# folks get that message soon, because they haven't yet.
Compare their approach to LINQ (from, where, select, in, etc. all become keywords) to, say, Apple's new Predicates stuff, which accomplishes the same thing (or at least appears to) without relying on new keywords.
Regarding C++ sublanguages - ok, my Mozilla link wasn't very good. But I stand by my point, that any given project will cherry-pick C++ features to construct their own internal C++ subset. Boost makes heavy use of exceptions and templates; wxWidgets doesn't. The STL barely uses inheritance. If you're programming for Boost, you should try to avoid using catch to catch exceptions. If you're programming for SGI, you shouldn't use C++ strings. Etc.
Java doesn't have issues like these. Java programs by and large all make heavy use of exceptions and inheritance, and recommending that you avoid catch() or strings is unthinkable! Keeping the language features trim and widely relevant is a big help.
You're right that, in principle, new users can learn best practices and start writing in the corresponding shared subset of the language, and really good C++ programmers do. If it weren't so damned hard to become a really good C++ programmer, this might actually happen in practice. Until then, best-practice libraries like Boost will remain out of reach for the majority of C++ programmers
(Though Stroustrup acknowledges that C++ makes things "unnecessarily difficult" for newbies. Maybe there is yet hope.)
Rather than allowing C# to evolve naturally, Microsoft is hoping that they can get people to buy into its intelligent design
Seriously, I've never seen anyone try to evolve a production language this quickly. They're throwing in features left and right. It's exciting! But it's also terrifying: I feel like C# is being driven at breakneck speed towards, err... I don't think Microsoft actually HAS any ultimate goal in mind for C#, as long as they can cover a lot of ground getting there.
And if you drive this fast, eventually you're going to crash, and when C# does, it will fragment into dozens of small shiny sublanguages. People will carve out their C# comfort zones containing the features they feel comfortable with and exclude the rest. Two C# programmers will no longer always speak the same "dialect," making it difficult understand each others' code.
The fact that there's a great deal of overlap among C#'s features only makes this worse. Programmer A's heavy use of generics and lambda expressions will be unfamiliar to programmer B, who never bothered to learn those features since he can accomplish the same things using implicit typing and LINQ.
And, needless to say, differing levels of compiler support will also exacerbate this problem.
I'm surprised Microsoft isn't more careful, given the cautionary example of C++. C++ is in the later stages of this disease. Large projects have to specify the C++ sublanguage dialect that they're using. And we aren't talking simple style guidelines, but the excision of large chunks of features, like RTTI and exceptions. If C# continues the way it's going, it will wind up like this.
ding! That was the sound of me reaching my metaphor limit of three per post. I guess I better end this. So to sum up:
Microsoft, you are the largest software developer and in control of the OS and development tools. You are in the unique position of being able to dictate every aspect of a new programming language. It will be used for years to come by millions of developers in all different situations. This is a blessing and a tremendous opportunity.
(Oh, and Spotlight is a lot deeper than just a nice interface on top of the existing search.)
You might also be surprised by what AppleScript is capable of. It has support for very modern features, including inheritance, exceptions, closures, eval... It's not meant to be the shell - that's why OS X ships with bash, tcsh, and zsh. It's more like VB Script, except vastly nicer and easier to write.
(Your criticism of its syntax is dead on, but believe it or not, AppleScript really does have a syntax, which as far as I know has only been fully documented once.)
Apple definitely has the in-house people to write an OS. The guy who wrote Mach works at Apple. The author of one of the slickest filesystems ever works there too. Oh yeah, and remember this guy? Seriously, Apple has been out-delivering Microsoft since 2001; you can't pick on them for not knowing how to write an OS.
(And, just to be snarky, Microsoft got their kernel folks from somewhere else too.)
I'm glad my OS was designed by, err, designers, incidentally. Apple has some computer science folk, but a computer scientist designing an OS is like a physicist designing a car.
Fearmongering aside, let's think about how viruses usually get into Windows. I see two many ways that worms spread:
Exploiting flaws in networked services
This is how Zotob got around. Microsoft shipped Windows with (I think) seven open ports by default. This colossal mistake ensured those too clueless or lazy to turn off unnecessary services would be the most vulnerable.
Microsoft finally fixed this with SP2, I believe, but the repercussions of all those insecure installs (and continuing insecure installs for non-SP2 Windows CDs) will take years to play out. That's why a worm like Zotob is still possible.
Needless to say, OS X has always shipped with zero ports open by default. (OS X does have mDNSResponder, which launches whenever you use Rendezvous, but that's all).
E-mail worms
ILOVEYOU spread by tricking users into launching a program. Outlook for a while didn't do a sufficient job of warning users that they were opening a potentially malicious applications. Mail, as of Tiger, warns about executable programs before it lets you open them, making it more difficult to trick users.
It's not entirely rosy for Mac users. I don't think OS X has any particular protection against Word macro viruses (e.g. Melissa). But overall, it seems to me that OS X does a better job protecting against the two main vectors that viruses use to infect Windows.
Why do you (and AnandTech) conflate "faster" with "better?" I haven't read the Moshe Bar article you mentioned because it requires significant registration hoops, but there are numerous design decisions that Apple makes that impact performance.
OS X always links libc dynamically. OS X allows for floating point and SIMD in the kernel. OS X gives the kernel its own address space. Etc. There's a tradeoff between performance and binary compatibility/flexibility. In each of the above cases, Linux prefers the former, and Apple the latter. The Anandtech article makes no mention of these; their implicit conclusion is that Apple's engineers are incompetent.
And incidentally, Apple has done a great deal of performance work in their kernel.
>For example, many Mac users still run Microsoft Office >on the Mac. Microsoft isn't obligated to offer that on >x86 for the Mac, now that the five year deal has expired.
Why did Microsoft come on stage at the Keynote and publicly promise to offer Office/x86 then?
> This is more about keeping options open in > case the Intel transition doesn't come off.
"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -Tom Cargill
The largest problem with C++ is its complexity. It is not just too complicated, it is *unmanageably complicated.* Some of the symptoms are:
The STL has inexplicable omissions. For example, there's no portable way to seed the built-in PRNG in the random_shuffle algorithm, rendering it useless.
Guruhood isn't good enough. Consider the seemingly simple task of creating a stack that works correctly with exceptions. It's extraordinarily difficult even for a guru.
Language features interact in nonintuitive ways, producing a combinatorial explosion. For example, if you overload a function in a class, you don't have to use the scope resolution operator, and if you override a function, you don't have to use it either - but if you do both, you DO have to use the scope resolution operator or else you get a compile error!
Insofar as the new C++ standard adds stuff, instead of simplifying, this will only get worse. Since it's unreasonable to expect a new standard to remove features, the problem is unfixable. The result will be that programmers carve out their separate comfort zones, compiler vendors will not implement all features, and the monolithic C++ language will fragment into a Venn diagram of sublanguages. More so than today.
Slashdot Mirror
From TFA:
> Intel executives believe they can use their considerable software resources to improve the performance
> of processing-intensive applications such as VoIP and home entertainment by working with software
> application developers to help them understand how Intel's chips process data.
If Intel is dedicating their own resources to helping software vendors meet performance goals on their own chips, it's reasonable to only enable features that require that performance on the chips that have been verified to reach that performance. Presumably, it took some work to reach that performance on Intel's chips, and there's no reason to believe that the unmodified code would run as fast on AMD's chips. Why should Intel go out of their way to help AMD?
Others in this thread are arguing that "it's completely artificial." How do you know that? It's up to Skype to validate what hardware configurations support their software's features so that they know when to enable them - if Intel does that work for them, and AMD doesn't, then it's not surprising that the features are only enabled under Intel's chips.
> One thing I have often wondered is if an object moves fast enough, could its relativistic mass become so large that it
> would look like a black hole relative to a laboratory frame?
No.
To repeat: the choice was not between "Let it die" and "Renew it." The choice was between "Keep it alive for another month so that we can have a real debate about its merits" and "Renew it now or the gubment will be powless to stop the terrists!" Under the circumstances, this is as much of a victory as could be hoped for.
No it doesn't, not any more. If you want to actually take any of that music with you, it'll cost you $12 a month. If you want to burn a CD, it'll cost you an extra 79 cents per song. And when they inevitably jack up the fees (and they will; $5 a month is a loss leader) and you switch to another subscription service, you'll have to recatalog and redownload all your music; what a hassle! You can have it.
The irony there is that, if the iBooks went Intel before PowerBooks, a cheap iBook would be faster than a more expensive PowerBook.
NOW are you surprised? :)
That's absurd! That is, it's absurd how right you are.
I live in the heart of Silicon Valley; if any place should have fast broadband, surely it should be here. But I can't get DSL service faster than 600 kbps, so instead I pay about $60/month for 4 Mbps cable, and the only way I can make it not crap out every other minute is with gold-plated cables and a bidirectional coax amplifier.
The movies are encoded using the awesome H.264 codec at 320x240. The resolution is rather low for watching on a TV. But since 320x240 is the iPod's screen resolution, if the videos were any bigger, then they would either have to be reencoded to put them on the iPod (slow!), or put on full-size and scaled down (wasteful of the iPod's space!), or Apple would have to provide the same file in multiple resolutions (confusing and expensive, though perhaps the best long-term solution).
BWA HA HA HA HAHA HA AHAH HA!!!
*cough*
Used Office recently?
Here's another doozy. Tried printing or saving recently? This one speaks for itself.
If this counts as "seamless interface design with other Microsoft products," I'll eat my mouse pad.
Permenantly dark goggles -- Java, etc
Goggles that tint when bright light happens -- C
So there you're arguing that C has fewer limitations than, say, Java? Sure, but I wasn't arguing that; I was addressing your claim that "C is actually the most secure language currently."
The argument "C is insecure, we should use [insert odd language here]" is like saying, "Goggles that auto-tint are bad because they're not dark all the time, and you could see a bright flash."
This seems to be a separate point from the one you made previously. You argued that C is the most secure language because it has the slimmest runtime and so the fewest things that can go wrong. I satirized that point. In places that demand C's flexibility, by all means, use C.
I suggest you don't make retorts to peoples' comments unless you actually know what you're talking about
Gladly, but you "what you're talking about" seems to have changed. Beam in your eye first.
Welding without goggles is actually the safest way to weld, AFAICT. Welding goggles open up additional hazard vectors - for example, you might choke on them.
While these "shiny new goggles" may boast "immunity to getting molten metal in your eyes," their approach is still designed around other concepts that may leave holes. Look at their strap and think about it wrapping around your neck. Or maybe you'll have an allergic reaction to the plastic.
So in short, welding without goggles has easily quantifiable hazard vectors, and thus the system can be targeted around those for security. Several such enhancements exist, see "Welding Without Goggles Using Goggles," or "Blindfolded Welding."
Face it. Welding without goggles is the best approach all around for speed, join strength, and safety. Even velcro would more easily fall victim to a "pull apart" type attack; any similar attack is impossible if you weld.
It took less than a year and a half of college for me to get sick of it. I dropped out of chemistry midway through my sophomore year, because the lab work was unending and tedious and I dreaded every day. I managed to coast through those three semesters based on what I had taught myself, before I switched my major to math.
The math work was a world apart from chemistry tedium. With the exceptions of linear algebra and differential equations, there were no routine problems; every problem involved proving a new, interesting theorem. They all required patience, work, and creativity. I solved one problem while doing crunches in weight lifting class, another while walking to the mall, a third one in a dream (really). Most of the tests were open book and/or take home.
As a result, I can run elliptic curves around most engineers in virtually any math topic. (Which isn't meant as a slight, of course; engineers take lots of courses that I didn't.) I can reason very abstractly (infinite dimensional vector space? No problem!).
No regrets, but it's not all roses. Job prospects are definitely a concern; most math graduates went to grad school, became actuaries (ugh!), or were "undecided" (read: unemployed). I was one of the lucky ones - I graduated with a signed job offer as a programmer, which I also love. Knock on wood.
And, like any major, we had our share of bad, bad professors. No need to get into that.
You can say that Kern wasn't cut out to be an engineer, and maybe he wasn't, and maybe I wasn't cut out to be a chemist. But my own experience has convinced me he's on to something. College turned my six year passion for science sour in a year and a half.
Here's Microsoft's page about it: http://www.microsoft.com/products/expression/en/de fault.aspx
OS 9 had some worms and viruses, like that one. As of yet, OS X is unaffected.
Your criticism of Java for making early, hasty changes is dead on, but I would like to think that the damage was lessened because the changes were mostly confined to libraries - deprecating APIs and the like. Had the changes been to language features, things would have gotten much nastier (as if AWT->Swing wasn't nasty enough!)
But all of these proposed changes are to the C# language proper, not libraries. I think that's an essential difference.
Stroustrup (did you call him "its inventor" because you couldn't spell it either? I had to look it up!) wrote in that link "Library extensions will be preferred to language extensions." Hooray! IMO, it's too little, too late for C++, but I'm happy that he's made that distinction. I hope that the C# folks get that message soon, because they haven't yet.
Compare their approach to LINQ (from, where, select, in, etc. all become keywords) to, say, Apple's new Predicates stuff, which accomplishes the same thing (or at least appears to) without relying on new keywords.
Regarding C++ sublanguages - ok, my Mozilla link wasn't very good. But I stand by my point, that any given project will cherry-pick C++ features to construct their own internal C++ subset. Boost makes heavy use of exceptions and templates; wxWidgets doesn't. The STL barely uses inheritance. If you're programming for Boost, you should try to avoid using catch to catch exceptions. If you're programming for SGI, you shouldn't use C++ strings. Etc.
Java doesn't have issues like these. Java programs by and large all make heavy use of exceptions and inheritance, and recommending that you avoid catch() or strings is unthinkable! Keeping the language features trim and widely relevant is a big help.
You're right that, in principle, new users can learn best practices and start writing in the corresponding shared subset of the language, and really good C++ programmers do. If it weren't so damned hard to become a really good C++ programmer, this might actually happen in practice. Until then, best-practice libraries like Boost will remain out of reach for the majority of C++ programmers
(Though Stroustrup acknowledges that C++ makes things "unnecessarily difficult" for newbies. Maybe there is yet hope.)
Rather than allowing C# to evolve naturally, Microsoft is hoping that they can get people to buy into its intelligent design
Seriously, I've never seen anyone try to evolve a production language this quickly. They're throwing in features left and right. It's exciting! But it's also terrifying: I feel like C# is being driven at breakneck speed towards, err... I don't think Microsoft actually HAS any ultimate goal in mind for C#, as long as they can cover a lot of ground getting there.
And if you drive this fast, eventually you're going to crash, and when C# does, it will fragment into dozens of small shiny sublanguages. People will carve out their C# comfort zones containing the features they feel comfortable with and exclude the rest. Two C# programmers will no longer always speak the same "dialect," making it difficult understand each others' code.
The fact that there's a great deal of overlap among C#'s features only makes this worse. Programmer A's heavy use of generics and lambda expressions will be unfamiliar to programmer B, who never bothered to learn those features since he can accomplish the same things using implicit typing and LINQ.
And, needless to say, differing levels of compiler support will also exacerbate this problem.
I'm surprised Microsoft isn't more careful, given the cautionary example of C++. C++ is in the later stages of this disease. Large projects have to specify the C++ sublanguage dialect that they're using. And we aren't talking simple style guidelines, but the excision of large chunks of features, like RTTI and exceptions. If C# continues the way it's going, it will wind up like this.
ding! That was the sound of me reaching my metaphor limit of three per post. I guess I better end this. So to sum up:
Microsoft, you are the largest software developer and in control of the OS and development tools. You are in the unique position of being able to dictate every aspect of a new programming language. It will be used for years to come by millions of developers in all different situations. This is a blessing and a tremendous opportunity.
Don't fuck it up.
(please?)
- Replace one class wholly with another, at runtime (that is, all methods that are invoked on the original class instead get invoked on your new class).
- Change the class of an existing object to a different class.
- Treat classes as if they were any other object, with class methods becoming instance methods on the class object.
- Control what happens when a method is invoked on nil.
- Message forwarding. You just can't do generic RPCs or message logging in C# without a code generator.
- Add a method to an existing class without recompiling it or even needing its source code. How many silly StringUtilities classes have people written?
- Easily incorporate any C or C++ code (just copy and paste).
- Key-value observing. Get notified when a method is invoked without that method even knowing that anyone might be listening.
- Learn the language in an afternoon.
But of course, there's lots of neat stuff that C# has over Objective-C:Ugh. There's a lot to like about C#, but I would never call it beautiful. It's got more keywords than C++, it's chock full of silly features (did you know you can use a keyword as an identifier if you prefix it with @?), and, most egregiously, Microsoft commonly pollutes the language to make up for deficiencies in their toolset.
(Oh, and Spotlight is a lot deeper than just a nice interface on top of the existing search.)
You might also be surprised by what AppleScript is capable of. It has support for very modern features, including inheritance, exceptions, closures, eval... It's not meant to be the shell - that's why OS X ships with bash, tcsh, and zsh. It's more like VB Script, except vastly nicer and easier to write. (Your criticism of its syntax is dead on, but believe it or not, AppleScript really does have a syntax, which as far as I know has only been fully documented once.)
Apple definitely has the in-house people to write an OS. The guy who wrote Mach works at Apple. The author of one of the slickest filesystems ever works there too. Oh yeah, and remember this guy? Seriously, Apple has been out-delivering Microsoft since 2001; you can't pick on them for not knowing how to write an OS.
(And, just to be snarky, Microsoft got their kernel folks from somewhere else too.)
I'm glad my OS was designed by, err, designers, incidentally. Apple has some computer science folk, but a computer scientist designing an OS is like a physicist designing a car.
I'm eagerly awaiting Longhorn, incidentally.
Spotlight is not powered by mySQL.
Exploiting flaws in networked services
This is how Zotob got around. Microsoft shipped Windows with (I think) seven open ports by default. This colossal mistake ensured those too clueless or lazy to turn off unnecessary services would be the most vulnerable.
Microsoft finally fixed this with SP2, I believe, but the repercussions of all those insecure installs (and continuing insecure installs for non-SP2 Windows CDs) will take years to play out. That's why a worm like Zotob is still possible.
Needless to say, OS X has always shipped with zero ports open by default. (OS X does have mDNSResponder, which launches whenever you use Rendezvous, but that's all).
E-mail worms
ILOVEYOU spread by tricking users into launching a program. Outlook for a while didn't do a sufficient job of warning users that they were opening a potentially malicious applications. Mail, as of Tiger, warns about executable programs before it lets you open them, making it more difficult to trick users.
It's not entirely rosy for Mac users. I don't think OS X has any particular protection against Word macro viruses (e.g. Melissa). But overall, it seems to me that OS X does a better job protecting against the two main vectors that viruses use to infect Windows.
Why do you (and AnandTech) conflate "faster" with "better?" I haven't read the Moshe Bar article you mentioned because it requires significant registration hoops, but there are numerous design decisions that Apple makes that impact performance.
OS X always links libc dynamically. OS X allows for floating point and SIMD in the kernel. OS X gives the kernel its own address space. Etc. There's a tradeoff between performance and binary compatibility/flexibility. In each of the above cases, Linux prefers the former, and Apple the latter. The Anandtech article makes no mention of these; their implicit conclusion is that Apple's engineers are incompetent.
And incidentally, Apple has done a great deal of performance work in their kernel.
>For example, many Mac users still run Microsoft Office
>on the Mac. Microsoft isn't obligated to offer that on
>x86 for the Mac, now that the five year deal has expired.
Why did Microsoft come on stage at the Keynote and publicly promise to offer Office/x86 then?
> This is more about keeping options open in
> case the Intel transition doesn't come off.
I don't think you can know that now.
I'm thinkin', but I don't get it. I can and do use any USB mouse I please with my Macs. How am I locked in?
I've placed my order. At the moment, I believe this is an upgrade over a "regular cheap mouse." When it arrives, I'll know for sure!
The largest problem with C++ is its complexity. It is not just too complicated, it is *unmanageably complicated.* Some of the symptoms are:
- The STL has inexplicable omissions. For example, there's no portable way to seed the built-in PRNG in the random_shuffle algorithm, rendering it useless.
- Guruhood isn't good enough. Consider the seemingly simple task of creating a stack that works correctly with exceptions. It's extraordinarily difficult even for a guru.
- Language features interact in nonintuitive ways, producing a combinatorial explosion. For example, if you overload a function in a class, you don't have to use the scope resolution operator, and if you override a function, you don't have to use it either - but if you do both, you DO have to use the scope resolution operator or else you get a compile error!
Insofar as the new C++ standard adds stuff, instead of simplifying, this will only get worse. Since it's unreasonable to expect a new standard to remove features, the problem is unfixable. The result will be that programmers carve out their separate comfort zones, compiler vendors will not implement all features, and the monolithic C++ language will fragment into a Venn diagram of sublanguages. More so than today.I guess you never used HyperCard? It was a great RAD tool for the Mac.