I bought a ThinkPenguin.com laptop for my Mom for her birthday. She’s a long time GNU/Linux user and she was ready for an upgrade from her ThinkPad T41. I decided to try ThinkPenguin.com. I’m really impressed with their service and their product.
The laptop shipped within a few days, and when it arrived it had Fedora 17 pre-installed like I had requested. The build quality is very good. It’s a slim light laptop with attractive styling, and a solid keyboard. One of ThinkPenguin’s main selling points is hardware support, and it really was great. Graphics, Wi-Fi, suspend, hibernate, resume all worked perfectly, out-of-the-box, no configuration necessary. It’s fantastic to get this smooth out-of-the-box experience with GNU/Linux instead of a proprietary operating system.
If you care about Free Software and are in the market for a laptop, check out ThinkPenguin.com.
I bought the Pulse-Eight USB CEC adapter a few months back and so far it’s been a great addition to my XBMC setup. For a long time I wanted to control my TV from my Android phone, for a few reasons. First, I usually have it with me and charged up, unlike my TV remote which might be misplaced or out of batteries. Second, I find it annoying that the infrared TV remote requires line-of-sight. And finally, a smart phone remote just seems like the right way to control a TV in this day and age.
For such a tiny package the Pulse-Eight adapter enables a lot of functionality. I can turn my TV on and off from my phone over Wi-Fi, using the Official XBMC Remote Android app and a slightly-hacked version of XBMC. But there’s more. Guests who prefer using a TV remote can use its extended buttons to control XBMC playback. The adapter enables communication in both the TV-to-XBMC and XBMC-to-TV directions by passing CEC commands over the HDMI bus. And its inventors maintain a Free Software library, libcec, to control it. This is a much cleaner and cheaper solution than the various Wi-Fi-to-IR converters I’ve looked at.
If you run XBMC make sure to check out this adapter.
I like to read documents in fullscreen mode using keyboard navigation. I want a viewing mode with the following properties:
- No scrollbars
- No navigation toolbars
- No drop-shadow page borders
- Fit-to-width display
- Emacs-style scrolling, maintaining 2 lines of context for continuity
To me 1, 2 and probably 3 should be properties of anything claiming to be “fullscreen mode”. Unfortunately fullscreen mode now seems to mean “mostly fullscreen mode with some widgets reminding you you’re in fullscreen mode”. Nowadays what I want would be called “true fullscreen mode”.
The DjVuLibre document viewer can be configured to support all these requirements. It provides a perfectly clean mode, allowing you to really focus on the document itself with no distractions. Unfortunately it only supports DjVu documents.
Evince has excellent multi-format support but its fullscreen fit-to-width mode fails 1 with an ever-present vertical scrollbar, 3 and 5. Its presentation mode is fully-uncluttered but it is necessarily not fit-to-width, so it’s not great for just reading documents.
Okular seems at first glance to have format support equivalent to Evince but its fullscreen fit-to-width mode fails 2 with a non-removable navigation footer, 3 and 5.
Maybe I’ll file some Evince feature requests. In the meantime, any suggestions for other viewers?
A patch I wrote for mobileorg-android was accepted and shipped to the Market in mobileorg-android 0.4.8. It works around lighttpd’s missing support for the Expect HTTP header. The issue was that pulling from lighttpd to the phone would work, but pushing from the phone to lighttpd wouldn’t.
To debug the problem I set up an Android development environment. In doing so I found android-mode.el and android.el (shipped with the SDK in android-sdk-linux_86/tools/lib) very useful both during development and initially for learning the Android Emacs workflow. For the most part, developing for my Nexus One was very straightforward. The only issue I ran into was not being able to start /sbin/adbd on the phone.
Since none of the Android development tutorials I Googled mentioned this problem, I’ll outline the symptoms here. If this issue affects you, the Settings -> Applications -> Development -> USB debugging check box on your phone will have no effect. After you’ve checked “USB debugging”, when you plug your phone into your development machine via USB, the USB file storage dialog will come up. “adb devices” on your development machine will not list the USB-connected phone. If you open a terminal window on your phone,
$ getprop persist.service.adb.enable
will print 0, and
will not list /sbin/adbd.
When things are working correctly, checking USB debugging causes /sbin/adbd to be run on the phone. /sbin/adbd exports different USB endpoints to “adb fork-server server” (started by adb on the development machine) so that the phone shows up as an Android development device, instead of a USB hard drive.
In my case the workaround was to check “USB debugging” then reboot my phone. After the reboot, persist.service.adb.enable was set to 1 and /sbin/adbd started when I checked USB debugging.
Unfortunately I couldn’t find a way out of this scenario without rebooting my phone which I avoid doing if possible (my best uptime so far is 60 days ended by the 2.2.1 system update). I haven’t rooted my Nexus One so /sbin/adbd caused “Permission denied”, and I couldn’t change persist.service.adb.enable to 1 with setprop; it would stay set to 0. Without /sbin/adbd (and before I discovered the reboot workaround), I was left having to manually install a mobileorg-android .apk file via the SD card which was a pain. I was disappointed that I didn’t have control over persist.service.adb.enable (which I assume I would if I had root). The main reason I bought the Nexus One was for its unlocked hackability, so things like this leave a bad taste. Hopefully the issue I linked to gets resolved.
I’m very happy to see IcedTeaPlugin enabled by default in the Fedora 12 Live USB images. This wasn’t always the case — in the past space-savings arguments were made to exclude java-1.6.0-openjdk and java-1.6.0-openjdk-plugin from Live images. I haven’t found out who’s responsible for the editorial change-of-heart, but to the people who made it happen: thanks! It’s great to see this plugin, and others, installed and enabled in the browser by default. No messing around finding and downloading Firefox plugins post-install or worse, during a Live session; just true “Works-Out-of-the-Box” operation.
My main interest in this release is seeing the LiveConnect work that I started in IcedTea finished and released. Deepak Bhole did an amazing job taking over where I left off — IcedTeaPlugin was prototype quality when I handed it over. He completed the major features and then polished the result into the robust plugin that appears in Fedora 10. Thank you Deepak!
Today, I had my first “Just Works” experience with the plugin when reading about Biosphere 2. The Cortado video player applet in that page first asked me if it could open a connection to upload.wikimedia.org and then played the video. Adjusting the PulseAudio Mixer volume control works for this applet, which may mean that IcedTeaPlugin is also using the PulseAudio backend written by my excellent interns, Ioana Ivan and Omair Majid. It’s nice to see that work released too!
In general Fedora 10 is nice. All the hardware on my HP Pavilion dv5t works fine, though the 3D graphics performance is not good. The graphical boot feature doesn’t seem to be enabled for my graphics card yet which is a little disappointing but booting does feel faster with this release.
I’m currently using swfdec 0.9.2 (built from source) as my Flash plugin. It’s getting there! The only thing preventing YouTube from working acceptably is the lack of support for the AAC audio codec. It’s nice to see progress on this very important component of the Free Software desktop!
I’ve also got Ekiga set up but I’ll have to convince some of my Skype-using friends to try it with me.
Looking forward to Fedora 11, I’m glad to see the volume control nightmare coming to an end and I’m super-excited about the Windows cross-compilation efforts. My wish list at this point is pretty short: kernel modesetting enabled for my graphics hardware, better 3D graphics performance, and to the Red Hat Java Team: try to get IcedTeaPlugin on the Fedora LiveCD!
Red Hat Summit was great. I manned the Open Source Java booth on the show floor. There was a lot of interest in what we’re doing, and people were impressed to hear that the OpenJDK packages in Fedora pass the TCK. I showed a few IcedTea demos including IcedTea Web Start and gcjwebplugin. Notably, they were running on my daily-use Fedora 9 notebook with the current OpenJDK packages; unlike at previous conferences where I always had to show development versions, this time I just browsed to interesting demo sites and everything just worked. Knowing that any Fedora 9 machine would run the same demos out-of-the-box was a nice feeling.
Every single person I talked to about OpenJDK asked me about the plugin. I had to give them an answer with caveats. Hopfully those caveats can be eliminated by Fedora 10, and from then on I can say IcedTea provides a plugin that Just Works.
I attended talks by Sami Wagiaalla (Frysk), Andrew Overholt (Eclipse) and Richard Hughes (power management). I was already familiar with the first two subjects but I really enjoyed Richard’s talk. I liked his point that GNU/Linux distributions can beat proprietary operating systems on battery life/data centre cost because we control the entire stack of software and thus can audit for and patch out wasteful power consumption.
The Fenway Park tour was terrific, what a quaint stadium! Now I really want to see a game there.
FUDCon was fun too. Andrew Overholt and I shared a time slot, thanks to the Barcamp format with which I was previously unfamiliar. I gave my IcedTea/OpenJDK status spiel, which I had honed over the past four days at the Summit. Other talks I attended: Secondary Arches, Augeas, Kernel, and Upstart. All talks indicate Fedora making great progress. FUDCon was the first I had heard of talk.fedoraproject.org; nice to hear Paul Frields keeping it real by entertaining totally crazy (but maybe brilliant!) ideas like offering free phone support for Fedora.
All-in-all a fun trip. Nice to be in Boston for the Celtics win, just so I can say I was there.
IcedTea 6 Mercurial tip configured with –enable-liveconnect on Fedora 9:
That’s a signed LiveConnect applet.
I’m planning two Fedora Features for OpenJDK in Fedora 10. I’ll write the Wiki pages soon.
Improved Multilib Support for JDK Packages
The first feature is improved multilib support for Java packages. This will involve fixing the darn persistent rpm scriptlet argument bug and adding multilib support to jpackage-utils and java-1.6.0-openjdk. I already have patches for these latter two but they depend on the rpm bug being fixed. We’ll have to carefully test upgrade paths when introducing these changes.
I’m hoping we can make java-gcj-compat multilib-compatible as well. My current plan involves using wrapper binaries for the tools instead of the direct symlinks we use now.
If we complete this feature Fedora 10 will allow parallel installation of 32-bit and 64-bit OpenJDK packages. Likewise for subsequent RHEL releases.
Java Packaging Improvements
The second feature deals with miscellaneous messiness in the current packages.
- Merging the rest of java-gcj-compat into libgcj. We’ve made steady progress in this direction with each Fedora release. Hopefully Fedora 10 will complete the process. Josh Sumali is already making headway on this.
- Security provider and extensions packaging improvements. This will allow us to package extensions like BouncyCastle such that they’re automatically loaded by the JRE. It will also allow us to move the GNOME Java Access Bridge currently bundled in the OpenJDK packages into its own separate package.
- Move %config files under /usr to /etc and replace them with symlinks.
- Rename java-1.6.0-openjdk* to openjdk*? Now that OpenJDK is becoming a standard component of Fedora we should revisit the JPackage naming conventions for it. The idea would be to use the python naming approach. The latest OpenJDK packages would be called openjdk and older releases would be renamed e.g., compat-openjdk6. (I’m a little conflicted about this. There’s some merit to the shared library approach — that once a name’s been used you can’t reuse it for an incompatible update because you’ll break dependents — but retaining one name across major versions forces dependent packages to update to the new version (a good thing for Fedora) and also simplifies dependency specifications.)
- Eliminate embedded full version strings from the OpenJDK directory names. We’d collapse directories like /usr/lib/jvm/java-1.6.0-openjdk-220.127.116.11 to just /usr/lib/jvm/java-1.6.0-openjdk. Our internal rpmdiff tool has trouble with versioned directories — this change would reduce rpmdiff output noise. It would mean that you couldn’t install OpenJDK 18.104.22.168 and OpenJDK 22.214.171.124 in parallel, but people should never need to do that. If they did, it would be to work around a bug that should just be fixed instead.
- Eliminate alternatives use from the OpenJDK packages, making them the exclusive owners of /usr/bin/* symlinks. I wish! It’s probably too soon to relegate other JDK alternatives to /opt though.
The primary goal of this feature is to make our OpenJDK packages easier to maintain. A secondary goal is to make packages that depend on OpenJDK easier to maintain. And the larger goal is smooth long-term maintenance of these packages in RHEL.
Plugin and Web Start
A shout-out to Planet JDK readers: Wouldn’t it be awesome if Sun’s cool plugin and Web Start rewrites were released in time to be shipped in Fedora 10?