 The Fuse design team is doing a great job with the XO-3 design. The images look great, and the price point (sub $100) is awesome. The timeline says the XO-3 will be available in 2012, and I can’t wait to see one in action.
I’m a sucker for new Linux based computers, and cheap Linux based computers are even better. I’m anxiously awaiting the arrival of my my Cherrypal Africa (I’ll be posting the unboxing as on the day it arrives, and how to load Linux if it doesn’t come with Linux installed). The day is coming when we’ll see cell phones and computers at grocery store between the Black and Mild cigars and the 5 hour energy drinks.
The OLPC folks don’t have to build this computer. They just have to threaten to build it. Prices will fall, feature sets will rise and programmers will be employed. At the rate that ARM processors are showing up in mobile devices, I wouldn’t be surprised if this device is running on an as-yet-unannounced 2ghz ARM processor and running a snappy version of Android.
 OpenRD Client The Christmas music is playing around my house now, and the Thanksgiving turkey hasn’t even been bought. All of this holiday spirit got me to thinking – what would be some of the best geek Christmas gifts this year? I’ll try to post some of the things that friends of mine are talking about (and lusting after) over the next month.
Near the top of my list is an OpenRD ARM based low power computer. The OpenRD comes in two models – the OpenRD Base, and the OpenRD Client.
OpenRD Base $149
- High performance Marvell® Sheeva™ up to 1.2 GHz
- Supports both Big & Little Endian
- Includes MMU to support virtual memory
- 512 MB DDR2-800 SDRAM in 2 banks of x8 devices and 512 MB NAND Flash
- 12 Volts power supply
- SD Card
- 1 USB 2.0 Port with integrated PHY
- 1 GbE Port with GMII and RGMII support
- SATA/eSATA Ports with integrated Marvell 3 Gbps SATA PHYs
- 1 x PCI Express (PCIe) Port
- UART with RS232 (Yay legacy!)
- USB Interface for Debug supports JTAG & Serial Console
- Operating System: Linux 2.6.22.18 & Fedora 8.0
OpenRD Client $249 (Additional features)
- 7 USB 2.0 Port with integrated PHYs
- 2 GbE Ports with GMII and RGMII support
- VGA support up to 1280×1024 at 60 Hz
- UART with RS232/RS485 interface
I’m itching to use the OpenRD Client to
- run my web and DHCP server off of battery power (7 watts at idle)
- be a MythTV client
- Provide In-room touch screen information
There’s also a smaller member of this family – the Sheeva Plug. It’s built into a wall wart sized package, it’s got the processing power of the OpenRD boards, and just a USB plug for output.
Any of these could excite your geek this holiday season.
In a recent post ( There’s no shame in looking good) DHH says
“it’s at the core about people feeling good about that which is pretty. That doesn’t make us shallow, that just makes us human.”.
I think, though, we’ve got our own perception of pretty. My idea of pretty is the Thinkpad that he mentioned in the article (up next to the MacBook Air). I agree that the MacBook Air has some aesthetics, but the beauty that I see in the Thinkpad is durability and support for my favorite OS (Linux). There’s a line there – I wouldn’t accept a brick for a laptop, but my perfect design is significantly different than DHH’s.
Embrace what looks good to you. Is it the aesthetics of a clean, svelte design? Or, like me, do you appreciate the durable and extensible? Where do you draw the line? What’s your perfect design?
While browsing the blog of a fellow penguin lover, I noticed his latest post. Apparently Best Buy is offering Linux on laptops now. Links and images are posted over on Vincent’s post.
I’m embarking on a little Flex development, but I ran into a snag installing the Flex Builder into my *very* stock Fedora 8 system. I found a link to some comments here in follow up comment to the author of the post.
Apparently (and I’m not an Eclipse expert), the problem stems from Fedora’s choice of “Eclipse Europa”, rather than “Eclipse Classic”.
Problems:
- The install says “Choose an existing Eclipse 3.3 or higher root folder to be extended with the Flex Builder Plug-ins”
- An error message is displayed when you select the correct folder
%20not%20found.png)
The installation proceeds fine from that point, but the Flex project isn’t available in Eclipse. As it turns out, you need to copy some files by hand:
cd ~/Adobe_Flex_Builder_Linux/
cd com.adobe.flexbuilder.update.site
sudo cp features/* /usr/share/eclipse/features/
sudo cp plugins/* /usr/share/eclipse/plugins/
And that’s all there is to it – you’ll have access to the Flex Projects in Eclipse. I’ll update this post if I find any problems with this method of patching the installation
Update: 13-Apr-2008
The above works great for *creating* a flex application, but it will not compile. There is an error generated that says:
Flex 0.0 (1): Flex SDK location "/home/.../configuration/org.eclipse.osgi/bundles/159/1/.cp/devsdks/moxie" does not exist.
I struggled and struggled to find the elusive “moxie” plugin. Alas, It was not found on my computer, or in any of the jar files. It turns out you need to download the “Adobe Flex SDK” from the “Stable Builds” section of (Adobe Wiki link):
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
- Download the file
- unzip it into a directory
- In Eclipse, Window->Preferences->Flex->Installed Flex SDKs->Add the directory you just created
- Delete the other installed SDKs for moxie (Flex 0.0)
- Enjoy!
I hope this helps someone
If you want to test to see if your installation works, add the following between the mx:Application tags in a Flex project
<mx:Canvas width="100%" height="100%">
<mx:Label text="Hello World"/>
</mx:Canvas>
I’m a software developer, both professionally, and as a hobby. So, at any one time, I’ve got at least two laptops on my person, and at least one runs Linux. Those that don’t run Linux had the OS pre-installed by the client that insists that I use only their hardware. Whatever.
When I decided to buy a laptop for personal use, I had a few years of experience to pull from. I’ve run Linux on laptops from most of the major vendors:
- Dell (Several models)
- Toshiba
- E-Machines
- Gateway
- IBM
All with limited success, especially with early versions of Linux. I started Linux on Slackware, then switched to Redhat, and more recently to Fedora. All of my laptop experiences have been with Redhat derivative distributions of Linux.
A good friend of mine is an IBM Territory Partner Manager, and he offered me his IBM discount. That, coupled with IBM’s stellar support of Linux, sealed the deal – I’m getting an IBM.
My criteria were:
- Modestly powerful
- Epic Battery Life
- Somewhat svelte
- Rugged
All of which were more than satisfied by the IBM lineup. After seeing a z60t, I decieded that would be the machine for me. The hardware specs are (shamelesly pulled from ThinkWiki.org):
My Configuration
(~$1300)
- Intel Pentium M (Dothan) 1.73, 1.86 or 2.0GHz
- Intel Graphics Media Accelerator 900 video controller
- 14.0″ wide-screen TFT display with 1280×768 resolution
- 1GB PC2-4200
- 40GB 5400RPM SATA HDD
- AD1981HD HD Audio 1.0 controller
- Intel_82801FB_HDA Intel High Definition Audio Controller
- UltraBay Slim with DVD±RW (dual layer)
- Broadcom 10/100/1000 Ethernet
- CDC slot (1) with a ThinkPad 56K Modem (MDC-1.5)
- ThinkPad 11a/b/g Wireless LAN Mini Express Adapter
- IBM Embedded Security Subsystem 2.0
- Integrated Fingerprint Reader on select systems
- UltraNav
- IEEE1394 (Firewire) on select systems
- CardBus slot (Type 2)
- SD Card Slot
Weight and Dimensions
- Weight: 2.2432 kg
- Travel weight: 2.053 kg
- Height: 26.6 mm
- Width: 334 mm
- Depth: 228 mm
So, once I finally took delivery of this laptop, I immediately dd‘d the Windows partition (just in case), and put Fedora Core 5 on it. Now, everything on the laptop did not work “out-of-the-box”, but, after a little configuration, a few downloads, and a kernel update or two, it’s all working! No ndiswrapper needed, sound works, USB, firewire, screen, monitor output, DVD, SD Card slot (whoopee!), fingerprint reader, hibernate / suspend, etc.
The best site on the web for IBM+Linux foo is ThinkWiki.org. Those guys have all the part numbers, links to all the drivers, postings from folks with similar hardware – everything for the new IBM owner. Many thanks to a well-run community site!
What I like about this machine:
- Small
- It’s a widescreen model, so the keyboard is plenty large, but the machine is thin and light. It’s exactly what I wanted as far as size and weight goes
- Touchpad
- Lots of IBM machines have shipped without a touchpad, but, I can’t function without it. Works like a charm.
- Atheros Wireless
- All the other laptops I’ve loaded Linux on have had Broadcom chipsets. The Atheros chipset based wireless was a big selling point for me. I’m using the madwifi-ng drivers, and I’m pretty sure I needed that to get WPA support working with NetworkManager. I’m using the Subversion build, and have been for a while. I’ve never had one bit of trouble out of the tip of the Subversion trunk
- Battery
- I got the extended battery, even though it added a little weight. I’ve never been disappointed.
- Suspend
- How did we ever live without Suspend? I’ve only used Hibernate (to disk) a few times, but it works too.
- Keyboard
- The most important part of a laptop (in my world) is the keyboard, and this one rocks. My hands are large, and I don’t feel cramped at all. Everything is there, and in the correct place. I really notice it when I use any other brand of laptop.
What’s not-so-hot about this machine
- CPU
- It seems I bought this machine just days before all respectable machines went dual-core. I’ll admit I had a bit of CPU-Envy towards a couple of guys that got a t60 a month after I bought mine. After a good bit of soul-searching, I’ve realized that my machine stays clocked down at 800mhz most of the time. I don’t write C++ or Java on this machine (Ruby and Perl, mostly), so I don’t have long compile cycles to worry about. Bottom line – It’s just what I need
- Screen resolution
- I’m an XEmacs user, so I can slice and dice the screen as I see fit. Also, I’m a virtual desktop power user, so I’ve got lots of real-estate for full-screen apps. If I used Eclipse, or just about any IDE, this screen would be too low-res. Again, just what I need, probably not for everyone.
- Windows Key
- This IBM has a Windows key – go figure. I don’t use it, but I think that it works.
So, this machine, warts and all, is my personal coding machine. I only have to reboot when there’s a new kernel, I authenticate with the fingerprint reader (one finger is me, one finger is root), and generally love every minute of coding on it. I keep trying to convince my wife she needs one, but she’s wedded to the Microsoft Natural keyboard, for some reason.
dhw
Subversion rocks! I’ve been a fan of Subversion for the past 4 years or so. Recently, I needed to give Subversion access to a small team, and my constraints were:
- Available to the users over the Internet
- *Not* hosted over my DSL/Cable
- Using Apache 1.3
- Secure
- SSL not available
Given these constraints, I couldn’t have a traditional Apache 2.0+https installation of Subversion, rather I needed svnserve. Since I didn’t want to host it at home (my home machines frequently donate vital organs to science), I decided to host it on a virtual server. I’d previously discounted svnserve as a minor footnote, not something that was useful or interesting. Without Apache 2.0 and a dedicated server this imposed a couple more constraints:
- Only one user account
- No access to arbitrary ports for
svnserve to listen on
From the Subversion Book, svnserve is:
A lightweight serve(sic) process which can run either as a persistent daemon, or as something automatically launched by inetd when necessary. Clients authenticate via CRAM-MD5 algorithm and speak a custom network protocol.
That’s all fine, but a little further down in the Subversion Book, we find svnserve over SSH, which fits the bill nicely.
The basic premise of svnserve over SSH, is that the client connects via SSH to a host, which spawns an svnserve process to serve the repository data. The Subversion designers built in a bit of *nix synergy here, so that svnserve could handle the repository, and ignore the authentication and encryption, via the -t option (tunnel mode). Tunnel mode assumes that the svnserve process communicates over STDIN/STDOUT with the client.
General Requirements
- Subversion command line client
- Although this will work with TortoiseSVN, I use the command line client.
- *nix server
- My virtual host is Linux, but this should work on just about any *nix host. On Windows, your mileage may vary
- SSH Access to your virtual host
- If your virtual host doesn’t allow SSH, then this will not work
Server SSH Configuration
First of all, your server needs to have Subversion installed. Whether it’s installed by your hosting service, or you install it right to your user account, it really doesn’t matter. Installation to a user account is a little tricky, since you may need to compile Subversion (lots of binaries exist, though).
All that’s really required is editing your .ssh/authorized_keys2 (on Linux) Here’s the line I added to mine:
(Line breaks added for readability) From “Controlling the invoked command” in the Subversion Book
command="svnserve -r /home/jkeyfrom/repo -t --tunnel-user=dwilkins",
no-port-forwarding,
no-agent-forwarding,
no-X11-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2EA<snip....snip>DGLSKTFLPzUA9J8xJr1p/w== dwilkins@z60t
This command instructs ssh to run the svnserve command when the specified key is encountered. The Subversion Book suggests the additional ssh options to limit the rights of your Subversion users. If you’ve got users that will be using both shell access and Subversion access, they’ll need two public/private key pairs, one for shell, and one for Subversion.
The options to the svnserve command are:
-r <repository path>-t (instructs svnserve to tunnel)--tunnel-user <subversion user>
The <Subversion User> doesn’t have to bear any resemblance to your virtual host user.
Subversion Client Configuration
Your Subversion configuration is in ~/.subversion/config. This file is a pretty standard INI-style file, and in there, you’ll find a [tunnels] section. In the [tunnels] section, add / edit the ssh = line to read something like:
ssh = $SVN_SSH ssh -l jkeyfrom -i /home/dwilkins/.ssh/identity.svn
The options to the ssh command are:
-l <username> (this is the username of your virtual host account)-i <location of your ssh private key for Subversion>
And that’s all there is to it! You can get Subversion SSH keys from each of your team members, and put them in the ~/.ssh/authorized_keys2 file, and they’ll have secure access to your archive, with full accountability of checkins.
Your urls will be of the form:
svn+ssh://example.com/directory
Again, I’m a big fan of Subversion, and I’ll probably be blogging more about it later. All of the information in this article came from the Subversion Book – a must-read for Subversion administrators. Subversion users can generally skip it, and just follow their noses in their Subversion client.
dhw
|
|