This statement confused the heck out of me (wow! magic free memory) but of course, the pointers are being held to the contents of the memory, just not to the start of the object, which is what the GC cares about.
Perhaps the GC could be modified to track pointers not just to the head of object but to any address within it. Alternatively, C-coders working with Ruby could just say "I'm using this gc object" before calling C code.
I don't see this is a fatal flaw at all. Sounds like its just a bug. Now if, as many here assert, this bug is present all over the Ruby VM, then that's pretty unfortunate. Is that the case, or just hyperbole?
to the extent we think it necessary for the Service
vs
to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services.
I am astounded that people here would criticize anyone for erring on the side of caution. If anyone can argue that the former is equivalent "plain english" for the latter, or that the latter is complicated legalese for the former then go ahead and signing contracts to that effect.
Dont fucking mod me down. The author claims that this is the paragraph that caused the furor:
We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services. You must ensure you have the rights you need to grant us that permission. [Emphasis added]
When in fact this is the modified version that was posted after the furor. The original version is this:
By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent we think it necessary for the Service.
Significantly different. And it was changed for a reason.
to the extent we think it necessary for the Service.
I know HN only has one viewpoint on these matters. However, I was hoping someone could explain to this poor soul how a scenario like the following is ruled out by this language:
I'm the dropbox CEO. I provide a free service for most of my users. As time goes on, I'm having trouble making ends meet. I find that unless I get more cash in the next 7 days, I will be unable to pay my hosting bill and my service will be shuttered. Thus, obtaining more cash is necessary for the Service.
Now along comes a firm, we'll just call them SLP. SLP is willing to give me a bridge loan on very good terms immediately. The only catch is that they require me to sublicense worldwide royalty-free rights to use, copy and publicly display all works stored in the dropbox service. Their purposes for wanting the data is unclear, however it is quite clear that I won't have oversight on the use of the data. I can imagine, however, that they might be interested in using it for data mining, advertising or industrial espionage. We don't speak of any details, though. If I revoke the license, the bridge loan plus penalties immediately comes due.
I can find no other source of funding at this time - I've played all my other cards. I, as the CEO, believe taking this loan at these terms is absolutely necessary if I am going to continue providing the service. So, I sign, sublicense, and don't actually inform even many people in my company let alone the user base. SLP quietly gets read only access to all the data. To whatever extent SLP uses this data, they believe their use of it is necessary for the Service in that they don't believe the bridge loan will ever be repaid and they believe it is necessary to extract value from the data to recoup any losses they expect on the loan.
Now, mind you, I don't actually believe that dropbox has any sort of intent of doing something like this, or that they'd be likely to do so even if their back was against the wall. I also agree it's a pretty far fetched scenario.
I'm simply wondering how a license like this (and the multitide of others like it, I'm not intending to single dropbox out at all) prevents this behavior. You know, because I'm one of the total morons that can't understand simple english.
IANAL, but the "service" and the "company's survival" are not the same concept. When, as GrantTree, I sign an NDA to file a grant application for a client, it states, like most NDAs do, that I can disclose it to subcontractors/advisers/etc "for the performance of their work".
As a programmer, you might say, like you just have, "AHA! But if you don't pay your subcontractors, they won't do their work. So, for the performance of their work, you can sell your data to anyone, if the company's survival is threatened!"
Unfortunately (or fortunately), lawyers, judges, prosecutors and juries are not programmers, and I think you'll find they don't interpret it that way. "For the performance of their work" is clearly intended to mean "directly linked to their work" as well.
The same is true of the DropBox terms. "Necessary for the Service" does not mean "whatever you might imagine could be necessary if you were arguing with a magical genie as to the possible definitions of terms" - it means "what is directly necessary so that the service can operate as normal". So I don't think any judge or jury would accept that selling out all their customers was "necessary for the Service", in the hypothetical case you mention.
Remember, law isn't about theoretical logic - it's about practically resolving disputes between people.
No, I think they completely missed the issue. Which is
* dropbox's customers are not lawyers
* serving up people's files without passwords one week reduces people's confidence when the read new TOCs next week.
No, nix that, the real issue is standards of blogging. The author made a claim about what caused the furor, including a quote, and that quote, regardless of whether or not you believe it to be legally equivalent, was not the TOCs that caused the furor.
Had the author made all the same points about, after quoting the original TOCs, then a) I would not have posted and b) you would be right.
It was changed because all the idiots who couldn't read the words "to the extent we think it necessary for the Service" were throwing a hissy fit. I'm guessing you were in that group and needed the clarification.
What was the reason that you think it was changed? Do you think that they had plans to share user's private files with anyone they would like that they now had to cancel with new language in the ToS?
I believe it was changed because the first version caused a massive furor.
I don't believe that dropbox has any intention of screwing people over. Nor do I believe that they had any intention of allowing users to log in to any account without a password. I do believe that the latter incident, and the TOCs, are huge gaffes, and that the 1password guy misrepresented the TOC issue with incorrect facts.
Their is no difference in policy. They only added terms to explain what the policy meant. The actual policy remained the same. Why did they do this? Because people were making false assumptions and don't understand legalese.
As for your language and comment, drop it. HN is for intelligent discussion, not this tripe.
Edit: Just looked at your comment history. It's pretty bad. You'd best learn to be civil, or leave now.
Ah yes, the old "we can fuck you as long as we use nice words while we do it" argument. I made a "civil" argument and was modded down. Censorship isn't civil.
And your 2.8 avg isnt anything to shout about either.
Compare the above version to this new form: "This license is solely to enable us to technically administer, display, and operate the Services"
It would appear that you didn't look into the issue at all before jumping to the defense of your main service provider. Is this the level of diligence we can expect from your product?
I once pair-programmed an IK animation harness. The math was hard (for me anyway). There were plenty of times where I'd have balked and gone and made a cup of coffee but my partner had the insight and we plowed ahead. Sometimes I was the one with the clarity. The increase in productivity is vastly more than just twice as fast. Sometimes it can mean that a feature that could not be done can now be done. Or take days instead of weeks.
For the other 80% of what goes into any software: total waste of time, or worse. Two people, independently, could get twice as much done. But worse: pairing on something like that can result in over engineering, language battles, just about any kind of drama to make the day more interesting. Seen it happen.
If I had to choose between 100% pair-programming or 100% single-programming, I'd have to choose pair-programming. In this artificial comparison, pair-programming is more productive. Which is why, I think, so many companies fall into this trap. 100% PP teams beat 100% lone-coder teams.
However, teams that pair when appropriate will destroy the zealots of either denomination. Rationality vs religion.
but unfortunately the culture at RIM does not allow us to speak openly without having to worry about the career-limiting effects
The response:
it is particularly difficult to believe that a “high level employee” in good standing with the company would choose to anonymously publish a letter on the web rather than engage their fellow executives in a constructive manner
Since the merits to making anonymous public arguments are so obvious, that line is one in particular that stands out as defensive. It also confirms one of the points made in the original letter, that people are afraid to speak out. Is there any doubt that the author of the above quotation is someone to be feared?
For a good example of a case where public anonymous argument had far more persuasive power than "engaging fellow executives in a constructive[sic] manner" look at the Federalist Papers, which had a profound effect on the ultimate ratification and subsequent interpretation of the US Constitution.
Calendar does have a custom view, which defaults to showing the next "4 Days" (hint), available in the bar at the top of the calendar view. You can change it to 7 days if you like in the settings (gear -> Calendar settings -> General -> Custom view).
Testing: testing is at the forefront of our development philosophy. We never need to check our code coverage to know that it's at 100%: with disciplined TDD, no line of code will be written without a test.
Bravo. In my experience that can be overkill, but with finance, I agree: why risk it. TDD everything.
We don't have a QA team.
WTF?
That might be terrifying when you consider the type of software that we're building, but we're confident that our automated testing is thorough and will catch any regression bugs.
Are regression bugs the only kind of bugs?
We use continuous integration to test every version of every client library against our gateway.
What happens when someone uses your client library in a way you didn't anticipate?
What happens when johnny-botnet hits your API directly without using the client library?
I spent several years developing games, with QA teams that outnumbered the developers. The QA team did not just play the levels through and say "it works!". Sure, they did that for the first hour. Then they'd start doing all those things that they thought someone might try (e.g. in a fit of boredom, or for a laugh). After that they'd just try breaking stuff. What a lot of bugs they would find!
As I write I find it hard to believe that I, a game developer, is having to explain the importance of QA to a financial company.
Agreed -- 100% code coverage is impressive, but only means you are testing the code you've written.
What about all the cases you forgot about. By definition you forgot about the tests too.
What about all the interactions between module A & module B? They may work 100% on their own, but not together.
A good QA department can generate many more tests that the developer could, and do so without the 'author blindness' that is somewhat unavoidable when writing code.
Dan from Braintree here. I think a QA team would be valuable; we just don't have one right now. To answer your rhetorical question, regression bugs aren't the only type of bug, but they're one of the most dangerous in a payments system. If there's a bug with an unanticipated use of a library, it will show up in our sandbox environment before merchants hit it in production. But if functionality that works in production breaks because of a change, that's a really serious problem.
How are regression bugs more dangerous than other kinds of bug?
Here's how I'd rate the "dangerousness" of a bug:
1. How easy is it to detect?
2. How easy is it to reproduce?
3. What are the consequences of it occuring?
4. How likely is it to happen?
Look, bravo for all the TDD. TDD eliminates a huge chunk of bugs. But by definition, the bugs that you find with CI are easy to detect, easy to reproduce and 100% likely to happen. Sure, without a TDD/CI system, these bugs may not have been detected, may not have been easy to repro. But the reverse does not hold: a TDD/CI system doesn't make all bugs easy to detect and easy to repro.
So all the other bugs that your system has right now, are the ones that are left: hard to detect, hard to reproduce, and don't always happen. Now turn on a thousand users. How many users are you hoping to have btw?
Your worst kind of bug:
* Is not detected for months.
* Unable to reproduce.
* Company killer. (Reputation, lawsuits, whatever).
* Happens once every 40,000,000 sessions.
Not detectable using TDD and CI. Company still dead.
And QA would be able to detect these worst kind of bugs?
I'm not suggesting that QA is useless, I think QA should guide developers in terms of testing, as in QA should help writing the test-cases including the corner-cases in spec and let the developers write more tests around those things.
I also think that QA should help performing benchmark tests, load tests, and probably write end-to-end automation-tests (what do they call it these days? Acceptance tests?)
Last but not least, QA should redefine the software processes if bugs happened regularly in a particular area. Consider QA to be a manager that responsible for the productivity of your software team: if a software process doesn't work (let's say one day you found out that TDD doesn't work well), QA should detect that and figure out a better way.
Unfortunately, QA these days are still old school button clicker and test-case fanatics (i.e.: prepare 1000 test cases and ask the director for a week to run them all).
But at the end of the day, bugs exist. No amount of human or practices would cover those exotic bugs.
Perhaps the GC could be modified to track pointers not just to the head of object but to any address within it. Alternatively, C-coders working with Ruby could just say "I'm using this gc object" before calling C code.
I don't see this is a fatal flaw at all. Sounds like its just a bug. Now if, as many here assert, this bug is present all over the Ruby VM, then that's pretty unfortunate. Is that the case, or just hyperbole?