There is also something about the extreme emphasis on 'this is not your word'. Much like the public shaming, it suggests the professor is not just displeased, but viscerally outraged.
You may not know this but it is an offensive thing to see a student fail or cheat to get out of failure. It's not right to get mad about it but that doesn't change the fact that it does happen.
I try not to get mad and I try to be as objective as possible but after I know for sure it is very disappointing. It's a reflection of my abilities I feel.
I usually confront the student by asking them to speak to me after class in front of the entire class. It's not shaming as in reality no one cares, everyone knows no one cares, and most students in shitty classes do it. There is one class at my university that students cannot pass without old exams. The teacher doesn't rotate questions and doesn't talk about anything on the exams so it's useless to pay attention. It's basically a study/homework session at school that's a given C to B because you know all the questions on the exam.
Everyone cheats in some way. What I am concerned about is disingenuous cheating where a student obviously is preforming poorly in non-adverse conditions and decides to take it upon themselves to rectify the situation in a non-productive manor.
I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes?
Just trying to understand why rkt is less overhead...
A lot of it is historical. What rkt added conceptually when it was introduced was 1) a spec and test suite, 2) signed/content-addressable images and first class third party repos, 3) not running everything under a single daemon.
Since then, Docker has improved quite a bit on these so the most in your face practical differences are smaller, but there are still philosophical differences that affects it.
E.g. rkt comes out of CoreOS. CoreOS does a lot around embracing systemd to its full extent. Systemd can provide a lot of the capabilities that Docker did itself, and parts of rkt's design flows from that. E.g. restarting, querying status, capturing the logs, so in a systemd based system, Docker integrated fairly poorly in that systemd would be starting and keeping track of a Docker client rather than the process actually controlling the container, while rkt fits right in.
Again, the difference is getting smaller, and various tools like runc etc. from Docker now allows you narrow the gap even more (if you put in extra effort).
Try both, basically - they're similar enough that it's worth figuring out which "flavor" you like best.
One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers.
The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.
Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).
The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.
Wrong. Without usernamespacing your containers do run as root. If you type `docker run busybox id` it will print uid=0, and that uid is 0 in the container and out of it.
You are namespaced, so the linux kernel promises that even though you're root, you're not dangerous, and there is syscall filtering and shit going on.... but that historically has not really fared that well!
But your statement is false. You're root with and without privileged. Privileged gives you back CAPABILITIES which are different than USER, so your claim is bullshit.
He said "but your containers are not running as root".
That is objectively false.
uid = 0 is "privileged" basically everywhere in the kernel, from filesystem management (reading a file bindmounted in that's owned by root e.g.) to binding to low ports (like 80).
As you can see from the docs, it says "the most important security improvement is that, by default, container processes running as the root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged uid on the host."
This implies the reverse, that if you don't use userns then your process as root in the container will be mapped to a privilege uid on the host.
This is all I'm saying is true. You clearly don't understand what I'm saying.
Could you please give a hint on what kind of stability issues you experienced? Do they still exist? My team is thinking about using Docker for high loaded system in production, and stability is one of our priorities here.
I don't personally operate docker in production, but googling "docker stability" or perusing their github issues should lead to the same anecdotes I'm referring to.
If you'll indulge me putting on my corporate hat for a minute: we've had some customers very happy scheduling a high volume of containers at a high rate on nomad:
Disney probably doesn't need a blockchain, but they do a fair bit of research. Considering Disney already has a relationship with its customers, a centralized system works best. In fact, this is what they're doing now with their wristband payment/identity system. Considering they just invested $1bn into this, I suspect they're going to be using it for quite some time.
While Disney Dollars are no longer produced, I can see them used in other ways. If you haven't been to Walt Disney World (not Disneyland) in the last 2-3 years then you might not know about their MagicBands. They are a RFID wrist band that you basically use it for everything. To get on the Magical Express from MCO, check in at resort, open your room door, park admission, fastpasses, dining reservations, dining plan information, gift shop purchases, etc.
This is less safe than the branching alternatives. Instead of "moving" the original commit, this copies the original commit to a new one and leaves the original one dangling and waiting to be garbage collected.
Also, if you have more than one commit before you noticed you were on the wrong branch, this only grabs the one commit.
Are you exercising? I can't emphasize enough what a difference exercise makes. Try going for a run or at least work up a sweat somehow - I've found it's been an incredible support to my emotional well being.
ujson doesn't error out if you have a collection that isn't serializable so you can lose individual keys. It also has issues with ints and floats that are too big (just fails out)
Don't take it (or at least treat it as an enormous red flag). Only companies in a position of weakness do this, which means there is something wrong with them. My first job I gave in to an exploding offer like that and it did not end well (though it taught me a ton because I got to be a rock star)
BUT - if you really think that you aren't a great programmer AND this job will give you the opportunity to level up your skills, then it could be worth it. (esp if your current job is not programming-related)
Otherwise, leave it in the dust - if you can get a job at 2 places (current job + this one), you can get a job at another place.
> BUT - if you really think that you aren't a great programmer AND this job will give you the opportunity to level up your skills, then it could be worth it. (esp if your current job is not programming-related)
Yes, this. I'm hoping that maybe I can not feel like such a loser for once if I take this job. I'll get stuff done and at least learn something.
