I usually hate Bennet's long-winded posts, mainly because he thinks he knows what he's talking about, but manages to be rather wrong most of the time.
This post is more like a "Here's some cool stuff!" - and he's right, a lot of it is pretty cool. If you don't really read the words and just skim the links, it's a pretty good article.
I don't think it's unusual or undesirable for a university to have a code of ethics they follow, even if it differs from the "will of the people" as it manifests through an aggregate of individual actions.
I also don't think it's fascism for a private school to have, you know, a code of ethics - I don't really see how MIT is a nationalist authoritarian government.
I do like the subhuman bit though. I'm now imagining myself tunneling beneath the earth, erupting out to snatch and devour shitty dudes.
It also sends a really clear message: "This behavior will not be tolerated." If sexual harassment causes your name and work to be disgraced - that's a pretty strong deterrent to people in academia.
So if you're considering the aggregate effect, you've also got to consider the aggregate improvement in the lives of students who now face less harassment and can learn in a less hostile environment.
Yeah, they're in cahoots. There are services out there that will contact you offering to magically drive up ad-clicks on your site (for a small fee, of course). I'm sure that some of the website owners think that they're driving actual users to the site, but... it's hard to imagine how anyone tech-savvy would not understand what they're doing.
Stone Soup was the first roguelike I actually got into; and probably still the one I've sunk the most time into. Not remotely qualified to talk about whether or not it's good, but dang it's fun.
The containers aren't like full-fledged VMs - they're generally running only the processes they need. If you enter it & bring up top, you're quite likely to see 3 processes in there - one for top, one for your shell, and one for your actual app.
You're going to have a slightly larger footprint, yeah - I don't believe you can take advantage of shared libraries to reduce RAM usage (though... possibly in some cases. I'm not sure) - but it's much lighter than running a VM.
I mean, I'm a big fan of static linking, so that probably explains my enthusiasm for this. I haven't yet figured out how to statically-link an entire django project, though.:)
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.
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.
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.
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.
Slashdot Mirror
So, if we accept that a "slippery slope" argument is valid, that will lead to "all or nothing" arguments also being valid? :)
Huh, good point. I might actually try that nail polish, though, so it was a little useful for me. :)
I usually hate Bennet's long-winded posts, mainly because he thinks he knows what he's talking about, but manages to be rather wrong most of the time.
This post is more like a "Here's some cool stuff!" - and he's right, a lot of it is pretty cool. If you don't really read the words and just skim the links, it's a pretty good article.
"crazy females"
Huh, I wonder why women don't like you. Probably because we're just addicted to bullying. It's like heroin for us, you know.
I don't think it's unusual or undesirable for a university to have a code of ethics they follow, even if it differs from the "will of the people" as it manifests through an aggregate of individual actions.
I also don't think it's fascism for a private school to have, you know, a code of ethics - I don't really see how MIT is a nationalist authoritarian government.
I do like the subhuman bit though. I'm now imagining myself tunneling beneath the earth, erupting out to snatch and devour shitty dudes.
It also sends a really clear message: "This behavior will not be tolerated." If sexual harassment causes your name and work to be disgraced - that's a pretty strong deterrent to people in academia.
So if you're considering the aggregate effect, you've also got to consider the aggregate improvement in the lives of students who now face less harassment and can learn in a less hostile environment.
Well, when your professor is sexually harassing you, it /does/ tend to diminish your experience of his lectures.
Yeah, they're in cahoots. There are services out there that will contact you offering to magically drive up ad-clicks on your site (for a small fee, of course). I'm sure that some of the website owners think that they're driving actual users to the site, but... it's hard to imagine how anyone tech-savvy would not understand what they're doing.
Gotta spend money to make money, right? :b
It also takes time & energy to, you know, develop, maintain, and generate content for a website.
There's more to the costs of a website than just "how much electricity does the server use"
Stone Soup was the first roguelike I actually got into; and probably still the one I've sunk the most time into. Not remotely qualified to talk about whether or not it's good, but dang it's fun.
The containers aren't like full-fledged VMs - they're generally running only the processes they need. If you enter it & bring up top, you're quite likely to see 3 processes in there - one for top, one for your shell, and one for your actual app.
You're going to have a slightly larger footprint, yeah - I don't believe you can take advantage of shared libraries to reduce RAM usage (though... possibly in some cases. I'm not sure) - but it's much lighter than running a VM.
http://www.infoq.com/news/2014... if you want some more gory details.
Haha, I have read that and, predictably, found it pretty cool. :)
I mean, I'm a big fan of static linking, so that probably explains my enthusiasm for this. I haven't yet figured out how to statically-link an entire django project, though. :)
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:
/apps/docker/1.3.2.007 /apps/docker/1.3.2.007/bin/docker $@
#!/bin/sh
##TARGET=/apps/docker/1.3.2.007/bin/docker
#TMPDIR=/run/apps/docker
cd
aa-exec -p docker_docker_1.3.2.007 --
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?