It's never surprising to see yet another attempt to herd the cats that are software engineers towards the greater good that is structured design. And there doesn't seem to be anything particularly interesting or new in this iteration either.
The one important flaw to note about this book is that it treats software engineering as if the lone example of its practice is in the offices of commercial, shrinkwrapped software vendors. It may surprise a lot of people to realize that the total software sales of commercial software products (including all of Microsoft's products, Oracle's, and SAP's) are only a small, small percentage of the amount paid for custom software solutions for industry, government, and the military.
In these non-commercial arenas, strong software engineering disciplines have been the norm for decades. Good design, long development cycles, and carefully engineered software are an absolute requirement when human lives are involved (air traffic control, avionics, flight control systems, manned space flight applications, command and control systems) or extremely expensive hardware is affected (factory production lines, communication satellites, telephone systems, railroads, etc.)
To lump all software developers under the umbrella of the frenzied exercise that passes for software "engineering" in the commercial marketplace is a myopic view at best and is pretty much wrong. Yes, commercial software developers could do a better job. But market pressures don't allow for this, and frankly, they never will. So ranting about making the engineers do things "better" without addressing the market pressures is a waste of effort.
Until the tools, processes, and automation that surround software engineering improve beyond handwritten code in a text editor, this situation cannot improve. If the market continues to apply innovative pressure on the developers, the only way to catch up is to give developers a higher level platform to develop from. Twiddling around in the O/S, pushing bits around in a frame buffer, and spewing characters to and from a hard disk are far, far below the level where software engineering should be practiced, yet that's what most engineers have to suffer through given the relatively primative state of operating systems and development tools.
It's like trying to build a skyscraper with a hammer and a saw.
All of the zealotry over which FPS rulez is gratifying, I'm sure, but it might be revealing to continue this discussion after people have had a chance to actually look throught the code.
First and foremost, this application was written with MPW. That means that it will require significant rework to get it to compile under CodeWarrior. Second, the code is 8 years old. That means it's written to versions of the Mac APIs that are long gone. I didn't look closely, but I didn't see any PPC support, support for UPPs, or many of the other tweaks Apple has forced on developers over the past 4 or 5 revs to the universal headers.
Finally, even if you used the precise version of MPW used to build the program originally, it still wouldn't build because several chunks of code are missing. Don't get me wrong. I'm not faulting Bungie in any way. I think this is a great contribution on their part. But it's still going to be a while before someone steps up and gets this thing to build under a modern development environment on the current version of the O/S.
Re:This REALLY kinks our plans (Score:0) by Anonymous Coward on Thursday January 13, @06:30AM EST (#248) I disagree. You're expecting non-traditionally Linux coders to come over to Linux. Fine. However, you're forcing the traditionalist Linux philosophy on them ("You don't have it? Okay, build it!"). That isn't right.
That was essentially my original point. I never implied that "professional developers buy their tools". What I meant to say was that professional developers have an additional requirement to do things in their economic best interests. In our case, forcing engineers to switch toolsets to something that they feel is a less productive, more complicated environment is not an economically viable option for us right now.
When we were looking at writing a few hundred lines of portability code and then a recompilation with CodeWarrior, Linux versions of our software were a lot closer to reality. Adopting a second, entirely different set of engineering tools and processes is just not an option if the net result is reaching a few dozen more paying customers.
This same problem confronted Adobe when Be approached them to port Photoshop to BeOS. I was in the room with all parties when this was discussed. Jean-Louis made a compelling case for the market and the business opportunity. In the end Adobe decided that the cost to port was too high because (at the time), BeOS didn't have the same standard development tools that Adobe was using for Mac and PC development. Adobe felt the cost of the port would be higher than the revenue they'd see over the next several years, so they simply declined.
In our case, our next product will have a version distibuted for free. So we can't argue this issue from a profit standpoint, only from expense and time to market issues. As a small company, we can't afford hits to either. So having our major productivity "ace-in-the-hole" removed from Linux means that the math now says no port. I'm sure we're not the only company in this position.
What pisses me off is that BIAP makes some cool stuff, and it isn't gonna make it to Linux now.
hehe. Well, there are enough Linux aficionados here in the office that you can bet someone will find a way to get our new stuff running under Linux. All but a few engineers here have at least one machine running Linux. It'll just have to wait until someone has a free weekend to puzzle out the build process and a few GUI issues.
What pisses me off is that BIAP makes some cool stuff, and it isn't gonna make it to Linux now.
hehe. Well, there are enough Linux aficionados here in the office that you can bet someone will find a way to get our new stuff running under Linux. All but a few engineers here have at least one machine running Linux. It'll just have to wait until someone has a free weekend to puzzle out the build process and a few GUI issues.
Another reason: CodeWarrior compiles for Intel x86, and Motorola doesn't want to make software that compiles for its competitor, especially when GCC makes faster code. And if you're worried about difficult GCC assembly syntax, look at NASM, the Netwide Assembler for x86.
You know, I had overlooked that rationale. I'm afraid you might be right, which is even more of a concern when you consider what that might mean for cross-platform work between Windows and Macs with CodeWarrior going forward.
Of course, LinuxPPC's existence flies in the face of that reasoning if Motorola's rationale for terminating the Linux version of CodeWarrior was to restrict x86 competition. In fact, by not releasing CodeWarrior for LinuxPPC, Motorola is actually diminishing their own market share further. Maybe someone should point this out to them?:)
Ultimately, I'm just really disappointed because we enjoy a wonderful development environment where engineers can use whatever platform (Win32 or Mac) they choose, and we have 100% compatibility between the tools. In fact, the Mac users can sit down at a PC and vice versa and know exactly how to use the CodeWarrior tools on either platform. I know there's no other IDE that can make this claim and I was really looking forward to seeing our products on Linux as well using this technology.
Okay, I'll let you argue your point. How about this... GCC is targeted at over a 30 microprocessors.
This is a non-argument. We have only two platforms to support currently (Win32, Mac) and would like to add Linux. That gcc is a Swiss Army Knife of command line options and back ends is irrelevant.
The ONLY relevant issue is that we have a staff of engineers that is familiar with a specific tool, namely CodeWarrior. We have development, QA, and release processes based on this tool. We also have a long standing relationship with the vendor, Metrowerks. That gcc or g++ exists and that some people find it an acceptable development environment in no way makes a compelling case for us abandoning a highly productive environment for one that is clearly an old-style way of doing business and not one our engineers are comfortable in.
So I reiterate my original statement. You probably won't see our products on Linux unless there is an easier, more productive tool set than what comes with a stock Linux install. 20 years of software development has taught me that choosing the right tool for the job is paramount. And gcc/g++ simply isn't the right tool for our job.
You are free to select whatever tools you want, for whatever political, economic, or personal reasons you have. But my choice is based squarely on issues of reliability, economy, performance, and the precise needs of our business. To make our choice for us is a bit presumptuous, don't you think?
Our cross-platform product build process is completely based on Metrowerks' tools. We were promised on several occasions by the president and CTO of Metrowerks that the Linux tools were in the pipeline for release "soon". Metrowerks had already done most of the hard work when they ported their tools for use on Solaris. Supporting Linux just isn't that hard after that. I could give a rat's ass about signing "support Linux" petitions. It's not like corporate software execs are going to pay attention to a list of people who have a credo that says they think all software should be free. That's no motivation for them to expend R&D dollars on a product for a market that doesn't pay for software in general. What I *do* want is someone at Metrowerks to step up and honor the promises they made to hundreds of professional developers that were counting on CodeWarrior tools to deliver cross-platform versions of their product to Linux users. There are plenty of products that will now never see the light of day on Linux because the cost will be too high to retrofit them into the text-only Makefile nightmare that is g++. THAT should be a reason for Linux users to complain -- Metrowerks' decision to cancel this product deprives you of software that otherwise will never be ported from Windows or the Mac because Linux doesn't have the rich set of IDE-based tools that modern developers rely on to deliver code in a cost-effective manner. Please don't consider the previous statement flame bait. It's not. It's a cold, hard fact about managing large, complicated development tasks. There are better ways to do it now in the 21st century than using a directory full of text files glued together with a batch-oriented makefile. Metrowerks has what is arguably one of the best cross-platform environments for doing this and now you'll never see it (or the software that would have been ported with it) because Metrowerks has reneged on a long-standing promise. Boo!
I2 is basically what the internet was back in the 80s and early 90s, before the web took over.
So I2 is now a haven for cheesy little Gopher servers, FTP sites with the latest patches for XTrek, and a sandbox for little toy projects from disgruntled CS professors and their grad student lackies? Sign me up!! Seriously, you say that as if what was happening on the Internet in the late '80s-early '90s was somehow better than what you can do with the Internet now.
The truth is that there was no common standard for data interchange beyond a flat ASCII file. TeX documents were the norm and to read them, you had to print them out. There was no way to build collaborative systems short of cobbling together a bunch of homemade C code and trying to convince others to use it. And the AVERAGE bandwidth of the Internet "backbone" was sub-T1.
Anyone who longs for the "golden days" of the Internet either wasn't there, or isn't participating in today's net in any meaningful way. It just wasn't that exciting.
Is this guy for real? Does this poor, deluded video dweeb actually think that Sony even makes a tiny percentage of its gross income from the PlayStation console? Clearly this is naive, armchair financial analysis from someone who has probably never purchased a share of stock, much less read Sony's balance sheet. The vast bulk of Sony's revenue comes from consumer electronics, corporate, and industrial sales. The video game business is a nice sideline, but it isn't what moves their stock and it isn't what makes or breaks their bottom line. Companies split their stock because they want to keep the price in a certain range to make it attractive to investors, not because of any financial "risk taking" as this article rambles about. Slashdot is falling below its usual standards by pointing to this dreck.
Steve, You've been involved with computers in the class room and bringing computer-related technologies to schools long enough now to seem some of the first students you worked with graduate and go on to college and careers.
How much of a difference do you think technology learning has made for these kids?
What have *you* learned about teaching technology to kids as a result of fostering this process that hasn't yet clicked with mainstream educators?
How do you see current schools and administrations bridging the technology gap between traditional (low tech) classes and curricula and where you'd like to see things?
Netscape was a classic example of a naive, technology-driven start-up unable to cope with a leadership position and an excess of capital. AOL has simply saved the remaining Netscape employees from becoming unemployed and picked up a marginally well-trafficked Web site in the process. All the other problems are of Netscape's own making.
Specifically, they were never able to articulate a compelling technical vision. (c'mon, did *anyone* really think a Web browser was an operating system?) They never shipped a single product that was complete and of sufficient quality to warrant the market share they claimed or the price they charged. They never executed a successful acquisition strategy to do something constructive with the mass of cash they raised in their IPO.
So in the end, they ended up with a bunch of 3 year old technology, nothing new in the pipeline, no partners or acquisitions to take them in a new direction, and competitors that followed a logical path towards the commoditization of Netscape's entire product line.
Anyone with an ounce of business sense predicted in 1995 that Web browsers and Web servers would become integral parts of every operating system and ship on all new computers. Where did Netscape think they were going to make money? They can poor-mouth Microsoft all they want, but they simply put themselves out of business if for no other reason than a lack of vision.
Totally a knee-jerk, uninformed reaction. Read their press release and use your brain to understand what it means. Pez are taking a proactive step to keep porno sites (and others) from hijacking their web site by misappropriating their trademarked name in the hijacker's meta tags.
The hijacker is in effect representing themselves as Pez in order to obtain traffic otherwise destined for Pez's site. If someone put up a billboard on the side of the road that said "Free Pez, call 1-900-NAUGHTY-BITS", I doubt anyone would think poorly of Pez if they sent their lawyers crawling up the pornographers proverbial butt.
This is absolutely no different. In a very specific, defensible way, they have said that misrepresenting yourself as Pez on the Internet by using Pez's trademarks will be considered an infringement and will be prosecuted.
And a note for the armchair lawyers here, "fair use" applies to copyrights, not trademarks. And the current trademark law REQUIRES that a trademark holder defend infringements on their mark or risk losing it to the public domain. Any responsible business SHOULD do this. I think Pez has chosen a completely acceptable approach to a problem that afflicts a huge number of sites. I hope they follow through and actually sue some of the hijackers.
Or do you think that porno sites *should* be able to hijack traffic otherwise bound for businesses by using a trademark they don't hold in the meta tags of their site?
Apple's attempt to position the G4 as an ueber-computer is missing the point. It's still difficult to upgrade and loaded with proprietary hardware.
Hmmm, is it the PCI bus, the IDE controller, the USB ports, or the FireWire interface that makes it difficult to upgrade? Oh yeah, maybe it's the ethernet port, or perhaps it's the SVGA connector? Maybe you meant the three-prong electric connection?
What, specifically, did you mean by "difficult to upgrade" and "proprietary hardware"? Have you used, owned, or even looked at a Mac since the Mac Plus? Your dogma regarding Macs needs to be upgraded to reflect something bordering on reality...
Back in '93-'94, O'Reilly was one of the true Web pioneers with one of the first portals (GNN) and a stable of commercial Web servers (I know, you almost landed my MacHTTP product as one of them). Web servers obviously turned out to be a commodity business, but I wonder if you have any thoughts or regrets regarding the early sale of GNN?
Contrary to popular myth, companies that open source their product line don't survive in this industry (in any meaningful way). They simply cannot generate the revenue required to compete with all the companies that retain their competitive advantage.
Please tell this to RedHat. They are doing it right. RedHat doesn't slave away creating huge monstrous projects then just releasing them for free! They take what is out there, add value and support, and sell the added value and support. True, they also contribute code, but this is only part of their overall strategy. I read through the prospectus for Red Hat's IPO. Perusing their financial statements certainly lends credence to my statement at top. While RedHat was in the (small) business of burning CDs with a specific Linux distribution on them and selling them through book stores and retail software channels, they probably stayed in the black. But I suspect it will be a long time (if ever) before they see profits again.
They're entering into a commodity business that has very slim margins, especially when smaller companies can simply take the RedHat distribution and redistribute it. Any serious innovations that RedHat makes (or invests in) will be yet another reason for them to have to figure out a way to recover the cost. Pressing CDs isn't the way. Getting into the body shop business of providing tech support isn't the way either.
I'm not anti-Red Hat by any measure. I think what they've accomplished is commendable. But I also think the jury is still out on whether their business model can survive, much less flourish with low-overhead competition that can offer a similar product with zero overhead. Red Hat has benefitted from some amazing timing, positive press, and a lot of anti-Microsoft sentiment. Just like Netscape....
It's not whether Open Source for Windows is more or less important than Open Source for Unix. The issue is more properly defined in terms of the respective marketplaces for products on the two operating systems. The right question is "Is Open Source less important in a commercially-driven marketplace than in a freeware/shareware/public domain marketplace?"
The obvious answer is yes, Open Source (at least as far as it is defined with respect to the GNU Copyleft definition) is not only less important, but almost undesirable in the commercial marketplace. There are certain areas where commercial advantage can be gained by "open sourcing" libraries, protocols, and other building block technologies. But companies with millions in revenue and hundreds of employees to support will not be able to build a credible business case for engineering based on a concept that boils down to "whatever innovations we create will be made immediately available to our competitors."
Contrary to popular myth, companies that open source their product line don't survive in this industry (in any meaningful way). They simply cannot generate the revenue required to compete with all the companies that retain their competitive advantage.
On platforms where the commercial developer community is small (i.e., Linux et al.) relative to the industry as a whole, open sourcing makes a lot more sense since most of the products are still small enough in scope to be engineered by a handful of individuals sharing technologies. At the point a 20 person team is required to engineer, distribute, and support a Linux app, you'll quickly see how little of it ends up being open sourced simply due to the economics.
And I'm not talking about 20 people hacking a Linux kernel in their spare time. I'm talking about a full time staff of engineers, tech writers, QA personnel, tech support, and management. You can't make that sort of enterprise function without revenue and positive cash flow.
Here's what we do to handle back-ups for an entire LAN of mixed machine types. First, we have a SCSI DAT II drive hooked up to the Linux box and a cron task that runs nightly and backs up all the contents of a single directory (/home/shared in our case.)
We also have samba and netatalk installed on this machine so both Macs and PCs can mount the shared volume as a network volume. We then use platform-specific back-up tools (Retrospect from Dantz in this case for both machine types, but you can mix and match)on each machine to write back-up archives to the shared Linux volume.
The cron task fires up tar at 4 AM and streams the whole pile of archives off to tape. First person in in the morning swaps tapes.
One advantage of using Retrospect is that it can perform Mac and PC back-ups via FTP, without the need to mount a shared volume.
There is a better solution to the spam problem, but it involves upgrading the e-mail (SMTP) backbone to something beyond 1975 technology.
Specifically, e-mail should contain a header with an authenticated signature for the originator. Any mail message that doesn't contain an authenticated signature can be refused at the server level and the spam problem will stop much closer to its source.
Unfortunately, that means that someone somewhere would have to manage a pretty large key repository for everyone who wanted to send e-mail outside of their LAN. Still, it's not an insurmountable problem, since we already have to maintain an equally large repository of information, namely the DNS system. It's more efficient than DNS, since you don't have to check the signature at every mail hop, just when you want to verify someone's identity.
And this doesn't preclude sending mail in the form (essentially anonymous) that we use today. The lack of any authentication in mail messages today doesn't prevent people from using it. If you choose to opt out of sending authenticated mail, you just have to be prepared to have intervening systems refuse to carry your mail traffic.
I guess this really boils down to providing a more robust SMTP server architecture that really validates senders of mail before propogating the messages. Client side and legislative solutions are doomed to failure as long as spammers get to ride the mail backbone anonymously and free of charge.
It's odd, but there still seems to be a serious lack of good wireless ethernet hardware at affordable prices. I don't understand why there aren't more solutions to this problem given all the initiatives to free up frequencies for just this purpose and the availability of low-cost radios on a chip, etc. I gave up on shopping based on price and opted for the most functional solution.
After a lot of analysis, the BreezeNet series of devices bubbled to the top of the heap. They are NOT cheap, but they will plug into any ethernet NIC and provide totally transparent 1.5 mbit to 2.5 mbit connectivity between a wired LAN and wireless nodes, or between wireless stations only. Details are at http://www.breezecom.com/Products/brz nprd.htm.
Unfortunately, a 2 node set-up (for example) will cost well over $1000. The access points (wireless hubs if you will) are around $1000, but you only need one of them. The "stand-alone" stations for individual ethernet interfaces are about $400, if I recall correctly.
The stuff has fantastic range (well over 500 feet through walls between 2 buildings with little signal loss in my case), requires absolutely no configuration, and works with any 10baseT ethernet device. My only complaint is the expense. If someone made similar hardware at a $200/node price point, they'd own this market.
FWIW, I have no connection with BreezeCom other than as a satisfied user of the BreezeNet hardware.
Graydon's essay is interesting, but definitely not a new proposal. Allowing talented developers to post info on areas they are working in or are interested in working in and having companies purchase the rights to the completed work by funding it is something we tried several years ago.
We termed it the "rock band" approach to software development. Like a good band, you get some of the best musicians (developers) together, come up with some good music (software), and find a record label to produce and publish it. You get all the creative aspects of coming up with your own stuff and all the benefits of having someone pay you to do it. It was a win-win because companies only sponsored/funded/bought stuff that fit in with their business directions and the developers got to build stuff that they owned if no one else wanted to buy it.
Unfortunately, every single company we talked to (and we talked to a LOT, from Adobe, Apple, and Microsoft, to IBM, Dell, and NASA) not only failed to see the benefits of this arrangement, but actually thought it was such an alien concept that they generally dismissed it out of hand.
The 2 barriers seemed to be the need for some serious marketing horsepower on the part of the "rock band" and a fundamental shift in how companies acquire software engineered outside the narrow confines of their own organizations.
In short, Graydon's proposal (and the "rock band") will only work if the developers' reputations are sufficiently high that the quality of the product can be guaranteed, if there is sufficient marketing muscle behind the developers to get the word out about the new approach to developing outsourced code, and a sufficient number of companies decide to adopt the new approach. Otherwise, this is just another nice idea to be dismissed out of hand (again.)
To paraphrase, "Those who can, do. Those who can't, regulate."
This is a total crock. Why is it that the marginal elements in the software industry always want to regulate, control, organize, or otherwise stick their fingers in a pie that they aren't baking?
This is a free market economy (or at least the closest facsimile to one on the planet.) The market will correct for abberrations in quality, customer support, or any other problem that these bureaucrats want to help resolve. There is very little to be gained from this proposal that can't already be handled with existing consumer protections, industry standards, and a little common sense.
Slashdot Mirror
The one important flaw to note about this book is that it treats software engineering as if the lone example of its practice is in the offices of commercial, shrinkwrapped software vendors. It may surprise a lot of people to realize that the total software sales of commercial software products (including all of Microsoft's products, Oracle's, and SAP's) are only a small, small percentage of the amount paid for custom software solutions for industry, government, and the military.
In these non-commercial arenas, strong software engineering disciplines have been the norm for decades. Good design, long development cycles, and carefully engineered software are an absolute requirement when human lives are involved (air traffic control, avionics, flight control systems, manned space flight applications, command and control systems) or extremely expensive hardware is affected (factory production lines, communication satellites, telephone systems, railroads, etc.)
To lump all software developers under the umbrella of the frenzied exercise that passes for software "engineering" in the commercial marketplace is a myopic view at best and is pretty much wrong. Yes, commercial software developers could do a better job. But market pressures don't allow for this, and frankly, they never will. So ranting about making the engineers do things "better" without addressing the market pressures is a waste of effort.
Until the tools, processes, and automation that surround software engineering improve beyond handwritten code in a text editor, this situation cannot improve. If the market continues to apply innovative pressure on the developers, the only way to catch up is to give developers a higher level platform to develop from. Twiddling around in the O/S, pushing bits around in a frame buffer, and spewing characters to and from a hard disk are far, far below the level where software engineering should be practiced, yet that's what most engineers have to suffer through given the relatively primative state of operating systems and development tools.
It's like trying to build a skyscraper with a hammer and a saw.
First and foremost, this application was written with MPW. That means that it will require significant rework to get it to compile under CodeWarrior. Second, the code is 8 years old. That means it's written to versions of the Mac APIs that are long gone. I didn't look closely, but I didn't see any PPC support, support for UPPs, or many of the other tweaks Apple has forced on developers over the past 4 or 5 revs to the universal headers.
Finally, even if you used the precise version of MPW used to build the program originally, it still wouldn't build because several chunks of code are missing. Don't get me wrong. I'm not faulting Bungie in any way. I think this is a great contribution on their part. But it's still going to be a while before someone steps up and gets this thing to build under a modern development environment on the current version of the O/S.
Anyone gotten started on it yet? ;)
That was essentially my original point. I never implied that "professional developers buy their tools". What I meant to say was that professional developers have an additional requirement to do things in their economic best interests. In our case, forcing engineers to switch toolsets to something that they feel is a less productive, more complicated environment is not an economically viable option for us right now.
When we were looking at writing a few hundred lines of portability code and then a recompilation with CodeWarrior, Linux versions of our software were a lot closer to reality. Adopting a second, entirely different set of engineering tools and processes is just not an option if the net result is reaching a few dozen more paying customers.
This same problem confronted Adobe when Be approached them to port Photoshop to BeOS. I was in the room with all parties when this was discussed. Jean-Louis made a compelling case for the market and the business opportunity. In the end Adobe decided that the cost to port was too high because (at the time), BeOS didn't have the same standard development tools that Adobe was using for Mac and PC development. Adobe felt the cost of the port would be higher than the revenue they'd see over the next several years, so they simply declined.
In our case, our next product will have a version distibuted for free. So we can't argue this issue from a profit standpoint, only from expense and time to market issues. As a small company, we can't afford hits to either. So having our major productivity "ace-in-the-hole" removed from Linux means that the math now says no port. I'm sure we're not the only company in this position.
hehe. Well, there are enough Linux aficionados here in the office that you can bet someone will find a way to get our new stuff running under Linux. All but a few engineers here have at least one machine running Linux. It'll just have to wait until someone has a free weekend to puzzle out the build process and a few GUI issues.
hehe. Well, there are enough Linux aficionados here in the office that you can bet someone will find a way to get our new stuff running under Linux. All but a few engineers here have at least one machine running Linux. It'll just have to wait until someone has a free weekend to puzzle out the build process and a few GUI issues.
You know, I had overlooked that rationale. I'm afraid you might be right, which is even more of a concern when you consider what that might mean for cross-platform work between Windows and Macs with CodeWarrior going forward.
Of course, LinuxPPC's existence flies in the face of that reasoning if Motorola's rationale for terminating the Linux version of CodeWarrior was to restrict x86 competition. In fact, by not releasing CodeWarrior for LinuxPPC, Motorola is actually diminishing their own market share further. Maybe someone should point this out to them? :)
Ultimately, I'm just really disappointed because we enjoy a wonderful development environment where engineers can use whatever platform (Win32 or Mac) they choose, and we have 100% compatibility between the tools. In fact, the Mac users can sit down at a PC and vice versa and know exactly how to use the CodeWarrior tools on either platform. I know there's no other IDE that can make this claim and I was really looking forward to seeing our products on Linux as well using this technology.
This is a non-argument. We have only two platforms to support currently (Win32, Mac) and would like to add Linux. That gcc is a Swiss Army Knife of command line options and back ends is irrelevant.
The ONLY relevant issue is that we have a staff of engineers that is familiar with a specific tool, namely CodeWarrior. We have development, QA, and release processes based on this tool. We also have a long standing relationship with the vendor, Metrowerks. That gcc or g++ exists and that some people find it an acceptable development environment in no way makes a compelling case for us abandoning a highly productive environment for one that is clearly an old-style way of doing business and not one our engineers are comfortable in.
So I reiterate my original statement. You probably won't see our products on Linux unless there is an easier, more productive tool set than what comes with a stock Linux install. 20 years of software development has taught me that choosing the right tool for the job is paramount. And gcc/g++ simply isn't the right tool for our job.
You are free to select whatever tools you want, for whatever political, economic, or personal reasons you have. But my choice is based squarely on issues of reliability, economy, performance, and the precise needs of our business. To make our choice for us is a bit presumptuous, don't you think?
Our cross-platform product build process is completely based on Metrowerks' tools. We were promised on several occasions by the president and CTO of Metrowerks that the Linux tools were in the pipeline for release "soon". Metrowerks had already done most of the hard work when they ported their tools for use on Solaris. Supporting Linux just isn't that hard after that. I could give a rat's ass about signing "support Linux" petitions. It's not like corporate software execs are going to pay attention to a list of people who have a credo that says they think all software should be free. That's no motivation for them to expend R&D dollars on a product for a market that doesn't pay for software in general. What I *do* want is someone at Metrowerks to step up and honor the promises they made to hundreds of professional developers that were counting on CodeWarrior tools to deliver cross-platform versions of their product to Linux users. There are plenty of products that will now never see the light of day on Linux because the cost will be too high to retrofit them into the text-only Makefile nightmare that is g++. THAT should be a reason for Linux users to complain -- Metrowerks' decision to cancel this product deprives you of software that otherwise will never be ported from Windows or the Mac because Linux doesn't have the rich set of IDE-based tools that modern developers rely on to deliver code in a cost-effective manner. Please don't consider the previous statement flame bait. It's not. It's a cold, hard fact about managing large, complicated development tasks. There are better ways to do it now in the 21st century than using a directory full of text files glued together with a batch-oriented makefile. Metrowerks has what is arguably one of the best cross-platform environments for doing this and now you'll never see it (or the software that would have been ported with it) because Metrowerks has reneged on a long-standing promise. Boo!
So I2 is now a haven for cheesy little Gopher servers, FTP sites with the latest patches for XTrek, and a sandbox for little toy projects from disgruntled CS professors and their grad student lackies? Sign me up!! Seriously, you say that as if what was happening on the Internet in the late '80s-early '90s was somehow better than what you can do with the Internet now.
The truth is that there was no common standard for data interchange beyond a flat ASCII file. TeX documents were the norm and to read them, you had to print them out. There was no way to build collaborative systems short of cobbling together a bunch of homemade C code and trying to convince others to use it. And the AVERAGE bandwidth of the Internet "backbone" was sub-T1.
Anyone who longs for the "golden days" of the Internet either wasn't there, or isn't participating in today's net in any meaningful way. It just wasn't that exciting.
Is this guy for real? Does this poor, deluded video dweeb actually think that Sony even makes a tiny percentage of its gross income from the PlayStation console? Clearly this is naive, armchair financial analysis from someone who has probably never purchased a share of stock, much less read Sony's balance sheet. The vast bulk of Sony's revenue comes from consumer electronics, corporate, and industrial sales. The video game business is a nice sideline, but it isn't what moves their stock and it isn't what makes or breaks their bottom line. Companies split their stock because they want to keep the price in a certain range to make it attractive to investors, not because of any financial "risk taking" as this article rambles about. Slashdot is falling below its usual standards by pointing to this dreck.
Steve,
You've been involved with computers in the class room and bringing computer-related technologies to schools long enough now to seem some of the first students you worked with graduate and go on to college and careers.
How much of a difference do you think technology learning has made for these kids?
What have *you* learned about teaching technology to kids as a result of fostering this process that hasn't yet clicked with mainstream educators?
How do you see current schools and administrations bridging the technology gap between traditional (low tech) classes and curricula and where you'd like to see things?
Netscape was a classic example of a naive, technology-driven start-up unable to cope with a leadership position and an excess of capital. AOL has simply saved the remaining Netscape employees from becoming unemployed and picked up a marginally well-trafficked Web site in the process. All the other problems are of Netscape's own making.
Specifically, they were never able to articulate a compelling technical vision. (c'mon, did *anyone* really think a Web browser was an operating system?) They never shipped a single product that was complete and of sufficient quality to warrant the market share they claimed or the price they charged. They never executed a successful acquisition strategy to do something constructive with the mass of cash they raised in their IPO.
So in the end, they ended up with a bunch of 3 year old technology, nothing new in the pipeline, no partners or acquisitions to take them in a new direction, and competitors that followed a logical path towards the commoditization of Netscape's entire product line.
Anyone with an ounce of business sense predicted in 1995 that Web browsers and Web servers would become integral parts of every operating system and ship on all new computers. Where did Netscape think they were going to make money? They can poor-mouth Microsoft all they want, but they simply put themselves out of business if for no other reason than a lack of vision.
Totally a knee-jerk, uninformed reaction. Read their press release and use your brain to understand what it means. Pez are taking a proactive step to keep porno sites (and others) from hijacking their web site by misappropriating their trademarked name in the hijacker's meta tags.
The hijacker is in effect representing themselves as Pez in order to obtain traffic otherwise destined for Pez's site. If someone put up a billboard on the side of the road that said "Free Pez, call 1-900-NAUGHTY-BITS", I doubt anyone would think poorly of Pez if they sent their lawyers crawling up the pornographers proverbial butt.
This is absolutely no different. In a very specific, defensible way, they have said that misrepresenting yourself as Pez on the Internet by using Pez's trademarks will be considered an infringement and will be prosecuted.
And a note for the armchair lawyers here, "fair use" applies to copyrights, not trademarks. And the current trademark law REQUIRES that a trademark holder defend infringements on their mark or risk losing it to the public domain. Any responsible business SHOULD do this. I think Pez has chosen a completely acceptable approach to a problem that afflicts a huge number of sites. I hope they follow through and actually sue some of the hijackers.
Or do you think that porno sites *should* be able to hijack traffic otherwise bound for businesses by using a trademark they don't hold in the meta tags of their site?
hardware.
Hmmm, is it the PCI bus, the IDE controller, the USB ports, or the FireWire interface that makes it difficult to upgrade? Oh yeah, maybe it's the ethernet port, or perhaps it's the SVGA connector? Maybe you meant the three-prong electric connection?
What, specifically, did you mean by "difficult to upgrade" and "proprietary hardware"? Have you used, owned, or even looked at a Mac since the Mac Plus? Your dogma regarding Macs needs to be upgraded to reflect something bordering on reality...
Back in '93-'94, O'Reilly was one of the true Web pioneers with one of the first portals (GNN) and a stable of commercial Web servers (I know, you almost landed my MacHTTP product as one of them). Web servers obviously turned out to be a commodity business, but I wonder if you have any thoughts or regrets regarding the early sale of GNN?
Please tell this to RedHat. They are doing it right. RedHat doesn't slave away creating huge monstrous projects then just releasing them for free! They take what is out there, add value and support, and sell the added value and support. True, they also contribute code, but this is only part of their overall strategy. I read through the prospectus for Red Hat's IPO. Perusing their financial statements certainly lends credence to my statement at top. While RedHat was in the (small) business of burning CDs with a specific Linux distribution on them and selling them through book stores and retail software channels, they probably stayed in the black. But I suspect it will be a long time (if ever) before they see profits again.
They're entering into a commodity business that has very slim margins, especially when smaller companies can simply take the RedHat distribution and redistribute it. Any serious innovations that RedHat makes (or invests in) will be yet another reason for them to have to figure out a way to recover the cost. Pressing CDs isn't the way. Getting into the body shop business of providing tech support isn't the way either.
I'm not anti-Red Hat by any measure. I think what they've accomplished is commendable. But I also think the jury is still out on whether their business model can survive, much less flourish with low-overhead competition that can offer a similar product with zero overhead. Red Hat has benefitted from some amazing timing, positive press, and a lot of anti-Microsoft sentiment. Just like Netscape....
It's not whether Open Source for Windows is more or less important than Open Source for Unix. The issue is more properly defined in terms of the respective marketplaces for products on the two operating systems. The right question is "Is Open Source less important in a commercially-driven marketplace than in a freeware/shareware/public domain marketplace?"
The obvious answer is yes, Open Source (at least as far as it is defined with respect to the GNU Copyleft definition) is not only less important, but almost undesirable in the commercial marketplace. There are certain areas where commercial advantage can be gained by "open sourcing" libraries, protocols, and other building block technologies. But companies with millions in revenue and hundreds of employees to support will not be able to build a credible business case for engineering based on a concept that boils down to "whatever innovations we create will be made immediately available to our competitors."
Contrary to popular myth, companies that open source their product line don't survive in this industry (in any meaningful way). They simply cannot generate the revenue required to compete with all the companies that retain their competitive advantage.
On platforms where the commercial developer community is small (i.e., Linux et al.) relative to the industry as a whole, open sourcing makes a lot more sense since most of the products are still small enough in scope to be engineered by a handful of individuals sharing technologies. At the point a 20 person team is required to engineer, distribute, and support a Linux app, you'll quickly see how little of it ends up being open sourced simply due to the economics.
And I'm not talking about 20 people hacking a Linux kernel in their spare time. I'm talking about a full time staff of engineers, tech writers, QA personnel, tech support, and management. You can't make that sort of enterprise function without revenue and positive cash flow.
Here's what we do to handle back-ups for an entire LAN of mixed machine types. First, we have a SCSI DAT II drive hooked up to the Linux box and a cron task that runs nightly and backs up all the contents of a single directory (/home/shared in our case.)
We also have samba and netatalk installed on this machine so both Macs and PCs can mount the shared volume as a network volume. We then use platform-specific back-up tools (Retrospect from Dantz in this case for both machine types, but you can mix and match)on each machine to write back-up archives to the shared Linux volume.
The cron task fires up tar at 4 AM and streams the whole pile of archives off to tape. First person in in the morning swaps tapes.
One advantage of using Retrospect is that it can perform Mac and PC back-ups via FTP, without the need to mount a shared volume.
C.
There is a better solution to the spam problem, but it involves upgrading the e-mail (SMTP) backbone to something beyond 1975 technology.
Specifically, e-mail should contain a header with an authenticated signature for the originator. Any mail message that doesn't contain an authenticated signature can be refused at the server level and the spam problem will stop much closer to its source.
Unfortunately, that means that someone somewhere would have to manage a pretty large key repository for everyone who wanted to send e-mail outside of their LAN. Still, it's not an insurmountable problem, since we already have to maintain an equally large repository of information, namely the DNS system. It's more efficient than DNS, since you don't have to check the signature at every mail hop, just when you want to verify someone's identity.
And this doesn't preclude sending mail in the form (essentially anonymous) that we use today. The lack of any authentication in mail messages today doesn't prevent people from using it. If you choose to opt out of sending authenticated mail, you just have to be prepared to have intervening systems refuse to carry your mail traffic.
I guess this really boils down to providing a more robust SMTP server architecture that really validates senders of mail before propogating the messages. Client side and legislative solutions are doomed to failure as long as spammers get to ride the mail backbone anonymously and free of charge.
After a lot of analysis, the BreezeNet series of devices bubbled to the top of the heap. They are NOT cheap, but they will plug into any ethernet NIC and provide totally transparent 1.5 mbit to 2.5 mbit connectivity between a wired LAN and wireless nodes, or between wireless stations only. Details are at http://www.breezecom.com/Products/brz nprd.htm.
Unfortunately, a 2 node set-up (for example) will cost well over $1000. The access points (wireless hubs if you will) are around $1000, but you only need one of them. The "stand-alone" stations for individual ethernet interfaces are about $400, if I recall correctly.
The stuff has fantastic range (well over 500 feet through walls between 2 buildings with little signal loss in my case), requires absolutely no configuration, and works with any 10baseT ethernet device. My only complaint is the expense. If someone made similar hardware at a $200/node price point, they'd own this market.
FWIW, I have no connection with BreezeCom other than as a satisfied user of the BreezeNet hardware.
Graydon's essay is interesting, but definitely not a new proposal. Allowing talented developers to post info on areas they are working in or are interested in working in and having companies purchase the rights to the completed work by funding it is something we tried several years ago.
We termed it the "rock band" approach to software development. Like a good band, you get some of the best musicians (developers) together, come up with some good music (software), and find a record label to produce and publish it. You get all the creative aspects of coming up with your own stuff and all the benefits of having someone pay you to do it. It was a win-win because companies only sponsored/funded/bought stuff that fit in with their business directions and the developers got to build stuff that they owned if no one else wanted to buy it.
Unfortunately, every single company we talked to (and we talked to a LOT, from Adobe, Apple, and Microsoft, to IBM, Dell, and NASA) not only failed to see the benefits of this arrangement, but actually thought it was such an alien concept that they generally dismissed it out of hand.
The 2 barriers seemed to be the need for some serious marketing horsepower on the part of the "rock band" and a fundamental shift in how companies acquire software engineered outside the narrow confines of their own organizations.
In short, Graydon's proposal (and the "rock band") will only work if the developers' reputations are sufficiently high that the quality of the product can be guaranteed, if there is sufficient marketing muscle behind the developers to get the word out about the new approach to developing outsourced code, and a sufficient number of companies decide to adopt the new approach. Otherwise, this is just another nice idea to be dismissed out of hand (again.)
To paraphrase, "Those who can, do. Those who can't, regulate."
This is a total crock. Why is it that the marginal elements in the software industry always want to regulate, control, organize, or otherwise stick their fingers in a pie that they aren't baking?
This is a free market economy (or at least the closest facsimile to one on the planet.) The market will correct for abberrations in quality, customer support, or any other problem that these bureaucrats want to help resolve. There is very little to be gained from this proposal that can't already be handled with existing consumer protections, industry standards, and a little common sense.