10 years since Google said to “hang tight” about Linux support for Google Drive(abevoelker.github.io)
abevoelker.github.io
10 years since Google said to “hang tight” about Linux support for Google Drive
https://abevoelker.github.io/how-long-since-google-said-a-google-drive-linux-client-is-coming/
226 comments
Just give us a web filesystem already. Stop with these shitty infantilized GUIs with no hierarchical organization and an overreliance on search to find things. I have literally hundreds of thousands to millions of files on my local machines and have no trouble remembering where I put things. Drive can't seem to scale past a few dozen before it's confusing, useless, and apparently lossy. Remember when web servers would serve up the contents of a directory as a list with hyperlinks on the file names? That actually worked ffs. I cannot understand how we could be moving backwards so quickly.
There is a transition from a file-centric to an app-centric model, that I mostly disapprove of, but that's what is happening.
Before, you had files stored in a filesystem, you picked the file and opened it with the app. On Windows, you double-click on the file, on a command line, you type "app filename".
Now the trend is to first open the app and then use the app to fetch your data, that data is entirely managed by the app and may be stored in an opaque area of a filesystem, some server on the internet, etc...
I disapprove of the "new" way (that is not so new, but it is the current trend) because it favors lock-in and general loss of control. But there are also some advantages such as being able to do versioning, syncing, collaborative work, searching and general database-like operations when your filesystem doesn't support it. A lot of popular open source "not evil" software use that model, for example, IIRC, Firefox has always stored bookmarks in an opaque sqlite database while Internet Explorer stored them as files in a folder, and I don't think I need to tell you which one is considered the most evil.
I disapprove of the "new" way (that is not so new, but it is the current trend) because it favors lock-in and general loss of control. But there are also some advantages such as being able to do versioning, syncing, collaborative work, searching and general database-like operations when your filesystem doesn't support it. A lot of popular open source "not evil" software use that model, for example, IIRC, Firefox has always stored bookmarks in an opaque sqlite database while Internet Explorer stored them as files in a folder, and I don't think I need to tell you which one is considered the most evil.
sqlite is opaque? I've got this script to list my open tabs, and a few more scripts for other Firefox actions.
$ grep FIREFOX ~/.bashrc
export FIREFOX_DIR=$HOME/.mozilla/firefox/q3m93qpe.default-release/
$ cat ~/.local/bin/ff-tabs
#!/bin/bash
lz4jsoncat $FIREFOX_DIR/sessionstore-backups/recovery.jsonlz4 | jq -r '.windows[].tabs[].entries[-1] | .title, .url, ""'Ha! Of course I would choose an example based on JSON, not sqlite, but the point still stands. Sqlite is one of my favorite file formats, it presents the data in an interface far easier to manipulate for a one-off CLI command than writing another Python script with open() and dozens of re.sub().
JSON is also not very opaque. What's opaque is iOS with its locked down storage per app as you mentioned.
Some OS builders have been trying to push this model on the desktop but have not been very successful due to legacy. It only seems to be done with mobile apps running on the desktop (Windows with Android apps and macOS with iOS)
I also lament this model, I think we should always have full access to our devices. But there's a strong commercial push for lock-in and subscription models.
Some OS builders have been trying to push this model on the desktop but have not been very successful due to legacy. It only seems to be done with mobile apps running on the desktop (Windows with Android apps and macOS with iOS)
I also lament this model, I think we should always have full access to our devices. But there's a strong commercial push for lock-in and subscription models.
How do you use it?
On the flip side, Steve Jobs tried to make this happen for the iPad and Apple eventually gave up and built the Files app because they were trying to make it into a system you could do actual work. "All data belongs to a single app" was at odds with most work tasks other than checking your email, and sending copies of data back and forth between apps with share sheets is alright if you only have to do it once, but it doesn't really scale.
The people pushing to have all desktop programs isolated from each other by default in the name of "security" are making the same mistake.
Actually Google did made a version of Google Drive Filestream for Linux, and made it available it Google Colab, just that they never released it publicly for unknown reason. I have grabbed the binary of it. https://github.com/michaellee8/gdrivefs/tree/master/assets
There are quite a few clients for Linux, I use Syncdocs https://www.syncdocs.com/ as it has built in encryption.
Non I've seen do a proper job of mounting as a drive, NFS or SMB would be nice.
Non I've seen do a proper job of mounting as a drive, NFS or SMB would be nice.
I’d take a file system that can be indexed by my local operating system (MacOS).
The last MacOS update broke Spotlight indexing for my Google Drive folders. Really annoying not being able to use Spotlight (and by extension Alfred), so the only logical thing to do was move to iCloud.
In the process of moving off of Google Drive, I also decided to move my email to Fastmail and just ditch GSuite (or whatever they are calling it today) forever. I’ll sleep better at night knowing that Fastmail knows their place and (hopefully) won’t try and force a chat function into my web email client as a means to build engagement for a product I don’t care about.
The last MacOS update broke Spotlight indexing for my Google Drive folders. Really annoying not being able to use Spotlight (and by extension Alfred), so the only logical thing to do was move to iCloud.
In the process of moving off of Google Drive, I also decided to move my email to Fastmail and just ditch GSuite (or whatever they are calling it today) forever. I’ll sleep better at night knowing that Fastmail knows their place and (hopefully) won’t try and force a chat function into my web email client as a means to build engagement for a product I don’t care about.
Spotlight no longer working with google drive — for months now — has been such a pain in my ass that it’s finally convinced me to shift my entire company off Google Workspace. At least with Microsoft I can get someone on the phone.
I agree with you 100%. I just want something that stores files and works with SFTP and NFS out of the box. I get so annoyed every time I have to use S3 manually.
However, there is a post on this site that has become infamous in which a commenter questions the need for Dropbox when stuff like SFTP already exists.
However, there is a post on this site that has become infamous in which a commenter questions the need for Dropbox when stuff like SFTP already exists.
I’ve wondered how practical using Azure Files with SMB is. It also supports NFS.
https://docs.microsoft.com/en-us/azure/storage/files/files-s...
https://docs.microsoft.com/en-us/azure/storage/files/files-s...
SMB is absolutely terrible over latent connections.
I don't understand how SMB could work unless there was geographical replication to nodes closer to you, with some kind of load balancing to change the endpoint you're using to be closer to you.
I don't understand how SMB could work unless there was geographical replication to nodes closer to you, with some kind of load balancing to change the endpoint you're using to be closer to you.
Yup, hence the wondering. They keep improving the protocol and I am hopeful that one day I might try it and be pleasantly surprised.
https://docs.microsoft.com/en-us/windows-server/storage/file...
https://docs.microsoft.com/en-us/windows-server/storage/file...
You want https://rclone.org/commands/rclone_mount/. Yes it should really just be a straight up product, but for the moment you can hack it together fairly effectively.
They should take inspiration from nginx and Apache directory listings. Doesn't take 4s to load and uses actual links so you can open in new window or copy the link.
> Just give us a web filesystem already.
WebDAV is kinda that. I subscribe to a (super cheap) hosted version from Hetzner and I'm happy with it even though the server is on a different continent. As mentioned somewhere in another comment, I also use rclone mount to use it, but there are other options as well (the client built into GNOME is reasonably good, the client built into Windows 10 is terrible).
WebDAV is kinda that. I subscribe to a (super cheap) hosted version from Hetzner and I'm happy with it even though the server is on a different continent. As mentioned somewhere in another comment, I also use rclone mount to use it, but there are other options as well (the client built into GNOME is reasonably good, the client built into Windows 10 is terrible).
Agreed. Every time I go to save a file I have to stop thinking like a techie and put my 'think like Google' hat on. My wife is the average, basic user. Windows and Linux filesystems she navigates with no issue. Google Drive? Confuses the heck out of both of us and I've been a techie my whole life.
You’re still free to use a webserver with directory listing turned on..
I agree with all of your complaints, but will say Gnome nautilus integration is working pretty well these days, and allows me to interact with it more like a filesystem than a shitty webui.
... until you try to open the files with a non-gnome application. Mounting a filesystem was supposed to be a solved problem.
Examples? Maybe I just don't have enough non-Gnome applications tbh.
I just tested with Slack, VSCode, and GIMP, and all three allowed me to browse and open from there.
I just tested with Slack, VSCode, and GIMP, and all three allowed me to browse and open from there.
From the top of my head, QOwnNotes (hierachical markdown notes) and KeePassXC (password manager). I remember those two because I had to use DropBox, they can't see the Gnome Google Drive path as a regular path.
I ended up buying InSync because it was 50% off in easter, and its Google Drive/Dropbox paths works perfectly even in the terminal. Unfortunately it lacks Google Drive streaming.
I ended up buying InSync because it was 50% off in easter, and its Google Drive/Dropbox paths works perfectly even in the terminal. Unfortunately it lacks Google Drive streaming.
CoastalCoder(1)
Consider paying for S3.
S3 is not a filesystem replacement unfortunately.
Why not? It's a cloud service that stores files, can pretend to have directories, and for which there exist multiple utilities to mount the thing as a local file system. What's the shortcoming?
S3 is object storage not block storage.
https://www.digitalocean.com/community/tutorials/object-stor...
Object storage isn’t random access (the ability to read and write any part of a file) the way a disk drive is. This causes complications for software that expects to be able to randomly access a file like they would on a disk.
https://www.digitalocean.com/community/tutorials/object-stor...
Object storage isn’t random access (the ability to read and write any part of a file) the way a disk drive is. This causes complications for software that expects to be able to randomly access a file like they would on a disk.
WebDAV is also an object storage protocol but it can do random access. Well, almost.
Partial reads are supported everywhere out of box just by using the Content-Range HTTP header.
Partial writes aren't standard, but some implementations e.g. SabreDAV can do those using PATCH with X-Update-Range header (and e.g. rclone supports this).
WebDAV has its warts and limitations but it's a very underappreciated protocol.
Partial reads are supported everywhere out of box just by using the Content-Range HTTP header.
Partial writes aren't standard, but some implementations e.g. SabreDAV can do those using PATCH with X-Update-Range header (and e.g. rclone supports this).
WebDAV has its warts and limitations but it's a very underappreciated protocol.
As someone else pointed out, it's object storage not block storage meaning things like partial reads and partial writes don't work. That may not be a problem for you, but it _is_ a problem for me (particularly when dealing with remote data).
> for which there exist multiple utilities to mount the thing as a local file system
Which all have their own sets of intricacies. The most obvious one being listing a directory is either impossible, costly, or as slow as the heat death of the universe. Other (far riskier) ones (from s3fs-fuse, which I have the most experience with[0] ) are the lack of guarantees about atomicity and concurrent access.
[0] https://github.com/s3fs-fuse/s3fs-fuse
> for which there exist multiple utilities to mount the thing as a local file system
Which all have their own sets of intricacies. The most obvious one being listing a directory is either impossible, costly, or as slow as the heat death of the universe. Other (far riskier) ones (from s3fs-fuse, which I have the most experience with[0] ) are the lack of guarantees about atomicity and concurrent access.
[0] https://github.com/s3fs-fuse/s3fs-fuse
Why pay when https://min.io/ exists?
I'd rather that didn't happen. The current web ecosystem of adtech companies and data brokers makes the web one of the last places where I'd want to entrust my files with. And before anyone mentions permissions, I don't see that putting a stop to data harvesting. Because if that even worked, social media would not have been a thing. It has been shown that people just "willfully" give up their data without giving as much thought to the consequences. So if this web filesystem plan goes through, entire services would be built around users giving companies access to their files, and those would go straight to the ad networks. Less friction in the browser means that we'd see an exponential increase in those type of services. So the current friction is better for user privacy.
It feels like Google’s attention span, leadership longevity, and product development patience is roughly 3 years. Any product that survives longer than that probably has transcended beyond being a “pet project/toy” into a PR-problem or revenue-stream significant enough that it takes on a life of it’s own. As management turns over, that lease on life is renewed…
https://killedbygoogle.com/
While this fosters new ideas and opportunities, that conversion into long-term direction and execution can be pretty rough.
https://killedbygoogle.com/
While this fosters new ideas and opportunities, that conversion into long-term direction and execution can be pretty rough.
3 years is roughly the average time it takes to get promoted at Google.
Or the time someone leaves and goes to another job.
Or the time for a product to die.
Funny how they all seem to be correlated. /s
You nailed it. Every 3 years google renames and rebadges their chat system. I don't even know what to call it anymore.
I've posted this link before in comments, but for anyone who's not read this arstechnica piece it is well worth it:
A decade and a half of instability: The history of Google messaging apps
https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...
A decade and a half of instability: The history of Google messaging apps
https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...
Good stuff. To give google a little credit, google talk is what killed off AIM for everyone I knew. Mostly because you could knock out chat and email on one page and it was cool cuz google was not yet being evil and then eventually they had other fun stuff to integrate with like reader and igoogle…
> A decade and a half of instability: The history of Google messaging apps
How do they keep failing over and over, in the same way, when these failures are a well-known embarrassment?
You'd think the CEO would either just ban development of new messaging apps or pick a winner and give it the same kind of care and feeding as GMail.
How do they keep failing over and over, in the same way, when these failures are a well-known embarrassment?
You'd think the CEO would either just ban development of new messaging apps or pick a winner and give it the same kind of care and feeding as GMail.
I was completely fine with the old Hangouts thing. A small little call/chat system embedded into the inbox. Would occasionally ping friends and occasionally chat.
You maybe, but Google is looking for a whatsapp/wechat killer, and will keep trying till they have it, or abandon the idea.
My guess is because things like that don't make any or much direct revenue, so they aren't going to get senior executives to want to take ownership and champion the thing.
Killing a chat product that has always been a net loss for the company might not appear to be a failure.
Killing a chat product that has always been a net loss for the company might not appear to be a failure.
> Killing a chat product that has always been a net loss for the company might not appear to be a failure.
Doing that once, yeah, doing that over and over, no so much.
At this point the smartest thing to do it just kill them all and definitively say: "No more, this is the end of Google chat apps."
Doing that once, yeah, doing that over and over, no so much.
At this point the smartest thing to do it just kill them all and definitively say: "No more, this is the end of Google chat apps."
> Doing that once, yeah, doing that over and over, no so much.
What do you mean? It's always good move to kill a product that loses money for the company.
Why do they start so many new products that are losers? That's a different question. Possibly the incentives for starting new products are poorly calibrated, which is the common narrative. But possibly they aren't and they are quite happy to make a mountain of shit, including doing almost the same thing over and over, for the small chance of a diamond. That's entirely consistent with the rest of the start-up industry.
What do you mean? It's always good move to kill a product that loses money for the company.
Why do they start so many new products that are losers? That's a different question. Possibly the incentives for starting new products are poorly calibrated, which is the common narrative. But possibly they aren't and they are quite happy to make a mountain of shit, including doing almost the same thing over and over, for the small chance of a diamond. That's entirely consistent with the rest of the start-up industry.
>> Doing that once, yeah, doing that over and over, no so much.
> What do you mean? It's always good move to kill a product that loses money for the company.
Look at the Ars Technica article I was responding to. Google has failed at chat apps repeatedly for a long time, to the point where it's an embarrassment AND they've created a self-reinforcing vicious cycle of failure. The smart decision for users is to avoid any Google chat app like the plague, because it will inevitably be killed, which means those apps will also fail for lack of users.
A business doesn't have infinite tries to get something right. Eventually they burn up all their credibility. They should kill them all, and stop developing new ones, completely exiting the space.
> What do you mean? It's always good move to kill a product that loses money for the company.
Look at the Ars Technica article I was responding to. Google has failed at chat apps repeatedly for a long time, to the point where it's an embarrassment AND they've created a self-reinforcing vicious cycle of failure. The smart decision for users is to avoid any Google chat app like the plague, because it will inevitably be killed, which means those apps will also fail for lack of users.
A business doesn't have infinite tries to get something right. Eventually they burn up all their credibility. They should kill them all, and stop developing new ones, completely exiting the space.
I know they have repeatedly scrapped them and repeatedly made new ones. That's the whole basis for the discussion we're having.
The question is what their strategy is. Obviously they know this too. The idea that nerds on HN know what is best for the company's brand or reputation is dubious at best. Google is (allegedly) one of the most valuable brands in the world, and more trustworthy than Microsoft or Apple or Amazon (https://www.zdnet.com/article/facebook-tiktok-least-trusted-...).
Sure us supernerds will guffaw and chortle into our neckbeards to one another and deride Google for killing lots of things, but how much does that actually hurt their bottom line or brand value?
The question is what their strategy is. Obviously they know this too. The idea that nerds on HN know what is best for the company's brand or reputation is dubious at best. Google is (allegedly) one of the most valuable brands in the world, and more trustworthy than Microsoft or Apple or Amazon (https://www.zdnet.com/article/facebook-tiktok-least-trusted-...).
Sure us supernerds will guffaw and chortle into our neckbeards to one another and deride Google for killing lots of things, but how much does that actually hurt their bottom line or brand value?
Wow! This really does cover everything. I just wrote a comment saying Disco is never brought up. It is here.
There's Google Chat, which is really made for companies but available on normal accounts too, and Google Messages, their SMS/MMS/RCS app for Android, which requires that you have an Android phone and a phone plan.
Also Hangouts, Meet, Duo, Allo, Spaces. I don't even know if all of them are alive now, and I don't care enough to check.
Hangouts is just another client for Google Chat now, Allo is dead, and Spaces is a feature of Google Chat. Meet and Duo are not chat apps really, but there is a pretty clear separation in that Meet is primarily designed for business meetings (competes with Zoom) and Duo is more primarily for personal use (competes with FaceTime)
> Spaces is a feature of Google Chat.
This is true today, but 3-4 years ago Spaces was actually a completely separate product that was so bad that most Googlers didn't even know it existed.
I have never met a single person, including on the Spaces team, that used Spaces for anything. Ever.
This is true today, but 3-4 years ago Spaces was actually a completely separate product that was so bad that most Googlers didn't even know it existed.
I have never met a single person, including on the Spaces team, that used Spaces for anything. Ever.
Disco is forgotten usually. From the early smartphone days before Whatsapp and others had firmly won. I believe they even owned Disco.com. I had that app installed way back when.
I'm pretty sure there was a Google+ chat, and who remembers Google Talk?
And Wave, whatever that was?
It was Slack/etc years before those existed. They just couldn't figure out how to market it because there were no reference points at the time, so few could see any reason to use it.
I doubt it's just that. If those things were actually great, people would have embraced them like they did slack.
Consider Google+ also. They had plenty of reference points for that. It was just not very good.
Google tends to abandon development on new projects way too quickly, before they're ready for mass appeal. They probably expect it to explode like Gmail did. But I think they forget they lost a lot of promotors like us when they abandoned the don't be evil thing.
At the time I recommended Gmail to everyone, now I try to get people away from Google :)
Consider Google+ also. They had plenty of reference points for that. It was just not very good.
Google tends to abandon development on new projects way too quickly, before they're ready for mass appeal. They probably expect it to explode like Gmail did. But I think they forget they lost a lot of promotors like us when they abandoned the don't be evil thing.
At the time I recommended Gmail to everyone, now I try to get people away from Google :)
Before Slack there was Flowdock (which was never as popular) and I'm pretty sure another I'm forgetting from back then. I used Slack as probably the best-known example.
"We couldn't figure out how to market it" was from an interview straight from the people who made it: The companies they pitched to responded with things like "why would we need this, we have email".
"We couldn't figure out how to market it" was from an interview straight from the people who made it: The companies they pitched to responded with things like "why would we need this, we have email".
Loved Wave, thought it was terrible that it got shelved
Buzz
To be even more confusing, it’s also possible to chat and video conference with the Gmail app. But maybe this changes tomorrow who knows?
They removed the ability to install the dedicated chat app and moved it all into the Gmail app. Infuriating. Oh, and it opens all links on the built-in chrome browser instead of respecting your default browser settings. There is no option to change the behavior.
> They removed the ability to install the dedicated chat app and moved it all into the Gmail app.
The first part of it is not true (but the second part is true, in that you can access chats from Gmail as well).
I just checked, and Google Chat exists as a separate app on iOS, Android, and web (chat.google.com). Even though the web version redirects to a gmail url (mail.google.com/chat), it is still a separate web version, not embedded into gmail. The only thing it shares with gmail is its subdomain, the page itself has zero mention of gmail or any gmail-related functionality.
The first part of it is not true (but the second part is true, in that you can access chats from Gmail as well).
I just checked, and Google Chat exists as a separate app on iOS, Android, and web (chat.google.com). Even though the web version redirects to a gmail url (mail.google.com/chat), it is still a separate web version, not embedded into gmail. The only thing it shares with gmail is its subdomain, the page itself has zero mention of gmail or any gmail-related functionality.
>I just checked, and Google Chat exists as a separate app on iOS
I used to have this app installed, then one day it started telling me I had to use the GMail app for chat instead.
I wouldn't be surprised to hear that they were rolling the out the migration to accounts incrementally, or they've reversed course. But I deleted the google chat app because it wouldn't let me use google chat.
I used to have this app installed, then one day it started telling me I had to use the GMail app for chat instead.
I wouldn't be surprised to hear that they were rolling the out the migration to accounts incrementally, or they've reversed course. But I deleted the google chat app because it wouldn't let me use google chat.
The separate chat app still exists (at least on Android). I have it, because I often like to copy and paste between them.
I used Allo for some time. It's long gone now.
Not to be confused with Chat, which is inside the Google Messages app, which is RCS.
That's actually "Chat Features"
I think I may make an independent thread about this soon (but my question may be stupid): why does messages use this paradigm of connecting to one's phone directly instead of accessing texts in some centralized fashion? Is that impossible because only the carrier has the contents of the thread (even though other services can be used to post texts)?
The surveillance state likes it that way.
> I don't even know what to call it anymore.
Google.
Google.
I generally agree but I really dislike that site. Change is inevitable, as is progress.
Angular 2010-2021? Seriously? Angular was simply superseeded after 11 years by better technology, and same goes for a lot of other projects and services on that site.
I’m not a Google fanboy and I know about the few instances where they screwed over users by turning stuff off but cmon now.
Angular 2010-2021? Seriously? Angular was simply superseeded after 11 years by better technology, and same goes for a lot of other projects and services on that site.
I’m not a Google fanboy and I know about the few instances where they screwed over users by turning stuff off but cmon now.
Times have changed in many more ways than one.
These days I greatly prefer to own my data more directly, which I accomplish using a NAS. I don’t use Dropbox OR Google Drive, I use Syncthing, which can do stuff that neither of those could ever dream of in terms of syncing between machines.
Not only do I not want Google Drive, I don’t even want anything like it.
That said, I totally get why it’s still important. I do use Google Drive at work and for that type of use case I would not argue in favor of self-hosting. Syncthing is great for a single person or even a fairly large group of people, but not for a big organization. Not to mention you probably use Google Docs or Office 365 anyways, both of which are integrated with their respective company’s storage offerings. Syncthing won’t give you directory sync, docs integration, or granular ACLs.
But that’s actually perfectly fine, because I don’t need any of those things. Hell, I flat out don’t really want them. You could probably get something similar with ownCloud which I did try running, and I’m not even particularly enticed. I’m sure Synology has a full suite as well, but it’s not what I want out of my NAS. Part of being happier with my technology was just as much realizing what I didn’t want as it was realizing what I wanted.
These days I greatly prefer to own my data more directly, which I accomplish using a NAS. I don’t use Dropbox OR Google Drive, I use Syncthing, which can do stuff that neither of those could ever dream of in terms of syncing between machines.
Not only do I not want Google Drive, I don’t even want anything like it.
That said, I totally get why it’s still important. I do use Google Drive at work and for that type of use case I would not argue in favor of self-hosting. Syncthing is great for a single person or even a fairly large group of people, but not for a big organization. Not to mention you probably use Google Docs or Office 365 anyways, both of which are integrated with their respective company’s storage offerings. Syncthing won’t give you directory sync, docs integration, or granular ACLs.
But that’s actually perfectly fine, because I don’t need any of those things. Hell, I flat out don’t really want them. You could probably get something similar with ownCloud which I did try running, and I’m not even particularly enticed. I’m sure Synology has a full suite as well, but it’s not what I want out of my NAS. Part of being happier with my technology was just as much realizing what I didn’t want as it was realizing what I wanted.
I've been very happy with self-hosting a Seafile instance to serve as a personal cloud for myself and a small academic ML team. I built a small NAS, Proxmox runs on baremetal, on top of which there's an ubuntu VM running a Seafile docker instance. Fantastic performance, so so much more efficient for syncing large libraries b/w machines. Owncloud/Nextcloud was a pig for my purposes, it seemed unable to sync libraries w/ large number of files (2million+). IIRC Seafile sync client is C under the hood, and is much more performant than any other sync client I've tried. OneDrive was completely unable to upload the amt of data that I needed, and I was tired of manually splitting my datasets into chunks, only to have to stitch them back together on the shitty WebUI. Feel free to hit me with any questions if anyone is thinking of setting up a Seafile instance. I've found their 'community edition' free release to be more than sufficient for our team.
Oh yeah, most importantly-- Linux is treated as a 1st class citizen, the sync clients are equally performant b/w platforms in my experience. In contrast to Nextcloud, Seafile is really good at one thing-- file sync&share-- and the Web UI is intuitive & full-featured for users & admin alike.
The last time I used Seafile, it was very slow, and it was more of a pain to get and keep running than it was worth, though I was using the free version instead of the paid version.
The problem with seafile I had was if I tried to sync down files and the sync client stopped, it would have no problem uploading the incomplete downloads as changes to the server, as well as pushing missing as deletes to the server.
I didn't lose any data over it, thank god, but I moved away from that.
The moral of the story is sync is a hard problem. And corner cases need to be tested before you rely upon any sync service for your data.
The problem with seafile I had was if I tried to sync down files and the sync client stopped, it would have no problem uploading the incomplete downloads as changes to the server, as well as pushing missing as deletes to the server.
I didn't lose any data over it, thank god, but I moved away from that.
The moral of the story is sync is a hard problem. And corner cases need to be tested before you rely upon any sync service for your data.
> The problem with seafile I had was if I tried to sync down files and the sync client stopped, it would have no problem uploading the incomplete downloads as changes to the server, as well as pushing missing as deletes to the server.
this surely does not seem like a 'corner case' and would be absolutely terrifying if true.
could you be more specific in regards to the circumstances?
this surely does not seem like a 'corner case' and would be absolutely terrifying if true.
could you be more specific in regards to the circumstances?
Why are you running Seafile in Docker, and not directly in Ubuntu?
Why are you running Ubuntu in Proxmox, and not directly on the metal?
Thank you! I might set up a NAS in the very near future.
Why are you running Ubuntu in Proxmox, and not directly on the metal?
Thank you! I might set up a NAS in the very near future.
container/vm makes for easier deployment and management, seldom technical reasons.
I’m curious, what do you use to access files on your NAS? I’ve used Samba for forever but it’s always been kind of annoying to deal with permissions, and whilst running AD would probably solve that, I then have to deal with running AD. I’m tempted to try switching to NFS instead.
Samba. I tried AD very briefly before realizing how absolutely terrible of an idea it was. It just makes life so complicated, and AD integration was not as good as I was hoping. I can see why this market constantly has all kinds of crazy offerings…
As far as permissions go, I guess I am mostly ignoring granular permissions. I’m generally only concerned with permissions on a per-share basis. This way, file permissions mostly don’t matter and can be a one-and-done affair. Then, I can split files up into separate shares.
NFS also seemed appealing, but honestly it does seem to bring a lot of complexity that SMB/CIFS does not, and everything supports the latter well enough for my use cases.
Remote access is another issue, since you should probably not do SMB over the internet, but I guess that can be solved with Tailscale or ZeroTier.
As far as permissions go, I guess I am mostly ignoring granular permissions. I’m generally only concerned with permissions on a per-share basis. This way, file permissions mostly don’t matter and can be a one-and-done affair. Then, I can split files up into separate shares.
NFS also seemed appealing, but honestly it does seem to bring a lot of complexity that SMB/CIFS does not, and everything supports the latter well enough for my use cases.
Remote access is another issue, since you should probably not do SMB over the internet, but I guess that can be solved with Tailscale or ZeroTier.
SMB3 is secure over the internet. But you really have to make sure it is an encrypted connection. In Samba you do this by adding:
server min protocol = SMB3 smb encrypt = required
to the [global] section of your smb.conf.
server min protocol = SMB3 smb encrypt = required
to the [global] section of your smb.conf.
Honestly, I don’t mind a VPN moat on top of even that, but it’s definitely a good tip. Any unencrypted data over a VPN is a liability anyways.
That said: for the moment, I still have some SMB1 clients inside my network. Yes, this is terrible, and frankly it is surprising Samba still supports it (I won’t be too surprised or too angry if it gets removed now that it’s separated out.) I should probably segregate SMB1 clients onto a different fileserver on a different VLAN or something. Until then, it would be annoying to force SMB3 on all clients.
(As for why Anybody would use SMB1, the answer is retro computing. I also suspect that Open PS2 Loader is an SMB1 client, though I have not checked.)
That said: for the moment, I still have some SMB1 clients inside my network. Yes, this is terrible, and frankly it is surprising Samba still supports it (I won’t be too surprised or too angry if it gets removed now that it’s separated out.) I should probably segregate SMB1 clients onto a different fileserver on a different VLAN or something. Until then, it would be annoying to force SMB3 on all clients.
(As for why Anybody would use SMB1, the answer is retro computing. I also suspect that Open PS2 Loader is an SMB1 client, though I have not checked.)
We just (a week or so ago) added the ability to remove it. You can now configure samba with:
--without-smb1-server
and the SMB1 code is no longer compiled into the binary :-).
--without-smb1-server
and the SMB1 code is no longer compiled into the binary :-).
My NAS of 6 years just crapped out on me a couple days ago. Probably just the power supply, but my suggestion is to get 2 NASes in RAID6 and mirror data between them if you can.
raid5/6 are traps because they increase complexity by a unreasonable ammount (and recovery workload).
just use raid1 if you are not in a position to write an academic paper on the differences.
just use raid1 if you are not in a position to write an academic paper on the differences.
Worth noting that it's not actually "Google" that said to "hang tight". An entire brand does not make a decision like whether to support Linux. It's a two-pizza team with a shitty budget and a remit to just keep the damn thing from going down and working out all the bugs with basic features like moving a file to a new folder in a weird drop-down.
I'm sure the team would like to support Linux, if they had a bigger budget, if they could get out from all of their tech debt, if they had one or two specialized engineers added to their team. But the giant corporate behemoth isn't even remotely aware of those problems, nor will it care. There would have to be a clear case that adding a Linux client would create real business value. But considering how small Linux users probably are, and without an additional revenue stream to offset the cost of development, it's a non-starter.
I'm sure the team would like to support Linux, if they had a bigger budget, if they could get out from all of their tech debt, if they had one or two specialized engineers added to their team. But the giant corporate behemoth isn't even remotely aware of those problems, nor will it care. There would have to be a clear case that adding a Linux client would create real business value. But considering how small Linux users probably are, and without an additional revenue stream to offset the cost of development, it's a non-starter.
I get what you're saying, but:
- The specific actions of a company will _always_ come from a specific subset of people who are interacting with and sometimes constrained by the broader organization. Should this mean that we can never talk coherently about the actions or statements of a company?
- Isn't the company overall responsible for creating the organizational constraints and obstacles? Why is that team that size? Why is that their remit, and how has it changed since _someone_ decided to say "hang tight"? Why do they have the staff they have?
- The specific actions of a company will _always_ come from a specific subset of people who are interacting with and sometimes constrained by the broader organization. Should this mean that we can never talk coherently about the actions or statements of a company?
- Isn't the company overall responsible for creating the organizational constraints and obstacles? Why is that team that size? Why is that their remit, and how has it changed since _someone_ decided to say "hang tight"? Why do they have the staff they have?
I get what you're saying, but ultimately it is an issue of priority. Google has the money, they just don't choose to spend it on supporting Google Drive on Linux, even after saying they would. So, supporting Linux is by definition a lower priority than anything that did pass the bar for resource allocation in the last ten years.
You're right about the motivations: they must not view it as creating real business value, since that's how these decisions get made.
My only point here is that it IS a choice someone in an office is making: it's not worth it to support Drive on Linux. They do know about it, because it was on their radar 10 years ago. Somebody took it off their radar.
You're right about the motivations: they must not view it as creating real business value, since that's how these decisions get made.
My only point here is that it IS a choice someone in an office is making: it's not worth it to support Drive on Linux. They do know about it, because it was on their radar 10 years ago. Somebody took it off their radar.
The team who made the post were representing Google, therefor the company made the post.
To propose otherwise implies that all similar actions/statements made in a similar way are not made by the company, which is both ludicrous and also causes Google to not exist.
To propose otherwise implies that all similar actions/statements made in a similar way are not made by the company, which is both ludicrous and also causes Google to not exist.
[deleted]
That's why you need to use your best judgement to determine if a random employee at a company has the knowledge/power/clout to act as an official spokesperson before believing what they say...
I don't know how many M$/yr Google engineers cost, but there is at least one small software company out there (InSync) that built a multiplatform Google Drive client which, personally, has been working great for years, even on Linux (I'm just a user), for likely less than that.
Maybe they could ship a linux app instead of deprecating and replacing the mac app next time :)
Though Linux might be a small platform it's the only one that really matters.
It apparently does not, since lack of Linux support hasn't killed the product.
> it's the only one that really matters
Demonstrably not.
Demonstrably not.
The thinking was probably more along the lines of "no one ever got promoted for filling out the basic feature set of a file share me too service" and that promotion is what's standing between them and an extra 9000 pizzas a year worth of salary. With a bonus hint of "nobody cares what somebody promised that left the team a year ago after a year of working on it".
[deleted]
Related
How long since Google said a Google Drive Linux client is coming? - https://news.ycombinator.com/item?id=24183399 - Aug 2020 (109 comments)
How long since Google said a Google Drive Linux client is coming? - https://news.ycombinator.com/item?id=9434643 - April 2015 (59 comments)
How long since Google said a Google Drive Linux client is coming? - https://news.ycombinator.com/item?id=24183399 - Aug 2020 (109 comments)
How long since Google said a Google Drive Linux client is coming? - https://news.ycombinator.com/item?id=9434643 - April 2015 (59 comments)
I just want to collect the major options for Google Drive on Linux in a single comment, since a few options are scattered around:
Insync works well, and it's 50% off for a couple more days: https://www.insynchq.com/ Not affiliated, but $15 is not a lot to pay, as opposed to waiting for something that probably won't happen.
Rclone has support for Google Drive, and it's open source: https://rclone.org/
There's a command line client that uses a push/pull workflow: https://github.com/odeke-em/drive It was written by a member of the Google Drive team.
Gnome supports Google Drive, or at least used to, directly in Nautilus. I don't use Gnome, so I can't comment.
There may be other options I've missed, but the point is that there is already good support in multiple forms. I'd be interested to know what support Google could provide that's not already available.
Insync works well, and it's 50% off for a couple more days: https://www.insynchq.com/ Not affiliated, but $15 is not a lot to pay, as opposed to waiting for something that probably won't happen.
Rclone has support for Google Drive, and it's open source: https://rclone.org/
There's a command line client that uses a push/pull workflow: https://github.com/odeke-em/drive It was written by a member of the Google Drive team.
Gnome supports Google Drive, or at least used to, directly in Nautilus. I don't use Gnome, so I can't comment.
There may be other options I've missed, but the point is that there is already good support in multiple forms. I'd be interested to know what support Google could provide that's not already available.
> Gnome supports Google Drive, or at least used to, directly in Nautilus. I don't use Gnome, so I can't comment.
I'm using it right now. It is not particularly responsive (perform an operation and it looks like no operation is happening until the remote end responds) but works well enough for copying files in and out via nautilus if you don't expect instant feedback.
I'm using it right now. It is not particularly responsive (perform an operation and it looks like no operation is happening until the remote end responds) but works well enough for copying files in and out via nautilus if you don't expect instant feedback.
No mention of https://rclone.org/drive yet in case anyone is unaware.
I don't see how 1st party could do any better than the handful of 3rd party options.
I don't see how 1st party could do any better than the handful of 3rd party options.
I connected my Linux systems to my Nextcloud server, and then I connected my Gdrive as external storage in Nextcloud. When I turned on server side encryption in Nextcloud it also encrypted my connected storage of Gdrive. So I accomplished both Gdrive integration as well as file encryption at the same time.
Maybe I'm doing something wrong, but nextcloud constantly somehow manages to corrupt data it is storing locally. Its only user is an android backup agent.
Is there something that's, say, 1% as complicated as nextcloud that can sync multiple devices without giving a cloud provider access to cleartext (while also keeping an encrypted backup in the cloud)?
Is there something that's, say, 1% as complicated as nextcloud that can sync multiple devices without giving a cloud provider access to cleartext (while also keeping an encrypted backup in the cloud)?
Syncthing?
Does this mean you're storing a backup of your NextCloud as a large encrypted blob in your gdrive?
> I connected my Gdrive as external storage in Nextcloud.
This bit sounds interesting, could you explain it a little more, how you managed it?
This bit sounds interesting, could you explain it a little more, how you managed it?
I have since just moved everything into my Nextcloud server since it does everything I need and keeps my data totally private. It is on a Raspberry PI running Yunohost, and I can add additional drives as needed. I don't remember all I did when I setup the Gdrive, but I recommend checking the official documentation at https://docs.nextcloud.com/server/latest/admin_manual/config...
As the decision seems to be deliberate, I'm interested why Google has chosen not to implement such a feature. I'm a paying GSuite customer. I'd love to be able to NFS-mount portions of my home directory into Google Drive for access across platforms and sharing/collaboration with others.
There's got to be a reason that Google Drive isn't interested in implementing linux mounts -- I'd be surprised if it is market share alone. The reason may be interesting/unexpected.
There's got to be a reason that Google Drive isn't interested in implementing linux mounts -- I'd be surprised if it is market share alone. The reason may be interesting/unexpected.
It's market share, but I suspect Google's numbers may be skewed here by their measurement system. They almost certainly have hard numbers on the percent of users accessing the UI via various platform configs, and the Linux numbers are low. Question is if that's because they haven't cracked into the market because they aren't offering desktop integration.
The other interesting question is: what are Linux users using instead? Because that's Google's competition for this software, which implies how much they could make competing.
The other interesting question is: what are Linux users using instead? Because that's Google's competition for this software, which implies how much they could make competing.
My experience is that data-driven companies get into self-reinforcing circles:
- Data shows not a lot of customers use Linux
- Which leads to poor Linux support
- Which leads to not a lot of customers using Linux
That's not specific to this either. I've seen companies discount continents of people due to lack of customers on those continents, which was often due to inanely easy-to-solve problems. But if you only have 0.1% of your market in China, why bother with servers which are inside the Great Firewall? If 0.1% of your population is Spanish-speaking, why bother with i18n?
Data driven companies have an inherent bias towards /current/ customers, and away from /potential/ customers....
- Data shows not a lot of customers use Linux
- Which leads to poor Linux support
- Which leads to not a lot of customers using Linux
That's not specific to this either. I've seen companies discount continents of people due to lack of customers on those continents, which was often due to inanely easy-to-solve problems. But if you only have 0.1% of your market in China, why bother with servers which are inside the Great Firewall? If 0.1% of your population is Spanish-speaking, why bother with i18n?
Data driven companies have an inherent bias towards /current/ customers, and away from /potential/ customers....
Isn’t there some saying about analysts and how they often tell you what’s already the case, but almost never tell you what’s possible? I feel like that applies here.
Lack of Drive integration was what kicked me to finally self-host a Seafile instance.
There's always the excellent unofficial google-drive-ocamlfuse which uses FUSE to mount Google drive to a local directory.
https://github.com/astrada/google-drive-ocamlfuse
https://github.com/astrada/google-drive-ocamlfuse
Over ten years ago it was already obvious that Google wasn't a reliable or useful company. You're gonna be waiting a LOOOONG time.
GPL should add a clause: "If you're a large enterprise making money off of Linux and provide services/products to Windows and Mac users but not the exact same to Linux users; your enterprise is no longer authorized to use or run Linux in any capacity.".
The FSF will almost certainly never do that, and even if they did, Linux isn't licensed under "GPLv2 or Later." It's just under GPLv2, probably forever.
Linux could change it if every single copyright holder consented, but that's even less likely than the FSF adding a field of endeavor restriction to the GPL. Google owns partial copyright to Linux. Other copyright holders are gone, and nobody knows who the heir is.
Linux could change it if every single copyright holder consented, but that's even less likely than the FSF adding a field of endeavor restriction to the GPL. Google owns partial copyright to Linux. Other copyright holders are gone, and nobody knows who the heir is.
I am clueless about these licensing matters. How does Google own partial copyright to Linux? I thought Linux is something independent.
Each contributor to Linux retains the copyright to their contributions.
Google is a pretty big Linux contributor.
Google is a pretty big Linux contributor.
Meh. Google. Google really hasn't come out with anything innovative in quite awhile, while killing once innovative projects.
Those were the quaint times when we still believed that Google was awesome and cool, and doing amazing things.
Now, it's a "our project is already dead", automated banning hellscape, where the only assistance is from other yet-to-be-AI-killed fellow user attempt to barely help. Or gods forbid, find someone here for a "social media escalation".
I used to care. I gave up caring WRT google ages ago. They are not worth the trouble.
Now, it's a "our project is already dead", automated banning hellscape, where the only assistance is from other yet-to-be-AI-killed fellow user attempt to barely help. Or gods forbid, find someone here for a "social media escalation".
I used to care. I gave up caring WRT google ages ago. They are not worth the trouble.
https://issuetracker.google.com/issues/35904387 ipv6 support in GCP is similar, it's at 9 years now.
Websockets still not generally available, ticket opened in 2009 https://issuetracker.google.com/issues/35886348
There's really no reason to use AppEngine these days. I believe it still exists for legacy apps. You should be using Cloud run. Cloud run support WebSockets[1].
If you already have an AppEngine App you can always keep it and create a CloudRun app to handle the WebSocket part and they communicate well.
[1]: https://cloud.google.com/run/docs/triggering/websockets
If you already have an AppEngine App you can always keep it and create a CloudRun app to handle the WebSocket part and they communicate well.
[1]: https://cloud.google.com/run/docs/triggering/websockets
What's it supposed to do? Aren't "rclone mount" and the OS file manager sufficient?
... exactly what I was thinking. Discovering rclone mount finally let me abandon the file sync paradigm and return to my workflows of yesteryear when NFS was still the dominant file sharing system on Unix.
https://www.insynchq.com/ solved that long time ago. I even use them as preferred client on my mac for years because Google's client is pretty bad in my opinion.
And happy that there is software from Filipino developers and software out there!
And happy that there is software from Filipino developers and software out there!
There’s a pretty good FUSE driver and the web app is fine. Never felt the need for a Linux client for this service. Two decades of Linux use and the thing that has changed everything has been the arrival of electron which has made practically everything cross-platform.
If something uses electron, I'll look for a native alternative.
Ripcord doesn't have the best UI and I can't open Teams calls or even links that are too long (Slack broke their API at some point) but at least it's not wasting my ram and it's responds quickly. The rare times I have to open Slack on the web I sigh and wait 2 minutes for the app to load.
I automated Prituln VPN via bash just not to have to deal with another Electron client for a damn popup on my tray bar.
Ripcord doesn't have the best UI and I can't open Teams calls or even links that are too long (Slack broke their API at some point) but at least it's not wasting my ram and it's responds quickly. The rare times I have to open Slack on the web I sigh and wait 2 minutes for the app to load.
I automated Prituln VPN via bash just not to have to deal with another Electron client for a damn popup on my tray bar.
If it takes two minutes to open slack in your Web browser then your Web connection might be the problem. Or is your computer from the 90s?
I don’t think average users even use the Google Drive desktop client.
Do Google use Google Drive on Linux internally? Isn't Linux used a lot there?
They can mount GDriveFS internally as NFS, I think
Not really. I mean, drive stuff is used here and there to share some docs/attachments, etc. but not via a mounted filesystem, just from web browser.
There's a Google-wide shared file system that is mounted on all gLinux workstations, but it has nothing to do with Google Drive.
There's a Google-wide shared file system that is mounted on all gLinux workstations, but it has nothing to do with Google Drive.
To be honest I like, forgot this -- attaching/syncing Drive and the local disk -- was a thing people did.
I just like, upload and download files as needed to Drive? I don't really have a huge "need to sync files to the cloud" quadrant in my personal or professional life.
I just like, upload and download files as needed to Drive? I don't really have a huge "need to sync files to the cloud" quadrant in my personal or professional life.
GNU/Linux users are mostly a bit tech-savvy users, big of IT like dumb users, they are easy to profit from, very moderately tech-savvy ones are just needed to pull more people in so offering a bit of services with a good enough quality and something to make the experience nice enough for a tech-savvy user (like YT or Google Search with a certain set of extensions to cut ads etc) is enough to have thous users recommend those services to their less tech savvy friends and the world of mouth do the magic. More than that might be even counter-productive if show a real tangible far lower quality to the aforementioned users like most single-company show software are: crappy and outdated.
Alphabet do want data from the masses, not much from a small cohort of smart users. Invest for them is not interesting.
Alphabet do want data from the masses, not much from a small cohort of smart users. Invest for them is not interesting.
Link to the Google product forum on the target page is broken, so this is not informative at all.
Yeah, I'm confused why no one else is discussing this. Who even said to hang tight? Was it someone on a Drive team? Was it a trusted community member? Was it just a optimistic Linux fanatic?
There is missing context.
There is missing context.
Yeah, looks like they broke the groups page, which was 'migrated' from an original Plus page at https://plus.google.com/u/0/+ChadMcCullough/posts/SxDNKR7ehS...
Thanks Insync I could survive without their support.
Wait, doesn’t this work? I had a weird experience where pop_OS! automatically mapped my google drive to nautilus once I had logged in.
I’m sure that it’s not native, but what features would I be missing? I was very pleasantly surprised when it just kinda worked.
I’m sure that it’s not native, but what features would I be missing? I was very pleasantly surprised when it just kinda worked.
That support comes from Gnome Online Accounts.
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Provider...
Last time I tried it, that only supported the virtual drive thing, so no actual files locally.
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Provider...
Last time I tried it, that only supported the virtual drive thing, so no actual files locally.
We use Google drive at my corporate, and half the devs are on Linux. I wonder if this space was more competitive if Google would feel more urgency. A part of the issue is we use Google for calendar and email as well.
I've been using Insync for a few years now, works flawlessly.
Google is a me too company now. Innovation left the company a long time ago. That is why I tell startups I invest in, not to worry at all if Google enters their space.
encryptluks2(2)
I have been using InSync for Google Drive for the past 4 years. Been pretty happy with the performance. There is only one catch with their personal license: you can only use it for the account you bought it for. Changing account implies buying another license. You can't sign on more than one Google account as your main account - although they have some child account configuration & you could use it on as many computers you want.
Does anyone know why Linux/OSS devs haven't built this themselves yet? I am looking at the api and it seems to have all the necessary bits for filesystem syncing but maybe there's something I'm missing. https://developers.google.com/drive/api/guides/manage-upload...
You will never show impact for the purposes of a promotion with this feature, therefore no one will work on it. That's how anything is being driven at Google now.
Look at Nest. Barely any useful new features at all in years. They could easily add more useful features like car detection, etc, but it hasn't changed in several years now. Google has become a graveyard where ideas go to die because no one cares there.
Look at Nest. Barely any useful new features at all in years. They could easily add more useful features like car detection, etc, but it hasn't changed in several years now. Google has become a graveyard where ideas go to die because no one cares there.
FUSE with S3 is awesome. I have a few local mounts, including using it as my Git upstream, and it Just Works(tm)
Don't say "Google Drive" out loud or they'll cancel the whole thing.
Would the ChromeOS implementation work if they packaged it, and if not, why not?
I’m glad that Dropbox provides a Linux client, although it is annoying that it is limited to x86 and ext4. At least the latter can be worked around with a loopback device.
Dropbox works on zfs, xfs and btrfs just fine.
Source: https://help.dropbox.com/installs-integrations/desktop/syste...
Source: https://help.dropbox.com/installs-integrations/desktop/syste...
Check https://news.ycombinator.com/item?id=20498454
Dropbox did drop support and bring it back.
I use Linux with xfs, so I switched off Dropbox. Even though Dropbox went back on this decision, they did some damage, and probably lost people that haven't come back (like me).
Thanks, I hadn’t been aware that they relaxed the requirements. In my case it doesn’t help me though, as the VPS I’m using is still on ext3.
Well... There's a lot of good alternatives so I - personally - don't miss it!!!
But I understand the frustration and that some people do miss it...
But I understand the frustration and that some people do miss it...
Is there a similar site tracking how long it has been since Steve Jobs said Facetime would become an open standard?
I wish google drive worked on the Mac! At least once a day it decides it can’t work and tells my to unmount it.
The OP no longer seems to succesfuly link to any communication from Google saying to "hang tight".
I use pop os and just by login with my google account it's show my drive in the file explorer
Don't worry - Google Drive does support Linux. Just only on for the server, not the client :D
Google Drive does support Linux with the completely open source DriveFS and supporting userspace services like Seneschal in the ChromiumOS project. People who claim otherwise don't believe in actual open source software development, they just want a convenient quasi-commercial software package that doesn't cost them anything.
> they just want a convenient quasi-commercial software package that doesn't cost them anything.
Wouldn't I be paying for gdrive and thus expect to get working software? The free tier isn't enough for me and I would have paid if they had a linux client.
Its okay if they don't think linux is worth it, but your argument that i should pay for the software again seems really weird to me.
Wouldn't I be paying for gdrive and thus expect to get working software? The free tier isn't enough for me and I would have paid if they had a linux client.
Its okay if they don't think linux is worth it, but your argument that i should pay for the software again seems really weird to me.
Again:
Google writes, maintains, distributes, and supports a working Drive client for Linux, called DriveFS.
Google writes, maintains, distributes, and supports a working Drive client for Linux, called DriveFS.
This?
https://github.com/thejinx0r/DriveFS
It is the top hit for "google drivefs source code" on google. "google drivefs" just returns hits about clearing a cache on macos or something.
The duck duck go results are arguably more relevant, though one is a link to DriveFS.exe, which I don't plan to download.
https://github.com/thejinx0r/DriveFS
It is the top hit for "google drivefs source code" on google. "google drivefs" just returns hits about clearing a cache on macos or something.
The duck duck go results are arguably more relevant, though one is a link to DriveFS.exe, which I don't plan to download.
In Ubuntu if you log in with your Gmail, you can mount the drive to your filesystem.
Google got fat and lazy.
At least they should sponsor someone motivated to write a client for it.
At least they should sponsor someone motivated to write a client for it.
The Drive API is pretty stable. So given that we're talking about Linux, the immediate question that comes to my mind is "why hasn't somebody written it themselves?"
Perhaps Google sees no benefit in building a service in a space where users can self serve making it.
Perhaps Google sees no benefit in building a service in a space where users can self serve making it.
GCS works. For my own use it is just much simpler to use GCS
Right. Don't they have a fuse file system that they actively maintain?
There is some guy there that maintains an ocaml based fuse google-drive client. It works okay. I'm not sure if he volunteers to maintain or is paid. I have moved on to the isync product but the ocaml opensource project is still there and maintained last I checked.
The web app works fine. In fact, it works better than anything OneDrive related for example (which never seems to sync properly).
Chrome and all of Google's services make being in Linux-land way easier...
Chrome and all of Google's services make being in Linux-land way easier...
I suspect that there's a fundamental conflict in semantics somewhere between drive and posix filesystems. Any sort of filesystem wrapper on top of drive would immediately require making annoying compromises, and the trade-off is convenience vs. data safety.
Targeting a locked down OS like Windows or Mac isn't too difficult, because those compromises can be carefully implemented in a way that avoids accidental data corruption but doesn't negatively impact user workflow too much. On a Linux system, there's hundreds if not thousands of configurations that folk would expect a filesystem to work in, and so it's a lot more difficult to strike that balance.
Years ago, I remember a coworker dragged a directory around on his MacBook, and it completely flattened the company's entire drive directory structure.
Targeting a locked down OS like Windows or Mac isn't too difficult, because those compromises can be carefully implemented in a way that avoids accidental data corruption but doesn't negatively impact user workflow too much. On a Linux system, there's hundreds if not thousands of configurations that folk would expect a filesystem to work in, and so it's a lot more difficult to strike that balance.
Years ago, I remember a coworker dragged a directory around on his MacBook, and it completely flattened the company's entire drive directory structure.
Insync works well but it is pay to play
Dropbox support sucks.
[deleted]
[deleted]
Wasn't that around the time Sean Hannity volunteered to get waterboarded?
The market size is not big enough to justify the internal costs of building and maintaining it.
For dev environments, you can workaround it using Windows + Drive filestream + WSL. https://github.com/microsoft/WSL/issues/2999#issuecomment-91...
For dev environments, you can workaround it using Windows + Drive filestream + WSL. https://github.com/microsoft/WSL/issues/2999#issuecomment-91...
When I worked at Google, almost all developer workstations were running Linux. That alone really should be plenty of justification for having such a client. They did not.
Internally is a lot different than externally https://www.statista.com/statistics/218089/global-market-sha...
You’re missing my point.
Your point is a lot of internal developers use Linux so they should make a Linux drive client, my counterpoint is that dedicating engineering resources to building and maintaining such a project is not worth the cost. Management looks at the cost and ROI of developing and maintaining projects, in this case the ROI from having a Linux client that would likely need 5-10 SWEs to maintain is not worth it for them. They have to ensure the client is compatible with multiple flavors of Linux releases, monitor security issues etc it's a big ongoing cost. If more consumers and businesses used Linux, they could justify the cost.
I'm not saying this is the right move, but I'm explaining why this project hasn't been funded.
I'm not saying this is the right move, but I'm explaining why this project hasn't been funded.
If Google made a calculated decision to not implement Drive on Linux, it wasn’t clear to me, nor did I ever hear that in or out of Google.
As a Google employee, you almost never need to store anything on Drive, do you? I'm struggling to think of a "sync my files" workflow where corp Drive would have been the best solution if only there had been a Linux client.
If you needed to share files outside of code or what have you, you would have to use Google Drive. Perhaps not all developers wind up needing this very often. But realistically, for me, the majority of the benefit would’ve been integration. I’m sorry, but browsing files in a web browser absolutely sucks. Even if double clicking a document only opened Google Docs, that would still be a usability win.
At my current workplace I use a FUSE driver to get Google Drive in my file browser and I wouldn’t have it any other way.
At my current workplace I use a FUSE driver to get Google Drive in my file browser and I wouldn’t have it any other way.
As a Google employee using Linux, the kind of files I stored in Drive were rarely useful synced to my filesystem.
To be clear, I would’ve preferred something more like a FUSE implementation, which thankfully exists for someone outside of Google.
There is FileStream or whatever it’s called, but it’s never coming to Linux so who cares.
There is FileStream or whatever it’s called, but it’s never coming to Linux so who cares.