Re: Small Docker container builds the latest pil in Alpine image

[Guido Stepken]

Yes, you're right. Docker, from security point of view, is like a Swiss
Cheese. I always succeeded to find a way to break out, getting *full
access* to the underlying machine. Always!

Webassembly is a bit different. We now have around 200 people working
fulltime at building the "absolutely safe" webassembly interpreter. Not a
compiler, but an interpreter catching any undefined bytecode behaviour.
It's designed from scratch with security in mind - right from the
beginning.
Why? ***You can't test security into software!***

But this is, what stupid cowboys use to do. Unqualified (from security
point of view) people writing world class software?  ... A nightmare!

Whole Linux/Apache Foundation software packages - from security point of
view - finally are ready for the dustbin. Not ready for mission critical
purposes to keep the world going. See e.g. Emotet virus/trojan. Since one
year now it's spreading and Microsoft still has no antidote. This is not a
professional company, IMHO. Bunch of idiots, for sure. Same for Intel.

Use L4 kernel on ARM Cortex-A53 CPUs. Spectre, Meltdown? - ARM Cortex-A53
is - not affected. Makes a $25 Raspberry Pi 3 safest solution ever!

Have fun!

Guido Stepken

Am Donnerstag, 26. März 2020 schrieb David Bloom :

Too bad that WebASM is bunk from a security perspective and I share your
> love for hardware isolation.  Wherever it is running I am grateful for the
> language and the community.
>
> Cheers,
> David B.
>
> On Thu, Mar 26, 2020 at 9:43 AM  wrote:
>
>> Thanks for your informative email.
>>
>> I mostly agree with your points, except for WebAssembly on the client.
>> Though you differentiate between WebASM on client and on server - didn't
>> know about WebASM on server, might be a very good thing!
>>
>> But WebASM on the client is a epic conceptual mistake - it is the new
>> Adobe Flash.
>> Already now it is mostly used for malware obfuscation:
>> https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf
>>
>> Web scripting languages should not be turing complete, same holds true
>> for everything with untrusted scripting input.
>> Impossible to validate, unless you execute it. Yes, containment using
>> sandboxing turns out to be a better strategy than we thought years ago, but
>> still it gives a strong incentive to not work properly.
>>
>> Of course, that battle is already lost :(
>>
>> Security-wise, the whole cloud business should be dead, only full
>> hardware isolation gives full security.
>> Servers could be many small devices (e.g. rock64's, raspis, ..) instead
>> of shared resources with many layers and much (energy) overhead.
>>
>> No, I don't fully practice this, not viable currently.
>> Yes, I enjoy living in my radical purity niche.
>>
>> Have fun ;-)
>> - beneroth
>> On 26.03.20 13:35, Guido Stepken wrote:
>>
>> Though - for some folks - it might make things simpler, i am no friend of
>> Docker.
>>
>> What the Docker founder is saying about Docker now:
>>
>> Solomon Hykes
>> @solomonstre
>> 
>> ·
>> 27 März 2019
>> 
>> If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
>> That's how important it is. Webassembly on the server is the future of
>> computing. A standardized system interface was the missing link. Let's hope
>> WASI is up to the task!
>>
>> Source: https://twitter.com/solomonstre/status/004913222324225
>>
>> Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler and
>> runs perfectly in (server side) Webassembly containers. It's completely
>> replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.
>>
>> https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
>>
>> And when you look deeper into Webassembly, you will notice, that - in
>> itself - it's a Lisp, very much like Picolisp.
>>
>> https://developer.mozilla.org/en-US/docs/WebAssembly/
>> Understanding_the_text_format
>>
>> Lisp now rules the world. And Linux has won! ;-)
>>
>> Have fun!
>>
>> Guido Stepken
>>
>> Am Mittwoch, 25. März 2020 schrieb David Bloom :
>>
>>> For work reasons I have strayed from the beloved PicoLisp into Erlang
>>> for some time.  While I have much love for using Erlang/OTP to build
>>> robust, distributed systems, it handles a different job than PicoLisp in my
>>> opinion.  Even though work kept me in the Erlang world for a while I still
>>> followed the mailing list and one day saw instructions on how to build pil
>>> with musl.  After a single attempt in a fresh Alpine container it worked so
>>> I felt compelled to share with the group.  BEHOLD!
>>>
>>> https://hub.docker.com/r/progit/pil-alpine-minimal
>>>
>>> Big, big thanks again to Alex and this entire community.  Happy hacking!
>>>
>>

Re: Small Docker container builds the latest pil in Alpine image

[David Bloom]

SmartOS provides good multi-tenant isolation but it won't run on a Rock64
or Raspi.  That said I do have a rock64, love it, and wish I had a need for
something so that I could buy a clusterboard.  A 28-core, 14GB RAM cluster
on a mini-ITX board for ~275 euros could get some nice work done.

Too bad that WebASM is bunk from a security perspective and I share your
love for hardware isolation.  Wherever it is running I am grateful for the
language and the community.

Cheers,
David B.

On Thu, Mar 26, 2020 at 9:43 AM  wrote:

> Thanks for your informative email.
>
> I mostly agree with your points, except for WebAssembly on the client.
> Though you differentiate between WebASM on client and on server - didn't
> know about WebASM on server, might be a very good thing!
>
> But WebASM on the client is a epic conceptual mistake - it is the new
> Adobe Flash.
> Already now it is mostly used for malware obfuscation:
> https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf
>
> Web scripting languages should not be turing complete, same holds true for
> everything with untrusted scripting input.
> Impossible to validate, unless you execute it. Yes, containment using
> sandboxing turns out to be a better strategy than we thought years ago, but
> still it gives a strong incentive to not work properly.
>
> Of course, that battle is already lost :(
>
> Security-wise, the whole cloud business should be dead, only full hardware
> isolation gives full security.
> Servers could be many small devices (e.g. rock64's, raspis, ..) instead of
> shared resources with many layers and much (energy) overhead.
>
> No, I don't fully practice this, not viable currently.
> Yes, I enjoy living in my radical purity niche.
>
> Have fun ;-)
> - beneroth
> On 26.03.20 13:35, Guido Stepken wrote:
>
> Though - for some folks - it might make things simpler, i am no friend of
> Docker.
>
> What the Docker founder is saying about Docker now:
>
> Solomon Hykes
> @solomonstre
> 
> ·
> 27. März 2019
> 
> If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
> That's how important it is. Webassembly on the server is the future of
> computing. A standardized system interface was the missing link. Let's hope
> WASI is up to the task!
>
> Source: https://twitter.com/solomonstre/status/004913222324225
>
> Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler and
> runs perfectly in (server side) Webassembly containers. It's completely
> replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.
>
> https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
>
> And when you look deeper into Webassembly, you will notice, that - in
> itself - it's a Lisp, very much like Picolisp.
>
>
> https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format
>
> Lisp now rules the world. And Linux has won! ;-)
>
> Have fun!
>
> Guido Stepken
>
> Am Mittwoch, 25. März 2020 schrieb David Bloom :
>
>> For work reasons I have strayed from the beloved PicoLisp into Erlang for
>> some time.  While I have much love for using Erlang/OTP to build robust,
>> distributed systems, it handles a different job than PicoLisp in my
>> opinion.  Even though work kept me in the Erlang world for a while I still
>> followed the mailing list and one day saw instructions on how to build pil
>> with musl.  After a single attempt in a fresh Alpine container it worked so
>> I felt compelled to share with the group.  BEHOLD!
>>
>> https://hub.docker.com/r/progit/pil-alpine-minimal
>>
>> Big, big thanks again to Alex and this entire community.  Happy hacking!
>>
>

Re: Small Docker container builds the latest pil in Alpine image

[David Bloom]

On Thu, Mar 26, 2020 at 8:43 AM Guido Stepken  wrote:

> Though - for some folks - it might make things simpler, i am no friend of
> Docker.
>
> What the Docker founder is saying about Docker now:
>
> Solomon Hykes
> @solomonstre
> 
> ·
> 27. März 2019
> 
> If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
> That's how important it is. Webassembly on the server is the future of
> computing. A standardized system interface was the missing link. Let's hope
> WASI is up to the task!
>
> Source: https://twitter.com/solomonstre/status/004913222324225
>
>
I had no idea.  That's what I get for being out of the loop for a few years

Re: Small Docker container builds the latest pil in Alpine image

[andreas]

Thanks for your informative email.

I mostly agree with your points, except for WebAssembly on the client.
Though you differentiate between WebASM on client and on server - didn't
know about WebASM on server, might be a very good thing!

But WebASM on the client is a epic conceptual mistake - it is the new
Adobe Flash.
Already now it is mostly used for malware obfuscation:
https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf

Web scripting languages should not be turing complete, same holds true
for everything with untrusted scripting input.
Impossible to validate, unless you execute it. Yes, containment using
sandboxing turns out to be a better strategy than we thought years ago,
but still it gives a strong incentive to not work properly.

Of course, that battle is already lost :(

Security-wise, the whole cloud business should be dead, only full
hardware isolation gives full security.
Servers could be many small devices (e.g. rock64's, raspis, ..) instead
of shared resources with many layers and much (energy) overhead.

No, I don't fully practice this, not viable currently.
Yes, I enjoy living in my radical purity niche.

Have fun ;-)
- beneroth

On 26.03.20 13:35, Guido Stepken wrote:
> Though - for some folks - it might make things simpler, i am no friend
> of Docker.
>
> What the Docker founder is saying about Docker now:
>
> Solomon Hykes
> @solomonstre
> 
> ·
> 27. März 2019
> 
> If WASM+WASI existed in 2008, we wouldn't have needed to created
> Docker. That's how important it is. Webassembly on the server is the
> future of computing. A standardized system interface was the missing
> link. Let's hope WASI is up to the task!
>
> Source: https://twitter.com/solomonstre/status/004913222324225
>
> Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler
> and runs perfectly in (server side) Webassembly containers. It's
> completely replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.
>
> https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
>
> And when you look deeper into Webassembly, you will notice, that - in
> itself - it's a Lisp, very much like Picolisp.
>
> https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format
>
> Lisp now rules the world. And Linux has won! ;-)
>
> Have fun!
>
> Guido Stepken
>
> Am Mittwoch, 25. März 2020 schrieb David Bloom  >:
>
> For work reasons I have strayed from the beloved PicoLisp into
> Erlang for some time.  While I have much love for using Erlang/OTP
> to build robust, distributed systems, it handles a different job
> than PicoLisp in my opinion.  Even though work kept me in the
> Erlang world for a while I still followed the mailing list and one
> day saw instructions on how to build pil with musl.  After a
> single attempt in a fresh Alpine container it worked so I felt
> compelled to share with the group.  BEHOLD!
>
> https://hub.docker.com/r/progit/pil-alpine-minimal
>   
>
> Big, big thanks again to Alex and this entire community.  Happy
> hacking!
>

Re: Small Docker container builds the latest pil in Alpine image

[Guido Stepken]

Though - for some folks - it might make things simpler, i am no friend of
Docker.

What the Docker founder is saying about Docker now:

Solomon Hykes
@solomonstre

·
27. März 2019

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.
That's how important it is. Webassembly on the server is the future of
computing. A standardized system interface was the missing link. Let's hope
WASI is up to the task!

Source: https://twitter.com/solomonstre/status/004913222324225

Picolisp compiles perfectly fine with emcc Emscripten C/C++ compiler and
runs perfectly in (server side) Webassembly containers. It's completely
replacing any Docker/Hyper-V/VMware/Amazon AWS Lambda solution.

https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm

And when you look deeper into Webassembly, you will notice, that - in
itself - it's a Lisp, very much like Picolisp.

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

Lisp now rules the world. And Linux has won! ;-)

Have fun!

Guido Stepken

Am Mittwoch, 25. März 2020 schrieb David Bloom :

> For work reasons I have strayed from the beloved PicoLisp into Erlang for
> some time.  While I have much love for using Erlang/OTP to build robust,
> distributed systems, it handles a different job than PicoLisp in my
> opinion.  Even though work kept me in the Erlang world for a while I still
> followed the mailing list and one day saw instructions on how to build pil
> with musl.  After a single attempt in a fresh Alpine container it worked so
> I felt compelled to share with the group.  BEHOLD!
>
> https://hub.docker.com/r/progit/pil-alpine-minimal
>
> Big, big thanks again to Alex and this entire community.  Happy hacking!
>

Re: PicoLisp on windows

[Guido Stepken]

Sure. But tell me: What is faster? A tiny Picolisp interpreter binary, that
entirely fits into 1st/2nd/3rd level cache, accesses memory without
waitstaites - or a huge, multi gigabyte JIT engine, that, in itself, is a
pure memory monster?

My measurements show, that small, tiny interpreters - especially for lambda
microservices - are much faster than any Microsoft/Oracle/Apple (LLVM is
heavily sponsored by Apple!) technology.

And then you will also notice, that your "cloud memory footprint" (tens of
thousands of micoservices running at the same time with different customer
data, each) will tremendously go down, when you simply don't use any
"Wintel Alliance" technology: "We make slower software for you make faster
hardware!" (where Apple and Oracle certainly belong to!)

It saves you plenty of money, when you simply don't use U.S. technology
(neither Closed Source nor Open Source), using a sledgehammer to crack a
nut.

Tiny interpreters, like Picolisp, here have tremendous advantages. Also
don't forget to activate KSM (Kernel Same-page Merging) in Linux. Same
binaries (4K memory pages) get consolidated, only use one, single binary
instance in DRAM.

Remember: *Picolisp is a genius-strike!*

Most people simply don't understand why, because they simply got victim of
long-term U.S. advertising strategies selling more and more hardware to
host bigger and bigger software packages. That nonsense has kept up going
Silicon Valley for two decades now, pulling billions from our pockets.

Have fun!

Guido Stepken


Am Donnerstag, 26. März 2020 schrieb :

> Does anyone realize that there's an LLVM-based port of picolisp being
> worked on by Alex? :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>