Each container would contain all of the stuff it needs to run - in this case, Java + associated modules.

It simplifies stuff, because if one server requires Foo v1.11.4 but another needs Foo v1.10.8, neither server "sees" the other. You simply configure each container separately, without worrying what the other container's doing. When distributing the container, all you have to do is send out one image. If you want to run 12 containers on a host, that's cool. If you want to run only 1, that's fine too. And that same container will work just fine whether it's running on the server or the new kid's development laptop.

It's not an all-or-nothing approach, so you can choose if you want the database to live in a container of its own, on the host, in the app container, or somewhere distant.

Two years ago's 20-years-ago would have been 1992? Unless leap years work very differently than I've been told...

Yeah, there's a lot of drama 'round there. Cynically, it makes sense for CoreOS to roll their own solution, as Docker continues to reach into CoreOS's core areas. On the other hand, the Rocket announcement certainly sounded nice and desirable.

Neither the Rocket announcement nor the Docker response made me feel like I was reading a technical appraisal of either technology. Too much politics for me to dig through, so I'll wait for smarter people than I to weigh in before making a decision.

Update: Playing with it, It looks like there isn't a build step. Following the steps here: http://www.ubuntu.com/cloud/to... - it seems that docker is installed under /apps/docker (~20 files total) - they're basically just distributing tarballs which contain all necessary dependencies.

From there, it puts a quick wrapper script at ~/snappy-bin/docker, containing:

#!/bin/sh
##TARGET=/apps/docker/1.3.2.007/bin/docker
#TMPDIR=/run/apps/docker
cd /apps/docker/1.3.2.007
aa-exec -p docker_docker_1.3.2.007 -- /apps/docker/1.3.2.007/bin/docker $@

To build your own "snappy package" looks as simple as "cd mydir; snappy build ."

No dependency management or fooling around packages that require conflicting library versions, possibly near-instant "installation" (depending on if they're distributing Dockerfile-equivalents* or containers directly). Sounds good to me - I'll have to take a look sometime.

*Yes, I know that Docker is not the only way to do containers, but it's easy to imagine they could be using a similar "build" step.

UGH slashdot, eating my angle brackets.
Should be `std::cout << "string";` of course.

Because it's, like, the first thing you learn when learning C++.

Any time you see `std::cout "string";` you'll know exactly what's going on. This is a case where standardized operator overloading improves readability, because it's standardized and near-universal. The one-time cost of learning this convention is outweighed by the ongoing improvements in composibility & comprehensibility.

Similarly, if you're working in a very large project, it may make sense to overload the operators for very common operations done with your common objects. Again, the standardization is what's important. If convention is to use `foo * bar` to mean "transmogrify the user foo with the list of magicians bar," and it's a pattern that appears over and over again in your project; every developer on your team is going to be aware of the convention, and after your first week working there, it will no longer be surprising.

Again, the case to be made isn't "Language X has feature Y, which can be abused so let's not use X" - rather, you should say "We won't use feature Y" (with possible exceptions on a case-by-case basis).

I don't love C++. When I have to use it, I write "C with objects," and I know I'm limiting myself quite a bit there. But rejecting a language because it allows you to aim the gun at your foot is silly. That's what code-review is for! If a pull-request is confusing, don't merge it! If a new coworker is doing confusing shit, just talk with them about why your team doesn't code that way.

Yes, thank you for illustrating the similarities to today's US for me. :) The only difference, is that the government itself doesn't hold the money, but rather transfers it to the rich.

I'm running Lubuntu on a $200 Chromebook right now. Works pretty great, except a little wonkiness with suspend/resume & bluetooth connectivity.

If Ubuntu got its stuff together, it could sell capable Ubuntu laptops in the sub-$250 market.

Might wanna revisit your Boolean logic, bro.

A -> B != ~A -> ~B

And the solution to that isn't to ditch the language - you just reject code that does obtuse and sneaky things in your project. If multiplication of your objects doesn't make sense, then why on earth would you overload the * operator?

Even though a[i] and i[a] are the same thing in C (well, except for making the compiler's job harder), you shouldn't use them interchangeably in your code.

You shouldn't judge a language simply because it allows obfuscation. You should judge your coworkers for writing obtuse code.

Never watched Robin Hood, huh?

So, both, then? You'd wish we could still rape our wives and want to have sex with "beautiful children."

Let's play the Slashdot sex offender guessing game: is parent talking about pedophilia, or just plain ol' regular rape of grown women? Or, for double points, a third option not represented here?

Submit your guesses now! The winner will receive one free case of "really wish I didn't want to know" delivered to your address.

Definitely this. Don't bring your laptop to class, bring a notebook and pen. Don't check your phone unless you've got an incoming call you need to take.

You might not be quite as efficient in note-taking (if you're in certain disciplines), but you'll be a lot more able to focus on what's going on, and you'll retain a lot more.

When studying, turn off your phone, or at least disable notifications.

TL;DR: When you're doing something, do one thing well.