Cubbit: the distributed cloud funded in 1h on Kickstarter

[JackTheLad]

Hello, I'm Alessandro. As I said in my introductory post, I'm here to learn about NAS technology in general (and FreeNAS in particular) as I'm personally interested in this topic. That's also why I'm collaborating with Cubbit, an innovative distributed p2p cloud storage service with built in redundancy and encryption features.
I want to make a point clear: I'm not here to market a product, but as I have the chance to talk with people interested in the same kind of technology I'm working with, I'd like to hear some opinions, feedbacks and ideas.

I'd like for this topic to be constructive but in the event of divergent opinions I'd prefer it if we adopt this attitude

instead of

Some brief information about Cubbit:

How does it work?

You connect the Cubbit Cell to a router and an electrical power socket and you are ready to go. You just need to make an account to start storing your files. When you upload a file it is client-side encrypted, split into chunks and distributed over the network of Cubbit Cells (your files don't reside directly in your Cubbit Cell but they are in the network, so if the power or internet connection go off at home you're still able to access the stored data). The redundancy procedure is based on Reed Solomon error-correcting codes: each encrypted file is divided into 24 pieces, which are processed into 36 redundancy shards. Out of the 36 shards, only 24 of them are necessary to retrieve the original encrypted file, moreover a recovery procedure is triggered when the total number of online shards reaches a threshold of 30/36.
The user experience is pretty similar to Dropbox to give you an idea.
For any storage device you plug in to the Cell you get half of it to use as cloud service.
This is because of the 100% of the space: 50% is reserved to the user while the other 50% is reserved for redundancy and network operations (including Cubbit's business model to offer in the future a b2b professional cloud service to make it sustainable in the long term. In case you're concerned the user's 50% won't ever be decreased).

Just a quick glimpse of the Cell to let you see it and make the post a bit more visually appealing, lessening the "wall of text" effect :D

Cubbit's service is:

- completely free from subscriptions, forever
- expandable up to 4TB (for now) by simply connecting any USB hard drive
- zero-knowledge: nobody except the owner (and those he decides to authorize) can access the stored data, not even the Cubbit team
- 10 times greener than traditional cloud services, based on proprietary data centers

Currently:

- We raised $50.000 on Kickstarter in less than 1 hour from the launch.
- The Cubbit software is already up and running in beta in more than 10 countries .
- For our green technology, we are funded by the European Commission through the Horizon2020 program. We've also made it into Techstars, an important startup accelerator worldwide.


Below you can find the link to our Kickstarter campaign where, if you're interested, you'll be able to find further informations on the project and in case you have some deep technical questions you'll reach people much more qualified than me to answer them:
https://www.kickstarter.com/projects/cubbit/cubbit-reinventing-the-cloud?ref=4wm35x

There are also Kickstarter's FAQ and Cubbit's webpage FAQ that could help solve your questions.
For any doubt that I'm able to clear I'll be happy to do it.

 

[jgreco]

Want to comment and compare on how this relates to other projects such as IPFS, Swarm, Storage@home, OFFsystem, and other similar projects that have tried similar things? With particular interest in how you deal with the impermanence of volunteer nodes and stuff like that.

 

[jgreco]

Also, it appears you have to buy some dumb "stylish" appliance. I don't need dumb "stylish" appliances. This is a big red flag.

Requiring an additional appliance actually increases carbon footprint, because the users on this forum already have an always-on storage engine. If this isn't something that you can throw onto a FreeNAS as a jail, or for those of us with substantial resources, throw onto our private clouds, it's hard to see where there's any relevance.

 

[JackTheLad]

Want to comment and compare on how this relates to other projects such as IPFS, Swarm, Storage@home, OFFsystem, and other similar projects that have tried similar things? With particular interest in how you deal with the impermanence of volunteer nodes and stuff like that.

Sure, as regards "the impermanence of volunteer nodes and stuff like that" I thought that this part: "...a recovery procedure is triggered when the total number of online shards reaches a threshold of 30/36" would answer it. If you mean what prevents a user from disconnecting the cell, then he'll be notified that his cell is not working properly and that he needs to make sure why. In case of damage to the cell itself the user has one month to replace or repair it before having his files deleted from the network. In case of any problem he can contact us and we'll figure out a solution.
Regarding the other services you mentioned I confess I know only IPFS and Swarm. The first difference that comes to mind from these is that they're both blockchained based and to keep your files stored you need to pay periodic fees to someone else, while with Cubbit you're free from periodic fees forever. The other two projects you mentioned (storage@home and OFFsystem) seem to be volunteer based so I don't know what's the positive reinforcement that drives the nodes to be constantly online and prevent them from deleting the users' files stored.

Also, it appears you have to buy some dumb "stylish" appliance. I don't need dumb "stylish" appliances. This is a big red flag.

Requiring an additional appliance actually increases carbon footprint, because the users on this forum already have an always-on storage engine. If this isn't something that you can throw onto a FreeNAS as a jail, or for those of us with substantial resources, throw onto our private clouds, it's hard to see where there's any relevance.

That "dumb stylish appliance" as you call it :D is a low power device with an almost irrelevant power consumption (less than 1W at full power) that's not really always on as it really works only when storing or serving chunks. When it's not doing these two operation it's basically a LED :p (I'm making a joke here so don't quote me on that, but I really think it could be comparable). The thing is that it's not an additional device, but you could use it instead of a NAS system with the added bonus that your files are spread on a network instead of being stored in just one place. For example, if your NAS has an hardware failure - or in case your home internet connection is cut off - while you are away from home, you probably wouldn't be able to access your files (unless you had set up some other backup systems in place), so personally I wouldn't exactly say that it's hard to see where there's any relevance :D

 

[Constantin]

The best possible integration scenario I can see with the likes of a FreeNAS is a jail plugin or like approach that allow the FreeNAS to act a s Node without requiring the purchase of the black hardware featured in the video. We already have the hardware and our individual internet connection is likely the biggest source of latency, throughput bottlenecking, and so on.

I find some of the claims like "10 times greener" somewhat dubious, especially in the context of a 4TB drive limit. On a annual kW/TB basis, most data center disks likely best the 4TB cubbit drives by a wide margin. For example, my 10TB He10 drives use less power than the 3TB drives they replaced. On a annual kW/TB storage basis, they thus blow the 3TB drives out of the water.

This site features a large technical crowd. Please bring some data to back up those marketing claims.

 

[JackTheLad]

The "ten times greener" claim was refered to traditional data centers, not to a private NAS system as the personal configuration of each NAS can be so diverse that it's impossible to make an accurate estimation. If you want to see some data on which our claims are based please feel free to consult the Green Paper that you can find on Cubbit's website. As regards an integration with other hardware I'm sorry but I don't know what it'd take from a technical point of view so I can't answer on that.

 

[Constantin]

The thing is that it's not an additional device, but you could use it instead of a NAS system with the added bonus that your files are spread on a network instead of being stored in just one place. For example, if your NAS has an hardware failure - or in case your home internet connection is cut off - while you are away from home, you probably wouldn't be able to access your files (unless you had set up some other backup systems in place), so personally I wouldn't exactly say that it's hard to see where there's any relevance :D

If that device of yours isn't running ZFS or a variant thereof, I doubt anyone here will have much use for it. Or is the idea that we'd buy this device in addition to our own FreeNAS? If a jail plugin can be written for FreeNAS then the marginal energy consumption of enabling the cubbit plugin might be de minimus. FWIW, I'd be wary of adding a device to my home network or a jail on my FreeNAS that allows content from others to be stored in my home / business / whatever. If I need a cloud service, there are plenty of folk out there providing the service for a fee with the expectation that the service functions.

Having started to look at the green paper hosted on cubbits site, I'll simply suggest that the first calculation on page 2 is off by a factor of 1000 due to the use of kW when W would have been appropriate (see calculation "1)" vs. table 1). That error doesn't propagate but it illustrates to me the sloppy math at use in this example.

Cherry-picking among disk drives to select one with a lower wattage than the ones used by Backblaze doesn't help either. Not everyone will use a 2.5" form factor WD Blue. Please have a look at @Farmerpling2's excellent resource page regarding more realistic hard drive power consumption figures. If you do that, I think you'll realize quickly that consumer-grade drives below 8TB do not achieve the same W/TB figures as the 8+TB drives used in data centers today, especially if you don't mix and match among form factors.

Next, consider the assertion that all data is mirrored in a data center. I doubt that's the case. Rather, I imagine that most data is going to be stored in a Z2 or Z3 like format on a hot basis and perhaps mirrored to a cold site if further redundancy is required. The cubbit system will likely require more redundancy since any node at any time can drop out. That interplay (nodes entering and leaving the cubbit universe) will likely lead to more packet traffic across the internet as the data blocks get (re-)distributed. All that will likely take more power than what it would take to do the same thing inside a data center where a single entity can actually control the distribution of hardware / data. There is no free lunch.

Does data-center cooling really double the power needs of a hard drive? Also consider that most homes in the US targeted by the cubbit appliance likely feature AC systems that are less efficient than the AC systems used in data centers. Thus, I'd drop that multiplier on page 2 from the get-go. Networking equipment equipment in SOHO applications is also unlikely to be significantly more energy efficient than the professional stuff once you factor in how many TB/annum are being transferred across it.

In other words, I suggest the use of critical thinking skills rather than absorbing anything published in a PhD dissertation format as genuine. I find the math simply too skewed in the direction that the authors wanted it to point in rather than offering a realistic assessment of what cubbit offers vs. the regular cloud. Please don't take this criticism personally, I'm simply trying to level the playing field.

 

[JackTheLad]

I sincerely thank you for your inputs, this is exactly why I started this topic: constructive criticism.
I'll be sure to point out what you said to our tech guys so that we can improve (if needed) our approach and documentation.

Regarding our target user I don't think it is necessarily someone who already owns a NAS and wants another solution to implement on it (as of now there are no actual plans to integrate the software with other hardware, so someone could try Cubbit by itself, not use it with other systems) but more somebody that wants/needs a different solution from the ones actually offered by NAS or traditional cloud systems.

I feel like Cubbit could be the missing link between these two technologies as it's definitely more user friendly than a NAS (requiring much less work and knowledge than setting up and maintaining it) while offering the easy user experience and resilience (actually even more thanks to the data's distribution) of traditional cloud services (but without the fees and privacy concerns associated to it).

I feel like this picture express exactly this

 

[jgreco]

almost irrelevant power consumption (less than 1W at full power)

That seems ... unlikely, especially if there's a hard drive in there. If there isn't a hard drive, and it's SSD, then the pricing seems off, though I suppose it might be possible to arrive at 1W idle power.

I'm happy to see @Constantin 's well thought out message as it saves me the time and trouble on a day I don't have the time.

If you were trying to save the world, you'd build a software stack and let people stick it on devices such as a Raspberry Pi, or for those of us with private cloud capacity, a virtual machine with "de minimus" (nice choice of term @Constantin) cost.

I don't want to have to find some place to stick some unnecessarily large dumb "stylish" appliance. This thing shouldn't need to be big. With AC power supply, logic, and a 2.5" internal HDD, it should be around the size of a 3.5" HDD.

I don't want to have to pay ~$250 for the lowest tier device.

What happens when, as with so many Kickstarters, this project runs out of funds? It appears someone somewhere is "managing" this thing and maintaining a directory. This is not actually free. What happens when the money runs out? When the feds decide it's being used for kiddie pr0n and shut it down? Will this thing even have the decency to dance and sing for you to tell you that it's dead?

This doesn't appear to be innovative, or a new idea, or particularly well thought out as to what happens down the road. I easily have files dating back to the '80's here. Storing data reliably is a long-term affair. Convince me there's some business plan for this to be viable 24 months from now.

 

[Constantin]

Based on the video embedded above, I reckon the idea is that the HDD is external and 2.5" form factor (hence the 4TB drive limit) in order to allow bus-powered operation and to claim that sweet 1.6W power consumption. I'm still scratching my head here regarding the cost efficiency of it all. Anytime someone offers an allegedly free service that reputable providers like BackBlaze, AWS, etc. charge money for, ask yourself a simple question: how is this going to get paid?

I certainly would not expect a bunch of sub-1W nodes be able to figure this out and coordinate data distribution on their own once the project starts to scale. Just the node-node traffic coordinating where everything is, what was lost, what will need to be re-distributed, etc. seems like a really difficult complex problem to solve in the context of unreliable nodes that rely on high-latency links. This type of P2P network has the potential to make AWS Galcier services look downright quick.

Thus it's likely that an entity has to control / coordinate all those data packets out there. Even if the backend scales perfectly, how will the needed infrastructure grow with the project? How will it finance itself? One-time hardware sales aren't going to do it at the $250 price point, even if you make 4x on the hardware, as all that money will start to run out quick once you hit the top of the adoption curve. Recurring revenue is the cornerstone of just about any viable business.

 

[Constantin]

Regarding our target user I don't think it is necessarily someone who already owns a NAS and wants another solution to implement on it (as of now there are no actual plans to integrate the software with other hardware, so someone could try Cubbit by itself, not use it with other systems) but more somebody that wants/needs a different solution from the ones actually offered by NAS or traditional cloud systems.

I sincerely don't want to hurt your feelings, but if the above is true, why are you posting an advertisement for your product on this website? Per your own words, no one here would be interested in your product because they all decided to roll their own or buy a pre-configured NAS.

I feel like Cubbit could be the missing link between these two technologies as it's definitely more user friendly than a NAS (requiring much less work and knowledge than setting up and maintaining it) while offering the easy user experience and resilience (actually even more thanks to the data's distribution) of traditional cloud services (but without the fees and privacy concerns associated to it).

Careful. You are advertising features that have yet to see the light of day (aka Vaporware). I've repeatedly remarked on the steep learning curve associated with FreeNAS in this forum but at least the features are there. You also make statements regarding reliability that I would shy away from unless you have petabytes of data to back it up with. Your proposed system has no control over the availability of data. Unless the data is even more mirrored than the data center that the green paper complained about, you can't possibly claim that the data will be retrievable on a reliable basis.

I do not work in a data center but I reckon that big cloud providers like AWS, Azure, iCloud, etc. are not only backed up but also geographically diverse to ensure data survival with a very high likelihood regardless of what mother nature drops on them. I don't quite see how cubbit manages to eclipse that even if you start backing up US data to Australia and back (never mind the latency or addressable market problems associated with that scenario).

I feel like this picture express exactly this

Regardless of the appeal of pretty overlapping Venn diagrams or the Krupp Stahl symbol, this "solution" seems to be built on a shaky foundation. The math is likely wrong, the ease-of use / security / resiliency / etc. claims unsubstantiated, the funding uncertain. Not trying to burst your bubble, but I'd look for a better opportunity to improve the world than this project.

 

[JackTheLad]

...If you were trying to save the world, you'd build a software stack and let people stick it on devices such as a Raspberry Pi...


...I don't want to have to pay ~$250 for the lowest tier device.

What happens when, as with so many Kickstarters, this project runs out of funds? It appears someone somewhere is "managing" this thing and maintaining a directory. This is not actually free. What happens when the money runs out?...

...Convince me there's some business plan for this to be viable 24 months from now.

We decided to use the Cell to start building the network because it hosts a single PC board 2/3 times more effective than a Pi, so it lets us overcome some limitations that we encountered during the development of the project and it'll permit us to scale accordingly. What you should understand is that you aren't just buying a device but also helping us build the network and infrastructure necessary to grant the service you'll be able to enjoy - free of charge - for the rest of your life. As I said in my opening post (and also in the FAQ i believe), once the network will be more distributed we are planning to offer a b2b professional cloud service to help us maintain the network.

We are debating on the possibility of releasing the software open-source in the future. We are not doing it now because, as you can imagine, releasing a very big codebase open-source requires a great effort, both for handling the community and for addressing issues. Also, the simple fact that the repositories are open-source generate a noise which we could not endure at the current stage, having just a few developers and not much money (remember that we have to ship a product in a few months and handle a crowdfunding campaign in the meantime).

... Anytime someone offers an allegedly free service that reputable providers like BackBlaze, AWS, etc. charge money for, ask yourself a simple question: how is this going to get paid?

I certainly would not expect a bunch of sub-1W nodes be able to figure this out and coordinate data distribution on their own once the project starts to scale. Just the node-node traffic coordinating where everything is, what was lost, what will need to be re-distributed, etc. seems like a really difficult complex problem to solve in the context of unreliable nodes that rely on high-latency links. This type of P2P network has the potential to make AWS Galcier services look downright quick.

Thus it's likely that an entity has to control / coordinate all those data packets out there. Even if the backend scales perfectly, how will the needed infrastructure grow with the project? How will it finance itself? One-time hardware sales aren't going to do it at the $250 price point, even if you make 4x on the hardware, as all that money will start to run out quick once you hit the top of the adoption curve. Recurring revenue is the cornerstone of just about any viable business.

You're right when you say that hardware sales aren't going to provide all the necessary funds to support the project, that's why - as I already said - we're going to offer a b2b cloud service to generate a flow of constant revenues to let us do that.

As regard your concerns about the coordination of the network, I'll tell you what's also clearly explained in the "Technology" section on Cubbit's website: "Once the file has been encrypted and segmented, the client communicates with the coordinator to obtain authorization for uploading it to the distributed cloud. The coordinator, in turn, verifies the authorization and finds the optimal set of 36 Cells to store the file by minimizing a cost function that accounts for geographical proximity, mean uptime, free space and other metadata. It then acts as handshake server to initiate the peer-to-peer connection between the hosting Cells and the client, which distributes the shards on the network."
The coordinator is hosted on one of the most reputable providers on the market, so I'd say we're covered on that.

I sincerely don't want to hurt your feelings, but if the above is true, why are you posting an advertisement for your product on this website? Per your own words, no one here would be interested in your product because they all decided to roll their own or buy a pre-configured NAS.



Careful. You are advertising features that have yet to see the light of day (aka Vaporware). I've repeatedly remarked on the steep learning curve associated with FreeNAS in this forum but at least the features are there. You also make statements regarding reliability that I would shy away from unless you have petabytes of data to back it up with. Your proposed system has no control over the availability of data. Unless the data is even more mirrored than the data center that the green paper complained about, you can't possibly claim that the data will be retrievable on a reliable basis.

I do not work in a data center but I reckon that big cloud providers like AWS, Azure, iCloud, etc. are not only backed up but also geographically diverse to ensure data survival with a very high likelihood regardless of what mother nature drops on them. I don't quite see how cubbit manages to eclipse that even if you start backing up US data to Australia and back (never mind the latency or addressable market problems associated with that scenario).


Regardless of the appeal of pretty overlapping Venn diagrams or the Krupp Stahl symbol, this "solution" seems to be built on a shaky foundation. The math is likely wrong, the ease-of use / security / resiliency / etc. claims unsubstantiated, the funding uncertain. Not trying to burst your bubble, but I'd look for a better opportunity to improve the world than this project.

I'll copy-paste the reply that was given to me by one of the writers of our green paper adressing some of your concerns about the math used to back up our claims:

- "factor 1000 in eq. (1): an obvious typo (that, as you said, does not propagate). Thanks for reporting it, but typos do not illustrate sloppy math.
- factor 2 for cooling in DC: it is not made up, if you are familiar with the concept of PUE, it is actually usually higher than 2 (see for example https://www.electronics-cooling.com...costs-more-than-the-it-equipment-it-supports/)
- factor 2 for redundancy: again, not made up. It is a factor included in the original publication from which we took the public cloud model, Baliga et al. proceedings of the IEEE (2011).
- Cubbit's redundancy: we have a factor 1.5 since we use 24+12 Reed Solomon error correcting code. That is taken into account into the computations (also on the transfer side).
- WD Blue: is used in the computations because it is the HDD featured inside the Cubbit cell. Again, this is explicitly specified in the text."


I think I already made clear in both my opening posts that I'm not here to market a product, but to learn more about storage technlogies. I took the chance to introduce Cubbit to the community to receive some direct feedbacks on it and understand how it is perceived by a more tech oriented crowd of people. I may use some "promotional" material to help me explain my point of view but that's just because this is what I have on hand. As I'm part of the business development team I'm used to seeing it so thats why I often use it to explain what we do and how we do it.
I'd also like to remind you and everyone else that I'm here privately as a technology enthusiast, not on an official role as "Cubbit's promotional man", so we aren't on opposite sides. I welcome confrontation, I'd just like it more if you weren't trying to belittle Cubbit at all costs.

I'd also like to invite both you and the other users interested on the topic to adopt an open minded approach (as to me it seems that things here are escalating pretty quickly and I'd like to avoid the scenario I talked about in my OP) and to read carefully the informations you can find on Cubbit's website and Kickstarter's page FAQ other than the replies given in the Kickstarter campaign page. After doing that, if you still have some doubts I'll be happy to discuss the project with anyone interested in doing so. Also, you don't need to worry about my feelings, but I'd like to ask you to say what you have in your mind with a neutral attitude to avoid flames and also because in our team there are many people whom I respect that could be earning a lot more money in other companies but they decided to dedicate themselves to this project as they firmly believe in it and its ideals. So I'm a bit more annoyed by the fact that you're calling their work bu****it than because you're trying to diminish what I say :)

 

[Constantin]

The proof will be in the implementation. :)

I take exception to the characterization that I tried to start a flame war. Instead, I pointed out obvious mistakes in the energy model for this application. Accounting for every watt on the cloud server side and then not doing the same on the cubbit side is simply biased math that aims to show a energy efficiency improvement where there likely isn't any. A distributed cloud model for data storage is neat by all by itself, making efficiency claims of '10x better' immediately triggers skepticism from folk who have been working on energy efficiency pretty much their entire career.

Companies like Backblaze, Facebook and Apple design their own storage systems / PCBs precisely to improve performance while lowering the power bill. Here is an example from LinkedIn, whose latest open19 platform will allow the server to "operate properly between 10C and 40C". That in turn allows for the use of economizers and like cooling methods instead of vapor-compression systems. Data centers and the hardware in them have made great leaps since the 2011 study cubbit references; a fair comparison would have compared current data center designs with your current design. So much for the 2x space-conditioning factor.

Similarly, the 2x backup factor claimed in the paper also doesn't seem to hold up. For example, at storage cloud provider Backblaze, files are broken into 20 shards (17 data, 3 parity) and stored inside 20 separate storage pods. Backblaze claims a data durability of 99.999999999% - and they have the data to back up that claim. Moreover, the storage efficiency at Backblaze (17/20) is 85% vs. the 66% claimed for cubbit. All the data, coordination, etc. is done within their own facilities, minimizing the amount of equipment that needs to be powered to 'touch', coordinate, move, and store the data. Bottom line, I don't see how Backblaze can be less power efficient than cubbit, as long as you include all the infrastructure needed for either storage scenario in your calculation. Just because your average home user doesn't see the power bill associated with the operations at the ISP and up level, make no mistake, they will pay for them eventually.

Moving on to the cubbit hardware, any active HDD is stated to consume more than 1W all by itself per FarmerPling2's data. Thus, a sub-2 Watt plug-load limit is difficult to achieve once you account for power supply efficiency, network adapter activity, and other loads. But... the cubbit node pictured in your intro video shows an additional, bus-powered hard drive on the outside. The minimum idle load of any drive in the database is 0.5W. Staying below 1W will hence depend on having to pretty much never spin up the hard drive(s), which seems pretty unattainable on an active network if the network is supposed to be even remotely responsive.

In closing, if you truly are open to constructive criticism, act like it, and choose your words a bit more wisely. Accusing me of calling someone's work "bu****it" is not only a lie but also completely at odds with your stated goal of preventing a flame war.

 

[HoneyBadger]

Hey now, I'm the one with the Angriest Animal In The World as their avatar. Let me be the jerk here. ;)

The Kickstarter FAQ and comments from "Marco" there do seem to lend some additional credence to the idea of this being a software-based solution in the future, what with talk of expanding to general-purpose devices, growing beyond the original scope, and only using the funding from the nodes as a "springboard" to better things. I can see Cubbit being quite suitable for smaller scale users who don't need large amounts of data. For others, especially users with significant storage requirements and/or bandwidth transfer caps, it's obviously less appealing.

I see this as complimentary to FreeNAS, not necessarily competitive. Think "decentralized storage, made easy enough for that clueless relative that keeps badgering you why they run out of iCloud space." hehehe "badgering"

We decided to use the Cell to start building the network because it hosts a single PC board 2/3 times more effective than a Pi, so it lets us overcome some limitations that we encountered during the development of the project and it'll permit us to scale accordingly. What you should understand is that you aren't just buying a device but also helping us build the network and infrastructure necessary to grant the service you'll be able to enjoy - free of charge - for the rest of your life. As I said in my opening post (and also in the FAQ i believe), once the network will be more distributed we are planning to offer a b2b professional cloud service to help us maintain the network.

Let me get a little Dragon's Den here as a potential investor:

What's the target audience for this b2b cloud service, and how will you position your solution as a viable and economically beneficial alternative to existing solutions? The obvious appeal markers of zero-knowledge encryption certainly goes a long way in the consumer world what with the multiple wide-scale and highly-publicized data breaches, but any business that's not encrypting before piping their data offsite is just being negligent (and possibly violating industry-specific regulations, depending on their vertical.) It's fine to sell to consumers based on the virtue-signal of being eco-friendly and having a high degree of individual user-friendliness, but much like the animal I took my name from, "Big Business don't care. Big Business don't give a damn."

Hit me with your elevator pitch. (PM is fine too.)

We are debating on the possibility of releasing the software open-source in the future. We are not doing it now because, as you can imagine, releasing a very big codebase open-source requires a great effort, both for handling the community and for addressing issues. Also, the simple fact that the repositories are open-source generate a noise which we could not endure at the current stage, having just a few developers and not much money (remember that we have to ship a product in a few months and handle a crowdfunding campaign in the meantime).

From a hacker perspective, I'd like to see something to the effect of a "drop-dead clause" that would say "upon insolvency of the company, the software will be released open-source" so as that the devices aren't rendered useless; maybe also provide a JTAG port on the device and don't restrict the bootloader.

 

[jgreco]

- factor 2 for cooling in DC: it is not made up, if you are familiar with the concept of PUE, it is actually usually higher than 2 (see for example https://www.electronics-cooling.com...costs-more-than-the-it-equipment-it-supports/)

So you're going to have the temerity to quote a report from the era of peak single-core CPU where we broke the 100W TDP for a *single core*, meaning very inefficient, hot-running CPU's, and quote the PUE from *THAT* year?

I'm sorry, I'm just going to have to rip that a new one. As someone who's been working professionally to increase efficiency in the data center, I take great offense at that, Go take a look at the Global Data Center Survey (Uptime Institute). Yes, it was around 2.5 in 2007, but fell to just less than two (1.98) by 2011, 1.65 in 2013, 1.58 in 2018, and trends suggest that there will be some disruptive things happening that may reduce the need for cooling much further. The switch from HDD to flash is one of these.

I find it hard to have a meaningful discussion if there is obviously false information being used by the opposing side.

 

[uoR]

@JackTheLad - I am also new to this forum and the kinds of knowledge wielded here. And I know it isn't difficult to misinterpret the communication styles of people who know A LOT and spend huge energy and time sharing with people like me. I may be off the mark, but I empathize on some level with the position you've put yourself in. It's not so easy to just float into a tech forum, open your own thread, and then try to dictate proper decorum, as you did in your opening post. At a minimum, here or at your next forum stop, you might try reading through some threads for a day or two, first, getting to know, if nothing else, the minds at play. If you're like me, you still won't understand much, but you'll save yourself and others from trying to reinvent the local culture, the lines between insult and passionate feedback, and the difference between fact and opinion. Sincerely, it's very easy to fall into doing all of those things.

You have yet to ask any questions of these very knowledgeable folk, who, as one should expect, will seek facts more than opinions. If you give them opinions that they remold (graciously, if you ask me, regardless of how I feel it is communicated) into better researched opinions or facts, then you have been given a gift.

So, maybe you could come up with some questions you really want to know the answers to...since you're really

here to learn about NAS technology in general (and FreeNAS in particular)

and not wishing to appear instead as more of a startup buzz generator who identifies less with learning from the forum than with staying rooted in

"promotional" material to help me explain my point of view but that's just because this is what I have on hand. As I'm part of the business development team I'm used to seeing it so thats why I often use it to explain what we do and how we do it.

 

[JackTheLad]

Hi guys, I just wanted to let the discussion cool off and have the time to reply properly.

@Constantin : I was talking more about the direction the topic was heading to (in my opinion). Backblaze seems good (with Reed Solomon etc.) as their policy appears to be above the industry standard. Being the exeption and not the majority we didn't take them as a comparison point. Thanks for the useful information though. I'll keep it in mind and check it out when I have the chance. If you have other thoughts feel free to share them.

@HoneyBadger : I agree with this point you made "I see this as complementary to FreeNAS, not necessarily competitive". As of right now we decided to focus on b2c. We'll see the developments in the next future as regards b2b.
In case you are interested we just released Enigma, our crypto isomorphic library, open source.
You can check out this article to see how it works https://medium.com/cubbit/how-to-bu...-with-javascript-and-webassembly-6fc7aa708437
or if you want to see the more technical part, here is the github repository: https://github.com/cubbit/enigma
Regarding the "drop-dead clause" it's an interesting idea, I'll report it.

@jgreco: Thanks for pointing to documents with data more updated than the ones we had. We'll integrate them in future revisions of our greenpaper.

@uoR: Thanks for the tips, I'll keep them in mind

 

[Constantin]

Backblaze, Carbonite, etc. are not the exception. They are massive providers and they are what you hope to become (i.e. your peers). Dedicated backup providers in the cloud are about as close to a point of comparison as you're going to get for your academic paper. Like Cubbit, their emphasis is on storage, not VMs, etc. Please compare yourselves to peer companies focused on storage, not the general cloud. Otherwise, you're comparing apples to oranges and deliberately skewing the results.

Similarly, we have already established that the current Reed-Solomon implementation envisioned by cubbit is not as storage-efficient as Backblazes'. That's to be expected, your project has no control over attached assets, whereas Blackblaze does. Hence, it's quite logical for your project to be less efficient re: available vs. installed storage than that of a dedicated backup provider. Backblaze only loses 15% of its installed storage to parity / backup whereas your description of cubbit loses 33%.

The point of all this is that I would take down your claims re: efficiency and focus on the the distributed cloud idea instead, which may have merit. The claims regarding energy efficiency do not hold up to even cursory review. Any backer disappointed with the project could then use this as leverage to make kickstarter de-fund your project due to fraudulent claims being made or blacklist the team from ever working with kickstarter again. Why risk this? Your team has a big enough challenge to build the hardware and create the software.

Congratulations on getting funded, best of luck with the challenge of implementation ahead.

 

[jgreco]

[Mod note]: Thread seems to be attracting random website spammers so I am locking it, sorry. If any established user wishes to contribute to this thread, please let me know and I will happily unlock it.