“The final ISO ballot on C++0x closed on Wednesday, and we just received the results: Unanimous approval.”
Yay! Now we just need a stable GCC with official support then.
“The final ISO ballot on C++0x closed on Wednesday, and we just received the results: Unanimous approval.”
Yay! Now we just need a stable GCC with official support then.
After extending its time to register for the pre listing share issuing. Excito now cancels its IPO, referring to the turbulent market as the reason for failing to attract capital.
To solve its immediate cash requirements Excito is working on a Private Placement i.e. raising the money from it’s current owners and new, “private”, investors.
Excito plans to retry the IPO “when the market stabilizes”.
My home office these days. Nice view but no AC thus a bit hot now in the summer 🙂
I of course use a Bubba to store all my precious data which in turn is backed up off-site using rdiff-backup. Rdiff-backup gives me the best of two worlds synchronization, giving me direct access to the files in the remote backup, and incremental backup, giving me the history of my files as well. But this is material for a completely separate article.
But for some reason I’m not completely comfortable with mounting the Bubba share on my Linux desktop computer for more write intensive operation such as my home folder. This most likely due to me starting with the B1 & B2 which hadn’t that computing power of the B3. I nfs mount the complete storage share at the same desktop computer to give me instant access to my media files and other stuff.
All this is perfect but I almost always end up with a non backed up Documents folder containing a lot of important documents that I then tried to manually synchronize with my storage Bubba. Needless to say this is a recipe for failure.
Thus one day i stumbled upon lsyncd. This is a daemon that watches local directories for changes, waits for a predefined time for possibly further changes, and then synchronizes these changes to a remote location using one of many configurable methods.
I use this to launch when i log in to my Ubuntu Desktop and then monitor my Documents folder. When anything changes there it is automatically synchronized to my Bubba.
Lsyncd is available from Ubuntu repositories but at least the one for Ubuntu 10.10, which i run is outdated. Thus i opted to compile it my self. I downloaded the latest release from here: http://code.google.com/p/lsyncd/downloads/list
Untar the downloaded source to a temporary directory using either the file manager, nautilus, or the command line.
Then start a shell, if not already running, and change into the directory created when unpacking the archive.
Issue configure to set up the build environment:
Then build the application by running:
This should hopefully complete without any errors. If not its most likely due to missing dependencies such as fx build-essential, liblua5.1-0-dev.
To finish it of and install the application run
sudo make install
Which will install the application to /usr/local.
From the same shell create a folder to keep your local configuration
Create the configuration file $HOME/.lsyncd/lsyncd.lua with for example gedit (run gedit $HOME/.lsyncd/lsyncd.lua) And enter something like this:
To launch the lsync daemon I have modified a Debian SYSV initscript to check if there is a running instance of the daemon and if not start a new one.
It is available here. Download and copy it in to the $HOME/.lsyncd folder. Make sure it is executable by executing
chmod +x $HOME/.lsyncd/start_lsyncd.sh
Then to make the script run at login, in Ubuntu 10.10 at least. Select the menu System->Preferences->Startup Applications
Select Add, enter a name for the service and browse or enter the path to the start script. Click Add to complete the setup.
Now whenever you login to your desktop the lsyncd daemon will be started if not already running.
For all of the above to work you have to have a user account and shell access on the remote server. With that said the setup should work when you log in next time.
But to not have a password prompt pop up every time a file is changed in the Documents folder the best way is to generate and store a key on the server. Run
ssh-keygen -f $HOME/.ssh/lsyncd
Enter a secure password and confirm it by enter the same password.
Copy the key to the remote server
ssh-copy-id -i $HOME/.ssh/lsyncd.pub b3-server
Where b3-server is the hostname of the remote server.
If you then use this key to try access the remote server via ssh you should get a dialog something like this
Enter the password for the key and also select “Automatically unlock this keyring whenever I’m logged in” And click OK
Now hopefully everything should be in place.
Log out of your desktop and log in again. Create a new file in the Documents folder. Then verify that all files in the Documents folder on the remote server matches the one on your desktop. Also check that changes propagate correctly to the remote server.
If anything goes wrong start by checking that the daemon is actually running. (For example by running ps or check the System Monitor and the processes tab)
If the daemon is running check the log file /var/log/user.log for any clues on what goes wrong.
Apparently Excito has hired a new VP for sales and marketing, Thomas Jell formally from Netgear. Nice work! Who knows, maybe CEO material?
Aktietorget has the story (In Swedish). No news at excito.com yet.
So now it’s official, Excito is doing an IPO and will be listed at Aktietorget. There you can read the teaser and the memorandum (In swedish). First day of trading seems to be 25th of July.
The “new” name of the company is Excito Electronics AB
I started writing this when i ended my work at Excito, unfortunately it took a bit longer to complete than what i had anticipated 🙂 (Note to self, write shorter and more often)
So today was my last day working at Excito. A journey that started almost a decade ago came to an end. I intend to use this post to recap this journey, as experienced by me, over the years. So here we go.
The founders of Excito, Tor Krill (Me), PA Nilsson, Johannes Book and Magnus Lovén all worked at the same company, Blokks, at the turn of the millennium.
At Blokks we developed hardware and software for the digital infrastructure in your home. A fiber optic media converter to convert the incoming fiber broadband into regular ethernet.
A prioritised multimedia switch to make sure that streamed media and VOIP traffic would be delivered to their endpoints in a timely manner without delay.
And the crown jewel was our IP-TV player that played multicast streams from Framfab(?) delivered to our monster cisco machine distributing them to our local office in Lund.
(Thanks to Petter Duvander for the picture above)
The vision was that everybody should have fast symmetric broadband via fiber and use IP for all services. Triple play was the buzzword of the day.
Then two things happened. The dot com bubble bursted with a bang here in Sweden and all venture capital vanished in an instance. Number two was the broadband adoption. The Fiber to the home vision vaporised and instead the big phone companies started pumping out cheap ADSL. God what I hate that A as in Asymmetric. That A is what makes people stay passive consumers and keeps the distributing power in the hands of those with a lot of financial muscles. (This is a different story though.)
But Blokks ran out of venture capital at this time and went bankrupt in 2002. During the last weeks at Blooks we where mainly idling doing mostly nothing. During this the idea to start a new company using some of the ideas from Blokks. So we founded Excito, which we ran on our spare time, and shortly thereafter Blokks ceased operations and all four of us where scattered to other companies. (A side note here, the video player part of Blokks actually lived on in the form of the company Books(?) later bought by MultiQ and is now a key part of that company)
But never the less, Excito was born. Our initial idea was to provide cheap Arm development boards for companies and perhaps even for private use, who knew. I worked on the software stack, Magnus, PA & Johannes did the hardware and if my memory serves me right Magnus and Johannes did all technical writing etc.
We started developing the Eagle devkit, a Cirrus Logic ARM processor running at a stunning speed of 74MHz, 16MB of ram and one 10Mb ethernet port. Everything was controllable from a Linux host via serial cable and we provided a state of the art Linux 2.4 kernel and a root filesystem based on Busybox.
All this was a complete failure regarding sales. If we sold 20 kits in all I think I’m exaggerating. But never less we kept struggling and kept developing. We added a few add on boards during this, a simple I/O board with some buttons, an Audio addon capable of playing lower quality MP3s. But the main add on that really started it all was the mass storage add on board.
Highlighted in the picture above. It provided a CF-card slot and more interestingly a PATA IDE interface where users could attach a hard drive or a CD-ROM.
We tried to sell this for about a year or two with no greater success and things looked quite pale. Then one day it struck me, we had all the components to build a complete mini-server. I myself had an aging 400MHz P2 machine running in my kitchen doing user management via LDAP, file sharing via NFS and handling all my e-mail via fetchmail, postfix etc.
With this in mind we started developing “Bubba Server” in the autumn of 2004.
Since all of this was done on our spare time things progressed slowly. It took us almost a year to make the product ready for launch.
The Bubba server was quite limited on hardware. Equipped with an Atmel at91 Arm processor and originally only 64MB of Ram we had to carefully decide on which software to include and how to code our own functionality not to hit the limits of the hardware. One of these quirks where that, even though the CPU was capable of running in 200MHz we found out that we could squeeze more performance out of it when running it at 180MHz (Due to faster memory accesses at that speed)
Initially the B1 had a steel casing making it very heavy. We shipped them manually wrapped in a neutral “gift paper” much in the same way as a Christmas present. I guess our first customers must have lifted their eyebrows when opening the package. Later models had the steel plates exchanged for aluminum ones and the memory was doubled to 128MB and we quickly abandoned the gift wrapping due to it being a bit labor intensive.
Because all of this work where done on our spare time and money we also assembled and tested the units ourselfs. Up until late Johannes wife, Jenny, soldered the IDE connector on each unit. (Much love went in to the making of B1.)
During this time the B1 was the only NAS, that i knew about, that had any other features beyond pure network storage. B1 came with mail & print capabilities, a few streaming servers and a download manager. This and the bonus of being completely open, ssh and root password included, really made this creature different. Needless to say this made quite an impression in the, small, interested crowd. We got a lot of good publicity and sold quite a few B1s
With all this good publicity and good sales we started toying with the idea to actually try making this into our daytime jobs as well. So in the autumn of 2007 we started working on what would become Bubba|TWO.
And so after some hard work both on the product itself and a completely new web site we launched Bubba|TWO in the summer of 2008.
Equipped with a twice as fast processor and double up on ram and a four port sata controller made it quite a hardware upgrade from the B1. On the software side we did a complete makeover introducing a new look basing all of it on the CodeIgniter framework. The framework was actually suggested by one of our B1 users and the framework has since worked nicely all the way.
Initial sales where quite good and “unfortunately” we still did all end assembly our selfs 🙂
While the B1 server always where rock stable. The B2, initially, had some nasty stability issues mostly in the ethernet section. The B2 dropped connectivity, rebooted spontaneously and in some rare occasions dropped networks speed to a crawl. If we only had read the errata a bit more closely we might have chosen another processor. The errata weighed in at 167 pages and with some 80 problems known to the ethernet controller itself. I can tell you, we had some tough months stabilizing this after launch and the Excito forum is still full of evidence of customers who got bitten by this.
But gradually we got most things under control and in later production batches we got newer releases of this processor that solved most of these bugs. Over time the B2 actually got quite good.
Over the lifespan of B2 we renewed the user interface, using an art director, to do the look & feel which actually turned out very well. This is mostly the same look and feel still used to day.
The other part was adding the wireless functionality. If the decision of processor was one of the big technical hurdles the other was the decision regarding adding the wlan module. Everything seemed to work out nicely during initial testing. But when putting the configuration under harder pressure it showed some cracks. This was mainly due to the software stack not being ready for prime time. The Linux wireless stack was not stable enough to run in Access Point mode. At least not in combination with the Atheros chip we decided to use then.
This costed us hundreds of hours testing and analyzing the problems and at least as many hours hiring outside help to solve these issues. The big problem being Excito not having this expertise in house. The good thing with this is at least that we helped the Linux community somewhat redeeming this problem. And i think as of today it should be possible for “Joe Average” Linux hacker to deploy similar solutions by them selfs.
Overall the B2 was a great product, the only problem was its price/performance. Due to Excito having quite small economical means we always had to produce small volumes resulting in high end prices. That and the fact that B2 had severe performance issues compared to competitors in the same price segment, especially in the end of its product life, we started to think about the future.
Excito would, at the time, never being able to compete with the competition on a price factor. The only way to meet the competition would be on performance and being somewhat different than the rest of the pack.
We already where quite a different product compared to the other NASes out there. We had a completely open architecture flirting wildly with the technological crowd. We also had a completely different approach. While all other manufacturers, what i know of, produces products with user interfaces mainly designed to configure the unit. Excito focused primarily on how the user could use the unit in his/her daily life. The configuration was secondary. We lifted all the day to day usage to the first page and shovelled all the configuration hidden behind a small icon on the first page of the UI.
With this in mind we started to think of the next Bubba generation. We wanted more power out of the unit and we wanted to be able to add an, “easily”, configurable amount of ram.
With these requirements set we started designing the B3 based on the big brother CPU of the one we used on B2, Freescale’s 800MHz 8377. This had a 64 bit memory bus making it feasible equipping the unit with a SODIMM slot for easily upgrade of memory.
We did the complete design, built the first prototypes for smoke tests and initial startup. Then we got news from Freescale, 26 weeks + in delivery time for the processor. The photo was taken in spring 2010 more or less when we got the bad news.
With this delay in component delivery we would not have been able to start production of B3 until late October 2010. This would mean that we most likely would miss the so valuable autumn and Christmas sales.
What where one to do, we took a deep breath, kept as much as possible of the original B3 design and started over. This time we used the Marvell Sheeva core, used in almost all plug computers of that time. Marvell guaranteed us more reasonable delivery times.
On the software side we kept most of the code base from the B2 but rebased it all on top of Debian 6 aka Squeeze instead. Thus a lot of code initially written for the B1 actually still runs on the B3 some six years later.
In September 2010 we launched Excito B3 a whole month before we should have received the components to the original B3.
It has been a, mostly, fun journey over the last nine years. Our users never stopped to amaze me. Take a look at Excito Forum and you can find lots of cool ways people use their units.
But with all that said Excito and I somewhat grew apart. Being a true believer in Linux and Open Source I had a hard time getting along with the harsh reality of trying to become a mainstream consumer electronics company. Thus i came to the conclusion that it most likely was for the best if me and my baby went separate ways.
I really wish Excito the best of luck and i hope they will do amazing successful products. Both Johannes and Magnus still works at the company thus there should be a good chance of this happening.
And regarding my writings on Bubba, stay tuned. My digital life still is built mainly on Bubbas and thus I will most likely write more on this subject later and apart from that I hope I can provide some interesting reads otherwise as well in the future 😉
So fsckn right: “If You’re Not Paying for It; You’re the Product” The other form of free, I rather pay for it in cash thank you.
So my ADSL modem decided to take it’s last breath this weekend. After a brief conversation with my ISP support the modem was diagnosed to be no more. (They should send me a new modem replacing the old one. Hopefully this will arrive shortly)
So what should one do then. No Internet is certainly no option for me. I start to suffer from severe information shortage in a matter of hours. To remedy this my first thought was to connect my Android phone to my Laptop and thus at least get out on the net again. This works really great since the Android OS publish itself as an USB network device when plugged into a computer via USB. Unfortunately, since most of my Internet infrastructure is centered around a few Bubba units, nothing more than pure surfing worked when these units where offline.
Then it struck me, why not connect my phone to the B3 that currently is my router instead using the phones network to provide my home LAN with Internet connectivity, at least when I’m at home then 😀
Said and done this turned out to be a quite easy task. This is how I did it.
Start by connecting the USB cable between the phone and the USB port on B2/B3(Bubba).The phone then should show a selection box
Select “Internet sharing” and press “Ok”.
Log in to your Bubba via SSH and become root. Then save the current firewall rules into a temporary file:
iptables-save > original-rules.conf
This will contain the current setting with references to the eth0 ethernet WAN interface. We save these to be able to change the settings back.
cp original-rules.conf usb-rules.conf
Then we edit the usb-rules file and change all occurrences of eth0 to usb0
sed -i "s/eth0/usb0/g" usb-rules.conf
For convenience add the usb0 interface to the network configuration. Add the following line to the file /etc/network/interfaces
iface usb0 inet dhcp
Then pick down the current eth0 device if up and running.
If you like, unplug the wan cable as well. Then apply the USB firewall rules by issueing
iptables-restore < usb-rules.conf
Then finally pick up the USB network interface by running
If all goes well you should now be running the Android phone as the primary WAN interface on Bubba. And since we use this Bubba as a router all devices attached to the LAN interface or via Wlan should be able to use Internet via the phone transparently.
To restore functionality disconnect the phone and reattach the wan cable again. You might have to do an ifup/down on the eth0 interface as well.