Lately I'd say I've been reading roughly 1 out of every 20 Slashdot articles that come through my feedreader. And when I say "reading" I mean reading _all_ the comments. As any other Slashdot aficionado can tell you, there are often hidden diamonds of anonymous nerdiness buried within the rough of fanboy excrement that can be found in no other place. That's what keeps me
coming back I guess.
Yesterday an article mentioned Ioke which caught my attention mostly for being a brainchild of Ola Bini. To no surprise of my own, the best part of this post was the comments.
In one corner you have Ola Bini, a prolific self-trained hacker, author and speaker, talking about what he does in his spare time and how he has a a roughly working new language that has some interesting features (for some definition of "interesting"). In the other you have a sea of nerds who Just Don't Get It. Ola is not trying to create yet another language whose documentaion will clutter blogs and a bookstore near you. He's just having fun.
While he is a promenent member of the Ruby community, I definitely wouldn't label him as a Ruby programmer any more than I would label him a Blub programmer. He, like most of the people I know in the Ruby community, loves computer languages. I started to understand this at RubyConf last year when Matz showed off his Python shirt during the keynote. This year he spoke again of his love for (almost) all computer languages while Dave Thomas proclaimed that now is the time to fork ruby (for reasons no Slashdot pundit would understand). I highly recommend Dave's keynote to anyone who's interested in why we program computers. I suspect it will eventually be available at this link: http://rubyconf2008.confreaks.com/
Tuesday, November 11, 2008
Tuesday, August 12, 2008
Ruby 1.8.7
I must say I'm a bit worried by the 1.8.7 release. The only reason I even care out about it is because I recently was bitten by a bug in 1.8.6p230 that, as of the time of this blog entry, is the latest version in Fedora. Quite frankly I am surprised whenever Fedora decides not to ship the latest "stable" upstream package which is why I took the time to understand the state of 1.8.6.
I think the main problem is that the goal for 1.8.7 is unclear, at least from the community's perspective. Contrast this situation with 1.9--a release I'm actually excited about. There are plenty of people telling you what to expect from 1.9. Matz talked about it at RubyConf last year. There's even a beta book out about it now.
In short, 1.9 represents the correct way to work with the community to move a platform forward. Namely, coupling core changes that likely break the killer apps with features that entice developers to go through the effort of porting their code. 1.8.7 needs as many eyes looking over it as possible and it's just not attracting them in my opinion simply because the community doesn't see a reason to upgrade.
I think the main problem is that the goal for 1.8.7 is unclear, at least from the community's perspective. Contrast this situation with 1.9--a release I'm actually excited about. There are plenty of people telling you what to expect from 1.9. Matz talked about it at RubyConf last year. There's even a beta book out about it now.
In short, 1.9 represents the correct way to work with the community to move a platform forward. Namely, coupling core changes that likely break the killer apps with features that entice developers to go through the effort of porting their code. 1.8.7 needs as many eyes looking over it as possible and it's just not attracting them in my opinion simply because the community doesn't see a reason to upgrade.
while(burn :me)
desire_to_upgrade = ignore(:version => :latest_stable)
raise if desire_to_upgrade.nil?
end
Wednesday, April 9, 2008
Shell History Meme
/me is thrilled svn isn't anywhere on this list.
[bleanhar@tumbolia ~]$ history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
418 git
166 ls
95 cd
72 exit
58 vim
19 screen
19 rm
16 pwd
14 tig
13 sudo
Tuesday, March 25, 2008
My ctags lightning talk
Last week at the Raleigh.rb we had an evening of lightning talks. I presented
a handy utility called exuberant ctags for indexing source code and showed
how nicely it plays with Ruby and Vim. Here's a recap of my 5 minute lightning
talk (along with a few points I failed to mention).
Setup:
# From the top level of your project
ctags --recurse
Once it finishes there will be a file called 'tags' in your working directory.
In my case vim loads tag files automatically if it finds them in the same
directory from which it was launched. If for some reason your version does not
do this for Ruby files you can type the following in command mode:
set tags=[path to your tags file]
To make the change permanent add the following to your vimrc:
# Look for a tags file in vim's working directory.
au BufRead,BufNewFile *.rb set tags=tags
In both cases a comma separated list is accepted. This is nice if you are
working on multiple projects.
Usage:
ctags works with most real text editors though I'm only experienced with the vim
integration. Basically, once vim has loaded the tags file you can place
the cursor on top of any word and press cntrl - ] to jump to the
declaration. In some cases users will notice their terminal also has that
specific key combination bound. Under gnome-terminal I have to press cntl-shift - ] to
access my tags. In the case where more than one tag matches a selection
mode will be displayed. Usually it's fairly obvious which one you want.
Also worth mentioning is vim's tagstack. It works pretty much as expected. You push down as far as you
want and then use cntrl - t to pop back.
Limitations:
Obviously this sort of indexing faces challenges when working with a language
as dynamic as Ruby. Things that trip it up are method aliases and any fancy
metaprogramming.
ctags vs rtags
There is a Ruby ctags alternative called rtags. In my opinion ctags works better:
a handy utility called exuberant ctags for indexing source code and showed
how nicely it plays with Ruby and Vim. Here's a recap of my 5 minute lightning
talk (along with a few points I failed to mention).
Setup:
# From the top level of your project
ctags --recurse
Once it finishes there will be a file called 'tags' in your working directory.
In my case vim loads tag files automatically if it finds them in the same
directory from which it was launched. If for some reason your version does not
do this for Ruby files you can type the following in command mode:
set tags=[path to your tags file]
To make the change permanent add the following to your vimrc:
# Look for a tags file in vim's working directory.
au BufRead,BufNewFile *.rb set tags=tags
In both cases a comma separated list is accepted. This is nice if you are
working on multiple projects.
Usage:
ctags works with most real text editors though I'm only experienced with the vim
integration. Basically, once vim has loaded the tags file you can place
the cursor on top of any word and press cntrl - ] to jump to the
declaration. In some cases users will notice their terminal also has that
specific key combination bound. Under gnome-terminal I have to press cntl-shift - ] to
access my tags. In the case where more than one tag matches a selection
mode will be displayed. Usually it's fairly obvious which one you want.
Also worth mentioning is vim's tagstack. It works pretty much as expected. You push down as far as you
want and then use cntrl - t to pop back.
Limitations:
Obviously this sort of indexing faces challenges when working with a language
as dynamic as Ruby. Things that trip it up are method aliases and any fancy
metaprogramming.
ctags vs rtags
There is a Ruby ctags alternative called rtags. In my opinion ctags works better:
- ctags is several orders of magnitude faster that rtags. On my laptop a 100,000 SLOC project is indexed in less than one second. rtags takes about a minute to do the same.
- ctags supports dozens of languages. Run ctags --list-languages to see them all.
- rtags has trouble parsing files on most Ruby projects I work on. This is what led me to switch back to ctags in the first place.
- rtags claims to be more aware of Ruby syntax though in practice I find it indexes many things I just don't care about.
Saturday, March 8, 2008
GEB part two
I finished the second (and final) part of "Godel, Escher, Bach" last weekend. Originally I was thinking about all the clever things that could be said about the book but now I don't think there is much value in doing so. The one thing I can say is that this book was vital in luring me out of my mental rut of technical reading. In short, I recommend this book to everyone.
It's hard to express in words exactly why I believe this book is such an important read. Ironically, that is one of the major themes from the book. It deals greatly with holism vs. reductionism. I can see quite patently that the whole of GEB is greater than the sum of it's chapters.
Should you decide to read GEB I suggest that you read the entire work. Due to its length it's probably one of the most half-read books of our time. Many of the people that recommended the book to me said things like, "It's a great book! Though I only read the first (x) pages". Strangely enough I did meet one person who said they read the entire work in 18 hours straight.
No matter how long it takes if you stick with it you will be rewarded many times over. It took me 3 months and I confess there were indeed times in which I felt I was understanding very little. However, time after time, I would reach a point where things started weaving together in the sort of "Eternal Golden Braid" that I believe Hofstadter intended. I venture to say that, while you may indeed walk away with completely different insights about the book's "meaning", your experience will be quite similar.
It's hard to express in words exactly why I believe this book is such an important read. Ironically, that is one of the major themes from the book. It deals greatly with holism vs. reductionism. I can see quite patently that the whole of GEB is greater than the sum of it's chapters.
Should you decide to read GEB I suggest that you read the entire work. Due to its length it's probably one of the most half-read books of our time. Many of the people that recommended the book to me said things like, "It's a great book! Though I only read the first (x) pages". Strangely enough I did meet one person who said they read the entire work in 18 hours straight.
No matter how long it takes if you stick with it you will be rewarded many times over. It took me 3 months and I confess there were indeed times in which I felt I was understanding very little. However, time after time, I would reach a point where things started weaving together in the sort of "Eternal Golden Braid" that I believe Hofstadter intended. I venture to say that, while you may indeed walk away with completely different insights about the book's "meaning", your experience will be quite similar.
<obligatory_Reading_Rainbow_quote>
"But you don't have to take my word for it..."
</obligatory_Reading_Rainbow_quote>
Wednesday, February 27, 2008
Success with gstreamer
A few weeks ago I nearly threw my laptop down the hallway at work out of frustration with Kino and Pitivi. All I wished to do was create a simple screencast using open source software. I later tried some tips I found on the Fedora Screencasting wiki only to find the recommended splice script out of date.
Though the script was broken on F8 it did give me insight into the power of the gstreamer framework. I knew that whenever I had the time I should dig in a little deeper. With the help of this Linux Conf Austrailia talk I was able to figure out what needed to be changed in order to get the splice script working again on F8.
Here's how I spliced my theora video (made with istanbul) with a wav file recorded in audacity:
gst-launch oggmux name=mux ! filesink location=ldap-gst.ogg { filesrc location=ldap.ogg ! decodebin name=v } { filesrc location=ldap-audio.wav ! decodebin name=a } { v. ! queue ! ffmpegcolorspace ! theoraenc ! queue ! mux. } { a. ! queue ! audioconvert ! vorbisenc ! queue ! mux. }
As a big fan of golfing on the command line I can appreciate convoluted oneliners. The big trick to getting the fedora-av-splice.sh script running was:
Though the script was broken on F8 it did give me insight into the power of the gstreamer framework. I knew that whenever I had the time I should dig in a little deeper. With the help of this Linux Conf Austrailia talk I was able to figure out what needed to be changed in order to get the splice script working again on F8.
Here's how I spliced my theora video (made with istanbul) with a wav file recorded in audacity:
gst-launch oggmux name=mux ! filesink location=ldap-gst.ogg { filesrc location=ldap.ogg ! decodebin name=v } { filesrc location=ldap-audio.wav ! decodebin name=a } { v. ! queue ! ffmpegcolorspace ! theoraenc ! queue ! mux. } { a. ! queue ! audioconvert ! vorbisenc ! queue ! mux. }
As a big fan of golfing on the command line I can appreciate convoluted oneliners. The big trick to getting the fedora-av-splice.sh script running was:
- Remove the version number from the 'gst-launch' executable (why hard-code that anyway?)
- Corrected syntax (honestly, I mostly cargo-culted this from examples I found on the interweb)
- Changed 'rawvorbisenc' to plain old 'vorbisenc'. The talk mentioned 'gst-inspect' which for me was the key to finding out what my system could do.
Sunday, February 10, 2008
Getting your parents to run Fedora: Challenge 1
Problem 1: Remote system administration
As other people in the session shared their similar philanthropic tech support stories we soon discovered our first problem. A problem which has led to much headache for all involved and marred the name of open source. The issue we speak of in this entry is that of remote system administration.
You can't be serious
It definitely seems odd that a group of people consisting of either developers or system administrators would face challenges with remote administration. I mean, just about every machine I work on is "remote". It's typically a Xen guest whose physical host location is both unknown and unimportant to me. But the fact of the matter is that, when dealing with our family, we're often thrown into a world (almost) completely unfamiliar to us; the world of people who do not attend FUDcons.
"Oh, but I am serious" or Phone support for the inlaws
To make things a little more concrete I'll share a little about a strange tradition in our household. Each year my wife and I fly out to visit her relatives. With impeccable regularity, during our vacation one of their Windows machines goes up in flames due to some mixture of bugs and malware and, with similar predictability, I install Fedora on their machine. The sad part to the story is that every year they end up having to remove Fedora and switch back to Windows simply because we fly back home and they don't have anyone else nearby that can help them. The truth is they have equally as many problems with Windows. It just happens to be the case that they have had years of experience with 'workarounds'. I can't tell you how many times we've had conversations on the phone like this:
I was quite surprised when several people from the Fedora project actually suggested not installing Fedora in this particular case. After talking a bit more what they really meant was, "don't install Fedora, yet". In certain cases it can be almost traumatic to have their entire digital world flipped on them. Find _good_ open source solutions to the areas where they are locked in. Once successful the switch to Fedora will be a lot smoother. After all, it's typically the case that a person only uses a handful of rather basic apps and they only have one or two apps where they are truely 'locked in'. In my mother-in-law's case it's Sibelious. Sadly, GNU Denemo didn't work well for her.
For remote support we really need something better than
Wish list for remote tech support
The second challenge: Usability
As other people in the session shared their similar philanthropic tech support stories we soon discovered our first problem. A problem which has led to much headache for all involved and marred the name of open source. The issue we speak of in this entry is that of remote system administration.
You can't be serious
It definitely seems odd that a group of people consisting of either developers or system administrators would face challenges with remote administration. I mean, just about every machine I work on is "remote". It's typically a Xen guest whose physical host location is both unknown and unimportant to me. But the fact of the matter is that, when dealing with our family, we're often thrown into a world (almost) completely unfamiliar to us; the world of people who do not attend FUDcons.
"Oh, but I am serious" or Phone support for the inlaws
To make things a little more concrete I'll share a little about a strange tradition in our household. Each year my wife and I fly out to visit her relatives. With impeccable regularity, during our vacation one of their Windows machines goes up in flames due to some mixture of bugs and malware and, with similar predictability, I install Fedora on their machine. The sad part to the story is that every year they end up having to remove Fedora and switch back to Windows simply because we fly back home and they don't have anyone else nearby that can help them. The truth is they have equally as many problems with Windows. It just happens to be the case that they have had years of experience with 'workarounds'. I can't tell you how many times we've had conversations on the phone like this:
mother-in-law: The internet is broken on my laptopCurrent recommendation for my inlaws:
me: Opps, that was probably my fault. Remember that thing I mentioned to about Ogg Vorbis? Well when I ssh'd into your machine this morning to make it so that you could view our family videos I accidentally upgraded your kern...
*mother-in-law* interupts,
mother-in-law: Uhh... what can I type to fix this? I need to check my email.
me: Press alteff too. Then type 'nome terminal'. Then type 'pseudo sue dash enter'. Then type 'yum update eye dubya...'
(I'm trying my best to faithfully represent the role poor mobile phone connectivity plays in to these scenarios.)
I was quite surprised when several people from the Fedora project actually suggested not installing Fedora in this particular case. After talking a bit more what they really meant was, "don't install Fedora, yet". In certain cases it can be almost traumatic to have their entire digital world flipped on them. Find _good_ open source solutions to the areas where they are locked in. Once successful the switch to Fedora will be a lot smoother. After all, it's typically the case that a person only uses a handful of rather basic apps and they only have one or two apps where they are truely 'locked in'. In my mother-in-law's case it's Sibelious. Sadly, GNU Denemo didn't work well for her.
For remote support we really need something better than
- explain how to activate desktop sharing
- reverse an ssh connection
- port forward to their vino server
- launch vnc viewer over lousy internet connection and try to couch family member on what button to click on to fix their problem
Wish list for remote tech support
- An effective way to securely establish connections with nontechnical users and their trusted, penguin-loving friends. When connecting two people that are both on networks with some form of NAT you are frequently forced to use a third, internet addressable, machine in order to establish a connection. Obviously you can get around the use of a third party if you control the router on your end, but that's not always the case. Say my mom calls from home and I'm at coffee shop or at work.
- A disaster recovery strategy that protects our family members from being forced to return closed source alternatives. With my inlaws some unrecoverable (at least over the phone) situation always comes up and they are forced to do the only thing they know how to--pay someone to install Windows.
- Use a service to spin up secured Fedora virtual machines over the internet. From there have an applet on their dock to request a connection from their trusted friend. Some form of remote desktop connection is then made over a tunnel ssh connection that is brokered by the VM. Of course using such a service would always require money. In the case of the EC2 it's pretty cheap in comparison to the cost of paying some Geek Squader to fix things. With Amazon's DevPay (A service that allows people to pay for usage of VMs) it would be possible to even have a system for Fedora community members to raise support for the Fedora project by volunteering to fix people's machines.
- Koan/Cobbler to allow remote provisioning. Profiles could be created for sundry machine configurations that would lay down a working machine.
- Customized LiveCDs or recovery DVDs. This shouldn't be too hard with the Fedora tooling and fits quite well with Koan/Cobbler.
- Another interesting use case for a live CD would be to have an automated method to back up their data before wiping everything and starting over. In the post installation their data could be restored.
The second challenge: Usability
Wednesday, February 6, 2008
Getting your parents to run Fedora: Intro
A few weeks ago at FUDcon I spawned a session entitled "Getting your parents to run Fedora". We had 20 people or so show show up that day and it's high time I posted some of the topics that were discussed. My first attempt in writing this proved far too verbose so I'm going to break it into parts and try and make things a little more concise. To put it best:
Open source computing appears to be at a veritable tipping point for mass adoption. Dell actively promotes machines with Ubuntu preinstalled, Wal-mart has a hot selling Linux-based desktop, the OLPC project is getting commodity laptops in the hands of the third-world and Asus is getting them to the rest. Though this mass adoption might very well be nothing more than a footnote in the minds of many open source aficionados I view it of utmost importance regarding the topic of file formats and true digital freedom. Unless formats like odf, ogg vorbis/theora and the like are actually used in the wild they will be ignored by the online services that we use daily.
How can we assist this mass adoption? Well, like many of my friends at FUDcon, I install Fedora on every machine whose owner will allow it and, at least in my case, there is a clear dual motive. On one hand, as stated previously, I desire open source to be adopted by the masses, on the other I want my family to have machines that meet their needs. Since they are family I would be their tech support regardless of what OS they choose to run. I merely urge them to let me install Fedora since that's what I use and it's the only way I can test things out for them.
Up Next
The first challenge: Remote administration
"If I had more time, I would have written a shorter letter."Intro
--Hemingway, Cicero, Voltaire, Mark Twain, or maybe T.S. Elliot
Open source computing appears to be at a veritable tipping point for mass adoption. Dell actively promotes machines with Ubuntu preinstalled, Wal-mart has a hot selling Linux-based desktop, the OLPC project is getting commodity laptops in the hands of the third-world and Asus is getting them to the rest. Though this mass adoption might very well be nothing more than a footnote in the minds of many open source aficionados I view it of utmost importance regarding the topic of file formats and true digital freedom. Unless formats like odf, ogg vorbis/theora and the like are actually used in the wild they will be ignored by the online services that we use daily.
How can we assist this mass adoption? Well, like many of my friends at FUDcon, I install Fedora on every machine whose owner will allow it and, at least in my case, there is a clear dual motive. On one hand, as stated previously, I desire open source to be adopted by the masses, on the other I want my family to have machines that meet their needs. Since they are family I would be their tech support regardless of what OS they choose to run. I merely urge them to let me install Fedora since that's what I use and it's the only way I can test things out for them.
Up Next
The first challenge: Remote administration
Sunday, January 6, 2008
home Sweet Home 3D
Last night my wife was feeling particularly creative. While I usually approve of her creative inclinations I was simply not in the mood to move our large objects (some call it furniture) around our apartment. Thinking aloud I said to my wife, "there must be some great open source software for interior design".
When someone says such as phrase there a few common outcomes:
When someone says such as phrase there a few common outcomes:
- It is the case that such a project exists therefore the problem is solved
- It is not the case that such a project exists therefore it is the case that either
- You create the great project yourself therefore your weekend is shot OR
- You do not create the great project yourself therefore you are forced to move heavy objects (your weekend is probably still shot)
Tuesday, January 1, 2008
Lanier's Well-Tested Conjecture
Something has been eating at me for the last few days since Jaron Lanier's article Long Live Closed-Source Software! first came through my feed reader. I couldn't put my finger on it at first but maybe after letting the thoughts percolate a bit through my mind I'll be able to dig it out by the time I'm done here.
On the surface I guess the reason I was initially bothered by the article was the fact that I came across it while thumbing through my slashdot feed. Honestly, it's probably more my fault for reading /. in the first place (I get really annoyed when I see articles that seem as if they are begging for attention).
It wasn't until I finally got around to reading it that I realized it was something I needed to consider. If you make exception for phrases like "there's a reason the iPhone doesn't come with Linux" it seems as if Lanier makes several valid points. Later in the article he even makes statements that make him appear sympathetic with the open source movement. So he can't be all bad, right? Though, again, that wasn't what has been itching me as I don't tend to get too stirred up by those sorts of issues.
What really gave me a sour taste was the idea that he would be in any position to judge innovation based by his "evidence". Personally, examples like the iPhone seem ridiculous when its basic functionality is comprised of nothing more than things that I have wanted on my phone since the late 90s. The trick that will make billions for Apple is that they have done it a fashionable way. To say that it doesn't come with Linux wouldn't even be true if you consider many of the web applications on which the iPhone experience relies are are indeed running on Linux and open source. Though it wouldn't have been as catchy, Lanier should have directed his statement towards the Linux community if that was indeed what he was hinting at, "the iPhone doesn't come with [the ideals commonly expressed by the Linux community]". I guess I was wrong--that does sound catchy!
But how do communities innovate? How does one even recognize that innovation? I'll tell you how--not very easily. Let me continue along those lines and explain that I'm more accustomed to hearing people talk about innovation long after the particular innovation in question has actually been innovated. I studied Spanish golden age literature in College. For some strange reason though it wasn't called golden age literature at the time of it's writing. I even see a parallel in the field of music strangely enough. I played in several bands whose prime preceded the dawn of YouTube and MySpace, that is to say their existence is presently only in my mind (and a few other minds). I wouldn't even say our music was innovative but I do feel that in the hundreds of shows we played I was exposed to innovation through the people we encountered. Few of those bands are still around today in any form yet these underground cultures are alive all over the country. They share with each other through tours and festivals and now more than ever with the advent of communities such as Last.FM. I don't want to spend much more time on this particular topic so suffice it to say:
I just don't buy the any statement that claims the open source movement doesn't innovate. People innovate, period. Closed source projects fail as commonly (and for many of the same reasons) as open source projects. The vast majority of closed source software is miserable in much the same manner as the sundry projects on [Insert your favorite repository here] are. It's just too simple to think of examples and counter examples for any theorem that aims to prove a function of Open/Closed sourcedness to innovation. Surely things are more complex than that.
On the surface I guess the reason I was initially bothered by the article was the fact that I came across it while thumbing through my slashdot feed. Honestly, it's probably more my fault for reading /. in the first place (I get really annoyed when I see articles that seem as if they are begging for attention).
It wasn't until I finally got around to reading it that I realized it was something I needed to consider. If you make exception for phrases like "there's a reason the iPhone doesn't come with Linux" it seems as if Lanier makes several valid points. Later in the article he even makes statements that make him appear sympathetic with the open source movement. So he can't be all bad, right? Though, again, that wasn't what has been itching me as I don't tend to get too stirred up by those sorts of issues.
What really gave me a sour taste was the idea that he would be in any position to judge innovation based by his "evidence". Personally, examples like the iPhone seem ridiculous when its basic functionality is comprised of nothing more than things that I have wanted on my phone since the late 90s. The trick that will make billions for Apple is that they have done it a fashionable way. To say that it doesn't come with Linux wouldn't even be true if you consider many of the web applications on which the iPhone experience relies are are indeed running on Linux and open source. Though it wouldn't have been as catchy, Lanier should have directed his statement towards the Linux community if that was indeed what he was hinting at, "the iPhone doesn't come with [the ideals commonly expressed by the Linux community]". I guess I was wrong--that does sound catchy!
But how do communities innovate? How does one even recognize that innovation? I'll tell you how--not very easily. Let me continue along those lines and explain that I'm more accustomed to hearing people talk about innovation long after the particular innovation in question has actually been innovated. I studied Spanish golden age literature in College. For some strange reason though it wasn't called golden age literature at the time of it's writing. I even see a parallel in the field of music strangely enough. I played in several bands whose prime preceded the dawn of YouTube and MySpace, that is to say their existence is presently only in my mind (and a few other minds). I wouldn't even say our music was innovative but I do feel that in the hundreds of shows we played I was exposed to innovation through the people we encountered. Few of those bands are still around today in any form yet these underground cultures are alive all over the country. They share with each other through tours and festivals and now more than ever with the advent of communities such as Last.FM. I don't want to spend much more time on this particular topic so suffice it to say:
When people call the iPhone innovative it gives me much the same feeling as when one of my hip-hop aficionado friends from Spain considers Coolio to be innovative.I only mention Spain because I lived there for a year and a half and those situations came up far too often. The idea is simply that the majority of Spanish teens are too far removed from hip-hop culture to make any judgement on west coast music from across the ocean (they would be, however, more knowledgeable on hip-hop from Iberia). The only thing they ever experience from the US, in my opinion, is culture that happens to be profitable. I believe Lanier's definition of innovation borders dangerously close with "it's popular ergo it matters".
I just don't buy the any statement that claims the open source movement doesn't innovate. People innovate, period. Closed source projects fail as commonly (and for many of the same reasons) as open source projects. The vast majority of closed source software is miserable in much the same manner as the sundry projects on [Insert your favorite repository here] are. It's just too simple to think of examples and counter examples for any theorem that aims to prove a function of Open/Closed sourcedness to innovation. Surely things are more complex than that.
Subscribe to:
Posts (Atom)
