While I do not put any backdoors in my code intentionally, I have the sufficient knowledge of the system to poke a few holes big enough for a full compromise
Seems to me those vulnerabilities should qualify as problems you address before you ship the product. I'll grant that some of these kinds of problems may have very low criticality -- for example, they may require physical access to the machine and unusual permissions, in which case you're probably screwed anyway -- but it doesn't sound like you're talking about that kind of scenario.
Basically you're talking about bugs. Just because it doesn't cause the machine to crash or set off alarms with your QA testers doesn't make it any less worthy of fixing.
It seems likely none of that is news to you, but somebody had to say it...
Yep, Zubrin really comes down hard on NASA, and rightly so. Be sure to read Zubrin's "Entering Space", too. It's a little more broadly scoped, but it's just as good.
Before I get the Automatic Microsoft Flame response, I say this with some rather unusual supporting evidence: Microsoft's Project Gotham is the most realistic game I've played. On one of the beat-the-clock tracks at the Very Hard level, I was falling short of the lap time required to close out the final level with a gold medal. After failing to make that lap time by thousandths of a second for many weeks in a row, I went to the Panoz road racing school at Road Atlanta for four days. (No, I didn't go because of the game, heh heh.)
I learned a lot at the school, and really hadn't given any thought to games or anything other than real driving. (That much racing is very exhausting.) I still had a few days off when I got home, so one morning I said what the hell and fired up the XBOX, and immediately nailed the lap 0.021 seconds faster than the gold medal time. I used the car control techniques which I had just learned at the school. Braking, cornering, the whole "friction circle" concept, all of it "feels" as if it applies exactly as it would in a real car. In fact, once you understand those principles, you can easily "sense" the difference betwen cars in Gotham unlike any other game I've ever played. You can fix a loss of control doing exactly what you'd do in a real car. (I wish they'd use that same engine for a bunch of racing games. I'd kill for an IMSA GTP Group-C era racing game using the Gotham engine...)
I'm not claiming I'm the best driver who has ever lived (far from it), but since then I've been to two more racing schools and a bunch of events, and I have probably 200 hours of road racing time under my belt now. From that perspective, I'll say I played a lot of GT3 at a friend's house and it's fun, but it isn't even a little bit realistic, sorry.
On the other hand, I can at least say that your original point stands -- we DO have a realistic driving sim out there -- Project Gotham.
Since it is a web app, I suspect that a complete lack of Internet connectivity would cause greater problems in using it than just not being able to download the new JVM...
Not every TCP/IP network is connected to the Internet. The same is true for web servers. At my office we have roughly 50 web servers that have never seen a single packet that originated outside the building...
Actually, wasn't the original title "Hack N Slash", then it got shortened to "Hack"? I think I read that somewhere back when I stumbled across some old version on a BBS in the 80's...
It's a niche Mac product. The question of profitability is a matter of scale. For a small company like Connectix, the Mac VPC product was undoubtedly a great success. For a monster like Microsoft, the same product would be a drop in the bucket -- an unnecessary distraction -- and knowing what I (unfortunately) do about how costs run up quickly in large corporations, it isn't unreasonable to consider that it might not be profitable at all.
If it was normal to receive source with binaries, nobody would really think twice about it. It's only seen as a bad thing because it's not what Microsoft does.
I do agree with your observations about the BSD code and it's usage in closed source, but the conclusion quoted above twists things around a bit. You should have said, "If it was normal to DELIVER source with binaries..."
NOBODY would have any problems RECEIVING source, not even the companies who refuse to deliver it. However, people and companies do perceive DELIVERING their source as a bad thing, and it has nothing to do with Microsoft -- it is primarily because nobody TRUSTS other people.
But as soon as warning labels start showing up, some of 'em will start to wonder what they're being warned about
Especially when the warning reads: Secured for your protection.
Or when a giant yellow and red sticker on the front proudly proclaims:
NEW! ADVANCED MAGIC-GATE MEDIA PROTECTION!
...leading the average buyer to assume this is some fantastic thing they can't live without. When the buyer doesn't know anything about what they're buying, it's SIMPLE to use the ancient secrets of the marketing vampires to put a "you must have this" spin on it. In a similar vein, I've actually met people who were excited about the "chance" to register their software. They think it's cool. Makes 'em feel important. They never stop to consider that it's no different than the guy at Radio Shack asking for their home address (I know, they stopped that).
I have a feeling we haven't seen the worst of this DRM problem yet.
The XBOX is a console, whether techies recognize it for a PC or not. There are several important standard operating procedures in that industry (which is NOT the PC software industry) which make this stunt and most of the replies to the article completely irrelevant.
First, a big part of console-based licensing is driven by the console manufacturer agreeing that the software in question furthers the console maker's needs, whether it be a simple question of content (remember Nintendo disallowing violent games?), or a question of reasonably standardized interfaces (I read an article about the Dance Dance Revolution guys having a hell of a time since their software required new hardware), or similar considerations. Clearly, Linux doesn't come anywhere close to being interesting to Microsoft from this perspective.
Second, an even bigger part of console-based licensing is royalty payments. Everything that gets licensed involves a kickback to the console maker for each unit sold. Since this XBOX Linux thing isn't intended to be sold for any sort of profit, it is safe to assume that the people behind this stunt are in no position to pay royalties.
Third, although I haven't seen them, it seems very likely that Microsoft's existing licensing rules explicitly prohibits things of this nature. Microsoft is king in both the operating system and language tools market. This would be such an obvious point for their lawyers to cover from day one that it doesn't even bear further discussion. After all, non-game uses for consoles isn't a new concept, and the Linux-on-XBOX speculation dates back to about three hours after Microsoft admitted the XBOX project even existed. Not to mention the fact that they've certainly studied the efforts to port Linux to other consoles. So, I feel certain that base was covered a long, long time ago.
Those three points pretty firmly put the whole question to rest, and the response wouldn't be any different if we were talking about Sony or Nintendo, because as I said, this is SOP in the console world, and precedents exist long before the XBOX was even a rumor.
Yeah, and we know that Microsoft would never sacrifice profits in order to put a competitor out of business.
The only reason your comment was moderated "insightful" is because it's anti-Microsoft.
They can't profit from a tiny handful of Mac guys buying a few copies of DOS. Sufficient demand doesn't exist to generate a profit. The production and support costs would instantly push it into the red. This isn't an elementary-school bake sale where profits are counted in cents, folks.
I don't disagree with your basic premise, but it isn't even remotely applicable here.
Not easily or conveniently. I find it's better to grab the shareware version of Tiny Personal Firewall (search shareware.com, version 2.x) then prevent Outlook from using anything but ports 25 and 110.
Not to mention a component model.
Unfortunately, that component model is based on a single, language enforced, object model. Which is fantastic if you think that everyone is going to code in C# for the next 20 years.
I missed this comment of yours earlier today.
Your assertion is totally false. IL itself happily supports a few quirky things which C# can't do -- for example, overloaded return types. They are very closely related by design, but they are not dependent on each other, and when there was a conflict, IL and the CLR won out.
There is nothing in the CLR or IL which is in any way C# specific. The relationship is completely in the opposite direction, and even then the dependencies are tenuous -- it would be pretty easy to compile C# directly into a regular non-.NET binary on any platform.
There just isn't anything overwhelmingly dependent in either C# or IL/CLR. Your statement is as ridiculous as me coming here and stating that CORBA is fantastic if you think everyone is going to code in Java for the next 20 years -- solely based on the fact that Java implementations exist.
Binary-level compatability is a strange term in this context, as.NET and Java work with a VM. IMHO a VM is basically a new word for an old thing, namely interpreters. The fact that there is some pseudo machine code in between doesn't change the fact that the compiled code does actually run on the processor, but runs on a virtual machine. That's no more binary compatible then Basic was in it's interpreter days.
Your statement reflects a couple of common misunderstandings. First of all, a VM is definitely not an interpreter. An interpreter is combining the work of a compiler and a runtime environment. Second, the.NET CLR is not a VM. A VM seeks to implement a hardware-like pseudo-processor. Conversely, the CLR's main goal in life (along with IL) is to compile code. IL is designed to describe an application to a JIT. It isn't designed to be executed directly. (And in the specific case of.NET IL versus the JVM, IL does a lot more.)
Binary compatability is therefore not at all a strange concept in this context.
Furthermore, the claim that using non-OOP for anything but simple utilities and command-line tools strikes me ass odd. C and C++ are suitable for OOP, OOP is a programming discipline, not a programming language.
I've done HUGE projects in non-OOP languages -- thousands of code files, hundreds of megs of executables (and tens of millions of dollars at stake). They would have been far more managable, easier to modify for later releases, and I believe just all around better products had OOP methodologies been an option at the time. Indeed, after encountering OOP (back when it was new) I found myself borrowing and "faking" OOP concepts when I used non-OOP languages. Conversely, there is no reason to not use OOP in the simpler examples, but I've also seen many simple programs over-engineered to death just for the sake of OOP purity.
Many people reject.NET outright because of the "taint" of Microsoft. Being less Microsoft-averse than the average/.er, I still find I am still increasingly suspicious of The Beast, and I have been really rooting for Mono. Indeed, if I could find a Linux that would install on my RAID-only machines without requiring me to become a Linux guru overnight, I would probably make some attempt to contribute. However, when viewed in a vacuum (especially a vacuum that excludes the horribly inaccurate and misleading marketing hype from MS itself) it's actually a pretty killer set of technologies and tools. It isn't perfect, but it's damned good.
Well,.NET doesn't help you here much unless you like C#'s OOP model. The class libraries are great, for their model of what OOP is, other models (like Objective-C, Smalltalk, C++, etc) have to either Change (into Managed C++, whatever Eiffel turned into, etc) or go away. Not forcing all object models into one mold does not equal ignoring OOP
I was responding to someone who was comparing C to C#. In that context, C#'s OOP support is fantastic compared to C...:)
Sandisk appears to have a mediocre rep when it comes to camera flash cards. They were nailed for misrepesenting the capcity of their media. After being busted, they pulled that stunt where they conveniently "redefined" what "they" mean by "megabyte".
I did a quick Google search but couldn't find any articles. It's out there, though; I ran into this when I was selecting media for my first digital camera about two years ago. Also I seem to remember certain on-line retailers showing a warning note with Sandisk media about this, ahem, "unusual" definition of megabyte.
Could be unrelated to the thread problem (sounds like it, from some of the other posts about frequent writes wearing the card out), but it might be worth considering.
I have a better conspiracy theory to offer the tinfoil-hat/armchair-lawyer community.
This is just a guess, but I would assume they have no intention of using this to kill off Mono. Rather, they seek to protect the.NET class hierarchy itself. Mono is focused on the underpinnings, not the "good stuff" on top that most people use to write real world applications. (I personally like underpinnings myself, but that's not where most programmers spend their days, these days.)
What I think might be happening is Microsoft is letting Ximian do all the hard work of getting stuff to work on Linux/Unix/Mac/whatever, but they're protecting the next layer up, where everything exists that makes a "Windows app" what it is -- think Office.
That way, when Mono is done (or at least usefully functional), they will have a lock on "the good stuff". They can advertise "You can run Office on Linux," and the catch will be, in order to do so, you first have to buy this "Windows for Linux" layer, which runs on top of Mono.
(Incidentally, this reminds me of a/. sig I saw recently: "Free, as in working for IBM without getting paid.")
Back up, most unix-ish C code can be compiled on any vaguely unix-like system with very little modification. I'd call that platform independence, wouldn't you?
Of course,.NET (and Java) seeks to provide binary-level compatability. No recompiling necessary. Not to mention support for a minor little thing we've thought up within the past twenty years -- OOP. Not to mention a component model. Oh yeah, and some half-decent security stuff. Starting to see the point?
(Don't get me wrong, I like C, but these days ignoring OOP for anything beyond simple utilities and command-line tools is just stupid.)
the central theme through the book is that of XML and web services, accurately reflecting their importance in the.net framework.
Except for the minor problem that web services are not a central theme of the.NET framework. They are there, and they are well supported, but the majority of the framework would work unchanged if they didn't exist or are not used.
I don't disagree that there is a practical limit. I've had similar thoughts before. I suppose we just disagree where that limit is. 1.7" x 1.4" x 3.3mm (the size of a typical CF card according to some Google searches) isn't much smaller than your ideal size, and they have the benefit of already existing.:)
Plus, if they became the standard, due to their high capacity and convenient form factor, I bet the prices would come down... prices are only high because the only common use is as camera "film" which is a very limited market compared to computer ownership.
Oh well, it's a pipe dream anyway. Dell is dropping the floppies because they're shaving pennies, not because they have any urge to make things better...:)
An 8MB CF card is equivalent to about 5.5 floppies, which will cost you about $3, making my example about 5x more expensive than a floppy. (2MB and 4MB cards are available, and the 5X multiplier seems to apply across the price range). However, a CF card is much smaller than a floppy (let alone FIVE floppies), should last a lot longer (1M+ writes), is far more durable, reads faster, and can be used in a wider variety of devices. And of course, has higher capacity.
Addtionally, unlike a ZIP drive, the drive itself could be used for a very wide array of storage sizes, making it superior to a ZIP drive. Also, drives are about the same price as floppy drives, whereas a ZIP drive still runs about $45.
To me a CF card makes a lot of sense as a standard alternative to floppies. There's more to it than just scrimping a few bucks.
Slashdot Mirror
Seems to me those vulnerabilities should qualify as problems you address before you ship the product. I'll grant that some of these kinds of problems may have very low criticality -- for example, they may require physical access to the machine and unusual permissions, in which case you're probably screwed anyway -- but it doesn't sound like you're talking about that kind of scenario.
Basically you're talking about bugs. Just because it doesn't cause the machine to crash or set off alarms with your QA testers doesn't make it any less worthy of fixing.
It seems likely none of that is news to you, but somebody had to say it...
Yep, Zubrin really comes down hard on NASA, and rightly so. Be sure to read Zubrin's "Entering Space", too. It's a little more broadly scoped, but it's just as good.
Before I get the Automatic Microsoft Flame response, I say this with some rather unusual supporting evidence: Microsoft's Project Gotham is the most realistic game I've played. On one of the beat-the-clock tracks at the Very Hard level, I was falling short of the lap time required to close out the final level with a gold medal. After failing to make that lap time by thousandths of a second for many weeks in a row, I went to the Panoz road racing school at Road Atlanta for four days. (No, I didn't go because of the game, heh heh.)
I learned a lot at the school, and really hadn't given any thought to games or anything other than real driving. (That much racing is very exhausting.) I still had a few days off when I got home, so one morning I said what the hell and fired up the XBOX, and immediately nailed the lap 0.021 seconds faster than the gold medal time. I used the car control techniques which I had just learned at the school. Braking, cornering, the whole "friction circle" concept, all of it "feels" as if it applies exactly as it would in a real car. In fact, once you understand those principles, you can easily "sense" the difference betwen cars in Gotham unlike any other game I've ever played. You can fix a loss of control doing exactly what you'd do in a real car. (I wish they'd use that same engine for a bunch of racing games. I'd kill for an IMSA GTP Group-C era racing game using the Gotham engine...)
I'm not claiming I'm the best driver who has ever lived (far from it), but since then I've been to two more racing schools and a bunch of events, and I have probably 200 hours of road racing time under my belt now. From that perspective, I'll say I played a lot of GT3 at a friend's house and it's fun, but it isn't even a little bit realistic, sorry.
On the other hand, I can at least say that your original point stands -- we DO have a realistic driving sim out there -- Project Gotham.
Not every TCP/IP network is connected to the Internet. The same is true for web servers. At my office we have roughly 50 web servers that have never seen a single packet that originated outside the building...
one click, BAM (barring any rights or security issues) Or barring a complete lack of Internet connectivity.
Actually, wasn't the original title "Hack N Slash", then it got shortened to "Hack"? I think I read that somewhere back when I stumbled across some old version on a BBS in the 80's...
It's a niche Mac product. The question of profitability is a matter of scale. For a small company like Connectix, the Mac VPC product was undoubtedly a great success. For a monster like Microsoft, the same product would be a drop in the bucket -- an unnecessary distraction -- and knowing what I (unfortunately) do about how costs run up quickly in large corporations, it isn't unreasonable to consider that it might not be profitable at all.
I do agree with your observations about the BSD code and it's usage in closed source, but the conclusion quoted above twists things around a bit. You should have said, "If it was normal to DELIVER source with binaries..."
NOBODY would have any problems RECEIVING source, not even the companies who refuse to deliver it. However, people and companies do perceive DELIVERING their source as a bad thing, and it has nothing to do with Microsoft -- it is primarily because nobody TRUSTS other people.
Especially when the warning reads: Secured for your protection.
Or when a giant yellow and red sticker on the front proudly proclaims:
NEW! ADVANCED MAGIC-GATE MEDIA PROTECTION!
I have a feeling we haven't seen the worst of this DRM problem yet.
First, a big part of console-based licensing is driven by the console manufacturer agreeing that the software in question furthers the console maker's needs, whether it be a simple question of content (remember Nintendo disallowing violent games?), or a question of reasonably standardized interfaces (I read an article about the Dance Dance Revolution guys having a hell of a time since their software required new hardware), or similar considerations. Clearly, Linux doesn't come anywhere close to being interesting to Microsoft from this perspective.
Second, an even bigger part of console-based licensing is royalty payments. Everything that gets licensed involves a kickback to the console maker for each unit sold. Since this XBOX Linux thing isn't intended to be sold for any sort of profit, it is safe to assume that the people behind this stunt are in no position to pay royalties.
Third, although I haven't seen them, it seems very likely that Microsoft's existing licensing rules explicitly prohibits things of this nature. Microsoft is king in both the operating system and language tools market. This would be such an obvious point for their lawyers to cover from day one that it doesn't even bear further discussion. After all, non-game uses for consoles isn't a new concept, and the Linux-on-XBOX speculation dates back to about three hours after Microsoft admitted the XBOX project even existed. Not to mention the fact that they've certainly studied the efforts to port Linux to other consoles. So, I feel certain that base was covered a long, long time ago.
Those three points pretty firmly put the whole question to rest, and the response wouldn't be any different if we were talking about Sony or Nintendo, because as I said, this is SOP in the console world, and precedents exist long before the XBOX was even a rumor.
The only reason your comment was moderated "insightful" is because it's anti-Microsoft.
They can't profit from a tiny handful of Mac guys buying a few copies of DOS. Sufficient demand doesn't exist to generate a profit. The production and support costs would instantly push it into the red. This isn't an elementary-school bake sale where profits are counted in cents, folks.
I don't disagree with your basic premise, but it isn't even remotely applicable here.
That's okk.
http://www.howstuffworks.com/stirling-engine.htm
Not easily or conveniently. I find it's better to grab the shareware version of Tiny Personal Firewall (search shareware.com, version 2.x) then prevent Outlook from using anything but ports 25 and 110.
I missed this comment of yours earlier today.
Your assertion is totally false. IL itself happily supports a few quirky things which C# can't do -- for example, overloaded return types. They are very closely related by design, but they are not dependent on each other, and when there was a conflict, IL and the CLR won out.
There is nothing in the CLR or IL which is in any way C# specific. The relationship is completely in the opposite direction, and even then the dependencies are tenuous -- it would be pretty easy to compile C# directly into a regular non-.NET binary on any platform.
There just isn't anything overwhelmingly dependent in either C# or IL/CLR. Your statement is as ridiculous as me coming here and stating that CORBA is fantastic if you think everyone is going to code in Java for the next 20 years -- solely based on the fact that Java implementations exist.
Your statement reflects a couple of common misunderstandings. First of all, a VM is definitely not an interpreter. An interpreter is combining the work of a compiler and a runtime environment. Second, the .NET CLR is not a VM. A VM seeks to implement a hardware-like pseudo-processor. Conversely, the CLR's main goal in life (along with IL) is to compile code. IL is designed to describe an application to a JIT. It isn't designed to be executed directly. (And in the specific case of .NET IL versus the JVM, IL does a lot more.)
Binary compatability is therefore not at all a strange concept in this context.
Furthermore, the claim that using non-OOP for anything but simple utilities and command-line tools strikes me ass odd. C and C++ are suitable for OOP, OOP is a programming discipline, not a programming language.
I've done HUGE projects in non-OOP languages -- thousands of code files, hundreds of megs of executables (and tens of millions of dollars at stake). They would have been far more managable, easier to modify for later releases, and I believe just all around better products had OOP methodologies been an option at the time. Indeed, after encountering OOP (back when it was new) I found myself borrowing and "faking" OOP concepts when I used non-OOP languages. Conversely, there is no reason to not use OOP in the simpler examples, but I've also seen many simple programs over-engineered to death just for the sake of OOP purity.
Many people reject .NET outright because of the "taint" of Microsoft. Being less Microsoft-averse than the average /.er, I still find I am still increasingly suspicious of The Beast, and I have been really rooting for Mono. Indeed, if I could find a Linux that would install on my RAID-only machines without requiring me to become a Linux guru overnight, I would probably make some attempt to contribute. However, when viewed in a vacuum (especially a vacuum that excludes the horribly inaccurate and misleading marketing hype from MS itself) it's actually a pretty killer set of technologies and tools. It isn't perfect, but it's damned good.
I was responding to someone who was comparing C to C#. In that context, C#'s OOP support is fantastic compared to C... :)
Unless I'm being trolled. ;)
I did a quick Google search but couldn't find any articles. It's out there, though; I ran into this when I was selecting media for my first digital camera about two years ago. Also I seem to remember certain on-line retailers showing a warning note with Sandisk media about this, ahem, "unusual" definition of megabyte.
Could be unrelated to the thread problem (sounds like it, from some of the other posts about frequent writes wearing the card out), but it might be worth considering.
This is just a guess, but I would assume they have no intention of using this to kill off Mono. Rather, they seek to protect the .NET class hierarchy itself. Mono is focused on the underpinnings, not the "good stuff" on top that most people use to write real world applications. (I personally like underpinnings myself, but that's not where most programmers spend their days, these days.)
What I think might be happening is Microsoft is letting Ximian do all the hard work of getting stuff to work on Linux/Unix/Mac/whatever, but they're protecting the next layer up, where everything exists that makes a "Windows app" what it is -- think Office.
That way, when Mono is done (or at least usefully functional), they will have a lock on "the good stuff". They can advertise "You can run Office on Linux," and the catch will be, in order to do so, you first have to buy this "Windows for Linux" layer, which runs on top of Mono.
(Incidentally, this reminds me of a /. sig I saw recently: "Free, as in working for IBM without getting paid.")
Just a thought.
Yeah, they're a lot deeper than Sun's, and look what happened...
Of course, .NET (and Java) seeks to provide binary-level compatability. No recompiling necessary. Not to mention support for a minor little thing we've thought up within the past twenty years -- OOP. Not to mention a component model. Oh yeah, and some half-decent security stuff. Starting to see the point?
(Don't get me wrong, I like C, but these days ignoring OOP for anything beyond simple utilities and command-line tools is just stupid.)
Except for the minor problem that web services are not a central theme of the .NET framework. They are there, and they are well supported, but the majority of the framework would work unchanged if they didn't exist or are not used.
Plus, if they became the standard, due to their high capacity and convenient form factor, I bet the prices would come down... prices are only high because the only common use is as camera "film" which is a very limited market compared to computer ownership.
Oh well, it's a pipe dream anyway. Dell is dropping the floppies because they're shaving pennies, not because they have any urge to make things better... :)
That's a troll, right? :)
I mean... really...
Addtionally, unlike a ZIP drive, the drive itself could be used for a very wide array of storage sizes, making it superior to a ZIP drive. Also, drives are about the same price as floppy drives, whereas a ZIP drive still runs about $45.
To me a CF card makes a lot of sense as a standard alternative to floppies. There's more to it than just scrimping a few bucks.