I did some work for Clariion once, and I now work for EMC (because they bought the company I wanted to work for), and I have to say that I wouldn't consider them to be in the same market. Each has some features the other doesn't. Some of those features are useful, some aren't. For example, Clariion likes to make noise about "end-to-end FC" when it really doesn't matter (to a host) whether it's FC, SCSI, or duct tape on the far side of the array controller.
So what are the significant differences? EMC arrays scale to more disk capacity, more cache, more ports. EMC arrays support load balancing between concurrently-active array controllers better, though still not as well as I believe they could/should. (BTW, be very careful before you challenge that claim, since I wrote some of the original software to do this on Clariion, and within the organization that did so on EMC) EMC support is very highly regarded, to the extent that we're wary of even someone as good as HP "diluting our trademark". Think about that. Of course, EMC equipment also costs a bundle. As for performance, that's mostly a trackless swamp that I won't get into except to note that you can't talk performance without talking scale. In my experience, talking now about both storage systems and hosts, optimal low- or mid-range performance and high-range scalability are rarely found in combination. More often, some companies focus on winning the benchmark contests at the low or middle ranges - and they succeed - but don't even have products in the high range. That's not a criticism; it's a perfectly good and moral business strategy. In the end, the only valid benchmark is your workload.
I'm not going to make any recommendations for either EMC, Clariion, or any of our numerous competitors in either the disk-array or NAS spaces, though. Just offering some food for thought.
>And quite a few of them, even most of them, don't.
...nor should they. Just as grownups the world over are realizing that one language might not fit all needs, in a couple of years a similar realization with respect to OSes may set in. Toasters and desktops and servers provide very different environments to both the OS author and the user, and no OS out there today is so universal as to be appropriate for all of those environments. None. Don't even get me started on the so-called microkernels. Some of the "nanokernels" and "exokernels" and such are getting there, but not yet. Until then, people who want to get real work done (have you ever actually tried to do embedded-system work, tlewis?) will be well served by choosing an OS appropriate for their particular use.
People seem to be confusing several different performance-oriented activities, acting as though they're all the same. Here are some examples of things I've seen done:
Changing already-existing parameters to suit a particular workload. It's really hard to argue that this isn't legit.
Adding options/features that are only good for a particular workload. This is generally OK, especially if the machine is only sold for that purpose, or if the extra options/features can be turned off if the machine is used differently.
Adding code that only helps the benchmark but nothing in the real world. For example, there was at least one case where a vendor shipped a compiler that would use pattern-matching to detect whether it was compiling Dhrystone and, if so, do a bunch of optimizations that would never be applied to any other code. A less extreme case might involve optimizing how a particular "weird" behavior or edge case just because a certain benchmark does things that way. This practice is generally frowned upon.
The worst is when vendors make changes for the sake of a benchmark that actually sacrifice correctness. One example I had to fight against was failure to flush data to stable storage even when explicitly required to do so. Even the people who perpetrate this kind of thing don't consider it justifiable; they just hope they don't get caught.
On a slightly different point, I just have to laugh at Linux advocates complaining about "hacking the kernel" to get better performance. Does anyone really think the very design of Linux's major subsystems hasn't been heavily influenced by a desire to improve performance in particular situations (notably web service)? In my experience there are about a hundred times as many Linux hackers worrying about performance than about correctness, which is why we allow abominations like a non-journaling filesystem with delayed metadata writes (because if you try to force synchrony you get undetected data corruption, and the authors admitted as much in a public paper). This is the very worst sort of benchmarketing, case 4 above. Linux advocates must tread very lightly indeed when they presume to criticize other OS vendors of benchmarketing sins.
>I think the difference here is that the previous person thinks that this right has infinite value, and thus he/she should never have to give it up for something of finite value, whereas you do not.
But, again, which right are we talking about here? I have ceded only very specific rights to my employer, involving work produced under a very particular set of conditions. Work I produce under other conditions (on my time, my equipment, not incorporating my employer's trade secrets) remains mine...unless I decide to sell those rights separately, of course.
If we were talking about giving up one's general intellectual property rights, such that the employer or other grantee retained rights to all of one's "intellectual output" regardless of the conditions under which it was created and in perpetuity, that would be a whole different thing. Many employers' confidentiality agreements attempt to do just that, and that's why I amend such agreements before signing them (and nobody has ever squawked very hard about such amendments, BTW).
Am I making this clear enough? I think it's crucial to distinguish between selling individual works (the core of capitalism) and selling what is in a sense part of oneself (one's ability to produce further works).
>In the commercial software community, your >personal property rights are violated because >your rights to YOUR OWN PERSONAL PROPERTY are >being violated.
Which rights are those, exactly? I'm in the "commercial software community" and I don't feel that my employer is violating any of my personal rights. We have a contract which we have both entered into because we consider it beneficial to do so. Sure, I'd like to have a little more say in how my work is used or abused, but I willingly gave up that "right" in return for quite a bit of money.
If you'd read your economics and philosophy a little more carefully, you'd see that the idea of being able to make such contracts, to attach a value to what one produces and then sell it, is at the very core of capitalism. We're having enough problems with "painting the enemy red" without turning notions of capitalism and communism on their heads.
Microsoft likes to stick their head in the sand and not admit that an idea exists until it shows up in Windows, leading to abominations like their "Digital Nervous System" campaign. Certain Linux advocates then stick their heads in some different sand and don't admit that something exists until it shows up in Linux, leading to comments like the above. Both examples are rooted in flagrant ignorance of what else is out there besides "us" and "them". In actual fact, very little that has appeared in either Windows or Linux for as long as I can remember was truly new at the time. "Thirty years" is a little bit of an exaggeration, but it's a heck of a lot more accurate than "two weeks".
I rather explicitly said that such a claim was tempting, but not entirely true. Sure, Tera's implementation has some problems - some of which you point out - but I think the "real story" is that MTA just isn't the panacea it was hoped to be. It's just one more weapon in a rather large arsenal of performance-improving tricks, and not even one of the most powerful.
Basically, I think the lesson - once again - is that there are no magic bullets. Sometimes we just have to slog through the hard problems one small step at a time.
I was initially very optimistic about the prospects for multi-threaded architectures, but have been very disappointed by the real-world results. It's tempting to say Tera screwed up their implementation of a good idea, but I don't think that's entirely true. There are also some serious OS and compiler issues to be resolved (e.g. how to do optimal scheduling for an MTA system). I also think there are some inherent limitations in MTA. All of that chip real estate used for contexts could be used for other performance-improving techniques; for example, the contexts are in many ways functionally equivalent to but less flexible than traditional caching. MTA doesn't help single-instruction-stream performance, the presence of many concurrent streams messes up locality of reference and results in the memory interface being even more of a bottleneck, etc. etc.
Maybe all of these "kinks" in MTA can be worked out. I'm not ready to give up on MTA yet, but it's not looking as promising as it once did. Bubble memory looked really promising once too.
Hearing the PC users argue about IDE vs. SCSI vs. FireWire is pretty funny. Just some random thoughts:
The serious storage companies are all going Fibre Channel, and it's not because they're ignorant of alternatives.
Latency counts too, not just bandwidth. How much depends on the I/O pattern.
The fact that SCSI devices are offered at higher RPM and media-transfer rates than IDE has more to do with marketing than with the interface. It would be trivial to make a 10K RPM IDE drive just as good as the upper-tier SCSI drives, but apparently nobody buys such things.
Don't forget multiple initiators. IDE doesn't handle them at all, SCSI handles them quite poorly (which is why multi-initiator systems tend toward having the initiators on separate buses), FW and FC handle them pretty well.
The limitations of media with moving parts will be with us for a long time, unfortunately. The solutions for the foreseeable future will be what they have traditionally been at all levels of the storage hierarchy: parallelism, prediction, caching, etc. and thus it's no surprise that a lot of very interesting research continues to be done in these areas.
>Why is it such a bad thing to have pointers? I understand how, when used wrong or poorly, they can lead to Bad Things but in general I have found them very powerful elements of programming. > >If someone could enlighten me I'd appreciate it.
Sure, I'll give it a try. The problem is people can and often do use pointers "wrongly and poorly" and there's not a whole lot you can do to recover when they screw up. That's why a segfault or GPF or is the most common form of application failure. So you have to ask yourself, can we give programmers the benefit of pointers without letting them use pointers to shoot them and us in the head? It's still a very open debate, but the majority opinion seems to be yes. The theory is that pointers are only used to implement a certain number of things, and if you've implemented those things already in other ways (e.g. dispatch tables, pass by reference) then pointers are no longer necessary. Personally I think Java falls a little short in terms of providing an adequate replacement for complex linked data structures, but there are other languages that do provide these things and in doing so support the theory more strongly than Java does.
>Simiarly with garbage collection. I thought that was an indication of an interpreted language; that compiled languages used a stack, BSS and data areas to get the job done.
Oh, please, "BSS" is a platform-specific and outmoded term. The idea behind GC is that in a program of any complexity tracking references and freeing stuff up manually gets to be a real problem. Memory leaks are everywhere. So, as with pointers, the question is whether we can do this little piece of micromanagement automagically so the programmer can do other things, without sacrificing performance and predictability. Again, the majority answer is that yes, with modern GC technology and a language that doesn't let the programmer muck about behind the GC code's back we can provide that luxury and never have to worry about memory leaks.
Of their six listed vulnerabilities in Solaris on an E10K:
One has to do with security, which is a known weak point for NT.
Three have to do with removing "hot" components, which it utterly impossible in NT.
One has to do with another feature (multiple domains) also not available in NT.
That leaves them with one reasonably uncompelling point about dependence on a service processor when they start plugging their own high-availability "story" - and what a piece of fiction that is. I've worked professionally in the HA field, and Wolfpack is the laughingstock of the industry. It's the most unbearably pathetic HA package I've ever seen, only surviving because of its parentage, and even then it amazes me somewhat that anyone uses it.
I know marketing material is not intended to be objective, but this piece is the most blatantly offensive piece of misinformation I've seen in a long time. While no individual claim in it is untrue, the overall result is incredibly misleading. Whoever wrote it is a master of their craft, but some forms of mastery don't deserve to be acknowledged.
Yes indeed, an interesting article. I hope somebody tells NS to read this thread, because I do have a few comments. If somebody else finds them interesting, so much the better.
I liked the bit about how both Stallman and Gates created the conditions necessary for Linux's success. Very insightful.
I also liked the big about the problem with a user making a menu selection on a Mac hanging the network, because I remember running into that exact problem myself once many years ago. Ahhh, memory.
I disagree that the Mac wasn't very hackable. Hardware-wise, perhaps, but the software had everything in resources from a very early stage and browsing with ResEdit was a popular hobby for Mac hackers. There were WDEFs and MDEFs and CDEFs so you could make everything look/behave differently. Overall, as hackable as anything else, just in different ways.
NS is dead wrong about how a sufficiently motivated programmer could write everything to the bare metal and doesn't really need an OS. That assumes that the only purpose of an OS is to provide layers of abstraction, whereas in a real OS it has other purposes such as protecting processes and users from one another. It's ironic that he'd make this error, because he talks about UNIX to open one's eyes regarding Mac/Windows, but then he falls prey to seeing the world through desktop-OS eyes.
His comparison of UNIX to the Hole Hawg strikes me as a little inapt. If Windows is the wimpy "power drill" for the home handyman and UNIX is the Hole Hawg for the professional building contractor, he has obviously overlooked even older hoarier OSes (VMS and MTS are two I've used) that are the equivalent of earthmovers and piledrivers.
It'd be interesting to see how the LISP/Scheme culture (of which RMS was of course a part, interestingly in this context) fits into his metaphors.
Emacs for serious word processing? Gack! Yes, a lot of what's in MS Turd is feature bloat, but for really long documents some features (styles, automatic cross-references and tables of contents etc.) are truly useful. Fixing up all those references to Section X by hand when you insert a new section in between is like trying to do OOP with case statements instead of dispatch tables.
OK, the single-word response was enjoyable, but now I've given this a little more thought, and here's a more detailed response. Yeah, I know, who the hell is going to read a dead slashdot discussion? Well, you.;-) Get a life.
Most companies, particularly small ones, have a set of "crown jewels" written by the founders and/or key employees, representing some sort of "core competency". Ick. Hate that phrase, but it fits. Anyway, they usually don't hire contractors to work on that stuff. They hire the contractors to work on stuff at the periphery, often the scutwork, often maintaining the worst ugliest pieces of code around. Contractors are called upon to hack on broken pieces of an inconsistent whole, with requirements coming from panicked managers who have to ship something this month. Most good programmers couldn't be lured into such an environment for any amount of money.
Successful contracting is as much about marketing as about anything technical. Contractors have to network, so they go to trade shows and hang out online and have elaborate web pages. They overstate their accomplishments because that's part of the job, so PHBs and the terminally naive think they're big shots, but the claim is most likely to be nothing more than hot air. Sure, contractors can make a lot of money, but that doesn't make them good programmers. If I wanted to find a good programmer I'd look in the back rooms of startups (the front-room guys are just like the contractors).
Re:kinda lame comment in story
on
K7 Benchmarking
·
· Score: 1
>Um yeah, what special thing do you need to do for ADSL, unless you have some really bogus implementation? Most of them go with just a straight Ethernet connection, so the processor has nothing to do with it, save for interpreting the data that comes in over the NIC.
There are three major ways to deploy DSL or broadband or any other new communications medium:
Use an Ethernet half-bridge. This is a common solution, and the one you obviously have in mind, but some would say it's pretty bogus.
Use a dedicated DSL/whatever card. This is The Right Thing in an abstract sense. In the real world, Ethernet cards (I hate the term "NIC" which was popularized mostly by MS) are produced in such great quantity and are therefore so cheap that it's hard for a dedicated card to be price-competitive.
Use a WinModem-like card that relies on the CPU to do half of the work. This is obviously what the original author had in mind, and is truly bogus.
So, in other words, your original question is a very good one, but your "background information" doesn't really account for all of the possibilities very well.
As with many things, the "right" way to deal with secrecy in a development context is a narrow bridge across a broad chasm, and it's easy to fall off either side. On the one hand, you can be too secretive and there's not enough peer review etc. and you end up producing the wrong thing or crap (which is always the wrong thing). On the other hand, not allowing enough secrecy - which BTW is very closely related to privacy - can be a real problem during the "incubation phase" of a project.
Here's why I think the "forum" model won't work. Let's say that I want to write the world's greatest cluster/distributed file system - which in fact I do. I can blab about my ideas in public forever and never get anywhere; to attract serious interest, i.e. the kind that will pay my bills, I have to provide a lot more detail than that. Here's the catch: I don't want to provide that kind of detail in a public place. Resentment over who stole/copied what, which is after all merely the flip side of pride in accomplishment, is one of the greatest banes of open-source software development. GNU/Linux, anyone? For me personally, the idea of someone taking credit for my incomparably brilliant ideas is intolerable.;-) I worry about such misappropriation when dealing with potential employers or investors, bound about with NDAs. There is no way in hell that I'm going to talk about the details to a group of people notorious for their belief that every idea belongs to everybody and their tendency to reward eleventh-hour midgets instead of the innovative giants on whose shoulders those midgets stand.
[My apologies to those offended by my usage of "midgets" in that metaphor; it predates both me and the spirit of political correctness, and it seemed apt.]
>I told her that the greater threat to software developers came from anticompetitive practices by large corporations.
...not that that's relevant or anything. The presence of a larger threat does not make the smaller threat disappear.
>That ended the conversation.
Maybe she's just not into deprogramming Moonies and Robin Hood wannabes. Lord knows why I still try.;-)
>Piracy, per se, is not the evil here. Failing to reward software developers for their efforts, whether they develop free or proprietary software, is evil.
As a software developer I can honestly say that you don't represent me or my views. Thanks for trying, but you can stop now.
>The people who care about that are in the other wing in
Somebody else made the point that not every software developer works for a behemoth like Microsoft. Many (most?) work on their own, or for small companies that can only dream of making billions of dollars in excess revenue solely due to their market position and not product innovation or quality. I'd say the non-'softies of the world quite often do care about piracy.
That said, you make a good point about copying TV shows. The interesting thing is that TV shows are supported by the advertisers not the viewers. If that weren't the case then the TV people, like the movie people and the record people and the cable people, would care a whole heck of a lot more about piracy.
The big issue is loss of revenue. Maybe nobody cares about the "trading card" warez kiddies or the packrats (though they still doesn't make those people's actions right) but I think people here are unaware of the dimensions of corporate and for-profit piracy. Even if the vendors' claims are somewhat inflated - and I know they are - there are people out there selling pirated software for billions of dollars. By what reasoning should people like that be rewarded instead of the people who wrote the code? What are the consequences of an economy where it's more rewarding to be an uncreative leech than an innovator and builder?
Think about the consequences of your attitudes if applied globally. Personally, I want to reward people who make new things. Some of those people are motivated by altruism or ego, and they write free software; good for them! Other people are motivated by money, and if what they create is worth enough to me I reward them for that by buying it. Other people - pirates, monopolists, government officials - create nothing. The world (my world?) is not improved by their presence, and might well be improved by their absence. Not only do I not want my money going into their pockets, I want that form of livelihood denied them, so they'll be forced to do something constructive for a change.
>Ideas are free. If I understand how a good bicycle is made
So make your own bicycle, i.e. write your own program. Writing a program to do something and pirating a program are two very different things, aren't they? If your version would be "probably inferior" as you say then isn't it possible that you owe the author something for doing it better than you could have? For the time spent designing, testing, documenting and supporting their work, even if you place no value on the bits themselves?
People seem to be hung up on this "they still have a copy" thing. The problem is that software is not just an idea, it's an expression of an idea. The comparison is to books or records, not to bicycles and cars. We could of course have a lot of fun discussing whether it's OK to copy a book or a record. That would be a discussion with some meat to it, but thing I'm convinced of when I read about stealing cars or "MS can afford it" is that teaching ethics (not to mention logic) in schools might not be such a bad thing.
>I may be forced to use their products (e.g., games)
You're forced to play games?
The sad thing is that the notions of things like "force" and "cost" and "rights" represented by the above are not significantly less mature than those in most of the other pro-piracy posts. It's really very very simple: a license agreement is a contract. If the license says don't copy and you do copy, you have broken your word. Whether it's "stealing" to you, whether it harms anyone, whether it furthers some political agenda...you broke a promise. Maybe we shouldn't be stringing up oathbreakers by their thumbs, but it is a moral negative.
If you don't want to pay for software, stick exclusively to free (beer) software. However you rationalize, anything else is immoral.
>Having the market decides works better than you think. The theory is (if you ever took economist)
*Sigh* What purpose is served by such ad hominem attacks? You don't in fact know my views on market efficiency, or how deep my knowledge of economics is. In actual fact, this is still a very hotly debated set of issues, just about the only consensus being that the "solution" probably lies at neither extreme - total laissez-faire or central planning.
>if your product is desirable people will want it, if it's not nobody will
This is overly simplistic. There are other factors, such as availability, pricing, compatibility with other products, monopoly situations, etc.
>Having an external body decide what is good and bad is something only a communist
Again with the grade-school rhetoric, eh?
I am not suggesting, nor is anybody else here, that any central authority - either a government or a monopoly holder, and the two scenarios are actually veryt similar - should decide precisely what products people should buy. All I'm talking about are minimal standards that differentiate honest business from fraud or malpractice. Consumers have a right to expect that bridges and cars and drugs and electrical applicances (including computers) must meet minimum safety standards because even if the market does eventually differentiate between good products and bad it may not be efficient enough to do so before people get hurt. My suggestion is merely that the same idea be extended to software. I'm not talking about feature sets or pricing or bundling or anything other than a very basic promise that the software won't lose or damage your assets in the form of data.
>What you fail to see, is that people WANT microsoft products
No, they put up with Microsoft products, because they perceive the benefits as greater than the costs, and you know what? That's great. I just like to base standards on what is achievable rather than what I can get away with. In a sense, by failing to hold themselves to a higher standard than that absolutely required of them, the whole software industry is acting like one big cartel denying consumers a choice. I would like to see that deadlock broken, and a world created where the creators of quality software are rewarded relative to the purveyors of crap, instead of being pushed out of the market. If you have a better solution, please speak up.
>We all know honor doesn't work. it puts us in neat little boxes and expects us to behave according to some vague rule nobody really understands
Umm, no, we don't "all know" that. Some of us "know" quite differently.
It doesn't matter though, because I at least wasn't talking about honor. I was talking about accountability. You screw someone over, in this case by what amounts to fraud, you pay the price. Your naive version of "let the market decide" is the same justification used by snake-oil salesmen and psychic hotlines, but I think we can do a little better.
>I Agree. Could you sue a software engineer/company for malpractice?
Ick, no, I hope not. This society is litigious enough already. My hope is that we can keep things simple, without throwing accountability out the window because it's "too hard".
>How many geeks out there would submit to a professional association, like accountants and solicitors|lawyers? Not many I think..
I agree: not many. The grammar-school libertarians and suspiciously-alike "nonconformists" would never stand for it. Certification of individuals is not really what I'd propose. ISO-9000 "quality school" BS is even worse, focusing either on the wrong parts of the process or on whether it's documented rather than whether it works or is adhered to. What I had in mind was more of a one-time audit, much like when you have an outside accounting firm look at your books, associated with the release of a product to say "yup, somebody made a reasonable effort to test/debug up to reasonable professional standards before it went out the door".
To elaborate a little, we all know that "I don't write code with bugs" is rarely if ever true. All the auditor should need to do is look at a test plan and report and a bug database and make sure they look "kosher". If you don't have a real bug database or a process that includes formal bug reporting the job gets more difficult, but the information may still be there in CVS/RCS logs and the audit might just take a little longer. If you don't even have real source control...well, at some point just about anyone would have to admit that they can't prove the product was properly tested and debugged, and that it shouldn't pass even a relatively informal kind of audit. At that point I have to ask then how the hell do you justify asking customers to pay you and trust you?
Sorry for the shouting. It just seems absurd to me, as a software engineer myself, that software engineers should have absolutely no accountability whatsoever for what they produce, even when they're making a profit, and yet that seems to be precisely what many here believe. That disgusts me, even as I remind myself that the/. audience is not exactly representative of the industry at large...and thank God for that.
Slashdot Mirror
I did some work for Clariion once, and I now work for EMC (because they bought the company I wanted to work for), and I have to say that I wouldn't consider them to be in the same market. Each has some features the other doesn't. Some of those features are useful, some aren't. For example, Clariion likes to make noise about "end-to-end FC" when it really doesn't matter (to a host) whether it's FC, SCSI, or duct tape on the far side of the array controller.
So what are the significant differences? EMC arrays scale to more disk capacity, more cache, more ports. EMC arrays support load balancing between concurrently-active array controllers better, though still not as well as I believe they could/should. (BTW, be very careful before you challenge that claim, since I wrote some of the original software to do this on Clariion, and within the organization that did so on EMC) EMC support is very highly regarded, to the extent that we're wary of even someone as good as HP "diluting our trademark". Think about that. Of course, EMC equipment also costs a bundle. As for performance, that's mostly a trackless swamp that I won't get into except to note that you can't talk performance without talking scale. In my experience, talking now about both storage systems and hosts, optimal low- or mid-range performance and high-range scalability are rarely found in combination. More often, some companies focus on winning the benchmark contests at the low or middle ranges - and they succeed - but don't even have products in the high range. That's not a criticism; it's a perfectly good and moral business strategy. In the end, the only valid benchmark is your workload.
I'm not going to make any recommendations for either EMC, Clariion, or any of our numerous competitors in either the disk-array or NAS spaces, though. Just offering some food for thought.
>And quite a few of them, even most of them, don't.
...nor should they. Just as grownups the world over are realizing that one language might not fit all needs, in a couple of years a similar realization with respect to OSes may set in. Toasters and desktops and servers provide very different environments to both the OS author and the user, and no OS out there today is so universal as to be appropriate for all of those environments. None. Don't even get me started on the so-called microkernels. Some of the "nanokernels" and "exokernels" and such are getting there, but not yet. Until then, people who want to get real work done (have you ever actually tried to do embedded-system work, tlewis?) will be well served by choosing an OS appropriate for their particular use.
Please, let's can the slashdot FUD, and compare apples to apples.
On a slightly different point, I just have to laugh at Linux advocates complaining about "hacking the kernel" to get better performance. Does anyone really think the very design of Linux's major subsystems hasn't been heavily influenced by a desire to improve performance in particular situations (notably web service)? In my experience there are about a hundred times as many Linux hackers worrying about performance than about correctness, which is why we allow abominations like a non-journaling filesystem with delayed metadata writes (because if you try to force synchrony you get undetected data corruption, and the authors admitted as much in a public paper). This is the very worst sort of benchmarketing, case 4 above. Linux advocates must tread very lightly indeed when they presume to criticize other OS vendors of benchmarketing sins.
>I think the difference here is that the previous person thinks that this right has infinite value, and thus he/she should never have to give it up for something of finite value, whereas you do not.
But, again, which right are we talking about here? I have ceded only very specific rights to my employer, involving work produced under a very particular set of conditions. Work I produce under other conditions (on my time, my equipment, not incorporating my employer's trade secrets) remains mine...unless I decide to sell those rights separately, of course.
If we were talking about giving up one's general intellectual property rights, such that the employer or other grantee retained rights to all of one's "intellectual output" regardless of the conditions under which it was created and in perpetuity, that would be a whole different thing. Many employers' confidentiality agreements attempt to do just that, and that's why I amend such agreements before signing them (and nobody has ever squawked very hard about such amendments, BTW).
Am I making this clear enough? I think it's crucial to distinguish between selling individual works (the core of capitalism) and selling what is in a sense part of oneself (one's ability to produce further works).
>In the commercial software community, your >personal property rights are violated because >your rights to YOUR OWN PERSONAL PROPERTY are >being violated.
Which rights are those, exactly? I'm in the "commercial software community" and I don't feel that my employer is violating any of my personal rights. We have a contract which we have both entered into because we consider it beneficial to do so. Sure, I'd like to have a little more say in how my work is used or abused, but I willingly gave up that "right" in return for quite a bit of money.
If you'd read your economics and philosophy a little more carefully, you'd see that the idea of being able to make such contracts, to attach a value to what one produces and then sell it, is at the very core of capitalism. We're having enough problems with "painting the enemy red" without turning notions of capitalism and communism on their heads.
Microsoft likes to stick their head in the sand and not admit that an idea exists until it shows up in Windows, leading to abominations like their "Digital Nervous System" campaign. Certain Linux advocates then stick their heads in some different sand and don't admit that something exists until it shows up in Linux, leading to comments like the above. Both examples are rooted in flagrant ignorance of what else is out there besides "us" and "them". In actual fact, very little that has appeared in either Windows or Linux for as long as I can remember was truly new at the time. "Thirty years" is a little bit of an exaggeration, but it's a heck of a lot more accurate than "two weeks".
>In what sense did Tera screw up?
I rather explicitly said that such a claim was tempting, but not entirely true. Sure, Tera's implementation has some problems - some of which you point out - but I think the "real story" is that MTA just isn't the panacea it was hoped to be. It's just one more weapon in a rather large arsenal of performance-improving tricks, and not even one of the most powerful.
Basically, I think the lesson - once again - is that there are no magic bullets. Sometimes we just have to slog through the hard problems one small step at a time.
I was initially very optimistic about the prospects for multi-threaded architectures, but have been very disappointed by the real-world results. It's tempting to say Tera screwed up their implementation of a good idea, but I don't think that's entirely true. There are also some serious OS and compiler issues to be resolved (e.g. how to do optimal scheduling for an MTA system). I also think there are some inherent limitations in MTA. All of that chip real estate used for contexts could be used for other performance-improving techniques; for example, the contexts are in many ways functionally equivalent to but less flexible than traditional caching. MTA doesn't help single-instruction-stream performance, the presence of many concurrent streams messes up locality of reference and results in the memory interface being even more of a bottleneck, etc. etc.
Maybe all of these "kinks" in MTA can be worked out. I'm not ready to give up on MTA yet, but it's not looking as promising as it once did. Bubble memory looked really promising once too.
The limitations of media with moving parts will be with us for a long time, unfortunately. The solutions for the foreseeable future will be what they have traditionally been at all levels of the storage hierarchy: parallelism, prediction, caching, etc. and thus it's no surprise that a lot of very interesting research continues to be done in these areas.
>Yeah, this'll be cool for those wanting Windows apps that run both on their desktop and on their CE-based PDA
I wish. So far I've had no luck finding a usable JVM for my CE device.
>Why is it such a bad thing to have pointers? I understand how, when used wrong or poorly, they can lead to Bad Things but in general I have found them very powerful elements of programming.
>
>If someone could enlighten me I'd appreciate it.
Sure, I'll give it a try. The problem is people can and often do use pointers "wrongly and poorly" and there's not a whole lot you can do to recover when they screw up. That's why a segfault or GPF or is the most common form of application failure. So you have to ask yourself, can we give programmers the benefit of pointers without letting them use pointers to shoot them and us in the head? It's still a very open debate, but the majority opinion seems to be yes. The theory is that pointers are only used to implement a certain number of things, and if you've implemented those things already in other ways (e.g. dispatch tables, pass by reference) then pointers are no longer necessary. Personally I think Java falls a little short in terms of providing an adequate replacement for complex linked data structures, but there are other languages that do provide these things and in doing so support the theory more strongly than Java does.
>Simiarly with garbage collection. I thought that was an indication of an interpreted language; that compiled languages used a stack, BSS and data areas to get the job done.
Oh, please, "BSS" is a platform-specific and outmoded term. The idea behind GC is that in a program of any complexity tracking references and freeing stuff up manually gets to be a real problem. Memory leaks are everywhere. So, as with pointers, the question is whether we can do this little piece of micromanagement automagically so the programmer can do other things, without sacrificing performance and predictability. Again, the majority answer is that yes, with modern GC technology and a language that doesn't let the programmer muck about behind the GC code's back we can provide that luxury and never have to worry about memory leaks.
That leaves them with one reasonably uncompelling point about dependence on a service processor when they start plugging their own high-availability "story" - and what a piece of fiction that is. I've worked professionally in the HA field, and Wolfpack is the laughingstock of the industry. It's the most unbearably pathetic HA package I've ever seen, only surviving because of its parentage, and even then it amazes me somewhat that anyone uses it.
I know marketing material is not intended to be objective, but this piece is the most blatantly offensive piece of misinformation I've seen in a long time. While no individual claim in it is untrue, the overall result is incredibly misleading. Whoever wrote it is a master of their craft, but some forms of mastery don't deserve to be acknowledged.
Yes indeed, an interesting article. I hope somebody tells NS to read this thread, because I do have a few comments. If somebody else finds them interesting, so much the better.
I liked the bit about how both Stallman and Gates created the conditions necessary for Linux's success. Very insightful.
I also liked the big about the problem with a user making a menu selection on a Mac hanging the network, because I remember running into that exact problem myself once many years ago. Ahhh, memory.
I disagree that the Mac wasn't very hackable. Hardware-wise, perhaps, but the software had everything in resources from a very early stage and browsing with ResEdit was a popular hobby for Mac hackers. There were WDEFs and MDEFs and CDEFs so you could make everything look/behave differently. Overall, as hackable as anything else, just in different ways.
NS is dead wrong about how a sufficiently motivated programmer could write everything to the bare metal and doesn't really need an OS. That assumes that the only purpose of an OS is to provide layers of abstraction, whereas in a real OS it has other purposes such as protecting processes and users from one another. It's ironic that he'd make this error, because he talks about UNIX to open one's eyes regarding Mac/Windows, but then he falls prey to seeing the world through desktop-OS eyes.
His comparison of UNIX to the Hole Hawg strikes me as a little inapt. If Windows is the wimpy "power drill" for the home handyman and UNIX is the Hole Hawg for the professional building contractor, he has obviously overlooked even older hoarier OSes (VMS and MTS are two I've used) that are the equivalent of earthmovers and piledrivers.
It'd be interesting to see how the LISP/Scheme culture (of which RMS was of course a part, interestingly in this context) fits into his metaphors.
Emacs for serious word processing? Gack! Yes, a lot of what's in MS Turd is feature bloat, but for really long documents some features (styles, automatic cross-references and tables of contents etc.) are truly useful. Fixing up all those references to Section X by hand when you insert a new section in between is like trying to do OOP with case statements instead of dispatch tables.
OK, the single-word response was enjoyable, but now I've given this a little more thought, and here's a more detailed response. Yeah, I know, who the hell is going to read a dead slashdot discussion? Well, you. ;-) Get a life.
Most companies, particularly small ones, have a set of "crown jewels" written by the founders and/or key employees, representing some sort of "core competency". Ick. Hate that phrase, but it fits. Anyway, they usually don't hire contractors to work on that stuff. They hire the contractors to work on stuff at the periphery, often the scutwork, often maintaining the worst ugliest pieces of code around. Contractors are called upon to hack on broken pieces of an inconsistent whole, with requirements coming from panicked managers who have to ship something this month. Most good programmers couldn't be lured into such an environment for any amount of money.
Successful contracting is as much about marketing as about anything technical. Contractors have to network, so they go to trade shows and hang out online and have elaborate web pages. They overstate their accomplishments because that's part of the job, so PHBs and the terminally naive think they're big shots, but the claim is most likely to be nothing more than hot air. Sure, contractors can make a lot of money, but that doesn't make them good programmers. If I wanted to find a good programmer I'd look in the back rooms of startups (the front-room guys are just like the contractors).
There are three major ways to deploy DSL or broadband or any other new communications medium:
So, in other words, your original question is a very good one, but your "background information" doesn't really account for all of the possibilities very well.
>most good programmers already contract
Baloney.
As with many things, the "right" way to deal with secrecy in a development context is a narrow bridge across a broad chasm, and it's easy to fall off either side. On the one hand, you can be too secretive and there's not enough peer review etc. and you end up producing the wrong thing or crap (which is always the wrong thing). On the other hand, not allowing enough secrecy - which BTW is very closely related to privacy - can be a real problem during the "incubation phase" of a project.
;-) I worry about such misappropriation when dealing with potential employers or investors, bound about with NDAs. There is no way in hell that I'm going to talk about the details to a group of people notorious for their belief that every idea belongs to everybody and their tendency to reward eleventh-hour midgets instead of the innovative giants on whose shoulders those midgets stand.
Here's why I think the "forum" model won't work. Let's say that I want to write the world's greatest cluster/distributed file system - which in fact I do. I can blab about my ideas in public forever and never get anywhere; to attract serious interest, i.e. the kind that will pay my bills, I have to provide a lot more detail than that. Here's the catch: I don't want to provide that kind of detail in a public place. Resentment over who stole/copied what, which is after all merely the flip side of pride in accomplishment, is one of the greatest banes of open-source software development. GNU/Linux, anyone? For me personally, the idea of someone taking credit for my incomparably brilliant ideas is intolerable.
[My apologies to those offended by my usage of "midgets" in that metaphor; it predates both me and the spirit of political correctness, and it seemed apt.]
>I told her that the greater threat to software developers came from anticompetitive practices by large corporations.
;-)
...not that that's relevant or anything. The presence of a larger threat does not make the smaller threat disappear.
>That ended the conversation.
Maybe she's just not into deprogramming Moonies and Robin Hood wannabes. Lord knows why I still try.
>Piracy, per se, is not the evil here. Failing to reward software developers for their efforts, whether they develop free or proprietary software, is evil.
Well put.
>As a software developer I can honestly say
As a software developer I can honestly say that you don't represent me or my views. Thanks for trying, but you can stop now.
>The people who care about that are in the other wing in
Somebody else made the point that not every software developer works for a behemoth like Microsoft. Many (most?) work on their own, or for small companies that can only dream of making billions of dollars in excess revenue solely due to their market position and not product innovation or quality. I'd say the non-'softies of the world quite often do care about piracy.
That said, you make a good point about copying TV shows. The interesting thing is that TV shows are supported by the advertisers not the viewers. If that weren't the case then the TV people, like the movie people and the record people and the cable people, would care a whole heck of a lot more about piracy.
The big issue is loss of revenue. Maybe nobody cares about the "trading card" warez kiddies or the packrats (though they still doesn't make those people's actions right) but I think people here are unaware of the dimensions of corporate and for-profit piracy. Even if the vendors' claims are somewhat inflated - and I know they are - there are people out there selling pirated software for billions of dollars. By what reasoning should people like that be rewarded instead of the people who wrote the code? What are the consequences of an economy where it's more rewarding to be an uncreative leech than an innovator and builder?
Think about the consequences of your attitudes if applied globally. Personally, I want to reward people who make new things. Some of those people are motivated by altruism or ego, and they write free software; good for them! Other people are motivated by money, and if what they create is worth enough to me I reward them for that by buying it. Other people - pirates, monopolists, government officials - create nothing. The world (my world?) is not improved by their presence, and might well be improved by their absence. Not only do I not want my money going into their pockets, I want that form of livelihood denied them, so they'll be forced to do something constructive for a change.
>Ideas are free. If I understand how a good bicycle is made
So make your own bicycle, i.e. write your own program. Writing a program to do something and pirating a program are two very different things, aren't they? If your version would be "probably inferior" as you say then isn't it possible that you owe the author something for doing it better than you could have? For the time spent designing, testing, documenting and supporting their work, even if you place no value on the bits themselves?
People seem to be hung up on this "they still have a copy" thing. The problem is that software is not just an idea, it's an expression of an idea. The comparison is to books or records, not to bicycles and cars. We could of course have a lot of fun discussing whether it's OK to copy a book or a record. That would be a discussion with some meat to it, but thing I'm convinced of when I read about stealing cars or "MS can afford it" is that teaching ethics (not to mention logic) in schools might not be such a bad thing.
>I may be forced to use their products (e.g., games)
You're forced to play games?
The sad thing is that the notions of things like "force" and "cost" and "rights" represented by the above are not significantly less mature than those in most of the other pro-piracy posts. It's really very very simple: a license agreement is a contract. If the license says don't copy and you do copy, you have broken your word. Whether it's "stealing" to you, whether it harms anyone, whether it furthers some political agenda...you broke a promise. Maybe we shouldn't be stringing up oathbreakers by their thumbs, but it is a moral negative.
If you don't want to pay for software, stick exclusively to free (beer) software. However you rationalize, anything else is immoral.
>Having the market decides works better than you think. The theory is (if you ever took economist)
*Sigh* What purpose is served by such ad hominem attacks? You don't in fact know my views on market efficiency, or how deep my knowledge of economics is. In actual fact, this is still a very hotly debated set of issues, just about the only consensus being that the "solution" probably lies at neither extreme - total laissez-faire or central planning.
>if your product is desirable people will want it, if it's not nobody will
This is overly simplistic. There are other factors, such as availability, pricing, compatibility with other products, monopoly situations, etc.
>Having an external body decide what is good and bad is something only a communist
Again with the grade-school rhetoric, eh?
I am not suggesting, nor is anybody else here, that any central authority - either a government or a monopoly holder, and the two scenarios are actually veryt similar - should decide precisely what products people should buy. All I'm talking about are minimal standards that differentiate honest business from fraud or malpractice. Consumers have a right to expect that bridges and cars and drugs and electrical applicances (including computers) must meet minimum safety standards because even if the market does eventually differentiate between good products and bad it may not be efficient enough to do so before people get hurt. My suggestion is merely that the same idea be extended to software. I'm not talking about feature sets or pricing or bundling or anything other than a very basic promise that the software won't lose or damage your assets in the form of data.
>What you fail to see, is that people WANT microsoft products
No, they put up with Microsoft products, because they perceive the benefits as greater than the costs, and you know what? That's great. I just like to base standards on what is achievable rather than what I can get away with. In a sense, by failing to hold themselves to a higher standard than that absolutely required of them, the whole software industry is acting like one big cartel denying consumers a choice. I would like to see that deadlock broken, and a world created where the creators of quality software are rewarded relative to the purveyors of crap, instead of being pushed out of the market. If you have a better solution, please speak up.
>We all know honor doesn't work. it puts us in neat little boxes and expects us to behave according to some vague rule nobody really understands
Umm, no, we don't "all know" that. Some of us "know" quite differently.
It doesn't matter though, because I at least wasn't talking about honor. I was talking about accountability. You screw someone over, in this case by what amounts to fraud, you pay the price. Your naive version of "let the market decide" is the same justification used by snake-oil salesmen and psychic hotlines, but I think we can do a little better.
>I Agree. Could you sue a software engineer/company for malpractice?
/. audience is not exactly representative of the industry at large...and thank God for that.
Ick, no, I hope not. This society is litigious enough already. My hope is that we can keep things simple, without throwing accountability out the window because it's "too hard".
>How many geeks out there would submit to a professional association, like accountants and solicitors|lawyers? Not many I think..
I agree: not many. The grammar-school libertarians and suspiciously-alike "nonconformists" would never stand for it. Certification of individuals is not really what I'd propose. ISO-9000 "quality school" BS is even worse, focusing either on the wrong parts of the process or on whether it's documented rather than whether it works or is adhered to. What I had in mind was more of a one-time audit, much like when you have an outside accounting firm look at your books, associated with the release of a product to say "yup, somebody made a reasonable effort to test/debug up to reasonable professional standards before it went out the door".
To elaborate a little, we all know that "I don't write code with bugs" is rarely if ever true. All the auditor should need to do is look at a test plan and report and a bug database and make sure they look "kosher". If you don't have a real bug database or a process that includes formal bug reporting the job gets more difficult, but the information may still be there in CVS/RCS logs and the audit might just take a little longer. If you don't even have real source control...well, at some point just about anyone would have to admit that they can't prove the product was properly tested and debugged, and that it shouldn't pass even a relatively informal kind of audit. At that point I have to ask then how the hell do you justify asking customers to pay you and trust you?
Sorry for the shouting. It just seems absurd to me, as a software engineer myself, that software engineers should have absolutely no accountability whatsoever for what they produce, even when they're making a profit, and yet that seems to be precisely what many here believe. That disgusts me, even as I remind myself that the