1 2 3 Previous Next


64 posts

Why I do Open Source Blog

Posted by eitan Jan 26, 2009
First Kirill blogged on "Why I do open source" and then invited Andres and Alex to do the same. So a chain reaction is in motion. Andres published his version, and tagged me and three others. So here's my entry, my version of "Why I do open source."

So this piece has some history, which you may already be familiar with. First Kirill blogged on Why I do open source and then invited Andres and Alex to do the same.  So a chain reaction is in motion.  Andres published his version, and tagged me and three others.  So here's my entry, my version of "Why I do open source."

So first you realize you like software development and make it your choice of a career:

  • finding my place in the world:  falling in love with the practice of software development.  All you need to build something is your brain and a computer.

Second you become aware of open source and learn about it:

  • exposure to open source projects across the spectrum, both in the java camp (jakarta) and outside it

Third, a motivation for constructing something comes along.  Many people call it "scratching an itch."  For whatever reason, you have an idea to build something in software that motivates you.

In my case, in the mid to late nineties i was into web and into Java.  I recall one of the first things I liked about Java is that its documentation system was: [a] web-based, and [b] auto-generated from the code.  That's pretty darn cool, or at least it was then.  I'm not 100% sure that Java was the first but it's somewhat a fact that almost all platforms and languages today come with a similar javadoc'ing system.  Unfortunately the innovation effort turned out to be more of a burst and then it ended.  Javadoc today is pretty much the same system that James Gosling brought forth back in 1995.

I clearly saw that javadocs should be a web app backed by an rdbms.  Second, I identified various ways of fundamentally redesigning the ui to make it more usable.  For a long time, it was just an idea tugging at me.  One day I said "enough, I must build this," had a serious talk with my wife, took a 2-week vacation, shut myself in a hotel room and wrote ashkelon, which at the time I called "dbdoc."  It was one of the most creative short periods in my life, perhaps back in 2001.

It took me a year before I decided to open source the project.  That was after James Davidson came to talk to the Austin JUG about one of his open source projects: Ant.  In 2002 I open-sourced the project and named it Ashkelon, after a town that I lived in, which I consider my old home town.

I can't say the effort was successful.  Writing the code is one thing.  Using it is one thing.  But successfully preaching and evangelizing it and urging its adoption turned out not to be my forte.  And I feel that I failed at the latter.  I still regret it.  Even today, years later, most javadoc systems don't come close (imho) to what I'd built.  Ashkelon has not kept up with Java and I have not updated its implementation to incorporate elements of Java that were introduced in version 5 (annotations, generics, etc..).

Anyhow, I tried to leverage open source to increase exposure to what I'd constructed.  Many benefits came that I did not expect:  email conversations with folks from all across the world, who had been using my system and who had taken the time to read parts of the code and make improvements and contribute to them.  It's enriching, to say the least.

My two main open source software projects are, or have been:

  1. A javadoc system that uses a back-end database and its own UI design, named ashkelon

  2. JMatter:  streamlining the construction of domain centric apps with database persistence.  My stab at the nakedobjects architectural pattern in Java, leveraging Swing and Hibernate.

I like the fact that open source is an inclusive club:  anyone has access to code, to use it, to learn from it, and they're free to contribute to a project (of course, it's up to the project maintainer to ultimately decide whether to use or include your contributions, but you're free to make whatever changes you like to your copy, and to redistribute it freely).

I feel today we're at a tipping point:  there is an abundance of free software and of free software projects.  It's really wonderful to see.

Some literary influences:

In the end, it's more fun to construct software that you can share with others.  It's fun to be and feel like you are a part of a community.  I like belonging to a group where what everyone has in common is a passion.  In this world, we are often categorized by our ethnicity, our birth.  This is better.

An essential ingredient for a community is periodic face-to-face meetings.  Although events such as JavaOne have served the purpose in the past, this event was stricly about the Desktop, and (unlike JavaOne) was very small and most intimate.

I most enjoyed getting to meet a number of java.net bloggers such as Kirill Grouchnikov, the author of the Substance look and feel, and members of the Sun Swing team including Shannon Hickey, Chet Haase, Hans Muller, and Richard Bair.  Of particular interest to me was the chance to meet people behind independent open source frameworks such as Wolf Paulus, the author of SwixML.  It's also always a pleasure to revisit with old friends Ben Galbraith, Dion Almaer, and Scott Delap, whom I know from speaking tours with NFJS (no fluff just stuff).

What I value most about such conferences is the chance to connect with the community, the people who were drawn to this conference, speakers and attendees alike, because of their involvement with desktop technologies in some respect.  They came to share and discuss.  This was not a dead audience.  Talks were interactive, and Ben made sure to heckle speakers that didn't get their fair share of questions.

Personally, I was very humbled by the feedback I received about my talk.  There's nothing more encouraging to one's work than getting positive feedback so personally.

I enjoyed informal conversations with fellow speaker Kai Toedter of Siemens, and Etienne Studer who delivered two presentations:  the first on the ULC product from Canoo (which imho rocks), and the second on IntelliJ IDEA's GUI designer where Etienne's facility in the environment made me reconsider my own intimacy with the product.  It was also an honor to get to meet and listen to the people behind JIDE.  David Qiao gave a great talk.

So, now that DM is over, and now that I'm home, I can finally say that I feel like I know at least a few members of my community, and it's a good feeling.


All sorts of matter.. Blog

Posted by eitan Mar 5, 2007

I'm excited about the upcoming Desktop Matters conference, which takes place March 8-9 this week in San Jose, CA.  This conference is a first of its kind, focusing on Swing and other desktop technologies.

The conference is organized such that it has a single track, which I very much like.  As much as it's nice to have a choice of talks to attend, I believe there's more value in everyone being in on what goes on, in sharing a common experience.  It's not unlike how TV used to be.  I recall a place and time where there was only a single national television station.  If a movie was on, everyone watched it, and there's something nice about that.

Personally, I will be attending the conference as a speaker:  I will be showing off my project:  JMatter.  It's been a little over six months since I announced the project as open-source.  Our mailing list has grown to over 100 users and the feedback has been extremely positive.  Some of my favorites are:  "you should be speaking about this at JavaPolis" and "the documentation is outstanding."  Speaking of the documentation, I have recently expanded it and it now stands at roughly 200 pages.  The manual is now available in print as a self-published book from lulu.com.

I am looking forward to meeting the members of the rich client community at Desktop Matters.  Sometimes as developers we overlook the importance of attending a conference.  Listening to a talk or speaking with a colleague can be a catalyst for new ideas, and reinvigorates us when we get back to coding.  Perhaps I'll see you there.


That Open Source Feelin' Blog

Posted by eitan Dec 3, 2006

I wanted to wait for the dust to settle a bit before airing my comments on the now dated news that Sun Microsystems has open-sourced Java.

I recall clearly a period of activity on java.net where many (including me) voiced their desire to see Java open-sourced.

Now that this has happened I'm amazed at the correlation of this event with my own experiences.  In my career I've open-sourced two projects:  ashkelon and JMatter.

Each time the process of letting go and embracing open source was very difficult, even arduous.  I took what felt like forever to arrive at the decision. Surprisingly after the decision was made, the feeling was very positive, very rewarding:  that I'd shared my work with the community.  The same thoughts reverberate:  "why did it take me so long to do this?"  I believe the reward is of equal or greater magnitude to the effort;  that is, it's worth doing.

With my first project, I hadn't yet read Eric Raymond's Cathedral and the Bazaar.  I was a novice when it came to managing an open source project.  I still regret that I wasn't able to make the project flourish, though I don't regret for a moment open-sourcing the project.  Many used my code and some sent me improvements.  There was also at the time an obstacle to this project:  the fact that one could not legally publish online javadocs for Java's APIs.

Another correlating fact was my choice of license.  Both my projects are available under the GPL.  So it's a great feeling of validation to see that Sun has also chosen this license.

One odd way to describe how I feel about Sun open-sourcing Java is that the positive feeling is of equal magnitude to the negative feeling I had when hearing the news of the Novell ship sinking.  It gives me hope for the future.

In my mind the parallels that exist between the events that play out in real life: the battle being waged between the forces of open and close code, and between the Star Wars saga are striking.  I don't mean to sound cheesy here, but we see time and again how sometimes organizations exert their force by proxy, sometimes anonymously (as in the case of SCO).

One item I've been ranting about to friends (and on this site) for too long is how companies can get away for charging people for software they don't use.  Each time I purchase a notebook computer and quickly wipe the disk clean to install Ubuntu, I pay the famous "microsoft tax" for a license of windows I did not ask for.

I would like publicly thank Sun Microsystems for choosing to side with its community, to side with the open-source community on Java.  I sincerely hope that a few years from now Sun will be able to say:  "we made a good decision;  and it has paid off handsomely."


Where Swing should Venture Blog

Posted by eitan Jun 28, 2006

An increasing number of frameworks are appearing that I find particularly interesting.  They're web AJAX frameworks where the details of the HTTP communication and of all the HTML and JavaScript on the front-end are hidden behind a Swing-like API.

Here are some of these new frameworks:

It's also worth mentioning that Canoo ULC also provides a Swing-like API, but they're trying to leap-frog AJAX altogether:  they deploy Swing thin clients.

Even though this model is new and not yet "fully" proven, I find it very promising.  Up until now, web developers have had to master multiple different technologies including Java, Servlets, JavaScript, HTML, HTTP, session management and cookies, and the idiosynchracies of various web browsers on a multitude of platforms.

These frameworks promise to collapse all of these layers down to one.  That's tremendous.

So I was thinking, if what is essentially a Swing-like API can be used to build rich web applications, would it be possible to extend Swing in such a way that a deployment switch controls whether we produce a web application or a ...   Swing application?

I suppose we could think of this in reverse:  can an HTML look and feel be constructed for Swing?

The end result would be the same:  we'd write a single application, using The Swing API (not a Swing-like API) and we'd be able to target the web without any extra effort.

So, my message in this blog is:  I think Swing should venture in that direction.

For some reason, I did not catch the wonderful Monty Python Flying Circus episodes in my youth.  Recently in the USA on public TV they've started airing re-runs.

So it was not until maybe a few months ago that I got a great big laugh watching the classic Monty Python Spam episode, wherein everything on the menu has Spam in it.

Earlier this week I proudly announced that I'd finally open sourced JMatter, a framework that I've been developing for a good while, for developing rich client applications at very high productivity levels.

I never really blogged about it, feeling it was not appropriate to promote code that was proprietary.  For some reason, even now I have a little difficulty with this.  So I thought why not try to do it with a little humour?  That usually makes the SPAM go down a little easier.  :-)

On a more serious note, I've been delighted at the response to my announcement.  We already have a thriving mailing list, terrific discussions, and I've had the good fortune that a few fellow developers have blogged most favourably on JMatter.

If you have a little time, I invite you to check it out!


A Harness for Swing Blog

Posted by eitan May 3, 2006

I was thinking about this a while back and it struck me as interesting that as a GUI toolkit, Swing is different from a number of other GUI toolkits out there that were born out of the need for creating a graphical desktkop system.  Namely, GTK has GNOME (and Xfce), Qt had KDE, and MFC has Windows.

What does Swing have?  SwingSet2?  Not really.  There are indeed thousands of rich Swing applications that exercise Swing.  NetBeans being a very serious one developed by Sun, the same organization that develops Swing.  One could also say, "look SWT doesn't have a desktop either,  they just have Eclipse."  So, you are right, it's not fair to make such a comparison.  Nevertheless, it does not mean that it would be a bad idea to have such a project drive the evolution of Swing going forward.

There's nothing like a full-fledged desktop system used by thousands of people daily to serve as a complete harness for a robust GUI API.  A desktop system probably exercises all facets of such a toolkit:

  • Does the toolkit provide a complete suite of widgets that can support a very dynamic user interface?
  • Are the widgets rich enough?  Are they flexible enough?
  • Is the performance of the toolkit's components being put to the test on a regular basis?
  • How well do the components interact with each other?

I see an interesting development going forward.  I recall reading that someone has ported most of GTK to MacOSX.  That is, very soon, Apple users will be able to run GTK apps alongside their Cocoa apps.  It is my understanding that GTK also works on Windows.  Swing has been in a unique position for a while of being able to run multiple platforms.  Others are catching up.  And they do have some advantages, having multiple language bindings possibly being one such advantage.

In all fairness, I should mention an excellent project out of France whose goal is to create a desktop system for Java written in Swing:  JDistro.  What I'm really interested in is a stronger coupling, a stronger feedback loop between two teams:  one developing a Swing Desktop System, and another supporting its development by making improvements in the Swing toolkit.


Thought Catalysis Blog

Posted by eitan May 2, 2006

Recently some new ideas have come to me out of activities that I    did not expect would generate any.  In this blog entry I'd like    to enumerate sources or catalysts for ideas, for generating    thoughts.

  1. Revisiting things you already know:  you will likely see them from a new point of view.  This will usually happen because time has passed.  You've changed, you're not exactly the same person you were when you originally studied the material.  That's what happened to me as I prepared to give my set of talks at NFJS last weekend.

  2. Attend talks given by others.  It's very likely that the same topic will be presented from a different angle, a different point of view.

  3. Get together with other developers.  A NFJS conference might do the trick.  JavaOne is coming up.  Maybe your local JUG meeting.

  4. Even if a topic is not related to the work that you're currently doing, you might be surprised to find once in a while that a situation is discussed that is analogous to yours, albeit in a different domain, a different context.

  5. Provoke thoughts in others.  That has the tendency to amplify the thought process.  You might not be prepared for an avalanche of feedback, ideas triggered by your original provocation.  That happened to me recently after I demo'd some software I was working on to a couple of friends / colleagues.

  6. A few friends recently decided to get together for Friday lunch meetings. It's been a great opportunity to discuss what each of us are working on, articles or books we came across that grabbed our attention or interest. We always have more to talk about than time available, which is a positive sign.

How many times have we heard or preached (or both) the important lesson of not having our business logic "leak" into the client tier.  Each time we hear it, we nod our heads and say "how true," and get serious for a moment.

The idea of logic leaks applies to other aspects of development, not just the client tier.  For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me.  Say for example that we define a business object, maybe a Customer.  Furthermore, let's say we define a number of fields on this object:  name, date of birth, etc..  The minute we put down in our text editor the lines:

<input type="text" name="name" />

..is the minute we've crossed the line;  we have violated the DRY principle.  We have just leaked business logic into our view.  From now on, if we rename the field, we must do it in two places:  in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields.  Model changes are going to occur.  They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger.  Yet business change is inevitable.  People talk about the high cost of building software.  It's no wonder the cost is high if we have to manually make each change twice.  Not only is it more work but also error-prone.  The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:


If we're going to have a model-view-controller system   without business logic leaking into the view, then we   must construct generic views and controllers.

What does that mean?  Take for example, the CRUD scaffold generators in Rails.  The code duplication is still there but at least the duplication is automated.  Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:


GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

I sometimes enjoy describing feelings a software developer might experience, at certain moments during development.   For example, a while back I blogged about "Grazie Signore" moments.

This past weekend I attended the Northern Virginia Software Symposium and was fortunate to have a little time to spend with my NFJS comrades.  A most vivid comment that Justin Gehtland made during one discussion was how stoked he was about this software we were discussing.

It occurred to me on the plane ride back to Austin that the term "stoked" is normally used to describe the feeling one gets when surfing.  Perhaps it's also applied in the context of extreme-sports related activity.

To my wonder, the term could be applied, and very aptly so, to moments that we, geek software developers, have in our work.  That feeling arises when we do something that we think is extremely cool, that perhaps hasn't really been done in that particular way.  For example, I sensed that feeling when reading a weblog I came across on java.net a while back, having to do with a very cool idea that occurred to one of the Wicket Framework developers.  See Wicket + Swing == hmmm...interesting....

I believe that this feeling is the driving force behind the hordes of us out there, of any age, who spend their spare time coding, pursuing the creation of something that, to them, is so incredibly cool.  So, just like surfers can't stop surfing and continually strive to be in that most special state of being stoked, so do software developers.

Each time I look at the task of constructing a business software application, I see tremendous repetition.  Each application has many facets, most of them are generic.  Yet each time we appear to rebuild each facet from scratch.  For example, we construct new authentication screens.  We build an object model for our domain.  We must construct mechanisms for browsing and searching objects, mechanisms for creating new objects, for viewing objects, for editing and deleting objects:  the CRUD (Create, Read, Update, Delete) operations.  Let's also not forget validation.

Oftentimes, we deal with scheduling activities and must develop or integrate calendars into our software applications.  Inevitably, our customers will require a mechanism to produce reports.  We will also supplement our user interfaces with wizards, by walking a user through a series of steps.  We need to persist our objects to databases, we need an authorization mechanism.  We need audit mechanisms to find out when information was edited, by who.

Many of these tasks are generic, orthogonal to the problem domain.  Must we keep on constructing new implementations each time we start on a new project?  Is it even feasible to produce implementations of these concerns (e.g. authentication, authorization, CRUD, a user interface, searching, reporting, wizards, etc..) that are completely decoupled from the business domain in question?  Can we even entertain the thought?

To me, the NakedObjects framework is a proof of concept.  It demonstrates that it is indeed feasible to implement many of the various concerns of application development generically.  Usually the tradeoff is adherence to certain framework conventions, though others have shown that many of these conventions are not absolutely necessary.

Look at the scaffolding generators in Ruby on Rails.  Trails is another project that embodies these same ideas.  The idea is basically that a domain model can be constructed that is to a large extent ignorant of the context it runs in.  This sounds like the Spring Framework and Dependency Injection.  But it goes well beyond injecting transactional rules or turning JNDI on its head.  Indeed, a long time NakedObjects proponent, Dan Haywood, is working on his own framework (see Essential), and is leveraging the Spring Framework for it.  The Naked Objects folks have recently coined the term "The Naked Objects Architectural Pattern" to categorize frameworks that adhere to their architecture concepts and ideas.

In Ruby, one uses the piece of metadata :attr_reader to tag fields that one wants to expose with getter methods.  In NakedObjects, there's a fieldOrder piece of metadata to relate how fields should be laid out on a form in a user interface.  It is specified in a manner analogous to Ruby's :attr_reader.  This manner of specifying metadata is also in line with the DRY (Don't Repeat Yourself) principles given to us by the pragmatic programmers.  It expresses our intent succintly and without duplication.

Let's set aside the "can it be done" question for a moment and envision the rewards.  What do we have to gain as an industry if we manage to develop a system that provides generic implementations for these generic aspects of business application development?

Imagine an ecosystem, similar to Eclipse, but not for tooling.  Instead, this ecosystem would be a runtime infrastructure ecosystem, where providers supply competing implementations of these various concerns (this is what Rails is evolving towards by the way).

  • developers would spend the vast majority of their time directly addressing customers' problems
  • conversely, very little time would be spent building software infrastructure
  • software infrastructure would become standardized
  • development time and cost would decrease dramatically
  • infrastructure components would be of higher quality
  • the size of the code that pertains directly to a specific project would shrink dramatically
  • our abilitly to read, understand, and extend other people's code would likewise improve
  • we would have true decoupling of concerns
  • the developer would simply plug in their object model (the data and behaviours) into a an infrastructure that would supply everything else
  • we'd be able to pick which aspects we want to include in our application at deployment time (the true, original vision of J2EE by the way)
  • our applications would inherit new features when infrastructure upgrades came along, without even altering a single line of code in our applications

I'm not even mentioning the benefits to developer-customer relations, the closer mapping between a user interface and its object model with direct benefits to customers' understanding of the logic behind a business application (hence the term "Naked Object").


Many people have been saying "Move over Java, Ruby is the new language in town."  I do agree to some of the arguments but not all of them.  How much of this is a language issue?  I do admit that maybe implementing such a system is easier and simpler in Ruby.  But that does not mean that it cannot be done in Java.  Java has reflection.  Java does not have mixins.  Java has AOP.  So there are tradeoffs.  I suppose if you really want to do it from scratch, Ruby might be a better choice, from a certain point of view.  If you're building a rich client that needs to run cross-platform with a minimum of fuss, I'd say that Java is the better choice.  Smalltalk could be just as good a choice, perhaps a better one.  Paul Graham says it's LISP and I know he's got some very good reasons.

My contention is that the debate has been focusing disproportionately on the language as the root enabler of frameworks such as Rails.  The ecosystem I dream of can be constructed in Java.  We would reap serious savings in development time, development cost, similar to the time and cost savings that are being boasted about by the Rails community.

I have developed my own framework that embodies these ideas.  At this time, this framework addresses only workgroup business applications.  It does not tackle the important issue of transport.  I have recently employed this framework to construct a small solution for a customer.  The numbers are in line with my expectations.  On this particular job, I spent under two weeks implementing the solution when the original estimate had been in the order of two months.  So how much does this have to do with language?

[Footnote:  blog entry cross-posted on Eitan's personal weblog]

I think these should make for a nice extension to the existing Java 5 Annotation API:

  1. From an Annotation, one should be able to navigate back to the programming element that it annotates.

    For example, a method annotation clearly marked with a Target of ElementType.METHOD cannot say getAnnotatedElement().getName(),

    There are two problems here.  The first is the lack of the   getAnnotatedElement() method The second is the fact that an AnnotatedElement is too primitive of an interface.  You cannot actually invoke getName() on an annotated element.  I feel that there should exist a basic ProgrammingElement implemented by or extended by all annotated elements.

  2. The default value for an annotated element should not be restricted to a constant expression.  Instead, the value should be a code block.

    For example, let's assume that I want to annotate methods to give them a caption.  By default, the caption should be some kind of derivation from the method name it is bound to.

    That is,

    class MyClass
      @MyMethodAt(caption="The X Method")
      public void method x()
        // ..
    public @interface MyMethodAt
      public String caption() 
           return getAnnotatedElement().name();  // see [1]

    As far as I know, this is currently not possible.

* Entry cross-posted on my personal weblog

Skip the Compile Blog

Posted by eitan Jan 17, 2006

It seems to me that many issues that come up in Java stem from the "I don't want to have to recompile my code" argument.  All kinds of design decisions stem from it too.  We end up with systems that are written in two or more languages.  What I mean is that we usually end up with a mix of Java code, properties files, xml files and other stuff.  The properties files and xml files can be viewed as interpreted mini-languages that bypass the Java compilation hurdle.

Many debates surrounding Java 5 annotations also are related to this issue:  many have argued that they don't want to have to recompile their code to revise the value for a piece of metadata.  Fair enough.

How many times have you heard or read of a selling point for a software framework or product or solution being "and you can make changes to the system without having to recompile the code."  I must admit I'm sure I used that line more than once before (in my early days programming :-)).

So here's what I find interesting:  instead of coming up with all kinds of schemes to get around the problem, why don't we just deal with the root cause?  I think it's staring at us in the face:  why don't we simply program in an interpreted environment?

I think we all must admit that it's much nicer to be able to make a change to a web page or a template or a piece of code and very quickly turn around and test the change without having to recompile. Compare that to the way a jsp works:  compile the jsp into a servlet and compile the servlet into bytecode.  It's true that servlet containers are easily configured to 'autoreload' jsps.  So in this case, it's really no big deal.

But that's not what I'm talking about here.  What I'm talking about is if we need the equivalent of a config file, we don't have to go out-of-band and step out of the Java environment and start our new metalanguage in a properties or XML file like James Duncan Davidson did with Ant or like we do every day.  We would simply write source code.  An entire thick layer of nonsense design decisions would simply disappear.  No more debates about put this code here or there depending on whether we want to incur the cost of a recompile.

This essentially is the argument for internal domain specific languages (DSLs).  So Rake files are not written in XML like Ant is but instead they're interpreted by Ruby, the same interpreter that you use to write your Rails app (note: ruby and rake and rails are discussed here as means to provide an illustration.  this entry is _not_ about 'ruby is better than java' but rather about the more general idea that 'interpreted might be better than compiled, from this point of view anyway').

More and more these days I'm coming to think that a single or unified underlying model for interpreting stuff would be a good, pleasing thing. I like this kind of simplification.  We end up with a more uniform system, and spend less time reinventing the wheel.

I find it most interesting that for some reason, discussions around this basic issue never seem to come up.  What comes up are people talking about or trying to solve the symptoms of the root cause, but the root cause seems to evade us.

Note: this entry is cross-posted on my personal weblog


Ubuntu Review Blog

Posted by eitan Dec 13, 2005

Approximately in June or July of 2005, I started weaning myself off of my powerbook G4, and learning the Gnome environment under Ubuntu (v5.04, now v5.10).

Overall, it's been a terrific experience, and it's looking like I've come here to settle down.

So I thought I'd summarize my experiences, from my perspective as a Java software developer, and as a computer user in general.

The Good

Here are a few things I really like in Ubuntu / Linux:

  • The Gnome Epiphany Web Browser:  my favorite browser. See my blog entry on the subject.

  • Edutainment + kids games:  On linux, one can download a number of games for children that are of high quality from the point of view of the material they cover.  Sure, some games like supertux, are just plain fun 'mario brothers' style games.  But many can be powerful tools that can hone the brain power of children.  Here are some of them:

    • kturtle (logo programming)
    • gcompris
    • tuxmath / tuxtyping

    My kids and I also very much like supertux, tuxracer, and tuxkart.  I'm particularly proud of my 3 year-old who is now a supertux champion and has mastered the arrow keys, the enter key, the control key, and spacebar.

  • Quality open source desktop applications.  Who said that open source can't produce desktop apps of higher quality than their commercial counterparts.  If you thought the adobe had the best vector graphics editing application, take a look a inkscape.  For pictures, check out the beauty of f-spot.  For spreadsheets, I think gnumeric is terrific.

  • Authoring tools.  A number of different technologies can be used to write books or articles.  Docbook is one and docbook support in the form of toolkits, documentation, utilities and more is the strongest on linux.  Many love LaTex.

    I particularly appreciate lyx, a wonderful wysiwym editor that does all the heavy lifting for you.  If you're about to write a book and don't have in-depth knowledge of docbook or latex, then I believe lyx is the right choice.

  • Strong pdf support.  One can easily produce a pdf version of a document, translate a postscript file to PDF.  I recently printed a web page to a postscript file and then translated it to PDF.

  • editors galores.  Lots of editors to choose from.  gedit, kedit, kate, jedit, and many more besides.

  • apt-get and the amazing synaptic package manager. Want an app?  Just wish it and a few seconds later it's completely installed on your system, along with all its dependencies.  That's the magic of the synaptic package manager.  apt is the technology that makes it happen and the synatpic front-end gives you no reason to ever fall back to the command line.

  • strong printer support

    • lj3200 which i'd given up on entirely with my mac (hp did not make apple drivers for this specific version), worked like a charm with linux, without having to install drivers
    • doing duplex printing with my brother 5150D at the office
    • doing network printing to an hp inkjet printer
  • wifi worked for me out of the box.

  • the sleep feature works just fine but does not conserve the battery charge nearly as well as my powerbook did.  hibernate then is the alternative, which has worked great for me for many months, up until a recent kernel update.

  • strong device support in general:  plugged in my camera and automatically started downloaded photos, without even having to download anything.

  • amazing endless suite of kde apps.  from kontact to koffice, kde is simply an amazing source of seemingly boundless energy.

  • kde and gnome apps can run side by side

  • terrific support forums

  • java:

    • unlike the last OS i worked on, there are no issues regarding obtaining the latest java udpates on time
    • all the java ides work with it: intellij, eclipse, and netbeans
    • have the option of building java applications that use the gtk toolkit
  • latest firefox

  • endless supply of artwork for customizing background image, login manager, login splash, window decorations, icons, and themes
  • freedom!

  • no viruses, no symantec, no mcaffee

  • complete desktop customization features, especially with kde, although in the end i prefer gnome;  i find myself forever tinkering on kde, and more productive on gnome.  each has their strengths and together they make for an even better distribution: a wider array of choices;  sometimes you get this feeling though that the velocity on the kde projects is just so amazing..

  • i love the ability to assign keyboard shortcuts to anything i rarely touch the mouse and am in complete control

  • ruby.  if you're doing ruby development, installing the toolstack, including rails is a snap.

  • cost.  i don't have to pay for additional apps.  my notebook cost me approximately 1/3 the price of my last one.

The Bad

  • projector support is not really there like it is on a mac
  • sleep does not conserve battery well
  • had some hickups with hibernate after a kernel update
  • have some weird totem/video problems at the moment, though there's no lack of video players for gnome or kde, this one happens to be the default and for some reason hangs when attempting video playback


The main reason I switched to ubuntu is that I can now compile and launch my java apps in 1/2 to 1/3 the time it used to take me on my last laptop. I used to run a 1GHz powerbook G4.  Now I run a 1.7GHz intel centrino (same amount of ram on both).  That's a serious advantage.

Finally, contrary the general perception, I don't compile my gnome apps or kernel.  I download and install precompiled binary distributions of all my apps.

I'm very satisfied with Ubuntu and in the event that you're looking for the right home, I hope this short review was helpful.


An Epiphany Blog

Posted by eitan Dec 13, 2005

Filter Blog

By date: