Re: Stop using US controlled software stacks!!!
> On Apr 20, 2020, at 5:07, Guido Stepken wrote: > > And what about Apple buying and removing Open Sourced FoundationDB from > Internet? > > "In March 2015 the FoundationDB Community site was updated to state that the > company had changed directions and would no longer be offering downloads of > its product. The company was acquired by Apple Inc., which was confirmed > March 25, 2015." But FoundationDB was not free software in the first place. According to 2013 reports, the company did not intend to release it as free software (only some parts, in the future and further down the road as a "community" version). Apple released it fully as free software (MIT license) in 2018. I am sure there are plenty other exemples of bad practices in the software world, but this one does not strike me as one. Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
On Sun, Apr 19, 2020 at 10:11:07PM +0200, Tomas Hlavaty wrote: > thanks for the links You're welcome! I thought I'd add other links, but it was laready too long a message. (Links to books and pages showing the intimate reltionship of Google and NSA; the episode when Microsoft spied on Brazilian President Dilma Rousseff; the book by Snowden... But I digress) > I think the problem with nuclear is more human than technical. It is > the problem of corruption, likely due to such level of centralisation, > concentration of power, scale and magnitude of possible damage, as you > suggest. I think the scale problem is more important than people think. > > With LibreCMC > > interesting > > I use openwrt on some routers. > > Do you run picolisp on librecmc or openwrt? which picolisp? O have one LibreCMC device, three OpenWRT devices. I get the tarball from picolisp.com and compile (actually, the Makefile on that page does the compilation inside the OpenWRT build root, and produces an OpenWRT package). There are several Lisps available -- some not that small actually (like Chicken and Gauche). It's really a fun thing to get those packages done! -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
thanks for the links > With nuclear energy, there came a requirement for more > authoritarianism, stronger vertical power structures. Why? Because > the potential for damage is huge. See, for example, the radioactive > boy scout, David Hahn [6]. I do recall that there was some similar > incident in Europe, but couldn't easily find the reference. Besides > requiring more authoritative power, nuclear energy is also related to > several disasters, and there is thenuclear waste problem. I once talked to a random guy on my flight from Wien to Tokyo who happened to be travelling from an International Atomic Energy Agency meeting. He was working for the Japanese government as a regulator trying to restart Japanese nuclear powerplants. He was annoyed about opposition from local people. He worked for Toshiba in his previous job. (regulating his previous self?) The Westinghouse fiasco did not bother him too much, just commented that there was an avoidable issue with the contract. I think the problem with nuclear is more human than technical. It is the problem of corruption, likely due to such level of centralisation, concentration of power, scale and magnitude of possible damage, as you suggest. I remember reading about another guy from Hitachi working on the steel containment vessel. It was a good read. Found it: http://www.bloomberg.com/news/2011-03-23/fukushima-engineer-says-he-covered-up-flaw-at-shut-reactor.html Also "solving" the problem of nuclear waste by shiping it to Mongolia speaks for itself: http://www.reuters.com/article/2011/05/09/energy-nuclear-mongolia-idUSL3E7G80HD20110509 It is a shame, really. We did cycle today to see sakura blossom in Berlin and it was amazing. Clean air, clear sky, no airplains... I wish we had clean energy. > With LibreCMC interesting I use openwrt on some routers. Do you run picolisp on librecmc or openwrt? which picolisp? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Guido Stepken writes: > Well, perhaps you could find a few papers about "Frank" at Viewpoint > Research homepage. Bert Freudenberg, Ian Piumarta, Alan Kay certainly have > the full "Frank" code. I might have heard something about that research. Probably related to that concise vector graphics library. > But this is not the point. The point is, that MetaCola was a code > generator, where you can implement whole programming languages within just > a few lines of code. What you're seeing here is an OMeta (a MetaCola > descendant) Lisp interpreter. > > http://www.tinlizzie.org/ometa-js/#Lisp > > What you're seeing here is the complete Lisp machine!!! > > OMeta Parser/Interpreter has been translated into many programming > languages and is used almost everywhere now to implement DSL (Domain > Specific Languages). Here a Common Lisp Implementation with OMeta: > > 153 Lines of OMeta code: > > https://github.com/thiago-silva/cl-ometa/blob/master/src/ometa-parser.g > > Means: What you're seeing there, that's the *complete* Common Lisp parser > and Interpreter ... interesting common lisp has a programable reader and does not really have syntax to be parsed > I use it all the time, not only to implement new languages, compilers, but > also to design my own FPGA and ASIC CPUs, my compilers then are generating > code for. I directly parse any programming language with OMeta and > transpile to VHDL. Only a couple of minutes later i can upload my "CPU of > choice" onto my FPGA board. > > The complete toolchain (parser, lexer, compiler) is automatically > generated. And after running a couple of tests i can handover everything to > my customer(s). > > I almost completely stopped writing code in any programming language by > hand, since there is not a single problem that cannot be solved with OMeta > .. New is, that you also can generate your own CPU (implemented in FPGA or > much faster ASIC) and compiler, tools in one go. ASICs go up to 10 GHz > clock frequency, ultra fast! fascinating -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Tomas Hlavaty writes: > Guido Stepken writes: >> Using US software stacks, even if open source and under a free license are >> not tolerable. For any nation, for any kind of project. > Where can I learn more about your work? probably here: https://stepken.blogspot.com/ hidden behind javascript wall and here: https://plus.google.com/+GuidoStepken/ also not securely accessible (and both US software stacks) shame, I'd love to learn something about your ideas but this is impossible without javascript -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
What about US sanctions against China about Huawei using free, open sourced Android? What about USA advising Germany, Switzerland to stop buying gas from Russia - see Grenell's letters to industry: http://www.xinhuanet.com/english/2019-12/24/c_138655403.htm (B.t.w.: Grenell's now commander in chief of all US secret services. A pure nightmare, that guy!) That affront even was noticed in China. And what about Apple buying and removing Open Sourced FoundationDB from Internet? "In March 2015 the FoundationDB Community site was updated to state that the company had changed directions and would no longer be offering downloads of its product. The company was acquired by Apple Inc., which was confirmed March 25, 2015." Never, ever trust US government, US companies, US Foundations. Even RISC V Foundation had to move away from the US to Switzerland due to geopolitical concerns: https://www.theregister.co.uk/2019/11/26/riscv_foundation_switzerland/ Most people here seem to think, i would be paranoid or being a "US hater". I fear, it's much worse than that! :-( Again: Stop using US software stacks! Under all circumstances!!! Best regards, Guido Stepken Am Sonntag, 19. April 2020 schrieb Jeronimo Pellegrini < j.pellegr...@randomnode.info>: > [ sorry for duplacates; I've realized I have sent this from a wrong > From: address, so I'm sending it again ] > > Hello. > > I don't usually write here, but I believe this is important. > > I agree that the tone used initialy by Guido was really bad. But > there are strong arguments that lead to what he said. > > I would like to at least present the argument, even if only > pointing to external references. Because there is one, and for > the same reason I don't like when people go saying that "earth is > flat", or that "there is no coronavirus" [0], because that is strongly > disrespectful of science, I also believe that for agreeing or > disagreeing on the subject being discussed on this thread, one would > also need to show where the agreement or disagrement comes from. > Scientifically -- and I'm including human sciences. > > The argument would not be strictly in exact sciences, and that may > be why it is uncomfortable for programmers to actually pay attention > to it [1]. The argument would likely go through Mumford, Foucault, > Deleuze, Zuboff. I wont reproduce it here. > > However, cryptographer Phil Rogaway did write an essay that is closely > related to that, and explains much of the core of it. It is called > "The Moral Character of Cryptographic Work" [2], and is really > brilliant. This as a distingueshed IACR lecture in 2015 [3]. IACR > is the International Association for Cryptologic Research [4]. > > So. One important thing: Lewis Mumford noticed [5] that technology > is not always of the same kind. Sometimes it is more useful than > damaging, and sometimes it is the other way around (the terminology he > used is different, but it is the same). And people have been working > on developing technology without any attention to that (nuclear energy is > the usual first example of this. Rogaway metions the Russel-Einstein > manifesto, for example. It was written by two exact science researchers! > Rogaway also mentions in his text that "Academic cryptography used to > be more political" -- check that. > > A few examples may be interesting. > With nuclear energy, there came a requirement for more authoritarianism, > stronger vertical power structures. Why? Because the potential for damage > is huge. See, for example, the radioactive boy scout, David Hahn [6]. > I do recall that there was some similar incident in Europe, but couldn't > easily find the reference. > Besides requiring more authoritative power, nuclear energy is also > related to several disasters, and there is thenuclear waste problem. > > Am example closer to programmers: deep fake. "We have neural networks, and > we now can train deep networks" - everybody is happy. "We can use > deep learning in videos and audios" - happier. Then comes deep fake. > It is hard -- and will possibly become harder and harder -- to detect > wether a video is fake or not. This could potentially lead > both criminology and investigative journalism to the pre-photography > era. There will be a solution, and I am afraid that it will, again, > require an even more authoritative society (your video, photo or > audio must have been recorded by a tivoized device with a unbreakable > crypto module, otherwise it is useless). AND you will need to > trust the manufacturer (they COULD use the private keys to create whatever > fake videos they want). > > See... Technology is not "neutral". (Interestingly, this is also why > darktable -- a great software package -- does not have a face recognition > module [7]) > > > As to LLVM. Being or not funded by a foundation is not really a good > criterion for assessing software, I'm afraid. But I can do this: I trust > the people who develop GCC. They have a longstanding strong
Re: picoLisp 19.12: variable length array in structure fixes
Hi Mike, You don’t need energy, you need some patience. Andras ===> time pil huge.l -bye OK-UTF8 OK-Montgomery OK-Leibniz OK-math OK-forth OK-parse2list OK-mapreduce OK-pow OK-destr OK-test-car OK-bitwise # reduce redefined # pow redefined OK-4clojure # pow redefined OK-AoC15 OK-SimplyScheme # lcm redefined # evenp redefined # second redefined # mystery redefined # add1 redefined # numbers redefined # half redefined OK-Touretzky # prime? redefined OK-Menshikov # pow redefined # exp redefined # log redefined # sin redefined # cos redefined # tan redefined # asin redefined # acos redefined # atan redefined # atan2 redefined # create redefined # inrow redefined # f3-1 redefined # f3-2 redefined # f3-3 redefined # f4-2 redefined # f4-3 redefined # f8-22 redefined OK-Gorlansky OK-Stepanoff SIPHASH-OK # mod32+ redefined # endian redefined Hash-ALL-OK OK-RNG OK-HKDF OK-test-pbkdf2 # pow redefined # exp redefined # log redefined # sin redefined # cos redefined # tan redefined # asin redefined # acos redefined # atan redefined # atan2 redefined OK-HMAC OK-test-MD5 OK-test-MD2 OK-test-aes # totwo redefined # fromtwo redefined # tilde redefined OK-test-KECCAK OK-test-SHA512 OK-test-SHA256 OK-test-RIPEMD160 # mod32+ redefined # hex2L redefined OK-test-Blowfish OK-test-bcrypt # mod32+ redefined # mod32* redefined # hex2L redefined OK-test-twofish # endian redefined OK-test-threefish # hex2L redefined OK-test-RC2 # mod32* redefined # hex2L redefined OK-test-rc5 OK-test-rc6 # f redefined # num64 redefined # create redefined OK-test-camellia # expand redefined OK-test-idea OK-test-MD4 OK-test-SHA1 # num64 redefined # sbox redefined OK-test-Tiger # wsbox redefined OK-test-Whirlpool OK-test-JH256 # num32 redefined OK-test-anubis # rol redefined OK-test-scrypt # endian redefined OK-test-blake2s # endian redefined OK-test-blake2b # i redefined OK-test-Kangaroo12 crypto-ALL-OK OK-All real13m46.284s user13m58.501s sys 0m15.341s > On 2020. Apr 19., at 13:11, Mike wrote: > > hi all, > >> If you are interested I have patched the 19.12 32bit sources to compile >> without GCC. >> I have attached the changed files: pico.h, main.c, apply.c and flow.c > > My testing status for https://github.com/picolisp/picolisp > > 1. pil @lib/test.l + > clang - ok > clang+asan - ok > tcc-git- ok > > > 2. huge.l - failed (you must take care) > $ git clone https://git.envs.net/mpech/tankf33der.git > $ cd tankf33der > $ pil huge.l + > OK-UTF8 > OK-Montgomery > OK-Leibniz > OK-math > OK-forth > OK-parse2list > OK-mapreduce > OK-pow > OK-destr > OK-test-car > OK-bitwise > # reduce redefined > # pow redefined > OK-4clojure > # pow redefined > // hangs in advent2015/code2015.l > // is it hangs or very-very slow? > // the same in crypto/test.l > > !!! > Super goal - huge.l should pass all code with your patch set. > > > p.s. I dont have enough energy right now to debug all this. > > (mike) > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
[ sorry for duplacates; I've realized I have sent this from a wrong From: address, so I'm sending it again ] Hello. I don't usually write here, but I believe this is important. I agree that the tone used initialy by Guido was really bad. But there are strong arguments that lead to what he said. I would like to at least present the argument, even if only pointing to external references. Because there is one, and for the same reason I don't like when people go saying that "earth is flat", or that "there is no coronavirus" [0], because that is strongly disrespectful of science, I also believe that for agreeing or disagreeing on the subject being discussed on this thread, one would also need to show where the agreement or disagrement comes from. Scientifically -- and I'm including human sciences. The argument would not be strictly in exact sciences, and that may be why it is uncomfortable for programmers to actually pay attention to it [1]. The argument would likely go through Mumford, Foucault, Deleuze, Zuboff. I wont reproduce it here. However, cryptographer Phil Rogaway did write an essay that is closely related to that, and explains much of the core of it. It is called "The Moral Character of Cryptographic Work" [2], and is really brilliant. This as a distingueshed IACR lecture in 2015 [3]. IACR is the International Association for Cryptologic Research [4]. So. One important thing: Lewis Mumford noticed [5] that technology is not always of the same kind. Sometimes it is more useful than damaging, and sometimes it is the other way around (the terminology he used is different, but it is the same). And people have been working on developing technology without any attention to that (nuclear energy is the usual first example of this. Rogaway metions the Russel-Einstein manifesto, for example. It was written by two exact science researchers! Rogaway also mentions in his text that "Academic cryptography used to be more political" -- check that. A few examples may be interesting. With nuclear energy, there came a requirement for more authoritarianism, stronger vertical power structures. Why? Because the potential for damage is huge. See, for example, the radioactive boy scout, David Hahn [6]. I do recall that there was some similar incident in Europe, but couldn't easily find the reference. Besides requiring more authoritative power, nuclear energy is also related to several disasters, and there is thenuclear waste problem. Am example closer to programmers: deep fake. "We have neural networks, and we now can train deep networks" - everybody is happy. "We can use deep learning in videos and audios" - happier. Then comes deep fake. It is hard -- and will possibly become harder and harder -- to detect wether a video is fake or not. This could potentially lead both criminology and investigative journalism to the pre-photography era. There will be a solution, and I am afraid that it will, again, require an even more authoritative society (your video, photo or audio must have been recorded by a tivoized device with a unbreakable crypto module, otherwise it is useless). AND you will need to trust the manufacturer (they COULD use the private keys to create whatever fake videos they want). See... Technology is not "neutral". (Interestingly, this is also why darktable -- a great software package -- does not have a face recognition module [7]) As to LLVM. Being or not funded by a foundation is not really a good criterion for assessing software, I'm afraid. But I can do this: I trust the people who develop GCC. They have a longstanding strong ethical commitment, and I have no reason to be afraid of what gcc may do on my system. I don't trust LLVM, for several reaosns, so I avoid it as much as possible. Jerônimo (The guy who maintains the LibreCMC and OpenWRT packages of Picolisp [8] -- by the way, OpenWRT and similar firmware would probbaly not exist if developers of Linux and several userland utilities had not picked the GNU/GPL as a license. Another example of a decision that does have an impact on how technology will be used and how it impacts people's lives. With LibreCMC, I have some more confidence that my router runs *strictly* what I want, for example. This is important for security, since I don't want to have to trust a big hardware maker. See, for example, what is already happening with other devices -- smart TVs recording audio on your house and SENDING IT TO THE MANUFACTURER. And they don't even deny it) [0] It is really sad that I have been seeing this a lot in my country. [1] About the communication gap between exact sciences and human sciences, see C. P. Snow, "TheTwo Cultures". There is a Wikipedia page for the text: https://en.wikipedia.org/wiki/The_Two_Cultures [2] https://web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf [3] https://www.youtube.com/watch?v=F-XebcVSyJw [4] https://www.iacr.org/ [5] https://en.wikipedia.org/wiki/Technics_and_Civilization [6] https://en.w
Re: Stop using US controlled software stacks!!!
Well, perhaps you could find a few papers about "Frank" at Viewpoint Research homepage. Bert Freudenberg, Ian Piumarta, Alan Kay certainly have the full "Frank" code. But this is not the point. The point is, that MetaCola was a code generator, where you can implement whole programming languages within just a few lines of code. What you're seeing here is an OMeta (a MetaCola descendant) Lisp interpreter. http://www.tinlizzie.org/ometa-js/#Lisp What you're seeing here is the complete Lisp machine!!! OMeta Parser/Interpreter has been translated into many programming languages and is used almost everywhere now to implement DSL (Domain Specific Languages). Here a Common Lisp Implementation with OMeta: 153 Lines of OMeta code: https://github.com/thiago-silva/cl-ometa/blob/master/src/ometa-parser.g Means: What you're seeing there, that's the *complete* Common Lisp parser and Interpreter ... I use it all the time, not only to implement new languages, compilers, but also to design my own FPGA and ASIC CPUs, my compilers then are generating code for. I directly parse any programming language with OMeta and transpile to VHDL. Only a couple of minutes later i can upload my "CPU of choice" onto my FPGA board. The complete toolchain (parser, lexer, compiler) is automatically generated. And after running a couple of tests i can handover everything to my customer(s). I almost completely stopped writing code in any programming language by hand, since there is not a single problem that cannot be solved with OMeta .. New is, that you also can generate your own CPU (implemented in FPGA or much faster ASIC) and compiler, tools in one go. ASICs go up to 10 GHz clock frequency, ultra fast! You can easily find your OMeta Parser/Interpreter of your language of choice in Google. Best regards, Guido Stepken Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty : > Guido Stepken writes: >> That group implemented a whole operating system in MetaCola language within >> 20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver .. >> everything included, called "Frank" for Frank - enstein. > > interesting, where can I learn more? > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: Stop using US controlled software stacks!!!
Jo-To Schäg writes: > However the PicoLisp community does not like to solve problems for > other people. Especially if it is motivated for political reasons. > Do not expect Alex to spend his time on satisfying your paranoia or > political motivations. Where I live we had freedom of movement for about 30 years. Now for the first time since the fall of communism, the borders closed. In many countries power is getting more centralised and many governments are regressing back to authoritarianism. I think he raises important points which will be even more important in the (probably near) future. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Tiny C Compiler
Well, perhaps i may recommend you an excellent course into "C system programming". IMHO it's basic knowledge, nobody can succeed without. This guy is a highly talented teacher, IMHO. Example lesson, worth watching at first: http://cs-education.github.io/sys/#/chapter/5/section/0/activity/0 Here the overview: http://cs-education.github.io/sys/#lessons The book: https://github.com/angrave/SystemProgramming/wiki The online IDE and compiler: http://cs-education.github.io/sys/#VM I am absolutely sure, that after you will have completed these short lessons each, your little "problem" with replacing a C macro by C code also will disappear magically. ;-) Best regards, Guido Stepken Am Dienstag, 14. April 2020 schrieb C K Kashyap : > Thanks Guido, > I was not able TCC to align the functions though :( > Regards, > Kashyap > On Mon, Apr 13, 2020 at 2:05 PM Guido Stepken wrote: >> >> That's kind of tabulator for structs of data in memory .. only of real use for handing over to vector instructions (SSE, AVX2, AVX512 ... ARM NEON). It's a GCC thing, not a C standard! ;-) >> >> https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro >> >> Hope, that helps. >> >> Am Montag, 13. April 2020 schrieb C K Kashyap : >> > Hi all, >> > I just noticed that TCC was mentioned in another thread so I wanted to share my experience with it. I had tried to build miniPicoLisp with it but unfortunately, TCC does not seem to generate aligned functions :( it did not seem to honor __attribute__((aligned)) >> > Does anyone else have any experience with using TCC to build miniPicoLIsp or PicoLisp for that matter? >> > Regards, >> > Kashyap
Re: Stop using US controlled software stacks!!!
Alexander Burger writes: > In case of pil21, where is the problem? > llvm assembler to convert to machine code ^ I think he is pointing here > Do you seriously believe the libraries contain backdoors? I don't think he said anything like that. My understanding is that he said that llvm is not reasonably reviewable and that it is under control of people with questionable reputation and that it poses potentially serious risk which he does not want to take. The problem with trust is that it is not transitive. I might trust Alex, Alex might trust llvm but that does not mean I trust llvm. > They would be detected very quickly. If you take the optimistic point of view, you can certainly ignore the issue completely. Detection can take years or decades if at all, then somebody needs to find a way to fix it if there is a will to fix it at all and then actually fix it and then make sure it does not happen again. > The generated machine code and runtime behavior I debug and observe > permanently. Because you observe software does not mean it does not contain so far unobserved behaviour. Also iirc that famous C guy had a talk about backdoors in compilers. Interesting stuff. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Guido Stepken writes: > That group implemented a whole operating system in MetaCola language within > 20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver ... > everything included, called "Frank" for Frank - enstein. interesting, where can I learn more? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Ok. Fine. Then let's look, how many lines it needs to write your own compiler. Means: Source language -> Windows .exe binary. What do you think, how many lines are needed to generate 64-bit Machine code COFF executable format for Intel, AMD Ryzen, Thread Ripper, EPYC on Windows? I can tell you: 100 lines!!! https://github.com/d3dave/brainfuck-x64/blob/master/compile.py You are not "teaching" the right things, IMHO. Lisp -> x64 compiler is just a few lines longer, since you have to handle multiple stack machines. That's all! Compare to 2,5 million lines of LLVM code. Do you understand me now? Best regards, Guido Stepken Am Sonntag, 19. April 2020 schrieb Jo-To Schäg : > Dear Guido, > all our time on earth is limited. We all got our own priorities. > I think the PicoLisp community gladly spends time teaching people. Even multiple times. > However the PicoLisp community does not like to solve problems for other people. > Especially if it is motivated for political reasons. > Do not expect Alex to spend his time on satisfying your paranoia or political motivations. > You are weary of the giants of muscle and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You political motivations have no sovereignty where we gather. - inspired by the Declaration of Cyberspace > Also you do not need to leave the community but at least stop bothering Alex about your political opinions. > We have heard you concern thrice. As far as i see we only use LLVM to translate LLVM-IR to some CPU architecture, so we only depend on the code for that. > You could write your own LLVM-IR to x86 translator if you are bothered by LLVM itself. > > > > On Sun, 19 Apr 2020 at 15:54, Guido Stepken wrote: >> >> Alex, this is not the point. One day LLVM will inject trojan code, because US government, by law, tells them to do so! >> >> With Cloud Act and Patriot Act US government can advise any US company or organisation to implement evil code. >> >> Can you do a full code review at every update coming for LLVM? I can't! Nobody can! 2.5 million lines is out of anybody's reach! >> >> 100 bytes more in a binary can make a *huge difference* from security oint of view. Do you always know, why LLVM suddenly is generating bigger code? Can be everything. E.g. this: >> >> https://gistgithub.com/DGivney/5917914 >> >> TCC, i can review any time code is so tiny. Well ok, TCC binary code is not as highly optimized in terms of speed, but AMD processor microcode does compensate that. Differences to GCC -O3 or LLVM - in practice - have become negligible. >> >> TCC always is fast enough. And i repeat: Stop using US software stacks! >> >> Best regards, Guido Stepken >> >> Am Sonntag, 19. April 2020 schrieb Alexander Burger : >> > Hi Guido, >> > >> >> Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In >> >> terms of size as well as of security. >> > >> > True, LLVM is huge (as is gcc, and other equivalent systems), but this is >> > irrelevant because I *use* it only to translate *my* code. >> > >> > The generated pil21 'picolisp' binary is only a few percent larger than the >> > assembly version of pil64. >> > >> > ☺/ A!ex >> > >> > -- >> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
Re: Stop using US controlled software stacks!!!
Guido Stepken writes: > Picolisp, thanks to Alex' brilliant ideas, behind the scenes, serves as > prototype of a new kind of "minimalistic, highly efficiency" software > strategy within the EU. Goal is: Back to the roots, small modules, security > review everywhere, minimal hardware requirements, driving down energy > consumption massively. does EU fund Picolisp as part of the software strategy? If not, why and how could that be achieved? Where can I read about the EU software strategy? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Hi Guido, Guido Stepken writes: > Using US software stacks, even if open source and under a free license are > not tolerable. For any nation, for any kind of project. > > US Cloud Act, Patriot Act, by law, force US companies as well US > organisations in general, such as Linux Foundation as well as Apache > Foundation and LLVM Foundation to comply with US law. is using google mail tolerable? > And i can assure you: My influence is **much bigger** than you might think! > Stop that, immediately! You raise interesting points. Where can I learn more about your work? Cheers Tomas -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
andr...@itship.ch writes: > I have to disagree with your tone. I empathise with his tone. This issue is frustrating. Just this week a friend of mine was told by her employer to install whatsapp so that they can keep her updated about the suspended work due to the pandemic. I told her about the downsides and possible alternatives. She did install whatsapp on her private phone in the end. I see the same problem everywhere and it's very hard not to ignore the downsides because e.g. I won't pay her bills. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Dear Guido, all our time on earth is limited. We all got our own priorities. I think the PicoLisp community gladly spends time teaching people. Even multiple times. However the PicoLisp community does not like to solve problems for other people. Especially if it is motivated for political reasons. Do not expect Alex to spend his time on satisfying your paranoia or political motivations. You are weary of the giants of muscle and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You political motivations have no sovereignty where we gather. - inspired by the Declaration of Cyberspace Also you do not need to leave the community but at least stop bothering Alex about your political opinions. We have heard you concern thrice. As far as i see we only use LLVM to translate LLVM-IR to some CPU architecture, so we only depend on the code for that. You could write your own LLVM-IR to x86 translator if you are bothered by LLVM itself. On Sun, 19 Apr 2020 at 15:54, Guido Stepken wrote: > Alex, this is not the point. One day LLVM will inject trojan code, because > US government, by law, tells them to do so! > > With Cloud Act and Patriot Act US government can advise any US company or > organisation to implement evil code. > > Can you do a full code review at every update coming for LLVM? I can't! > Nobody can! 2.5 million lines is out of anybody's reach! > > 100 bytes more in a binary can make a *huge difference* from security oint > of view. Do you always know, why LLVM suddenly is generating bigger code? > Can be everything. E.g. this: > > https://gist.github.com/DGivney/5917914 > > TCC, i can review any time code is so tiny. Well ok, TCC binary code > is not as highly optimized in terms of speed, but AMD processor microcode > does compensate that. Differences to GCC -O3 or LLVM - in practice - have > become negligible. > > TCC always is fast enough. And i repeat: Stop using US software stacks! > > Best regards, Guido Stepken > > Am Sonntag, 19. April 2020 schrieb Alexander Burger : > > Hi Guido, > > > >> Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! > In > >> terms of size as well as of security. > > > > True, LLVM is huge (as is gcc, and other equivalent systems), but this is > > irrelevant because I *use* it only to translate *my* code. > > > > The generated pil21 'picolisp' binary is only a few percent larger than > the > > assembly version of pil64. > > > > ☺/ A!ex > > > > -- > > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: Stop using US controlled software stacks!!!
Alex, this is not the point. One day LLVM will inject trojan code, because US government, by law, tells them to do so! With Cloud Act and Patriot Act US government can advise any US company or organisation to implement evil code. Can you do a full code review at every update coming for LLVM? I can't! Nobody can! 2.5 million lines is out of anybody's reach! 100 bytes more in a binary can make a *huge difference* from security oint of view. Do you always know, why LLVM suddenly is generating bigger code? Can be everything. E.g. this: https://gist.github.com/DGivney/5917914 TCC, i can review any time code is so tiny. Well ok, TCC binary code is not as highly optimized in terms of speed, but AMD processor microcode does compensate that. Differences to GCC -O3 or LLVM - in practice - have become negligible. TCC always is fast enough. And i repeat: Stop using US software stacks! Best regards, Guido Stepken Am Sonntag, 19. April 2020 schrieb Alexander Burger : > Hi Guido, > >> Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In >> terms of size as well as of security. > > True, LLVM is huge (as is gcc, and other equivalent systems), but this is > irrelevant because I *use* it only to translate *my* code. > > The generated pil21 'picolisp' binary is only a few percent larger than the > assembly version of pil64. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Stop using US controlled software stacks!!!
8k ... well, looks like totally bloated ... somebody implemented Ian Piumarta's Lysp in Free Pascal, using 192 lines of code only. I haven't tested, but should come out at under 4k, one memory page for the binary. https://github.com/tangentstorm/lysp Finally, to execute Lisp like code, you only need to implement a lambda calculus, perhaps some alpha, beta reductions, caching on top to gain some speed ... That group implemented a whole operating system in MetaCola language within 20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver ... everything included, called "Frank" for Frank - enstein. I've seen that "Frankenstein OS" booting on bare Intel metal and working quite well. Have fun! Am Sonntag, 19. April 2020 schrieb Alexander Burger : > On Sun, Apr 19, 2020 at 06:10:25PM +0900, George-Phillip Orais wrote: >> You mentioned nokolisp, I also tried that and from what I remember the >> source code was only runnable on an old DOS? > > Then 8kLisp is even better: > >https://software-lab.de/8kLisp.tgz > > It run on CP/M, and the whole interpreter binary 8kl.com has 8192 *bytes*
Re: picoLisp 19.12: variable length array in structure fixes
Hi tankf33der, Thanks for sharing your huge.l test, I tried it on my pil64 on WSL and all passed! 20:27 $ pil huge.l + OK-UTF8 OK-Montgomery OK-Leibniz OK-math OK-forth OK-parse2list OK-mapreduce OK-pow OK-inc-db # worker redefined # +Inc c redefined OK-inc-db-v2 OK-destr OK-test-car OK-bitwise # reduce redefined OK-Cartesian # reduce redefined # pow redefined # seq redefined OK-4clojure # pow redefined OK-AoC15 OK-AoC16 # f3-2 redefined # f4-2 redefined OK-AoC17 # a10 redefined OK-AoC18 # c5 redefined # c9 redefined # c11 redefined # c13 redefined OK-AoC19 OK-SimplyScheme # lcm redefined # evenp redefined # second redefined # mystery redefined # add1 redefined # numbers redefined # half redefined OK-Touretzky # prime? redefined OK-Menshikov # pow redefined # exp redefined # log redefined # sin redefined # cos redefined # tan redefined # asin redefined # acos redefined # atan redefined # atan2 redefined # f1-1 redefined # f1-2 redefined # create redefined # inrow redefined # f2-1 redefined # move redefined # f3-1 redefined # f3-2 redefined # f3-3 redefined # f4-1 redefined # f4-2 redefined # f4-3 redefined # product redefined # f5-1 redefined # f5-2 redefined # f6-1 redefined # f6-2 redefined # f7-1 redefined # f7-2 redefined # f8-22 redefined # f10-1 redefined # f10-2 redefined # f14-1 redefined # f14-2 redefined # f15-1 redefined # f16-2 redefined # f17-1 redefined # f17-2 redefined # f18-1 redefined # f18-2 redefined OK-Gorlansky OK-Stepanoff SIPHASH-OK # mod32+ redefined # endian redefined Hash-ALL-OK OK-RNG OK-HKDF OK-test-pbkdf2 # pow redefined # exp redefined # log redefined # sin redefined # cos redefined # tan redefined # asin redefined # acos redefined # atan redefined # atan2 redefined # T1 redefined OK-HMAC OK-test-MD5 OK-test-MD2 OK-test-aes # totwo redefined # fromtwo redefined # tilde redefined OK-test-KECCAK OK-test-SHA512 OK-test-SHA256 OK-test-RIPEMD160 # mod32+ redefined # hex2L redefined OK-test-Blowfish OK-test-bcrypt # mod32+ redefined # mod32* redefined # hex2L redefined OK-test-twofish # endian redefined OK-test-threefish # hex2L redefined OK-test-RC2 # mod32* redefined # hex2L redefined OK-test-rc5 OK-test-rc6 # f redefined # num64 redefined # create redefined OK-test-camellia # expand redefined OK-test-idea OK-test-MD4 OK-test-SHA1 # num64 redefined # sbox redefined OK-test-Tiger # wsbox redefined OK-test-Whirlpool OK-test-JH256 # num32 redefined OK-test-anubis # rol redefined OK-test-scrypt # endian redefined OK-test-blake2s # endian redefined OK-test-blake2b # i redefined OK-test-Kangaroo12 crypto-ALL-OK OK-All Cool! Thanks! BR, Geo On Sun, Apr 19, 2020 at 8:17 PM Mike wrote: > hi all, > > > If you are interested I have patched the 19.12 32bit sources to compile > without GCC. > > I have attached the changed files: pico.h, main.c, apply.c and flow.c > > My testing status for https://github.com/picolisp/picolisp > > 1. pil @lib/test.l + > clang - ok > clang+asan - ok > tcc-git- ok > > > 2. huge.l - failed (you must take care) > $ git clone https://git.envs.net/mpech/tankf33der.git > $ cd tankf33der > $ pil huge.l + > OK-UTF8 > OK-Montgomery > OK-Leibniz > OK-math > OK-forth > OK-parse2list > OK-mapreduce > OK-pow > OK-destr > OK-test-car > OK-bitwise > # reduce redefined > # pow redefined > OK-4clojure > # pow redefined > // hangs in advent2015/code2015.l > // is it hangs or very-very slow? > // the same in crypto/test.l > > !!! > Super goal - huge.l should pass all code with your patch set. > > > p.s. I dont have enough energy right now to debug all this. > > (mike) > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: picoLisp 19.12: variable length array in structure fixes
hi all, > If you are interested I have patched the 19.12 32bit sources to compile > without GCC. > I have attached the changed files: pico.h, main.c, apply.c and flow.c My testing status for https://github.com/picolisp/picolisp 1. pil @lib/test.l + clang - ok clang+asan - ok tcc-git- ok 2. huge.l - failed (you must take care) $ git clone https://git.envs.net/mpech/tankf33der.git $ cd tankf33der $ pil huge.l + OK-UTF8 OK-Montgomery OK-Leibniz OK-math OK-forth OK-parse2list OK-mapreduce OK-pow OK-destr OK-test-car OK-bitwise # reduce redefined # pow redefined OK-4clojure # pow redefined // hangs in advent2015/code2015.l // is it hangs or very-very slow? // the same in crypto/test.l !!! Super goal - huge.l should pass all code with your patch set. p.s. I dont have enough energy right now to debug all this. (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Hi Alex, Indeed! How can I missed that hehe if I remember correctly, the character for commenting was not yet ‘#’ right? So cool!! thanks for reminding me ;) BR, Geo On Sun, Apr 19, 2020 at 6:37 PM Alexander Burger wrote: > On Sun, Apr 19, 2020 at 06:10:25PM +0900, George-Phillip Orais wrote: > > You mentioned nokolisp, I also tried that and from what I remember the > > source code was only runnable on an old DOS? > > Then 8kLisp is even better: > >https://software-lab.de/8kLisp.tgz > > It run on CP/M, and the whole interpreter binary 8kl.com has 8192 *bytes*
Re: Stop using US controlled software stacks!!!
On Sun, Apr 19, 2020 at 06:10:25PM +0900, George-Phillip Orais wrote: > You mentioned nokolisp, I also tried that and from what I remember the > source code was only runnable on an old DOS? Then 8kLisp is even better: https://software-lab.de/8kLisp.tgz It run on CP/M, and the whole interpreter binary 8kl.com has 8192 *bytes*. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Hi Guido, > Look at LLVM generated bloat and compare with Nokolisp. Less is more!!! In > terms of size as well as of security. True, LLVM is huge (as is gcc, and other equivalent systems), but this is irrelevant because I *use* it only to translate *my* code. The generated pil21 'picolisp' binary is only a few percent larger than the assembly version of pil64. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Hi Guido, You mentioned nokolisp, I also tried that and from what I remember the source code was only runnable on an old DOS? One thing that was cool about nokolisp was it was intended for Nokie phones right? How about Lisp dialects made in Japan? Im interested to hear your thoughts about them as well :) BR, Geo
Re: Stop using US controlled software stacks!!!
Am Sonntag, 19. April 2020 schrieb : Picolisp, thanks to Alex' brilliant ideas, behind the scenes, serves as prototype of a new kind of "minimalistic, highly efficiency" software strategy within the EU. Goal is: Back to the roots, small modules, security review everywhere, minimal hardware requirements, driving down energy consumption massively. That's why i am so upset. LLVM definitely is the wrong way: It's pure bloat! Regards, Guido
Re: Stop using US controlled software stacks!!!
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 : > 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 >
Re: Stop using US controlled software stacks!!!
Oh dear, Since you (Guido Stepken) are already ranting about US software stacks (e.g. LLVM), I will take the opportunity to add my 2 Euro-cents. What about your operatjng system? I presume you are using Linux. Have you yet audited the ca. 5 MLoc of code that are the Linux kernel? Other operating systems (the BSDs all hail from the US, except OpenBSD, which is from Canada, but which is well in the US and Her Majesty's Government sphere of influence) have similar problems. Not to mention the hardware, which for the popular modern amd64 platform also comes from the US and contains numerous "security" backdoor. So unless you run your own compiler on your own OS on custom built hardware, it is hard to get the degree of security that you seem to want. Bummer, but we'll somehow have to put up with it. Am 18. April 2020 22:46:14 MESZ schrieb Guido Stepken : >Hi Alex! > >"completely replace it with pil21" ... (LLVM based) > >Using US software stacks, even if open source and under a free license >are >not tolerable. For any nation, for any kind of project. > >US Cloud Act, Patriot Act, by law, force US companies as well US >organisations in general, such as Linux Foundation as well as Apache >Foundation and LLVM Foundation to comply with US law. > >Here's a possible outcome: >https://www.infoq.com/news/2016/06/visual-cpp-telemetry/ > >The compiler itself becomes a NSA/CIA spy tool. With (compressed) over >420 >megabytes of source code size for LLVM, world does not have the >slightest >chance to do any security review on that software stack. > >And that's what stupid cowboys are hoping for: Not only creating >Lock-In - >as well as legal problems - on APIs of all kinds (see Oracle-Google >lawsuit) with Apache/Linux/LLVM/... Foundations, stupid cowboys are >also >injecting spy code into in all kinds of US controlled libraries (NPM >now is >Microsoft/Github owned) and especially compilers, development tools. > >My urgent advice: Stay with your own x64 compiler, forget about >everything >that is coming from or is directed by US companies, US foundations of >any >kind. > >Switch to LLVM with pil21 and i cannot recommend you and your (until >today: >trustworthy) software stack any longer for any kinds of projects. > >And i can assure you: My influence is **much bigger** than you might >think! >Stop that, immediately! > >Use C99 compilers, that are small enough to be security reviewed, such >as >TCC. > >Best regards, Guido Stepken > >Am Samstag, 18. April 2020 schrieb Alexander Burger >: >> Hi Andras, >> >>> If you are interested I have patched the 19.12 32bit sources to >compile >without GCC. >>> I have attached the changed files: pico.h, main.c, apply.c and >flow.c >> >> Thanks a lot! >> >> >>> Since clang does not support variable length array in structures I >allocate the bindFrame >>> with alloca() and provided a macro in pico.h to ease this: >allocFrame(). >>> >>> I know that the 32bit version is not the mainstream version, but >feel >free to >>> abuse the patches. >> >> Cool! >> >> As I'm concentrating on pil21, I'm glad if development and >maintenance of >pil32, >> mini and/or ersatz is taken care of by others. Until it is replaced >by >pil21 >> next year, I will do necessary fixes to pil64 and then - if all goes >well >- >> completely replace it with pil21. >> >> Let's hope that no major problems pop up ... ;) >> >> ☺/ A!ex >> >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >> -- You have zero privacy anyway. Get over it. Scott McNealy 1999
