jagger11's comments

So, helping Nazi Germany in the beggining of the WW2 seems justified in light of this, I agree.

I don't think I've ever made a point that PL (and earlier PL-LI commonwealth) had a stellar record of treatment of minority nationalities in its borders. Could you clarify with which point I'd made you argue?

Please retract the accussation of lie, it's quite unpleasant to me personally: I said that the title says "march", and you seem to confirm.

It had authoritarianism (with many democratic elements in place) since 1926 (way way more liberal than that of Soviet Union, or Nazi Germany). Before that it was fully democratic (though, chaotic).

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).

Polish borders as of 1918 are here - https://pl.wikipedia.org/wiki/Historia_Polski_(1918%E2%80%93...

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

- In 1918, borders of Poland were established on the future Curzon line (more or less, less in fact) - https://pl.wikipedia.org/wiki/Historia_Polski_(1918%E2%80%93...

- 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.

> 2nd Polish republic was established after WW1, so there was no Polish ground

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

I've already condemened it.

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

Polish government went exile after the Soviets invaded.

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.

That's something both Polish and international historians condemn, and there's no serious justification of this act, not in maintream Polish history books, nor on Wikipedia (described as "annexation" in .pl wiki). PS: Poland was not a signatory to the Munich agreements.

A digression: in effect of the secret protocol being signed, then-USSR attacked Poland on 17-th of September 1939 (co-starting the 2WW, together with Germany). Wikipedia articles describing this "event" are typically named "Soviet invasion of Poland" or "Soviet occupation of East Poland", or something similar: https://en.wikipedia.org/wiki/Soviet_invasion_of_Poland

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.

Hi,

> 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).

Hi,

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.

Hi, one of the authors here.

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).

Hi, one of the authors here.

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.

The thing about Lem is that he was reading a lot (I mean, a lot) of scientific journals and later scientific papers (in an interview with him he mentions Soviet "Priroda", "Scientific American", some French and German journals of this type), plus books of Dawkins/Hawking/Penrose /Shklovsky/Soviet scientists etc., and all of that in 60's-70's-80's

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)

About Asimov's predictions: those (incl. listed above) either haven't yet materialized, or are rather funny from today's perspective (Robotics, AI and "psychohistory" as described in the Foundation series). He's been rather poor futurologist IMO, contrary to the level of his popularity.

Oh man, Asimov was so bad with futuristic ideas. If you'd like to read good thoughts about future, go for Stanislaw Lem (Summa Technologiae, Golem XIV)

Maybe what the OP meant was, that Lem's works are much less known in the West than in the old good "Eastern Block", though AFAIK he's quite well known in Germany.

One of the greatest sources of those Lem's "predictions" is his Summa Technologiae, which was recently translated into English - https://www.amazon.com/s?search-alias=stripbooks&field-isbn=...

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.