Fedora Core 2, The One Week Report
Here's my Fedora Core 2 experience report after one week of usage. First the positive:
- The unofficial-official yum repositories (as described in the Unofficial FAQ) for things not included on the CD for licensing reasons. The installation of RealPlayer, Adobe Reader, XMMS MP3 plugin, Flash plugin, etc., is as painless as "yum install [package-name]".
- The very usable input method support in Gnome 2.6. Right clicking on any Gnome text component brings up a context menu that includes an "Input Methods" submenu. Select the "Internet/Intranet Input Method" (iiimf) menu item and a taskbar applet will appear that allows for switching among the selected input methods. This is available even if I'm logged in with a US/English locale.
- Tomcat 4.1.27 is included in the CD and is ready to run, just as any other system services. Many other Java packages are bundled in the CD: ant, junit, xerces, xalan, struts, mx4j, bcel, etc. I especially like the way the installed their jar files in a common location /usr/share/java.
- The Mono 1.0 Beta1 yum repository for Fedora Core 1 seems to still work for Fedora Core 2. ASP.NET (xsp.exe), Gtk#, WinForms all seem to work. Official FC2 support, along with the MonoDevelop IDE, will be available with Mono 1.0 Beta2, scheduled for tomorrow, according to the Mono 1.0 Roadmap.
- New versions of familiar softwares all around: subversion 1.0.2 (was 0.31.0 in FC1), Mozilla 1.6 (was 1.4), Gnome 2.6, kernel 2.6.5, Open Office 1.1.1, etc.
- Newly available software such as the Rhythembox music player.
Now the glitches:
- No 3D support for my nVidia GeForce MX 440 video card yet.
- The dictionary taskbar applet stopped working.
- The Volume Control Gnome applet is very confusing, at least for the on board RealTek ALC650 6-channel audio chip on my MSI KT4AV mb. With about 90 vertical slider bars laid out in a single row, I have to use the horizontal scroll bar five times to get to the right end of it. It took me a while to figure out by trial and error that the four controls names "VIA DXS" on the far right end are the ones that control the volume.
- Unfortunately, the Sun JDK/JRE falls into the category of "software packages of questionable licenses and need a separate download." As a Java developer, I want at least the JRE to be distributed as widely as possible. Seeing that in the case of Fedora Core 2, the Sun license is preventing the widest distribution of the JRE, I recognized the importance of the recent round of "Open Source Java" calls. And I'm ready to switch sides from Sun to ESR and IBM.
- The gcj compiled native executable /usr/bin/ant takes precedence over any ant ant shell script from the canonical Ant installation if the /opt/apache-ant-1.6.1/bin directory is not put in front of the /usr/bin directory. I reported a similar problem with the jar command in the context of Cygwin 66 days ago. Other affected commands include rmic and rmiregistry.
JDK 1.5 Beta 2 Tidbits
Just downloaded beta 2 of Java 1.5. And there are plenty small things that's noticeable (by browsing the documentation, I haven't tried any of these in code yet):
- On Windows, it installs itself into "C:\Program Files\Java\jdk1.5.0" and "C:\Program Files\Java\jre1.5.0". It's no longer j2sdk. I never liked that name.
- The System.getenv(String) method is no longer deprecated.
- JFrame.add() works again. It took them seven years to do it!
- The new javac -Xlint option produce warnings for legal but potentially problematic constructs.
- There's a new tool called apt. Guess what it does. (Not getting new packages for your Debian distribution of GNU/Linux!)
- IndexedPropertyChangeEvent is finally added to the JavaBeans API.
- The java.lang package grew quite a bit. New members include Appendable, Iterable, Readable, Thread.UncaughtExceptionHandler interfaces and Enum, ProcessBuilder, StringBuilder classes.
Now, is it too much to ask for a JFrame that shows up where Windows (or GNOME or KDE or CDE or Motif or whatever) would have it show up instead of the top-left corner?
Pragmatic Programmer Quiz
I'm sure everybody have heard about and read the book The Pragmatic Programmer.
Now it's time to close your book for a little quiz:
-
When was the book published?
- 1996
- 1998
- 2000
- 2002
-
How often did they recommend you to learn a new language?
- Every month
- Every quarter
- Every half year
- Every year
-
How many new languages should you have learned by now?
- 8
- 6
- 4
- 2
-
What are they?
-
How many tips did they give in the book?
- 30
- 50
- 70
- 90
-
How many do you know by heart (no peeking into the book)?
- 0
- 1
- 2
- 3
-
Say one of them.
-
What is the DRY principle?
-
How do you write "shy" code?
-
Was JUnit old enough to be mentioned in the book? How about AOP?
bin & lib, or bine & libe?
Here's a trivia question: How do you call your bin and lib directories?
I've always call my bin the "bin" directory and my lib the "libe" directory.
I didn't realize the inconsistency in my convention until recently: If I call lib libe because it is short for libraries, then I should call bin bine because it is short for binaries.
Right?
Fedora Core 2, nVidia GeForce 4 MX, Windows 2000 Dual Boot, ...
I installed Fedora Core 2 on my workstation last night. I did a reinstall rather than an upgrade. I also took the opportunity to reinstall my Windows 2000 on the other side of the reboot (A Windows Update hosed my Windows 2000 installation 83 days ago).
Both went smoothly. The Windows 2000 installation took longer (3 hours) than the FC2 installation (50 minutes), just like the last time. This time I kept the NTFS partition on the primary master (first) hard drive that Windows 2000 required, even though I'm installing Windows on primary slave (second) hard drive.
I've heard warnings about FC2 messing up Windows 2000/XP dual boot on O'Reilly Weblogs and Slashdot. I did receive a warning during the FC2 installation informing me that there's something wrong with my partition table. But the message also mentioned that the problem is fixable after the installation. It turned out that my system dual boots just fine.
I've also heard that the nVidia driver is not compatible with FC2's kernel. But I'm less concerned about that because I don't play games on my machine. The stock nVidia driver that comes with FC2 works just fine for my nVidia GeForce 4 MX card.
All in all, a very smooth process. I'm sticking with Fedora Core:
- 05/23/2004: Installed Fedora Core 2
But of course YMMV.
I *Do Not* Hate Red Hat Linux
I have been a very happy Linux user since 1994, and a Happy Red Hat Linux user since (around) 1996. Here's just a few entries in my system maintenance log book (I did not keep a log before 1998):
- 06/20/1998: Installed Red Hat Linux 5.0 (Hurricane)
- 11/04/1998: Upgraded to Red Hat Linux 5.1
- 05/01/1999: Installed Red Hat Linux 5.2
- 08/28/1999: Installed Red Hat Linux 6.0
- 02/18/2000: Installed Red Hat Linux 6.1
- 07/10/2000: Upgraded to Red Hat Linux 6.2
- 02/17/2001: Installed Red Hat Linux 7.0
- 11/28/2002: Upgraded to Red Hat Linux 8.0
- 05/03/2003: Upgraded to Red Hat Linux 9.0
- 11/09/2003: Installed Fedora Core 1
As you can see, I came back to Red Hat Linux again and again and again and again and again and again and again and again in the last eight years. Keep in mind that coming back to Red Hat Linux is different from coming back to Windows or even MacOS because unlink Windows or MacOS, there are alternative Linux distributions such as SUSE, Mandrake, Debian, Gentoo, Knoppix, etc.
I choose to come back to Red Hat Linux because
- It does what I needed
- Switching to a different brand of Linux offers too much pain with too little gain
Then, all of a sudden, you see a column somewhere titled Why Linux Users Hate Red Hat.
Even before I clicked on the link, several thoughts went through my mind. The most prominent one being: Why am I not hating Red Hat Linux? Is there anything wrong with me?
Had I not actually read the article, that thought would have taken root and might actually influence my decision for the next upgrade cycle.
It's a good thing I did read the article and discovered that it's all about Red Hat Inc.'s business decisions regarding the EOL of Red Hat Linux 9.0 and how
Business customers, who usually expect to get at least three years of work out of an operating system, were as mad as wet hens to find their support disappearing from underneath them.
And in general I agree with everything the article says except for the above quote and the poor choice of words in the title.
You see, Red Hat Linux 9.0, for people who bought it, included:
- 30 days Web-based installation support
- 30 days Red Hat Network Basic Service
And on the outside of the box there is a big lettered notice surrounded with a black frame that reads:
Want to run your business on Red Hat Linux?
Red Hat Enterprise Linux is the right choice for you. Get mission-critical functionality, support from top enterprise vendors, a longer product life cycle, and up to 24 x 7 support to keep your business running. Purchase or learn more at www.redhat.com/enterprise/
I don't see how anybody could be so confused as to buy something with 30 days of support and expect a three year life cycle.
Maybe they are reading the wrong trade magazine?
As for me, I have just downloaded Fedora Core 2, which is released 4 days ago. I'll upgrade when I have a chance.
BeanShell
Jeff Brown: If you are a Java developer and you aren't familiar with Pat Niemeyer's BeanShell, you should check it out. ...
I agree 100%. Check out the User Manual and the presentation at St. Louis JUG, which I reported on 209 days ago.
Duplicate Classes In CLASSPATH
Here's a hypothetical question :): Should the same Java class be allowed to appear twice in the CLASSPATH of one application (in two different jar files)?
Windows, Java, Linux, ...
(There is a debate going on between Bryan Young and Anthony Eden over .NET yesterday. I just want to add some fuel to the fire.)
These are three platforms for developing and deploying software systems that has become popular over the years.
If you look at their adoption curves, you will see something very similar:
Windows started out as a single process under DOS with non-preemptive multitasking capabilities and a slick API for writing Windows programs (or was that a plug-in?). People liked it. They started to write little programs for it.
A few years and versions later, its popularity grew, and finally SQLWindows, PowerBuilder, Visual Basic made it the platform of choice for the client platform.
Java started out as a virtual machine that runs on several operating systems with a very intuitive language and a six package API that included a five widget GUI toolkit. Class files are portable. People liked it. They started to write little programs for it.
A few years and versions later, its popularity grew, and finally J2EE, IntelliJ IDEA, made it the platform of choice for the Web development.
Linux started out as a clone of the Minix operating system with all standard, and familiar, tools and APIs. It's free. People liked it. They started to write little programs for it.
A few years and versions later, its popularity grew, and finally Mono/C#/.NET made it the platform of choice for Free Software applications.
Mono also has some of that "people like it" quality itself. Whether it will become a dominant platform for Free Software development remains to be seen. But the seed is already there.
I can't speak for others, but I find myself liking Mono the same way I liked my console based Slackware Linux (in 72 floppies) back in 1994, the same way I liked my AWT based Java applet (no new JDK 1.1 Events, no Collections, no Swing) back in 1996, and the same way I liked my GNOME based desktop (no Nautilus, crashes daily) in 1998.
O'Reilly Developer's Notebook Series: Mono
Stumbled upon this blog by Didier Girard, over there at Application-Servers.com, about a new O'Reilly book: Mono: A Developer's Notebook.
Here is an outline by the first author Edd Dumbill. This book is going to be the second (the first being a Hibernate one) in a new Developer's Notebooks series.
I'm looking forward to this new book, which will hit the stores when Mono 1.0 is released.
I also like the idea behind The Developer's Handbook series, which is to introduce new technologies to experienced developers through lab like examples.
As much as I say I like the Nutshell books, I haven't opened my Java In a Nutshell for about two years, maybe longer. The Javadocs is simply easier to get at (Shift-F1 in IDEA).
The Text Zoom Test for Web Pages
I read a lot of web pages. Unfortunately, most of them use font sizes that are too small for me. So I use the "Text Zoom" feature of my browser (Ctrl++, Ctrl+-, and Ctrl+0 in Mozilla) to make the words bigger.
I have noticed that some web pages don't respond well to this treatment:
- The fixed width column: This happens most on "news" sites. As I increase the font size, the column that contains the text does not grow with it. I end up with a couple of words per line.
- The crazy rules: This happened on at least one weblog that I read regularly. It uses horizontal and vertical rules to separate different areas of content. As I increase the font size, the texts grow as I expected, but the rules jump all over the place, clashing with the text.
- The overlapping layers: This happened for some of the weblogs I read. As I increased the font size, different regions of the page grow into each other, obscuring each others words.
- The disappearing header: Again, on a blog, as the font size increases, the area reserved for the page header remains constant, clipping off first the sub title, then increasing percentages of the bottom portion of the main title.
I suspect most of these are caused by hard coded pixel sizes, and shouldn't be that hard to fix.
Could you please take a moment and do a few text zooms on your web pages for me?
Thank you!
Generics in Java Are Evil?
Dean Wette's talk about Collections and Generics in J2SE 1.5 at the St. Louis Java Users Group tonight is livelier than usual.
Here's the gist of the talk:
- Generics are evil: The deeper I dig into the specification, the scarier it gets.
- Generics solves a problem that's not there: The kinds of errors that a type safe collection prevents are the trivial programmer errors that's easily detected with unit tests. IDE's can help with the drudgery of casting when working with Collections.
- JDK 1.5 generics uses erasure: None of the parameter type information is present in bytecode. Therefore instanceof doesn't work with generic types. Many intuitive programming constructs are illegal. The erasure decision was made so that Sun doesn't have to modify the JVM. They ended up modifying the JVM anyway.
- The new syntax is too complicated: I've been doing Java since 1996 and am pretty good at it. I'm having trouble with the syntax. Just imagine what a new Java programmer will feel.
- I would rather use C++ templates!
Dean did talk about several things that he likes: autoboxing, and the enhanced for loop. The java.util.concurrent classes were not covered tonight but were favorably mentioned.
Jeff Grigg urged programmers to take a look at C# for generics done right.
How would you like code like this?
public <T extends Comparable & Serializable> T foo(Collection<T> c1,
Collection<? extends T> c2) {
// ...
}
What Does It Print
(This was first posted 902 days ago. Zhicheng thought it's worth a repost.)
Question: What is printed when you run java Main?
// Main.java
class A {
// A is a singleton. The getInstance() method is even synchronized.
private static A instance;
public synchronized static A getInstance() {
return (instance == null) ? (instance = new A()) : instance;
}
// A uses B
private B b;
private A() {
b = new B();
}
}
class B {
// B caches the only instance of A
public static A a = A.getInstance();
}
class Main {
public static void main(String[] args) {
System.out.println(A.getInstance() == B.a);
}
}
Quiz: Default Encoding of Java Source Files
Quickly, without peeking into the documentation, answer this question:
When you run javac Foo.java, what encoding does the Java compiler assumes Foo.java to be in?
Is it UTF-8? UTF-16? ISO-8859-1? ASCII with escaped Unicode? Or something else?
I Wrote a Web Service :)
I have never written a Web ServiceTM. Until today, that is.
I've heard all about Axis, WSDL, SOAP, doc/literal, rpc/encoded, JAX-RPC, SAAJ, etc. But the process of setting everything up and actually writing and testing a Web Service in Java just seemed so daunting. And I never got around to try it.
The Beta 1 release of Mono contains a ASP.NET/Web Services host called XSP. So I decided to take it for a spin.
[weiqi@gao] $ cat hello.asmx
<%@ WebService Language="C#" Class="Hello" %>
using System;
using System.Web.Services;
public class Hello : WebService {
[WebMethod()]
public string SayHello() {
return "Hello, World!";
}
}
[weiqi@gao] $ mono /usr/bin/xsp.exe
Listening on port: 8080
Listening on address: 0.0.0.0
Root directory: /home/weiqi/temp/src/webservice
Hit Return to stop the server
The URL http://localhost:8080/hello.asmx gives me the WSDL and client proxy code. I took the client code, added a Main() method, compiled, and run it. It worked as expected.
[weiqi@gao] $ mcs -r:System.Web.Services hello.cs Compilation succeeded [weiqi@gao] $ mono hello.exe Hello, World!
EJB 3.0 Will Be Different
When I heard the talk about "The Spring Framework is going to kill EJB" 43 days ago at the NFJS symposium, I thought they were just joking. EJB's not going to be killed, I thought.
Apparently they know something I don't. Reports from TheServerSide Symposium, here, here, here, here, and here, describe the announcement of EJB 3.0 by Linda deMichiel, EJB 3.0 spec lead.
Some noticeables:
Dion Almaer: No more home interfaces, deployment descriptors, SessionBean interfaces.
Hani Suleiman: EJB 3.0 is basically a bizarre subset of Hibernate, for the CMP portions. The session bean bits are...Spring!
I don't know about you, but it sounds to me like EJB, as we know it, has indeed died. EJB 3.0 will be a whole different ball game.
Mono Beta 1 Here, 1.0 in June
Ximian^H^H^H^H^H^H Novell announced Mono Beta 1 yesterday. Mono is an implementation of the .NET Framework for Linux, Unix and Windows.
I had been a fan of Mono since the early days, getting the sources from CVS, building it daily to see the progress, and writing my first C# programs with it.
It's amazing what the Ximian folks have done in a few short years. The Beta 1 release for Fedora Core 1 contains 48 RPMs totalling 67MBs in size.
Installation is a breeze with yum. I simply added the following in my /etc/yum.conf and installed everything that's available (yum list followed by a bunch of yum installs):
[mono] name=Mono baseurl=http://www.go-mono.com/archive/beta1/fedora-1-i386/
Here's the obligatory Hello GTK# application:
using Gtk;
using GtkSharp;
using System;
class Hello {
static void Main() {
Application.Init();
Window window = new Window("Hello Gtk#");
window.DeleteEvent += new DeleteEventHandler(DeleteEvent);
window.Show();
Application.Run();
}
static void DeleteEvent(object obj, DeleteEventArgs args) {
Application.Quit();
}
}
And here's the screenshot:
JARPATH
The concept of the CLASSPATH has been with us since the beginning. The concept of the Jar file has also been with us for some time now, although I still remember the time when it was introduced in JDK 1.1.
I've always felt that there is something wrong with both concepts, but couldn't pin it down.
Today I had an A-ha moment: The way Java's going about putting classes into a CLASSPATH is just silly. We should be using something like a JARPATH, not CLASSPATH.
The Java class file is no longer the unit of distribution of modern Java systems. We deliver our systems as a set of Jar files. Yet we insist on maintaining a CLASSPATH.
This is the wrong level of granularity.
We sort of already have a solution for this problem in the context of web apps with its WEB-INF/lib directory. We also can use the JRE extension mechanism whereby you can put a jar file into the $JRE_HOME/lib/ext.
But can't we persuade Sun to introduce a JARPATH environment variable? So that instead of doing:
export CLASSPATH=$CLASSPATH:/opt/jboss-3.2.3/client/concurrent.jar:\ /opt/jboss-3.2.3/client/getopt.jar:\ /opt/jboss-3.2.3/client/gnu-regexp.jar:\ /opt/jboss-3.2.3/client/jacorb.jar:\ /opt/jboss-3.2.3/client/jbossall-client.jar:\ /opt/jboss-3.2.3/client/jboss-client.jar:\ /opt/jboss-3.2.3/client/jboss-common-client.jar:\ /opt/jboss-3.2.3/client/jbosscx-client.jar:\ /opt/jboss-3.2.3/client/jbossha-client.jar:\ /opt/jboss-3.2.3/client/jboss-iiop-client.jar:\ /opt/jboss-3.2.3/client/jboss-j2ee.jar:\ /opt/jboss-3.2.3/client/jboss-jaas.jar:\ /opt/jboss-3.2.3/client/jbossjmx-ant.jar:\ /opt/jboss-3.2.3/client/jboss-jsr77-client.jar:\ /opt/jboss-3.2.3/client/jbossmq-client.jar:\ /opt/jboss-3.2.3/client/jboss-net-client.jar:\ /opt/jboss-3.2.3/client/jbosssx-client.jar:\ /opt/jboss-3.2.3/client/jboss-system-client.jar:\ /opt/jboss-3.2.3/client/jboss-transaction-client.jar:\ /opt/jboss-3.2.3/client/jcert.jar:\ /opt/jboss-3.2.3/client/jmx-connector-client-factory.jar:\ /opt/jboss-3.2.3/client/jmx-ejb-connector-client.jar:\ /opt/jboss-3.2.3/client/jmx-invoker-adaptor-client.jar:\ /opt/jboss-3.2.3/client/jmx-rmi-connector-client.jar:\ /opt/jboss-3.2.3/client/jnet.jar:\ /opt/jboss-3.2.3/client/jnp-client.jar:\ /opt/jboss-3.2.3/client/jsse.jar:\ /opt/jboss-3.2.3/client/log4j.jar:\ /opt/jboss-3.2.3/client/xdoclet-module-jboss-net.jar
I can simply do:
export JARPATH=$JARPATH:/opt/jboss-3.2.3/client
