Hi Alex! I have enough proof, that USA is weaponizing its whole developer community to spy upon us. Facebook SDK for Android, in fact, not only is a highly sophisticated library for programming Android Apps, but also a spy tool, that copies all contents, your business contacts, ... onto facebook servers, even if you don't have any Facebook account.
https://media.ccc.de/v/35c3-9941-how_facebook_tracks_you_on_android Also see Brian Lunduke findings: https://youtube.com/watch?v=8n6ubzCzZ5I And Microsoft ....they're continuously collecting 1.9 Petabytes of data from 800 million Windows 10 workstations ... all "telemetry" data, of course ;-) https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/ Back to LLVM. LLVM is Open Source. Assumed, people might find any trojan code in it sooner or later. But the finally compiled LLVM binary, that comes with most Linux/FreeBSD/NetBSD/Darwin/MacOS X Distributions, has nothing to do with its official sources!!! It's completely different code, as i've found out. Doing a security review of the official (assumed trojan free) LLVM code - even is impossible. 420 Megabytes compressed - no chance to review this beast in lifetime ... TCC - no problem. One week and i was through. Perhaps i should remind you, that even your "tiny" (relatively to US frameworks) Picolisp - is hard at the limit, what can be reviewed. Compared to Nokolisp, Picolisp is pure bloat: Nokolisp only has 5600 lines of code, its binary .exe is 50 KILOBYTES in size only: https://github.com/timonoko/nokolisp Just to give you an idea, what to aim for. I've implemented a couple of Lisp interpreters now, they all do fit into 1st level caches (32 KBytes) of all kinds of CPUs. Memory access - with zero waitstates - finally makes them *ultra fast*, much faster than LLVM. Fast, security reviewed software is a good sell today ... i can't complain: Minimal effort, secures me highest income. Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In terms of size as well as of security. And there is another aspect to consider ... Clouds ... the smaller the interpreter is, that is executing some e.g. fastcgi code, the more clients can be served, the faster startup - and cleaning up - times, lesser latency. With interpreters, that only occupy one 4 KByte Memory Page ... i can have millions of instances (forks, whatever) running, without even coming close to one Gigabyte of memory footprint, thanks to KSM (Kernel Samepage Merging) mechanism in Linux. Identical binaries here are only stored once in memory. With LLVM? No chance. It would need terabytes of memory and dozens of cpus and servers, load balancers ... to serve a million clients. That's, of course, in US interest: "Hardware sales optimization" over bloated Open Source libraries and compilers and - intentionally - ultra slow, old fashioned algorithms, especially to be found in Open Source database code, hosted and maintained by Apache Group. I have reviewed some of them. Pure mess, a huge, no giant pile of shitty, slow, highly insecure code, full of US government injected trojans. Nobody can even security review billions of lines of code ... Less is more! Back to the roots! Also very important: "Reproducible builds". Also for security reasons. No chance with LLVM! Best regards, Guido Am Sonntag, 19. April 2020 schrieb Alexander Burger <a...@software-lab.de>: > Hi Guido, > >> Using US software stacks, even if open source and under a free license are >> not tolerable. For any nation, for any kind of project. > > Then no software stack, from anywhere, is tolerable. > > In case of pil21, where is the problem? I use Lisp to generate LLVM-IR, then the > llvm assembler to convert to machine code, then link it with libc. > > Do you seriously believe the libraries contain backdoors? They would be detected > very quickly. The generated machine code and runtime behavior I debug and > observe permanently. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
