B.Jay

"Not very stable"? That's not exactly my experience... I was actually testing Syncthing for quite a while now (between a variety of VMs and a variety of ARM devices), starting with 0.8.xx, and didn't have much of a problem with it - other than it being unable to resume interrupted syncs (not sure if "resume sync" has been already implemented in 0.10.3 or if it's still work in progress - haven't checked the changelogs / git commit in quite a while). For me it's working rather perfectly, though you well better expect "breakage" to happen for as long as there's a "0" as the leading major version number. There was only one version in the 0.9.xx series where sync totally broke, but that was fixed within a few days at the next release version (I guess it's worth pointing out that Pulse/Syncthing gets at least one update a week - they don't take 3+ weeks to fix up small-fry problems like a non-working "listening port value"). As for "sync speed" ... within my LAN the speeds are far above BTSync. While it doesn't max the Gigabit link, I see up to 60/75MB/s when syncing a couple of large (i.e. Linux CD/DVD ISOs) files (Windows via SMB tops out at ~110/115MB/s here). With a ton of small files Syncthing still fares well better than Windows' SMB ... synchronizing a test folder consisting out of 8GB of random small files (100K files, 4KB min, 20MB max, randomly generated with a script to mimic a mixture of image and mp3 files in terms of file sizes) runs at rather consistent 31MB/s average where copying via Windows (via SMB) results in <4MB/s averaged. I once tried the same with BTSync (back in the 1.2 days) and it wasn't too breathtaking as well (~7MB/s avg. if memory serves me well). I actually have only one system still running BTSync (1.3.109) - once "resume sync" is confirmed to work this last instance will fly off and be replaced with Syncthing as well; I don't want to make my friends switch before this last "showstopper" is resolved - it's a pain in the rear when a large folder starts re-syncing from scratch because it was interrupted before it finished up. Lastly, I run Syncthing as a service (via the NSSM "How To" method) and am very pleased with the browser UI. It's consistent across platforms, loads up incredibly fast (much unlike a certain 1.4 UI) and is well structured (the BTSync devs could take that as an example about "How to do things absolutely right"). I'm also in the progress to code up a systray indicator (I know about Syncthing-Tray for Windows, but that one's outright c**p) to act much like the Dropbox one (just the most important notifications and not spamming each-and-every event to the screen like Syncthing-Tray does). Other than that... since Syncthing is Open Source one can always fork it (am currently trying to get cozy with "Go") and iron out "betterfications" if said "betterfications" happen to go down south (i.e. "absolutely unfavorable UI revamp" or other "pushing certain dependencies upon users just because")... not exactly doable with close source software. EDIT: Just to point this one out as well: With Syncthing you don't have to use their "Announce" server (the equivalent to the relay/tracker of BTSync, to put it very simply) it you already wear a tinfoil hat, you can setup your own server and make Syncthing use that one instead; though your own server has to be reachable from the internet if you want to use it with other peers outside your LAN (read: either leased server of your own machine in a DMZ).

What you're missing is that in order for BTSync 1.4's "fabulous" UI to actually display and work you _NEED_ to have at least IExplode 9.0 installed. This means: 1. Disable Iploder, either through "Programs and Features" or via a System Group Policy, and BTSync will happily present you a empty page. 2. If you never update/d Imploder, simply because you can't care less about that Microsoft Malware, it will also refuse to work because Windows 7 ships with IE8 by default (update to IE9/10/11 are on Windows Update but they won't be installed if IE is turned off). In short, you get forced to use/let enabled a particular component you may not even want to use in the first place or about which presence you can't be entirely sure (keep in mind that Microsoft left us with a configuration option to make it disappear, and it's still there even in Windows 10). That being said, no matter how the suits around here try to defend their decision: it's only a sad display of bad coding skills and lacking mangementship to produce something that relies on something you can't take "for granted" just because it happens to be a part of the OS. They could implement Gecko or WebKit (both Free Open Source Software apart from them being levels of magnitudes better and more standard compliant than IE's dire excuse for a render engine) to have a embedded render engine, but ... obviously too far-fetched to be considered. Sync started off as a great product, but at least for me it disqualified itself for further use with 1.4.

To contribute to the OP's poll... Downgraded to BTSync 1.3.109 a few days ago because I simply had enough dealing with the 1.4 beta trainwrecks. As for the 'why?': - BTSync 1.3 (Windows) has the way saner, more sleek, more elegant, UI - BTSync 1.3 (Windows) displays the UI _right away_ and doesn't make me wait till eternity for some moronic "index.html" to load up. Sorry to say BT devs, but waiting 5-6 seconds for the UI to load up, on a 8-core machine having 16GB RAM and running off a SSD, is simply unacceptable; even the 1.3 Linux web UI loads up faster than the trainwreck you call "Settings UI" on BTSync 1.4 Windows. Apart from that I don't like being forced having to have Internet Exploder enabled (first thing I do on Windows is to implement a Group Policy to send IE to hell). - BTSync 1.3 at least works (didn't come across any oddities, which can't be really said about 1.4 ... non-sticking config parameters or dysfunctional functions - hint: "Listeing port" which wasn't fixed in the course of three subsequent releases - and such rather imply a "pre-Alpha" than a "Beta"). - I'll stick to this version for a few months until some other software, doing about the same thing and not forcing me to have some lousy _Browser_ installed/updated/enabled down my throat (simply because it needs it epically bad render engine), has matured a bit more (not going to drop a name here; may be considered 'advertising compeditors') to leave BTSync for good; I don't see it getting any better as it seems that "running with that LULZ HTML/AJAX UI" is to where the management suits want to take it (well, have luck with that).

Alright, I promise to get on your nerves just this last time... Re: "But you can still use it but not the UI (IE <9.0)"... GreatMarko, you still fail to understand my point here. I know that BTSync would still work but not the UI, but: This would still put the BTSync icon into the notification area which, running with a homebrewn UI, wouldn't be required at all - I could implement my own "spinning logo thingy". A plain binary without _ANY_ Windows Shell integration or HTTP served parts would be plain awesome, even if you don't see my point here. Take the guy who coded up the BTSync GUI for Linux as an example (even under the danger to get you mad: he had to do it because your coding monkeys couldn't/wouldn't do it -> #LackingCodingSkills) ... did he need a notification icon prodvided by your binary or some dysfunctional "UI" window? I don't think so. One more Re on "Management knows best": And we're back to #LackingCodingSkills yet again. Your coding monkeys obviously never heard of embeddable browser engines (Gecko, WebKit - just to name two to try and give you the idea). Using Gecko or WebKit as the embedded render engine would resolve a whole lot of the troubles reported around here (UI bomb/misbehaves with customized IE Zone settings and so on) - though you would have a point in going "but that would increase the size of BTSync", but who cares in times like these where hard drives are measured in Terabytes. And while we're at it ... "Unification across platforms" is a joke, right? If you would be serious about "uniform across platforms with easy portability" you would actually want to resort to Java (though everyone hates that beast with a vengeance as well). Seeing how BTSync turned from a manly C/C++ project into a "Metrocalypse-worthy HTML5/JS/CSS" catastrophe and seeing how "Bleep" is C# ... come in with "Uniformity" again? Oh, and using "Trident" to render the UI ... well ... given that even manly Web Developers (earning their living by enduring the PITA that is "making it work with Internet Exploder and its lacking JavaScript and CSS support" - take my word that I know what I'm talking about as a good friend of mine is one of these poor tortured souls) scream like little girls when they get confronted with a "has to also work with IE" project of some client ... wise management decision. I take your suits never, ever, coded up something that had to work in IE (read: tons of ugly hacky code just to make it work in that POS of a browser/engine) as well as in true-to-the-W3C-standard Mozilla/Chrome browsers. Anyway, I'll now shut up - seems you "big fellas" know better than me anyhow.

Thanks for the response. Seems the long-term solution will be to cling on to 1.3 on all peers and rely on DHT discovery (assuming your relay-tracker will stop accepting pre-1.4 peers at some point). However, maybe please tell your "management floor" that they just made a huge mistake with this decision (I'm obviously not the only slightly disgruntled user here). As for "the API is my friend": I know, but that doesn't resolve _ONE_ important issue, and that is the "you need IE >8.0 to use the UI" requirement (hence why you broke BTSync for the guys _still_ running XP (or Vista or RTM Windows 7/SP1)). Having a binary NOT requiring crappy IE would make it easier to plug a "code-it-yourself UI" on top (and you guys could still ship one with your own UI), it would also enable a true "run as a Windows service" experience in the likes of Linux/BSD (minus the HTTP served part). Anyway, I'm not going to hang my hopes up too high as you expressed the evil "management decision" words ... which means that the Armani suits already settled for sealing the doom on this program. Well... we'll see what the future now holds for BTSync, but I have that gut feeling that you guys just commited Sepukku (look it up on Wikipedia) with that decision. Thanks for the response, and good luck sailing down these tides.

@mikelock: I understand your concern about "could be bugged". I can assure you that the APK is untampered and genuine... however... it's just an offer to help out, it's up to the individual to accept it or not. Just to prove it's genuine: 602281a7f1b9c0e190b086f6280ddf5c *BTSync-1.3.21.0.apk <-- MD5SUM f7e83ad051221f2b8efe587a4285d6180215a2d5 *BTSync-1.3.21.0.apk <-- SHA1SUM If I would have modded the file by any means the checksums wouldn't match (with the original), and the signature would be broken as well (i.e. Play Store wouldn't bug you about "Update available").

Just to chime in on the bandwagon as well... I uninstalled BTSync 1.4 from Android. The previous versions were already "bugtastic" (i.e. always rotated the screen 180° when quitting the app for no aparent reason), but 1.4.36.0 on Android really killed the bird now. Force closes randomly, and, to be honest, I'm not even in the mood to collect the logcat stack trace (it's not the ROM at fault here - happens on Stock Samsung 4.3.1 (SGS3) and Stock Samsung 4.4.2 (SGS4) and Stock Samsung 4.2.2 (SGT2) and... well... I better spare myself the whole list). The Windows version and the "renders the UI through "Trident" (IE) now" feature(bug?) ... well ... I'm out of words here. While it works for me on Windows 7 with up-to-date IE ... that's a fail of coding skills to no ends as well as a massive LOL (for any manly Wndows software developer not taking some easy way out because #LackingCodingSkills). Q; What was soooo fundamentally wrong with the previous UI? Q: What part of the new UI was soooo impossible to implement in C/C++ (assuming up to 1.3.xxx were developed in VS)? Can we please get a Windows commandline-only binary in the likes of the Linux/BSD version? I'll happily code my own UI around it rather than use your total "IE based Interface" fail.

I just grabed BTSync 1.3.21.0 out of my lastest Titanium Backup cache (am I glad I keep 2 versions worth of back-log for each app). Anyone who needs the APK for side-loading - PM me and we'll work out how I can get a copy to you. Seems that posting a link for the masses will only piss off the BT staffers. (@BT staff: Instead of cracking down on your user base you should well better invest the time and effort to fix that crap asap - the "Windows BTSync renders the UI through IE" feature is something where I don't know if I should fall off my chair from laughing too hard or if I well better cry because you obviously just fired all your manly C++ coding monkeys and replaced them with HTML/JS/AJAX kiddies from a local elementary school. In my eyes you are currently damaging BTSync's reputation heavily).