I feel like you may be trolling a bit here, but I feel your feelings about PHP are misplaced. Given the recent Heartbleed bug, do you really trust seasoned developers working in a strongly typed language to do any better? It’s not about the language but about the protocols and code review surrounding the development. PHP may have been chosen for the simple fact that it’s still the most easily deployed web language available. If a main concern was getting Joe Sixpack to deploy his own cloud infrastructure as easily as possible, that alone may have trumped any other consideration about speed, potential type safety, etc. As long as your protocols are strong (unit tests, CI, peer review, etc.) then your concerns about correctness of implementation are lessened and other ‘soft’ concerns can come to the fore like ease of deployment, or joy to code in. I don’t think PHP does much for the latter, but that’s a matter of opinion 
I totally disagree. Logmein was free from 2007 (or before) until 2014. After seven years, it’s hardly a bait-and-switch to change a business model, especially with the months and months of advanced notice that they were going to end it.
It is not merely disagreeing with their views, it is their actions. Rice and the rest are guilty of war crimes and it is clear that they are not going to ever face trial. Take a look at the people being tortured on their orders.
They won’t even admit that what they did IS torture.
Further, during the Bush administration, they used the same tactics on their critics. Remember what happened to the Dixie chicks?
Calling people ‘traitors’ for disagreeing with you, as the Bushies did is a good way to bring similar on yourself.
I totally disagree. Logmein was free from 2007 (or before) until 2014. After seven years, it’s hardly a bait-and-switch to change a business model, especially with the months and months of advanced notice that they were going to end it.
I’m not sure you understand how a bait and switch operates then.
Like many others I paid for Logmein but only used their service because I could recommend it to others to use the more limited, free service for those who only needed to use it on rare occasions, but keep it installed for when it’s needed but also having the advantage of being compatible with my paid version.
That’s what baited a lot of people into using and paying for their service.
The switch came when they dropped the free service and people who trusted that it was part of their business model were put in a lurch of having to tell all those rare users they had to ante up fees or uninstall. While also getting them to switch to another solution.
The people baited into this model now have to either stay and pay more to cover the expenses of those they collaborate with (by those that were set up as a premise of limited, but free), or go through the time and expense of changing everyone over to a new solution.
A few months to change over 7 years of people who often don’t even know how to uninstall the current app, much less change to something else on their own means that some are just going to be told to plug in their credit card and pay until there’s time to get to them. They may feel like that’s a bait and switch, so the support person, once again, may need to eat the cost and pay for it.
Freemium models aren’t supposed to work this way.
For a model that was run for 7 years, there should have been about a year or more notice for such a radical departure. If Logmein was smart they just would have limited the free accounts in such a way as to drive those who are heavy users to pay, while still allowing light usage for free. That’s how a Freemium model works, unlike a bait and switch.
Could you imagine the outrage if all free Gmail accounts went to paid only accounts right now?
In the end, it backfired on Logmein and many have switched to other solutions, but the hassle of doing so hasn’t been forgotten. Many sure as heck aren’t going to use Logmein for free storage and recommend it to others to get it integrated deep into their workflows only to find that rug swept out later. Even Dropbox isn’t dumb enough to pull that bait and switch on its user base.
TL;DR the TL;DR - I wasn’t driving trollies.
TL;DR - I’m skeptical of ownCloud based on my longish career in software development and an influential article that matches my own experiences and which suggests that it is a red flag that ownCloud is implemented in PHP.
I use the terms security and correctness a lot. For clarity, here’s what I mean by “security”:
- keep private that which is private
- prevent unauthorized reading, writing, deleting of my content
And “correctness”:
- don’t corrupt my data
- handle conflicts in a sane manner
- more generally: the program should behave as the developers intended, e.g. avoid undefined behavior
Though I’m a coder, I don’t specialize in security, so technically speaking you should ignore everything I have to say on the matter. Fortunately, I’ve spent the majority of my career specializing in creating correct software; so I consider myself qualified to speak on that.
Not at all; I genuinely believe what I wrote.
You incorrectly assume I’m advocating a strongly typed language. Python, Ruby, or even Node.js (with similar type-coersion warts as PHP) would be better choices than PHP.
Yes, it is, at least in part.
In my original comment I acknowledges that it could be done in PHP. But all other things being equal (talent, process, code coverage) choose a better language.
I get where you’re coming from; I’ve been there. My career has included a few oscillations between strong-typing and strong-testing camps, equal parts coding in strongly-typed and weakly-typed/dynamically-typed languages, and the gamut of process wonkery (eXtreme Programming, SCRUM, Lean). For what it’s worth, were ownCloud implemented in, say, Python, but without unit tests, I’d be advocating similar skepticism.
My beef with PHP as it relates to implementing secure and correct cloud sync is that — compared to its contemporaries — PHP gets in the way more often than it helps.
My top gripes are that PHP:
- wasn’t designed by a language designer; it was cobbled together over time and it shows
- lacks a history or strong culture for modularity, automated unit testing, and code review
- does many things wrong by default
- exception handling arrived late and most code still uses error reporting, including core PHP
- has instead a design philosophy leading towards incorrect or undefined behavior when things go wrong
- has backwards compatibility to a fault
I have other issues with it, but those are the low points. All languages have warts; it’s just that PHP has a high concentration of them.
Again, I’ve repeated a lot of what was addressed in PHP: a fractal of bad design complemented by a rebuttal where the original author shows up in the comments.
As I write this the forum hosting the rebuttal (forums.devshed.com, running PHP) is returning this:
HTTP/1.1 200 OK
Date: Mon, 14 Apr 2014 06:35:54 GMT
X-Powered-By: PHP/5.3.10-1ubuntu3.11
Content-Type: text/html
…
Connect Error: Too many connections
- should be
500 Server Errornot200 OK - body is plain text not HTML
- in another language, the default behavior of the web framework coupled with the language’s exception handling would have taken care of both
Update: now it’s returning this:
HTTP/1.1 200 OK
Date: Mon, 14 Apr 2014 08:56:54 GMT
…
Invalid query: Table './f_devshed/dbtech_dbseo_resolvedurl' is marked as crashed and last (automatic?) repair failed116
Because revealing your internal database schema to the world is secure…
[quote=“selfsimilar, post:162, topic:28218, full:true”][emphasis mine]
PHP may have been chosen for the simple fact that it’s still the most easily deployed web language available…that alone may have trumped any other consideration about speed, potential type safety, etc..
[/quote]
It’s a popular opinion that PHP “is still the most easily deployed web language.” But I share your supposition that it was a motivator in selecting PHP. The problem is that — in my mind — that “etc.” includes some unacceptable tradeoffs. I question the acumen of developers who would exchange security and correctness for ease of deployment by lay people particularly when it comes to cloud sync.
A side channel response thread to my comments here (I’m a newbie, so only two links per comment):
https://gist.github.com/toolbear/10714417#file-cj-md
The phrase, “one-sided class war”, comes to mind.
I’ve been using SpiderOak for some time. Their commitment to end-user privacy is exemplary – all files are encrypted client-side, automatically, before going to the server. On the whole, SpiderOak does the job. It does have some shortcomings, as others have mentioned – occasionally, the syncing speed becomes very slow, and the Android client doesn’t sync, only download.
Actually, the biggest frustration I’ve had with SpiderOak is that it advertises itself as primarily a backup solution, secondarily a file-syncing solution. While it does track historic versions of a file, which has been useful a few times, when you delete a file locally, it’s immediately deleted from the sync – which is not what you want a backup system to do. But, if you ignore the backup system claim and focus on syncing and file sharing, it’s fine.
If you’re just syncing your files it may work, but if there’s any kind of sharing going on (we use it at work for sharing documents), the user-interface and functionality is abysmal (or maybe it’s just the interface).
My company has enjoyed using https://www.drivehq.com for their enterprise service. Not sure how good their other offers are but their enterprise service is really impressive.
This topic was automatically closed after 5 days. New replies are no longer allowed.
