OK, I just have to get this out of my system first: web design is stressful? Try real programming some time. There, I feel better now.;-)
Whenever I start hating my job, I think about how the non-techie population lives - and how I lived, once.
I work in a nice air-conditioned office. I know the AC is there for the machines, but I get to come along for the ride. I don't have to work outside on rainy days, or worry about sunburn on sunny ones.
I sit in a chair, stare at a monitor and type if I'm in my office or stare at other people and talk if I'm in a meeting. My job doesn't leave me physically tired and sore at the end of the day. The chances of physical injury are extremely low.
I have flex time. If I'm fifteen minutes late to work, it's likely that nobody will even notice let alone care. If I have to run errands or stay home to wait for a plumber I can just do it without having to make special arrangements.
I'm very lightly supervised. I'm accountable for results, not time on task. Nobody's watching over my shoulder to make sure I'm working every minute. If I want to take fifteen minutes to chat with a coworker about the latest gadget, or go out behind the parking lot and watch birds for half an hour, nobody cares.
Relatively speaking, I make a ton of money. Believe me, not having enough money to pay the rent creates its own kind of stress. So does worrying about how to pay for kids going to college, or for retirement. As it is, the money I make allows me to surround myself with nice stuff at home and go on neat vacations, and I'll probably be retiring early.
I get to work with smart people. If you've ever worked with a bunch of dullards you know how much of a difference that can make.
Sure, my job can be frustrating. The technical challenges are the least of it; sometimes I think Sarte ("hell is other people") was right. When I start getting annoyed, though, I try to think of what it would really be like to have another kind of job - working on an assembly line, delivering packages for FedEx, picking up trash,... no, thanks. Even the cushy-seeming jobs (doctor, lawyer, stockbroker) and the "fun" jobs (ski instructor, river guide) have their own trials and tribulations. They call it work for a reason. If you really think about it, working in high tech is about as close to a perfect job as you can reasonably expect.
Have you ever worked on an enterprise network? Or just sit home on your windows LAN?
If you were really that bright, you wouldn't be asking. What I do is right on my website, which is linked from here. You, on the other hand, hide behind the cloak of anonymous cowardice, from which any idiot can claim any credentials (and often does) without fear of contradiction. Not only have I worked on enterprise networks, but I'm currently active in defining and implementing new functionality for storage networks which are, if anything, more challenging than the IP kind. What can you prove that you have done? The phrase "diddly squat" comes to mind. You disrespect Jericho et al by asking "what have they done since then" but your own visible contributions are even less.
Go away, troll. You're bothering the people who build your toys.
Looks like someone's fragile little ego got stepped on. "What have they done since then" and "there takes skill in a real intrusion" are the tipoffs that we're probably dealing with a 16-year-old who think computing began with him - yeah, almost inevitably him, sorry but that's the way it is in that community and I had to pick a pronoun. Here's a clue for you, kid. Cracking might not take zero skill, but it's still absolutely nothing compared to the difficulty of actually creating the systems you crack, or the tools you use on either side of the security fence. Reality puts up a lot more obstacles than any number of white hats, black hats, or any other color hats. Raven - who can obviously take care of herself and doesn't need my help defending her or other female hackers - offers some excellent advice that I can only second:
To aspiring hackers, Alder has this piece of advice: "Learn TCP/IP or the internals of your operating system of choice. Ideally, learn both. Don't just be a script-kiddie who downloads an attack program off the Internet and think that's cool.
"Understanding what you're doing is more cool. Having the know-how to develop a new and innovative attack or to develop a creative defence is a lot more impressive than 'dude, I sniffed your Hotmail password'."
I hope that they've made some vast improvements or they're gonna have some serious issues feeding that beast. Systems now, even the Opteron which is among the better mem controllers around for a commodity processor, still have issues with wait states.
It's interesting that you should mention that, because one of the early multi-threaded processors (at Tera) was specifically designed to solve that problem. The theory was, and still is, that if one thread has to stall it's OK because there are still plenty of others that can keep running from cache. So no, you won't have N threads all running without waits and yielding N threads' worth of performance, but you'll still have enough live threads to give you more performance than you'd have with a single-threaded core.
Only time will tell which way it will really go. Most likely, there will be some workloads on which this approach works extremely well, some on which it provides no benefit, and a few on which you would have been better off with a "fat" single-thread CPU design. One thing to remember is that if the system has X threads, cache pollution and memory bandwidth are going to be problems either way. The fact that the multi-thread processor can still get some work done on some threads even while others are blocked waiting for memory will probably allow it to maintain an advantage over a faster single-thread processor that blocks completely more often.
Re: Everything, including tools, in moderation!
on
UML Fever
·
· Score: 4, Insightful
When the design finally fails because you were missing something, the egotistical designer then blames the method.
...and when the method fails the snake-oil salesmen blame the implementation of that method. UML bigots are exactly like Extreme Programming bigots; they believe the tool is a panacea, so any failure when using it must be the result of not using it properly. It's a great way to count all the hits and ignore all the misses, and for people who couldn't make a buck by selling drawing programs as drawing programs to make a buck by selling them as something much grander.
I have no interest in pushing UML tools...I'm an OO consultant
Those two statements are inconsistent.
teaching to use the right tool for the job.
Obviously not.
If you process level is so "low" that UML -- not even talking about an UML tool -- is out of scope for you... then we simply speak different languages here.
Ahhh, another gratuitous insult. You're the one who started with the condescending attitude, buddy. Don't whine when it rebounds on you. Our process level is doing just fine, and you have NO EVIDENCE that you could improve our productivity one iota. Any so-called "mentor" or consultant who came across as such an arrogant prick would get shown the door pretty quickly in any real-world business environment, and you'd know that if you really had any of the experience you claim.
Once again, this was about diagramming/flowcharting tools, not code generation. What part of "in terms of diagramming" are you having trouble with? Do you speak English? Do you understand the concept of a qualifying phrase?
A UML tool can do two things a simple diagramming tool can't:
* generate source code
* reverse engineer source code
The poster wasn't asking about source-code generators. He was asking about diagrams. In terms of diagrams the UML-oriented tools are no better than simple alternatives, even if they offer other features as well. Is a text editor no good just because it's not a full-blown IDE? Not if you just want to edit text.
Furthermore: how much time do you spend analizing? How much time designing? How much time coding?
You sound as if you would analyze/design one week and code after that 6 weeks. So you spend in total 7 weeks.
You have absolutely no basis for that self-serving assumption. FYI, I'm the chief software architect at my company, with technical oversight for the work of 30-some engineers, and that work seems to be going rather well. Don't expect me to be intimidated by your empty claims.
With an aditional 3 days of testing I made a 24 days sprint where you made a ~49 days coding marathon.
I haven't had to do a 24-day "sprint" for years. Anybody who does screwed up earlier in the process. Of course you push UML tools because you have a business interest in doing so; maybe you should have skipped that dozenth UML class and taken an ethics class instead.
I've tried a lot of the fancy UML tools, but they're really not any better than a very simple drawing program. The purpose of a diagram is to convey information. For that purpose simpler is usually better, and a diagram that uses too many specialized symbols to denote subtle nuances is not simple; that stuff should be described in the text. Maybe a case can be made for the extra symbology in a class diagram, but not in a flowchart or timeline. If your flowchart has more than about twenty items, or more than four types of items, or can't be drawn without crossing lines, it needs to be broken apart into a top-level flow and separate diagrams for secondary flows. Any simple box-and-line drawing program should be able to handle that, though a little bit of intelligence in routing lines doesn't hurt. Focus on the information, not the tools.
A CPU is controlled by a set of registers and the contents of a stack, even if you virtualize those things (JVM, smalltalk,.NET,...) and give them access controls you still have a system that is subject to massive failure once a single part of the system falls.
Not really. The only potential for system failure should be if the entity - e.g. an OS kernel - controlling and coordinating the others fails. For that very reason, that entity should be as simple and bulletproof as possible, providing nothing but virtualization and communication between the virtualized parts of the system. If any of those other components fails, it should at the worst cause a partial loss of functionality (ideally it should be recoverable) and should not be capable of killing the whole system. That's the basis for microkernel architecture. Microkernels are in disrepute right now, primarily because of performance concerns that some (e.g. Linus Torvalds) have made out to be far worse than they really are. Sure, there were some slow microkernels Back In The Day, but only a fool dismisses an idea based on a flawed implementation and that's what seems to have happened in this case. It's possible to implement a fast microkernel-based system. Put a bunch of them together in a network (microkernels are also more inherently compatible with transparent distribution BTW) and you'd have a system that's much more robust than one based on monolithic kernels. Even if you did lose a little bit of performance in the process, it's always worth remembering that your performance is zero while a critical resource is down. Count transactions per month, not per second.
I'm frankly sick of architects (that's the term for people who say they design software but don't actually design software) who bemoan the gap between their glorious visions and the real products their teams end up producing. These people need to click "Close" on their UML models and go get their hands dirty by writing parts of the production code. Then they'll understand the real-world constraints that their codeless design didn't account for, like internationalization, performance bottlenecks, user authentication, heterogenous networked environments, and ACID transaction support (to name the first few).
While I generally agree with your point and have spent a great deal of my own time and energy over the years ranting in much the same way about reality-free architects, I think you also need to consider the other side of the story. Just as you get tired of architects who stay up at the 30,000 foot level and never come to earth to code, architects get tired of programmers who are grubbing around in the dirt and refuse to look at how their little piece affects the whole. Any project of significant complexity needs people working at both high and low conceptual levels. A message-formatting module might be important, for example, but still a small part of the overall design. It shouldn't consume huge amounts of (human or machine) resources, or drive interface definitions throughout the rest of the system, but all too often the guy writing the message-formatting module acts like it's The Only Thing That Matters. It's an architect's job to remind such people that there are other things that matter too. There are other modules, and other considerations, and of course the features that users need and developers occasionally forget. Some of those considerations, like security or performance, are of immediate concern to developers, while others involve different constituencies.
No you can't do it that way, the architect has to say, because it complicates recovery or doubles the number of scenarios QA has to test or requires an overhaul to the documentation or leaves our support people hanging as they try to explain a weird program limitation to an unsympathetic customer. Of course the person who just wants to get their one piece done doesn't like to hear that, and they go off grumbling about architects who don't understand how hard it is to write a decent message-formatting module. Screw 'em. Somebody has to look out for how all the pieces will eventually fit together or else you end up with a dozen brilliantly-coded modules that don't work together. Been there, done that, seen projects and companies fail because of it. Yes, there are reality-free architects who spend way too much time with their nose stuck in the latest $10K piece of UML-diagramming junk and don't have Clue One about how anything actually works. Maybe they're even the majority of architects, and every one of them should be shot (except that shooting's too quick). However, there are also architects who can code as well as anyone else on their team in any of a half-dozen languages, and who would love to prove it day in or day out, but who end up being architects because they're the only ones on their team who can do anything but code. More projects fail due to a lack of architecture than due to an excess of it.
Looks like the US Air Force's Rome Air Development Center thinks they have a patent on it. Am I the only one who thinks "United States of America as represented by the Secretary of the Air Force" should not be a valid patent assignee?
Is it just me, or does it seem a little odd to other people that several of the principals listed on their web page (including the CTO) remain anonymous? Why the heck would anyone do that? Most companies at this stage splash the identities of their principals everywhere. These guys must have some pretty bad skeletons in their closet to hide like this.
You can't steal what is freely given. The distinction between quoting with and without attribution, which you fail to make, is also important. Much of what's written on blogs is deliberately put into the public domain, with a clear desire on the authors' part to see it get broader distribution. Many bloggers obsessively track who's linking or responding to them, or how they stand on the various blogger rankings, or where they are on Google's list of hits for particular pet terms. It's a universal enough phenomenon that it's the exceptions - the people who do not want their material used elsewhere - who should be required to identify themselves. The default assumption, which mirrors copyright law, should be that if someone made a concrete effort to publish and didn't make an effort to limit the scope of that publication then it's public domain.
I was part of this ''multiskilling" fad, and was employed to do prepress work. It's my passion, and I love it. I find dealing with people stressful.
Your example sounds like someone set a ridiculously high bar for social interaction, but "don't be a total flaming dickhead" is a low one. It's the social equivalent of writing hello.c and if someone can't do even that much then they don't deserve to get hired anywhere. Not even at Mall-Wart. Everyone has to deal with someone, even if it's only their boss, and they need a modicum of skill to do that. While it might be unreasonable to expect that people have (and exercise) too many different skills, requiring that people behave like adults is perfectly sensible and the sad truth is that many OSS "luminaries" (Al Viro is the clearest example) fail that test.
Think about it: this is a situation where people were actively encouraged to write buggy code! Finally, a way to harness the unique talents of the average Slashdotter.
Most of the shares are owned by individuals through:
1. pension funds
2. 401k plans
3. mutual funds
Owned by? Yes. Controlled by? No. The big mutual-fund managers read exactly the same business articles or books and make exactly the same decisions as the people who run endowments and foundations. They all think outsourcing is great. They don't much care that the people who lose jobs to outsourcing are their very own customers because that effect won't be felt until they personally are long gone. All they want to do is pump up the price on their fund according to whatever MBA mania is sweeping the financial sector that week, then retire and let others deal with the mess they've made. The fund managers exercise investors' proxy votes in their own best interest; the number of people who own stock directly and can therefore cast their own votes is relatively small.
Unfortunately, astroturf is common on Amazon. I've long known and tracked one author (Robert Stanek) who has written dozens of glowing reviews for his own incredibly-bad books, and adds reviews of other books "casually" mentioning himself in the company of Tolkien or Martin. He even Googles regularly for comments about himself elsewhere, which is how I found him on my own site once, trying to discredit me because I had written about his unethical behavior. I recently noticed another example, where an excellent book by Charles Perkins got several identically 40-column-formatted slag reviews in quick succession - probably an author or publisher of a competing book.
The problem is that it's too easy to establish multiple identities on Amazon. It would be trivial for me to create a hundred identities and use them to have a significant effect on the ratings of books I like or dislike. ..and you'd better believe I'd be less obvious about it than Stanek. Any claim Amazon might make about policing such abuse is a joke. Let's face it, folks: anywhere that online identities can be created basically out of thin air, fraud will be rampant. Yeah, that means Slashdot too. Pseudonymity is great, but anonymity is too often a cloak for abusers.
The accusation of bias at the end does open source no credit; someone writing for O'Reilly could be accused of bias as easily as someone writing for DevX. Stone would have done better to leave that out, and read one of the advocacy FAQs instead. DevX itself hosts a better rebuttal than his.
Checksums aren't sufficient. Where are you getting the MD5 to check against? From the same server the attacker would have compromised to modify the tarball you just downloaded? Do I need to explain what's wrong with that? To protect against a server compromise and subsequent source-code exploit, the source needs to be signed with something the attacker cannot find on that server and you as the recipient need to be capable of verifying that signature. Fat chance, unless you both happen to be on the same development team.
All of the Windows exploits you mention are easier to detect than a source-level exploit such as the one that inserted a broken privilege check into the Linux kernel. In one there's a process they can see, in another there's registry cruft, in the third there's a whole account. Those are all things that the next consultant might check, or that a third-party scanner might check. By contrast, there's no way in hell even the most sophisticated programmer or scanner is likely to notice the source-level exploit. If you can't see the difference, you're not qualified to be commenting on security.
If all someone does is check an MD5 on the executable they produce, they wasted their time and might as well have fetched the binary because nothing they build on their own is likely to match the official binary's MD5 anyway. The only real way to guarantee integrity is to require that every checked-in version of every file be signed using a trusted developer's key that is not stored on the public server. Far fewer than 100K people are even capable of doing such a check for any project without resulting in gazillions of false alarms that would only make it harder to spot the one real intrusion; realistically it will only be done by someone on the project's dev team. In other words, about the same number of people are really doing an effective check on an open-source project as would be doing one on a closed-source project. Given that a source-level exploit is more likely to occur in the first place when the source is widely and anonymously available, I'd say this indicates a danger that really is greater for open source. That doesn't mean open source is generally less secure; it just means that this one scenario does not favor them. The sourceforge etc. exploits demonstrate the danger of source exploits, and the open source community would be better off recognizing it than denying it.
Everything he claims can go wrong with open source can go wrong with closed source
Not exactly. Let's say that I'm a consultant, and I want to leave backdoors on every box I install for a client. My clients are hiring me precisely because they lack the expertise to set up the OS themselves, but they might know what a Linux or Windows system looks like once it's running. If the OS is Linux I can download all the source, add whatever kind of backdoor I want to it, compile the result, install it, and have a system that looks indistinguishable from one installed off a RH/Mandrake/whatever CD. If the OS is Windows I either have to get the Windows source or satisfy myself with the kinds of backdoors that can be implemented at the executable (not source) level - most of which do not themselves come with source and for which there are scanners that the customer might think to run some day. The fact is that an open-source OS would actually make a bad guy's job easier in this specific scenario. Sure, there are many other ways in which open-source has the advantage, but the score for closed source in this game is greater than zero.
Slashdot Mirror
OK, I just have to get this out of my system first: web design is stressful? Try real programming some time. There, I feel better now. ;-)
Whenever I start hating my job, I think about how the non-techie population lives - and how I lived, once.
Sure, my job can be frustrating. The technical challenges are the least of it; sometimes I think Sarte ("hell is other people") was right. When I start getting annoyed, though, I try to think of what it would really be like to have another kind of job - working on an assembly line, delivering packages for FedEx, picking up trash, ... no, thanks. Even the cushy-seeming jobs (doctor, lawyer, stockbroker) and the "fun" jobs (ski instructor, river guide) have their own trials and tribulations. They call it work for a reason. If you really think about it, working in high tech is about as close to a perfect job as you can reasonably expect.
If you were really that bright, you wouldn't be asking. What I do is right on my website, which is linked from here. You, on the other hand, hide behind the cloak of anonymous cowardice, from which any idiot can claim any credentials (and often does) without fear of contradiction. Not only have I worked on enterprise networks, but I'm currently active in defining and implementing new functionality for storage networks which are, if anything, more challenging than the IP kind. What can you prove that you have done? The phrase "diddly squat" comes to mind. You disrespect Jericho et al by asking "what have they done since then" but your own visible contributions are even less.
Go away, troll. You're bothering the people who build your toys.
Looks like someone's fragile little ego got stepped on. "What have they done since then" and "there takes skill in a real intrusion" are the tipoffs that we're probably dealing with a 16-year-old who think computing began with him - yeah, almost inevitably him, sorry but that's the way it is in that community and I had to pick a pronoun. Here's a clue for you, kid. Cracking might not take zero skill, but it's still absolutely nothing compared to the difficulty of actually creating the systems you crack, or the tools you use on either side of the security fence. Reality puts up a lot more obstacles than any number of white hats, black hats, or any other color hats. Raven - who can obviously take care of herself and doesn't need my help defending her or other female hackers - offers some excellent advice that I can only second:
It's interesting that you should mention that, because one of the early multi-threaded processors (at Tera) was specifically designed to solve that problem. The theory was, and still is, that if one thread has to stall it's OK because there are still plenty of others that can keep running from cache. So no, you won't have N threads all running without waits and yielding N threads' worth of performance, but you'll still have enough live threads to give you more performance than you'd have with a single-threaded core.
Only time will tell which way it will really go. Most likely, there will be some workloads on which this approach works extremely well, some on which it provides no benefit, and a few on which you would have been better off with a "fat" single-thread CPU design. One thing to remember is that if the system has X threads, cache pollution and memory bandwidth are going to be problems either way. The fact that the multi-thread processor can still get some work done on some threads even while others are blocked waiting for memory will probably allow it to maintain an advantage over a faster single-thread processor that blocks completely more often.
...and when the method fails the snake-oil salesmen blame the implementation of that method. UML bigots are exactly like Extreme Programming bigots; they believe the tool is a panacea, so any failure when using it must be the result of not using it properly. It's a great way to count all the hits and ignore all the misses, and for people who couldn't make a buck by selling drawing programs as drawing programs to make a buck by selling them as something much grander.
Those two statements are inconsistent.
Obviously not.
Ahhh, another gratuitous insult. You're the one who started with the condescending attitude, buddy. Don't whine when it rebounds on you. Our process level is doing just fine, and you have NO EVIDENCE that you could improve our productivity one iota. Any so-called "mentor" or consultant who came across as such an arrogant prick would get shown the door pretty quickly in any real-world business environment, and you'd know that if you really had any of the experience you claim.
Once again, this was about diagramming/flowcharting tools, not code generation. What part of "in terms of diagramming" are you having trouble with? Do you speak English? Do you understand the concept of a qualifying phrase?
The poster wasn't asking about source-code generators. He was asking about diagrams. In terms of diagrams the UML-oriented tools are no better than simple alternatives, even if they offer other features as well. Is a text editor no good just because it's not a full-blown IDE? Not if you just want to edit text.
You have absolutely no basis for that self-serving assumption. FYI, I'm the chief software architect at my company, with technical oversight for the work of 30-some engineers, and that work seems to be going rather well. Don't expect me to be intimidated by your empty claims.
I haven't had to do a 24-day "sprint" for years. Anybody who does screwed up earlier in the process. Of course you push UML tools because you have a business interest in doing so; maybe you should have skipped that dozenth UML class and taken an ethics class instead.
I've tried a lot of the fancy UML tools, but they're really not any better than a very simple drawing program. The purpose of a diagram is to convey information. For that purpose simpler is usually better, and a diagram that uses too many specialized symbols to denote subtle nuances is not simple; that stuff should be described in the text. Maybe a case can be made for the extra symbology in a class diagram, but not in a flowchart or timeline. If your flowchart has more than about twenty items, or more than four types of items, or can't be drawn without crossing lines, it needs to be broken apart into a top-level flow and separate diagrams for secondary flows. Any simple box-and-line drawing program should be able to handle that, though a little bit of intelligence in routing lines doesn't hurt. Focus on the information, not the tools.
Not really. The only potential for system failure should be if the entity - e.g. an OS kernel - controlling and coordinating the others fails. For that very reason, that entity should be as simple and bulletproof as possible, providing nothing but virtualization and communication between the virtualized parts of the system. If any of those other components fails, it should at the worst cause a partial loss of functionality (ideally it should be recoverable) and should not be capable of killing the whole system. That's the basis for microkernel architecture. Microkernels are in disrepute right now, primarily because of performance concerns that some (e.g. Linus Torvalds) have made out to be far worse than they really are. Sure, there were some slow microkernels Back In The Day, but only a fool dismisses an idea based on a flawed implementation and that's what seems to have happened in this case. It's possible to implement a fast microkernel-based system. Put a bunch of them together in a network (microkernels are also more inherently compatible with transparent distribution BTW) and you'd have a system that's much more robust than one based on monolithic kernels. Even if you did lose a little bit of performance in the process, it's always worth remembering that your performance is zero while a critical resource is down. Count transactions per month, not per second.
While I generally agree with your point and have spent a great deal of my own time and energy over the years ranting in much the same way about reality-free architects, I think you also need to consider the other side of the story. Just as you get tired of architects who stay up at the 30,000 foot level and never come to earth to code, architects get tired of programmers who are grubbing around in the dirt and refuse to look at how their little piece affects the whole. Any project of significant complexity needs people working at both high and low conceptual levels. A message-formatting module might be important, for example, but still a small part of the overall design. It shouldn't consume huge amounts of (human or machine) resources, or drive interface definitions throughout the rest of the system, but all too often the guy writing the message-formatting module acts like it's The Only Thing That Matters. It's an architect's job to remind such people that there are other things that matter too. There are other modules, and other considerations, and of course the features that users need and developers occasionally forget. Some of those considerations, like security or performance, are of immediate concern to developers, while others involve different constituencies.
No you can't do it that way, the architect has to say, because it complicates recovery or doubles the number of scenarios QA has to test or requires an overhaul to the documentation or leaves our support people hanging as they try to explain a weird program limitation to an unsympathetic customer. Of course the person who just wants to get their one piece done doesn't like to hear that, and they go off grumbling about architects who don't understand how hard it is to write a decent message-formatting module. Screw 'em. Somebody has to look out for how all the pieces will eventually fit together or else you end up with a dozen brilliantly-coded modules that don't work together. Been there, done that, seen projects and companies fail because of it. Yes, there are reality-free architects who spend way too much time with their nose stuck in the latest $10K piece of UML-diagramming junk and don't have Clue One about how anything actually works. Maybe they're even the majority of architects, and every one of them should be shot (except that shooting's too quick). However, there are also architects who can code as well as anyone else on their team in any of a half-dozen languages, and who would love to prove it day in or day out, but who end up being architects because they're the only ones on their team who can do anything but code. More projects fail due to a lack of architecture than due to an excess of it.
If NASA disclosed the invention without a patent, that would be prior art and would prevent anyone else from patenting the same idea.
The RADC page above specifically mentions that they expect to make money from royalties.
If it was developed at public expense, it should be placed into the public domain, not patented and subject to royalties.
Looks like the US Air Force's Rome Air Development Center thinks they have a patent on it. Am I the only one who thinks "United States of America as represented by the Secretary of the Air Force" should not be a valid patent assignee?
Is it just me, or does it seem a little odd to other people that several of the principals listed on their web page (including the CTO) remain anonymous? Why the heck would anyone do that? Most companies at this stage splash the identities of their principals everywhere. These guys must have some pretty bad skeletons in their closet to hide like this.
You can't steal what is freely given. The distinction between quoting with and without attribution, which you fail to make, is also important. Much of what's written on blogs is deliberately put into the public domain, with a clear desire on the authors' part to see it get broader distribution. Many bloggers obsessively track who's linking or responding to them, or how they stand on the various blogger rankings, or where they are on Google's list of hits for particular pet terms. It's a universal enough phenomenon that it's the exceptions - the people who do not want their material used elsewhere - who should be required to identify themselves. The default assumption, which mirrors copyright law, should be that if someone made a concrete effort to publish and didn't make an effort to limit the scope of that publication then it's public domain.
Your example sounds like someone set a ridiculously high bar for social interaction, but "don't be a total flaming dickhead" is a low one. It's the social equivalent of writing hello.c and if someone can't do even that much then they don't deserve to get hired anywhere. Not even at Mall-Wart. Everyone has to deal with someone, even if it's only their boss, and they need a modicum of skill to do that. While it might be unreasonable to expect that people have (and exercise) too many different skills, requiring that people behave like adults is perfectly sensible and the sad truth is that many OSS "luminaries" (Al Viro is the clearest example) fail that test.
Think about it: this is a situation where people were actively encouraged to write buggy code! Finally, a way to harness the unique talents of the average Slashdotter.
Owned by? Yes. Controlled by? No. The big mutual-fund managers read exactly the same business articles or books and make exactly the same decisions as the people who run endowments and foundations. They all think outsourcing is great. They don't much care that the people who lose jobs to outsourcing are their very own customers because that effect won't be felt until they personally are long gone. All they want to do is pump up the price on their fund according to whatever MBA mania is sweeping the financial sector that week, then retire and let others deal with the mess they've made. The fund managers exercise investors' proxy votes in their own best interest; the number of people who own stock directly and can therefore cast their own votes is relatively small.
Unfortunately, astroturf is common on Amazon. I've long known and tracked one author (Robert Stanek) who has written dozens of glowing reviews for his own incredibly-bad books, and adds reviews of other books "casually" mentioning himself in the company of Tolkien or Martin. He even Googles regularly for comments about himself elsewhere, which is how I found him on my own site once, trying to discredit me because I had written about his unethical behavior. I recently noticed another example, where an excellent book by Charles Perkins got several identically 40-column-formatted slag reviews in quick succession - probably an author or publisher of a competing book.
The problem is that it's too easy to establish multiple identities on Amazon. It would be trivial for me to create a hundred identities and use them to have a significant effect on the ratings of books I like or dislike. . .and you'd better believe I'd be less obvious about it than Stanek. Any claim Amazon might make about policing such abuse is a joke. Let's face it, folks: anywhere that online identities can be created basically out of thin air, fraud will be rampant. Yeah, that means Slashdot too. Pseudonymity is great, but anonymity is too often a cloak for abusers.
The accusation of bias at the end does open source no credit; someone writing for O'Reilly could be accused of bias as easily as someone writing for DevX. Stone would have done better to leave that out, and read one of the advocacy FAQs instead. DevX itself hosts a better rebuttal than his.
Checksums aren't sufficient. Where are you getting the MD5 to check against? From the same server the attacker would have compromised to modify the tarball you just downloaded? Do I need to explain what's wrong with that? To protect against a server compromise and subsequent source-code exploit, the source needs to be signed with something the attacker cannot find on that server and you as the recipient need to be capable of verifying that signature. Fat chance, unless you both happen to be on the same development team.
All of the Windows exploits you mention are easier to detect than a source-level exploit such as the one that inserted a broken privilege check into the Linux kernel. In one there's a process they can see, in another there's registry cruft, in the third there's a whole account. Those are all things that the next consultant might check, or that a third-party scanner might check. By contrast, there's no way in hell even the most sophisticated programmer or scanner is likely to notice the source-level exploit. If you can't see the difference, you're not qualified to be commenting on security.
If all someone does is check an MD5 on the executable they produce, they wasted their time and might as well have fetched the binary because nothing they build on their own is likely to match the official binary's MD5 anyway. The only real way to guarantee integrity is to require that every checked-in version of every file be signed using a trusted developer's key that is not stored on the public server. Far fewer than 100K people are even capable of doing such a check for any project without resulting in gazillions of false alarms that would only make it harder to spot the one real intrusion; realistically it will only be done by someone on the project's dev team. In other words, about the same number of people are really doing an effective check on an open-source project as would be doing one on a closed-source project. Given that a source-level exploit is more likely to occur in the first place when the source is widely and anonymously available, I'd say this indicates a danger that really is greater for open source. That doesn't mean open source is generally less secure; it just means that this one scenario does not favor them. The sourceforge etc. exploits demonstrate the danger of source exploits, and the open source community would be better off recognizing it than denying it.
Heh. Even as I wrote that, it looked like the closed-source version of this trick became a lot easier with the leak of NT source. What a coincidence.
Not exactly. Let's say that I'm a consultant, and I want to leave backdoors on every box I install for a client. My clients are hiring me precisely because they lack the expertise to set up the OS themselves, but they might know what a Linux or Windows system looks like once it's running. If the OS is Linux I can download all the source, add whatever kind of backdoor I want to it, compile the result, install it, and have a system that looks indistinguishable from one installed off a RH/Mandrake/whatever CD. If the OS is Windows I either have to get the Windows source or satisfy myself with the kinds of backdoors that can be implemented at the executable (not source) level - most of which do not themselves come with source and for which there are scanners that the customer might think to run some day. The fact is that an open-source OS would actually make a bad guy's job easier in this specific scenario. Sure, there are many other ways in which open-source has the advantage, but the score for closed source in this game is greater than zero.