mpchlets

70's SCSS - Bell Labs, first source control, single user

80's RCS (single user) and then CVS (multiple users)

90's CVS and then Perforce

I don't know, this is from my memory, google can fill in the gaps.

Hmm, did you just post this "disclosure" on your blog before informing the company? Well, now everyone is at risk if your claims are true. Poor form.

Proper course is to disclose to company first, then disclose after fix is in place in reasonable amount of time. Why risk everyone for your benefit?

Oh it's people like you that ruin security through obscurity :P

It seems to me that this post is missing the advantages of Cloud Computing (AWS) and the Cloud Ecosystem. The Cloud is not less expensive than physical servers - it is different and a different beast. You have flexibility and a different toolset, as well the ability to start a new server without procurement. As well, it completely disregards some of the advantages of physical servers, including in-box IO (disk) needs. Clouds have not been good in the past for high-IO apps. As well, you get more control at the expense of flexibility.

Overall - the determination of Cloud vs Physical should not be based solely on Price but needs and overall Ecosystem that you want to participate in.

Not to mention, as an independent consultant and developer, the ability to spin up a new server to play with any time is invaluable.

You can sue for any reason whatsoever - does not mean you will win.

I am sure that Verizon was smart enough to put a limitation on the time that one had to activate the service. They have very many lawyers that would never allow a deal with no end date.

But again, you buy something over 1 year ago and only activate now? Did you really need this service?

Anyhow - you should not expect people to have a special offer that never expires, you must activate it to get the benefits.

But honestly, sounds like you are crying over nothing if it is really 1 year ago that you purchased this. You are being unreasonable.

Based on your comments of Cowboys, you have obviously never rode hard put up wet.

I use Verizon and they are always more than happy to activate my CDMA capable phone for use on the Verizon network - which I have been using for a very long time and live contract free this way. I also use a very old completely Unlimited plan, so buying a phone from Verizon would cancel this plan and force me on a new contract.

Anyhow my point is I have no problems adding a personal device to my plan anytime - many times.

I watched this speech near every MLK day in the US while I was growing up, I remember sitting there not understanding it as I was in grammar school.

We watched it on a large TV set that they rolled in on a cart. Granted I was in a 99% white school at the time, but the school was not for the rich - however they bought the necessary footage (I assume now, no idea).

I distinctly remember Dr. King's voice, I will not forget it.

Seems to me that melbourneit.com was the cause of these problems - that is the related link between all these different problems - basically poisoning the DNS of any popular company that uses them.

So not sure what to say, but this is the email I received from DynEct the other day: subject: Webinar Wednesday: Are You Prepared For DNS Disaster? sender: Dyn hello@dyn.com via dynect-mailer.net

and some info from my old whois: $ whois twitter.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.

   Server Name: TWITTER.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
   IP Address: 209.126.190.71
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com

   Domain Name: TWITTER.COM
   Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
   Whois Server: whois.melbourneit.com
   Referral URL: http://www.melbourneit.com
   Name Server: NS1.P34.DYNECT.NET
   Name Server: NS2.P34.DYNECT.NET
   Name Server: NS3.P34.DYNECT.NET
   Name Server: NS4.P34.DYNECT.NET

Again - that is what they are designed to do. The system is based on trust and espionage . . . it is a complicated relationship there, but again not news just the job description.

Agreed on the ransom, moreover - they gave the site to the owner on good faith that they would get paid, now they are complaining that they were fooled.

A verbal (oral) contract is a contract in the US - though very hard to prove. Chain of custody of the code is one way.

Intellectual property rights are all the rage these days and that would mix into this.

I don't know, this is a new site: https://www.google.com/#q=site:nycfreshmarket.com

There is no cache, so I think this is an over-reaction at this point by the designer and only discredits their business sense and will most likely result in not getting paid for this job.

The phrase 2 wrongs don't make a right comes to mind. WE already have a legal system in place to handle these issues, no reason to defame on the internet, which is truly a permanent record.

The real surprise is everyone is shocked an agency designed to spy is doing just that. And successfully for a long time. I don't like it, but it is not really news - they compare spying on the UN and loved ones in this article ... is it really related?

who enforces such laws?

Do you truly think that Github does not do the same? Any service needs to modify your data on the backend for the good of the service, including copying it to multiple servers for backups and ensuring uptime during a server failure.

They do not need to distribute your code, i.e. making your repo public - this is part of their service and you grant them the right to do so when you make it public.

Do they need to use your source code - well not explicitly as such, but they do modify it when displaying it back to you - look at any source code page, it is modified source code.

This is all in the auspices of giving you a good service.

Furthermore, any fork network modifies your repo - it is all one repository. So in essence, you are modifying people's repos without them knowing.

"However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."

You are granting permission of ownership through forking to anyone - including github.

I am not even sure that Atlassian has a different TOS than Github nor Assembla.

Atlassian is just ensuring with lawyer speak that they are able to do as they need to offer you the service that you signed up for.

I think you are misunderstanding the wording: "as you may authorize" - that bit is about you making it public, and only about you making it public - nothing else. You authorize it to be made public, github says the same as "By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories"

github is just not using lawyer speak, which is definitely cooler.

Oh man - failure to use a framework or they worked around it - either way this was a big programming no no - direct use of SQL with NO sanitizing. Very bad.

I can't even call this a vulnerability - it's an open door.

At Assembla, a project management tool that incorporates a repository service like github or bitbucket, we have a similar TOS as github:

"1. Assembla claims no copyright or other ownership rights in the Content you upload to the Service. 2. By uploading or otherwise providing Content to Assembla.com, You grant to Assembla a non-exclusive, royalty-free, paid-up right and license to use, reproduce, display and distribute such Content on Assembla.com in connection Assembla's provision of the Services to such persons as you may authorize. 3. You hereby represent and warrant that you have all intellectual property and other rights necessary concerning any Content posted by You on Assembla.com." https://www.assembla.com/terms_of_service

We do not want your data for our personal or corporate uses, we only want to display/reproduce/use your data with your expressed permission, i.e. you make your data public - the same as github.

The theory we have at Assembla is that the data is yours, always yours. We will never keep your data from you and we will never claim ownership over it.

We explicitly state that we do not own your IP because in today's world so many services are taking ownership over what you create. We feel it important to tell you right out that we do not claim ownership because if we do not, you will not know our stance.

Our stance is that we want you to feel comfortable using our service for both private and public projects for your data. We want you to be successful with a nice tool, we do not want to own your data.

If you have one long running branch, no issues since you do a mergeback often. All other production-ready code is integrated immediately, so all code is integrated in the long-running branch.

If you have 2 or more long-running branches, then you put them behind a centralized point and merge them up to this development branch which has a mergeback from production-ready code - so all code is integrated.

Either way, you can still integrate all code, its just not in the line of the flow towards production.

As for backing off - bugs happen, can't say they won't - but we fix things as soon as we are alerted of them. We hope you reconsider.

A patch has been applied - link should expire in 48 hrs now - please check it out and let us know

Nice response, nice sentiment, nice format. I often dislike the sensationalism surrounding attacks or viruses - it makes people distrust and gives others excuses for issues.

It would have been nice to receive a message to support about this, but we do monitor Hacker News.

We will get this fixed ASAP.

;)

Yup you do have to sign in, but it definitely lets you see the entire book, it just starts on a random page it seems.

dude, that is your computer - its fine on mine.