Syncthing is everything I used to love about computers(tonsky.me)
tonsky.me
Syncthing is everything I used to love about computers
https://tonsky.me/blog/syncthing/
162 comments
I would argue that the opposite is the case for most people. Commercial software is adapted to the needs of the greatest number of people who will pay for it. If you are an average user, this is you.
Open source, on the other hand, is generally adapted to the needs of whoever wants to do some unpaid work on it. This is why open source text editors are great. The users are the developers. This is also why open source applications (graphics, office, etc) are so horrible. Most developers don't use that stuff, or don't use it enough to put in some free work fixing GIMP. Desktop OS's are somewhere in the middle. Developers use them, but the things that would make an open source OS easy for the common user aren't fixed. As a result, they are generally only used by those who get enjoyment out of fixing their desktop, sort of like a classic car enthusiast who loves to spend a Sunday afternoon in the garage with a wrench.
Open source, on the other hand, is generally adapted to the needs of whoever wants to do some unpaid work on it. This is why open source text editors are great. The users are the developers. This is also why open source applications (graphics, office, etc) are so horrible. Most developers don't use that stuff, or don't use it enough to put in some free work fixing GIMP. Desktop OS's are somewhere in the middle. Developers use them, but the things that would make an open source OS easy for the common user aren't fixed. As a result, they are generally only used by those who get enjoyment out of fixing their desktop, sort of like a classic car enthusiast who loves to spend a Sunday afternoon in the garage with a wrench.
My whole point is that what people pay for changes over time. So, if you invest in a piece of software, then it's very likely going to continue evolving to stay profitable and chase whatever new fads happen to be.
This has been the case with literally every piece of commercial software I've ever used. And a lot of the time the changes either have absolutely no value for me, or they're actually detrimental to my workflow.
And clearly I'm not alone, because every time a major version change happens with popular commercial products a lot of users will complain about it. However, they have no power to do anything since they just have to follow whatever the current trend is, or find a new piece of software to use.
It's also a false dichotomy to claim that software is either commercial or open source. There are plenty of companies making money from open source products. This is a good combination since it provides commercial funding for the project, but also ensures that the users can always fork it if it and move it in a different direction from the original developers.
I also disagree that open source applications are in any ways horrible. GIMP and Libre Office are both excellent piece of software that work perfectly fine. I use GIMP all the time, and I have much easier time getting around it than Photoshop.
Also, would like to hear more about what specifically needs to be fixed on Linux. For example, what deficiencies does Elementary OS have compared to Windows?
This has been the case with literally every piece of commercial software I've ever used. And a lot of the time the changes either have absolutely no value for me, or they're actually detrimental to my workflow.
And clearly I'm not alone, because every time a major version change happens with popular commercial products a lot of users will complain about it. However, they have no power to do anything since they just have to follow whatever the current trend is, or find a new piece of software to use.
It's also a false dichotomy to claim that software is either commercial or open source. There are plenty of companies making money from open source products. This is a good combination since it provides commercial funding for the project, but also ensures that the users can always fork it if it and move it in a different direction from the original developers.
I also disagree that open source applications are in any ways horrible. GIMP and Libre Office are both excellent piece of software that work perfectly fine. I use GIMP all the time, and I have much easier time getting around it than Photoshop.
Also, would like to hear more about what specifically needs to be fixed on Linux. For example, what deficiencies does Elementary OS have compared to Windows?
> what deficiencies does Elementary OS have compared to Windows?
From a regular user's perspective, every answer you'll get boils down to "the bugs aren't in the same places as Windows". Most Open Source/Free software these days is as good or better than its proprietary equivalent.
From a regular user's perspective, every answer you'll get boils down to "the bugs aren't in the same places as Windows". Most Open Source/Free software these days is as good or better than its proprietary equivalent.
I have had this conversation with "most people" a number of times.
"I'm just a regular guy and I want to get my stuff done, but these programs are doing stuff I can't stop."
> Commercial software is adapted to the needs of the greatest number of people who will pay for it
Here's what has happened. Because apple is a hardware manufacturer, their app store makes software a complement.
https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
"A complement is a product that you usually buy together with another product. Gas and cars are complements."
So the price of gas goes down, the sales of cars goes up. and vice versa.
For apple, they can drive the cost of software to zero. In the beginning software couldn't really sell well above 99 cents, and now most software is free.
So now people are used to free stuff. But it is a trick. Free stuff pays for itself with tricky in-app purchases, or tricky sell-your-data. Apple doesn't care, because all the free software is selling gajillions of iphones.
But it would have been much better (for individuals and society) if people made and sold stuff, and if people just paid for stuff and got rid of the trickery.
"I'm just a regular guy and I want to get my stuff done, but these programs are doing stuff I can't stop."
> Commercial software is adapted to the needs of the greatest number of people who will pay for it
Here's what has happened. Because apple is a hardware manufacturer, their app store makes software a complement.
https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
"A complement is a product that you usually buy together with another product. Gas and cars are complements."
So the price of gas goes down, the sales of cars goes up. and vice versa.
For apple, they can drive the cost of software to zero. In the beginning software couldn't really sell well above 99 cents, and now most software is free.
So now people are used to free stuff. But it is a trick. Free stuff pays for itself with tricky in-app purchases, or tricky sell-your-data. Apple doesn't care, because all the free software is selling gajillions of iphones.
But it would have been much better (for individuals and society) if people made and sold stuff, and if people just paid for stuff and got rid of the trickery.
> Open source, on the other hand, is generally adapted to the needs of whoever wants to do some unpaid work on it.
Ironically, even commercial software has headed in the direction of "unpaid work", with its ad-based monetization.
Ironically, even commercial software has headed in the direction of "unpaid work", with its ad-based monetization.
> Commercial software is adapted to the needs of the greatest number of people who will pay for it. If you are an average user, this is you.
That's certainly what their marketing departments are paid to have people think.
That's certainly what their marketing departments are paid to have people think.
i haven't had todo any work on syncthing yet. that thing just works.
> Projects can survive with little or no commercial incentive because they're often developed by the users who themselves benefit from these projects.
That's true, but I want to point out a different dynamic, which is very important as well:
Projects can survive with multiple commercial contributors all active in it at once, and remain useful and not locked down due to a combination of copyleft licensing and companies being willing to share work if it benefits them. The Linux kernel is a prime example of this.
> Evolution of GNOME is a great example of this. There are now many flavors of GNOME all catering to different workflows, and users don't have to compromise their preferred way of doing things to chase how GNOME is evolving.
Zooming out, any user of an OS which uses X for its GUI can choose from a huge number of different window managers without someone coming along and deleting the ones "nobody uses" in the name of "streamlining the offering" or whatever "marketing synergy" or "confluent paradigm" is in vogue this month.
That's true, but I want to point out a different dynamic, which is very important as well:
Projects can survive with multiple commercial contributors all active in it at once, and remain useful and not locked down due to a combination of copyleft licensing and companies being willing to share work if it benefits them. The Linux kernel is a prime example of this.
> Evolution of GNOME is a great example of this. There are now many flavors of GNOME all catering to different workflows, and users don't have to compromise their preferred way of doing things to chase how GNOME is evolving.
Zooming out, any user of an OS which uses X for its GUI can choose from a huge number of different window managers without someone coming along and deleting the ones "nobody uses" in the name of "streamlining the offering" or whatever "marketing synergy" or "confluent paradigm" is in vogue this month.
Open source is great for tech-savvy professionals. Pick what you like, change it if you want, and it will never be taken away from you.
Open source has completely and consistently failed in the consumer market, and its adoption in the enterprise market has been mixed. In those markets users are either not knowledgeable enough or too busy to do the things open source asks of them.
Syncthing is cherry picked as an example in the original article because it's very atypical for open source. For open source it has a superb degree of polish and is quite easy to use.
Still I wonder how it would fare in a professional environment. How do I invite someone to syncthing the way I can with dropbox? How do I integrate it with my corporate management or IAM solution? How do I...? I assume there would be a long tail of weaknesses.
I also wonder what happens if syncthing gets abandoned or needs to undergo some major redesign to cope with some significant change to UI technology, OSes, or platforms. Who will do that?
Don't get me wrong. I like that syncthing exists and even that it lacks those features, but I also realize that it does not address the whole market and probably never will.
Open source as it stands has some fairly significant limits.
BTW the pathology described in this article is also seen in open source projects vying for mindshare, adoption, contributors, sponsorship, etc. It's not specific to commercial software. I do agree that it's more prevalent in commercial software because companies need to find a steady source of revenue, but it's gotten worse in recent years because nobody pays for the most basic core features of software that they want anymore. People only pay for fluff, or pay if they're wrangled into a closed ecosystem and then brought to the point of payment via some kind of dark pattern. You get what you pay for, and people no longer pay for just good software.
Open source has completely and consistently failed in the consumer market, and its adoption in the enterprise market has been mixed. In those markets users are either not knowledgeable enough or too busy to do the things open source asks of them.
Syncthing is cherry picked as an example in the original article because it's very atypical for open source. For open source it has a superb degree of polish and is quite easy to use.
Still I wonder how it would fare in a professional environment. How do I invite someone to syncthing the way I can with dropbox? How do I integrate it with my corporate management or IAM solution? How do I...? I assume there would be a long tail of weaknesses.
I also wonder what happens if syncthing gets abandoned or needs to undergo some major redesign to cope with some significant change to UI technology, OSes, or platforms. Who will do that?
Don't get me wrong. I like that syncthing exists and even that it lacks those features, but I also realize that it does not address the whole market and probably never will.
Open source as it stands has some fairly significant limits.
BTW the pathology described in this article is also seen in open source projects vying for mindshare, adoption, contributors, sponsorship, etc. It's not specific to commercial software. I do agree that it's more prevalent in commercial software because companies need to find a steady source of revenue, but it's gotten worse in recent years because nobody pays for the most basic core features of software that they want anymore. People only pay for fluff, or pay if they're wrangled into a closed ecosystem and then brought to the point of payment via some kind of dark pattern. You get what you pay for, and people no longer pay for just good software.
It's worth noting that open source isn't directly at odds with commercial funding. There are lots of open source products out there like Android, GitLab, Nextcloud, IntelliJ,and many others that are developed commercially, but also have an open source core. I think that's a good model since it ensures that the project has funding for full time development and polish, while also leaving the option for the users to take the source and fork it if the product goes in a direction they don't like. Another approach is open source foundations like Firefox or Linux foundation, and donations funded projects like Mastodon. All of these are solid and polished pieces of software.
If syncthing got abandoned then the source is still going to be there, and if there's a community of users around it then development can be picked up by somebody else. This happens all the time in open source world. I already gave GNOME as an example of a project where the original project went in a directions users didn't agree with, and now there are forks of it with Mate and Cinnamon that went their own way.
Meanwhile, if syncthing was a closed source product and the company went under, that would be the end of it definitively. The users would be hung out to dry, and there would be no possibility to adapt it to new OSes, or platforms. It would just be dead.
And syncthing is clearly meant for use cases where you're sharing files between personal devices. However, Nextcloud is a great answer for professional environment. In fact it's so great that German Federal Administration relies on it https://nextcloud.com/blog/german-federal-administration-rel...
So, I don't actually see any significant limits in open source compared to commercial software. There are some trade offs, but open source has certainly been demonstrated to work well in a very wide variety of environments including enterprise and consumer products.
And the core point here is that open source leaves uses with more options than commercial software. Yes, projects can move in new directions, become abandoned, and so on. However, there is at least the possibility of users being able to keep using the version of the project they like, and that's what's missing with closed source software.
If syncthing got abandoned then the source is still going to be there, and if there's a community of users around it then development can be picked up by somebody else. This happens all the time in open source world. I already gave GNOME as an example of a project where the original project went in a directions users didn't agree with, and now there are forks of it with Mate and Cinnamon that went their own way.
Meanwhile, if syncthing was a closed source product and the company went under, that would be the end of it definitively. The users would be hung out to dry, and there would be no possibility to adapt it to new OSes, or platforms. It would just be dead.
And syncthing is clearly meant for use cases where you're sharing files between personal devices. However, Nextcloud is a great answer for professional environment. In fact it's so great that German Federal Administration relies on it https://nextcloud.com/blog/german-federal-administration-rel...
So, I don't actually see any significant limits in open source compared to commercial software. There are some trade offs, but open source has certainly been demonstrated to work well in a very wide variety of environments including enterprise and consumer products.
And the core point here is that open source leaves uses with more options than commercial software. Yes, projects can move in new directions, become abandoned, and so on. However, there is at least the possibility of users being able to keep using the version of the project they like, and that's what's missing with closed source software.
I fight with this in the industrial automation space where a machine might last for decades but the control software is Windows based and lucky if its supported for 5 years. Maddening. I've had to retrofit machines with new controllers, write new GUI software to talk to lasers via serial protocols, and run various things in VM's on Xp. Then the Dos controlled machine with ISA cards -_-
Though there is no easy answer when it comes to this. How does a manufacturer support software reliably for 10+ years? Meanwhile we have three old machines here with all electromechanical controls. I will still be able to buy relays for them in 50 years. I'll be dead by then.
Though there is no easy answer when it comes to this. How does a manufacturer support software reliably for 10+ years? Meanwhile we have three old machines here with all electromechanical controls. I will still be able to buy relays for them in 50 years. I'll be dead by then.
If your competence and competitive edge is long-lived hardware, why not open source the control software? Are there any downsides to doing this? Perhaps incorporating some binary blobs to hide proprietary IP where / if necessary.
Industrial stuff has traditionally been proprietary and high priced. I suppose the volume is so low they have to charge such high prices for the development. I was once quoted 15,000 USD for a windows based HMI from a laser manufacturer.
Also, to may, "open source" is still a phrase which to them means anything from low quality to "pirated". Seriously, someone thought open source was cracked pirated software.
But the good news is a lot of the protocols and standards are opening up and open source stacks are common now. Many manufactures are also using Linux and even FreeBSD. But their software remains proprietary.
Also, to may, "open source" is still a phrase which to them means anything from low quality to "pirated". Seriously, someone thought open source was cracked pirated software.
But the good news is a lot of the protocols and standards are opening up and open source stacks are common now. Many manufactures are also using Linux and even FreeBSD. But their software remains proprietary.
> I've come to realize that open source is the only type of software worth investing into. No matter how great a commercial piece of software might be, sooner or later it's going to either disappear or change in a way that doesn't suit you.
Otherwise known as Pilgrim's law:
"In the long run, the utility of all non-Free software approaches zero. All non-Free software is a dead end."
Otherwise known as Pilgrim's law:
"In the long run, the utility of all non-Free software approaches zero. All non-Free software is a dead end."
The utility one derives from non-Free software is profit the vendor has not yet captured?
And their incentive is to capture as much of it as possible no matter how large the deadweight losses are; Free Software is a positive-sum game, and, unfortunately, proprietary software increasingly tends towards negative-sum games.
I basically agree, but note that open source software (especially popular projects and complicated codebases) can also change in ways you don't like. You can further mitigate this risk by using simple programs that have reached a "finished" state.
>complicated codebases) can also change in ways you don't like. You can further mitigate this risk by using simple programs that have reached a "finished" state.
That's exactly the kind of thing I'm working on, to be able to do simple 2D GUIs without having to directly depend on the complex depths and uncertain future of any specific GUI library: https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
I often had personal GUIs idea but never implemented them due to not wanting to depend on a particular library. Now that I built this abstraction layer, I'm starting to create GUIs.
I feel like building some software for you that depends on proprietary code, or on code too vast and deep to be easily "kept afloat" on the platforms of the day, is basically enslaving yourself to others, or building your house inside of a prison or on the Titanic.
That's exactly the kind of thing I'm working on, to be able to do simple 2D GUIs without having to directly depend on the complex depths and uncertain future of any specific GUI library: https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
I often had personal GUIs idea but never implemented them due to not wanting to depend on a particular library. Now that I built this abstraction layer, I'm starting to create GUIs.
I feel like building some software for you that depends on proprietary code, or on code too vast and deep to be easily "kept afloat" on the platforms of the day, is basically enslaving yourself to others, or building your house inside of a prison or on the Titanic.
> or building your house ... on the Titanic
Or rather, building your house on a ship, which may or may not sink.
Or rather, building your house on a ship, which may or may not sink.
>but note that open source software (especially popular projects and complicated codebases) can also change in ways you don't like.
that's true, but most OSS gives you the option to fork at that revision.
that's true, but most OSS gives you the option to fork at that revision.
I think it only depends on product and team and has nothing to do with OSS/commertial/corp. Sublime Text is fantastic and closed-source. Inkscape is horrible and open-source. Syncthing is both. Photoshop is neither. Good pieces are here and there, not in OSS only.
> Photoshop is neither.
Clearly, professionals pay money to Adobe for fun.
Clearly, professionals pay money to Adobe for fun.
Lots of people pay for Windows and the Microsoft Office suite, which are even worse than the Adobe software suite.
Entrenchment pays dividends.
Entrenchment pays dividends.
I've been using syncthing for several months now, syncing lots of files (code under active development) between a total of five computers, Linux and MacOS.
It's been fantastic.
It works well, it gets the job done, it doesn't pester you with notifications and upsells. It also doesn't eat all of your CPU/battery by watching changes everywhere, like Dropbox does. And it doesn't try to get at your photos. And other stuff.
I have not run into a single problem with it over the course of several months now, which is impressive.
I am about to sign up and start sponsoring it on a monthly basis — I started doing this recently with open-source software that I rely on. If everybody chipped in, we'd be in a world of great sustainable software, with people able to make a living on developing solutions like this.
BTW, a plug for another similarly impressive piece of software: https://vpncloud.ddswd.de — if you need to set up an encrypted VPN between a bunch of servers.
It's been fantastic.
It works well, it gets the job done, it doesn't pester you with notifications and upsells. It also doesn't eat all of your CPU/battery by watching changes everywhere, like Dropbox does. And it doesn't try to get at your photos. And other stuff.
I have not run into a single problem with it over the course of several months now, which is impressive.
I am about to sign up and start sponsoring it on a monthly basis — I started doing this recently with open-source software that I rely on. If everybody chipped in, we'd be in a world of great sustainable software, with people able to make a living on developing solutions like this.
BTW, a plug for another similarly impressive piece of software: https://vpncloud.ddswd.de — if you need to set up an encrypted VPN between a bunch of servers.
Correction: over the last week, syncthing has corrupted my git repository twice. I reported this as an issue, but the issue was immediately closed with an explanation I disagree with.
I no longer trust syncthing until this gets resolved, unfortunately.
I no longer trust syncthing until this gets resolved, unfortunately.
> If everybody chipped in, we'd be in a world of great sustainable software, with people able to make a living on developing solutions like this.
This is exactly the goal of Snowdrift.coop. (Disclaimer: I am a volunteer contributor and "replacement cofounder").
Unfortunately, not many people currently do donate. We posit that there's order(s) of magnitude more people who are willing to donate, but not willing to be the "sucker" who donates while others free-ride. (The game theory term for what they're after is mutual assurance). Fundamentally it's a coordination problem. To solve it, we need a mechanism that allows those folks to say, "I'm willing to do my bit, but only if others do theirs."
Snowdrift.coop is a crowdfunding platform (in development) that aims to provide such a mechanism. We call it crowdmatching. To support a project, patrons pledge to give a monthly donation of $1 per 1000 patrons of that same project. By pledging to match others, you invite them to join you, so we can reach that world of great sustainable software. And if they don't, you're left with a tiny bill, so it's safe to pledge to all the projects you'd like to support, without worrying that your lone $10/month is going to a project where it won't really move the needle.
There are two "safety measures" that are not part of crowdmatching, but I have to mention (opinions tend to be split on whether they are too obvious to be worth mentioning or too important not to say up front):
- You can set a monthly limit so you're not on the hook for more than you can afford.
- At low levels, donations are sometimes delayed and pooled (charged in arrears) to minimize processing fees.
I'll stop here to keep this a reasonable length, but will check back later and follow-up with replies. If you don't want to wait, I'd suggest reading down the list at https://wiki.snowdrift.coop until you get as far down the rabbit hole you want to go. Finally, we can use help getting all the way launched, especially if you're experienced with css or haskell (or, on the off chance, are a layer interested in doing pro bono work and/or serving on our board).
This is exactly the goal of Snowdrift.coop. (Disclaimer: I am a volunteer contributor and "replacement cofounder").
Unfortunately, not many people currently do donate. We posit that there's order(s) of magnitude more people who are willing to donate, but not willing to be the "sucker" who donates while others free-ride. (The game theory term for what they're after is mutual assurance). Fundamentally it's a coordination problem. To solve it, we need a mechanism that allows those folks to say, "I'm willing to do my bit, but only if others do theirs."
Snowdrift.coop is a crowdfunding platform (in development) that aims to provide such a mechanism. We call it crowdmatching. To support a project, patrons pledge to give a monthly donation of $1 per 1000 patrons of that same project. By pledging to match others, you invite them to join you, so we can reach that world of great sustainable software. And if they don't, you're left with a tiny bill, so it's safe to pledge to all the projects you'd like to support, without worrying that your lone $10/month is going to a project where it won't really move the needle.
There are two "safety measures" that are not part of crowdmatching, but I have to mention (opinions tend to be split on whether they are too obvious to be worth mentioning or too important not to say up front):
- You can set a monthly limit so you're not on the hook for more than you can afford.
- At low levels, donations are sometimes delayed and pooled (charged in arrears) to minimize processing fees.
I'll stop here to keep this a reasonable length, but will check back later and follow-up with replies. If you don't want to wait, I'd suggest reading down the list at https://wiki.snowdrift.coop until you get as far down the rabbit hole you want to go. Finally, we can use help getting all the way launched, especially if you're experienced with css or haskell (or, on the off chance, are a layer interested in doing pro bono work and/or serving on our board).
> This is exactly the goal of Snowdrift.coop.
There are many ways to sponsor sustainable open-source. I currently donate through GitHub Sponsors, Clojurists Together, OpenCollective (CIDER) and directly to developers via PayPal subscriptions.
There are many ways to sponsor sustainable open-source. I currently donate through GitHub Sponsors, Clojurists Together, OpenCollective (CIDER) and directly to developers via PayPal subscriptions.
There are many [existing mechanisms] to sponsor open-source, but unfortunately none of them appreciably move the needle much. Collectively, they produce many orders of magnitude less funding than is enjoyed their proprietary counterparts.
When Aaron and David (the original two cofounders) were deciding whether they wanted to pursue this project, they were very concerned about whether they'd be recreating the wheel. So, they did an Exhaustive review of [other crowdfunding platforms], which we've done our best to keep up to date (although Clojurists Together is new to me, so thank you for sharing; it's on my list to make sure it gets added).
In short, nobody has combined mutual assurance with sustainable, ongoing funding. As a nonprofit cooperative run almost exclusively by volunteers (myself included; I have no financial ties to the project), we're in this to hopefully make an impact on the world. If another platform adopted crowdmatching, and succeed in funding open source to the decree we hope, we'd cheer as we put down our (metaphorical) shovels. That is, we're not in competition with other platforms. We all want the same thing.
[existing mechanisms]: https://wiki.snowdrift.coop/about/existing-mechanisms
[other crowdfunding platforms]: https://wiki.snowdrift.coop/market-research/other-crowdfundi...
When Aaron and David (the original two cofounders) were deciding whether they wanted to pursue this project, they were very concerned about whether they'd be recreating the wheel. So, they did an Exhaustive review of [other crowdfunding platforms], which we've done our best to keep up to date (although Clojurists Together is new to me, so thank you for sharing; it's on my list to make sure it gets added).
In short, nobody has combined mutual assurance with sustainable, ongoing funding. As a nonprofit cooperative run almost exclusively by volunteers (myself included; I have no financial ties to the project), we're in this to hopefully make an impact on the world. If another platform adopted crowdmatching, and succeed in funding open source to the decree we hope, we'd cheer as we put down our (metaphorical) shovels. That is, we're not in competition with other platforms. We all want the same thing.
[existing mechanisms]: https://wiki.snowdrift.coop/about/existing-mechanisms
[other crowdfunding platforms]: https://wiki.snowdrift.coop/market-research/other-crowdfundi...
Oh hey! How's it going with Snowdrift? I first heard about you guys back in 2016 and the project sounded interesting and ambitious, but little news since then...
In late 2016, we (ironically) ran out of funding to pay our lead developer (who has stuck around as a volunteer but with greatly reduced capacity). Since then, development progress on the site itself has been mostly stagnant — we are still in a very soft launch, where you can sign up and pledge real money in the system, but Snowdrift.coop itself is the only project; we've held off on any kind of public announcement because (1) the site UX needs a bit of work, and (2) we don't want to give the impression that funding ourselves is the goal of the project.
While development hasn't seen much progress, other areas have:
- Formed a preliminary board of directors[1], currently working on drafting our bylaws, hopefully done (ready for lawyer review) by the end of the month.
- Moved most of our hosting from AWS to managed infrastructure from the Oregon State University's Open Source Lab (OSUOSL)[2]. This will be great once we're all the way migrated, since infrastructure maintenance has taken up a lot of the limited time that would have gone towards development.
- Almost-finished setting up a civicrm instance[3], to better organize the contact info of the many people who have expressed interest in helping over the years.
- Design folks have continued iterating to solve the site's current UX issues and clean up its css, to make it more approachable to volunteers with limited time. A lot of that has been implemented in a static site generator prototype[4], but we've been missing a good process for getting it integrated back into the main site. I've been working on this slowly for the past few weeks, and am taking next week off to hopefully finish that, so we can get that progress onto the main site.
- I'm not sure of the timeline, but we also moved our code to gitlab.com[5] and our mailing lists to a discourse forum[6]. Almost all development (discussion, project management, and code) now takes place in those two places.
We've also kept up weekly team meetings[7], usually attended between 5-7 team members (the total team size right now is ~10, with varying levels of activity). Progress may have been slow (picking up a little recently), but the project is in no danger of dying. Just to come full circle and tie back with my first post, the main things we still need for a full launch are:
1) Updated UX on the main site, ideally facilitated by making the frontend more approachable. This is why we can use help from anyone with css experience.
2) Backend support for multiple projects. This is why we can use help from Haskellers.
3) Governance and bylaws fully in place. This is why we can use help from a lawyer.
--------
[1]: https://community.snowdrift.coop/g/board
[2]: https://osuosl.org/
[4]: https://sdproto.gitlab.io/, repo at https://gitlab.com/sdproto/sdproto.gitlab.io
[5]: https://gitlab.com/snowdrift/snowdrift, and a few other repos under the snowdrift organization umbrella, https://gitlab.com/snowdrift/
[6]: https://community.snowdrift.coop
[7]: https://community.snowdrift.coop/t/weekly-all-hands-on-deck-...
While development hasn't seen much progress, other areas have:
- Formed a preliminary board of directors[1], currently working on drafting our bylaws, hopefully done (ready for lawyer review) by the end of the month.
- Moved most of our hosting from AWS to managed infrastructure from the Oregon State University's Open Source Lab (OSUOSL)[2]. This will be great once we're all the way migrated, since infrastructure maintenance has taken up a lot of the limited time that would have gone towards development.
- Almost-finished setting up a civicrm instance[3], to better organize the contact info of the many people who have expressed interest in helping over the years.
- Design folks have continued iterating to solve the site's current UX issues and clean up its css, to make it more approachable to volunteers with limited time. A lot of that has been implemented in a static site generator prototype[4], but we've been missing a good process for getting it integrated back into the main site. I've been working on this slowly for the past few weeks, and am taking next week off to hopefully finish that, so we can get that progress onto the main site.
- I'm not sure of the timeline, but we also moved our code to gitlab.com[5] and our mailing lists to a discourse forum[6]. Almost all development (discussion, project management, and code) now takes place in those two places.
We've also kept up weekly team meetings[7], usually attended between 5-7 team members (the total team size right now is ~10, with varying levels of activity). Progress may have been slow (picking up a little recently), but the project is in no danger of dying. Just to come full circle and tie back with my first post, the main things we still need for a full launch are:
1) Updated UX on the main site, ideally facilitated by making the frontend more approachable. This is why we can use help from anyone with css experience.
2) Backend support for multiple projects. This is why we can use help from Haskellers.
3) Governance and bylaws fully in place. This is why we can use help from a lawyer.
--------
[1]: https://community.snowdrift.coop/g/board
[2]: https://osuosl.org/
[4]: https://sdproto.gitlab.io/, repo at https://gitlab.com/sdproto/sdproto.gitlab.io
[5]: https://gitlab.com/snowdrift/snowdrift, and a few other repos under the snowdrift organization umbrella, https://gitlab.com/snowdrift/
[6]: https://community.snowdrift.coop
[7]: https://community.snowdrift.coop/t/weekly-all-hands-on-deck-...
Awesome! Will be following closely. Good luck!
To add to their reliability: I have been running it on my Synology NAS and my computers for six years now.
I have been switching systems three times, ran it on Android. Never had a hiccup.
Will probably contribute some money to the project tomorrow.
I have been switching systems three times, ran it on Android. Never had a hiccup.
Will probably contribute some money to the project tomorrow.
Title might be better as: Syncthing is everything I used to love about computers.
Title sucks, but I did enjoy reading the review.
I'm a Dropbox user since 2009 who recently switched to iCloud Drive. I miss the old Dropbox that just worked and stayed out of the way. Once Dropbox rebranded (2017?) I knew it was the beginning of the end. I cancelled my subscription a couple of years ago and just kept it around for syncing preferences, which I ditched a couple of months ago.
iCloud Drive works well enough, but it doesn't indicate whether files are synced (with a checkmark like Dropbox used to do). I typically avoid Apple software because in trying to simplify it they end up making it vastly overcomplicated.
I've heard good things about NextCloud but didn't want to self-host. I've tried SpiderOak and Google Drive before and both were just too slow (and Google Drive was very flakey).
I'm a Dropbox user since 2009 who recently switched to iCloud Drive. I miss the old Dropbox that just worked and stayed out of the way. Once Dropbox rebranded (2017?) I knew it was the beginning of the end. I cancelled my subscription a couple of years ago and just kept it around for syncing preferences, which I ditched a couple of months ago.
iCloud Drive works well enough, but it doesn't indicate whether files are synced (with a checkmark like Dropbox used to do). I typically avoid Apple software because in trying to simplify it they end up making it vastly overcomplicated.
I've heard good things about NextCloud but didn't want to self-host. I've tried SpiderOak and Google Drive before and both were just too slow (and Google Drive was very flakey).
I was looking for seamless sync between multiple desktops and phones, but nothing fit the bill. Tried all the cloud providers, syncthing, etc (Syncthing was great though). I want to have my calendar, my password manager db, my desktop config, my dev files, and my personal files accessible everywhere.
In the end I bought a Synology NAS and placed it at home.
Though SynologyDrive does have some issues, it works well on every OS I've tested including Android, and does have decent blacklisting features. I use synology drive for all my personal files and anything that's not under version control (git)
I installed gitea and use that to sync my source code. I just need to write a small command line utility that gives me easy access to the repos locally.
Using a password manager with webdav support (I use Enpass and I heartily recommend it) makes password sync easy, since Synology natively supports webdav.
For Contacts and Calendar you also have to use a client that supports CalDAV & CardAV, and I haven't found a good unified client for Tasks, CalDAV and WebDAV, so you'll likely have a mishmash of applications on different OSes, but it works well enough.
Other things I have installed are a local plex server and automated backups.
In the end it is a good solution if you like tinkering and are willing to try to build out something that fits your needs.
Syncthing is amazing but I remember I had issues with the Android client and that's why I tried the NAS route. Maybe the Iphone client is better.
I've heard great things about NextCloud, SeaFile and OwnCloud, and you could run those in a VPS if your traffic is light.
In the end I bought a Synology NAS and placed it at home.
Though SynologyDrive does have some issues, it works well on every OS I've tested including Android, and does have decent blacklisting features. I use synology drive for all my personal files and anything that's not under version control (git)
I installed gitea and use that to sync my source code. I just need to write a small command line utility that gives me easy access to the repos locally.
Using a password manager with webdav support (I use Enpass and I heartily recommend it) makes password sync easy, since Synology natively supports webdav.
For Contacts and Calendar you also have to use a client that supports CalDAV & CardAV, and I haven't found a good unified client for Tasks, CalDAV and WebDAV, so you'll likely have a mishmash of applications on different OSes, but it works well enough.
Other things I have installed are a local plex server and automated backups.
In the end it is a good solution if you like tinkering and are willing to try to build out something that fits your needs.
Syncthing is amazing but I remember I had issues with the Android client and that's why I tried the NAS route. Maybe the Iphone client is better.
I've heard great things about NextCloud, SeaFile and OwnCloud, and you could run those in a VPS if your traffic is light.
So, if I might ask, what people are looking for (in simplest terms):
a cloud synching platform that is cross platform, with a decent (or better) UI and a good indicator, that has end to end encryption.
To be honest, given the proper team, that doesn't seem like the hardest bill to fill. I will admit, though, finding a tech company that is willing to spend money decent interface and graphic designers is sometimes difficult, but not impossible.
a cloud synching platform that is cross platform, with a decent (or better) UI and a good indicator, that has end to end encryption.
To be honest, given the proper team, that doesn't seem like the hardest bill to fill. I will admit, though, finding a tech company that is willing to spend money decent interface and graphic designers is sometimes difficult, but not impossible.
> with a decent (or better) UI
I want no UI. It should transparently work like any other filesystem.
I want no UI. It should transparently work like any other filesystem.
I believe this already exists in the form of 'rclone'[1] and I believe that we[2] are the only cloud storage provider that explicitly supports it[3].
Which is to say, we built the 'rclone' binary into our environment such that you can run it remotely:
[2] https://www.rsync.net/products/universal.html
[3] https://www.rsync.net/products/rclone.html
Which is to say, we built the 'rclone' binary into our environment such that you can run it remotely:
ssh [email protected] rclone s3:/bucket/blah /rsync/dir
[2] https://www.rsync.net/products/universal.html
[3] https://www.rsync.net/products/rclone.html
I use rclone to sync a onedrive with an ubuntu host and it works. It is also a single binary, with one configuration file, which allows you to sync on your terms.
Either no UI, or using system standard frameworks and APIs (no custom UI stuff, and absolutely no Electron garbage).
If Dropbox had remained the same as it did back in the early days and focused on continuing to only update the product to be faster and more reliable and not adding additional features, it would have still been great. (Unrealistic considering that the investors need to get their ROI.)
If Dropbox had remained the same as it did back in the early days and focused on continuing to only update the product to be faster and more reliable and not adding additional features, it would have still been great. (Unrealistic considering that the investors need to get their ROI.)
I mean, they used to be about the only game in town. Now you have monsters like MS and Google and Apple in the game. Cloud storage used to be value in and of itself, that's less so the case now, especially when there isn't system integration the way there is with OneDrive, GDrive or iCloud.
Google's offer of free 15GB is also pretty ridiculously generous compared to the competition (Dropbox 2GB, OneDrive/iCloud 5GB). MS and Apple have some ecosystem stuff to drive sales, but Dropbox, eh...
Google's offer of free 15GB is also pretty ridiculously generous compared to the competition (Dropbox 2GB, OneDrive/iCloud 5GB). MS and Apple have some ecosystem stuff to drive sales, but Dropbox, eh...
I think features like smart sync and ignore are actually really useful. There’s stuff I don’t need (like Paper), but I don’t feel it is getting on my way.
And seems to be they have been also working with the core product. On the blog they mention rewriting the sync engine (with Rust): https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...
And seems to be they have been also working with the core product. On the blog they mention rewriting the sync engine (with Rust): https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...
I've used sync.com for several years with no issues, it just works and stays out of my way. I don't use it for syncing between computers though just to have a backup online
I use sync.com Canadian, so five eyes. Not end to end encypted, so probably the same level of security as Dropbox or iCloud.
Sync.com claims to be end-to-end encrypted [0]. Is there any indication they are not?
[0] https://www.sync.com/your-privacy/
[0] https://www.sync.com/your-privacy/
JS gets loaded from a sync server, no verifiable open source client, no documentation explaining security architecture.
It may or may not be E2E encrypted.
It may or may not be E2E encrypted.
Yes, I thought this was going to be about the great hobby computers of the 80s, with approachable built-in BASIC interpreters.
A title that isn't deliberately misleading but turns out to be about something other than what you expected is probably a good thing, more often than not.
Same, a favorite topic no less.
As mine.
I'll just leave this here for any other disappointed folks. Mega65 is due to begin taking orders for dev kits next week. I am so stoked: https://mega65.org/
(note that dev kits do not include the final molded case, that should be coming later)
I'll just leave this here for any other disappointed folks. Mega65 is due to begin taking orders for dev kits next week. I am so stoked: https://mega65.org/
(note that dev kits do not include the final molded case, that should be coming later)
I was just considering making that change when I saw your comment. Good idea!
We've changed the title above to that, which is a sentence from the article which more accurately represents what it's about.
We've changed the title above to that, which is a sentence from the article which more accurately represents what it's about.
I applaud everything in this article except this:
> Calendar sync? Why on Earth would FILE SYNCHRONIZATION application wants to access my calendar?
It's very handy to have shared calendars across multiple devices. Dropbox's advertised solution for this is garbage because I have no interest in letting Google or Outlook manage my calendars.
But there's another solution that used to work with Dropbox that doesn't any more. And the breakage is Apple's fault, not Dropbox's. Say you have two Macs and you want their Calendar apps to be in sync. Further, you don't want to use iCloud because you know from painful experience that Apple has no idea how to sync anything properly. It used to be possible to move ~/Library/Calendars to Dropbox and put a folder symlink in its place. If you do this on both machines, Dropbox automagically syncs your calendars. But in later versions of MacOS when you replace Library folders with symlinks the apps in question stop working. Thanks Apple. Looks like Syncthing might fix this problem for me again, and I won't even need Dropbox any more.
> Calendar sync? Why on Earth would FILE SYNCHRONIZATION application wants to access my calendar?
It's very handy to have shared calendars across multiple devices. Dropbox's advertised solution for this is garbage because I have no interest in letting Google or Outlook manage my calendars.
But there's another solution that used to work with Dropbox that doesn't any more. And the breakage is Apple's fault, not Dropbox's. Say you have two Macs and you want their Calendar apps to be in sync. Further, you don't want to use iCloud because you know from painful experience that Apple has no idea how to sync anything properly. It used to be possible to move ~/Library/Calendars to Dropbox and put a folder symlink in its place. If you do this on both machines, Dropbox automagically syncs your calendars. But in later versions of MacOS when you replace Library folders with symlinks the apps in question stop working. Thanks Apple. Looks like Syncthing might fix this problem for me again, and I won't even need Dropbox any more.
> It's very handy to have shared calendars across multiple devices.
CalDAV should have you covered there. While the need for a server may be a bit inconvenient, I doubt that usability would be on par with it when you just copy the files instead (think of alerts, sharing calendars with others, etc). Also, there is no iOS Syncthing client when your phone probably is the most important device to have your calendars on.
CalDAV should have you covered there. While the need for a server may be a bit inconvenient, I doubt that usability would be on par with it when you just copy the files instead (think of alerts, sharing calendars with others, etc). Also, there is no iOS Syncthing client when your phone probably is the most important device to have your calendars on.
I didn’t realize local calendars are still a thing. I though they are all hosted. That’s why I didn’t understand what was offered there
> Commercial solutions are interested in keeping users locked in and constantly upselling more features to them. As a result of that, you get notifications, features, popups.
At this point I'm pretty convinced that non open source software simply isn't viable for end-user applications and tools. The incentives don't work. You always end up with upsells/ads, insane missing features, bad UX, etc.
Closed source seems to work fairly well for some things like OSes, games, and perhaps some big-contract B2B, but not for apps.
At this point I'm pretty convinced that non open source software simply isn't viable for end-user applications and tools. The incentives don't work. You always end up with upsells/ads, insane missing features, bad UX, etc.
Closed source seems to work fairly well for some things like OSes, games, and perhaps some big-contract B2B, but not for apps.
This is exactly the conclusion I’ve come to. If I can’t find it on github (or similar) and build it then it’s probably going to do something weird that I don’t like.
I make exceptions for a very small number of games, Minecraft is one. Even then though I usually avoid closed stuff unless I know the game well.
I totally disagree that closed source works with OSes, I couldn’t imagine living with OS X or Windows. Sometimes it feels like the people who build those OSes use a special version that isn’t distributed publicly, how else could they leave so much broken?
I make exceptions for a very small number of games, Minecraft is one. Even then though I usually avoid closed stuff unless I know the game well.
I totally disagree that closed source works with OSes, I couldn’t imagine living with OS X or Windows. Sometimes it feels like the people who build those OSes use a special version that isn’t distributed publicly, how else could they leave so much broken?
> I totally disagree that closed source works with OSes
You might be right, I only rarely leave Linux.
You might be right, I only rarely leave Linux.
> At this point I'm pretty convinced that non open source software simply isn't viable for end-user applications and tools.
I would agree it's not ideal, or maybe even not desirable, but not viable is a very strong claim when the reality is that 99+% of end-users are using almost exclusively close source proprietary applications and tools.
I would agree it's not ideal, or maybe even not desirable, but not viable is a very strong claim when the reality is that 99+% of end-users are using almost exclusively close source proprietary applications and tools.
Yeah, you're right. Viable is obviously the wrong word.
[deleted]
I am a long-term user of Unison (https://www.cis.upenn.edu/~bcpierce/unison/) from the command line, to synchronize directories between my machines. If Unison weren't available, from studying the Syncthing documentation it would be my next choice.
You wouldn't think that writing synchronization software would be rocket science, but apparently it is: Unison's author is Benjamin C. Pierce, a prominent computer scientist and author of "Types and Programming Languages". Together with an active user community, he makes the correct call on some key design decisions.
I have tested many alternatives to expose these issues. I have not tested Syncthing, as this HN post is so poorly titled that it would sync into oblivion before I could complete the tests. I recommend writing your favorite sync software author if you find their handling of these issues problematic, though expect defensive replies.
[1] Symbolic links. They should be copied as is, not considered for their semantic content. Would you want sync software taking a half hour break if it found porn on your computer? Why should it think about symbolic links, either? It is your responsibility that they have some meaning on the target machine. Unison and Syncthing copy Unix symbolic links. All other programs wreck them or follow them. It confuses matters that some users beg for such behavior, in hopes of extending the capabilities of sync software beyond their original design.
On MacOS an application bundle, not meant to be examined by casual users, can contain internal symbolic links, for example from "latest" to a versioned directory. Software that mangles this will claim that it isn't meant for "system files" as if that is some dangerous art. It is not; they are simply handling symbolic links wrong.
[2] "Atomic" directories. If one has for example a MacOS sparse disk image open on two machines, and makes conflicting changes, one cannot simply merge the pieces, deciding arbitrarily on conflicting index files. Think of the movie "The Fly". A sparse disk image is again a directory of many files. This has many advantages, including ease of incremental backup. However, one needs to decide which copy to keep in case of conflict, at the directory level.
Unison has a way to declare this. I've never seen other software with this capability. This also applies for example to .git directories.
[3] Interactive conflict management. Using Unison, one chooses interactively how to resolve conflicts before committing to the sync. I sync many gigabytes of data, and I have no interest in dealing later with scattered renamed copies of files, many of which matter to automated tools and will never see my manual attention. I either choose a preferred copy at the time of sync, or I abort and fix the problem before the sync.
I prefer Unison's handling here to Syncthing.
You wouldn't think that writing synchronization software would be rocket science, but apparently it is: Unison's author is Benjamin C. Pierce, a prominent computer scientist and author of "Types and Programming Languages". Together with an active user community, he makes the correct call on some key design decisions.
I have tested many alternatives to expose these issues. I have not tested Syncthing, as this HN post is so poorly titled that it would sync into oblivion before I could complete the tests. I recommend writing your favorite sync software author if you find their handling of these issues problematic, though expect defensive replies.
[1] Symbolic links. They should be copied as is, not considered for their semantic content. Would you want sync software taking a half hour break if it found porn on your computer? Why should it think about symbolic links, either? It is your responsibility that they have some meaning on the target machine. Unison and Syncthing copy Unix symbolic links. All other programs wreck them or follow them. It confuses matters that some users beg for such behavior, in hopes of extending the capabilities of sync software beyond their original design.
On MacOS an application bundle, not meant to be examined by casual users, can contain internal symbolic links, for example from "latest" to a versioned directory. Software that mangles this will claim that it isn't meant for "system files" as if that is some dangerous art. It is not; they are simply handling symbolic links wrong.
[2] "Atomic" directories. If one has for example a MacOS sparse disk image open on two machines, and makes conflicting changes, one cannot simply merge the pieces, deciding arbitrarily on conflicting index files. Think of the movie "The Fly". A sparse disk image is again a directory of many files. This has many advantages, including ease of incremental backup. However, one needs to decide which copy to keep in case of conflict, at the directory level.
Unison has a way to declare this. I've never seen other software with this capability. This also applies for example to .git directories.
[3] Interactive conflict management. Using Unison, one chooses interactively how to resolve conflicts before committing to the sync. I sync many gigabytes of data, and I have no interest in dealing later with scattered renamed copies of files, many of which matter to automated tools and will never see my manual attention. I either choose a preferred copy at the time of sync, or I abort and fix the problem before the sync.
I prefer Unison's handling here to Syncthing.
I used to use Unison. It has a huge flaw. Like rsync, the Unison binary must be installed at both ends of the sync. Unlike rsync, they must be exactly the same version, compiled with exactly the same version of various libraries.
I was bitten by this so many times, because the path of least resistance is just to install unison from the repo of whatever OS you are using, but if you want to sync between different OSs, may God have mercy on your soul. Sometimes, it works. Sometimes, it explodes.
I switched to Syncthing. Your points here are valid, but so far, have not been a problem in the real world.
I was bitten by this so many times, because the path of least resistance is just to install unison from the repo of whatever OS you are using, but if you want to sync between different OSs, may God have mercy on your soul. Sometimes, it works. Sometimes, it explodes.
I switched to Syncthing. Your points here are valid, but so far, have not been a problem in the real world.
> Like rsync, the Unison binary must be installed at both ends of the sync. Unlike rsync, they must be exactly the same version, compiled with exactly the same version of various libraries.
Wow, I've been using rsync for years and never knew this. I hope I haven't silently corrupted anything.
Wow, I've been using rsync for years and never knew this. I hope I haven't silently corrupted anything.
> You wouldn't think that writing synchronization software would be rocket science, but apparently it is
It really is, depending on your constraints. It's one of those charming problems that starts at "Why don't you just ___?" and quickly devolves to "Okay, so we can probably avoid creating an inconsistent state here so long as edgecase0, edgecase1, and edgecase38 don't occur at the same time."
It really is, depending on your constraints. It's one of those charming problems that starts at "Why don't you just ___?" and quickly devolves to "Okay, so we can probably avoid creating an inconsistent state here so long as edgecase0, edgecase1, and edgecase38 don't occur at the same time."
> [2] "Atomic" directories.
What's this feature called in Unison's own terms? I'm also a regular Unison user, but I'm not familiar with this idea and it's not jumping out from a quick browse through the manual. Would like to know more in case I'm missing something good.
What's this feature called in Unison's own terms? I'm also a regular Unison user, but I'm not familiar with this idea and it's not jumping out from a quick browse through the manual. Would like to know more in case I'm missing something good.
atomic = Name .git
atomic = Name *.sparsebundle
https://www.cis.upenn.edu/~bcpierce/unison/download/releases...
syncthing is an incredible piece of software.
It should be noted that:
* "Security" changes in recent versions of Android seem designed to kill use cases like syncthing. See links below.
* There is no iOS version, as near as I can tell because iOS is already where Android is headed.
The crux of the problem is syncthing is a single golang binary, but the only way to manage filesystem permissions on iOS (and now Android) is through tightly controlled OS dialogs, and there is no way to do this from golang. There aren't even NDK APIs for it. The closest thing Android is providing to an escape hatch is "all files access" [5], for which your app has to go through an approval process in order to be put on the play store. If you watch [2], GOOG makes it very clear that they want to minimize the number of apps that obtain this permission. It's unclear to me whether apps installed through FDroid or side-loaded will be able to use that permission at all, or if the APKs must be signed.
I'm all for improved security, but never at the cost of controlling what I am ABLE to do with my computer.
It's sad that our operating systems are turning into gatekeepers between developers/users and the hardware they "own".
[0]: https://github.com/syncthing/syncthing-android/issues/29
[1]: https://www.xda-developers.com/android-q-storage-access-fram...
[2]: https://www.youtube.com/watch?v=UnJ3amzJM94&
[3]: https://news.ycombinator.com/item?id=19506544
[4]: https://commonsware.com/blog/2019/03/25/death-external-stora...
[5]: https://developer.android.com/preview/privacy/storage#all-fi...
It should be noted that:
* "Security" changes in recent versions of Android seem designed to kill use cases like syncthing. See links below.
* There is no iOS version, as near as I can tell because iOS is already where Android is headed.
The crux of the problem is syncthing is a single golang binary, but the only way to manage filesystem permissions on iOS (and now Android) is through tightly controlled OS dialogs, and there is no way to do this from golang. There aren't even NDK APIs for it. The closest thing Android is providing to an escape hatch is "all files access" [5], for which your app has to go through an approval process in order to be put on the play store. If you watch [2], GOOG makes it very clear that they want to minimize the number of apps that obtain this permission. It's unclear to me whether apps installed through FDroid or side-loaded will be able to use that permission at all, or if the APKs must be signed.
I'm all for improved security, but never at the cost of controlling what I am ABLE to do with my computer.
It's sad that our operating systems are turning into gatekeepers between developers/users and the hardware they "own".
[0]: https://github.com/syncthing/syncthing-android/issues/29
[1]: https://www.xda-developers.com/android-q-storage-access-fram...
[2]: https://www.youtube.com/watch?v=UnJ3amzJM94&
[3]: https://news.ycombinator.com/item?id=19506544
[4]: https://commonsware.com/blog/2019/03/25/death-external-stora...
[5]: https://developer.android.com/preview/privacy/storage#all-fi...
This is my main issue with using something like Syncthing. I have several computers that I use daily - a Windows machine for some work and most of my music, a Linux box as my daily driver, and my Andriod phone/tablets for watching videos and interacting with the physical world.
All of these are synced through Dropbox, and I have the confidence that 1) my files are backed up on a server that I don't own 2) the software will be updated and continue to work across all the disparate machines I currently own and will own in the future.
I don't doubt that Syncthing will work on Linux super-well, but Windows, Android, and IOS can be picky and not play well with open source. It scares me off a bit from using it.
All of these are synced through Dropbox, and I have the confidence that 1) my files are backed up on a server that I don't own 2) the software will be updated and continue to work across all the disparate machines I currently own and will own in the future.
I don't doubt that Syncthing will work on Linux super-well, but Windows, Android, and IOS can be picky and not play well with open source. It scares me off a bit from using it.
> but Windows, Android, and IOS can be picky and not play well with open source. It scares me off a bit from using it.
This is what scares me off from using Windows, Android or iOS :)
This is what scares me off from using Windows, Android or iOS :)
For phones, unfortunately there's not much of an option. I went the Maemo route, and then it became a dead end; I went the Openmoko route, and then it became a dead end too; Windows was obviously going to become a dead end (and unsurprisingly it did). There's now Pine64 and Purism, but given how many failed before, I'm not too hopeful they'll last. So the only real options are Android and Apple, and of these Android is the least closed (and also the one which doesn't require buying a whole new laptop, plus a paid registration, just to develop for it).
Pine64 and Purism don't need to last. As long as the phone can run without proprietary software and there are enough geeks to maintain a port, I can probably run Debian on it.
Forgive me if I'm missing something, but I'm not sure how this is connected to Android locking down filesystem access?
To your point, I've been using restic/rclone to backup my syncthing directory tree to Backblaze B2. That's worked quite well and is cheap.
Also I have a question. For Dropbox on Android, are your Dropbox files accessible from other apps? I'm pretty sure that's not possible.
To your point, I've been using restic/rclone to backup my syncthing directory tree to Backblaze B2. That's worked quite well and is cheap.
Also I have a question. For Dropbox on Android, are your Dropbox files accessible from other apps? I'm pretty sure that's not possible.
Short version is - I both automatically back up a lot of data and manually export items from Android, and also use the app to grab files (i.e. PDFs or audio) that I don't necessarily want persisted.
My understanding from the parent is that if the Android ecosystem becomes toxic to Syncthing, its functionality becomes restricted, and some of the base cases I use it for won't be available.
---
To answer your question, yes you can access files from your Dropbox in other applications. For example, I make a lot of video doodles for my Instagram, and the Inshot app lets you import audio and music directly into the app from Dropbox. This means I can render some audio on my computer,sync it to dropbox, make a silly video doodle on my phone, combine them and then upload to Instagram.
It's fairly seamless, something I actively use and definitely something I would want in a file-syncing tool.
My understanding from the parent is that if the Android ecosystem becomes toxic to Syncthing, its functionality becomes restricted, and some of the base cases I use it for won't be available.
---
To answer your question, yes you can access files from your Dropbox in other applications. For example, I make a lot of video doodles for my Instagram, and the Inshot app lets you import audio and music directly into the app from Dropbox. This means I can render some audio on my computer,sync it to dropbox, make a silly video doodle on my phone, combine them and then upload to Instagram.
It's fairly seamless, something I actively use and definitely something I would want in a file-syncing tool.
> My understanding from the parent is that if the Android ecosystem becomes toxic to Syncthing, its functionality becomes restricted, and some of the base cases I use it for won't be available.
My best guess at this point is that this will hinge on whether syncthing is able to get "All files access" approval for the play store. Otherwise they'll need to basically re-write syncthing-android from scratch in Java/Kotlin, so it can integrate with the system. They've discussed doing that but frankly it's ridiculous that should even be required.
> To answer your question, yes you can access files from your Dropbox in other applications.
Based on your description, I'm pretty sure this works because you're specifically dealing with media files, as there is special support for sharing those. Does it also work if you try to share a PDF from Dropbox with a generic PDF reader app?
My best guess at this point is that this will hinge on whether syncthing is able to get "All files access" approval for the play store. Otherwise they'll need to basically re-write syncthing-android from scratch in Java/Kotlin, so it can integrate with the system. They've discussed doing that but frankly it's ridiculous that should even be required.
> To answer your question, yes you can access files from your Dropbox in other applications.
Based on your description, I'm pretty sure this works because you're specifically dealing with media files, as there is special support for sharing those. Does it also work if you try to share a PDF from Dropbox with a generic PDF reader app?
If I'm in the Dropbox app, I can export the PDF to say, my printer, I can open it with a reader (I have Adobe Reader installed) from the Dropbox App, or if I'm in Adobe Reader, I can open the file from Dropbox.
I haven't tried any non-Adobe readers, but my experience is that there's a pretty good interop between applications and I haven't yet really run into a pain point where I need to get something from or export something to Dropbox and needed to create or download a shim.
I haven't tried any non-Adobe readers, but my experience is that there's a pretty good interop between applications and I haven't yet really run into a pain point where I need to get something from or export something to Dropbox and needed to create or download a shim.
That sounds like you're sharing a single file at a time, which has decent OS integration. If you had a directory of PDFs that you wanted to sync with Dropbox and open with a reader on your Android, I'd wager that's impossible these days.
It may be, but that's kind of out of the scope of what I do with my phone.
> There is no iOS version, as near as I can tell because iOS is already where Android is headed.
I don't see why there couldn't be an iOS or Android version. It could work the same way Google Drive and Dropbox work. I also use Qfile on my iPad with my QNAP NAS and it works just fine.
I don't see why there couldn't be an iOS or Android version. It could work the same way Google Drive and Dropbox work. I also use Qfile on my iPad with my QNAP NAS and it works just fine.
There is an Android version, but Android is becoming a toxic environment for it. The reason is because of the way syncthing works. It expects broad access to the filesystem, to add and remove files/directories according to its algorithm. This is perfectly reasonable, but GOOG is killing the ability to do so.
EDIT: Re Google Drive on Android: it works by not downloading most files, ie you have to be connected. You can pin files locally, but they go into a special directory controlled by the app. You can't access the files from other apps. For things like syncing a music library this is useless. They have workarounds specific for sharing media files between apps, but why all the complexity? Give me control over where I want to store my files.
EDIT: Re Google Drive on Android: it works by not downloading most files, ie you have to be connected. You can pin files locally, but they go into a special directory controlled by the app. You can't access the files from other apps. For things like syncing a music library this is useless. They have workarounds specific for sharing media files between apps, but why all the complexity? Give me control over where I want to store my files.
Do you think Dropbox is going to stop working on Android?
Well I don't use it so I'm not sure what functionality it currently has. It depends on if it stores any files outside its app directory, and if it needs files to be accessible from other apps.
I would suspect though that apps like Dropbox won't have much trouble getting "All files access" approval, so they should be fine in any case.
I would suspect though that apps like Dropbox won't have much trouble getting "All files access" approval, so they should be fine in any case.
Is "all files access" actually something that an app can be granted? Seems dangerous.
GOOG agrees with you, and so do I for the most part. That's the way Android worked until recently. Any app (with storage permissions) could store anything in shared locations (except SD cards; those have always had these issues), and could mess with other apps' data in these locations. I'm not saying this isn't a security concern. I'm saying they've thrown the user control baby out with the security concern bath water.
Why not have a designated area where apps can share whatever they want, and warn the user that information there can be seen by any app?
Why not have a designated area where apps can share whatever they want, and warn the user that information there can be seen by any app?
> Why not have a designated area where apps can share whatever they want, and warn the user that information there can be seen by any app?
That would rather defeat the point of something like SyncThing wouldn't it?
If someone wants to sync their files in MusicAppX which MusicAppX itself doesn't put in the designated shared area, the person needs their sync software to be able to look into MusicAppX's private files area.
This reminds me of a friend who used CAD software on their iPad.
Eventually they ran out of cash to keep paying the licence for the CAD. And then discovered there was no way to access their own design files they had created themselves. Because they exist inside a private folder, and the iPad does not (maybe did not, I'm not sure if it's changed) allow people to freely browse and read their own files with a generic file browser or other apps.
That would rather defeat the point of something like SyncThing wouldn't it?
If someone wants to sync their files in MusicAppX which MusicAppX itself doesn't put in the designated shared area, the person needs their sync software to be able to look into MusicAppX's private files area.
This reminds me of a friend who used CAD software on their iPad.
Eventually they ran out of cash to keep paying the licence for the CAD. And then discovered there was no way to access their own design files they had created themselves. Because they exist inside a private folder, and the iPad does not (maybe did not, I'm not sure if it's changed) allow people to freely browse and read their own files with a generic file browser or other apps.
Apps would be designed to use the shared space, or provide the option to the user whether to or not. Not all apps would have to provide this options but I suspect most open source apps would.
I tried to get it working on ish (the shell, in beta, similar to termux on Android) but could not even get the « go get » command to finish.
I would not mind syncthing to be limited to ish permissions.
I guess we will have to wait for a decent Linux on phones.
I would not mind syncthing to be limited to ish permissions.
I guess we will have to wait for a decent Linux on phones.
> I guess we will have to wait for a decent Linux on phones.
That's basically my conclusion as well. Though if we can come up with enough killer apps that aren't supported by Android/iOS, it might also open up an opportunity for someone like Microsoft to fork Android and open it back up for developers (feels weird even saying that).
That's basically my conclusion as well. Though if we can come up with enough killer apps that aren't supported by Android/iOS, it might also open up an opportunity for someone like Microsoft to fork Android and open it back up for developers (feels weird even saying that).
I would be happy with a terminal and a web browser for the most part. Some terms apps feel really mobile friendly (ranger, cmus, etc).
I would really miss the plant’net app though, to recognize plants from pictures.
I would really miss the plant’net app though, to recognize plants from pictures.
Is there plan for a native iOS version?
I've been thinking about switching to a self-hosted solution over the last couple years as Dropbox has gotten increasingly annoying. But I always assumed that would mean spending a weekend fighting with config files and trawling forums, and unlike iCloud, the core product of Dropbox has continued to work well enough for my needs. But after seeing how incredibly simple it is to set up Syncthing, I may go ahead and take the plunge.
I highly recommend NextCloud. It's trivial to set up with Digital Ocean, and I've been using it for a couple of years now without a hiccup. I use it as a file server, calendar, and a media streaming solution.
But then you’re back to client/server model no? I like the idea of syncthing and the p2p/node aspect.
yeah that's a trade off, but having your own server has some advantages as well since it's always available. Also provides an easy way to share stuff with friends.
Syncthing is definitely nice if you just need p2p sync between devices though.
Syncthing is definitely nice if you just need p2p sync between devices though.
Also love you can encrypt your files at rest. Something which Dropbox does not offer.
Syncthing vs NextCloud. I guess that nextcloud does alot more than syncthing, but I'm curious about the differences in implementing the file sync.
As a user of both, they're quite different. Syncthing is written in Go and does one thing well -- syncing folders.
If you need more than that, like a web portal full of your files, sharing via web links, etc.... Try nextcloud.
If you need more than that, like a web portal full of your files, sharing via web links, etc.... Try nextcloud.
Would you pay $5/mo for a hosted syncthing instance? A little surprised no one is offering that but I suspect the market is pretty tiny.
> Would you pay $5/mo for a hosted syncthing instance?
I might, but I'd want to hear a lot of reassuring words about security.
To a sibling comment's point: yes, syncthing is p2p, but I'd like to have one of my instances be somewhere off-premises and running all the time so I can synchronize between my office computer and a home computer without needing both of them running at the same time.
I might, but I'd want to hear a lot of reassuring words about security.
To a sibling comment's point: yes, syncthing is p2p, but I'd like to have one of my instances be somewhere off-premises and running all the time so I can synchronize between my office computer and a home computer without needing both of them running at the same time.
How would that be possible? Syncthing isn’t a hosted model is it? Eg, not client/server model— it’s more like p2p no?
I guess someone could offer a service based on it with theirs being the hosted/cloud node, perhaps like a “master” node I guess? I’d imagine they’d have to hack on the syncthing code to achieve this? Not sure...
I guess someone could offer a service based on it with theirs being the hosted/cloud node, perhaps like a “master” node I guess? I’d imagine they’d have to hack on the syncthing code to achieve this? Not sure...
Git is also p2p. Don't tell GitHub that that precludes having a centralized node :P
Pretty sure you'd just need to run it on a DigitalOcean droplet and expose the built-in webui with a password.
I currently pay $10/mo for Dropbox, so yes, I'd say I would :)
I agree with all of this - except for the part about the iCloud Drive path containing a space being a problem.
That should not be a problem, and if it is, it's a huge flaw in the software you are using, and you should file a bug. (Or if it's your software, fix it.)
Seriously, UNIX has supported spaces in filenames since the 70s.
That should not be a problem, and if it is, it's a huge flaw in the software you are using, and you should file a bug. (Or if it's your software, fix it.)
Seriously, UNIX has supported spaces in filenames since the 70s.
This is where theory and practice part ways. If it was a single bug, I’d be happy to file it. I even tried to do so with Jekyll. I located one, found a library, it was already fixed, but not published. Monkey-patched, only to fight next but. And there was not end to it. I didn’t even started looking into pyenv or bazel, which all were also broken in multiple ways.
provided you type them with a slash, in large part confusing the clarity again.
You can "enclose paths in quotes" and then you don't need to escape the spaces.
Which works fine until that context is quoted, or dequoted, in which case you're back to square one.
I set up Syncthing with an extra always-connected node on a NUC and it has been glorious :) Added Nextcloud on there for an easy way to share files with other people, and for more polished photo upload from my phone, contacts and calendar sync. The two work together great.
The fact that it's so transparent is an interesting point. I'm very used to Dropbox reminding me it exists all the time, whereas Syncthing just quietly works. (I wouldn't mind if syncthing-gtk provided a bit more information in its dashboard, though, like the number of changes sent / received in the past hour. Sometimes I feel like I'm just trusting that it's doing the right thing).
The fact that it's so transparent is an interesting point. I'm very used to Dropbox reminding me it exists all the time, whereas Syncthing just quietly works. (I wouldn't mind if syncthing-gtk provided a bit more information in its dashboard, though, like the number of changes sent / received in the past hour. Sometimes I feel like I'm just trusting that it's doing the right thing).
For the record, since nobody mentioned it in the past three days or so, SyncThing does not sync extended attributes, which makes it lose data (mostly metadata, but _useful_ metadata like file tags, and other info that traditional apps store alongside the data fork) when syncing some macOS files.
YMMV, but right now it find it more useful for source code trees than media projects (or any kind of macOS bundle).
YMMV, but right now it find it more useful for source code trees than media projects (or any kind of macOS bundle).
Is there any way to sync encrypted data to non-trusted server with Syncthing? I would like to have encrypted off-site backup.
"borg" is the tool for one-way encrypted backup, not syncthing.
I think you should look into the 'borg' backup tool - it has become the de facto standard for remote backups because it does everything that rsync does (efficient, changes only backups) but also produces strongly encrypted remote backup sets that only you have a key to ... the provider has no access to the data.
The borg website is here:
https://borgbackup.readthedocs.io/en/stable/
and a good description of how it works and why you should use it is here:
https://www.stavros.io/posts/holy-grail-backups/
The borg website is here:
https://borgbackup.readthedocs.io/en/stable/
and a good description of how it works and why you should use it is here:
https://www.stavros.io/posts/holy-grail-backups/
When somebody uses borgbackup with you guys, is there any way you can include "hey you have a stale lock file" (that's probably keeping your backup from working) in the automated email that gets sent when disk usage doesn't change?
Borg or Restic are good for off site backup, but if you want basically an untrusted storage server Reslio does support "encrypted" folders. The UX is a little hard to figure out sometimes though, it's not open source, and is not free. But very good software.
It's on the way. Not done just yet. TL;DR: watch this page: https://github.com/syncthing/syncthing/wiki/Untrusted-device...
Short history:
There was 1 attempt to do it which ended with nothing
https://github.com/syncthing/syncthing/issues/109
https://github.com/syncthing/syncthing/pull/4331
Then there was a follow-up PR (which I was downright giddy to discover): https://github.com/syncthing/syncthing/pull/6214
That PR was just closed yesterday in favor of https://github.com/syncthing/syncthing/pull/6727 which is where the current flame of hope burns.
Short history:
There was 1 attempt to do it which ended with nothing
https://github.com/syncthing/syncthing/issues/109
https://github.com/syncthing/syncthing/pull/4331
Then there was a follow-up PR (which I was downright giddy to discover): https://github.com/syncthing/syncthing/pull/6214
That PR was just closed yesterday in favor of https://github.com/syncthing/syncthing/pull/6727 which is where the current flame of hope burns.
I use restic for that, prerry great.
Also for two wat, check out cryptomator
Also for two wat, check out cryptomator
This honestly sounds like "FOSS advocate yells at cloud".
Many things the article paints as bad are pretty much "I like vanilla ice cream" level arguments, not actual faults.
eg. log in vs. generate and exchange codes.
"Sharing is so easy, just exchange public keys". Yes, and sharing with a serverside cloud storage solution is as easy as giving someone the link or typing their email into a share dialog, and I don't have to do jack anymore. It's completely onesided to share files is wanted and need be.
Not liking a default share folder is, again, personal preference. Having a dedicated cloud storage folder is nice and clear to most people.
Being able to pick and choose is a legit advantage, though.
> How do you connect two devices, if there’s no registration, accounts, email, etc? Simple! > Each device has a unique id, generated automatically when you first run the program. > Share this id with another device, let them share their, and you are good to go.
Totally easier than typing your account info, right?
Also means you have to install an app while with traditional storage services you can just log into a webpage and grab what you need.
> More “features”: > > Desktop sync, > Photos sync, > Screenshots sync. > > These are at least file-like? I don’t understand why they have to be “special features”, though, > if you already have an app whose primary task is to sync files. It already does that. Why are some files more special than others? > > The answer is simple: the only way Dropbox can survive is by building and selling more features. You’ll never have peace of mind with them.
Highly tech-savvy FOSS advocate is oblivious to the existence of non-UNIX operating systems.
Most of these are summarizable as "Dropbox sucks" more than "cloud storage services suck."
Many things the article paints as bad are pretty much "I like vanilla ice cream" level arguments, not actual faults.
eg. log in vs. generate and exchange codes.
"Sharing is so easy, just exchange public keys". Yes, and sharing with a serverside cloud storage solution is as easy as giving someone the link or typing their email into a share dialog, and I don't have to do jack anymore. It's completely onesided to share files is wanted and need be.
Not liking a default share folder is, again, personal preference. Having a dedicated cloud storage folder is nice and clear to most people.
Being able to pick and choose is a legit advantage, though.
> How do you connect two devices, if there’s no registration, accounts, email, etc? Simple! > Each device has a unique id, generated automatically when you first run the program. > Share this id with another device, let them share their, and you are good to go.
Totally easier than typing your account info, right?
Also means you have to install an app while with traditional storage services you can just log into a webpage and grab what you need.
> More “features”: > > Desktop sync, > Photos sync, > Screenshots sync. > > These are at least file-like? I don’t understand why they have to be “special features”, though, > if you already have an app whose primary task is to sync files. It already does that. Why are some files more special than others? > > The answer is simple: the only way Dropbox can survive is by building and selling more features. You’ll never have peace of mind with them.
Highly tech-savvy FOSS advocate is oblivious to the existence of non-UNIX operating systems.
Most of these are summarizable as "Dropbox sucks" more than "cloud storage services suck."
Dropbox does suck though.
I love tools like this, but one of the reasons I use Dropbox is that storage and transfer costs are a constant. I also don't have to worry about maintaining a publicly-accessible server in my home. Are there any cloud services that syncthing can connect to that are comparable in cost to that of Dropbox?
It's quite easy to let a VPS act as a central hub as long as your use case exactly matches "I want everyone to have full read-write access to everything and they understand things like being careful about simultaneous editing and not moving the shared folder wherever they please."
I found trying to manage anything like restricted access to be impossible from a practical standpoint.
Debugging what's going on when it doesn't want to sync is not fun. The logs are full of info that seems irrelevant and just finding the config file on Windows is a new adventure on each machine. Not sure why they can't at least show the path in the web UI somewhere.
I would have gone with Dropbox, but it's blocked in the country most of us work in. Syncthing mostly gets the job done, but I'd probably pay for Dropbox if I could eliminate the frequent inexplicable 15-30 minute delays from Syncthing. In it's defense, though, the network quality it has to work with is pretty terrible.
I found trying to manage anything like restricted access to be impossible from a practical standpoint.
Debugging what's going on when it doesn't want to sync is not fun. The logs are full of info that seems irrelevant and just finding the config file on Windows is a new adventure on each machine. Not sure why they can't at least show the path in the web UI somewhere.
I would have gone with Dropbox, but it's blocked in the country most of us work in. Syncthing mostly gets the job done, but I'd probably pay for Dropbox if I could eliminate the frequent inexplicable 15-30 minute delays from Syncthing. In it's defense, though, the network quality it has to work with is pretty terrible.
This strikes a chord, as we too made the switch from Dropbox to Syncthing recently. We also ended up using Syncthing-GTK, which is a cross-platform UI front-end for Syncthing. (For us the process does not get killed in Windows platforms when Syncthing-GTK exits, but we can live with us for the time being.)
The amount of up-selling is showing me as a paying customer is pretty egregious. Multiple prompts to upgrade to a more expensive plan. Multiple disabled checkboxes and additional prompts about features I can't use because I am only giving ~$120/year.
> You download a single binary executable. You run it. There’s no step three.
Indeed. I'd like to personally thank probonopd for AppImage making applications on Linux sane, if only for the relatively few projects distributing that way.
Indeed. I'd like to personally thank probonopd for AppImage making applications on Linux sane, if only for the relatively few projects distributing that way.
I thought about the kinds of system I would like that is no longer the norm today, and that would be low latency UIs, like those text-mode UIs.
If I were building a user-oriented web app today, this is what I'd do. Store data locally (using PouchDB or plain localStorage, optionally syncs to remote CouchDB that user owns), with optional MS-DOS era UI (using Bootstrap 386) for clarity and minimal distraction, keyboard shortcuts for all major operations (like Windows' Alt+Letter shortcuts for easy discovery), and avoid implementing user authentication where possible.
If I were building a user-oriented web app today, this is what I'd do. Store data locally (using PouchDB or plain localStorage, optionally syncs to remote CouchDB that user owns), with optional MS-DOS era UI (using Bootstrap 386) for clarity and minimal distraction, keyboard shortcuts for all major operations (like Windows' Alt+Letter shortcuts for easy discovery), and avoid implementing user authentication where possible.
[deleted]
1) I agree with what you shared mostly, and I love SyncThing!
2) I think you over exaggerated how difficult DropBox is. For typical users, just selecting the defaults is good enough, and let's be honest DP is pretty rock solid.
3) I think you WAY under exaggerated how technical setting up SyncThing is .. for non-technical users. It was a stretch for me, it would be a nightmare for most of my users.
4) If ST is reliable (I am testing now), I can see some place I would like to use it.
Take care! Gary
Take care! Gary
What the author doesn't realise is that Dropbox is not aimed at programmers or people who know how to work a computer. For example, when he says "And Dropbox? Well… I still have nightmares about this Dropbox UI <picture>", he doesn't realise that to a "normal" person, the UI looks absolutely fine and easy to use, much easier than "that horrible looking terminal! it must contain viruses and be dangerous!"
The problem with Dropbox is that I have to go to that UI and explicitly exclude each target/classes folder after I create a new project. And I have to do it on every machine. With syncthing it’s just a regexp that will work for existing and all future folders automatically
Dropbox has added ignore feature. Works also from command line.
https://help.dropbox.com/files-folders/restore-delete/ignore...
https://help.dropbox.com/files-folders/restore-delete/ignore...
With all due respect, I think you missed the point.
This is not a terminal vs GUI problem. He's discussing a 1 step process (terminal) vs 10-15 step process (GUI). If Dropbox allowed you to install in 1 single step, I'm sure the author wouldn't be as vocal.
This is not a terminal vs GUI problem. He's discussing a 1 step process (terminal) vs 10-15 step process (GUI). If Dropbox allowed you to install in 1 single step, I'm sure the author wouldn't be as vocal.
The ignorance about the reasons for those steps and the way they count feels disingenuous to me.
Examples:
At the end of the installation of both pieces of software, you did not accomplish the same things. Complications of ST (device id's for example) are presented as good solutions to a problem, glossing over the fact that the others wouldn't need them or they were counted towards the setup.
Examples:
At the end of the installation of both pieces of software, you did not accomplish the same things. Complications of ST (device id's for example) are presented as good solutions to a problem, glossing over the fact that the others wouldn't need them or they were counted towards the setup.
About .stignore ...
Dropbox actually offers tool for power user to exclude files from syncing, and no, it is not the tool in UI from you post. As a developer I use it a lot to exclude folders bloated with compiler/linker temp files from syncing.
https://help.dropbox.com/files-folders/restore-delete/ignore...
https://help.dropbox.com/files-folders/restore-delete/ignore...
Been using syncthing as a dropbox replacement since 2017 - It scales from a raspberry pi with a USB disk, to a docker container on my NAS. It even works if the devices aren't on the same network via relays.
It has very low system load, there are basically zero dependencies, and you can run it on your android phone too.
It has very low system load, there are basically zero dependencies, and you can run it on your android phone too.
I've tried switching to syncthing, but it consumed so many CPU cycles that I deed it unusable eventually
Synching but with cloud storage support like B2 or S3 compatibility is what I need.
ST works great with my Android phone and syncing to my Windows 10 PC. What is a good solution to sync photos, music, contacts, etc from an iPhone to a PC? There is not a ST app for iPhones.
The computer has become a commercial ad delivery device. No doubt. These days work on my computers makes me feel like I'm in AdOps optimizing their ad delivery to me.
«I can’t run bazel, etc. Useless.»
Can't agree more on bazel's usefulness :troll:
Can't agree more on bazel's usefulness :troll:
Nice program. Too bad it can not sync with a phone.
It can! At least, there are android apps for it. I don't know about ios.
Good time to remind everyone that the password prompt from Dropbox (in the screenshots, located right below the "Turn on notifications" from the OS) is fake. They pretend to use the password only to turn on accessibility permissions.
https://forums.macrumors.com/threads/dropbox-responds-to-mac...
https://forums.macrumors.com/threads/dropbox-responds-to-mac...
Gah. That is shitty. I deleted dropbox when Condoleezza Rice joined the board back in 2014ish.
I've quit Dropbox when they capped the free account to (I think) 3 devices only. I'm now using Mega.nz which has end-to-end encryption and works well. I actually have a paid account with them to backup photos from my phones. My local cloud directory is still named Dropbox.
It's not fake, it's using a standard Apple-provided API. They are not stealing your password.
As is explained in the link you provided.
As is explained in the link you provided.
That looks like it's from 2016 -- is this still the case? (I'm not a Dropbox user, but would like to know)
Wow i didnt know this! Thanks for the heads up.
upspin from Go people is also a good one.
"Control it by editing XML config"
NOOOOOOOOOOO! So close! Ack! The example is blinding my eyes!
The example even shows arbitrary attribute-heavy vs tag-heavy mixing. Truly a blast from the past.
NOOOOOOOOOOO! So close! Ack! The example is blinding my eyes!
The example even shows arbitrary attribute-heavy vs tag-heavy mixing. Truly a blast from the past.
> Syncthing has reminded me how great computers can be if they are not made by corporations. It’s simple, predictable, sane, acts no-nonsense.
Says someone running MacOS.
Says someone running MacOS.
macOS becomes more and more crap, but does it mean I can’t express my opinion about other programs anymore?
This is a bad situation to be in as a user since you have little control over the evolution of a product that you rely on. Instead of the product being adapted to your needs, it's you who has to adapt to the way the product evolves, or spend the time investing in a different product.
On the other hand, open source has a very different dynamic. Projects can survive with little or no commercial incentive because they're often developed by the users who themselves benefit from these projects. Projects can also be easily forked and taken in different directions by different groups of users. Even when projects become abandoned, they can be picked up again by new teams.
Evolution of GNOME is a great example of this. There are now many flavors of GNOME all catering to different workflows, and users don't have to compromise their preferred way of doing things to chase how GNOME is evolving. Meanwhile, users of Windows or MacOS have very little choice but to continue adjusting to the ways Apple and Microsoft choose to evolve the desktop. Microsoft even uses DMCA to prevent users from doing customization. [1]
[1] https://torrentfreak.com/removing-annoying-windows-10-featur...