DblPlusUngood

Never before have I been so eager to shoot potatoes into the sun.

Obviously a direct translation from English to Russian -- I doubt a Russian would ever actually say this.

They should change it to: молодец.

"Thousands of cycles" is definitely not true on modern CPUs. SYSENTER/SYSEXIT takes 150 cycles on my Xeon X3460.

The space overhead is significantly worse for native threading in the presence of many threads since each thread needs both a user and kernel stack.

For M:N, there are N kernel stacks.

SIG_IGN is not the same as the signal mask.

The result is the same though; I forgot that signal mask is not reset on exec. Damn POSIX signals!

Why is setting the signal handler for SIGHUP to getpid preferable to masking the signal?

Linus' reply: "I detest these patches."

https://lkml.org/lkml/2016/8/2/1589

Why do you say "non-standard"? O_NOFOLLOW is specified by POSIX.

It would be great if you could provide specific reasons why FireEngine is able to avoid the overheads which other projects avoid via kernel bypass.

> The advantage of this construct is that you can use the flags set by the increment to test for loop termination, rather than needing an additional comparison.

I don't understand your optimization. ZF is also set for dec, so why not just use dec and not negate the size?

My point is simply this: maybe the author wanted to write an OS that he could use on his PC without rewriting all of his programs.

Maybe he did not want to do OS interface research.

My point was to compare TOC to "typical generational collectors" (i.e. those using card-marking, which is common).

My point was not that TOC is fundamentally different from generational collection.

Tenuring the young object in the write-barrier is not correct since the the young objects reachable from the newly-tenured object won't be marked in the young collection. That is why TOC then traces this newly-tenured object, which is novel to my knowledge.

Indeed, as you say, write barriers precisely identify old-to-young pointers at the time of the write. But most collectors defer tracing and track this old-to-young pointer in a card-table, which results in lost precision i.e. now the collector only knows that some object in this region has an old-to-young pointer.

It sounds you like you asking for more toy OSes.

Supporting POSIX is necessary if the designer wants the OS to run real software.

Interesting. The transactional hypothesis sounds like a refinement of the generational hypothesis.

Seems like the main advantage of this transaction oriented collector over a typical generational collector is that it precisely identifies the old-to-young pointers and thus may scan less total objects.

Here are even more names for this fallacy: tu quoque and whataboutism.

I would be much more excited about contraptions that were more obviously useful and less about providing a special "experience".

Ah, the classic false equivalence argument.

You can expect at least one in any thread criticizing any country that isn't the USA!

Synchronous systems have the same problems you describe in your first paragraph, but worse (they tolerate less failures), so I'm not sure what you're trying to say.

I don't buy the rest of your post for two reasons. First, partitions are not only problematic for writes. Externally consistent systems also cannot generally serve reads during a partition either. Furthermore, it is not true that partitions are not a realistic worry - i know of at least one large system that encounters partitions on a weekly basis.

Second, you seem to be arguing that for some reason it is easier to solve consensus at the application level. This is simply not true, otherwise we wouldn't have consistent databases.

What exactly do you mean by "synchronous"? Do you have a particular system in mind?

If you mean "block waiting for all replicas to respond", then the failure mode is quite different from Paxos. I don't know of one such system that can tolerate two simultaneous failures or network partitions, unlike Paxos.

If you don't care about tolerating a single failure, then yes, pretending the network is synchronous can simplify your system.

I find it extremely amusing that after going through all the trouble of building the malware+infrastructure to sell keys, the authors couldn't be troubled to write the 5 lines of assembly code to enter protected mode. You can even leave paging off!

Hardware support for tracing branches is useful when the profiler cannot unwind the stack of the program being profiled (like when the binary is stripped and stack frames have been optimized out).

As a longtime OpenBSD misc reader, it took me a few minutes before I became convinced that the OP was joking.

These are a lot of fun!

The doom marine in me demands a poster for Phobos!

It is both terrifying and amusing that rm'ing files in /sys can brick my Linux machine.

I find it even more worrisome that some compare this mistake to accidental clobbering of /dev/sd?.

Here's another story: I was optimizing the performance of a small, in-house x86_64 OS on a specific benchmark. I spent many months finding and removing/improving bottlenecks.

Once the performance was similar to competing OSes, the measurements from my performance experiments were varying by 30%! This was surprising because the benchmark was simple and the performance of competing OSes was completely stable.

Well after three or four days of frustration, I discovered that the problem was our test hardware: for whatever reason, immediately after BIOS POST, any memory loads executed for the next 10 seconds were 30% slower than memory loads executed almost exactly 10 seconds after BIOS POST. Initially I was shocked, but this may make sense -- it seems plausible that hardware manufacturers would run initialization code in the background resulting in quicker boot times.

Anyway, after we figured that out we simply waited 10 seconds after POST before we ran any experiments. I'm curious how common this slow-for-the-first-10-seconds thing is with other x86_64 machines.

Edited for clarity.

For your enjoyment, a screencap of UEFI dumping core on a fancy Dell "server class" machine during bootup:

http://i.imgur.com/YpOQXet.jpg

Work required that I restarted this machine frequently -- it would fault during boot probably 1/20 times.

I agree that Paxos is much simpler than many people apparently think. It certainly didn't help that the original paper is almost completely useless for learning Paxos.

I highly recommend that anyone interesting in learning Paxos study this pseudo code from MIT's distributed systems class; it was the single thing that helped me understand Paxos most:

http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html