initial commit, including theme

1 files changed, 51 insertions, 0 deletions

diff --git a/content/posts/2005-08-11-re-news.html b/content/posts/2005-08-11-re-news.html
new file mode 100644
index 0000000..a2ce5c3
--- /dev/null
+++ b/content/posts/2005-08-11-re-news.html
@@ -0,0 +1,51 @@
+---
+date: "2005-08-11T17:29:06Z"
+title: 'Re: News'
+---
+
+<p>
+<a href='http://it.slashdot.org/comments.pl?sid=158670&cid=13295946'>This post</a> on <a href='http://slashdot.org/'>Slashdot</a> is great:
+</p>
+
+<blockquote style='margin: 2em; padding: 0.5em; border: 1px dashed #444; font-size: 80%; background-color: #eee;' cite='http://it.slashdot.org/comments.pl?sid=158670&cid=13295946'>
+<p>
+One of my favorite examples: Some years ago, I worked on a series of projects at a company where the development teams were more or less divided between those that used Sun workstations and those that used Apollos. There was an ongoing discussion of the merits of both. The main argument of the Apollo developers was that you got roughly twice the computing power for a given price with Apollo. Sun was "overpriced and underpowered".
+</p>
+
+<p>
+But Sun slowly won out. What would happen on any project is that you'd be debugging your stuff, and inevitably you'd be led into a system library routine that didn't behave like you expected. With Apollo, when you called Customer Support, the answer was usually "That's proprietary. We can't tell you." Brick wall. You're on your own, and all you can do is start guessing.
+</p>
+
+<p>
+When this happened with Sun, we usually didn't even contact Sun's CS. We asked on one or more of the Sun newsgroups and mailing lists. Within a few hours, we'd usually have an answer. More often than not, the answer came from a Sun engineer. It often came with a chunk of the source, with an offer to send more source if we needed.
+</p>
+
+<p>
+As a result, the Sun developers had working, sellable products much sooner than the Apollo developers. Having a product that works is always better than having a product that doesn't work, even if the price is a bit higher. The company slowly scaled down its use of Apollos. This may have had something to do with why Apollo no longer exists (though www.apollo.com still exists - try it ;-).
+</p>
+
+<p>
+Since then, of course, Sun has slowly taken its systems more and more proprietary. But that's OK, because linux has since arisen to fill Sun's old niche. Same argument: With Sun, you inevitably hit the "We can't tell you - it's proprietary" brick wall. With linux, you have all the source you want, plus a world-wide flock of linux hackers who love to show off their expertise by answering your dumb questions.
+</p>
+
+<p>
+The fun thing in this case is that linux and other open-source software now comes with a license that pretty much prevents anyone from ever closing off access. So it's a lot safer bet for a platform than anything proprietary, no matter how open a company may appear right now.
+</p>
+
+<p>
+Of course, the *BSD systems are about as good in this respect. One might argue that linux is now sufficiently successful that it could use a bit more competition. Maybe we should be pushing the BSDs a bit more loudly. Those people who don't like choice might object, but we'd probably all be better off for it.
+</p>
+
+<p>
+And I wonder how OS X fits into all this? I have a Mac Powerbook, but I've found it much more difficult and time consuming to find reliable low-level information about its innards than with linux. It's only partly for proprietary reasons. Usually it's the "Don't worry your little head about it; it Just Works" attitude. This is very frustrating when you have decades of C hacking behind you, and you're trying to get some low-level code to just work the way you want it to. Instead of a brick wall, you're beating your head against a very soft, fuzzy wall.
+</p>
+
+<p>
+In any case, I'd think that a reasonable software rule now would be: Don't build your product on any platform unless you have all the source. This is now feasible; you get full source with linux and the *BSD systems. So why use a platform that doesn't provide full source?
+</p>
+
+<p>
+And if you don't understand why you need full source, you aren't competent to make business decisions about software development. Hand the decision over to someone who understands. Hire them if you need to. Otherwise, you're risking your business on a foundation of quicksand.
+</p>
+</blockquote>
+