<beneroth>
container/VM is no security (say the OpenBSD guys, I think they're right)
<beneroth>
ASLR is obfuscation, no security (says Regenaxer, I think he is right)
<clacke[m]>
ASLR is mitigation
<beneroth>
well..obfuscation. no bug in program -> no need for ASLR. it is only used because it seems to be cheap
<beneroth>
fix the program.
<clacke[m]>
of course it's better to not have bugs
<beneroth>
yes, and ASLR might rescue you, but no guarantees! so..its obfuscation.
<beneroth>
well, ASLR + disabled CPU cache might give a pretty good guarantee, but not 100%.
<beneroth>
and you don't want to disable CPU cache
<beneroth>
the problem with probably-working-mitigation is, it resolves the pain of bugs enough that nobody cares. until a worm/ransomware/big-scale-attack uses it
<beneroth>
so.. maybe this security/bug pain is a good thing
aw- has joined #picolisp
<aw->
I submitted updated picolisp extensions for TinyCore Linux
<aw->
it was still on 16.6 in the latest tinycore 8.x
<Regenaxer>
Thanks aw-!
<aw->
submitted with pil 17.12
<aw->
perhaps i can handle the ARM releases as well...
<aw->
they don't seem to have arm64 builds though
<aw->
last i saw, their arm64 builds were running armv7 (32-bit) binaries or something like that
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
freeemint_ has joined #picolisp
<freeemint_>
Hi Regenaxer cani have your CV?
<freeemint_>
tankfeeder: I hereby request the CV of Alex Burger
<Regenaxer>
Hi freeemint_, first I need your project request ;)
<freeemint_>
Lets discuss financial matters in query not here
alexshendi has quit [Ping timeout: 248 seconds]
<freeemint_>
Which languages are interesting to write your own LISP dialect?
<beneroth>
every lisp
<beneroth>
:D
<beneroth>
or maybe C, most portable language
<freeemint_>
Would rust, borrowchecking bring anything interesting to the table for a lisp interpreter?
<beneroth>
I think language choice generally heavily depends on your specific use case. Naturally you can achieve anything in every turing-complete language, but your special lisp interpreter might require some feats which are much more easy to achieve in some languages than in other
<Regenaxer>
Yep, so assembly is definitely the best to write an interpreter
<beneroth>
if you are not aware of any such special requirements (like e.g. arbitrary stack growing, which prompted Regenaxer to use assembler instead of C)
<beneroth>
then just use the language you are most familiar/capable with
<beneroth>
better have a slow first running version of your own interpreter than a never-finished perfect one
<beneroth>
first make it running, then make it nice.
<Regenaxer>
T
<freeemint_>
Is there a reason to use a traditional stack over a stack made from cells?
<Regenaxer>
efficiency
<Regenaxer>
plus you need it if you want to make native calls
<beneroth>
Regenaxer, mashina is now using multiple DB files (currently generally 20 files)
<beneroth>
not-yet-fully-optimized first multip-file version
<beneroth>
and blocksize of default/first file increased to 4
<beneroth>
index btree levels have no relations to blocksize, is that right?
<beneroth>
how is it determined when a new level (in another block) is created ?
* beneroth
hasn't fully understood there something...
<freeemint_>
beneroth how large scale is your application?
<Regenaxer>
beneroth, what do you mean with index btree levels?
<Regenaxer>
the depth of the tree?
<Regenaxer>
"blocksize of default/first file increased to 4" is good I think
<beneroth>
freeemint_, currently pretty small (e.g. up to a few hundred users)
<freeemint_>
ok
<beneroth>
freeemint_, but meant for general re-usability...
<beneroth>
this part of it
<beneroth>
Regenaxer, yeah depth of tree
<beneroth>
how is depth determined
<beneroth>
bbl
<Regenaxer>
right
<Regenaxer>
small blocks give deeper trees
<freeemint_>
Regenaxer: Is there a technical reason why you can only pool one DB at the time? Or is there just not any need for it?
<Regenaxer>
It caches the symbols in these files in the heap
<Regenaxer>
Would be difficult for several DBs
<Regenaxer>
But you can easily switch DBs with (pool ...) in the middle of a program if needed
<Regenaxer>
(never needed it though)
<freeemint_>
So the problem in name colliosion?
<freeemint_>
*is
<Regenaxer>
Even before they collide ... it is the scope
<Regenaxer>
a name encodes file and block offset
<Regenaxer>
not DB
<Regenaxer>
All external symbols have therefore the scope of a given DB
<Regenaxer>
(logical DB, physically it may span remote machines or special cases)
<Regenaxer>
for example, the JVM in Android appears like a DB to PicoLisp
<Regenaxer>
ie. Java objects map to external symbols
<freeemint_>
mhh i see
<Regenaxer>
So you can map several DBs into the single logical scope
<Regenaxer>
On Android I have both the JVM and a normal DB open at the same time
<freeemint_>
Is there a remote access protocol for DB's
<Regenaxer>
This works cause the JVM has no E/R definitions
<Regenaxer>
yes
<Regenaxer>
of course
<Regenaxer>
otherwise it would not work
<freeemint_>
Is it possible to make a database read only? (under some circumstances)
<Regenaxer>
yes, just don't write to it ;)
<Regenaxer>
The Java objects are never written this way
<Regenaxer>
And remote (physically) DBs I also never write
<Regenaxer>
just send rpc messages to request changes
<Regenaxer>
Just try it to find out the details
<freeemint_>
i see
<freeemint_>
I do not really like "just do not write to it" ... but picolisp is just not ment to be explosed to the user i guess
<freeemint_>
i got to go
<Regenaxer>
It is meant to be explored by the user
<freeemint_>
but not written to ...
<freeemint_>
bye
freeemint_ has quit [Quit: Page closed]
<beneroth>
well... that is not at all picolisp related but the concept of non-consent-distributed-databases...
<beneroth>
anyway
<beneroth>
Regenaxer, block size should be large enough to not prompt a deeper level (I think)
<beneroth>
could it be that index relations which end up in file 1 because no Dbf (dbs) was specified for them assume blocksize 2 ?
<Regenaxer>
The size seems optimal at 6 for large trees
<beneroth>
yeah I made a 4 and 6 indice file
<Regenaxer>
I think if they default to 1, they still use the file's block size
<Regenaxer>
hmm
<Regenaxer>
not sure atm
<beneroth>
ok, I try to find out myself
<Regenaxer>
ok, maybe you are right
<Regenaxer>
yes, right
<beneroth>
I just splitted some data up here, and then review the blocksize usage (under-used vs over-used) per file
<Regenaxer>
Dbf is NIL then
<beneroth>
aye
<Regenaxer>
So a tree node may span several blocks
<Regenaxer>
or just half ones
<Regenaxer>
Nothing bad happens though, just not optimally efficient
<beneroth>
aye
<beneroth>
I have assigned all entities to files now, but not all index relations (soo many)
<Regenaxer>
ok
<beneroth>
so most end up in default file, and under-use the blocksize 4
<beneroth>
apparently
<Regenaxer>
I always do it immediately when I add new relations
<beneroth>
yeah good approach :)
<Regenaxer>
(dbCheck) tells you anyway
<beneroth>
I know
<beneroth>
used it a lot today
<beneroth>
very handy
<beneroth>
ah
orivej has joined #picolisp
<beneroth>
(dbfCheck)
<beneroth>
I used, not (dbCheck)
<beneroth>
hi orivej
<Regenaxer>
ok, it is called by dbCheck internally
<Regenaxer>
Just (dbfCheck) is faster
<beneroth>
T
<beneroth>
ah yes
<beneroth>
new index trees are created by (rel> '+index) via (store Tree Old NIL (: dbf)) - so when dbf is missing, it uses (according to documentation) "a database block size (defaulting to 256)"
<beneroth>
so my conclusion from data observation was right :)
<Regenaxer>
right
* beneroth
loves how easy it is to inspect inner workings in picolisp
<Regenaxer>
I just checked @lib/db.l too
<Regenaxer>
(: dbf) is NIL
<Regenaxer>
eg. (store Tree Old NIL (: dbf))
<Regenaxer>
so we default to 2 = 256
<beneroth>
point is, in mashina the database schema including file assignments might change over time - my end goal is tooling which analyses the data and proposes to the administrator to which blocksizes objects/indices should be assigned
<beneroth>
yep
<Regenaxer>
You can 'rebuild' then if needed
<beneroth>
aye
<beneroth>
ok, all riddles solved for today, many thanks Regenaxer :)