It is not an alias, but my zsh config does this really nice thing where “if a shell command completes when the terminal is not the foreground window, it sends me an alert that I can click to bring that terminal to the foreground”: https://codearcana.com/posts/2013/06/11/my-zsh-theme.html
I participated in the discussion when it was new, but I don’t think it’s going to come back to life unless BradFitz feels like it. Seemed like a labor of love and then he got busy with other stuff.
It is a coroutines implementation with a selector based on Duff’s device, all wrapped into a few macros. That’s why you can’t use switch statements in these async bodies.
Is there any way to recover the use of switch statements? At first, I thought you could insert braces into the macros, but I’m not sure if that would work.
We’re looking for people who’ve written code and cared about production to help us lead the Revenue SRE team (either as a manager or as a tech lead).
Twitter’s revenue organization operates services at massive scale. We are looking for engineers who want to build beautiful, simple tools and services to help their colleagues safely release code into production. We serve a diverse and growing set of customers who rely on you and your team to reliably and quickly develop features. You will be responsible for helping colleagues to run the largest production services at Twitter and support almost $3 billion in yearly advertising revenue.
Contact: Company policy requires you to apply through the career link, but you can also email ${MY_HANDLE}@twitter.com
That’s exactly what I’m talking about. The author is not a civil engineer and is speculating on how people build bridges. I’ve only met one person with the relevant expertise and they thought that koan was cringingly wrong about how bridge building actually works.
Hence why I want to survey people who’ve been in both worlds and find out what the actual differences are.
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.
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.
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?
It is not an alias, but my zsh config does this really nice thing where “if a shell command completes when the terminal is not the foreground window, it sends me an alert that I can click to bring that terminal to the foreground”: https://codearcana.com/posts/2013/06/11/my-zsh-theme.html
https://github.com/awreece/prezto/blob/76c70b21d8f6d1f3e5f731fa4040e1a2ff49b702/modules/notify/functions/notify_last_command#L25
It also does a lot of the other nice things, e.g. coloring prompt based on success/failure and showing execution time of last run command.
Heh, reminds me of https://codearcana.com/posts/2015/12/20/using-off-cpu-flame-graphs-on-linux.html (where we discovered that using mmap for file io caused our dbms to contend on the virtual address space lock for our process in the kernel).
Update: the paper actually cites that blog post!
You should really contribute some of these ideas to the discussion in the Go community about the HTTP client!
I participated in the discussion when it was new, but I don’t think it’s going to come back to life unless BradFitz feels like it. Seemed like a labor of love and then he got busy with other stuff.
Turns out lay people can get through this, if given the right coaching and the wrong information: TurboTax apparently didn’t bother to sign their binary, so the official docs tell people to go down this route D: https://ttlc.intuit.com/community/troubleshooting/help/turbotax-for-mac-won-t-open-when-installed/01/26611
You’d expect that a big company (software company even) would find someone to go through the trouble of properly signing the binary, …
Has anyone else looked at the code? How does https://github.com/naasking/async.h/blob/master/async/async.h accomplish this? Is today April fool’s day or something?
I think it might be based on https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
It is a coroutines implementation with a selector based on Duff’s device, all wrapped into a few macros. That’s why you can’t use switch statements in these async bodies.
Yeah, it’s pretty clever!
Is there any way to recover the use of switch statements? At first, I thought you could insert braces into the macros, but I’m not sure if that would work.
Company: Twitter
Company site: https://careers.twitter.com/
Position(s):
Location: San Francisco or Boston (USA)
Description:
We’re looking for people who’ve written code and cared about production to help us lead the Revenue SRE team (either as a manager or as a tech lead).
Contact: Company policy requires you to apply through the career link, but you can also email
${MY_HANDLE}@twitter.comI’d also ask if you had any certifications in either. I’ve seen more emphasis on that in Other than in software.
Also, http://thecodelesscode.com/case/154
That’s exactly what I’m talking about. The author is not a civil engineer and is speculating on how people build bridges. I’ve only met one person with the relevant expertise and they thought that koan was cringingly wrong about how bridge building actually works.
Hence why I want to survey people who’ve been in both worlds and find out what the actual differences are.
I love monodraw, best $20 I ever spent. https://monodraw.helftone.com/
To actually view the questions they want me to sign up to their email spam list.
Strange, I was able to see ~5 questions without.
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.
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.
The clean layer of abstraction is the type system of whatever the unikernel’s written in.
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 hito work, butalidoesn’t use traditional alias syntax. Worse, I got no error message and was just confused when there was nohifunction registered. Perhaps a warning if the command contained a=would be helpful?