Never Split the Difference – Chris Voss. Should be required reading for people expecting to negotiate, e.g. those doing job interviews.
Hyperion – Dan Simmons. Great science fiction, best I’d read in years.
Tell me how it ends – Valeria Luiselli. Heartbreaking short non fiction.
The most important thing – Howard Marks. Fantastic advice on investing from a bond guy.
Crossing the Chasm – Geoffrey Moore. Should be required reading for anyone at a startup.
Why would you post the answer to a homework assignment online?
The homework from CMU 15-213 is not the same binary used in this series. I’m using the “self-study” from the CS:APP website. If I recall correctly, each CMU student taking 15-213 receives a unique binary as their homework but I have no details about what is the difference between them.
Not everyone on the internet is a CMU student so others might benefit from reading the posts and maybe learning a little bit in the process.
he’s right that you don’t get dtrace and so on, but on the other hand, the need for dtrace is largely driven by the profusion of complexity of the modern operating system. Saying “hey, instead of having eighteen layers of abstraction, how about we just try eleven?” may not get us all the way to nirvana, but it’s a better option than doing nothing at all.
A unikernel is usually more layers of abstraction. Now instead of your userspace program inside the operating system, you run your unikernel inside qemu inside the operating system: https://youtu.be/ZBcMy-_xuYk?t=22m13s
The need for dtrace, etc is because systems are weird and hard. If you are using TCP, filesystems, etc, you’ll be using that logic in your application. A unikernel merely bakes it into one package rather than providing a clean layer of abstraction for you to reason about and debug.
I would say it’s usually less, because the “usual stack” in this context is (metal -> hypervisor os -> vm -> application), and what unikernels permit is instead (metal -> hypervisor os -> unikernel). I agree that if you just slathered unikernels on top of existing os or vm stacks, you’d be adding more crap.
As far as dtrace et al, it’s my belief as a 35 year Unix veteran, and I think you’d agree, that our systems are weird and hard at least in part because there are so many abstraction layers in between a given packet and a given response packet, and many of those abstraction layers have been written at different times, by differently skilled developers, in persnickety languages, using inadequate tooling. And that in fact dtrace, et al., are immune-system-style responses to that problem; that the systems fall over so unceasingly, so dramatically, and so grotesquely that people literally spend their entire lives creating complex DSLs to try to figure out where the tire fire fell over this time.
But let’s pretend for a minute – and I admit, this glorious future is not here now, not yet – that we boot up a vm into a kernel which exhibits the M:N qualities and actor model of Erlang, the type system and provability of Idris, and the capabilities model of (e.g.) Pony; and that the hypervisor is also written in this or a similar language, and provides a clean API and (literally-)proven drivers.
Given that universe, what use would any normal human have for dtrace or any other deep surgical tool?
So I see the unikernel idea not as a replacement for processes, or as yet another abstraction layer like docker, but as a way to start making up for the obvious flaws in docker (and lxc, jails, etc.). It may be a long road, may never get there, but it doesn’t hurt to start trying.
I agree that if you just slathered unikernels on top of existing os or vm stacks, you’d be adding more crap.
Note that “posix compatible” is often a selling point. Combining libos and app in the same address space doesn’t do much to reduce abstraction. (Of course, there are systems which forego compat too.)
true, but that’s because the early providers want early adopters, and the way to get that is to be close to their current needs (or, like some popular programming languages, to suggest it’ll be in 1.0). The more adventurous attempts, like Ling/L and Mirage, forswear that pretty comprehensively. I wager the paradigm will eventually settle at a place where many of the useful posix features are either provided or simulated, and most of the crappy ones with underspecified behavior fall by the wayside.
A unikernel merely bakes it into one package rather than providing a clean layer of abstraction for you to reason about and debug.
The clean layer of abstraction is the type system of whatever the unikernel’s written in.
but on the other hand, the need for dtrace is largely driven by the profusion of complexity of the modern operating system.
But that isn’t quite true. dtrace is effectively a standardized way to do printf debugging, but more powerful, and printf debugging is valuable basically anywhere.
But let’s say you’re right, systems are too complex, which I mostly agree with, in what way are Unikernels actually solving that?
For most problems people hit, the bug is in their own code, not the OS or surrounding system, so removing all the surrounding layers doesn’t necesarily fix that and making it difficult to debug doesn’t make anything better. There is also this whole movement to move Unikernels into containers which I don’t really get, but at least you have all the debuggability of an OS there, I guess, but that is making the whole system more complicated.
I would say that anything that reduces the mental load is important. Check THIS out: https://medium.com/@MikeRyan52/angular-2-first-app-post-mortem-b2b2b3618828 and now imagine that you have to understand all that nonsense, plus html, css, nginx, (say) node.js, (cough) systemd, …
Pretty cool. When I downloaded and tried to use it, I found the interface to be mildly surprising. I expected ali define hi=echo hi to work, but ali doesn’t use traditional alias syntax. Worse, I got no error message and was just confused when there was no hi function registered. Perhaps a warning if the command contained a = would be helpful?
ali define hi=echo hi