Is it just me, or do the distributed filesystems available even today just plain suck?

I've used NFSv3 and Samba Shares to share filesystems, and various Version Control packages like CVS, Subversion, and now Git... but I still haven't come across anything that is my DREAM SHARED FILESYSTEM.

Requirements of My Ideal Distributed File System

• Files must be available and Read/Write on the Local System's media.
• On File Write (file save), all changes from the Local System must be immediately Replicated to all "mirrors" of the Distributed File System
• all incoming changes received from a Remote System must "lock" the changed file while the updates are pending. 
• Applications that have "changed files" open must be able to notice the underlying file change (check the timestamp), and notify the user as appropriate.

OK, I know, most of those requirements are screaming "Use a Version Control System!", but here's where I digress from that chain of thought.

First, I don't really want to track individual changes in this Distributed File System -- all the change control and replication should be transparent.  I should be able to use a real Version Control package like Subversion or Git alongside this Distributed File System if I want to track the changes.  This makes the most sense to me, as most of my file-write changes are under 10 lines long.  (I do mostly prototyping and R&D work, so small and frequent changes is the normal workflow for me.)

Second, I want multiple "Filesystem Mirrors" of different flavors.  They could be networked filesystems like NFS or Samba; Read/Write mirrors via rsync or scp; ReadOnly mirrors via ftp; or full mirrors on an Encrypted Filesystem on a USB Memory Stick, mounted elsewhere on the Local System.  This "Memory Stick" option is particularly important to me, as I'd like the option (and comfort) of carrying a secure, physical backup of my work home at the end of the day. 

Wouldn't it be great to pop that stick into my Home Desktop, continue working on the project after hours, and return to work the next morning?  Just pop that stick into the Office Computer, and let this Distributed File System solution discover the changes and propagage the changes to all other Mirrors.  Basically, that memory stick becomes a disconnected "Briefcase on Steroids".  No network necessary.  Which is equally ideal if you plan to do some work in an airplane or something. 

These Ideals Scream of a Fuse FileSystem Based Solution

Yes, it certainly does -- there's no way something like this would work out in Kernel Space without some serious help and regression-testing.  Thus, I'm starting to design the architecture for the Local FileSystem portions, and once I have all the file-write hooks working right, I'll start to design the Remote Receiver portions.  The Remote Receivers might be small comet listeners that receive update notifications and implement the changes on specific filesystem solutions (NFS/Samba;rsync/scp;ftp;Encrypted Stick, etc..)...

Grumble Grumble Grumble

I'm gonna have to do some more research on this, to see if there isn't already something out there that I could cobble together.  This just screams "obvious" to me, but I just don't see anything out there at the moment.  Tips, hints, or pointers, anyone?  Am I reinventing File System Clustering or something along those lines?

OK, so it seems the Matz Ruby Team has borked the Ruby Interpreter.  Again.  This blunder has trickled down to most mainstream Linux distributions, and started affecting Fedora 9 as of June 25 (ruby-1.8.6.230).

What's the Problem?
The original problem is a security issue discovered by someone at Apple.  Zed Shaw has a great in-depth analysis of what the underlying problems are, if you're interested in the gory details. 

In a nutshell, someone found a bug, made a quick patch, and broke pretty much everything else.  On my Fedora 9 development box, ruby-1.8.6.230 causes segfaults when I run Rails and try to hit the first page.  That's not good.

The Quick Fix (Fedora 9)
Obviously, you don't want a vulnerable machine floating out on the Internet, but you still need to get things done, too!  The quick-fix is to revert to ruby-1.8.6.114 that was distributed earlier with Fedora 9, and hope for a more recent version of ruby in the near future that doesn't have this problem.

Grab the following RPMs (substitute for 32-bit architecture if necessary):

• http://mirrors.kernel.org/fedora/releases/9/Everything/x86_64/os/Packages/ruby-1.8.6.114-1.fc9.x86_64.rpm
• http://mirrors.kernel.org/fedora/releases/9/Everything/x86_64/os/Packages/ruby-devel-1.8.6.114-1.fc9.x86_64.rpm
• http://mirrors.kernel.org/fedora/releases/9/Everything/x86_64/os/Packages/ruby-libs-1.8.6.114-1.fc9.x86_64.rpm
• http://mirrors.kernel.org/fedora/releases/9/Everything/x86_64/os/Packages/ruby-irb-1.8.6.114-1.fc9.x86_64.rpm
• http://mirrors.kernel.org/fedora/releases/9/Everything/x86_64/os/Packages/ruby-rdoc-1.8.6.114-1.fc9.x86_64.rpm

 Then REINSTALL Ruby (execute these commands from the directory where you downloaded the above RPMs):

yum remove ruby ruby-devel ruby-libs rubygem-rails rubygem-mongrel

yum install ruby-1.8.6.114-1.fc9.x86_64.rpm \ 
      ruby-devel-1.8.6.114-1.fc9.x86_64.rpm \ 
      ruby-irb-1.8.6.114-1.fc9.x86_64.rpm \ 
      ruby-libs-1.8.6.114-1.fc9.x86_64.rpm \ 
      ruby-rdoc-1.8.6.114-1.fc9.x86_64.rpm \ 
      rubygem-rails rubygem-mongrel

If all went well, you will have Ruby 1.8.6.114 installed, and you can work as before.  If you're paranoid, you could add the above Ruby RPMs to the Yum Exclude list, but I'm pretty sure this is a temporary hiccup that'll be solved in another week or so.  We just need to let the upstream Ruby guys figure out a better solution that doesn't break everything.

The Hard Fix (Fedora 9)
A more viable alternative I'm experimenting with is using a different Ruby Interpreter.  Rubinius, or JRuby come to mind.  I'm looking into it, and will blog about it if I come up with a solid solution.

 Standard Disclaimer

These instructions are a work-in-progress, and not all issues have been fully worked out yet.  If you spot an error or have a quick fix, please comment below and help make this HOWTO more useful.  Thanks!

Please don't attempt this procedure unless you're comfortable with mucking around with your machine's configuration files.  If you're really that inexperienced, you should wait until someone publishes a proper RPM to auto-install and configure these things for you.  Thanks!

Install RPM Packages You May Need

yum groupinstall "Development Tools" "X Software Development"
yum install xorg-x11-server-devel

Download the Source Code (WizardPen 0.6.0.2 or Later)

http://specificcrap.arbitrarycrap.com/wizardpen-0.6.0.2.tar.gz
(If unavailable, scan this forum thread backwards to see if a more recent version was posted by "Miriad", and download that version if so.)

Unpack the Source Code

tar -xvzpf wizardpen*tar.gz
cd wizardpen-0.6.0.2

Compiling and Installing (64-Bit Systems)

./configure --with-xorg-modules-dir=/usr/lib64/xorg/modules/input/
make
strip src/.libs/wizardpen_drv.so
cp src/.libs/wizardpen_drv.so /usr/lib64/xorg/modules/input

Compiling and Installing (32-Bit Systems)

./configure --with-xorg-modules-dir=/usr/lib/xorg/modules/input/
make
strip src/.libs/wizardpen_drv.so
cp src/.libs/wizardpen_drv.so /usr/lib/xorg/modules/input

Disabling "evdev" handling of Keyboard and Mouse

*NOTE:  This is necessary because evdev "steals" events away from the wizardpen driver. 
I simply add ".BAD" to the end of the filename so it won't be processed; remove the ".BAD" extension if you need to undo this change.

mv /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi.BAD

Modifying Xorg.conf (Part 1)

*NOTE:  This is wonky, but necessary because both the wizardpad driver and the kernel's usbhid driver will be posting Mouse Events.  Without this fix, you will receive twice the number of mouse events -- which is harmless for X/Y coordinates, but devastating for Button Clicks.  (i.e. a Single Click will register as a Double Click). 

We will do things "the hard way" by telling Xorg about each and every mouse device currently installed.  (Excluding your Genius MousePen Tablet, which we'll configure below).  The first section must be named "Configured Mouse", otherwise, Xorg will silently auto-create a "Configured Mouse" section on startup.

The whole point of this procedure is to prevent Xorg from using /dev/input/mice so we don't have the "Double Mouse Event" problem.  OK, so let's make a backup of our Xorg configuration file, and then edit it with nano:

cp /etc/X11/xorg.conf /etc/X11/xorg.conf.BAK   # Always make a backup just in case!
nano /etc/X11/xorg.conf

Now, add a line to the ServerLayout Section:

InputDevice    "Configured Mouse" "CorePointer"

Then, add an InputDevice Section to configure the Configured Mouse Device:

Section "InputDevice"
       Identifier     "Configured Mouse"
       Driver         "mouse"
       Option         "CorePointer"
#      Option         "Device" "/dev/input/mice"
       Option         "Device" "/dev/input/mouse0"
       Option         "Protocol" "ImPS/2"
EndSection

Depending on your hardware, you may need to change "mouse0" above to a different number (mouse1, mouse2, etc..).  do an ls /dev/input/mouse* to see how many mouse devices you need to work with.

Repeat for other Mouse devices, if necessary.  If you prefer to view these changes in Diff/Patch Form, here's what my configuration looks like (Note the location of "mouse2" versus "mouse0" devices for my hardware):

--- xorg.conf.BAK       2008-06-16 15:45:02.000000000 -1000
+++ xorg.conf.part1     2008-06-19 04:52:54.000000000 -1000
@@ -4,6 +4,8 @@
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
+       InputDevice    "Configured Mouse" "CorePointer"
+       InputDevice    "Synaptics Touchpad"
 EndSection
 
 Section "InputDevice"
@@ -29,3 +31,19 @@
        EndSubSection
 EndSection
 
+Section "InputDevice"
+       Identifier     "Configured Mouse"
+       Driver         "mouse"
+       Option         "CorePointer"
+#      Option         "Device" "/dev/input/mice"
+       Option         "Device" "/dev/input/mouse2"
+       Option         "Protocol" "ImPS/2"
+EndSection
+
+Section "InputDevice"
+        Identifier      "Synaptics Touchpad"
+        Driver          "synaptics"
+        Option          "Device"        "/dev/input/mouse0"
+        Option          "Protocol"      "auto-dev"
+        Option          "HorizScrollDelta"      "0"
+EndSection

Before moving on to Part 2, you should test configuration to make sure your mouse devices are operating as you expect.  Simply log out of Fedora's Desktop to restart your Xorg server, and log in again.  If your mouse isn't functional, you can pop into a Virtual Console (CTRL-ALT-F1) to log in as root and use nano to make any changes to /etc/X11/xorg.conf.  Then do a CTRL-ALT-F7 to pop back into Fedora Desktop, and do a CTRL-ALT-BACKSPACE to hard-reset Xorg.

Modifying Xorg.conf (Part 2)

Now, add a line to the ServerLayout Section:

InputDevice   "Tablet0"   "SendCoreEvents"

Then, add an InputDevice Section to configure the Tablet0 Device:

Section "InputDevice"
       Identifier  "Tablet0"
       Option "Name" "UC-LOGIC Tablet WP8060U"
       Driver          "wizardpen"
       Option          "TopX"          "10"
       Option          "TopY"          "10"
       Option          "TopZ"          "10"
       Option          "BottomX"      "32747"
       Option          "BottomY"      "32762"
       Option          "BottomZ"      "1023"
EndSection

Or if you prefer to view these changes in Diff/Patch Form:

--- xorg.conf.BAK       2008-06-16 15:45:02.000000000 -1000
+++ xorg.conf   2008-06-19 02:05:49.000000000 -1000
@@ -4,6 +4,7 @@
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
+       InputDevice    "Tablet0"   "SendCoreEvents"
 EndSection
 
 Section "InputDevice"
@@ -29,3 +30,14 @@
        EndSubSection
 EndSection
 
+Section "InputDevice"
+       Identifier  "Tablet0"
+       Option "Name" "UC-LOGIC Tablet WP8060U"
+       Driver          "wizardpen"
+       Option          "TopX"          "10"
+       Option          "TopY"          "10"
+       Option          "TopZ"          "10"
+       Option          "BottomX"      "32747"
+       Option          "BottomY"      "32762"
+       Option          "BottomZ"      "1023"
+EndSection

If you are using a different device (Not a MousePen 8x6, but something that uses the wizardpen driver), you must change the Option "Name" line above to exactly match your device's name.  Do a cat /proc/bus/usb/devices and deduce which entry corresponds to your device, and make the necessary changes.  For reference, here's what the MousePen 8x6 entry looks like:

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=5543 ProdID=0005 Rev= 0.00
S:  Manufacturer=UC-LOGIC
S:  Product=Tablet WP8060U
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

Restart X, Cross Those Fingers
Log out of your Fedora Session, which should restart the X Server.  If all went well, you should still have your original mouse functionality.  At this writing (using the 0.6.0.2 driver), the MousePen Tablet will only work when you use the pen -- the "mouse" sends a different set of events, and the driver author hasn't yet added support to handle BOTH sets of events concurrently.  He's reportedly working on it, so expect it Real Soon Now. 

If you have serious problems with getting X started, you may need to revert your xorg.conf changes.  If so, press CTRL-ALT-F1 to get into a Virtual Console, log in as root, and restore your xorg.conf backup:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.BORKED
cp /etc/X11/xorg.conf.BAK /etc/X11/xorg.conf
 

You can then do a CTRL-ALT-F7 to try to get back into the Graphical Desktop.  If the Desktop is still a bit stubborn, you might need to do a CTRL-ALT-BACKSPACE, do an "init 3 ; init 5", or simply restart your machine. 

At this point, you should probably test your Touchpad's Button Clicks to make sure everything is working properly.  Go to System > Preferences > Hardware > Mouse, and test the Double-Click speed applet.  You should get a "Half Illuminated" image on a single click, and a "Fully Illuminated" image on a double click.  If you're always getting the "Fully Illuminated" image when you click with the MousePen Tablet, chances are good that Xorg is still using /dev/input/mice -- you may need to doublecheck your work, or dig deeper in /var/log/Xorg.0.log and dmesg to weed out the problem.

Other than that, enjoy!  This took me several days of research, and I hope this article has saved you from the aggravation I endured trying to get this all working!

Gimp and Pressure-Sensitivity
Pressure-Sensitivity works in 0.6.0.2, by the way.  Gimp needs to be configured to recognize Pressure Sensitivity, though.  (File>Preferences>Input Devices>Extended Input Devices, select "Tablet0" in the drop-down, select "Screen" in the Mode drop-down, and ensure Pressure is set to Axis 3.  Apply and enjoy.

Credit Where Credit Is Due

This article could not have been written without referring to these older resources:

http://www.stud.fit.vutbr.cz/~xhorak28/unb/forum.php?req=thread&id=71 - User "Miriad" is the lead developer of the "0.6.x" Driver, based on the acecad driver.

About the Author
Laurence A. Lee is a Fedora Ambassador representing Honolulu, Hawaii.  He is a Microsoft Certified Enterprise Applications Developer, and currently develops software in Ruby on Rails and other popular platforms.  (Full Profile)

I noticed the BULLSHIT posted on the front page of  HonoluluTransit.org and the GoRailGo.org Rail Propaganda Websites, and decided to offer a rebuttal to these false claims.  Thank goodness the people at StopRailNow.com are suing the City into providing TRUTHFUL information to the public.  Until that happens, it's up to us Conscientious, Educated Citizens to spread the truth about Rail.

What's Good about Rail? 

Good for MOBILITY
One train can move 300 people which equals 6 buses or 300 cars!  That means one rail line equals 6 lanes of cars.

Oh really?  This is an over-inflated claim.

If one train can move 300 people, and we can push a maximum of 20 trains per hour (one every 3 minutes), that means one rail line can only transport a maximum of 6000 people per hour.  One lane of Freeway Traffic is estimated to move over 2000 vehicles per hour (33 vehicles per minute, or about 1 vehicle every 2 seconds).

At 60 MPH, vehicles cover 88 feet per second (60 Miles Per hour = 1 Mile Per minute; 1 Mile = 5280 Feet, so 5280 Feet per minute = 88 feet per second).  A common factor is 1.467*Speed in Miles Per Hour; so at 50MPH, vehicles cover 73.35 feet per second.

To sustain 1500 Vehicles per Hour at 60 MPH (1 vehicle every 2.4 seconds), vehicles must be no more than 211 feet apart (2.4 seconds * 88 feet per second); with average mid-sized vehicles like the Toyota Camry having a length of about 15 feet long, that leaves 196 feet (about 13 car lengths) between a vehicle and the one in front of it.

To sustain 2000 Vehicles per Hour at 60 MPH (1 vehicle every 1.8 seconds), vehicles must be no more than 159 feet apart (1.8 seconds * 88 feet per second); or about 9.5 car lengths between a vehicle and the one in front of it.

As you'll notice, both the 1500 and 2000 vehicles per hour rates are within the two common "Safe Driving" rules of thumb:  1 Car Length per 10 miles per hour; or the "2-second distance rule".

If we also factor in a higher number of Express-Buses and High-Occupancy Vehicles travelling those same freeway lanes, we can yield a Net Average of 2, or possibly 3 People per Vehicle in those lanes:

( (50 Occupants x # of Buses) + (5 Occupants x # of High Occupancy Vehicles) + (1 Occupant x # of Single Occupant Vehicles) )

divide that by the Total Number of Vehicles to yield the Average Occupancy Factor.

Thus, 1500 or 2000 vehicles can transport 3000-4000 people with an Occupancy Factor of 2; or 4500-6000 people with an Occupancy Factor of 3.

Thus, the maximum yield of one rail line REALLY translates to the maximum yield one or two lanes of cars, not six.

More traffic-congestion formulas can be found at  http://www.krellinst.org/AiS/textbook/unit2/flow_solution.html

Good for the ENVIRONMENT
It's sustainable - rail can be powered by alternative energy like solar, wind or H-power.  This means less air and water pollution and fewer green house gas emissions.

In the near future, vehicles can ALSO be powered by solar, wind, or H-power.  We are already seeing Hybrid vehicles and Plug-In-Electric vehicles coming to market.  Thus, vehicles will also produce less pollution and fewer green house gas emissions.

For both Rail and Plug-In Vehicle Hybrid options, Honolulu should be asking:  How will this affect Hawaiian Electric Company, and do we need to make plans for additional Power Plants to provide power for this extra Electricity Consumption?

Good for the ECONOMY
The rail project will create 90,000 person years of employement or 11,000 direct and indirect jobs annually.  And, building a reliable, dependable, efficient transportation system encourages healthy economic growth. 

 At a time when the economy is in a RECESSION, and the buying power of our Almighty Dollar is at an all-time-low, building ANY MASS TRANSIT solution is not good for the overall economy.  At best, it will only benefit the CONTRACTORS who are working on building the Mass Transit Solution.

$3.7 Billion worth of Euros, Yen, or Hong Kong Dollars TODAY will be worth MUCH LESS when we actually get around to BUYING those Rail Train Cars from Japan.  Where will Honolulu come up with the projected shortfall caused by inflation?

Good for COMMUNITIES
Rail encourages managed, orderly growth along the route.  Planning where and how communities expand means we can keep the country country.

Rail will also provide opportunities for CRIMINALS to more easily move between communities.  For years, Honolulu Police had difficulty in controlling the drug, prostitution, and criminal activities of CHINATOWN (which is in the middle of Downtown!).  How do you think HPD will do when the drug dealers are hanging around at Rail Stations?

How do you think HPD will do when the GANG ACTIVITY increases along the Rail Line?  Two possible but disturbing outcomes:  Rival gangs routinely coming in via Rail to settle their differences in once quiet neighborhoods;  or larger, more organized, and more DANGEROUS gangs become UNITED along the Rail Stations.

Who will protect the elderly, or the school children whose schools are along the proposed route?

Good for YOU
The less time you spend in traffic means the more time you have for yourself and your family and that means a better quality of life for everyone.

 Nothing, absolutely NOTHING about Rail will reduce your commute times.  Not in the City's Alternatives Analysis done in 2006, or in the UHCA's Analysis done in 2008.  To skirt this glaring omission, proponents of the "Fixed Rail" alternative for "Mass Transit" have changed their Sales Pitch to "provide a transportation alternative".

I find it hard to believe that the 20-Mile Plan DOESN'T EVEN INCLUDE UH MANOA -- which is arguably the BIGGEST contributor of Freeway Traffic when school is in session.  When UH is out for the Summer, Spring, or Winter breaks, we all notice how easy it is to get to work in the morning.

I also find it hard to believe that the 20-Mile Plan DOESN'T INCLUDE the obvious traffic sites like EWA BEACH.  Travelling along Fort Weaver Road is a painful experience, and it keeps getting worse because of all the development going on in the area.

I also find it ridiculous that City Councilman Romy Cachola opted to route Mass Transit through Salt Lake Boulevard, instead of adopting the original plan of going through the Airport.  According to his OpEd in the Star Bulletin, Romy made the decision based on the input of a mere 122 people.  Romy affected 70,000 to 80,000 residents because of 122 PEOPLE ?!?!  That's an irresponsible decision, or ridiculously juiced.

You will notice in Romy's OpEd, he talks about Transit Oriented Development opportunities in Stadium Mall, and along Salt Lake Boulevard.  With the Mass Transit Plan as it is today, we are building across Salt Lake Boulevard to yield ONLY ONE RAIL STOP, and it's at the corner of Ala Lilikoi and Salt Lake Boulevard (See Page 2 of the March 23 News Conference's Materials for the map of all Rail Stops). 

Ala Lilikoi and Salt Lake Boulevard is a TRAGIC LOCATION, because we have an Intermediate School, a Public Library, and an Elementary School in the immediate vicinity of that stop.

And don't forget about Radford High School, whose students will be subject to the noise of 20 Trains Per Hour during Mass Transit's peak operation.

Furthermore, if Mass Transit is going along Salt Lake Boulevard, how will the Mass Transit route get across the H1 Bridge next to Stadium Mall?  Under the bridge?  Over the bridge?

 In Closing
I'm not saying "Don't Build Mass Transit".  I know we need a solution for the people in Ewa Beach and Mililani who are suffering in rush hour traffic every day.

But to be brutally honest, Mayor Mufi Hannemann is rushing into a Mass Transit Project without a solid plan, and I have a problem with that.  Under the current plan, we're committing $2,800,000,000 of Honolulu Tax Dollars to chase after a mere $900,000,000 in Federal Funding (and that's an OPTIMISTIC MAXIMUM).

For Honolulu to be spending that kind of money, and embarking on the largest Public Works Project in Honolulu's History, I'd rather start out with a SOLID PLAN that we all agree on.  With numbers and facts being wildly spun by proponents and advocates, I think "breaking ground" in 2009 is going to be a costlier mistake than abstaining for another year or two.

Speaking as a seasoned Software Engineer, it's always been my experience that Projects started with POOR Design and Planning end up costing WAY, WAY MORE than the original estimates, due to Change Requests and Scope Creep.  Just look at Honolulu's JIMS Project, where we recently wasted $12 MILLION.

Poor Planning leads to COSTLY OVERRUNS.  It doesn't matter if it's the Software Industry, or the Construction Industry.

We are scrambling over $900,000,000 in Federal Funding.
Think about this: We collected $211,000,000 -- about 1/4 of what we hope to receive in Federal Funds -- in the first 16 months of the Excise Tax increase.

It will cost Honolulu WAY MORE than $900,000,000 if we jump into a Mass Transit Project, and discover we need to make changes along the way.