1. 9

    This article is a bit of a rambling rant about threads, setting up a bunch of dubious strawmen, and doesn’t say:

    1. Anything about what KeyDB is or why it has a better architecture than Redis, unless you accept the implied assertion that multithreaded == better architecture.
    2. Anything about unikernels (the word is not even in the article)

    Honestly the title feels like clickbait given how low little it’s related to the article text.

    1. 3

      Thanks for the feedback.

      1. It wasn’t really supposed to be about keydb - that was just used as an example of what would work better (versus redis) - the links and such are edits dzone did. KeyDB was used as an example of showing what can/should be done for future facing software.

      2. Interesting! I wrote an entire article without saying that word - I didn’t plan that - the premise here is that a lot of older nix software (eg: let’s pick on postgresql) is old and not written to excel in a single process (but many threaded) system. I could’ve easily picked apart postgres instead but the keydb/redis was much easier to illustrate the point. Not only that, but developers have been pushed not to advance this style of architecture. My argument here is that if people would adopt this over something that embraces sys-v ipc style we could open up a much better ecosystem.

      1. 1

        There was work even way back when on making concurrency and/or parallelism easier to get right. Here’s some for you to check out in case you find them interesting: Concurrent Pascal (among others), Eiffel’s SCOOP, Clay’s type-safe locks (pdf), ParaSail, and DTHREADS (pdf).

        Since you mentioned Python, I’ll throw in that a few people told me they just used GNU Parallel with their scripts. I’m not sure how they do the integration step if there is one. I imaging pulling stuff out of text files into collections is common for them. GNU Parallel solves the harder problem with a one-liner in the terminal.

        1. 2

          In an unikernel context Parallel wouldn’t be an option. It solves the main job of executing N things yet still in the old create a new process way - that’s what I’m arguing to get rid of because of it’s numerous security and performance issues. Python has many non-trivial limitations (beyond the GIL) that would need to be addressed to have true multithreading. Jython kinda meets in the middle but introduces other issues. I’m not saying any of this is easy - just something to aspire to.

          Going back to how all this relates to unikernels - many unikernels have support for multiple threads but not multiple processes by design. One of the things that needs to happen to make the ecosystem thrive is more keydbs and less redis’.

          1. 2

            Honestly, I didn’t get to the unikernel claims since the article was pretty ranty on the anti-Python, anti-Guido stuff. I’d have made it if you just did a technical breakdown of what older solutions did, what modern hardware does, how it doesn’t fit, and what you were promoting. Those kinds of articles also get more support in general on Lobsters. More potential uptake, too. I agree Parallel itself wouldn’t fit a unikernel but a Parallel syscall might.

            1. 2

              It didn’t really come off as anti-python and/or Guido to me, but that might just be the last year or two giving me a higher bar for “anti Guido” :(

              I don’t care for Python, but Guido always struck me as a really thoughtful, nice guy; those nerds who drove him out of Python should be tarred and feathered.

              1. 1

                for the record I’m neither anti-Guido nor anti-python - that section was really intended to highlight:

                a) the inherent struggle to take advantage of native threads in interpreted languages such as python (it affects most, all? of them)

                b) the time period that certain views get espoused (1998, 2003, even up to 2008) these arguments had technical merit but the advent of real good threads in linux in ’03 and the drive towards many cores/many socket machines during those years really removed those technical arguments imo

                as evidenced in the prior section Go did not suffer this same fate even though one or more of it’s creators had similar arguments for the ability of the average developer to take advantage of threads to the extent that they designed one of it’s core features goroutines as an abstraction around them

            2. 1

              Performance of fork() I can buy, but insecurity? That I do not. In a multithreaded program, one bad reference and the poof! There goes the entire program, but in a multiprocess program, only one process goes poof on a bad reference (remember my days of programming on the Amiga sans MMU). Also, there’s been studies that have down fine grained locking degrades performance just as much as a single global lock (perhaps even more). Also, multithreaded programming is hard to reason about, which is why I personally prefer the actor model (share nothing message passing) over accessing shared mutating state.

              1. 1

                insecurity for this definition means ‘thwarting bad actors’ not making your program crash from a bad memory reference due to programming error - i’d put that in the memory safety camp; also this is in the unikernel (single process) context not necessarily a linux system

                being constrained to whatever you can do in the memory layout of a single executable is quite different than being able to execute random other arbitrary programs because your system is inherently built for that (eg: your average monero cryptominer bot dropper is most assuredly going to come in binary format and prob. written in a diff. language); your average shellcode does just that - pops a shell; for example i’ve yet to see an entire mysql client written in pure shellcode w/no calls to fork/exec*

      1. 11

        because I can compile binaries statically

        1. 6

          This is repeated a lot but almost every time I hear this the people stating this mean something completely different than ‘static linking’ which is what the statement implies (‘compile’, ‘statically’). For instance I see quite a lot of gophers state this as well yet when you look at the binaries libc and a half dozen others are linked in. I’m not stating this is good/bad - that’s a different argument. I just don’t find this to be a factually correct statement and when repeated a lot it is very misleading. If you look at most of the php or ruby interpreters in use you’ll find the situation is even dramatically different since it’s written in c, older, and has quite a few libraries that are written in c and linked in (rmagick, libxml, etc.) Furthermore most of the container shops I’ve interacted with don’t compile from source to begin with. It’s ostensibly one of the main reasons they are using containers to begin with because they seem to find it hard to compile/install the specific versions/libraries.

          To eliminate confusion those that repeat this should probably clarify that they are creating filesystems with known fixed versions of libraries that are in most likelihood 99% dynamically linked (the vast majority of linux binaries are) - not statically linking them.

          1. 2

            So you don’t think people who espouse “static compilation” actually use static linking?

            1. 1

              no I don’t - not in the “single binary completely statically linked” sense - especially with the interpreted languages as I mentioned as they aren’t sitting there and compiling from source and statically linking in all the different libraries to the language interpreter itself - in fact many of the interpreted languages apis that use dynamic libraries aren’t even built that way - many of them are built explicitly to dynamically load - this is easily proven by code - it’s not even really debatable in cases like this - again - this isn’t a right/wrong conversation here - it’s more of a confusion that’s be promulgated and I don’t think OP or any of the upvotes were intentionally trying to deceive - I think it’s one of the many things that dev evangelists from camp container have misspoken quite too often and then posts with titles of “why are you not using containers” appear <– this is a huge reason why

              1. 2

                I certainly wouldn’t want people to use the phrase “static compilation” or “static linking” to refer to an interpreted program… In this case though it seems quite possible that they were referring to compiled programs, statically linked.

                1. 1

                  so the forest for the trees here is that if you are indeed statically linking via say go why would you need docker to facilitate that process? I think the go switches are something like “go build -tags netgo -ldflags ‘-extldflags “static”’” - as I said before, ostensibly the reason why people were using docker in the first place is “it works on my machine” and they weren’t having to guess what version of what libraries were being used not that it’s really common to link in random shared libs to go anyways - that’s not a go idiom

                  1. 6

                    so the forest for the trees here is that if you are indeed statically linking via say go why would you need docker to facilitate that process?

                    i think that’s precisely the point /u/coco was making

                2. 1

                  I do not really understand what you say… for me “static linking” and “static compilation” is the same, but I’m just a C programmer, and distributing standalone binaries that work everywhere usually amounts to adding “-static” to your makefile

                  1. 4

                    nah I was confused - caleb was kind enough to help sort things out; i hear a lot of container folks state this as a reason for using containers to begin with whereas you were stating that it’s a reason why you don’t need containers and that’s completely valid

                    as for this direct comment - generally speaking there is a compile and a linking stage but you’re right if it’s a simple program that can accomplish both at the same time

                    sorry for the confusion

              2. 1

                you look at the binaries libc and a half dozen others are linked in.

                though those libs tend to be fairly reliable and pre-installed on virtually any system, whereas other libraries that might require a separate installation step can be linked into the binary (or perhaps distributed with the executable zip, Windows style)

            1. 4

              Even against the hype machine that is docker/k8s I’d argue there is way more content on doing things “the boring way” - you can go a very long ways with a little bit of apt-get.

              In the past I have used puppet/chef/terraform/shell scripts/etc. to build aws images and just launched manually whatever is needed with plain old ci (jenkins) systems doing actual deploys/rollbacks. I think the concerns about native library compatibility are typically overblown. Yes you have to change base images every now and then but you’d have to do the same in containerland. I’ve never liked the configuration management software out there yet I can see value on larger teams. I think the ci space is pretty straight-forward yet think there is plenty of room for improvement.

              True immutability is rather hard to do unless you severely restrict ssh access. I find people (including myself) will install all sorts of crap if given time and a problem. This can go south when certain tools and I’ll pick on sysdig come with kernel modules or someone’s favorite editor decides to upgrade tls.

              However I truly have not had the horrors that I see with people when they choose containers/k8s. My personal opinion on containers is that if people think installing a given service is such a pain then perhaps they shouldn’t be administering that service (with anything).

              Also I’m heavily involved in a company that is working on unikernel tooling so there’s that. :)

              1. 1

                Well, that’s debatable. I’ve seen so many articles that discuss about the deployment process of a jar file and write in the middle of the the blog post “deploy jar” without any explanation on how they deploy it, where do they put it, how they allow rollback, etc… There’s probably no magic, but I feel that it’s the jungle and everybody has different conventions.

              1. 3

                The link in the description on GitHub: https://nanos.org/ seems to be dead right now.

                It would be nice to have some comparison to existing similar solutions like:

                BTW There is a nice list of unikernel projects:

                1. 2

                  Yeh sorry we’ve reserved the domain name but we don’t have a site for it yet - kinda too busy with other things. I’d imagine that site will be up within a month or so though.

                1. 1

                  It gets me to wonder if it would be possible to use the kernel text console output from the hypervisor for the purpose of logging.

                  1. 2

                    by default that’s exactly what we do currently although we highly recommend for prod services to ship it to whatever log provider is being used (papertrail, elasticsearch, splunk, syslog, etc.)

                    1. 1


                      I spawn daemon | s6-log, with the logger that does:

                      • writing to a file with timestamp for each line,
                      • pattern matching filter useless logs away, or post some lines for further processing (send alerts…),
                      • rotate / compress logs as soon as the written size exceed the wanted size and/or date,

                      This makes logging extremely simple for everyone, flexible, trifial, lightweight, easy to implement, to configure, uniform across all daemons (or qemu vms), ubiquitous (everything have a mode to log to stderr)…

                  1. 1

                    Uh, curl | sh

                    1. 2

                      Well you can always build from github if you’re concerned but if you are downloading programs from a website and you don’t trust the website don’t run the program. We do have open issues for building debs/rpms and such but it’s one of those things that happens when enough people care.

                    1. 3

                      A unikernel is simply an application that has been boiled down to a small, secure, light-weight virtual machine. The resulting virtual machine image does not contain an operating system like Linux or Windows.

                      A unikernel still has a kernel to my understanding… so what kernel is this running?

                      1. 4

                        According to https://github.com/nanovms/ops/blob/master/CHARTER.md it’s the NANOS unikernel, which AFAICT is not open source.

                        Appears to be straight-up spam; this is the only thing @eyberg has posted here and it’s promoting their commercial service without further comment.

                        1. 3


                          How do we know it is secure if we do not see the code?

                          Come on! Show us the code, we want to have fun too! :)

                          1. 1

                            I wouldn’t call that spam cause you can use it for free via OPS. Also, I asked about this on IRC today. What would the difference between posting something about cockroachdb or elasticsearch or redis or any other ‘open source’ tools out there?

                            1. 3

                              Where’s the source for NANOS? I couldn’t find it, which lead me to assume this is not actually an open source tool. If it’s open source and OPS happens to offer a hosting service for it, that’s fine by me.

                              If your sole interaction with the community is to drop a link to your employers stuff, that’s fairly spammy. When a newcomer does that, it feels like they’ve joined for the sole purpose of promoting their company (rather than for the purpose of being involved in the community).

                              When people who are active participants post links to their work, it feels more like a friend saying “I did this cool thing at work, check it out”.

                              Does that distinction make sense?

                              1. 1

                                Nanos hasn’t been officially released yet (look at the version - 0.1.x), no and I don’t know what form (read: license) it will take. However it is free as in ‘free beer’ today and will continue to be so.

                                I didn’t see anything about the rules on the site that mentioned software needs to pertain to a given license. I see a lot of articles that have nothing to do with open source here. I popped on here cause it was mentioned in an article the other day here on /t/osdev -> https://dev.to/yonkeltron/the-coming-era-of-os-kernel-modularity-5emc and I noticed there was no link to the source code of the tool that was mentioned. I’m not an active member of this community as I frankly don’t have the time to be but the tool is open and you can download it for free. Are all parts open? No and neither are most ‘open source’ tools like the ones I mentioned - definitely not according to OSI.

                                If a tool needs to be GPL only on this site please let me know if not I’m sorry you are offended and I apologize for breaking any rules on the site if that’s the case.

                                I’m not trying to fight anyone.

                                1. 5

                                  I don’t care about the licensing. Is the source available? Where?

                                  I read through the repo that was linked, and didn’t find anything that looked like it implements a kernel.

                          2. 2

                            Yes all ‘unikernels’ do have the notion of a kernel even though they might not call it such. We’ve developed a new one that is built with unikernel concepts in mind (eg: no users/permissions/etc., single process, etc.) It clearly has a lot of work to go but it runs quite a lot today in a much safer environment than stock linux.

                            1. 1

                              We’ve developed a new one that is built with unikernel concepts in mind

                              From scratch?

                              1. 4

                                From the bootloader on up yes. It’s quite a lot of work but we felt it was necessary. We used to use Rumprun and OSv quite a bit but kept running into various limitations/issues and decided it wasn’t worth the effort to maintain forks since neither of those are super active (although Waldek is doing a great job w/OSv lately).

                                We’re asked a lot why we didn’t just patch/fork linux and the short of it is because of the same reasons. Linux is measured in the >10M LOCs and it just has way too much stuff in it that is antithetical to the unikernel philosophy. However it’s important to realize that we’re not trying to replace Linux either - for instance we never plan on not running as a vm so half of what linux is (drivers) we don’t need to code/support allowing us to focus in on what really matters.

                                1. 5

                                  Great job!

                                  This response should be the first thing I see when I look at the readme / and/or your business website. I spent ~10 minutes trying to find out what the hell your service does and why I would want to use it - this is the answer I was looking for.

                                  When you open source the kernel, please do post it here also, as it’d be of tremendous interest to the community.

                                  1. 2

                                    “but kept running into various limitations/issues and decided it wasn’t worth the effort to maintain forks”

                                    What issues and limitations were you running into?

                                    1. 3

                                      Well the big one with rump was 32bit only which is a non-starter for most java apps and databases and that opens up a large swath of technical decisions that have to be made (like virtual memory and paging). Also rump is composed with netbsd and so carries that load.

                                      The big one with OSv was PIE only (which is not quite the case anymore but in our exp still has quite a few gotchas).

                                      There are quite a handful of other technical issues but at the end of the day building our own allowed us to do whatever we wanted to.

                                      1. 2

                                        I could see you wanting to slim it down or use 64-bit. I assumed rump was 64-bit given the market. Only 32-bit? I couldn’t find something on the rumpkernel.org site saying that. You got a page from them or a detailed review I can link to as a reference in these conversations?

                                        1. 3

                                          apologies - I might be conflating issues - there was one for the 4G of ram here - https://github.com/rumpkernel/rumprun/issues/74 && for the past few years there was no aarch64 support (arm 64) but the nabla containers folks (ibm) have recently added support for that in the past few months -> https://github.com/nabla-containers/rumprun/pull/21

                                    2. 2

                                      That’s a rather incredible achievement, congrats! (And btw, yes, I think it would benefit you to open source that, since devops people aren’t going to run proprietary kernels if they can help it - at least I certainly have no plans to!). EDIT: consider the AGPL, it’s friendly to server-side stuff.

                                  2. 1

                                    So, given an unikernel is running on a hypervisor (qemu in the case of ops), it is basicallg a highly privdropped restricted process (a qemu process) security-wise?

                                    If a process has no exec(), and runs as non-root in a chroot, with further restriction on which syscall it can do, it might still be more complex from the inside (it listens for signals, interacts with virtual filesystem, have the large kernel mapped in memory…).

                                    But a unikernel runs on top of an hypervisor, that is complex itself!

                                    So, the point is not to remove the system complexity, but rather to move the complexity away from the application being developped downto something not in user’s (or attacker’s) control?

                                    On the other hand, running application onto a docker host OS onto a hypervisor /is/ more overhead than just the unikernel directly onto the hypervisor with maybe some orchestrator that tell the hypervisor to start and stop unikernel VMs.

                                    What about re-writing Ops as an unikernel with an authentycated TLS/SSH protocol?

                                    So, do you expect people to run Ops on a bare-metal Linux (in order to reduce the stack) ? Otherwise, it is adding a layer on top and not removing one. ;)

                                    I like this quote:

                                    layers are only ever added, never removed

                                    – apenwarr’s colleague

                                    1. 3

                                      Qemu is utilized by ops cause it’s the most common machine monitor out there, however there is no reason why we couldn’t roll in support for something else and intend to do so. Google made their own monitor that interacts with KVM that provides GCE mainly cause the qemu codebase is huge and supports everything under the sun.

                                      As for the stack, no, OPS is intended mostly for those who would wish to deploy their applications to the public cloud - AWS, GCE, Azure, etc. although any ‘cloud’ (virtualized) environment will work. For instance when you spin up an instance in Google with this it creates a raw GCE image that does not have linux in it and we assume the majority of these users would be using these platforms.

                                      I guess to be more explicit - this tool is designed more for everyday ‘work use’ like terraform or puppet for compute environments that have many machines to handle that you would find in companies versus a hobbyist use (ops -> devops). I wouldn’t run this locally for dev purposes but for production deploys. Not sure if that makes sense?

                                      1. 2

                                        “But a unikernel runs on top of an hypervisor, that is complex itself!

                                        So, the point is not to remove the system complexity, but rather to move the complexity away from the application being developped downto something not in user’s (or attacker’s) control?”

                                        If hardware support exists, hypervisors are more fixed purpose with way less complexity and code than monolithic kernels most people use. They just don’t have to do as much stuff. From there, they can be designed minimalist fashion easier to verify for correctness (eg Nova microhypervisor) or security (eg seL4). The cool thing is the isolation paradigm they implement can then pay off in all kinds of use cases.

                                        On top of that, you then add the minimal amount of code necessary to support the application. Being small and clean slate, one might even use memory-safe language for it (eg MirageOS). That mitigates lots of attacks itself. Ideally, the API’s would also be made for developers to use them securely by default. From there, the extra failures show up in just the code the developer added in a nice box the hypervisor provides.

                                        Disclaimer: Assumes hardware is secure. Little reason to think that. People should still try to get stuff above hardware right.

                                        1. 2

                                          Yes - you got it. In this security model the user and the attacker are treated much the same - again this assumes the infrastructure is either managed (aws/google cloud) or private (openstack/vmware/etc.). I think we crossed the rubicon a very long time ago when even small 20 person engineering teams have hundreds of vms they are managing. One linux is hard enough to secure.

                                          As for hypervisors - we already have unikernel tuned hypervisors - IBM even has multiple patents on it. https://patents.google.com/patent/US9886303B2/en

                                          As for hardware yes and no. You can “assume” it’s secure cause if someone can easily go around rooting vms on AWS we have some fairly serious issues to deal with. Having said that I agree that our current hardware is fundamentally flawed and this won’t fix that but I also contend we are stuck with it for a while.

                                          1. 2

                                            You can “assume” it’s secure cause if someone can easily go around rooting vms on AWS we have some fairly serious issues to deal with.

                                            I assume they’re doing something different than most other groups that their resources allow them to do. It may or may not reduce their odds. They might also have better monitoring and response. What AWS deals with is not equal to or doesn’t extrapolate to what average company with virtualization can do. Maybe not even F/OSS virtualization since their local modifications might improve security.

                                            So, I look at what the open products and many closed claim they do, the nature of the dependencies (esp shared resources), and the odds of leaks coming through them. The odds were high. It’s why I advocated for physical separation where possible on embedded-style boards. The leaks keep coming on server CPU’s.

                                        2. 2

                                          Many people have accepted the hypervisor as an implied part of their stack; in that case removing application/kernel separation means higher performance and less abstraction.

                                          1. 1

                                            Or even unikernel on bare metal!

                                            I think that what we often ask for when we use a hypervisor is an array of similarly manageable machines that we can spin or stop.

                                            It would be interesting to get unikernels spawned via PXE boot on a couple of managed hosts. Bare metal metal.

                                            Spawn a unikernel on hardware like one would spawn a process. More, smaller machines.

                                            No vertical scaling though…

                                    1. 2

                                      What gives it that security?

                                      Single Process

                                      Oh yes, process isolation is definitely not a security feature (/s). And of course no word about binary exploit. What about an attacker that can jmp into the whole kernel code ?

                                      No Users

                                      Oh no, users privilege separation is definitely not a security feature (/s). If we remove them we can’t bruteforce their password. We immediately log in as “god” instead (better than root, you’re the kernel).

                                      [the shell,] It’s an antiqutated concept that only lends it’s hands towards those who want to do your company harm.

                                      So you are adressing this speech to company-owners that have no idea of how UNIX-style computer works? I noticed that when you offered to expose kernel memory address rather than the system shell. But no shell means harder for an attacker to exploit an existing breach (or an admin to debug), true.

                                      Reduced Attack Surface […] Less code == less exlloits

                                      You made a point here. Kudos.

                                      1. 2

                                        P.S.: I still like the idea of unikernels.

                                        1. 2

                                          Not sure about the first point but to elaborate there is a single process and no facilities to create another process (no fork/exec). Also, unlike other unikernels we actually do have the concept of cpl0 and cpl3 and have opted to utilize vdso style ‘speedups’ where it makes sense. Also, we are explicitly addressing ‘binary exploits’ (eg: shellcode).

                                          As for users - you can’t login to these - at all. There is no ssh/telnet. Half the user syscalls are merely stubs. You can’t su/sudo. The entire concept of a shell doesn’t make sense in an unikernel since it already means you intend to run multiple programs.

                                          While this can execute linux programs I would be hard-pressed to call it a unix.

                                          If you are curious about more of the security properties I wrote up a short blogpost on it that is more technical.


                                          1. 2

                                            From that blog entry (which I certainly wouldn’t accuse of being “technical”):

                                            This is reminiscent of the “unikernels are un-debuggable” points brought up earlier. This is funny too considering one of the authors started working on an [sic] unikernel specific debugger…. For real.

                                            Is that a reference to my blog entry on unikernels being unfit for production? On the one hand, I can’t imagine it is – I am certainly not engaged in any unikernel debugger, and my piece was clearly single-authored – but on the other, I don’t know what else this could be a reference to. Could you clarify?

                                            1. 1

                                              hi Bryan :)

                                              It wasn’t directed at you. One of the NccGroup authors of the paper in question ended up writing a unikernel debugger because at the time there was no gdb stub to hook up to whatever implementation he was looking into.

                                              1. 1

                                                Is it not easier to debug when the source is fully available ? * hum hum * ;)

                                            2. 1

                                              Nice to know there is some privilege structure that remains. The article linked talks for itself.

                                              But I get the idea : noone will ever log (or break) into the kernel and an attacker will have to think again (I still don’t consider SSH with a strong key and no password a large threat).

                                              It looks like a reversed approach: instead of dropping privileges as the program goes (changing for a different user than root, chroots, pledge, capabilities, read-only filesystems…), do not expose the vunerable resources on the first place: filesystem privileges can be implemented by a fileserver in which the unikernel logs in, or that only expose (or have at all) the data the application is allowed to access.

                                              But there are many cases where there is a need to parse complex strings (risky) theb do something, then send the result back.

                                              To mitigate the risk, it is possible to split the job into multiple processes : one that parse, one that does and send back, so that the risky work of parsing the user input gets done in a separate memory space and process as the one that have full access to the protected data.

                                              How to do this with unikernels? Many tiny unikernels with networking to communicate rather than a pipe()fork()? Then there is a need for strong firewalling between the two or implementing authentication and crypto for every pipe replaced. This adds complexity and TCP overhead and require more configuration so that the two point at each other.

                                              Yet it permits a much more distributed system where it is possible to have a lot of distributed parsers and a few workers or the opposite.

                                              1. 1

                                                Threads! Maybe there is some way to limit privileges per thread (I’ll read the doc). Then while it is still the same memory space, one thread that have no network access, one thread that have no storage access. Woops, am I baking thread-ish processes? Not the good approach for unikernels…

                                                I’ll think again…

                                            3. 2

                                              In my part of the industry most software is deployed into a vm where it is the only thing running. Having access to that one thing is functionally equivalent to getting root on the box.

                                              1. 1

                                                In my part of the industry, it’s all vms running debian running apache running php running a framework running a website. In my part of the industry clients get their wordpress plugin hacked in multiple ways every day. I’ll probably quit my part of the industry.

                                                At works, things are managed from the inside of the system. Each have an agent that does the monitoring (a la puppet).

                                                But for every hack I’ve seen (not that many, it’s not on me to spot them…) there were basically no attempt to get root.

                                                1. 2

                                                  If you’ve already gained control of the website, what point is there to getting root?

                                                  1. 1

                                                    Yes, exactly! Not that much point!

                                                    Well still, attacking other machines, take over the infrastructure some more or attacking the hypervisor (VM escape)… But I bet the main target is taking over “whatever the client is doing” (taking over the application running as non-root).

                                            1. 2

                                              Another question I’m curious about: the website says that unikernels are faster because there’s no scheduler. But doesn’t the idea of running several unikernels still require for there to be a scheduler … somewhere? And so there must be a scheduler still, just moved up a level? Can you comment on the difference (if there is one)?

                                              1. 4

                                                There are two ‘schedulers’ here and one of them is something that is implementation specific (there are north of 10 different unikernels out there today).

                                                At the app/kernel layer we definitely support multiple threads but it’s single process (since there is no intention to run other programs). There are also single threaded unikernels out there. Some would consider that more of a purist style, however, we find that limiting since most people coming from a linux world, even using a single-process, single threaded program would still have access to multiple threads inside the kernel. Whether you go cooperative vs pre-emptive threading is kind of a different argument but a great (recent’ish) paper on the subject discusses problems with the way Linux does things https://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf . I point it out because again - Linux was built with the implication that it would be running on bare metal supporting multiple programs ran by multiple users - these constraints are broken when it’s one application per vm.

                                                At the orchestration/vm/cloud layer that is done with tooling around the hypervisor. If you spin up a unikernel using OPS on google cloud for instance you’ll spin up a GCE image and google cloud runs a modified/forked kvm. So they will schedule that vm as they see fit on their servers. You the user can then orchestrate several of them together (eg: a database, a webserver, a background worker, etc.) into the same vlan using higher level orchestration tools like ops or terraform or some other yet to exist tool.

                                                So scheduling in these two senses can be like physics - what works in newtonian can be radically different at the quantum level.