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.
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.
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.
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
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.
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.
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 tried it a little less than 2 months ago across a suite of services, Azure, self hosted, AWS EC2 instances, and all of these same options again with WireGuard over the top (well, with Tailscale in this instance).
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.
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.
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.
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.
> Just give us a web filesystem already. Stop with these shitty infantilized GUIs ... That actually worked ffs. ...
I responded by saying:
> Your level of angst makes me think ...
I suppose I could be wrong about the OP expressing angst, but I think it's reasonable inference.
Also, you wrote:
> Because it's a paid service.
I see two problems here:
(1) I was asking the OP (@titzer) what their reasons were, not yours.
(2) Only some people pay for Google Drive. One reason that I wrote:
> Your level of angst makes me think you believe someone out there is obligated to do this for you.
>
> If you believe that, I'm curious why.
was that if the @titzer was paying for Google Drive, I could see him having a stronger reason for expecting Google to make the product useful to him. But I didn't want to assume, which is why I asked.
Please don't go into how another person is feeling, just read the comment and reply. It will never go well for you if you try to dismiss somebody's comments by focusing on how they are feeling instead of their words.
Google Drive deletes files randomly (whether due to programmatic/storage problems or the documented issue with the algo not liking things and silently deleting them).
Missing block level sync reinforces that it's a toy. What would you do with 100+gb they tout if not having big media files? 10,000 spreadsheets (that might still randomly get deleted)?
If you're observing deleted files, and you don't have any third party applications with access to your Drive, we'd be very interested in hearing from you, we take data integrity issues very seriously.
You can check the activity under any folder and see what issued the deletes. If there are missing files _without_ an entry there, and it doesn't seem to be a rogue integration with the Drive API, feel free to get in touch with me.
Despite my acidulous comment I have only once personally experienced a silent deletion, and it was with a Google Sheet a few years ago.
It was a "Copy of" produced by "make a copy" menu option that ended up deleted, which I confirmed with someone else who also had made a copy the same exact way, who couldnt access theirs either.
Is this expected behavior when the source file is deleted, or is it, as I thought, a bug?
> It was a "Copy of" produced by "make a copy" menu option that ended up deleted, which I confirmed with someone else who also had made a copy the same exact way, who couldnt access theirs either. Is this expected behavior when the source file is deleted, or is it, as I thought, a bug?
Without being able to look at the item in question, I couldn't tell. However, deleting copies when a source file disappears is unexpected and as far as I'm aware there's no mechanism for "dependent" deletes.
Where did you copy the item to? Was it stored in your My Drive?
I see no proof of it doing this. It sounds like it you are saving spreadsheets it may have to do with an extension or third-party app you are using. I've never had an issue with files randomly getting deleted on Google Drive and it would be a much bigger issue if this was common.
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?
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.
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.
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…
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…
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.
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.
> 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.
>> 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.
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?
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.
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)
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.
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 :)
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".
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.
>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 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)?
This is probably the most insightful answer, the system is geared to rewarding creation of the next greatest technology. Sustaining what ever your predecessor did just doesn’t get prizes.
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.
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.
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?
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.
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.)
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.
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.
- 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.
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.
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.
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".
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.
> 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 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)?
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.
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.
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....
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.
If there was one, people wouldn't use it. It's so well supported by open source software like rclone and insync, I feel like it actually works better than it does on my windows machine.
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.
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.
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.
... 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!
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.
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.
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
