Something that could really change thinks

After years of parsing of packaging systems, software distribution technologies, OSX Bundles, ROX AppDir, GoboLinux way to do thinks, Autopackage, Klik & Co, BSD Ports, PC BSD way to spread to the world catalog software, Java WebStart, NetBSD pkgsrc, ex Lindows ;) klik like catalog with browser integration to mimic dmg OSX management...and so on.. I made SpatialBundles.

Single file full application bundles that you can manage like any other file in an typical human object oriented way...move, remove, send without using any intermediate layer like gio/kio/gvfs & co just use the power of file system engine (the layer exported from the kernel and available in the same way to all).

I think the best way to feel what I mean is to test on the road software packaged with SpatialBundle technology.

here you can taste it:

http://downloads.infodomestic.com

Today the SpatialBundles are build with Ubuntu Linux but in future will be easy to build against any UNIX flavor like *BSD, OSX and Windows that support POSIX shell

To better feel the power of what I did just start to taste Winamp that represent more than one technologies glued together into a SpatialBundle.

SpatialBundle is made for generic human that does not like complexity.Think my little children or my grandmother, peoples that does know about computer but want just make few direct click to object oriented thinks.

The process to manage a SpatialBundle is reduced to:

1) Download from internet or receive it by mail or by USB key or by CDROM or what else you think it's better for you..
2) Add exec attribute on the file
3) Double click on it

Then you have your application running

No root password
No installation
No dependencies required other than provided by the standard Ubuntu (Operative system) first installation.

SpatialBundle now support freedesktop menu and hidden configuration and local files.
When you start a SpatialBundle an icon appear into desktop and into tray icon.
The icon tray let you access to a little menu to better manage the package (About,Open,Send,Reset) i.e. the Send item let you send your bundle via mail (in the future by bluetooth like you can find into generic mobile phone) or send to Desktop or a selected folder...

At this point of my development cycle I think that there is nothing equivalent to the world like SpatialBundles they seems to be really unique.
I know that there is a lot of very closed technologies around here but nothing so extreme closed to an file/objects without any dependencies other that POSIX shell.

SpatialBundle are self protected against code injection so it's up to the distribution to provide catalog based key signed.
If code injection was made, SpatialBundle does not start at all.

The portability of a SpatialBundle is granted by using the most portable and available language that is POSIX shell.No Perl, no Python, no Ruby no other dependencies in term of language other than posix shell.
This help me to think in term of easy migration through OSs like OSX, BSD and finally Windows (why not!!).

Today I'm fine tuning the builder before release as GPL source code but you can freely use the SpatialBundle I already made now.

Hope this will help you to thread better your life

[The Road To...] atomic transaction safe file move

Dopo vari esperimenti ne emerge che c'è un grosso pericolo che la cache RAM venga velocemente saturata dai software pesanti.
A tal proposito consiglio la seguente modifica: Il centro nevralgico di esecuzione risulta essere /tmp/Programs/ioProgramma ma lo spatial bundle prepara alla migrazione in /dev/shm/Programs/ e nel caso migra solo ioProgramma nel seguente modo:
1) mi assicuro che la cartella /dev/shm/Programs esiste
2) mi assicuro che lo spazio necessario a destinazione sia sufficiente (> 10% del programma)
3) mv /tmp/Programs/ioProgramma /dev/shm/Programs/ioProgramma
4) ln -s /dev/shm/Programs/ioProgramma /tmp/Programs/ioProgramma

Per garantire l'atomicita della transazione sarebbe il caso di usare la tecnica di OSX dove viene creato un segnaposto per il nome del file prima di cominciare a copiare a destinazione.
Il segnaposto viene creato con un semplice $touch ioProgramma in questo modo si ha garantito uno pseudo lock sul nome file ma non sulla grandezza.
Potrebbe essere possibile associare al touch il comando dd in questa sequenza:
1) Si esegue il touch fileDestinazione in modo ricorsivo
2) Si esegue dd if=fileSorgente of=fileDestinazione in modo ricorsivo

Ritengo necessario quindi riscrivere l'algoritmo di mv Move con i seguenti metodi:
check Destinazione >10%
touch a Destinazione
dd if of
diff destinazione sorgente = 0
rm Sorgente

bitJet=true
Se l'utente dinamicamente decide di spostare il software nella turbocache bitJet deve poterlo fare con i metodi che gia conosce, ovvero passare comandi live usando il programma stesso esempio ioProgramma --bitJet=true anche se ioProgramma è gia in esecuzione riceve e modifica lo stato spostando dalla cache disco a quella RAM.
ioProgramma --bitJet=false riporta la cache RAM a cache Disk.

In questo modo si puo dare uno strumento dinamico anche al sistema per gestire criticita.

E' possibile rendere la soluzione ancora piu granulare agendo direttamente sui binari e sulle singole librerie facendo magari riferimento ad una lista di oggetti che lo sviluppatore vuole granularmente rendere piu veloci a runtime.

I vari livelli di granularita potrebbero passare per:
Tutto il programma in blocco
Solo le cartelle bin,sbin,lib,var
I singoli componenti a scelta libera

Per ognuna delle soluzioni è necessaria una gestione precisa dei link simbolici.

E' comunque sempre necessario a livello di first time building eseguire un profiling preciso di performance per identificare le bottleneck del programma ed eventualmente proporre un caching RAM per quelle componenti particolarmente penalizzate senza necessariamente tirare dentro blocchi di bit non influenti al fine del miglioramento dell'efficienza di esecuzione.