Every time I see a device like this, I'm left licking my lips and pondering just how much small company infrastructure you could fit on one.
800Mhz/512mb RAM is more than plenty to provide Gmail-like full text search for 10-20 users, while $6/user/year ($199+$1 / 20) is much lower than the equivalent cost for Google Apps Enterprise.
All that's missing is a competitive free software stack to rival the likes of Gmail/Google Docs. With the right governance, a small team of developers might enable a huge, disparate network of devices like these, with centralized security updates, a sweet admin/user UI, and be functionally competitive with most paid "low hanging fruit" cloud services (storage, docs, mail, sharing, RSS reader, ...), while offering unique features of its own (e.g. meaningful PGP e-mail, before the message leaves the building, from a web browser).
I wish someone with the right leadership skills could attract talent to a project like this. Young developers these days seem content to reinvent web frameworks and bolster Google's coffers writing crappy Android hacks, compared to those of even a decade ago, who had multitudes of successful efforts attacking Microsoft's ecosystem on its home turf.
You should have a peek at what my former coworker William is doing with Heliotrope. Pretty nice email client that supports threading with incredibly fast searching. It's not exactly what you're looking for and it's still pretty raw, you have to be familiar with the command line, but it has a lot of potential. https://github.com/wmorgan/heliotrope
I think you're right about the stability, but that's a better question for William to answer. Wasn't aware of Sup, I've only seen him using Turnsole (https://github.com/wmorgan/turnsole) which apparently is derived from Sup.
Both Heliotrope and Turnsole are derived from his work on Sup, from what I can tell.
His Rethinking Sup[1][2] blog posts were, as far as I can tell, the initial thought work that led to the creation of HT & TS.
Personally, I read them at the time with great expectations, and was a bit let down since it seemed to result in a email-specific system, whereas Sup-the-service was described as a generalist document system (RSS, notes, even IRC).
I'd try to contribute, but frankly I don't really want to delve into yet another language (Ruby) for now..
My thoughts are towards an appliance-like experience with minimum setup involved, more like installing a NAS, which the average Joe can manage nowadays without dedicated admin.
Of course things will go wrong, and there'll always be a need for support, but you can mitigate a lot with just software, e.g. pairing of bricks for mirroring, growing capacity by adding pairs, and supporting this through wizard-like UIs.
As for complicated failures, should they occur, there's always outside help (for which an ecosystem of its own might appear if such a software stack was successful enough).
Same here; I would probably get one if I didn't already have a server to run at home.
I've been kicking around ideas for a fully distributed social network/communication/file storage system. It would only really work if everyone had their own always-on, publicly accessible server at home. I don't know if I have "the right leadership skills", but I'm definitely interested in making something like that happen.
2) Some people don't trust their private data to 'the cloud.'
Yet you'll put the data on the cloud via this appliance and just require a username & password to it?
In addition to pyre's reasons, part of the point is to let people control their hardware, and to have better physical control of their data before it leaves the premises, e.g. encrypting email, as forgotusername suggested.
Full text search needs little more than stack space to perform merges, but it runs much faster with a good chunk of RAM to cache the tips of posting lists. If you dropped an SSD into one of these, the requirement for RAM to achieve good performance might disappear altogether.
Comments
Every time I see a device like this, I'm left licking my lips and pondering just how much small company infrastructure you could fit on one.
800Mhz/512mb RAM is more than plenty to provide Gmail-like full text search for 10-20 users, while $6/user/year ($199+$1 / 20) is much lower than the equivalent cost for Google Apps Enterprise.
All that's missing is a competitive free software stack to rival the likes of Gmail/Google Docs. With the right governance, a small team of developers might enable a huge, disparate network of devices like these, with centralized security updates, a sweet admin/user UI, and be functionally competitive with most paid "low hanging fruit" cloud services (storage, docs, mail, sharing, RSS reader, ...), while offering unique features of its own (e.g. meaningful PGP e-mail, before the message leaves the building, from a web browser).
I wish someone with the right leadership skills could attract talent to a project like this. Young developers these days seem content to reinvent web frameworks and bolster Google's coffers writing crappy Android hacks, compared to those of even a decade ago, who had multitudes of successful efforts attacking Microsoft's ecosystem on its home turf.
You should have a peek at what my former coworker William is doing with Heliotrope. Pretty nice email client that supports threading with incredibly fast searching. It's not exactly what you're looking for and it's still pretty raw, you have to be familiar with the command line, but it has a lot of potential. https://github.com/wmorgan/heliotrope
I thought Heliotrope/turnsole weren't stable yet?
Personally, I've used his Sup client and it's excellent, searches are basically instantaneous.
I think you're right about the stability, but that's a better question for William to answer. Wasn't aware of Sup, I've only seen him using Turnsole (https://github.com/wmorgan/turnsole) which apparently is derived from Sup.
Both Heliotrope and Turnsole are derived from his work on Sup, from what I can tell.
His Rethinking Sup[1][2] blog posts were, as far as I can tell, the initial thought work that led to the creation of HT & TS.
Personally, I read them at the time with great expectations, and was a bit let down since it seemed to result in a email-specific system, whereas Sup-the-service was described as a generalist document system (RSS, notes, even IRC).
I'd try to contribute, but frankly I don't really want to delve into yet another language (Ruby) for now..
[1]: http://masanjin.net/blog/old25 [2]: http://masanjin.net/blog/old13
That seems like a poor allocation of engineering resources, because $200 + fully loaded costs of a sysadmin for an email server >>> $50 x users.
My thoughts are towards an appliance-like experience with minimum setup involved, more like installing a NAS, which the average Joe can manage nowadays without dedicated admin.
Of course things will go wrong, and there'll always be a need for support, but you can mitigate a lot with just software, e.g. pairing of bricks for mirroring, growing capacity by adding pairs, and supporting this through wizard-like UIs.
As for complicated failures, should they occur, there's always outside help (for which an ecosystem of its own might appear if such a software stack was successful enough).
You're looking for the FreedomBox project.
Same here; I would probably get one if I didn't already have a server to run at home.
I've been kicking around ideas for a fully distributed social network/communication/file storage system. It would only really work if everyone had their own always-on, publicly accessible server at home. I don't know if I have "the right leadership skills", but I'm definitely interested in making something like that happen.
Why would the server have to be at home? Why would it not be enough for everyone to have e.g. their own EC2 microinstance?
No reason that it needs to be at home, but:
1) Ease of setup for the non-tech literate. Someone could buy it, plug it in, and have it running with minimal fuss.
2) Some people don't trust their private data to 'the cloud.'
2) Some people don't trust their private data to 'the cloud.' Yet you'll put the data on the cloud via this appliance and just require a username & password to it?
No, ideally you'll send it directly to other people's appliances, and use public-key encryption where possible.
It seems one could use ssh keys similar to what Amazon does with AWS.
In addition to pyre's reasons, part of the point is to let people control their hardware, and to have better physical control of their data before it leaves the premises, e.g. encrypting email, as forgotusername suggested.
How did you approximate how much memory per user for full text search?
Well, I didn't. :)
Full text search needs little more than stack space to perform merges, but it runs much faster with a good chunk of RAM to cache the tips of posting lists. If you dropped an SSD into one of these, the requirement for RAM to achieve good performance might disappear altogether.
We have built almost our entire warehouse/fulfillment infrastructure on a number of FitPC2 boxes, which also draw about 5-7W with solid-state disks.