« March 2003 | Main | May 2003 »
April 30, 2003
On Belay
Tristen took me climbing today, sort of. I knew she did a lot of climbing, and took her up on an offer to teach me some of it. We quickly ran through the rope basics, knots, terminology, and safety mechanisms. She went through them like a pro, right up until I said I'm left handed. Then she had a few problems, but they were easily sorted out.
The top rope climbing took only a few minutes to accomplish, and frankly my first climb was an easy one (5.5 or 5.6). I had made it to about one hand hold away from the top before I lost my grip (my foot slipped off while I was dependent upon it). I subsequently spent a few minutes afterwards working on getting a strong grip with my toes on non-existent holds at base.
Afterwards, Tristen and Emily (another girl at the wall) started doing bouldering. Essentially, they free climb (no ropes) and would place a hand somewhere. This hand pattern had to be continued and extended by each player. I get suckered into it, and started off okay. Not nearly as agile as they I picked the worst hold I could find, but they worked around it. I never could get past it after that. It was interesting to watch Tristen and Emily work the wall though, as you could see in their technique they have been doing this for sometime. It was impressive to watch as they would time their swings to provide optimal foot movements and hand gripping moments. I'll probably try to keep doing this over the summer, but it looks like one more expensive hobby right now. I do suggest trying it if you get a chance. It was a nice stress relief from the rest of the day/week/month.
Posted by Dan at 01:21 PM | Comments (0)
April 28, 2003
Is Ivy League worth it?
Kate sent me an article the other day, that questions if the higher cost of a "top tier" school is justified by the expectant salary difference. An interesting argument the researchers Alan Krueger and Stacy Dale make is that it's not really where you are trained that makes a person exceptional. Rather it is your natural drive and desire to succeed that is of importance and ultimately determines an individuals final worth. This feels, to me, like the whole nature vs nurture argument all over again.
The article can be used as the basis though for either side to push their opinion. As with all mainstream media though, it adds a catch all of "take all this [information] with a grain of salt" line, hoping to provide itself an easy way out if wrong. Gotta love lawyers.
Posted by Dan at 03:37 PM | Comments (1)
April 26, 2003
Future Crawlers
Awhile back I remember Microsoft claiming that they were going to get into the search game. While I can't find the specific article off hand, I did notice this in my most recent robot access log:
131.107.163.46 - - [26/Apr/2003:20:54:49 -0400] "GET /robots.txt HTTP/1.1" 200 237 "-" "MicrosoftPrototypeCrawler (How's my crawling? mailto:newbiecrawler@hotmail.com)"
Looks like they are starting to make good on this promise. Now spammers do your thing...
Posted by Dan at 06:05 PM | Comments (0)
April 25, 2003
Economics of Information Security
I recently had the opportunity to hear Dr. Ross Anderson of Cambridge University speak on the Information Security and Public Policy.
The talk started off discussing the failures of information security, why each has happened, and closes with the trends he sees happening in computing today. With the first failure he starts describing why cryptology has been a disappointment in many ways. It can be condensed down to because the direct impact of cryptos failure is not felt by those directly involved, but rather by those of a second party (or one step removed). His example cases were previous incidents of European banks having phantom transfers occur. The banks main point was that their security was infallible, and as such each customer must have made such a transaction. The problem with this idea is that you can't disprove the infallibility as a victim of such actions. Here in the US, a New York court case held in 1976 resulted in a ruling that bank machine logs were not substantial enough to prove that a customer did or did not do a transaction (thus they are not infallible). In this case public policy has dictated that a stronger means of security (logs and another form) be used rather than placing an implicit trust on it (log files only). This tidbit made me consider if this is why we have video cameras attached to ATMs, not for the purported public safety aspects (a value added side benefit). He points out an interesting comparison though; The US spends less money on security precautions than Europe does (with regards to banking), and yet it has less fraud too. While he didn't provide data to back this, it is certainly an interesting side effect that would be interesting to research.
Distributed Denial of Service attacks (DDoS) were another bit he touched upon. His main point with these is that we can currently implement systems to prevent this, but there is no reason to. When investigated further it breaks down to there is no direct financial reasoning to provide such a service. In the past when a virus would infect and destroy information on your local machine/network, the $N investment had a direct effect on you, your information, and your safety. Now with the use of distributed systems, implementing, at cost, a security system to help others provides no direct benefit to you as a user. It could, to use an example he did, benefit Microsoft X times more than it could benefit you. The only way I've really been able to discredit this theory is through groups that pay per month on bandwidth usage, but those typically have a cap system already in place.
With these kinds of ideals, how is it that software is able to generate any money? When looking at the traditional sense of economics, one typically looks at the marginal cost for a sense of possible income. In the case of software, while it may cost $N millions in research and development, the after effect is it costs nearly nothing to mass produce (depending upon a shrink-wrapped or electronic distribution). So how do software companies ensure their livelihood? The cost of switching. The total time to convert your current information over to the new formats, and total monetary costs are what keep people from switching.
Dr. Anderson points out that there are really two routes that could be taken here with regards to preventing user switching. The easier route, which includes locking users into a one format lifestyle much the way Microsoft has done. This creates an arena for which to keep users that makes it near impossible to get out of. The harder, but (purported) more prosperous, route is to become the universal enabler that allows access and interaction to all currently known formats. This format is harder due to the nature of supporting all these formats, and the ease of which you provide for switching from one format to another.
The effects of the easier route can be seen in everyday software. The need to release early and often can be directly traced back to the need to keep users confined within the format arena. If a competitor releases a product quicker you may loose userbase. Because of this confinement, the creation of the 3-version release process becomes essential to implementing and integrating any form of working security considerations (and stable software).
The effects of this kind of thinking are not limited to software only, and can be found in the hardware world pretty easily. Take for example the use of Motorola cellular phones. The battery contains a group of four connectors that power a special key chip. If the key chip matches a series known by Motorola (usually only sold by Motorola), the battery will work a lot longer. If it doesn't match the phone turns up the power consumption resulting in a shorter lifespan of the "alien" battery. Supposedly Motorola had put up a reasoning for this in the past but had taken it down for the poor wording choices. Dr. Anderson has stated he's mirrored the page somewhere on his site if you decide to investigate further.
Another example used in the lecture were toner cartridges for printers (Lexmark in particular). In this case they slowly begin to cut down the number of dots per inch produced on an "alien" cartridge, hopefully to get you to replace it with a "proper" piece. Remember the bit about public policy in the topic? Turns out that European legislators are planning to pass a regulation that requires all toner cartridges be refillable (presumably in a standard fashion). The logic behind this regulation is simple; environmental requirements. We will not have regulations that cut into corporate profit in an effort to save environmental conditions. This will surely cause a change (or at least a conflict) with thinking in the United States.
So why all these ploys to make the customers life difficult? Examining the data a bit, it stands to show that Motorola makes most of it's money off of cell phone batteries, not the phone itself. The same is true for printer makers and the toner cartridges, which makes sense given the number of times these are replaced vs printers themselves.
What this leaves you the customer with is better known as a trusted computer. But it's late now, and there is a lot of information to remember, digest, rethink, and type out on this topic so I'll have it for another day.
Posted by Dan at 10:15 PM | Comments (0)
April 24, 2003
Quoting
"Reports of my death are greatly exaggerated." -Samuel Clemens June 2 1897.
The silence seen on postings are due to an overwhelming amount of work to be accomplished in an extraordinarily short period of time. Worry not I've some interesting bits to post online soon as I have a moment to type them up.
The server has been acting strange lately though with electrical power issues that seem to be happening at random. Anyone have suggestions for checking a power supply on a colo'd box?
Posted by Dan at 08:16 AM | Comments (0)
April 15, 2003
Privacy Threat Index
EPIC has created a new Privacy Threat Index much like that of the Homeland security Index. It's color coded and even labeled! The parody level hasn't been lost on me, and the potential usefulness is there. So I followed the directions and linked to it from their mailing.
If you look down on the right hand side of the blog you should see it... sort of. It seems that EPIC hasn't even properly setup the GIF file yet. After doing a bit more research it turns out that threat_index.gif is not the file to be linking to, but rather threat_levels.gif.
What's happened to checking your press releases before release? Of course, they've also stuck it on that god awful blue background so it will cause an insta-clash with any color scheme you may choose. Couldn't this be done with just a nice bit of CSS so that it won't look so shoddy?
Posted by Dan at 06:12 AM | Comments (0)
April 14, 2003
Good Laws
An article in the SFGate over the weekend got my attention. Apparently the town of Arcata has made it illegal to voluntarily assist with the Patriot Act. It's nice to see that there are some areas where sanity still rules.
The article does mention that many cities have passed resolutions condemning it, but there really is no muscle behind a resolution.
Posted by Dan at 06:30 AM | Comments (0)
April 12, 2003
OS X and ext2
I've recently begun to help out on another project implementing support for ext2 in the OS X environment (found here). Brian Bergstrand has been the main developer so far, having gotten the source to state of reasonably usable code for use via KEXT. I ran through the code about a week ago and sent in some patches for a few bugs, potential bugs, and optimizations.
So where is the project at? Well it seems to be fairly stable. You can mount drives, read, write, and examine them just fine as unix drives. The problems are evident when you try to get a Mac only user to play with them, or use them with the ext3 file system.
EXT3 support will be set in place sometime soon, we just want to work out all the potential bugs in ext2 first, so expect that sometime in the future. It's really not that hard, and a good portion of it is already in place (architecturally) to be implemented.
As for the Mac user portion, one of the bits that many mac users don't understand is the idea of user ids, nor should they really have to. The multiple users of a desktop machine being something new to many of them. Apple has done a fairly good job of obfuscating this from the end user, by having the console user become a fake-root user thus bypassing many of the file permissions issues. This is where things go wrong on the ext2 mounting system. Right now if you mount a device without having mapped your user id's properly between the device and the local machine, you cannot access your own home directory.
Many long time unix administrators and users already know this and have worked hard to keep user id's the same across machines. It's not a new problem, it's just not something Mac users typically think about. So one of the parts I'm starting to research into is how to enable the console user control of the file system. It's been a bit more tricky since I cannot find some good documentation on this bit, but it does seem like it can be implemented.
In any case Brian is apparently waiting for the new release of the e2fsprog (1.33) so that can be integrated before the final release of 1.0 can happen. If you want to help debug and test the code, I would suggest doing this now. It would be nice to have a release that works extremely well for all.
Posted by Dan at 08:57 AM | Comments (0)
State of Graphics
This lecture happened a short while after (read 30 minutes) listening to Ari Schwartz speak, but my writeup has been unfortunately been delayed in posting due to numerous other events going on. Dr. Daniel Aliaga presented a talk on "Capturing and Rendering Real-World Environments" (white papers here and here), where he went into detail on the steps his team and he have taken to accurately rendering a real world environment with a minimal amount manual labor (i.e. taking measurements, etc).
You can read over many of the mathematical details in the white papers used to explain the research so I will keep this down to a minimum on details. The fascinating part of all of this has been the end resulting rendering. Dr. Aliaga worked to impress upon us many of the minor details that were able to be reproduced, like specular highlighting on the wall plaques.
As I understood it conceptually, the project starts out by taking an extremely high resolution data rich sample set on a set plane. Meaning an omnidirectional camera was set on a parallel plane to the floor collecting a series of high resolutions photos (1024x1024) within a densely covered area. If you look at his research page, the image of a floor plan with a series of red scribbles, that are actually dots not lines, represents the camera path taken and points of data collection. The robot was controlled manually through a handheld RC device, but there is hope for future research to allow the robot to be self controlling.
Once this data set has been collected, a method of associating and identifying features is executed. While the team used some obvious fiducials for tracking, they were also able to identify common themes through images via some computer vision algorithms. Each image was taken at about a distance of 3" apart, so a means of stitching the image together was created, called Sea of Images.
Interesting detail pointed out was the resolution capability to be generated for a single image through this stitching process was visibly higher than that of an MPEG2 stream (their initial data compression method). While it was still not as detailed as an original source image, many more details of small text and complex shapes could be identified in the SoI method.
The final demonstration provided a virtual walk through of a series of locations, like the Bell Labs library. Oddly enough in the walk through not one of the images seen was actually ever taken. Each image used on the walk through was dynamically generated from the data collected earlier. While the walkthrough only allowed a single perpendicular view to the floor (no angles up or down) but the detail and clarity was outstanding. This wasn't being run on any special hardware either. A 1.7Ghz Pentium4 processor with a "recent off the shelf video card around $200" was used.
There were still some problems. Occasionally the walk through would burp for a noticeable few frames, and when on a still frame occasional image ghosting artifacts could be found from the stitching.
Before seeing this presentation, I read an article written by Steve Silberman for Wired News on the state of the art graphics being employed by the new Matrix movies. Essentially the author was blown away with the quality of the 3D animation being used in real time, but provided nothing but fluff about it. I was a slight bit skeptical on the level of realism that could be provided, but after seeing this presentation I am now very excited to see the outcome. If Dr. Aliaga can provide essentially photo-realistic quality on a real-time basis, I can't wait to see the level of detail brought in a completely rendered world.
Posted by Dan at 07:50 AM | Comments (1)
April 10, 2003
Privacy Legislation
I attended a lecture today by Ari Schwartz, a Associate Director for the Center for Democracy and Technology, that covered some of the more recent trends in US government policy towards privacy. Essentially this broke down to a discussion, apparently for informing the non-enlightened masses, on the Patriot Act, the Homeland Security Act, and CAPPS II.
First a little bit about Avi. I had a chance to talk with him after the presentation and found him to be really well informed on a broad spectrum of topics. While it is his job to know politics and policy, he was very open about answering questions that were well thought out and those that were poorly planned. He's also a Mac OSX user on an iBook2. He instantly won my appreciation. All told, he seemed to be someone I would enjoy talking with on a more regular basis, with a lot of energy towards his job.
The lecture only lasted an hour, not nearly enough time to properly cover completely any one piece of legislation listed above, so many details were glossed over in favor of the more striking points. One of the more important points revolved around the Patriot Act and the sunset time on this abomination of civil rights and privacy. The New York Times has an article (free registration yadda yadda... or read the SFGate's version) about how some Republicans in power wish to extend the sunset date beyond the 2005 deadline. Ari pointed out that many of the powers granted in this legislation have been desired for a long time by law enforcement officials, and as such it's not surprising to see them fighting to keep these powers.
The part that becomes interesting really is the lack of information being brought forth by the Justice Department. It seems that detailed reports on how law enforcement groups are utilizing these powers are not being shared with outside observers. More importantly, there seems to be an inability to perform any oversight, as the rules and regulations are often decided instantly upon a scenario. Ari used an example of an FBI field agent being told to call headquarters for a decision if such a maneuver would be legal. This provides no real way to watch the watchers as it be.
Ari made an interesting point in regards to the CAPPS II system. I had asked if there was to be any movement towards allowing citizens to clear their name (read this Wired News article for more information). While it would be nice to allow this to happen, Ari points out that this also would allow criminals to enact the same steps. If a citizen can (with enough determination) clear up their name, an organized outfit would easily be able to bypass the system. More importantly it seems that security through obscurity is being kept in this case (not informing anyone on the search algorithms), which is very unlike any other technology in the US (witness wiretapping) government's typical arsenal.
All in all, the lecture was too short as each of these topics could easily take a day to discuss completely. He did open up the lecture by asking how many people read Lessig though. Surprisingly, I think I was the only one to raise a hand at this issue.
Ari did correct me on one major fault thought. It seems that only 10 or 15 calls are really needed to persuade a representative in their thinking. I had always been under the assumption that a few hundred may be necessary. Ari uses a phone call spamming session used recently to back his point. It's late now, I need to sleep. Please excuse the typos found in here, but I needed to put these thoughts together before they all left.
Posted by Dan at 10:10 PM | Comments (0)
April 09, 2003
Airport Antennas Continued
Marko sent me a link yesterday that knocked my socks off. A company has now created a series of antenna extenders for use with Airport cards on the TiBook. I see today that a large number of Mac news sites have also picked up on this, so the company might not be as flaky as the web page makes it look to be.
Now to decide if I want to try for the Whip or the Butt, and to see if I can afford one as well...
Posted by Dan at 10:57 AM | Comments (0)
April 08, 2003
RSS Feeds
Thanks to Marko for pointing out that my RSS feeds were not full feeds, but rather the horrible MT excerpt system. I think I've fixed this now, but if you run into more trouble, do please let me know.
Things I haven't got working yet, how to get an Extended Entry portion to be noted in the RSS feed. I'm open to suggestions from other MT users.
Posted by Dan at 08:50 AM | Comments (0)
April 06, 2003
Working Programmers
Kate sent me a copy of a paper today entitled Collectivism, Individualism, and Cohesion in a Team-Based Occupation by Michael Workman (available through the Idea Library Journal of Vocational Behavior 58, 82-97 (2001). The main research on the paper revolves around group interaction and inter-group interaction, typically not very exciting or entertaining reading for me. The interesting bit is that the researcher choose to use computer programmers within an unnamed company as the groups, providing a sample near and dear to my own heart.
The three groups broke down to a Real-Time, Open Systems, and Mainframe group respectively. My first instinct being that this paper would be stating the obvious to someone within the realm of programming. That individualism is encouraged, and collectivism is encouraged. A paradox of ideals yes, but exactly part of the problems seen today in engineering. My initial assumption believed collective group work would be done towards identifying a problem and solution. While once identified, the team members would be allowed to implement and solve the problems each their own way. Thus providing a unified view on how a system was to work as a whole, while the nitty-gritty details of each part were not needed. From this paper it seems that idea was wrong with more programmers preferred to identify a problem and solve it on their own.
The interesting bits came from the data retrieved in how each group identifies itself. Within the Real-Time group (6 members) they felt themselves to be more (majority in each case) as part of the organization. While the Open Systems (9 members) and Mainframe (11 members) groups felt themselves to be associated more with their respective groups rather than the organization as a whole. WIth a little thought, I began to realize that in my last job, I too, did not feel as part of the company, but rather part of the engineering group I was working with. I did have interaction (although minimal) with other parts of engineering, but I never associated myself with them and I always felt like an invader when entering into their physical domain (cubes farms).
The follow up interviews with the Realtime group reviled that 4 out of the 6 members did have interaction with groups outside of their domain. Could this be why that group in particular felt itself to be part of the organizations while the others felt they were only an engineering group? It didn't go into the detail on this point, but isn't this typically the goal a company? To make the employee feel like part of the company, almost an essential part of it? I do know that one of my biggest problems with a previous employer was that I didn't feel what I did mattered to the company. That despite the many long and hard hours put in, no one but my teammates recognized this effort. Once many of them were laid off, it really left no one to acknowledge this (read: group identity theory).
The paper does enforce the idea that yes indeed programmers search out the non-confrontational means for showing disrespect for each other ("I'm busy now, can you come back later?") or the occasional flame email.
All in all an interesting read for it made me think about previous employment and the social interactions I never considered.
Posted by Dan at 05:10 PM | Comments (0)
April 02, 2003
TV viewing habits
This little gem came across the Politech list the other day. Unfortunately, it came across on April Fools Day so I wonder how many people will take this seriously and how many won't.
Essentially it breaks down to this, it seems the Patriot Act allows the US government some rather extensive powers all in the name of anti-terrorism. It was rushed through in the hours after 9/11 and was really one of the actions that upset me.
The part I find interesting about this though is that it seems EPIC and the ACLU are at opposing ends to the interpretation of the text. It's not the first time the two have been on opposing ends, but it seems in this case rather odd. It does further the point of English being too ambiguous a language though for verification, a point made in yesterdays post.
What would be interesting to see is if you could claim the hacking of your DirecTV connection as ensuring your privacy. After all, it seems that DirecTV cannot ensure this, so it's left to you the consumer to do so.
Posted by Dan at 09:32 AM | Comments (0)
April 01, 2003
High Availability Programming
I can remember reading awhile back about how one of the Big Three American automobile makers was looking to drastically change their car designs. No longer would there be a steering column, or pedals like we're currently used to. The need to have a left or right hand only driving experience would go away as well, since the wheel could be transfered to either side (as could the pedals). Looking now I can't find the article or pictures about it, but the technology behind it was really interesting. Actuators to sense the rotational degree on the wheel, pressure sensors on the pedals, and all sorts of other neat changes. The result would be a drastic cut in cost for manufacturing, and hopefully a cheaper car for us to purchase with less parts that could malfunction.
Once the "wow! cool!" factor dissipated, it began to sink in that this isn't the coolest idea yet. This would change the state of a car from a mechanical system, to that of a total electronic device, meaning it would be controlled by software. Looking at the state of software development today, I'd find it near impossible for me to purchase such a system given my understanding of software. For example, what happens once an EM pulse disables your car while driving at high speeds? What about a software crash? Stack overflow? Out of memory?
At the time, I wanted to do a bit more research into how the industry planned to accomplish this, but details were limited to nonexistent. I ended my search with the concept of 'look into it more when a product is released' as the information would be available then and promptly put this in the back of my mind to forget.
The other day, I had a chance to listen to Dr. Rod Chapman discuss high reliability programming and SPARK. From the start I realized this would be a marketing speech with little bits of interesting ideas/concepts towards software reliability. He currently works for a company called Praxis Critical Systems, where SPARK was developed and is deployed for use in embedded systems. Typical application uses he threw out were Boeing 777's flight controls, Formula 1 racers, pacemakers, and various other embedded devices.
First about the presentation. Dr. Chapman is from the UK, and as such has an accent that is fairly strong, yet clear enough to understand. His use of local phrases though was lost on many in the audience who are not used to such mannerisms. The speed with which he presented everything was outstandingly fast. He threw out jokes which often took a whole sentence to be registered, or his commentary on how badly that flopped.
His talk started off by discussing what the problems were with programming in general, with verification being the ultimate goal attained by reliable software. If you can verify that something works as stated and only as stated, you should now have a piece of reliable software. The first problem he noted was not related to programming at all, but rather to requirements. More directly to the use of English, a language which by nature is very ambiguous in defining itself. This ambiguity is not good for creating a strict and formal set of guidelines to follow that can be verified. It can be seen through the multiple definitions of a word, dependent upon context use.
With English being a poor choice, what about a modeling language such as UML? As Dr. Chapman put it, the Unified Muddling Language is itself too ambiguous. My best example, by far, is the fact that none of the designers can give you the same explanation to what an aggregate relationship is (see UML Distilled, Fowler). Dr. Chapman went further to state that Object Oriented Programming is heading the way of UML, with the use of polymorphism, and exceptions. I can agree with polymorphism as that is by design, but exceptions are one area of programming that I see needing to be exploited more. Granted they add a new level of complexity to the code (and this was his point), but error condition handling in my mind is essential. His point is that it adds too much complexity, thus reducing the verifiability of the code.
So what methods did he like? Mathematic formulas for one. This follows in line with statements made by Alan Turing in 1948. The concept of "small steps" towards verification, with constant peer review of everything. The concept being that bugs fixed early in development cost far less than those discovered later in the development lifecycle, namely testing. One example of this thinking that I've experienced is the roundtable statement of all programming myths. Where each member of the development team is open to state their mind and beliefs on programming. Towards the end of the session each point is picked apart by everyone, and those that were left were probably safe to assume. This helped greatly in reducing a lot of effort put forth, for example, to building a system where the sharing of too much state data would occur, thus degrading the overall performance.
His biggest idea of providing software verification (and as such, high reliability) was the process of selecting the right tool for the job. Typically this does not include any technology that is the current rage/trend/whatever. For example, Java is not going to be one of the entries on his technology list any time soon for the simple reason of it not being time tested yet. I find that I agree with this line of thinking. When a system becomes not just dependent upon preserving data, but also the lives of many, I would find it much more relaxing to know many of the bugs in the development tools have been fixed. Also the fact that a JVM takes up so much space makes it also impractical for use in an embedded system requiring microsecond response times (i.e. Euro Fighter).
The rest of the talk went on to discuss how SPARK worked around these problems using a few interesting techniques. First, it's based off of Ada, a programming language designed originally for military use, but has since spawned off in a lot of other areas. Second, they use a "design by contract" system, forcing descriptions of how variables are used and altered by functions. Third there is no dynamic memory, relieving the stack overflow, and pointer errors so common today.
His third point brought up an interesting shift in thinking though, which made me question how useful these ideas are for non-embedded systems. When developing for an embedded device, there is typically a maximum amount of memory that can be used, a maximum number of controllers needed to be kept track of, and in general a very limited number of variables to concern yourself with all known at design time. In the case of a web server (for example), limiting the maximum number of connections could work, but it would really make your server pretty non-functional in the long run... or it would at least force random guessing on site popularity on a per-purchase system.
Looking into the current state of development though, I see none of this. The Open Source belief that more eyes can look over the source, hence finding more of the bugs (etc etc) improving reliability. This is great in theory, but how often is this actually done? More importantly how often is it that a system is truly understood by others? How many reliability or verification tests have been run on Open Source software? With the results published and distributed? How about distributed with the software? I'm sure testing has happened, but finding the links to it can be quite frustrating. Are there typically design documentations (beyond source code) that could be followed? Mathematical proofs? After having worked on a few Open Source projects I can honestly say that I don't think so, but I don't know.
Eric Raymond wrote an article entitled "Open Source: Programming as if Quality Mattered" (Google Cache only as I can't find a valid link) in January 1999. Essentially he claimed that high reliability is what will cause Open Source to triaumph over the traditional closed source application. I have yet to see the proof of Open Source providing a higher level of reliability. Much of the time I find my Open Source applications crashing as much as any commercial products.
So how can Open Source be made more reliable? I haven't yet figured out any ideas or suggestions, but I do believe the current idea/belief is broken.
Posted by Dan at 03:08 PM | Comments (0)
blog value
So it seems to be making the rounds, and I decided I should check it out.
My blog is now worth $252.38. Not a bad asking price for my thoughts... although Mr. Sterling's blog has become the .blog bubble pusher. We'll see how long that lasts until his bubble bursts.
Update: corrected the TrackBack to Sterling's post.
Posted by Dan at 10:56 AM | Comments (0)