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 [email protected] 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.