Is Microsoft's "cowboy spaghetti code culture" any different than the "cowboy spaghetti code culture" elsewhere? Most relevantly here, is it any different than the "cowboy spaghetti code culture" common in OSS? I see absolutely no sign of that. It's how programmers everywhere tend to operate when they know they can walk away from a mess instead of fixing it. Only the fear of being stuck with a pig, or some external kind of pressure (as at MS), causes 99% of programmers to design and code more responsibly. The other 1% do it because they know it's the right thing to do, but they remain a small minority.
This is ancient. Parasite Rex came out four years ago, received extensive media coverage (I heard about in on NPR), and describes many examples like this. What's news for you isn't necessarily news for nerds.
Speed might be a reason. I just happened to do a comparison of several programs (ZipGenius, TUGZip, IZArc, FilZip, and 7-Zip) yesterday. On the kinds of files I most often have to deal with, which are a couple of hundred MB worth of tarred/gzipped logs, IZArc was the fastest and 7-Zip was the slowest. That actually surprised me, because I had done a similar test a while back and ended up using 7-Zip for a while as a result. 7-Zip also had the unique distinction of being the only program in the group that required me to extract the files in two steps instead of one. I didn't actually test WinZip, but performance is one of the areas they claim to have improved and it could be a distinguishing factor vs. 7-Zip.
Would it be too ****ing hard for the editors who promote stories to the front page to at least ensure that it contains some mention of what the latest stupidly-named OSS project actually does? The whole point of advertising - what such stories really are - is to reach the not-already-converted, and that just doesn't work too well if the audience does not in fact know they're your audience.
Yes, I know the answer to my rhetorical question. Any semblance of usefulness is too hard for some people.
Re:Still a single point of failure
on
Basics of RAID
·
· Score: 1
Since a RAID controller doesn't have moving parts, is it less likely than a hard drive to fail?
Yes, and that's one of three reasons RAID has an advantage. The second, as someone else has pointed out, is that with RAID (except RAID-0 which isn't really RAID anyway) you might lose access (temporary) but don't lose your data (permanent). The third is that the RAID controller is only a single point of failure for crappy RAID implementations. Host-based RAID, whether in software or hardware, just totally sucks rocks compared to external RAID, and even low-end external disk arrays nowadays support dual controllers with separate power supplies etc. Mid- and high-end arrays also have a large non-volatile cache for a huge performance win because your writes only need to wait for memory and can be "destaged" to the back-end disks in an optimal order at the controller's leisure (the larger the cache, the more you can optimize the back-end traffic). Typically you also get nice things like snapshots, replication support, LUN masking and mapping, etc. Anybody who has ever used a real disk array knows it's a whole different world compared to the way a home user thinks about storage. Yes, it can be a lot more of a pain to set up, and it's often hellishly expensive (an enterprise-level disk array will cost you far more than anything you connect to it), but the level of performance, functionality and robustness is just light years beyond what you get with dumb disks and host-based RAID.
Disclaimer: I work in the storage industry, and have done so for quite a while. Make sure you don't confuse cause and effect, though. I don't say the technology's cool because I work with it; I work with it because it is cool.
I was going to plug lighttpd too, but it looks like you beat me to it. I did a bunch of tests of lesser-known web servers a while back, including lighttpd. It was among the easiest to get running, it performed well, it was the only one that scaled well as users were added, etc. I've used it at work several times to replace broken Apache instances included as part of a third-party package, and it has always worked like a champ. It's an excellent piece of software that I think deserves more recognition.
2) Memory protection through typesafety alone. Would give all computers a 30+% boost to performance if the security was handled by the compiler, and not the hardware.
Not possible, because you don't control what compilers other people use before they ship you their application/driver/whatever. The closest you can get is to check at install or load time (like Java's bytecode verifier) instead of run time, and there's still a lot of work to be done before that approach becomes useful for all kinds of programming and not just for the easy stuff. Does your favorite language have built-in support for the concept of multiple users extending variable privileges to each other? How is your compile- or load-time checker going to handle privilege changes during execution, or are you just going to slap on yet another pair of handcuffs and preclude that? Can you write a device driver in your "safe" language of choice, or will you need two different security models for different kinds of code (and very carefully manage transitions between them)?
Typesafe languages are great within a single application. When you get serious about trying to apply that approach at a system level, though, you run into some pretty nasty problems. It's not at all clear whether the necessary solutions to those problems are better than what we have now.
The way you started, I thought you were going to make a much more important point. Who cares if the government is spending all this money on propping up software prices? Well, I guess I do, but I care a hell of a lot more that the government is not spending that same money and devoting those same resources to dealing with real criminals who actually kill people. That seems like the real travesty here. No matter which side you're on with respect to software piracy, it just shouldn't be a higher priority than real security.
It only takes 30 minutes or so to custom build something that does exactly what you want it to, rather than spending probably hours configuring some bizarre conglomeration of weird things, that you'll then have to spend hours trying to figure out the code, if you have to make changes at that level.
Bull. I used to write all of the code for my own website. It probably took me about a week of full-time-equivalent work, and it worked OK, but that's still a far cry from half an hour. Don't give me any of that crap about it being because you're a better programmer, either. I work on kernels and distributed systems for a living, and have done for over a decade. Web programming is something I do as a break from real work because it's so easy by comparison. Nonetheless, all you can get in half an hour is something that sucks. If you want something that's modular and maintainable, that takes more time. If you want something that's database-efficient, that takes more time...and flat-file-based systems are even worse so don't go there. If you want something that's standards-compliant, that takes more time...and your main page generated 130 errors when I ran it through the W3C validator. If you want it not to look like crap (again unlike your site) that takes more time. If you want to have features like markup in comments and comment preview, decent archive management, categories, and search (again unlike...) that takes more time. If you want to do all of those things and have it be secure, that takes more time; not knowing how to implement features securely is a poor excuse for having a low-functionality site. Do all that in under the week it took me, and I'll be impressed. So far, not even close.
My guess, based on your comment, is that you're another victim of the rewrite bug that often afflicts junior programmers. Writing code is not necessarily more efficient than reading other people's, but it is generally more fun so kiddies always want to rewrite everything in sight. What they end up with isn't usually any better, though. Most code that's written as an excuse not to understand something that already existed sucks far worse than what it replaces. That's why most of the people who roll their own website never even have the balls to make the result available for others to see. They know that it's a lot easier to claim superiority than to prove it.
if you need some sort of "content management system" to power your website, you probably aren't the type of person who should be having a web site.
That's the most offensive thing about your post, and why I went out of my way to be offensive right back. Sure, maybe you and I can (with varying degrees of success) write code to do the things that a typical weblog does, but why should we be the only ones to have sites? Why shouldn't high-school students and grandmothers have them too? Sure, most of what they write is crap, but so is most of what geeks write (including here). What purpose is served by having someone who might be able to contribute code in some other domain that you know nothing about have to learn your most treasured skills as the price of entry to the world of website ownership? What if their contribution is something other than code - like scientific knowledge or political insight? Aren't those valuable too? Thinking that everyone should value what you value is beyond elitist, and contrary to the spirit of free enterprise. It's just a crutch for insecurity, not a valid or useful attitude. It's almost as pathetic as posting fake-IQ-test results to your blog.
First off, this isn't quite an example of a company suddenly deciding to donate stuff to the Archive. As can be seen on their own website, Capricorn was spun off from the Archive on July 1, 2004. To a large extent, Capricorn exists for the specific purpose of providing storage to the Archive, and if that same storage can be sold to others so much the better.
Second, what about interconnects and performance? The product descriptions say nothing about SCSI or FC or other storage-oriented connectivity, so one must assume that the connection to these boxes is through a network. That would mean each node is an NFS server (or similar), serving up 1.6TB using a 1GHz C3 processor, a maximum of 1GB of memory (for caching etc.) and what appears to be a single GigE link. Can you say unbalanced? The Internet Archive might be the only system with an access pattern so sparse that the ratio between capacity and performance wouldn't be crippling. Don't try using one of these with any other kind of application if performance is a concern...and BTW they don't seem to say anything about high availability or other storage functionality (e.g. integrated backup or snapshots) either. Capricorn's big play seems to be power consumption, but there are other players that can beat them on density (e.g. Copan with 224TB per rack) and multitudes who can offer better performance/functionality. I hate to sound negative, but this is a product so specialized as to be uninteresting.
Disclaimer: I think I met some of the Copan guys once and they seemed cool enough, but there's no other relationship between me and them. That just happened to be the first name I thought of in this space.
Some of these techniques are just plain old bizzare and might be way too difficult to approach algorithmically.
In order for a patent claim to be valid, a prototype must exist. Perhaps the most important word here is claim. There are two main parts of a patent: a description which is provided for purposes of explanation, and the claims which are the really important part. It's not uncommon for several patents to use the same description; last I knew, my previous employer was pursuing four patents on stuff I did, all using the same description. In other words, if you haven't looked at the claims you don't actually know what the patent's about. If there's something in the description that's not part of a claim, a prototype need not exist to prove the claim's validity.
The article (I refuse to call it a book) doesn't really even scratch the surface of what you need to know to do any serious reverse engineering. Yes, it covers some basics of things like debuggers and executable formats, but that's what man pages and header files are for. It doesn't even get as far as telling you how to tell you how to navigate through a simple dispatch table or loader stub, which are often used without any deliberate intent to obfuscate. If you want to tell people about true reverse engineering you should at least try to explain things like dynamically constructed dispatch tables, self-modifying code, and exception handlers used to implement on-the-fly decryption or decompression. Since the world has become so network-centric, a decent description of how to reverse-engineer protocols as well as code should also be considered a minimum requirement. Lacking all of these things, the cited article will leave the reader very little better off than they had been before in terms of actually puzzling out what something does or how it works.
The implementation for CPM/86 itself (copyright) was not copied, modified or distributed.
That's not as clear as you make it out to be, actually. The "look and feel" were certainly copied, and there are signs that the implementation was little more than a binary port from 8080/8085 to 8086/8088 code. Then there's the easter egg. Why would Tim Patterson put an easter egg into his own code that popped up Kildall's name and a copyright notice? Gary Kildall never sued, but that doesn't mean copyright violation did not occur. If SCP modified CP/M and distributed the result without a license allowing them to do so (which would have included the BSD license, to address the analogy to Linux vs. UNIX) then they were in the wrong.
More importantly, though, no matter how you slice it neither Patterson nor Gates invented much of anything. At best they had a clean but utterly unoriginal and strikingly similar implementation of functionality that already existed. Linus's implementation of a UNIX-like OS was original even if some of the concepts weren't, creating another point of distinction between the two cases, but it remains the case that both the AT&T and UCB groups did far more original work than he did. The whole structure that Linux uses of processes and memory spaces, pipes and signals, how drivers and filesystems etc. interact, and so on owe far more to their ingenuity than to his (and let's not forget Tanenbaum either). That doesn't mean they can lay claim to his original implementation, but let's give credit where credit is due. The whole point of Linux is that it's a collaborative effort, and those predecessors (unlike SCO) were an essential part of that effort. CP/M was not such an effort, was never intended to be, was not licensed as such, and so copies of CP/M at any level take on a very different character.
To use your own charming phrase, this is all so bloody obvious that only a total moron would question it. Instead of just being a prick, go educate yourself.
Are they really becoming "a business," i.e., a single monolithic entity?
Does it matter whether a monolithic or legal entity? Would it have made a difference if I'd said they're in business instead of a business? You're absolutely right that it's about the motivations of the invididual players...and it's about how those motivations are often misrepresented. Whether they work for one company or several, whether they compete or cooperate with one another, those individuals are driven by the same motivations as the proprietary programmers they often look down on. Many open-source programmers would switch to proprietary software in an instant under the right circumstances, and in the past many have done so. What keeps them in open source is often not their principles but the fact that their qualifications are tied to software that they've been able to work on because someone else allowed them to. They get more or better job offers to work on open source, so that's what they do.
If someone paid me to add particular features to Linux or Apache or Samba, would that make me a nobler person than someone who got paid to do equivalent work on closed-source competitors? The project would not be open source because of me, and my contributions wouldn't be open source because of me. In fact I've written code that was later open-sourced by IBM, but at the time I wrote it it was for profit and under contract and most proprietary. Did my contribution suddenly gain a new moral dimension when someone I never met decided to open-source it? If I were paid to work on it again because I know more about it than anyone else, would I get an Official Open Source Hero badge? No, I'd still be doing it for the same reasons as before, which are the same reasons that many professional Linux hackers do what they do. No better, no worse.
Why does the act of being paid to work on Free Software have anything to do with the moral argument of Free Software?
It doesn't affect the moral argument for free software in general, but it most certainly does affect how people portray their own role or motivations. A guy who makes money as a programmer, writer, and speaker on a topic should not be assumed to be doing so for any reason that wouldn't be familiar to Bill Gates. Many of these "top 25" have never shown any particular sign of ever having been less self-interested than anyone who works on proprietary systems. Linux just happened to be the project that satisfied their self-interest, for reasons that had to do with predecessors' generosity rather than their own. As I said, there's nothing wrong with that, but it doesn't create any moral high ground.
Just because money is being exchanged, does that mean your words become less convincing?
No, but it's one less reason why their opinions beyond the purely technical should not be considered any more convincing than anyone else's.
The article winds up by saying that Linux is in professional hands. Perhaps that's so, at least for the kernel(certainly less so than other OSS projects), but there is a flip side. To the exact same extent that the ranks of Linux hackers become more professional, they also become less able to claim altruism or objectivity. Somebody whose livelihood is tied up in promoting something simply cannot avoid self-interested bias when it comes to decisions about it or comparison to alternatives. I'm not saying that's a good thing or a bad thing, but it's reality. Anybody who wants to tout the "professionalization" of Linux had better be prepared to tone down some of the moralistic lecturing as well. They're becoming a business competing with other businesses, and that doesn't grant much moral high ground.
I definitely think they should teach ID in schools...as a case study in how to recognize pseudo-science. Many students don't know enough about falsifiability or Occam's Razor or whether they should work from premises to conclusions or vice versa. Let them compare and contrast the scientific basis of evolution vs. the intellectual muck that is ID, and their critical-thinking skills should improve significantly. Counterexamples can be useful things.
You may think of web application development as "web-wennie-world" if you want to, but you will only be limiting your own experience.
Would be, you mean, if I hadn't actually done web application development. I've done that, and I've done real programming, so I do know the difference. You apparently don't, or you wouldn't be arguing this point. Web application is a specialty more insulated than most from
Instead of providing a checklist, I'd suggest a mental approach to writing a design document. Consider who's going to be using your design - developers working on the piece you're designing, developers working on other nearby pieces, QA engineers, support, documentation, etc. Now, imagine you're in a room full of all those people and you have to explain/justify how the code is put together. For best results, imagine that the audience is just slightly hostile. Now, try to anticipate all of the questions they're going to have. Is somebody likely to suggest that you should have used a particular framework or technology? Explain why you did or didn't. Is there likely to be a performance weenie involved? Explain what you expect the performance to be under different kinds of load, and what will affect it. Security weenie? Explain what kinds of authentication/authorization will be involved. For anyone, explain what kind of diagnostic or debugging capabilities will be provided. Is there a particular kind of danger to which this type of program is particularly vulnerable (e.g. loss of connection for a network app, missed deadlines for A/V, data corruption for storage)? Explain what steps you're taking to prevent or ameliorate it. For extra credit, offer QA some ideas for testing difficult cases. If you do a good job anticipating what kinds of questions your constituents/reviewers should ask, you'll end up with a document that will not only sail through review but will actually be useful when it's all done.
Yeah, that will work really well for your device-driver design. What you describe sounds like a requirements document for a very narrow domain. Even in web-weenie-world a decent design document should address things like database usage and authentication, which your list omits. Try gaining experience beyond one role on one type of program before you try to tell other people about what makes a good design spec.
I've stuck with Google for a while, but I used to do surveys pretty often. My approach was to start preparing a couple of days in advance, by keeping notes about things I was searching for. Then I'd take three or four of them, usually the ones that I'd had the most trouble refining, and try them out on a bunch of search engines. For each, I'd keep track of how many searches I had to do and how many junk pages I had to get through before I could get to something useful on that subject. It usually became clear pretty quickly which search engines were allowing me to make efficient use of my time and which were wasting my time.
Another thing you might want to do is check out some of the newer "clustering" or "concept map" search engines such as Vivisimo or Kartoo, to see whether they suit your searching style better. They're really quite different from the search engines we've gotten used to, so the metrics I just described don't quite work for them. That doesn't mean they're better or worse - just different.
If C++ will run "shockingly better" that necessarily means it was shockingly bad to start with. It's like when Microsoft came out with FAT32 and claimed it would give you more usable space...but didn't go into the details of how they'd been pissing away your space before. "Yeah, we suck less!" Where's that eye-roll punctuation mark when I need it?
A social or economic tipping point is characterized by a sudden burst of mass sanity as mainstream public opinion abandons an unsustainable mythology in favor of something closer to reality.
It can also be a sudden burst of mass insanity as mainstream public opinion gets caught up in a new myth like the "new economy" of the dot-bomb era. Such a one-sided definition totally misses the point of how or why such change (for which "paradigm shift" was the previous buzzword) occurs.
Excuse me if I find that situation completely discountable in the real world.
Are you saying such "poorly coded" debuggers don't exist? Anybody who actually does any real programming knows that they do and that people are often stuck with them for other reasons (e.g. their being the only supported option on a platform they use). Maybe it's convenient for you to discount that, but it's not very rational.
And your thing about inlining creating costs is that the compiler *weighs* the cost, and does so better than humans.
Actually it doesn't. It can't possibly know how often an inline function is used in a large set of separately-compiled modules, let alone what effect the duplication might have on caches, and it can't undo the inlining when they're linked together if it guessed wrong. Compilers can make many decisions better than humans, but not - or at least not always - this one. Learn something about how compilers and computer systems work below the JavaScript level before you make your next claim about optimization.
Slashdot Mirror
Is Microsoft's "cowboy spaghetti code culture" any different than the "cowboy spaghetti code culture" elsewhere? Most relevantly here, is it any different than the "cowboy spaghetti code culture" common in OSS? I see absolutely no sign of that. It's how programmers everywhere tend to operate when they know they can walk away from a mess instead of fixing it. Only the fear of being stuck with a pig, or some external kind of pressure (as at MS), causes 99% of programmers to design and code more responsibly. The other 1% do it because they know it's the right thing to do, but they remain a small minority.
This is ancient. Parasite Rex came out four years ago, received extensive media coverage (I heard about in on NPR), and describes many examples like this. What's news for you isn't necessarily news for nerds.
Speed might be a reason. I just happened to do a comparison of several programs (ZipGenius, TUGZip, IZArc, FilZip, and 7-Zip) yesterday. On the kinds of files I most often have to deal with, which are a couple of hundred MB worth of tarred/gzipped logs, IZArc was the fastest and 7-Zip was the slowest. That actually surprised me, because I had done a similar test a while back and ended up using 7-Zip for a while as a result. 7-Zip also had the unique distinction of being the only program in the group that required me to extract the files in two steps instead of one. I didn't actually test WinZip, but performance is one of the areas they claim to have improved and it could be a distinguishing factor vs. 7-Zip.
Would it be too ****ing hard for the editors who promote stories to the front page to at least ensure that it contains some mention of what the latest stupidly-named OSS project actually does? The whole point of advertising - what such stories really are - is to reach the not-already-converted, and that just doesn't work too well if the audience does not in fact know they're your audience.
Yes, I know the answer to my rhetorical question. Any semblance of usefulness is too hard for some people.
Yes, and that's one of three reasons RAID has an advantage. The second, as someone else has pointed out, is that with RAID (except RAID-0 which isn't really RAID anyway) you might lose access (temporary) but don't lose your data (permanent). The third is that the RAID controller is only a single point of failure for crappy RAID implementations. Host-based RAID, whether in software or hardware, just totally sucks rocks compared to external RAID, and even low-end external disk arrays nowadays support dual controllers with separate power supplies etc. Mid- and high-end arrays also have a large non-volatile cache for a huge performance win because your writes only need to wait for memory and can be "destaged" to the back-end disks in an optimal order at the controller's leisure (the larger the cache, the more you can optimize the back-end traffic). Typically you also get nice things like snapshots, replication support, LUN masking and mapping, etc. Anybody who has ever used a real disk array knows it's a whole different world compared to the way a home user thinks about storage. Yes, it can be a lot more of a pain to set up, and it's often hellishly expensive (an enterprise-level disk array will cost you far more than anything you connect to it), but the level of performance, functionality and robustness is just light years beyond what you get with dumb disks and host-based RAID.
Disclaimer: I work in the storage industry, and have done so for quite a while. Make sure you don't confuse cause and effect, though. I don't say the technology's cool because I work with it; I work with it because it is cool.
I was going to plug lighttpd too, but it looks like you beat me to it. I did a bunch of tests of lesser-known web servers a while back, including lighttpd. It was among the easiest to get running, it performed well, it was the only one that scaled well as users were added, etc. I've used it at work several times to replace broken Apache instances included as part of a third-party package, and it has always worked like a champ. It's an excellent piece of software that I think deserves more recognition.
Not possible, because you don't control what compilers other people use before they ship you their application/driver/whatever. The closest you can get is to check at install or load time (like Java's bytecode verifier) instead of run time, and there's still a lot of work to be done before that approach becomes useful for all kinds of programming and not just for the easy stuff. Does your favorite language have built-in support for the concept of multiple users extending variable privileges to each other? How is your compile- or load-time checker going to handle privilege changes during execution, or are you just going to slap on yet another pair of handcuffs and preclude that? Can you write a device driver in your "safe" language of choice, or will you need two different security models for different kinds of code (and very carefully manage transitions between them)?
Typesafe languages are great within a single application. When you get serious about trying to apply that approach at a system level, though, you run into some pretty nasty problems. It's not at all clear whether the necessary solutions to those problems are better than what we have now.
The way you started, I thought you were going to make a much more important point. Who cares if the government is spending all this money on propping up software prices? Well, I guess I do, but I care a hell of a lot more that the government is not spending that same money and devoting those same resources to dealing with real criminals who actually kill people. That seems like the real travesty here. No matter which side you're on with respect to software piracy, it just shouldn't be a higher priority than real security.
Bull. I used to write all of the code for my own website. It probably took me about a week of full-time-equivalent work, and it worked OK, but that's still a far cry from half an hour. Don't give me any of that crap about it being because you're a better programmer, either. I work on kernels and distributed systems for a living, and have done for over a decade. Web programming is something I do as a break from real work because it's so easy by comparison. Nonetheless, all you can get in half an hour is something that sucks. If you want something that's modular and maintainable, that takes more time. If you want something that's database-efficient, that takes more time...and flat-file-based systems are even worse so don't go there. If you want something that's standards-compliant, that takes more time...and your main page generated 130 errors when I ran it through the W3C validator. If you want it not to look like crap (again unlike your site) that takes more time. If you want to have features like markup in comments and comment preview, decent archive management, categories, and search (again unlike...) that takes more time. If you want to do all of those things and have it be secure, that takes more time; not knowing how to implement features securely is a poor excuse for having a low-functionality site. Do all that in under the week it took me, and I'll be impressed. So far, not even close.
My guess, based on your comment, is that you're another victim of the rewrite bug that often afflicts junior programmers. Writing code is not necessarily more efficient than reading other people's, but it is generally more fun so kiddies always want to rewrite everything in sight. What they end up with isn't usually any better, though. Most code that's written as an excuse not to understand something that already existed sucks far worse than what it replaces. That's why most of the people who roll their own website never even have the balls to make the result available for others to see. They know that it's a lot easier to claim superiority than to prove it.
That's the most offensive thing about your post, and why I went out of my way to be offensive right back. Sure, maybe you and I can (with varying degrees of success) write code to do the things that a typical weblog does, but why should we be the only ones to have sites? Why shouldn't high-school students and grandmothers have them too? Sure, most of what they write is crap, but so is most of what geeks write (including here). What purpose is served by having someone who might be able to contribute code in some other domain that you know nothing about have to learn your most treasured skills as the price of entry to the world of website ownership? What if their contribution is something other than code - like scientific knowledge or political insight? Aren't those valuable too? Thinking that everyone should value what you value is beyond elitist, and contrary to the spirit of free enterprise. It's just a crutch for insecurity, not a valid or useful attitude. It's almost as pathetic as posting fake-IQ-test results to your blog.
First off, this isn't quite an example of a company suddenly deciding to donate stuff to the Archive. As can be seen on their own website, Capricorn was spun off from the Archive on July 1, 2004. To a large extent, Capricorn exists for the specific purpose of providing storage to the Archive, and if that same storage can be sold to others so much the better.
Second, what about interconnects and performance? The product descriptions say nothing about SCSI or FC or other storage-oriented connectivity, so one must assume that the connection to these boxes is through a network. That would mean each node is an NFS server (or similar), serving up 1.6TB using a 1GHz C3 processor, a maximum of 1GB of memory (for caching etc.) and what appears to be a single GigE link. Can you say unbalanced? The Internet Archive might be the only system with an access pattern so sparse that the ratio between capacity and performance wouldn't be crippling. Don't try using one of these with any other kind of application if performance is a concern...and BTW they don't seem to say anything about high availability or other storage functionality (e.g. integrated backup or snapshots) either. Capricorn's big play seems to be power consumption, but there are other players that can beat them on density (e.g. Copan with 224TB per rack) and multitudes who can offer better performance/functionality. I hate to sound negative, but this is a product so specialized as to be uninteresting.
Disclaimer: I think I met some of the Copan guys once and they seemed cool enough, but there's no other relationship between me and them. That just happened to be the first name I thought of in this space.
In order for a patent claim to be valid, a prototype must exist. Perhaps the most important word here is claim. There are two main parts of a patent: a description which is provided for purposes of explanation, and the claims which are the really important part. It's not uncommon for several patents to use the same description; last I knew, my previous employer was pursuing four patents on stuff I did, all using the same description. In other words, if you haven't looked at the claims you don't actually know what the patent's about. If there's something in the description that's not part of a claim, a prototype need not exist to prove the claim's validity.
The article (I refuse to call it a book) doesn't really even scratch the surface of what you need to know to do any serious reverse engineering. Yes, it covers some basics of things like debuggers and executable formats, but that's what man pages and header files are for. It doesn't even get as far as telling you how to tell you how to navigate through a simple dispatch table or loader stub, which are often used without any deliberate intent to obfuscate. If you want to tell people about true reverse engineering you should at least try to explain things like dynamically constructed dispatch tables, self-modifying code, and exception handlers used to implement on-the-fly decryption or decompression. Since the world has become so network-centric, a decent description of how to reverse-engineer protocols as well as code should also be considered a minimum requirement. Lacking all of these things, the cited article will leave the reader very little better off than they had been before in terms of actually puzzling out what something does or how it works.
Only to someone who never learned about scope. Treating global scope as the most "natural" is the hallmark of a terrible programmer.
That's not as clear as you make it out to be, actually. The "look and feel" were certainly copied, and there are signs that the implementation was little more than a binary port from 8080/8085 to 8086/8088 code. Then there's the easter egg. Why would Tim Patterson put an easter egg into his own code that popped up Kildall's name and a copyright notice? Gary Kildall never sued, but that doesn't mean copyright violation did not occur. If SCP modified CP/M and distributed the result without a license allowing them to do so (which would have included the BSD license, to address the analogy to Linux vs. UNIX) then they were in the wrong.
More importantly, though, no matter how you slice it neither Patterson nor Gates invented much of anything. At best they had a clean but utterly unoriginal and strikingly similar implementation of functionality that already existed. Linus's implementation of a UNIX-like OS was original even if some of the concepts weren't, creating another point of distinction between the two cases, but it remains the case that both the AT&T and UCB groups did far more original work than he did. The whole structure that Linux uses of processes and memory spaces, pipes and signals, how drivers and filesystems etc. interact, and so on owe far more to their ingenuity than to his (and let's not forget Tanenbaum either). That doesn't mean they can lay claim to his original implementation, but let's give credit where credit is due. The whole point of Linux is that it's a collaborative effort, and those predecessors (unlike SCO) were an essential part of that effort. CP/M was not such an effort, was never intended to be, was not licensed as such, and so copies of CP/M at any level take on a very different character.
To use your own charming phrase, this is all so bloody obvious that only a total moron would question it. Instead of just being a prick, go educate yourself.
Does it matter whether a monolithic or legal entity? Would it have made a difference if I'd said they're in business instead of a business? You're absolutely right that it's about the motivations of the invididual players...and it's about how those motivations are often misrepresented. Whether they work for one company or several, whether they compete or cooperate with one another, those individuals are driven by the same motivations as the proprietary programmers they often look down on. Many open-source programmers would switch to proprietary software in an instant under the right circumstances, and in the past many have done so. What keeps them in open source is often not their principles but the fact that their qualifications are tied to software that they've been able to work on because someone else allowed them to. They get more or better job offers to work on open source, so that's what they do.
If someone paid me to add particular features to Linux or Apache or Samba, would that make me a nobler person than someone who got paid to do equivalent work on closed-source competitors? The project would not be open source because of me, and my contributions wouldn't be open source because of me. In fact I've written code that was later open-sourced by IBM, but at the time I wrote it it was for profit and under contract and most proprietary. Did my contribution suddenly gain a new moral dimension when someone I never met decided to open-source it? If I were paid to work on it again because I know more about it than anyone else, would I get an Official Open Source Hero badge? No, I'd still be doing it for the same reasons as before, which are the same reasons that many professional Linux hackers do what they do. No better, no worse.
It doesn't affect the moral argument for free software in general, but it most certainly does affect how people portray their own role or motivations. A guy who makes money as a programmer, writer, and speaker on a topic should not be assumed to be doing so for any reason that wouldn't be familiar to Bill Gates. Many of these "top 25" have never shown any particular sign of ever having been less self-interested than anyone who works on proprietary systems. Linux just happened to be the project that satisfied their self-interest, for reasons that had to do with predecessors' generosity rather than their own. As I said, there's nothing wrong with that, but it doesn't create any moral high ground.
No, but it's one less reason why their opinions beyond the purely technical should not be considered any more convincing than anyone else's.
The article winds up by saying that Linux is in professional hands. Perhaps that's so, at least for the kernel(certainly less so than other OSS projects), but there is a flip side. To the exact same extent that the ranks of Linux hackers become more professional, they also become less able to claim altruism or objectivity. Somebody whose livelihood is tied up in promoting something simply cannot avoid self-interested bias when it comes to decisions about it or comparison to alternatives. I'm not saying that's a good thing or a bad thing, but it's reality. Anybody who wants to tout the "professionalization" of Linux had better be prepared to tone down some of the moralistic lecturing as well. They're becoming a business competing with other businesses, and that doesn't grant much moral high ground.
I definitely think they should teach ID in schools...as a case study in how to recognize pseudo-science. Many students don't know enough about falsifiability or Occam's Razor or whether they should work from premises to conclusions or vice versa. Let them compare and contrast the scientific basis of evolution vs. the intellectual muck that is ID, and their critical-thinking skills should improve significantly. Counterexamples can be useful things.
Welcome to Slashdot. I see you're new here.
Would be, you mean, if I hadn't actually done web application development. I've done that, and I've done real programming, so I do know the difference. You apparently don't, or you wouldn't be arguing this point. Web application is a specialty more insulated than most from
Instead of providing a checklist, I'd suggest a mental approach to writing a design document. Consider who's going to be using your design - developers working on the piece you're designing, developers working on other nearby pieces, QA engineers, support, documentation, etc. Now, imagine you're in a room full of all those people and you have to explain/justify how the code is put together. For best results, imagine that the audience is just slightly hostile. Now, try to anticipate all of the questions they're going to have. Is somebody likely to suggest that you should have used a particular framework or technology? Explain why you did or didn't. Is there likely to be a performance weenie involved? Explain what you expect the performance to be under different kinds of load, and what will affect it. Security weenie? Explain what kinds of authentication/authorization will be involved. For anyone, explain what kind of diagnostic or debugging capabilities will be provided. Is there a particular kind of danger to which this type of program is particularly vulnerable (e.g. loss of connection for a network app, missed deadlines for A/V, data corruption for storage)? Explain what steps you're taking to prevent or ameliorate it. For extra credit, offer QA some ideas for testing difficult cases. If you do a good job anticipating what kinds of questions your constituents/reviewers should ask, you'll end up with a document that will not only sail through review but will actually be useful when it's all done.
Yeah, that will work really well for your device-driver design. What you describe sounds like a requirements document for a very narrow domain. Even in web-weenie-world a decent design document should address things like database usage and authentication, which your list omits. Try gaining experience beyond one role on one type of program before you try to tell other people about what makes a good design spec.
I've stuck with Google for a while, but I used to do surveys pretty often. My approach was to start preparing a couple of days in advance, by keeping notes about things I was searching for. Then I'd take three or four of them, usually the ones that I'd had the most trouble refining, and try them out on a bunch of search engines. For each, I'd keep track of how many searches I had to do and how many junk pages I had to get through before I could get to something useful on that subject. It usually became clear pretty quickly which search engines were allowing me to make efficient use of my time and which were wasting my time.
Another thing you might want to do is check out some of the newer "clustering" or "concept map" search engines such as Vivisimo or Kartoo, to see whether they suit your searching style better. They're really quite different from the search engines we've gotten used to, so the metrics I just described don't quite work for them. That doesn't mean they're better or worse - just different.
If C++ will run "shockingly better" that necessarily means it was shockingly bad to start with. It's like when Microsoft came out with FAT32 and claimed it would give you more usable space...but didn't go into the details of how they'd been pissing away your space before. "Yeah, we suck less!" Where's that eye-roll punctuation mark when I need it?
It can also be a sudden burst of mass insanity as mainstream public opinion gets caught up in a new myth like the "new economy" of the dot-bomb era. Such a one-sided definition totally misses the point of how or why such change (for which "paradigm shift" was the previous buzzword) occurs.
Are you saying such "poorly coded" debuggers don't exist? Anybody who actually does any real programming knows that they do and that people are often stuck with them for other reasons (e.g. their being the only supported option on a platform they use). Maybe it's convenient for you to discount that, but it's not very rational.
Actually it doesn't. It can't possibly know how often an inline function is used in a large set of separately-compiled modules, let alone what effect the duplication might have on caches, and it can't undo the inlining when they're linked together if it guessed wrong. Compilers can make many decisions better than humans, but not - or at least not always - this one. Learn something about how compilers and computer systems work below the JavaScript level before you make your next claim about optimization.