After posting my comment, Cedric Champeau has since posted an announcement [1] to the users mailing list, giving the reason for the delay: "official Groovy support wasn't decided until GR8Conf, where I wanted to show a prototype". So it seems nowadays only Groovy developers who pay to attend their conferences are polled when making decisions. Those who "only" follow the mailing lists are ignored.
I agree that the mailing list should have been used the same day, but are you seriously unhappy that something is announced on the mailing list with a delay of 4 days, where all of these days had been travel, conference or holiday for any of the core members?
When you say improve, you should ask why the docs are broken in the first place.
I wrote a lot of doco for Groovy over 5 yrs ago, but it has a tendency to break between different versions of Groovy. E.g. this doco http://groovy.codehaus.org/JN2515-Closures I wrote stopped working after Groovy 1.5 because the Groovy despots suddenly decided to disallow try statements without a catch or finally clause for Groovy 1.6. I had to go through all my code and add finally{} throughout it all. I put the root problem down to the despots not taking work on the Groovy language spec (JSR-241) seriously.
"consumer protection mechanisms that benefit all of us"
If it's all about consumer protection why doesn't the Virginia DMV do something about all the sluglines throughout Virginia and DC. Sluglines are the practice of one stranger giving one or more other strangers a ride so that the car can get on the HOV.
Are those slugline cars safe? Are the drivers safe? Have they received proper training?
Maybe, maybe not. But they don't disrupt the powers that be
Here's a Virginia DMV page with a link to a slugline page:
Let me give all the non Virginians a quick glimpse into how unfair this is. DC has a thing called slug lines. Traffic is so bad here that drivers will offer strangers a ride so they can get on the HOV lanes. Lots of people do this. There are lines all over DC and Virginia of people doing this.
Does the Virginia DMV say anything about slug lines and how unsafe they may be? Or how the drivers may or may not have training? Or how the cars may not have been properly inspected?
NO, in fact they encourage it (see below)
Why? cause it doesn't disrupt the powers that be
They actually link to slug lines - again a popular practice of allowing strangers into the car of another stranger - on this page:
See my comment in this thread about me Ubering to DCA on Friday, and now when I get back in tomorrow I won't have it.
But just want to point out: Because nobody is being paid in slug lines, they couldn't tell people not to do it even if they wanted to.
You make an excellent point about how they claim to care about safety and then tell people to go use slug lines.
For a good laugh, go look at the slug line horror stories. My favorite is a guy who got in a car with a woman who was pulled over minutes later with a suspended license and warrants. She was carted off to jail, and the police officers gave him a ride to a strip mall where he had to call a taxi.
It's nice to see these thoughts at the top of the thread. I get tired of hearing people in the security industry constantly smirking at "dump developers". They don't have a clue what it's like to develop real code with deadlines. They point fingers at others and call that an accomplishment.
Check out this list of 14 Rules of Management by Kelly Johnson. It was true back then for building fighter jets and it's true now for basic software development projects:
"Johnson's famed "down-to-brass-tacks" management style was summed up by his motto, "Be quick, be quiet, and be on time." He ran Skunk Works by "Kelly's 14 Rules":
The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
Strong but small project offices must be provided both by the military and industry.
The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
There must be a minimum number of reports required, but important work must be recorded thoroughly.
There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books 90 days late, and don't surprise the customer with sudden overruns.
The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.
The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.
The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised."
Note that Kelly had a 15th rule that he passed on by word of mouth. According to the book "Skunk Works" the 15th rule is: "Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy.
"Local ephemeral stores are retained unless you terminate your instance"
That sentence makes no sense to people with no AWS experience. But if you give someone with Linux experience secure shell access to a DigitalOcean server they can hit the ground running.
If you shut down your server you lose the data that was stored on the local drives, no different to DO. If you shut down your droplet on DO you lose the data stored on the local drives (in fact DO now scrubs the disks on shutdown after a recent security screw-up). The only difference is that most folk on AWS use EBS storage (something which DO still doesn't offer) which allows you to have drives which can continue to exist after your server is no more and allows you to attach more storage without getting a bigger server.
It's not rocket science:
instance = virtual server ("droplet" in DO speak)
terminate = shut down
ephemeral store = local disk
An EC2 instance is just a virtual server so anyone who knows Linux, Windows, BSD or even Solaris can "hit the ground running" there too.
When you say shutdown are talking about issuing commands from the command line like 'shutdown now' or 'reboot'? Because with Digital Ocean you DO NOT lose your data when you issue those commands. I know from experience.
Terminate in EC2 is basically the same as the Destroy call of DO. In both cases you will destroy the data stored locally. Rebooting an EC2 instance will not result in data loss, same as DO.
http://www.sleuthkit.org/