jagger11

As for the conflicts you'd decribed, some of them were conflicts without clear aggressor (e.g. Polish-Czechoslovak conflicts of 1918) typical of those times, some were misdeeds of Polish state (annexation of Vilnus and Czechoslovakian Zaolzie in 1938).

Soviet Union decided to attack, it lost the war, it had to ceede territory.

- The territorial gains of Poland in 1919-1920 materialized, because it won a war started by the Soviet Union

- Curzon line was proposed/described only in 1920

- Those lands (that you described as conquered and re-conquered) weren't Russian etnically, more like Belarusian, Ukrainian, Lithuanian, and Ruthenian

- (edit) The secret pact (Germany-USSR) didn't say Soviet union will recover the territorial gains from 1920-1921, but that it will occupy Eastern Poland (east of Vistula River), making it effectively partition of Poland, so no Curzon line here too.

PS: Please reply if you'd like, and EOT for me. This whole centithread started because I wanted to display that the current Russian historiography is heavily biased (way more than other "western" countries) towards minimizing its own misdeeds, and portraying them as innocent, normal or justified.

Versailes declaration (FR, UK, IT), with support of Polish statehood - June 1918 / End of WW1 - November, 1918 / 2nd Polish Republic established - November, 1918 / Start of Polish-Sovet war - February, 1919

PS: I like sharp counterarguments, but I guess it cannot go as "P1: We did wrong! P2: What about that time you did wrong?"

PS: In 1919, it was USSR who fought the war on Polish ground, and lost. I don't think you'll find too much material to play moral high ground here.

The Russian version is titled: "Polish march/hike/walk of the Red Army (1939)", and Russian speaking Wikipedians don't like the idea of changing the title.

> I mean, linker tricks à la LD_PRELOAD, DYLD_INSERT_LIBRARIES are a lot less work than rewriting code. They don't even require a recompile most of the time.

Thanks. Also, simply providing static symbols during compilation should work (in most cases), as typically a static linker will only pick up the first provided and referenced (yet undefined) symbol.

Probably even a more "stable" (less conflicting) solution would be to use -Wl,--wrap=symbol and then provide __wrap_symbol() sandboxed definition. Agree, this all doable one way or another, and we might take a look at it at some point (we'll be glad to receive any input on that, preferably on the project's mailing list).

Thanks for those ideas - some early comments on those below:

> symbols could just be all prefixed

IMO, this wouldn't be conceptually different from how it works now - i.e. calling function through a C++ object. IOW: code using sandboxing "printf" would have to be changed to use "_sanbdoxed_printf" somehow (via code or linker tricks). Unless you mean something different here?

> File descriptors could be indicated with an annotation or simple function call.

Similarly to the problem above - it's probably in line with how it works now. It can definitely be simplified (even with a simple annotation "somewhere"), but again, that wouldn't probably solve the problem of having drop-in library replacement IMO?

> use a special allocator for anything that's going to be passed to the sandbox, and putting that memory onto an exchange heap ala Singularity.

Yes, that's something we're thinking about, mainly for performance reasons. As you certainly know, it will be more complex than simply having malloc()/calloc() (and friends) operating on a shared mmap(), as memory referenced can also include stack/bss/rodata/direct-mmap etc. etc.

These are all good ideas! Thanks for sharing them - in case you'd like to comment on them more, I'd like to invite you to do that on the project's mailing list.

PS: It might also be here that you might be thinking about something slightly else. I.e. moving all annotations wrt memory/file-descriptors into some middle layer, and then exposing identical-to-the-original library API. This is probably possible, even now, with some extern "C" magic, though there are no examples or tooling on how to do that yet.

The sandboxed library is indeed exec'd (it's a separate binary), so the only "secrets" that leak into it, are those which are already there - compiled into the binary.

As for fork/exec: the idea is to preserve the execution context as long as possible - if data leaks between sequences of library API calls are not a problem (e.g. because we just convert some data for internal use), then forking/execve is not necessary. The idea behind 'transactions' (as per Sandboxed API nomenclature) is just that.

If potential data leaks between API calls might be a problem, then a fresh instance is spawned via fork (no execve is needed here though).

It'd most likely lead to symbol conflicts, if you'd like to both use the sandboxed library, and the original (unsandboxed) one, even for constants / defines.

The other problem is memory synchronization: typical programistic run-times don't provide info on whether a given memory pointer points to memory which will be read only by the library, or maybe will be updated, or both (const-like annotations are rarely conclusive here), hence some additional work will always be needed to correctly wrap a library function. Also, file-descriptors are just integers, and it'd require a heuristics to figure out when file-descriptor sync between the main code and the library code is needed or it's just a pure int which is used.

So, no, a fully automatic library interface would be quite impossible, at least without some kind of heuristics, and this would be error prone.

PS: One of the main ideas behind the project is represented by the motto "Sandbox once, use anywhere", so technically only one implementation of a library API is needed for all users using the same set of functions.

Therefore his predictions are not that much original research/predictions, but rather a good compilation and clever choice of ideas which had appeared earlier in various sci papers. I suspect his quite striking description of "Kindle reader" from 60s was based on some previously read paper/article. Still, it's a very very good prediction as for 60's.

To add to his "predictions": Golem XIV is a philosophical desciption of technological singularity (from 80's), and his Summa Technologiae (from 60's) tackles a ton of then veeery novel stuff, like Machine Learning (a precise description even for today's standards), SETI research, VR, AI, and all of that in a "scientific" way, i.e. concreete and directly based on then published papers, and not simply made as an effect of extrapolation of then current trends (sort-a what Asimov liked doing)

It's from the 60s and contains strikingly good predictions on AI, SETI, Virtual Realities, nanotechnology, multiple universes, the future of our civilization etc.etc.

Also, if you're a fan of R.Kurzweil and others predicting the technological singularity - reading Golem XIV (from 80s.) - https://en.wikipedia.org/wiki/Golem_XIV - is a must.

https://youtu.be/lfg3jHV1TzE?t=246 https://youtu.be/9bfgEgFKccw?t=3

A small correction, it causes for the syscall not to be executed, and return with errno==ENOSYS

Wizja Lokalna (eng: Observation on the Spot, ger: Der Lokaltermin) is my favorite Lem's book. Unfortunately it was never translated to English AFAIK.

Personal anecdote:

I'm learning currently German (b/c living in a German-speaking country), and I chose "Der Lokaltermin" as my book of choice to work on with my teacher. After a year we're on the 9th page. (no worries, book is just small part of our lessons)

The reason for that is that the beginning of the book is full of utterly useless in everyday life words and sentences :) For example, I know how to say in German: "Two heavily-sweating midgets, after eating oily pasta, kidnapped me from underground parking because they suspected I'm the Princess of Pedimonte, then they asked Vatican for ransom money"

Possibly the first prosaic take on singularity from early 80's (computer AIs improving themselves ad infinitum): https://en.wikipedia.org/wiki/Golem_XIV

All of that in his Summa Technologiae from 60's (SETI, AIs, Virtual Realities): https://en.wikipedia.org/wiki/Summa_Technologiae

Steinhaus was Polish, the confusion probably comes from the fact that he was born in then occupied by Austro-Hungary part of Poland (city of Jaslo, now within borders of Poland).

I've changed my macro to yours, and compiled with clang (3.9)

  CC=clang-3.9 make clean indent depend all

  clang-3.9 -c -O3 -D_GNU_SOURCE -Wall -Werror -Wframe-larger-than=131072 -Wno-format-truncation -I. -std=c11 -I/usr/local/include -Wextra -Wno-override-init -funroll-loops -D_FILE_OFFSET_BITS=64 -D_HF_LINUX_INTEL_PT_LIB -Wno-initializer-overrides -Wno-unknown-warning-option -Wno-gnu-empty-initializer -Wno-format-pedantic -Wno-gnu-statement-expression -D_HF_ARCH_LINUX  -o cmdline.o cmdline.c
  In file included from cmdline.c:23:
  In file included from ./cmdline.h:28:
  ./honggfuzz.h:357:40: error: blocks support disabled - compile with -fblocks or pick a deployment target that supports them
  static inline void defer_cleanup(void (^*b)()) {
                                       ^
  cmdline.c:68:5: error: blocks support disabled - compile with -fblocks or pick a deployment target that supports them
    defer {
    ^
  ./honggfuzz.h:364:39: note: expanded from macro 'defer'
        __attribute__((unused)) void (^defer_varname(__COUNTER__))() = ^
                                      ^
  cmdline.c:68:5: error: blocks support disabled - compile with -fblocks or pick a deployment target that supports them
  ./honggfuzz.h:364:72: note: expanded from macro 'defer'
        __attribute__((unused)) void (^defer_varname(__COUNTER__))() = ^
                                                                       ^
  3 errors generated.
  Makefile:266: recipe for target 'cmdline.o' failed
  make: *** [cmdline.o] Error 1