Re: Stop using US controlled software stacks!!!

[Guido Stepken]

You guys haven't read or understood carefully. I said, that i have not
found any evidence to distrust IBM or to think, that IBM would be sitting
in the NSA boat. IBM, much earlier than other companies, did open source
everything, Power firmware included:

https://github.com/open-power

On the other hand, UEFI.sources never were published, could be compiled
through. Same as Intel IME (Minix) Firmware.

Doesn't mean, that i, in fact, do use IBM stacks for my own mission
critical businesses.

Have fun!

Am Mittwoch, 29. April 2020 schrieb :
> On Tue, 28 Apr 2020 17:57 -04:00, andr...@itship.ch wrote:
>> On 28.04.20 22:53, Guido Stepken wrote:
>> >
>> > (Blathering removed.)
>>
>> You generalize too broadly in one sentence and then contradict
>> yourself the next.
>
> ^^ This. ^^
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Stop using US controlled software stacks!!!

[rick]

On Tue, 28 Apr 2020 17:57 -04:00, andr...@itship.ch wrote:
> On 28.04.20 22:53, Guido Stepken wrote:
> > 
> > (Blathering removed.)
> 
> You generalize too broadly in one sentence and then contradict
> yourself the next.

^^ This. ^^

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

"gcc -fanalyzer" will fundamentally change safety of C programs, such as
Linux, GNOME, DQlite (distributed SQLite), Cython, Python, Crystal, Ruby,
NIM, ZIG, Vala/Genie ... but also the C compiled version of PicoLisp ...

https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/

Plenty of proactive security patches are coming out now minutely, which
vastly improve complete Linux environment.

Sadly, Microsoft does _not profit_ from the magic abilities of that new
flow analyzer in GCC. Windows, Office ... all written in C++! :-D

Have fun!

Am Dienstag, 28. April 2020 schrieb Edgaras Šeputis :
> Here is the thing, in consumer space, but not even there in a way "nobody
> cares about security". Not in that nobody cares, but there are more
> important things than security, like some particular ability, and for now
> it USA stuff or severe hits in performance, or even nothing at all. Which
> in such cases people will rightfully so take some security concerns over
> not being able to do anything, or things that competitors are doing. For
> now penetration of those technologies are super low, and it remains to be
> seen where they will go. I also have hopes that someone will unseat if not
> crush at least one company - Intel, but more for all the underhanded shit
> they done to win "top dog" position in market. Also Linus makes some very
> pragmatical valid points about security too:
>
https://www.cio.com/article/2434264/torvalds-calls-openbsd-group--masturbating-monkeys-.html
,
> which applies here full well. You can pipe all you want a bout this
> insecure or that with backdoor no one will care until you deliver
> competitive features, not with attitude like you shown sometimes. You go
> this is shit that will be most amazing and thus don't use this. Well seems
> people can not use 'that', so in a mean time they will keep using 'this'.
> And 'that' will have to compete, and dropping potential allies cause today
> they use 'this' is just stupid. Unless you think stuff can not be ported
> later on.
>
> On Tue, Apr 28, 2020 at 1:44 PM Guido Stepken  wrote:
>
>> I think, it's decided now, that China is going to remove US hardware, US
>> software and US protocols.
>>
>> In fact, US software stacks, especially those Open Source by Apache,
Linux,
>> .. "Foundations" have become a *huge pile of shit*:
>>
>> *Billions lines of code, millions of bugs, thousands of NSA backdoors,
>> hundreds of intentionally slowed down algorithms, sponsored mainly by
>> Intel*
>>
>> Security Reviews? Impossible! Removing NSA contributed code, e.g.
SELinux,
>> backdoors even deeply sticking in Linux TCP/IP stack? Impossible!
>>
>> Removing Intel IME Spy Firmware Processor (MINIX) from all 2008 later
>> motherboards (even in notebooks) - Impossible!
>>
>> To give you an idea, what's all running in parallel to your "Booted OS"
of
>> choice:
>>
>>
>>
https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf
>>
>> In fact, UEFI is an Operating System, that is running parallel to your
own
>> OS. You're booting Windows, Linux on a kind of Hypervisor, the
underlying,
>> hidden Minix OS (a tiny UNIX Clone living in North Bridge), has *full
>> access* to. Means: Disk, memory, keyboard, network ...
>>
>> NSA can access all of your passwords, certificates, ... any time. Even
when
>> main processor is switched off, the Cortex-A15 core can activate power
for
>> e.g. SSD, network on its own, even when Intel main CPU is deactivated.
>>
>> And i fear, the little "US problem" with surveillance, spying on other
>> countries industries to gain strategic advantage and control over forein
>> industries, politicians, CEOs ... is much bigger than anybody can
imagine

回复：Stop using US controlled software stacks!!!

[Enwei Zhang]

Where can we get safe hardwares? Zhang Enwei发自我的华为手机 原始邮件 发件人： Guido Stepken 日期： 2020年4月28日周二 傍晚6:50收件人： picolisp@software-lab.de主题： Re: Stop using US controlled software stacks!!!I think, it's decided now, that China is going to remove US hardware, USsoftware and US protocols.In fact, US software stacks, especially those Open Source by Apache, Linux,.. "Foundations" have become a *huge pile of shit*:*Billions lines of code, millions of bugs, thousands of NSA backdoors,hundreds of intentionally slowed down algorithms, sponsored mainly by Intel*Security Reviews? Impossible! Removing NSA contributed code, e.g. SELinux,backdoors even deeply sticking in Linux TCP/IP stack? Impossible!Removing Intel IME Spy Firmware Processor (MINIX) from all 2008 latermotherboards (even in notebooks) - Impossible!To give you an idea, what's all running in parallel to your "Booted OS" ofchoice:https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdfIn fact, UEFI is an Operating System, that is running parallel to your ownOS. You're booting Windows, Linux on a kind of Hypervisor, the underlying,hidden Minix OS (a tiny UNIX Clone living in North Bridge), has *fullaccess* to. Means: Disk, memory, keyboard, network ...NSA can access all of your passwords, certificates, ... any time. Even whenmain processor is switched off, the Cortex-A15 core can activate power fore.g. SSD, network on its own, even when Intel main CPU is deactivated.And i fear, the little "US problem" with surveillance, spying on othercountries industries to gain strategic advantage and control over foreinindustries, politicians, CEOs ... is much bigger than anybody can imagine.In Europe, we now have Exokernels (similar to Hypervisors, Microkernels)running on safe hardware (e.g. ARM Cortex-A53/55 (no Spectre/Melissavulnerability, like Odroid N4, RPi 3, ...) with *"UNIX as library"* runningon top, programmed in an old, rock solid funtional, compiled language named*OCaml*. Also see ReasonML. 10x faster, 100x lesser memory footprint forsame (web, database, GUI) functionality.New upcoming European "Gaia-X" Cloud will be built with that stuffexclusively (security reviews ongoing), leaving US companies and theirtechnologies in the dust. China, India, South America are going similarways.Also see "Shakti RISC-V" Project: https://shakti.org.in/RISC-V foundation recently has been moved to Switzerland. Finished with USinfluence. We're taking them out of business now. With "we" i mean wholeworld with 7 billion people outside the US.Have fun!P.S.: I neither smoke nor am i taking drugs!Am Dienstag, 28. April 2020 schrieb Edgaras Šeputis :> Now you seriously smoking something. China's bullshit new IP was notaccepted by anyone, no one wants their authoritarian extensions, and saywhatever you want about US (and one can say a lot of shit about them and bequite correct), US is still millions of miles better than China and if youare running from US, you should run even faster from China> I'll just point that for some time now you are acting like some kind ofweird troll, making some seemingly interesting pionts, even whiledisplaying crappy attitude, then spouting complete bullshit about Chinabeing better than US.>> On Tue, Apr 28, 2020 at 12:27 AM Guido Stepken  wrote:>>>> Seems, you haven't the slightest idea, what's going on in world:>>>> China is changing gears, decoupling from TCP/IP protocol. Means: USAbecoming isolated. It's a 320 million people state, making just 5% ofglobal population.>>>>https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/>>>> China, in fact, is double as big as Europe and the US together. Apartfrom that, not only half of USA is bankrupt, with Corona now it's ⅔

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

I think, it's decided now, that China is going to remove US hardware, US
software and US protocols.

In fact, US software stacks, especially those Open Source by Apache, Linux,
.. "Foundations" have become a *huge pile of shit*:

*Billions lines of code, millions of bugs, thousands of NSA backdoors,
hundreds of intentionally slowed down algorithms, sponsored mainly by Intel*

Security Reviews? Impossible! Removing NSA contributed code, e.g. SELinux,
backdoors even deeply sticking in Linux TCP/IP stack? Impossible!

Removing Intel IME Spy Firmware Processor (MINIX) from all 2008 later
motherboards (even in notebooks) - Impossible!

To give you an idea, what's all running in parallel to your "Booted OS" of
choice:

https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf

In fact, UEFI is an Operating System, that is running parallel to your own
OS. You're booting Windows, Linux on a kind of Hypervisor, the underlying,
hidden Minix OS (a tiny UNIX Clone living in North Bridge), has *full
access* to. Means: Disk, memory, keyboard, network ...

NSA can access all of your passwords, certificates, ... any time. Even when
main processor is switched off, the Cortex-A15 core can activate power for
e.g. SSD, network on its own, even when Intel main CPU is deactivated.

And i fear, the little "US problem" with surveillance, spying on other
countries industries to gain strategic advantage and control over forein
industries, politicians, CEOs ... is much bigger than anybody can imagine.

In Europe, we now have Exokernels (similar to Hypervisors, Microkernels)
running on safe hardware (e.g. ARM Cortex-A53/55 (no Spectre/Melissa
vulnerability, like Odroid N4, RPi 3, ...) with *"UNIX as library"* running
on top, programmed in an old, rock solid funtional, compiled language named
*OCaml*. Also see ReasonML. 10x faster, 100x lesser memory footprint for
same (web, database, GUI) functionality.

New upcoming European "Gaia-X" Cloud will be built with that stuff
exclusively (security reviews ongoing), leaving US companies and their
technologies in the dust. China, India, South America are going similar
ways.

Also see "Shakti RISC-V" Project: https://shakti.org.in/

RISC-V foundation recently has been moved to Switzerland. Finished with US
influence. We're taking them out of business now. With "we" i mean whole
world with 7 billion people outside the US.

Have fun!

P.S.: I neither smoke nor am i taking drugs!

Am Dienstag, 28. April 2020 schrieb Edgaras Šeputis :
> Now you seriously smoking something. China's bullshit new IP was not
accepted by anyone, no one wants their authoritarian extensions, and say
whatever you want about US (and one can say a lot of shit about them and be
quite correct), US is still millions of miles better than China and if you
are running from US, you should run even faster from China
> I'll just point that for some time now you are acting like some kind of
weird troll, making some seemingly interesting pionts, even while
displaying crappy attitude, then spouting complete bullshit about China
being better than US.
>
> On Tue, Apr 28, 2020 at 12:27 AM Guido Stepken  wrote:
>>
>> Seems, you haven't the slightest idea, what's going on in world:
>>
>> China is changing gears, decoupling from TCP/IP protocol. Means: USA
becoming isolated. It's a 320 million people state, making just 5% of
global population.
>>
>>
https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/
>>
>> China, in fact, is double as big as Europe and the US together. Apart
from that, not only half of USA is bankrupt, with Corona now it's ⅔

Re: Stop using US controlled software stacks!!!

[Edgaras Šeputis]

Now you seriously smoking something. China's bullshit new IP was not
accepted by anyone, no one wants their authoritarian extensions, and say
whatever you want about US (and one can say a lot of shit about them and be
quite correct), US is still millions of miles better than China and if you
are running from US, you should run even faster from China.
I'll just point that for some time now you are acting like some kind of
weird troll, making some seemingly interesting pionts, even while
displaying crappy attitude, then spouting complete bullshit about China
being better than US.

On Tue, Apr 28, 2020 at 12:27 AM Guido Stepken  wrote:

> Seems, you haven't the slightest idea, what's going on in world:
>
> China is changing gears, decoupling from TCP/IP protocol. Means: USA
> becoming isolated. It's a 320 million people state, making just 5% of
> global population.
>
>
> https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/
>
> China, in fact, is double as big as Europe and the US together. Apart from
> that, not only half of USA is bankrupt, with Corona now it's ⅔.
>
> Means: Germany also is saying 'goodbye' to USA, US technology, US
> protocols, US standards ...
>
> 'Show me the code' ... what code? I don't publish on M$ owned Github or M$
> owned NPM and i will never do. Not a single US owned server will be allowed
> to carry a singe bit of my code ...
>
> Do i want to get into jail for nothing like Meng Wanzhou? No evidence, no
> proof. Or Assange, Guantanamo prisoners? See 'Military Commissions Act'.
>
> Means: Everything now gets isolated from US software/hardware
> implementations. There are even NSA Backdoors implemented in hardware, e.g.
> Broadcom Wifi silicon. All Open Source repositories (Github, NPM, Anaconda,
> NuGet) now are poisined by NSA backdoors!!!
>
> Seems, most of you guys haven't yet understood, what USA is aiming at:
> Total control of all software, hardware, communication on the world.
>
> Sorry, but simply don't care your little provocation. Either you agree
> with US strategies or you do down under!
>
> I've already warned Alex not to use US software stacks (LLVM) for Picolisp
> ... but he simply doesn't listen.
>
> Picolisp, for me, now is dead, burnt. I have to reimplement it now,
> because plenty of my code uses Picolisp. As i've already mentioned:
> Picolisp is a genius strike, carries plenty of pretty usable ideas in it.
>
> Well, using Picolisp, with mighty LLVM (420 Mbytes compressed bloat,
> backdoor injections by NSA everywhere, no security review possible) will be
> the last Picolisp for me. Pil21 is a NO-GO! Finished, for all times.
>
> You must know, how your friends are, Alex doesn't.
>
> Have fun!
>
> Am Montag, 27. April 2020 schrieb Danilo Kordic :
> > Guido Stepken:
> >> [...]
> >
> >   ""Talk is cheap, show me the code."" -- Linus Torvalds
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >
> >

Re: Stop using US controlled software stacks!!!

[Wilhelm Fitzpatrick]

China is changing gears, decoupling from TCP/IP protocol. Means: USA 
becoming isolated. It's a 320 million people state, making just 5% of 
global population.


https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/

China certainly has long wanted to isolate itself from the rest of the 
internet, given the propensity for inconvenient truths to leak in that 
way. And given that they are 1/5th of the world population, perhaps they 
can do that.


That said, not sure we in the rest of the world should be excited about 
signing up for a new basic layer with "authoritarian ready" features. As 
much as some factions in the USA would like to become "China Jr.", 
keeping the sieve leaking is our best path forward to frustrating their 
ambitions.


https://www.engadget.com/2020-03-30-china-huawei-new-ip-proposal.html

I might have to look into the actual "New IP" proposal a little further 
though. I'm curious to see if they built in any "migration path" that 
would help solve the critical mass issues that have kept IPv6 on the 
back burner for 20 years.


-wilhelm


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Seems, you haven't the slightest idea, what's going on in world:

China is changing gears, decoupling from TCP/IP protocol. Means: USA
becoming isolated. It's a 320 million people state, making just 5% of
global population.

https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/

China, in fact, is double as big as Europe and the US together. Apart from
that, not only half of USA is bankrupt, with Corona now it's ⅔.

Means: Germany also is saying 'goodbye' to USA, US technology, US
protocols, US standards ...

'Show me the code' ... what code? I don't publish on M$ owned Github or M$
owned NPM and i will never do. Not a single US owned server will be allowed
to carry a singe bit of my code ...

Do i want to get into jail for nothing like Meng Wanzhou? No evidence, no
proof. Or Assange, Guantanamo prisoners? See 'Military Commissions Act'.

Means: Everything now gets isolated from US software/hardware
implementations. There are even NSA Backdoors implemented in hardware, e.g.
Broadcom Wifi silicon. All Open Source repositories (Github, NPM, Anaconda,
NuGet) now are poisined by NSA backdoors!!!

Seems, most of you guys haven't yet understood, what USA is aiming at:
Total control of all software, hardware, communication on the world.

Sorry, but simply don't care your little provocation. Either you agree with
US strategies or you do down under!

I've already warned Alex not to use US software stacks (LLVM) for Picolisp
.. but he simply doesn't listen.

Picolisp, for me, now is dead, burnt. I have to reimplement it now, because
plenty of my code uses Picolisp. As i've already mentioned: Picolisp is a
genius strike, carries plenty of pretty usable ideas in it.

Well, using Picolisp, with mighty LLVM (420 Mbytes compressed bloat,
backdoor injections by NSA everywhere, no security review possible) will be
the last Picolisp for me. Pil21 is a NO-GO! Finished, for all times.

You must know, how your friends are, Alex doesn't.

Have fun!

Am Montag, 27. April 2020 schrieb Danilo Kordic :
> Guido Stepken:
>> [...]
>
>   ""Talk is cheap, show me the code."" -- Linus Torvalds
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Stop using US controlled software stacks!!!

[Danilo Kordic]

Gudo Stepken:
> [...]

  ""Talk is cheap, show me the code."" -- Linus Torvald

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Replace LLVW - Was: Stop using US controlled software stacks!!!

[George-Phillip Orais]

Hi Guido,

I am very interested to hear about your ASIC Lispm, how can we avail once
its out? Can you please share more details? Actually I am also trying to
get back from what we have started using FPGA but time is always not on my
side these days, but will see..

I really hope to hear from you back, thanks.


BR,
Geo


On Tue, Apr 21, 2020 at 5:37 PM Guido Stepken  wrote:

> Hi Alex!
>
> Webassembly already is ported to almost all architectures, where browsers
> are available. All those Webassembly containers in those browsers takes
> Binary Lisp code and do translate it to native machine code.
>
> If you would please have a look at that giant list of programming
> languages, that transpile to that "Binary Lisp" for being executed in
> Webassembly browser containers.
>
> https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md
>
> There are couple of server side Webassembly containers out there, that do
> either interpret Webassembly Binary Lisp code or can JIT that.
>
> Means: Your PicoLisp .l code could *directly* run in any browser and on
> any hardware in such a Webassembly container. All you need to do is to
> tokenize your PicoLisp code. That's one day of work.
>
> I still haven't the slightest idea, what you are doing there with pil21
> and LLVM. Don't use buggy, backdoored US software stacks, such as LLVM,
> GCC, VC++ or JVM any longer!
>
> We simply *don't need* them!!!
>
> Webassemby, by JITing Binary Lisp code to machine code already has
> everything in it! It's kind of universal AST to machine code compiler,
> where the AST only is represented in Binary Lisp form.
>
> I've recently completed my ASIC Lisp machine, just waiting for the board
> designers to get finished. No CPU of any kind neccessary any longer.
> PicoLisp .l code then also could directly run on that ASIC. And much
> faster, than you can imagine! ;-)
>
> Best regards, Guido Stepken
>
>
>
>
> Am Dienstag, 21. April 2020 schrieb Alexander Burger  >:
> > Hi Guido,
> >
> > On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote:
> >> 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.
> >> ..
> >> OMeta Parser/Interpreter has been translated into many programming
> >> languages and is used almost everywhere now to implement DSL (Domain
> >> Specific Languages).
> >> ...
> >> 153 Lines of OMeta code:
> >> ...
> >> 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
> >
> > Wonderful! That saves all our problems. No reason to stop pil21 :)
> >
> > LLVM is only needed to translate the IR code, generated from PicoLisp
> pil21
> > sources, to the target machine language.
> >
> > You can surely write for us such a translator in 160 lines. For now,
> targets
> > x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would
> be
> > enough.
> >
> > Issue closed! :)
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >
> >

Re: Replace LLVW - Was: Stop using US controlled software stacks!!!

[Guido Stepken]

Hi Alex!

Webassembly already is ported to almost all architectures, where browsers
are available. All those Webassembly containers in those browsers takes
Binary Lisp code and do translate it to native machine code.

If you would please have a look at that giant list of programming
languages, that transpile to that "Binary Lisp" for being executed in
Webassembly browser containers.

https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md

There are couple of server side Webassembly containers out there, that do
either interpret Webassembly Binary Lisp code or can JIT that.

Means: Your PicoLisp .l code could *directly* run in any browser and on any
hardware in such a Webassembly container. All you need to do is to tokenize
your PicoLisp code. That's one day of work.

I still haven't the slightest idea, what you are doing there with pil21 and
LLVM. Don't use buggy, backdoored US software stacks, such as LLVM, GCC,
VC++ or JVM any longer!

We simply *don't need* them!!!

Webassemby, by JITing Binary Lisp code to machine code already has
everything in it! It's kind of universal AST to machine code compiler,
where the AST only is represented in Binary Lisp form.

I've recently completed my ASIC Lisp machine, just waiting for the board
designers to get finished. No CPU of any kind neccessary any longer.
PicoLisp .l code then also could directly run on that ASIC. And much
faster, than you can imagine! ;-)

Best regards, Guido Stepken




Am Dienstag, 21. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
> On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote:
>> 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.
>> ...
>> OMeta Parser/Interpreter has been translated into many programming
>> languages and is used almost everywhere now to implement DSL (Domain
>> Specific Languages).
>> ...
>> 153 Lines of OMeta code:
>> ...
>> 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
>
> Wonderful! That saves all our problems. No reason to stop pil21 :)
>
> LLVM is only needed to translate the IR code, generated from PicoLisp
pil21
> sources, to the target machine language.
>
> You can surely write for us such a translator in 160 lines. For now,
targets
> x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would
be
> enough.
>
> Issue closed! :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Replace LLVW - Was: Stop using US controlled software stacks!!!

[Alexander Burger]

Hi Guido,

On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote:
> 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.
> ...
> OMeta Parser/Interpreter has been translated into many programming
> languages and is used almost everywhere now to implement DSL (Domain
> Specific Languages).
> ...
> 153 Lines of OMeta code:
> ...
> 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

Wonderful! That saves all our problems. No reason to stop pil21 :)

LLVM is only needed to translate the IR code, generated from PicoLisp pil21
sources, to the target machine language.

You can surely write for us such a translator in 160 lines. For now, targets
x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would be
enough.

Issue closed! :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty :
> 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?

I am using US driven services and software libraries/stacks, US computer
hardware for unimportant work only. All other neither is internet connected
nor does it use any of the known US standards for communication or
encryption. I've learned my lessons! ;-)

Have fun!

Re: Stop using US controlled software stacks!!!

[Guido Stepken]

Am Sonntag, 19. April 2020 schrieb Tomas Hlavaty :
> 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?

No. I said, that Picolisp ideas serve as prototype for new developments.

> If not, why and how could that be achieved?

Why should EU fund sponsor something, what's already there? Apart from the
fact, that Picolisp not really is unique. But it has plenty of nice ideas
in it.

> Where can I read about the EU software strategy?

We have a EU commission of experts and, of course, the official EU database
of sponsored EU projects. E.g. PyPy project has received continuous
funding(s). PostgreSQL Columnar Store Extension too. Pharo Smalltalk
Environment ...

Best regards, Guido Stepken

Re: Stop using US controlled software stacks!!!

[Jean-Christophe Helary]

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

[Jeronimo Pellegrini]

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

[Tomas Hlavaty]

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

[Tomas Hlavaty]

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]

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

[Guido Stepken]

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: Stop using US controlled software stacks!!!

[Jeronimo Pellegrini]

[ 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!!!

[Guido Stepken]

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

[Tomas Hlavaty]

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: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

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

[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!!!

[Guido Stepken]

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

[Tomas Hlavaty]

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

[Tomas Hlavaty]

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

[Tomas Hlavaty]

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

[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://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!!!

[Guido Stepken]

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

[Guido Stepken]

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: Stop using US controlled software stacks!!!

[George-Phillip Orais]

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

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

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Stop using US controlled software stacks!!!

[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!!!

[George-Phillip Orais]

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

[Guido Stepken]

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

[Guido Stepken]

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

[Alexander Shendi (Web.DE)]

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

Re: Stop using US controlled software stacks!!!

[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!!!

[George-Phillip Orais]

Just for fun: I cannot imagine Guido's email what if Alex will announce
that he will stop pil21 and decide to port PicoLisp to WINDOWS and use .NET
as official VM ^^



On Sun, Apr 19, 2020 at 7:24 AM  wrote:

> Hey Guido!
>
> While I don't disagree with you in spirit (and I'm sure it's the same for
> most  of our community, we're a bunch of purist radicals), I have to
> disagree with your tone.
>
> And i can assure you: My influence is **much bigger** than you might
> think! Stop that, immediately!
>
> This is childish. You think we would part of this niche community (even
> pico-tiny within the lisp culture) if such words would work on us? Think
> again.
>
> We're not so much interested to convert anyone to our path by doing
> missionary work - nice if it happens, we welcome it, but not for the price
> of our principles. We foster the old programming hacker culture, only
> practical results (be it elegant code, elegant designs or well-thought
> arguments) count in this group. We don't give a damn about who you know or
> what influence you have. Certainly we like interesting stories, and we're
> open and welcoming to everyone - but for getting respected here you must
> deliver us something we value according to our standards.
>
> You are invited to develop the pil stack further, hands on, what holds you
> back?
> The PicoLisp stack is simple enough that we surely could coordinate
> multiple variants if people like to do the work. Less talking and more
> doing, Guido!
> Theorizing is nice and sometimes worthwile, but we're allergic to mental
> masturbation, let's not mix up the map with the real territory.
>
> Kind regards and no offense,
> beneroth
> On 18.04.20 22:46, Guido Stepken wrote:
>
> 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
> >
> >
>
>

Re: Stop using US controlled software stacks!!!

[andreas]

Hey Guido!

While I don't disagree with you in spirit (and I'm sure it's the same
for most  of our community, we're a bunch of purist radicals), I have to
disagree with your tone.

> And i can assure you: My influence is **much bigger** than you might
> think! Stop that, immediately!
This is childish. You think we would part of this niche community (even
pico-tiny within the lisp culture) if such words would work on us? Think
again.

We're not so much interested to convert anyone to our path by doing
missionary work - nice if it happens, we welcome it, but not for the
price of our principles. We foster the old programming hacker culture,
only practical results (be it elegant code, elegant designs or
well-thought arguments) count in this group. We don't give a damn about
who you know or what influence you have. Certainly we like interesting
stories, and we're open and welcoming to everyone - but for getting
respected here you must deliver us something we value according to our
standards.

You are invited to develop the pil stack further, hands on, what holds
you back?
The PicoLisp stack is simple enough that we surely could coordinate
multiple variants if people like to do the work. Less talking and more
doing, Guido!
Theorizing is nice and sometimes worthwile, but we're allergic to mental
masturbation, let's not mix up the map with the real territory.

Kind regards and no offense,
beneroth

On 18.04.20 22:46, Guido Stepken wrote:
> 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
> mailto:a...@software-lab.de>>:
> > 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
> >
> > 

Stop using US controlled software stacks!!!

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