Native Eclipse Comes To Linux
I Just Installed Fedora Core 4 on my IBM Thinkpad T30 (the download speed did pick up.) I Encountered three gotcha's along the way:
- I needed to specify linux ide=nodma on the boot prompt, otherwise Mediacheck would fail
- My swap partition is not mounted. There is an error on line 13 of my /etc/fstab.
- When I close the lid on the laptop, it wouldn't go to sleep mode.
Aside from those, everything is clean and easy, just like before. The sound, video, Ethernet, and wireless network (Onorico?) cards are all detected and work flawlessly.
Exciting new features in this release of Red Hat's Linux system include OpenOffice.org 2.0 Beta, and Free Software Java based on gcj, GNU Classpath and ecj (The Java compiler in Eclipse JDT), including a natively compiled version of Eclipse 3.1 M6, with the Eclipse CDT and pydev (Eclipse Python development plugin).
It is really nice to see both "Java Development" and "Eclipse" mentioned in the package selection screen, alongside "GNOME Software Development" and "KDE Software Development". I know some Java programmers are skeptical of the whole Free Software Java movement. They would say things like "I just don't care if it's free or not" or "If you don't use Sun, all bets are off for portability" or "What do you mean Java is not free?" My answer is that it doesn't matter that we (the end developers—end users of the Java development tools) don't care. It's the vendors opinions that matters. It has always been that way for both proprietary and open source tools. In this case, Red Hat and others cared enough to put real resources on the development of Free Software Java. And they are showing what they've done.
And what they've done is something very interesting—A natively compiled Eclipse.
To appreciate the significance of this achievement, you need to go all the way back to June 1998, and reread the original paper that launched gcj. In the seven years since, we've witnessed the development of a clean room implementation of the Java compiler in front of our eyes. Sometimes I wished the Sun team is as transparent and responsive as the gcj team.
My initial observation is that the native version's startup time and memory consumption on the laptop (P4M(?) at 1.8GHz) are comparable to that of the bytecode version running on a Fedora Core 3 box (Athlon XP 2700+ 2.2GHz.)
Here's a screenshot of native Eclipse running with a CDT project. Once you get passed the original shock of "Oh, a native version of Eclipse!" you soon realize that "It's just Eclipse." You use it just as you would the regular version of Eclipse. In other words, "It's not that big a deal."
Although the gcj compiler and the GNU Classpath libraries (and the Kaffe JVM, etc.) have been available in Fedora Core (and Red Hat Linux before it) for a long time now. The substantially improved Java offerings in Fedora Core 4 signifies another step in the spread of Java—to Linux desktop machines and potentially to other more obscure platforms where Sun is either not willing to invest the time to port the JDK or not willing to grant a license for third parties to port the JDK. I still remember the time when Sun refused to support their JDK on Linux.
I haven't played with the other 122 Java packages that came with Fedora Core 4. But I've heard about a natively compiled Tomcat 5. I'll try putting this blog on that thing some time, just because I can!
I took only a cursory look at OpenOffice 2.0 Beta. It started up a lot faster than the previous version, felt snappier, and looked a lot sharper. I've heard from multiple heavy MS Office users telling me that OpenOffice 2.0 is good enough now. Kudo's to the OpenOffice team (mostly Sun employees?) for their hard work.
Looks Like It'll Take A While
I just started downloading the Fedora Core 4 Torrent. Looks like it's going to take a while:
At this speed, I won't be able to install it before I go on vacation this Friday. But I'll post my impressions of Fedora Core 4 when I come back early next month.
Fedora Core 4 Released
Fedora Core 4 is released today.
[Update: Here's the release notes:
* GNOME 2.10 With the elegant Clearlooks theme, descendent of our old friend Bluecurve. Keep your eyes open for Evince, the new PDF viewer. * OpenOffice.org 2.0 prerelease. This popular office productivity suite handles all your favorite formats even better than before, and comes with a new database management capability. * Eclipse and a 100% open source Java stack. Gcj, need we say more? * Fedora Extras Extras packages are available, by default, at release time. Extras is now integrated into the development, testing, and release cycles. * KDE 3.4 Complete desktop packed with a web browser, mail client, and so much more. * PPC (PowerPC) PPC architecture support. Oh, yes, folks, Fedora Core on your PPC. It is downright amazing!
]
Trouble With Subversion
I have encountered a problem with my use of Subversion. The Subversion 1.1.4 (r13838) server is running on a Fedora Core 3 Linux machine up2date-ed on a daily basis.
From another machine, I was able to do svn status, svn add, but was unable to do svn commit or svn up.
The error message I've gotten is:
[root@gao blog]# svn commit -m "Updated blogs" svn: Commit failed (details follow): svn: OPTIONS request failed on '/svn/trunk/blog' svn: Could not open the requested SVN filesystem
I'm using mod_dav_svn to connect to Subversion through Apache httpd. I haven't changed any settings lately.
If you have encountered similar situations I'd appreciate it if you can give me a hint. Meanwhile, I'll try to diagnose the problem myself and let you know what I found out. Hopefully soon.
[Update: The problem seems to be SELinux related. I'm seeing lines like the following in my system logs:
Jun 11 16:12:55 gao-2004 kernel: audit(1118524375.759:0): avc: denied { write
} for pid=3970 exe=/usr/sbin/httpd name=__db.001 dev=hda3 ino=32791 scontext=us
er_u:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
The system did receive an updated selinux-policy-targeted-1.17.30-3.2 earlier today.]
Ruby On Rails: The Video
We had our first ever non-Java topic presentation at the St. Louis JUG today. Mr. Curt "Ten times faster development, indeed!" Hibbs himself braved a severe thunderstorm to talk about Ruby on Rails.
This is the second time I heard Curt talking about Ruby on Rails. Curt did a good job of selling Ruby on Rails. Stopped short of doing a live demo, he did the next best thing—a screencast video of him doing a live demo.
You can find the slides and the screencast video (Windows required) here.
Other tidbits I picked up at the meeting:
Jeff Brown did an informal survey of IDE usage among the attendees, and the scores are: JBuilder 0, NetBeans ~2, IDEA ~5, Eclipse ~25.
Brian Gilstrap mentioned that Apple is using technology similar to Java HotSpot to run a PowerPC binary on an Macintosh using an Intel processor.
Most people still don't know what JSF is. The standard answer to the "What is JSF?" question seems to be "I haven't done any JSF, but I've heard that JSF is ..."
Whoever is in charge of JSF evangelization, quit talking architectures and show us something real. A 30 minutes video showing someone using JSF building a website would do. Just show us, like Curt did today, would you?
How Many Milliseconds Ago Was That?
Reading a recent article on The Java performance debate over there at OSNews, I can't help but notice passages like the following:
This means that by default a Java application won't overwhelm your system and cause heavy swapping and other such nastiness.
People seem to get so focussed on the milliseconds that they forget that if a task takes 0.01s in C++ and 0.02s in Java, then, "oh no", it's half as slow!
Yet, there is no shortage of Java developers who will tell you that Swing is fast.
The biggest trap Swing programmers fall into is that they don't understand the threading model that is employed.
As a Java developer, I will happily sacrifice some memory, and a bit of speed, because ...
In an article aimed at dispelling the dual myth of "Java is slow/Java is a memory hog," they sounded more like excuses than good arguments and advises.
And I contend that this "Can't win, Won't try" attitute is exactly what hurts Java programs and programmers the most. You see, when you subconsciously say to yourself "I'm writing in Java because I want to trade some of that performance off for programming convenience," you are less likely to pay attention to the little things that might have a negative performance impact. And these little things accumulate faster than you think. A dozen milliseconds here, a dozen milliseconds there, pretty soon you are talking about hundreds of milliseconds. And that might be bad for the whole program.
And that brings me to the problem that's bothering me since last week. I wanted measure as accurately as possible the "start up time" of my JVM, when running the "Hello World" program—the elapsed time between the moment the shell forks the Java process and the moment control pass into the main() method.
Any ideas?
Immutability Of Interfaces
Erich Gamma: Since changing interfaces breaks clients you should consider them as immutable once you've published them. As a consequence when adding a new method to an interface you have to do so in a separate interface.
I hope the W3C people are listening. I have shouted about their adding methods to published interfaces 256 days ago, but you guys shouted me down.
Anybody want to argue the same point with Erich Gamma?
Customize Google
Saw a nifty Firefox extension yesterday. It's called Customize Google. It brings the Google Suggest feature to the main Google page:
It can also do a whole lot of other things. For example, it rewrites Google image search result links to point straight to the images.
Look, Air Force One
(Air Force One just flew past our building about an hour ago.)
Dan: Look, Air Force One!
All: (Gathered around the big window and looked up at the silver plane in the sky.)
Jonathan: How do you know it's Air Force One?
Dan: I saw the sign on the plane when it was closer.