Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twake Drive – An open-source alternative to Google Drive

github.com

Post reply on HN
Print view View original

151–160 of 219 posts

Re: Twake Drive – An open-source alternative to Google Drive

#151

Post by vlovich123 »

Steltek wrote: post #77
vlovich123 wrote: post #40

Earlier quoted context omitted.

I really hope you lock it down to something like Tailscale so that you have a private area network and your Samba share isn’t open to the entire world. Samba is a complicated piece of software built around protocols from the 90s. It’s designed around the old idea of physical network security where it’s isolated on a LAN and has a long long history of serious critical security vulnerabilities (eg here’s an RCE from th…

It seems like every network filesystem is irredeemably terrible. SMB and NFS the stuff of security nightmares, chatty performance issues, and awkward user id mapping. WebDAV is a joke. SSHFS is slow. You can get really crazy with CephFS or GlusterFS, and for all that complexity, you don't get much farther way from SMB/NFS issues with those either. My solution: Share nothing and use rsync.

Well one problem is that filesystem in general is a terrible abstraction both in terms of usability and in terms of not fitting well with how you design network applications.

I’d say Dropbox et all is closer to a good design but their backend is insanely crazy optimized to make it work and proprietary. There’s an added challenge that everything these days is behind a NAT so you usually end up needing to have a central rendezvous server where nodes can find each other.

Since you’re looking at rsync where you want something closer to Dropbox, I’d say look at syncthing. It’s designed in a way to make personal file sharing secure.

Re: Twake Drive – An open-source alternative to Google Drive

#152

Post by thebeardisred »

MontyCarloHall wrote: post #83
Wicher wrote: post #68

Earlier quoted context omitted.

As for the permissions, using ACLs would work better here. Then you don't need a separate group for every grouping.

TIL about ACLs! I think that would nicely solve the group permission issue.

Then let me also introduce you to extended attributes, aka xattrs. That's how the data for SELinux is stored.

Re: Twake Drive – An open-source alternative to Google Drive

#153

Post by dessimus »

navigate8310 wrote: post #101
CaptainOfCoit wrote: post #92

Earlier quoted context omitted.

I'd add a fourth; "Make it easy to do backups and verify they're correct". I don't think I've ever considered a data store without that being one of my top concerns. This anxiety comes from real-life experience where the business I worked at had backups enabled for the primary data store for years, but when something finally happened and we lost some production data, we quickly discovered that the backups weren't act…

Schrödinger's backup. Testing the backup works involves even more engineering and non creative work.

"Great, first you wanted more money to buy compute and storage for dev and staging separate from production, and now you even more for 'testing backups'?!"

Re: Twake Drive – An open-source alternative to Google Drive

#154

Post by Valodim »

sureglymop wrote: post #123
Balinares wrote: post #112

Earlier quoted context omitted.

> LINAGORA > ethical Wow, they sure turned things around since their CEO allegedly last locked employees in their office so they'd be forced to keep working through the night.

Can you please provide a source, I am curious about this. I've exhausted my googling capabilities here...

I asked ChatGPT and it said the story was absolutely correct

Re: Twake Drive – An open-source alternative to Google Drive

#155

Post by edoceo »

bornfreddy wrote: post #148

A bit off-topic, but is there a way I can convince various apps (Viber, WhatsApp) to use some replacement instead of Google Drive for backup? They do not offer such an option, but maybe by rooting the phone and faking the interface, or ...?

On Android isn't it "just" a share-targrt? You can make a PWA that's a share-target pretty easy.

Re: Twake Drive – An open-source alternative to Google Drive

#157

Post by wewtyflakes »

wobfan wrote: post #139
wewtyflakes wrote: post #119

Earlier quoted context omitted.

It seems reasonable that someone would want to go beyond just installing software; they are presumably doing so in order to use it for its purpose. Being pedantic about the nature of the complaint (i.e. "He complained about the difficulty of installing an application. He didn’t complain about...") seems to miss the point. All of the additional steps you lay out also have their own steps to get done or decisions to be…

I mean if you want a working Nextcloud instance, available through VPN with backups, then no, it doesn't get more complicated than that, actually. It is incredibly easy.

When hand-waving away complexity, then yes, everything looks easy. :)

Re: Twake Drive – An open-source alternative to Google Drive

#158

Post by misterdata »

seabrookmx wrote: post #150
pr3dr49 wrote: post #128

Give syncthing a go.

+1 for Syncthing. I've been running it for years, after my student discount for Dropbox expired (Google drive and OneDrive were just getting traction at the time). The mobile experience last I tried was pretty rough though. I don't really need my files on my phone and I have a web interface on my home server I can use to grab them in a pinch, but it's something to keep in mind.

If you’re on iOS, try my (FOSS) app for Syncthing: https://github.com/pixelspark/sushitrain

Re: Twake Drive – An open-source alternative to Google Drive

#159

Post by jjkaczor »

CaptainOfCoit wrote: post #92
Vipsy wrote: post #80

Open source drive tools live or die on three things. 1) Simple sync that never surprises. 2) Clean conflict handling you can explain to a non tech friend. 3) And zero drama upgrades. If Twake nails those and keeps a sane on prem story with S3 and LDAP, it has a shot. The harder part is trust and docs. Clear threat model. Crisp migration guides from Drive and Dropbox. And a tiny CLI that just works on a headless box.…

I'd add a fourth; "Make it easy to do backups and verify they're correct". I don't think I've ever considered a data store without that being one of my top concerns. This anxiety comes from real-life experience where the business I worked at had backups enabled for the primary data store for years, but when something finally happened and we lost some production data, we quickly discovered that the backups weren't act…

Heh - I once made a little chunk of change, because a former client from 10-years previous discovered the shiny "DVD/CD" backups had succumbed to "bit-rot" and needed some source code.

I grabbed the hard-drive off the shelf, put it in an enclosure and handed them the source-code... (At the time, every time I upgraded my system, I would just keep my old drives, so... had a stack of them - buy a new external enclosure, slot it and park it.)

Re: Twake Drive – An open-source alternative to Google Drive

#160

Post by gwbas1c »

evolve2k wrote: post #95
gwbas1c wrote: post #76

I built something similar years ago. These are terribly hard to build, so I did a bit of digging. 1: This appears to be backed by a French company called Linagoria. I don't know much about the company, but they've been around for a bit. 2: I experimented with Mongodb for the similar product, and it turned out to be very unreliable. A lot can change since I used Mongodb, but in general, I'm weary of any product that u…

I’ve had similar warnings from multiple very senior devs to never go near mongo. So better explain that choice if you’re wanting adoption. Reliability was the concern.

At the time (2010), MongoDB was intended (from the creators) for handling high volumes of data where some loss was tolerable.

What happened was that its document model, and flexible index model, made it very attractive as an easy-to-use database. I used to call it the "Visual Basic" of databases.

I think the less technical people in marketing latched on to how a lot of people found MongoDB easier to work with, and there was a lot of selling to people who it shouldn't have been sold to.

The problem was that the lossiness nature of MongoDB didn't rear it's ugly head until deep in a project, and the assumptions made when writing documents lead to situations where operations required changing multiple documents; or other corner cases that triggered loss in larger schemas.

Of course, if you used MongoDB as intended, which was for ingesting lots of data with some tolerance of loss, you were totally fine.

Post reply on HN