int0x80

IA32 is probably not getting all the focus from devs and users this days, still surprising whoever... Do you have a link to the issue, out of curiosity?

This is not primary about static checking. This is mostly a guarantee to the implementation so it has information at the target function so it can generate better code without having to resort to derivations or complex data flows (to optimize, basically).

One way is to over-allocate in the first place. When your spare pool is draining below a watermark, you scale in. Hopefuly there is enough time for that scale event to complete before the pool drains completely.

Any reference to this "holy grail" problem?

To me this is 'just' an optimization. If sorting by ID means 'sort by creation time' then you are just optimizing a timestamp in an entity. Overloading the ID, IOW. For the 'create the ID in the app' yes, but that is orthogonal to the ULID, AFAIK.

I agree here. But they just want to cover their asses I guess.

Yeah.. I think I see what you say, I mean, the end user interface is the quite the same but this has big implications anyway for the systems design POV, so is not a small thing :)

That is one big difference, with big implications.

With LUKS it doesn't matter. But not all encryption methods are like that. That was just really an example of potential differences. In fact, when this (Dropbox dropping non ext4 support) happened the problem that triggered this was encryption related IIRC.

In principle I agree with you, and many could argue the the app is broken. But in all fairness it is not so easy. Then there are lots of little details and corner cases where filesystems that implement a POSIX fs have slightly different semantics. This is important for example when dealing with sync'ing files to disk/backend. Encryption is another problem. Error handling. See for an example the annoying details here:

https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/

It's not profitable /or/ you are just going for the short-term and easy way out of the problem.

That code sample is outright ridiculous, it is totaly out of control. Can't agree more.

>Python has smoother installation than Java and GCC

How so? With java you can get your distro version from the package manager or just download a tarball and setup your PATH. Maybe install maven. GCC and build deps is as simple as a xxx install build-essential/build-base and you have a C compiler for C89/C99/C11.

There is mmap for read/write (some of the most used syscalls).

There is also the vdso page [1] for things like gettimeofday etc.

[1] http://man7.org/linux/man-pages/man7/vdso.7.html

It is possible. As you say, not completely problem free and indeed has raised some discussions regarding security implications. AFAICT documentation is scarce (non-existent). Here is a previous patch prepping for this one, with sample code to both submit/reap events: https://patchwork.kernel.org/patch/10712819/

Yes. Instead of using a syscall to get/issue events you use a mapped ring buffer. See https://lwn.net/Articles/743714/

The kernel handles the IO. You just don't need to enter the kernel (syscall) to issue it, it is done via a kernel<->user memory mapped ring buffer. Roughly, I don't really know the details well. See https://lwn.net/Articles/743714/

Both?

I think an 'error out if overflow/truncation'-mode available as a command line flag could be useful if you just don't have any JS involved in the JSON pipeline.

It makes sense (to me) and it has been discussed. I don't know what was the conclusion though.

Maybe. But KGDB and friends do exist too in Linux. And (AFAIK) not everyone likes using those, some just like throwing a few printks here and there. That is not universal obviously :) My point is that yes, unikernels may not be as easy to debug etc at this point as regular usermode code, but it is something that can be worked around and I think if people begin to use them in-mass frameworks and solutions will emerge.

That an also to avoid posibly revealing internals and details of the designs/architecture/etc to non-intel people.

Exactly my thoughts :)

Also: the F22 datalinks are incompatible and can not easily interoperate with the F35 ones. That problem sound familiar too.

I think that can be solved by good tracing and logging facilities. Both of which are already available in Linux (eBPF, ftrace, tracepoints, perf events...). You may have to customize them or polish them further though and provide more user friendly interfaces/frontends for them.

It might be wrong though, even if common. That might explain a few things in fact.

Ahh sorry, I understood the other way around :)

They can do right now. Both the API and ABI are very rarely (read never but very problematic bugs or similar) broken in a backwards way.

I was talking about the italian pronuntiation.

It is not too bad, but is not 'Maelan' but 'Meelan'.

1- Host your blog.

2- Write post.

3- Post to multiple aggregators (HN, reddit, etc)

It can even be made (semi)automatic.