[The Road To...] Domenica 14 Ottobre 2007

Mattina:
Riduco al minimo l'utilizzo di zenity in favore di xmessage prima di finire di mettere completamente a punto ioDialog che rappresenta l'oggetto di dialogo di Infodomestic Objects (wrapper a tutte le forme di widget dialogs disponibili sulle distribuzioni).
Test su Ubuntu Dapper, Ubuntu Feisty, FreeBSD 6, PCBSD, Sun Solaris 10
TODO: pulizia zenity con xmessage
La dicitura:
xmessage -center -buttons Yes,No -default No -print message
scrive il messaggio "message" con i pulsanti [Yes][No] e default evidenziato su [No], cliccando su un pulsante ritorna il nome del pulsante.
10:59
99% delle dipendenze a zenity sono state escluse e sostituite dal più flessibile xmessage.
Rimane la principale dipendenza che permette la manipolazione del system tray elementare.
A differenza di Zenity con xmessage è possibile integrare testo di Help per le scelte da operare.
Nei messagi di conferma dove compare solo il classico testo piu pulsante tipo:
--------------------------------------------------
"Ciao tutte le cose sono state svolte!!"
[OK]
--------------------------------------------------
Ho inserito un delay di 5 secondi per auto chiudersi.
Dipendenze da risolvere:
System tray entry per il primo menu e File selector per la scelta di destinazione del Send to...
Questi due componenti possono essere completamente riprogrammati con FLTK o simili.

11:24
Trunk SpatialFactory 0.8.8
0.8.8 usa xmessage per comunicare.
Si aspetta due file proxy di nome: ioNomeProgramma e ioWrapper in Contents/Resources/bin per la gestione dei binari reali

12:47
Attualmente nella modalità --silent si perde completamente il controllo della gestione del'oggetto, ovvero non si possono modificare gli attributi ne inviare messaggi per richiamare evetuali metodi (come per esempio il metodo Remove).
E' necessario introdurre un punto di ingresso sicuro tramite il file system come per esempio $HOME/Objects all'interno del quale replicare la vista di ioDock e permettere di accedere ai metodi esposti nel tray:
About
Open
Send
Controls
Remove

Quindi ioDock può far riferimento diretto a $HOME/Objects

Ad ogni esecuzione diretta copia l'oggetto ioMenu in $HOME/Objects ed esegue $HOME/Objects/ioProgrammaMenu --Open
Ad ogni Remove rimuove anche il relativo $HOME/Objects/ioProgrammaMenu
Se si esegue Open e ioProgramma non è disponibile allora autorimuove $HOME/Objects/ioProgrammaMenu e rilascia un messaggio di avvertimento.
Ciò preserva da evenutali condizioni di inconsistenza dove è presente il Menu ma non il programma.
ioProgrammaMenu è uno SpatialBundle

14:58
Primo wrapper 100% convertito in Object Rexx.
Nel frattempo la legna nel camino viene divorata dalle fiamme tramite una funzione gradino del tipo: Ciocco umido->Brace ... non c'è gusto
Devo cambiare notebook a passare a qualcosa con monitor max 15pollici, case alluminio, doppio processore 64bit super efficiente, batteria eterna, wifi e bluetooth, super scheda grafica 3D OpenGL con tanta RAM non condivisa.Ma i Powerbook ultima serie ci si avvicinano?Vedremo.

20:45
Mollo tutto e mi faccio una minidose di tenente Colombo e poi Heroes a tutto spiano.Rexx puo aspettare.
Dopo vomito pe la giornata in modalita macinacodice...ora mi godo il trip televisivo.

[The Road To...] Sabato 15 Settembre 2007

I post The Road To vengono prodotti con tomboy in modalita macinacodice.
Questi poi vengono tenuti in stagionatura in .tomboy fino a quando non mi rendo conto che mi sto ricordando di doverli postare!!!

---

18:00
E' dalle 9:30 di questa mattina che sono testa chinata sulla tastiera ad emettere flussi di bit.
Ho preparato un ambiente di runtime per REXX tramite Regina.
Ora si clicca sul Bundle ioReginaREXX e si avvia un terminale dedicato all'interno del quale è disponibile l'ambiente interpretato di Regina e quindi possibile passargli uno script .rexx da eseguire.
L'ambiente ha con se tutte le variabili di ambiente settate e disponibili, nonchè una shell ristretta.

Penso che gli sviluppatori di applicazioni desktop che richiedono un'interfaccia grafica, oggi dovrebbero preoccuparsi di offrire con la stessa applicazione delle interfacce separate e dedicate per classi di dispositivi.
Ad esempio:
Personal computer con monitor da almeno 8/10 pollici
Dispositivi mobili con monitor 4/8 pollici
Dispositiv mobili con monitor max 4 pollici.

Insomma la stessa applicazione ricompilata per un Nokia N73, per un Palm Tungsten, Per un Nokia N800, per un table da 10 pollici, per un iBook 12 fino a un desktop da 20 pollici, etc etc... dovrebbero avere delle interfacce grafiche disegnate esplicitamente per quel tipo di visualizzazioni.
E' lo stesso problema che i designers web incontrano ed affrontano già da tempo.
Quindi mi auguro che in futuro essi sviluppano più di una interfaccia dedicata.
Oggi è possibile pensare seriamente all'utilizzo di interfacce AJAX locali, chiaramente supportate da motori di rendering superveloci che tengono il passo con i widget classici.

20:49
Compilato e "Bundlizzato" ioLibnotify che verrà usato come componente di notifica dagli SpatialBundles.
Sarà onnipresente in ogni Bundle come carico pagante da 405Kilos
Il Dock tray implementato già da almeno una settimana funziona a meraviglia.La sua garanzia di funzionamenteo è strettamente vincolata all'utilizzo di Ubuntu Feisty.Questo concetto necessità di seria revisione ponendo in primo piano elementi quali: indipendenza dal gnome -panel e dal system tray applet di gnome.
In poche parole potrebbe essere necessario prendere in considerazione un pannello gtk/gnome agnostico che puo girare ovunque e che abbia un system tray bay standard che accetti icone svg/png da 128px.

Devo costruire un sistema di notifica basato su named pipe e non su librerie da compilare.
Il sistema, li dove presente, esegue il faultback a libnotify altrimenti esegue la sua notifica nativa da implementare con widget leggeri e super specializzati.

Il prossimo sistema di notifica sarà basato su OSD per operare un rinforzo informativo sulle attività dei Bundles.

Le notifiche devono poter operare ed essere esplicitate anche in una console.

Infodomestic Objects non vuole reinventare un mondo su tutte le piattaforme come sta riuscendo egregiamente Gnome tramite le sue librerie specializzate, ma vuole dare una forma al mondo che già esiste utilizzando scalpello e collante.

Mi è stato chiesto da un ragazzo americano di creare il Bundle di Pidgin.
La mia attuale toplist comprende:

GIMP
Calcolatrice
Terminale
Text Editor
Browser Web
Calendario
Thunderbird
Rubrica condivisa
Pidgin
Gnumeric
Abiword
Rhythmbox

E' assolutamente fondamentale avere canvas con un widget crossplatform leggero che possa integrare una libreria di parsing e rendering Web2.0 (XHTML CSS2 ECMAScript/Actionscript).
Con questo canvas ultraspecializzato che può essere eseguito in qualsiasi environment X sarà possibile integrare le applet Dashboard di Apple, Google e Yahoo ed eseguire direttamente materiale Flash (per quelle Apple è necessario un ulteriore layer di adattamento che traduce le chiamate a OSX).
Questa peculiarita è un KillerApp per il Desktop Linux e dovrebbe essere seriamente presa in considerazione.
Qualcosa si muove nella giusta direzione grazie a KHTML ed incredibile a dirsi: Apple stessa.
WebKit è una tecnologia che emerge grazie ai lavori di Apple su KHTML e presto sarà pienamente disponibile anche per GTK.
Epiphany su WebKit è gia in lavorazione e porterà degli ottimi risultati.
Ci si può chiedere sul perchè non supportare Gecko nell'incarnazione XULRunner, la risposta è che ancora non ritengono il caso di sganciarsi definitivamente dai widget XUL based (il quale di per se è un ottimo linguaggio di marcatura per widget tipo GLADE).Ci sono dei timidi binding ma la leggerezza e l'integrazione nativa è ancora utopia per questo progetto megalitico.
Mozilla è ancora un mondo a se stante e cambieranno seriamente registro nel momento che WebKit si sarà pienamente diffuso erodendo quote a Gecko.
Installare Mozilla, oggi, è l'equivalente impegno di installare Java.
E' un ambiente di esecuzione generico con widget specializzati per il rendering web, ma non dista molto dal runtime Java per principi. Infatti possiamo costruire aplicazioni verticali specializzate ed eseguirle con lo XULRunner.
Il principio è ottimo ma l'implementazione è troppo pesante in termini di spazio occupato e latenze di parsing.
Questo è quanto riguarda il classico Firefox, ma qualcosa si sta seriamente muovendo in seno a Mozilla e Minimo è gia una sua risposta concreta.
Lo spinoff di Thunderbird potrebbe essere un primo segno di tentivo di ottimizzazione dei gruppi di lavoro.
Devono dare una risposta concreta altrimenti crolleranno sotto il proprio peso.

23:54

Prima di passare al nuovo giorno...
Con l'utilizzo del notify ho integrato uno screenshot dell'applicazione che si va avviando.
Il feedback è immediato in quanto la rappresentazione non è tradotta con un'icona approssimata, ma diretta con una fotografia del'applicazione stessa.

[The Road To...] Raccolta di appunti sparsi durante l'avanzamento di SpatialBundle

Martedi 14 Agosto 2007

01:30 A.M.
Con le modifiche apportate a Java6 entra prepotentemente in scena il wrapper per la prima diretta esecuzione di AppRun.
Il wrapper in questione si trova in Linux-ix86/bin e nell'ipotesi più semplice richiama direttamente il binario principale.
Nel caso di Java6 in qualità di suite , il wrapper richiama il pannello di controllo e il JavaWS cache manager per fornire un feedback di base all'utilizzatore.

Dopo la prima esecuzione viene copiato AppRun.desktop in $HOME/Desktop/Broken_Link_You_Can_TRASH_It_$PROGRAMMA.desktop
L'effetto di questa copia è quello di avere un'icona colorata nel caso di cache attiva (il .desktop risolve felicemente contro il $prefix) nel caso che la cache sia stata --free allora compare nel desktop il nome del file .desktop che cerca di essere descrittivo della situazione poco felice con le parole: BROKEN_Link_You_Can_TRASH_It_ioJre6u1-feisty.desktop in questo modo l'utilizzatore osservando un file testo ostile ed il suo nome che lo invita ad essere buttato nel cestino, potrebbe eliminarlo direttamente ripulendo il Desktop di una foglia secca (DEPRECATo nel futuro implemento una soluzione più elegante).
Le parole BROKEN e TRASH sono volutamente poste in maiuscolo tale che l'effetto di Information Foraging permetta di intercettare piu velocemente le parole chiavi dell'invito proposto.
Ricordo che ad oggi l'utilizzo di un file .desktop è DEPRECABILE per l'inconsistenza tra l'oggetto reale ed il metadato.L'utilizzatore puo facilmente scambiare l'uno con l'altro.
Il problema verrà meno quando in futuro sarà possibile incorporare le voci .desktop in script eseguibili.

Quando si esegue uno SpatialBundle .jar questo deve poter accettare in ingresso uno SpatialBundle ioJre tale da poterlo aprire e passargli se stesso come argomento da lanciare.
Questa tecnica permette ai livelli superiori di poter effettuare il drop di un Jar su un ioJre e viceversa.
Un Jar che non trova un ioJre deve aprire una finestra di dialogo per fare scegliere all'utilizzatore lo ioJre voluto e consigliare nello stesso momento la capacita di drop dello ioJre sul Jar. Quest'ultimo dopo il drop prende nota della path di sorgente e registra un mime per le future esecuzioni.

03:30 A.M.
Ho aggiunto la capacità di parsing dei programmi Java Web Start potenzialmente passabili dal Web Browser che deve risolvere il mime.
Un file .jnlp viene copiato in cache locale poi eseguito direttamente.

• Lo SpatialBundle si occupa di eliminare il .desktop nel Desktop nel caso di ioProgramma --free

04:35 A.M.
Le modifiche apportate allo SpatialFactory meritano un cambio trunk da 0.7.4 a 0.7.5 cosa che avverrà prima di chiudere la sessione notturna ed avere la nightly build finale verso le 05:00 A.M.
File modificati makeself-header AppRunFooter fAppRun

05:20 A.M.
Brancolo nel buio attivo la modalita debug diretta nel codice per sapere cosa succede.

05:30 A.M.
file ed area di codice di bug ingaggiata

05:45 A.M.
Bug Aperto
Trunk 0.7.5
Sessione Chiusa


Domenica 19 Agosto 2007
Colonna (Casteli Romani) - Rome Italy


01:27 A.M.
Aperta la sessione per risolvere il bug del trunk 0.7.5

01:52 A.M.
Bug risolto ma sarebbe necessario che il CrossBundle riuscisse a distinguere tra una richiesta diretta da terminale ed un passaggio mime.
Il bug è risolto con default sul mime quindi: ..../bin/java -jar $YourPayLoad
La versione da terminale è momentaneamente commentata: ..../bin/java -jar $YouAreHere/$YourPayLoad
viene eseguito il parsing contro .jar e .jnlp per abilitare il mime sui file webstart anche tramite browser.

02:43 A.M.
mentre risolvo alcune questioni sul CrossBundle di Jre6 (clicco sullo SpatialBundle e deve aprire anche un file selector per farmi scegliere un .jar da eseguire) ascolto in cuffia dall'ibook G4 1Ghz 12' le mie ultime 10 traccie di musica elettronica sperimentale create quando ero in montagna i giorni precedenti...
E penso...codifico su questo catorcio di Acer Aspire 3000 (ma con Ubuntu Feisty on board) con un AMD 2800+ ed ascolto musica su un ibook G4 1Ghz e Mac OSX che da le piste a tutti!!! (...quasi tutti ;-)
E penso...che per garantirmi incontaminazioni di -dev varie ho una fresh feisty desktop e non posso ascoltare mp3!!! non posso perche dovrei avere una rete per tirare giù i codec dai repo di ubuntu e se avessi installato la reciproca versione di Freespire ora sarebbe tutto ok gia da CD (ma dovrei imbarcarmi KDE).
E penso...che una potenziale prossima compera potrebbe essere uno spettacolare Powerbook G4 12' di quelli superPower (ma perche non hanno mai fatto un G5 Powerbook... ho ancora la geekBava).
E penso... che con un PowerbookG4 partizionerei definitivamente per condividere con OSX Ubuntu e compilare rilassato senza temere di dovermi addormentare prima di vedere terminata una compilazione di GIMP tramite Pkgsrc di NetBSD...eh gia...dovete sapere che ha un overhead notevole per garantire la massima qualità di codice in crosscompiling e crossplatform...dare ed avere ;)
Piu andiamo avanti e piu questa ridicola saga dei Macbook Intel based andrà avanti ed i Powerbook costeranno sempre meno sempre meno sempre meno..fino a non trovarne piu :) ...ed intanto gli IBM G5 fanno sognare sempre più... vabbe torno sul codice...e ci ripenso.
Mi interessa arrivare alla Ubuntu 2008.4 che sembra essere una LTS con una macchina con supporto grafico 3D completo perche a quel punto Compiz & Co sarà una realta consolidata della quale non si puo far piu finta di nulla.

05.28 A.M.
Uno SpatialBundle che contiene uno Jar esegue uno spatialbundle Jre passando se stesso come parametro a runtime.
Quindi:
$ioMioJar ioJre
esegue
$ioJre /tmp/Programs/ioMioJar/Linux-ix86/bin/MioJar.jar

06:42 A.M.
Sessione terminata, svengo dal sonno.
Sviluppo un template per un wrapper al binario principale.
Se clicco ad un Jre mi chiede un Jar se clicco ad un Jar mi chiede un Jre.

15:27 P.M.
Dormito,svegliato,bevi acqua,lava denti,doccia,piatto di muesly con yogurt all'Aloe.
Modalita MacinaCodice ON
No Stop Coding.

19:18 P.M.
SpatialFactory 0.7.6 out.
Respatializing ioBash3.2 con SpatialFactory 0.7.6

20:08 P.M.
Bundling SpatialFactory 0.7.6 per fornire agli sviluppatori un tool spacialized.

Domenica 26 Agosto 2007
Colonna (Casteli Romani) - Rome Italy

12:51 P.M
Dopo due giorni in modalità "macinacodice" full immersion sono arrivato alla versione 0.8.4

Il mio attuale versioning funziona cosi:
X.Y.Z
dove X per ora è 0
Y ha un range da 0 a 9
Z ha un range da 0 a 9

Z viene incrementato di una unità ogni qualvolta viene introdotto almeno una modifica strutturale dove le funzionalita (retrocompatibili) vengono modificate, eliminate, sostituite, aggiunte.

Se vengono solo risolti bug questi vengono testati con versioni del tipo:
X.Y.Z.bugN
Ma al rilascio di buN viene anche rilasciato un Z+1 in questo modo la versione successiva eredita la risoluzione dei bug e qualche funzionalità in più cosi il rilascio non risulta sterile alla sola risoluzione del bug (che saranno sempre presenti per tutto l'arco della vita di tutto software del mondo).

Ad oggi le funzionalità di Infodomestic Objects Spatial Bundles producono i seguenti effetti interattivi:
L'utilizzatore clicca sullo SpatialBundle questo si carica in memoria ram/disco, attiva un'icona nel system tray ed avvia un programma wrapper che esegue i comandi specificati dal packager.
Cliccando sull'icona rappresentativa nel system tray si apre un menu contestuale con le seguenti voci:

About (informazioni testuali sul contenuto pagante dello SpatialBundle)
Clear (libera dalla memoria lo SpatialBundle)
Send to... (invia a: Cartella, Mail, Bluetooth, ....)
Properties (Statistiche dinamiche)

18:14
SuperMegaBug risolto.

Considerando che il CrossBundle è disponibile anche per gli altri utenti del computer sarebbe opportuno rendere disponibili in una locazione di comodo anche gli SpatialBundle singoli.
Ogni SpatialBundle dopo essersi aperto in un CrossBundle condiviso copia se stesso nella locazione condivisa.
La copia avviene solo se si apre in questo modo si previene una scrittura in uno spazio dove già presente ma appartenente ad altro utente.Non è necessario, cosi, un controllo di presenza per questa specifica azione.
La chiusura del CrossBundle deve eliminare anche la presenza dello SpatialBundle condiviso.
Al riavvio del computer tutti i CrossBundle e SpatialBundle condivisi vengno eliminati.
L'osservazione degli oggetti puo avvenire tramite il menu Action di qualsiasi Bundle nel system tray tramite il menu Send to... dove è possibile spostare lo SpatialBundle originale in una qualsiasi cartella (o spedire per posta o bluetooth o latro via plugin TODO).
Il menu Send to... potrebbe prevedere la possibilità di osservare il contenitore di tutti gli SpatialBundles condivisi nel sistema dagli utilizzatori attivi.
Esempio:
Send to...
• Desktop
• Another Destination...
• Mail
• Bluetooth
• SMS
∘ Infrared irDa
• Open All Shared Items...

Nel caso di tentata sovrascrittura nel Desktop o nella destinazione scelta l'azione ritorna un messaggio di avvertimento senza sovrascrivere.

Modificato il menu Action le funzioni di:
About
Play
Controls
Remove
Send to...
Properties

20:20
Ogni SpatialBundle ora viene condiviso in: /tmp/InfodomesticObjects/SpatialBundles/SharedItems/
cio comporta dei benefici per tutti gli utilizzatori concorrenti dello stesso computer.
Ogni utilizzatore è in grado anche di cancellare accidentalmente la propria copia e quindi copiare di nuovo dal menu Action lo SpatialBundle originale in una nuova locazione.

Sabato 1 Settembre 2007
Colonna (Casteli Romani) - Rome Italy

15:00
SpatialBundles con SpatialFactory 0.8.6

Sessione SpatialFactory 0.8.6 aperta

Modificato il menu Action le funzioni di:
About
Open
Send
Controls
Remove

Remove è un'azione drastica che richiede maggiore riflessione e minore impulsività quindi viene posto alla fine dell'elenco.

About al primo posto per sopperire anche ad eventuale click isterico.

23:00

Lavoro ancora assiduamente su una funzionalità che permette ad uno SpatialBundle di trovare una risorsa in un intorno stretto del luogo dove si trova posizionato lo SpatialBundle stesso.

Definizione: Considero un intorno stretto del nodo campione, il grafo costituito dai nodi connessi con una distanza massima di 3 dal nodo campione.

Questo metodo dovrebbe permettere a SpatialBundle di trovare velocemente alcune dipendenze nel caso non le avesse con se.

Ad esempio ioJGnash necessità dell'adattatore ioJre per funzionare.Potrebbe incorporarlo con se aumentanto di peso, ma anche cercarlo localmente.Considerando che ioJre pesa 99Mb, risulta essere un connettore non facilmente trasportabile per SpatialBundle di dimensioni 1/10 (è un nonsense dove ci sono lacune di banda come l'Italia ora, pero fuziona ottimamente per software distribuito tramite supporto ottico).

Domenica 09 Settembre 2007

Implementazione della modalità di avvio --silent
Questa modalita deve permettere di caricare in memoria l'applicazione senza avviare interfaccie grafiche.

La modalità si attiva con un'opzione passata allo SpatialBundle
ie: ioPippo --silent

Questa modalità esegue le seguenti operazioni:
Carica la memoria.
Attiva la sua rappresentazione nel Tray.
E' necessario prevedere una funzione del tipo:
--silent-nodock
che evita anche l'esplicitazione nel Dock.
Potrebbero beneficiare di questa funzione i Framework di supporto ad esempio Kdelibs, QT
Ad esempio ioAmarok attiva ioQt e ioKdelibs i quali attivano la loro rappresentazione nel Dock.Tramite la seguente definizione è possibile limitare la rappresentazione al solo ioAmarok:

ioQt --silent-nodock
wait
ioKdelibs --silent-nodock
wait
ioAmarok

E' una modalità deprecabile normalmente in quanto fuori dal controllo visuale dell'utilizzatore il quale deve sempre avere un ritorno di esperienza dall'attività del Computer.

Nella lavorazione di SpatialBundle 0.8.8 integro la funzione fSay come primitiva del futuro ioSpeak.
Questa funzione sostituisce il normale output di dialogo con un dialogo dedicato per l'ambiente in uso.
E' in grado di emettere informazioni utilizzando i widget dell'ambiente principale di run e si adatta in funzione della disponibilità fino a ridurre l'output ad un semplice echo.
Sono stati presi in considerazione i seguenti widget sets:
Zenity
GDialog
KDialog
XDialog
Dialog
bash echo
Quest'ultimo non deve funzionare necessariamente da una sessione di console ma anche da una sessione X dove non sono presenti i precedenti dialogs widget.Nel caso apre una finestra xterm (o altri disponibili) ed emette l'informazione.
L'ultimo stadio è l'implementazione parallela di un sintetizzatore vocale che lavora in parallelo.

ioCalendar Sunbird ready for the masses

Pubblicato ioCalendar Sunbird versione 0.5 con SpatialBundles 0.8.6

SpatialBundle vs OSX Bundle

Dedicato ai miei 200 Twitter Followers

grazie di cuore ;)

La Apple promuove presso la comunita degli sviluppatori OSX un documento di 66 pagine per descrivere le varie modalita di packaging and delivering del software.
Essa considera 5 distinte aree di applicazione per tipologie di packaging:

Type Destination
Application /Applications
Framework /Library/Frameworks
Font /Library/Fonts
Documentation /Library/Documentation
Command-line tool /usr/local/bin














Un esempio pratico:

Component	Component type	Installation destination
Levon.app	Application	/Applications
Levon_User_Guide.pdf	Documentation	/Library/Documentation
SharedServices.framework	Framework	/Library/Frameworks

E' facilmente intuibile che dal punto di vista posizionale, l'applicazione Levon subisce ancora un effetto UNIX filesystem.
Lo UNIX filesystem per l'utilizzatore casalingo tipicamente monoutente è fortemente DEPRECATO per i sistemi Infodomestic Objects.

La tecnologia degli SpatialBundles di Infodomestic Objects di nuovo riducono enormemente la complessita topologica ed organizzativa anche nei confronti degli sviluppatori che devono concentrarsi sul loro prodotto piuttosto che assecondare l'architettura, la quale, dovrebbe essere sempre un servizio che faciliti il lavoro e non qualche cosa che lo rende piu complesso.

Di nuovo il processo di delivering finale di un Bundle OSX utilizza i seguenti blocchi:

Product -> Container -> Transport -> Computer

Il blocco Product è un Bundle directory quindi deve necessariamente essere inserito in un contenitore che lo riduce ad un file per poter essere agevolmente manipolato.
Il Container OSX è tipicamente un archiviatore o un file immagine (.zip || .dmg).
Nel primo caso l'utilizzatore deve attivamente estrarre il contenuto dall'archivio .zip e poi operare manipolazioni sul suo contenuto (esempio duplicarlo, attivarlo con un click, rinominarlo, etc).
Nel secondo caso (immagine DMG) il Container è un vero e proprio filesystem chiuso e rappresentato da un file.Nel momento che l'utilizzatore clicca sul file .dmg le funzioni di systema gia presenti in un computer con OSX automaticamente si preoccupano di aprire il contenitore e rendere subito disponibile alla manipolazione il contenuto.

Uno SpatialBundle Infodomestic Objects risolve drasticamente la maggior parte delle operazioni che l'utilizzatore finale deve eseguire per prendere possesso delle funzionalita del programma.
Uno SpatialBundle è Product e Container nello stesso momento quindi la complessità di retrieving e manipolazione per l'utilizzatore finale si riduce a:

SpatialBundle -> Transport -> Computer/Run

Le azioni di un utilizzatore Infodomestic Objects nel tramite di uno SpatialBundle si possono ridurre a pochi passi:

La persona trova lo SpatialBundle in internet, clicca nella pagina web, il programma automaticamente si scarica nel Desktop e si esegue.
Altro caso, la persona compra una raccolta software su supporto ottico (CDROM o DVD), trascina l'icona del programma nel desktop e poi clicca sopra ed il programma parte.

Il vantaggio principale di utilizzare un filesystem di tipo .dmg contro un .iso sta principalmente nel fatto che è possibile parcheggiare file e mantenere intatti gli attributi del file stesso con particolare riguardo all'attributo di esecuzione che in un filesystem .iso non è possibile.
Lo svantaggio è che bisogna sempre far riferimento a tecnologie di parsing OS centriche e quindi delegare alla bonta del proxy in questione l'eventualita di potersi eseguire.

Nel caso di Linux sarebbe possibile usare un semplicissimo filesystem ext2 e simulare con un proxy installato sul sistema gli stessi effetti della manipolazione di un .dmg.
In questo caso verrebbe sempre meno uno dei concetti di Infodomestic Objects ovvero decentralizzazione del potere esecutivo per passarlo in mano all'utilizzatore che usa il suo spazio protetto di memoria.
Un secondo problema che riguarda sempre la centralizzazione è relativo al comando di mount necessario per eseguire il mounting dell'immagine il quale richiede un accesso di amministratore (assolutamente DEPRECABILE).
Con una classica installazione Desktop di Ubuntu non è possibile costruire workaround efficienti per simulare l'autofissaggio (mounting) di un immagine (equivalente di DMG in OSX) cosi come avviene intimamente nel Finder di OSX.

L'unica clasuola chiesta all'utilizzatore di Infodomestic Objects è quella di abilitare la capacita di esecuzione del file, che avviene solo la prima volta per quel programma.
Questa clausola aumenta la sicurezza in quanto nel caso di malware/virus/worms allarma attivamente l'utilizzatore che sta per eseguire un programma e non, quindi, osservare un oggetto dati tipo immagine, musica, documento...

E' previsto l'inserimento di tecnologia di intelligenza artificiale per permettere un uso piu autonomo e consapevole del software permettendo che l'utilizzatore possa anche sbagliare, come sua umana natura e diritto.

Packaging Gaim into ioGaim2.0 for feisty IOL2007

apt-get source OK
configure && make && make install OK
preparing Bundle package..
checking Icons...

[The Road To...] Domenica 24 Giugno 2007 04:35

E' preoccupante l'utilizzo del gateway /Programs che richiede necessariamente un accesso root per la manipolazione.
Un sistema Infodomestic Objects 100% da installazione CD Live puo contenere nativamente un gateway /Programs -> /tmp/Programs ma meglio ancora /Programs potrebbe risolvere le necessita di installazione rigida dove l'utilizzatore condiviso lo richieda.
In /Programs si possono memorizzare direttamente gli SpatialBundles che continueranno a funzionare con il metodo classico di disk caching.
Nei sistemi compatibili con Ubuntu si continuera ad usare il meccanismo diretto dello SpatialBundle manipolato dall'utilizzatore nella sua HOME o nello spazio dove esso puo leggere e scrivere (esempio puo prelevare i programmi da un cdrom).
Nel caso di utilizzo centralizzato utilizzando apt-get si usa quindi /Programs come land runway dove posizionare gli SpatialBundles che verranno poi utilizzati ed eseguiti centralmente dagli utenti.
Un installazione centralizzata permette di poter far riferimento ad un catalogo persistente non modificabile di software gestito dall'amministratore del sistema, ma lasciando la capacita di poter effettuare una copia e poter usare il software liberamente svincolandosi dall'amministratore anche quando esso ha eliminato il componente dal computer.
Il servizio mkdirPrograms si preoccupa di generare /tmp/Programs e /dev/shm/Programs
Gli SpatialBundle si devono preoccupare della generazione dinamica dei link simbolici a seconda se viene attivata la modalita bitJet /tmp/Programs/ioProgramma -> /dev/shm/Programs/ioProgramma
TUTTE le compilazioni avvengono contro /tmp/Programs/

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

Office vs Home

Fino ad oggi il paradigma usato nei Desktop è legato al primo studio dell'interfaccia Star poi clonata e modificata dalla Apple per il Mac e la Microsoft per Windows.
Il paradigma di Star era legato a fornire un ambiente di ufficio composto di Files, contenitori, fogli di calcolo, scrivanie, etc. etc.

Questo paradigma non è assolutamente più sostenibile per la nuova realtà degli anni di oggi (2007).
Oggi abbiamo un sistema interattivo multimediale documentale come Internet, abbiamo dispositivi mobili miniaturizzati tascabili come palmari e cellulari.Abbiamo un utilizzo continuo di elettrodomestici casalinghi che ci chiedono di comunicare tra loro.

Non possiamo sostenere più un interfaccia basata su un paradigma "Ufficio condiviso" per utilizzi personali tascabili/mobili/casalinghi.

Bisogna coscientemente razionalizzare l'interfaccia per utilizzo casalingo/multimediale e palmare mobile (palmare, palmtop, telefoni mobili, sub notebook < 10 pollici).

In casa non esiste il concetto di file e documento, ma principalmente il concetto di elettrodomestico, quindi un oggetto fisico che applica i suoi metodi/funzionalità sui dati.
Esempio la TV per guardare animazioni, lo stereo per ascoltare la musica, l'album per guardare le fotografie, il televideo per leggere alcune informazioni addizionali alla TV, il lettore DVD per guardare film noleggiati, la console di gioco per giocare con appositi giochi...
La cassetta postale per ricevere la posta.
Per spedire la posta ci si affida a cassette centrali dove comunque si trattano lettere che sono fogli multipli impacchettati in buste (headers).
La musica ed i film sono catalogati in contenitori di plastica DVD e posta in libreria.
Possiamo far fluire i bit contenuti nei DVD da una casa all'altra semplicemente portandoli fisicamente con noi.
La manipolazione spaziale per differenziare gli oggetti quotidiani è fondamentale per l'esperienza di interazione.

Alcune osservazione da OpenBSD

OpenBSD
è famoso per il seguente slogan:
" Only two remote holes in the default install, in more than 10 years!"

per questo motivo intendo valutare la possibilità di poter prelevare codice testato dai loro repository per integrarlo in Infodomestic Objects Linux.

A tal proposito leggendo tra le righe del manuale sezione 5 - Building the System from Source

ho potuto leggere che il sistema non accetta costruzioni miste e che deve essere considerato un unico sistema operativo integro che va in una sola direzione temporale...quella che conosciamo anche noi...

"E' importante capire che OpenBSD deve intendersi come un sistema operativo complessivo da considerarsi completamente sincronizzato con il repository"

Esiste solo una direzione temportale per gli upgrade che vanno dal vecchio al nuovo e dallo "stable" al "current".

Insomma a differenza di Debian/Ubuntu flavours che con la loro grande flessibilita permettono i backports, OpenBSD rinuncia completamente a questa feature in favore di una semplificazione di processo che permette alla comunita di sviluppo e mantenimento di garantire gli altissimi (praticamente assoluti in termini di primato) standard di qualita e sicurezza del software proposto.

Per questa ragione i lavori di OpenBSD saranno sempre sotto il mio riflettore.

[The Road To...]

Introduco il concetto di Dinamyc Framework per assecondare una realtà strettamente necessaria:
Se un'applicazione per funzionare ha bisogno di un framework di librerie (esempio le QT libs) queste devono essere portate dietro dall'applicazione stessa e messe a disposizione nella cache disco.
In funzione della grandezza del framework si puo introdurre nella Turbo Cache utilizzando la tecnologia bitJet oppure nella cache disco.
Nel caso specifico di QT, l'installazione occupa piu di 250 MB e quindi non si puo inserire nella Turbo cache (max 250MB).
Nei casi specifici dove è richiesto un Framework addizionale per ora la soluzione è di eseguire l'embedding nel Bundle dell'applicazione, quindi Bundle in a Bundle che viene aperto ed eseguito e posizionato in:
/tmp/Frameworks
con la stessa tecnica viene messo a disposizione degli altri utenti fino al riavvio.
Frameworks meno impegnativi possono essere spostati nella Turbo cache.

E' conveniente quindi compilare direttamente contro la cache disco e poi usare link simbolici dalla cache disco alla turbo cache per risolvere gli spostamenti dinamici.

Essendo la cache disco una risorsa grandissima, diventa il centro nevralgico prima delle valutazioni di efficienza.

Software collaborativo

I programmi potrebbero tornare a preoccuparsi della gestione della RAM (in parte) come si faceva una volta.
Potrebbero comunicare tra loro scambiandosi informazioni critiche di occupazione risorse e statistiche e autogestirsi.
Un protocollo comune peer to peer (stile piping) per interrogarsi reciprocamente.
Ad esempio se un programma occupa il 70% della RAM ed è in idle da 30 minuti e nel frattempo un altro ha bisogno del 50% di RAM si potrebbe spostare il primo in cache disco chiedendogli l'autorizzazione a trasferirsi.

The Secret to Understanding Design

We often discuss design. Should it be simple or complex? Should it be colorful or grayish? Do you make it low-tech or media rich? The answer can be found by looking at how design breathe.

Everything is breathing. You breathe in and you breathe out - either being full of air or having none at all. It is a continuous motion between two extremes. Take simple vs. complex. We constantly move between wanting things to be ever simpler - or ever more complex.

The secret to Complex vs. Simple design explained

Why do you think Apple's iPhone has a much more complex design (especially in the interface) than the iPod? Why didn't they keep it simple? It's because we have had it with "simple" - now we want more. We are now moving in the other direction, towards a more complex and rich environment. In 12-18 months we will again get fed up with the complexity and turn towards another period of simplicity - and so the motion continues in an eternal cycle.

Notice: Every curve is different and has different durations between its peaks. "Simple vs. Complex" roughly follows the example above. Other curves - e.g. colorful vs. low on color - have a slightly different look. The trends will also be different in other parts of the world and in each profession (the trends on the web design does not necessarily follow the trends in e.g. car design).

The trick is to know how to use this to your advantage.

Not everyone is a trendsetter

The first part is to realize that not everyone is at the same place. Trendsetters are in general far ahead - closely followed by the early adopters. These people are the driving force. They are the ones that drag everyone into the future.

The majority, however, is about a year behind the trend and the laggards haven't change yet. They only move ahead because old products are being replaced and decommissioned.

Note: The visionary are often very far ahead of everyone else - and thus often creates amazing stuff that never sells because the market it not ready for it.

Where to be?

The second part is to know how far ahead you need to be.

You need to aim for the "Cool Zones" - Where your products are close to the extremes. If people are moving from simple to complex (as we are now), you need something very complex to stun the crowd. This is what Microsoft did when they unveiled their Surface technology a few days ago.

Similarly, when we get fed up with the complexity and want simplicity, you need to make it very simple to make an impact. This is what 37Signals did a few years ago with their project management tool "Basecamp". People was getting fed up with the complexity of Microsoft Project and wanted something simple. Basecamp delivered just that.

Note: If 37Signals had released Basecamp today it would be much less successful since we are now moving away from simplicity.

Never aim for the middle. That is where the mediocrity is. Making products that are neither simple nor complex are just boring and useless. They have no sense of emotions; there is no energy.

And, never aim for the "dark side" of the curve (the red zones). Making a slightly less simple version is a very bad idea if people want more complexity.

When not to publish your product

The last trick is to know when to publish your product - and when not to.

The best moment is when we are starting to move from one extreme to the next (the green zones). This is the time when people realize that they want something else. They are susceptible to change - to something new. Act on it!

You will start to fall behind as we get closer to the extremes (the yellow zones). The cool companies have already marketed their products and the trendsetters are beginning to look in different directions. You can still make an impact if you make a really cool product - but you will not be seems as one of the innovative types.

And, you need to lay low when we reach the extremes. This is the point in time where people get fed up with it (the red zones). Wait until the early adopters have realized that they want something else - that they need to go in the other direction. It doesn't matter that the majority hasn't changed yet. It is the trendsetters and early adopters you want to reach.

The last thing to do is to identify what design aspects that is relevant to you - and what direction we are moving in. Here are some examples:

• Simple vs. Complex
• Colorful vs. low on color
• Visible vs. hidden technology
• Ordinary text/images vs. Rich Media presentations
• Efficiency vs. Exploration
• Manual vs. Automatic
• Big vs. small
• Rounded vs. edgy
• One-page vs. many pages
• No effects vs. fanciness
• Social vs. isolated
• Work vs. fun
• Long vs. short
• Sporty vs. comfortable
• Strong vs. fragile
• Masculine vs. feminine
• Independent vs. company
• Etc.

And always remember that the world never goes back to what it was. The kind of design we had in the past is not the one we will see in the future. Simple designs of the 80's looks hideous compared to the simple look of the iPod. Complex TV sets in the past looks old compared to Microsoft Surface.

Innovation3D 0.66.1 (Default)

I3D is a 3D modeling program for Linux. While it is primarily a mesh modeling tool, it has preliminary support of NURBS. Release focus: Minor bugfixes Author: Jon Anderson <janders |at| users |dot| sourceforge |dot| net> [contact developer] Homepage: http://innovation3d.sourceforge.net/ Tar/GZ: http://sourceforge.net/project/showfiles.php?group_id=640 Changelog: http://sourceforge.net/[..]notes.php?group_id=640&release_id=335822 CVS tree (cvsweb): http://sourceforge.net/cvs/?group_id=640 Mailing list archive: http://sourceforge.net/mail/?group_id=640

Virtual Universe 0.54 (Universe Server)

Added: Sun, Mar 16th 2003 23:04 PDT (4 years, 2 months ago)

Updated: Tue, Jun 5th 2007 15:07 PDT (6 days ago)

About:
The "Virtual Universe" is a realistic, three-dimensional cyberspace. People can meet, interact with each other, and build houses and whole worlds. Due to its extensive programming interface, this virtual reality environment can be used for more than just entertainment: simulation and visualization tasks for e.g. industry or science can be done too.

Release focus: Minor bugfixes

Changes:
A bug in the authentication and password retrieval function was fixed that could cause the registered email address to be reset.

Author:
Oxygenic [contact developer]

Homepage:
http://www.3dchat.org/servers.php#universe
Demo site:
http://www.3dchat.org/[..]e=http://www.3dchat.org/webstart/vu.jnlp

Gujin 2.0 (Default branch)

from freshmeat.net announcements (Global)

Gujin is a PC boot loader which can analyze your filesystems. It finds the Linux kernel images available, as well as other bootable partitions (for *BSD, MS-DOS, Windows, etc.), and displays a graphical menu for selecting which system to boot. Because it understands the structure of Linux kernel images, Gujin does not need LILO and can even load ELF kernels. There is no need to execute anything after making a new kernel: just copy the kernel image file into the "/boot" directory. Gujin is written almost entirely in C with GCC, and it fully executes in real mode to be as compatible as possible.

---

License: GNU General Public License (GPL)

---

Changes:
Correct behaviour following the latest Linux evolutions, bugfixes for tiny.exe related to BIOS data gathering for *.kgz kernels, disk size adjustment for SATA/SCSI/USB hard disks is done like ATA disks, and an initial attempt to automatically relocate the kernel when "ld" has the "--emit-reloc" flag and the kernel is moved by the "loadadr=" parameter.

Plash 1.18 (Default branch)

from freshmeat.net announcements (Global)

Plash is a sandbox for running GNU/Linux programs with minimum privileges. It is suitable for running both command line and GUI programs. It can dynamically grant Gtk-based GUI applications access rights to individual files that you want to open or edit. This happens transparently through the Open/Save file chooser dialog box, by replacing GtkFileChooserDialog. Plash virtualizes the file namespace and provides per-process/per-sandbox namespaces. It can grant processes read-only or read-write access to specific files and directories, mapped at any point in the filesystem namespace. It does not require modifications to the Linux kernel.

---

License: GNU Lesser General Public License (LGPL)

---

Changes:
A security vulnerability relating to granting access to terminal was fixed. A package system for running programs from Debian packages in sandboxes was added.

aTunes 1.6.3 (Default branch)

from freshmeat.net announcements (Global)

aTunes is a full-featured audio player and organizer, with some ripping and encoding tools included. It supports MP3, Ogg, WMA, WAV, FLAC, and MP4.

---

License: GNU General Public License (GPL)

---

Changes:
A "Copy To Clipboard" button was added for lyrics. FLAC support was added. Automatic scrolling of the play list was redesigned. The file properties window was redesigned. A tooltip for play list songs was added. A mute button bug was fixed.

Parsix 0.90 Test 3

from Phoronix

The third test release of Parsix GNU/Linux 0.90 is now available. New in this LiveCD is GNOME 2.18.2, Sun Java replaced by GCJ, added the Parsix Book to the LiveCD, several bug fixes, glibc 2.5, and many other improvements. If you've never tried out Parsix, it's based on a combination of KANOTIX and Debian that is a well polished distribution worth trying out for desktop users.

Filemerger 1.01 (Default branch)

from freshmeat.net announcements (Global)

Filemerger will merge two individual text files in to one big file. If a line in the second input file is identical to a line in the first input file, then that line is included only once in the output file.

---

License: Freeware

---

Changes:
Changes were made to the help file.

Murrine: Aperto il sito del Progetto.

from Cimi's Official Blog by Cimi

Ho deciso di aprire un nuovo sito dove raccogliere i migliori contenuti per Murrine (i miei più qualcuno non ufficiale che inserirò più avanti quando avrò più tempo a disposizione) in occasione dell’avvento della futura versione stabile 1.0.

Novità

Snapshot del changelog…

0.98
===
* Added toolbarstyle with three styles: toolbarstyle= 0 flat, toolbarstyle = 1 glassy, toolbarstyle = 2 gradient
* Added sliderstyle = 1 (from email [Murrine Improvement] “sliders style options” by Andrea Antolini) to add handles on sliders
* Implemented tooltip’s drawing
* Automatically colorize scrollbar with bg[SELECTED], a new option “colorize_scrollbar = TRUE | FALSE” is used to colorize it or no
* Fixed bug with symbolic colors
* Fixed bug #438456 of gnome bugzilla
* Using const color’s variable instead adding a cast

Segnalazioni

Se avete qualche bugreport o qualche richiesta di feature aggiungetela nell’apposita sezione di bugreport sotto “The Engine”, ovviamente in inglese.
@johnny (che sarebbe quel grande che sta facendo il nuovo configuratore):
Se ce la fai ad organizzare meglio la pagina del tuo progetto sarebbe fantastico. Quando impacchetti il sorgente ti suggerisco di chiamare la cartella murrine-configurator-1.x, e rinominare l’archivio murrine-configurator-1.x.tar.bz2. Così sono gli standard… altrimenti si creano confusioni nella pacchettizzazione dei sorgenti in qualunque distribuzione.

Commento completo al post di pollycoke su home is my desktop

Si parla di home is my desktop
Mi ha troncato il commento e quindi lo proseguo qui per completezza
Post originale su Pollycoke

COMMENTO:
Mi rendo conto che /$HOME è hardcore, veramente esagerato.Bisognerebbe svolgere valutazioni in funzione del reale utilizzo della macchina.
In fondo esiste una netta separazione di utilizzo tra un PC casalingo monoutente (mono >= 1 AND 3 < mono < 1) ed un server multiutente.
Un PC casalingo normalmente potrebbe avere uno due utenti...(3...tiè facciamo 5 nonna compresa) insomma enumerazioni umane che non sfuggono dal controllo della nostra memoria a corto termine...ovvero complessita bassa.
E' meglio evitare di trovare l'unica soluzione che va bene per tutto...non è piu questo il giusto luogo di sviluppo della discussione.
Penso che nel caso pseudo monoutente (un tipico caso è l'iBook di turno della ragazza, la mia, che ci cataloga foto e musica ed un nminimo smanettamento tra files ed internet), ecco in questo caso il sistema dovrebbe offrire una vista piu Unixless possibile.
Il filesystem Unix FHS che conosciamo è un'architettura classica Database distribuita, insomma un tecnicismo bellissimo che ci fa godere...ma va bene per ambiti tecnici /etc?? /proc?? ma che vuol dire?? (si chiede la mia ragazza)...già chiamarli /Binary /Processes /Devices avrebbe ridotto l'attrito cognitivo...
Se root fosse /Root (dark zone dedicata a noi) gia avrebbe risolto un sacco di tutte queste chiacchiere che andiamo facendo!!!
Se non fosse per un desktop launcher (virtual proxy) o un desktop nel Menu Applicazioni (virtual proxy anch'esso) la Manuela e Lavinia se ne guarderebbero di andare in /usr/bin a cercarsi nientepopodimeno che "gimp"!!!Anzi a dirla tutta...non sanno manco che cosa vuol dire /usr/bin
Cosa è Unix per quegli utenti?? Uno stato assistenzialista (proxy launchers provided by distro vendors) che se fallisce li lascia per strada? (inconsistenza classica di quando non funziona qualche cosa sotto Linux e devo intervenire io che ci capisco!!!).
Insomma il problema dell'FHS esiste ed è grave e non c'è Gnome VFS che regge.
Usare due dischi Root + Home?? E' un ottima idea, ma la root è sempre li in agguato (la possiamo nascondere alla vista totale??).
======
======
Aggiungo di seguito il mio primo commento per completezza
PRIMO COMMENTO
Per 2 anni di seguito ho svolto test desktop==home su 2 utenti novizi (3 con me) ai tempi dove Ubuntu non esisteva manco nella mente del suo grande ispiratore.
E’ ,per me, sotto sempre il concetto piu logico derivato da alcune considerazioni topologiche:
1) Nell’utilizzo quotidiano degli oggetti, l’uomo comincia a perdere orientamento se super i 3 livelli di nesting.Guardatevi intorno e vedrete che è raro superare 3 cose infilate una dentro l’altra (oggetti in scatole in cassetti ad esempio).Questa è la nostra natura…al 4 livello di nesting sbrocchiamo!!!
2) Il monitor è il computer (parafrasando Sun e la sua “Il computer è la rete”). Sembrera assurdo, ma un normale utilizzatore associa a cio che vede nel monitor…il proprio computer in temini di dati etc etc (windows è una continua violenza a questo concetto…forse Vista è andato oltre), da cio emerge che gli oggetti creati nel Desktop sono gli oggetti del nostro mondo digitale (spatial desktop esiste proprio per assecondare questo concetto). Ovvero, di nuovo, il Desktop/ è la nostra root.
Nella situazione attuale dove la deficienza (nel senso di deficere) del Gnome VFS non permette una completa virtualizzazione del FS su TUTTE le applicazioni possibili (e quando mai potrebbe se queste ultime non si adeguano utilizzando almeno il file selector GTK?? e perche mai dovrebbero applicazioni QT/FLTK/TCL/TK etc etc aderire univocamente?) ci ritroviamo una continua inconsistenza della vista del FS all’utilizzatore finale tale che: desktop==home è pericoloso (anche se necessario) perche mischia tutte le directory puntate (esposte in un’inifinita di file selectors di altrettante librerie grafiche).
Insomma la mia visione è qualcosa del genere: tutte le configurazioni devono essere esposte in una cartella del tipo $HOME/Configurations (o qualcosa di simile) tale che $HOME è una zona pulita == Desktop, root dell’utente che puo sviluppare la sua entropia.
Tornando al punto 1 desktop==home è necessario perche al livello $HOME siamo gia al 3 nesting (che viene esposto alla vista dell’utente mentre tenta di navigare tra i files): /, /home, /home/$HOME
Nonostante lo Unixware che è in me (da non confondere con SCO UnixWare) andrei addirittura oltre.
porterei le $HOME direttamente sotto root (/luca, /marco, /barbara)…sto bestemmiando? Meditate gente…meditate…
Un mio esperimento veramente estremo ha dato ottimi risultati:
Un PC monoutente aziendale in mano ad una ragazza, Manuela con configurazione root is my desktop (e le adeguate policy di scrittura e hiding dei file) ha prodotto questo: 1 anno di utilizzo ininterrotto giornaliero senza mai corrompere un solo file in root che veniva nascosto alla vista utilizzando il .hidden
Zero livelli di nesting…utente==monitor==Desktop=Root FS==Computer
Dal punto di vista dell’usabilita quotidiana è stato il massimo, ma dal punto di vista dell’amministrazione aggiornamenti etc etc…un incubo.
;)

[The Road To...] Rebuild World?

La tentazione di ricostruire il mondo è immensamente grande.Non mi tornano mai i conti nel bilancio ricavato dal rapporto Benefici/Entropia.
Insomma queste distribuzioni Linux ed in particolare Ubuntu...sono ecologicamente insostenibili.
Apt è una spada di damocle per la materia duale che va dal layer GNU (escluso) in su.
Ai tempi del C64 riuscivo a programmare grafica usabile (con il joystick) che risultava pulita efficace e fluida.
Oggi con un banalissimo AMD 2800+ e 512MB di RAM devo subire lacune di rendering quando trascino le finestre di Nautilus da una parte all'altra dello schermo (cosa che non succede manco al piu cesso di Mac...ok ho esagerato!!!).
Il mondo dello sviluppo OpenSource è tutt'altro che ecologico e decisamente entropico.
Mi piacerebbe lavorare con un sistema composto da:
Layer GNU di base gestito da un sistema a prova di bomba come Apt.
Layer grafico X/framebuffer gestito da un sistema in stile port di BSD (ricompilazione/ottimizzazione/installazione) posto in un bundle separato.
Layer userland gestito direttamentre dall'utente con programmi non installanti in stile Bundles di OSX/*STEP/ROX/RISC OS.
Il lato GNU + Kernel deve contenere nativamente in modo completamente trasparente un sistema tipo OpenSSI

Non è da escludere riconsiderare per il layer GNU l'utilizzo di builder del calibro di NetBSD (54 piattaforme supportate) o T2


SYSTEM CRASH SAFE
Cerco di immaginare un gruppo di software collaborativo che faccia di tutto per mantenere integro il sistema.
Se il sistema si interrompe l'utilizzatore anche in emergenza deve essere in grado di riprendere il proprio lavoro portarlo a compimento e poi eventualmente recuperare il sistema principale corrotto.
Esempio:
Dopo aver fornito una distribuzione stabile, l'utilizzatore scarica nella memoria ulteriori programmi (Abiword e Gnumeric).
Durante l'uso di Gnumeric il sistema si blocca non permettendo piu il lavoro, a quel punto l'utilizzatore riavvia e direttamente da GRUB selezione una sessione specializzata di nome Gnumeric che si limita ad avviare un kernel separato con un X separato minimale e Gnumeric al top esclusivamente per permettere di lavorare direttamente e concludere il proprio lavoro.

[The Road To...] Windows Manager Changes

Reintroduco il tasto "Chiudi" posizionandolo nell'angolo a sinistra. Elimino il tasto Massimizza e lascio Minimizza nell'angolo a destra.
RATIONALE:
I controlli GTK generici richiedono, nelle loro varie configurazioni, anche la presenza del tasto Chiudi della finestra, diversamente l'utente potrebbe non riuscire ad usare completamente l'interfaccia in modo consistente.
E' un problema di integrazione tra le tecnologie che va risolto a monte..forse Freedesktop è il luogo ideale.
Doppio click sulla barra della finestra produce la massimizzazione.E' una funzionalita nascosta in quanto ridondante alla capacita di estensione manuale dell'utilizzatore.
In pratica la persona è in grado, utilizzando l'angolo in basso a destra della finestra, di modellare la stessa a proprio piacimento e quindi anche massimizzarla, ma non minimizzarla o chiuderla completamente.
Cosi ho deciso di esplicitare visualmente le due funzioni di Chiusura e Minimizazione tenendole adeguatamente separate tra loro per evitare errori dovuti all'imprecisione di puntamento.
Sfrutto, in questo caso, anche la legge di Fitts per migliorare la capacita di puntamento in quanto le due funzionalita sono agli estremi degli angoli della finestra.
Considerando che la chiusura della finestra è un evento disastroso, ponendo il tasto a sinistra (mentre normalmente lo si aspetta a destra grazie alla diffusione di Windows e OSX) l'utilizzatore ha a disposizione piu tempo per ragionare e controllare la compulsivita (conosciuta come click isterico).
Dai test che ho eseguito, risultano diminuiti i casi di chiusura accidentale della finestra.
L'eliminazione del pulsante di Massimizzazione pulisce l'interfaccia grafica riducendo la complessita.
La funzionalita è comunque presente usando il menu contestuale sulla barra della finestra e comunque cliccando due volte sulla stessa.

L'albero della vita

Qui riassumo la situazione attuale della frammentazione delle distribuzioni Linux per avere un quadro strategico piu immediato.
Il quadro riprende cronologicamente e storicamente le distribuzioni numericamente piu diffuse, a queste vanno aggiunte centinaia di distribuzioni meno diffuse e molto piu specializzate...

Radici del 1992:

SLS

1993:

1) Slackware
2) Debian

1994:

1) Suse
2) RedHat

Da questo punto in poi comincia la grande scissione secondi questo schema:

SLS->Slackware->
Slackware->S.u.S.E.->SuSE
SuSE->Sun Java Desktop System
SuSE->SUSE

Slackware->Vector
Slackware->SLAX
Slackware->Minislack
Minislack->Zenwalk
Slackware->Frugalware

Debian
Debian->Corel Linux->Xandros
Debian->Lindows->Linspire
Debian->Linex
Debian->KNOPPIX
KNOPPIX->Morphix
KNOPPIX->Kanotix
Debian->MEPIS
Debian->Ubuntu
Ubuntu->Kubuntu
Ubuntu->Xubuntu
Debian->Damn Small Linux

RedHat
RedHat->Connectiva->Mandriva
RedHat->Mandrake->Mandriva
RedHat->Red Flag Linux
Mandriva->PCLinuxOS
RedHat->Ark Linux
RedHat->Fedora Core
Fedora Core->FoX Linux
RedHat->CentOS
RedHat->rPath
rPath->Foresight
RedHat->White box

CRUX
CRUX->Arch Linux

Gentoo
Gentoo->VidaLinux/VLOS
Gentoo->Kororaa

Manca molto materiale ma tutto è riducibile a questo.

[The Road To...]

Quando Mario attiva la cache con io SpatialBundle questo deve rimanere autoconsistente attraverso l'uso di Maria ed altri utilizzatori.
Cio implica che le modifiche dinamiche al proprio Desktop devono avvenire TUTTE localmente in $HOME/.local
Devono essere eliminate le modifiche nella LiveDir.
Mario ha i diritti in scrittura nello ioSpatialBundle in caching quindi è l'unico che potrebbe scrivere nella LiveDir mentre Maria ha solo diritti in lettura rimanendo penalizzata in scrittura nella LiveDir.
La LiveDir viene eliminata a favore di un metodo dinamico in caching: DinamicCacheLiveDir presente in /tmp/ioSpatialBundle_DinamicCacheLiveDir_Maria/ costruita semplicemente con:
export PROGRAMMA=ioSpatialBundle
export PERSON=whoami
export CacheLiveDir=$PROGRAMMA"_DinamicCacheLiveDir_"$PERSON

[The Road To...]

Bisogna tener conto che Manuela potrebbe voler/dover passare un file allo SpatialBundle per poterci operare sopra.
Potrebbe operare in questa direzione trascinando il file sullo SpatialBundle oppure passare in qualche modo il parametro a linea di comando o tramite un'associazione MIME esempio:

$ioGftp ftp://manuela@ftp.infodomestic.com

In questo caso lo SpatialBundle deve essere in grado elegantemente di poter prendere qualsiasi parametro $1 in ingresso conservarlo gelosamente e portarlo all'attenzione del CrossBundle ed in particolare del file ultimo eseguibile in questo caso in:

/Programs/ioGftp/Linux-ix86/bin/gftp ftp://manuela@ftp.infodomestic.com

Questo comporta che lo SpatialBundle rende accessibile globalmente la $1 esportandola definitivamente a runtime per i sottoprocessi con un comando del tipo:

export $PayLoad=$1

da quel momento in poi qualsiasi script puo conoscere il valore del $PayLoad inteso come carico da assegnare al CrossBundle (inserire in SpatialBundleToDo)

[The Road To...]

Il rispetto del versioning avviene in compilazione dove il compilato deve rispettare il prefix contenendo anche il numero di versione.
Questo processo è potenzialmente indipendente dal nome dello SpatialBundle il quale è un file nominabile come si vuole.
Esempio:
Compilazione con
$./configure --prefix=/tmp/Programs/ioWine0.9.8/Linux-ix86
e SpatialBundle di nome
ioWine

Per questa ragione è opportuno inserire con precisione il numero di versione nel file ioWine0.9.8_SpatialFactory.sh tale da permettere al builder di sapere dove costruire il dinamic disk cache.

In questo modo si puo aggirare il problema di necessaria sincronia tra il nome dello SpatialBundle che segue regole di apparenza e il nome della destinazione compilata che segue la coerenza di versioning per evitare conflitti.

Di conseguenza è possibile avere anche 4 file SpatialBundle di nomi vari e puntare allo stesso programma con 4 versioni differenti.

Esempio di differenze tra /tmp/Programs/ioJava1.4 e /tmp/Programs/ioJava1.5 con eventuali SpatialBundles di nome ioJava e ioJava2

Cestino in Nautilus

Sarebbe interessante integrare il cestino in Nautilus tale che sia piu immediato cancellare un file semplicemente trascinandolo nel cestino della finestra attiva.
L'uso del cestino nel Desktop necessita un ulteriore movimentazione e disposizione delle finestre per permettere il trascinamento.
Mentre l'uso del cestino nella barra necessita di un icona di dimensioni maggiori rispetto a come viene presentata la bottom bar in Ubuntu.

Vorrei vedere se è possibile integrare il Cestino nell'elenco dei Device e non in quello dei Bookmark del riquadro laterale delle Risorse a sinistra.

Di seguito una patch dalla comunita:

http://mail.gnome.org/archives/nautilus-list/2007-March/msg00095.html

Un metodo molto banale consiste in:

Creare un bookmark alla cartella $HOME/.Trash di nome Cestino.
Cambiare icona alla cartella $HOME/.Trash e metterci un cestino.

A questo punto il bookmark compare nel riquadro laterale con la dovuta icona e pronto a ricevere dati da cancellare.


Bisognerebbe eliminare il tasto di chiusura del riquadro.E' un elemento non utilizzato dalle mie "Personas" (su Wikipedia).

Mi aspetto che eliminando il pulsante di chiusura abbia come conseguenza una maggiore pulizia dell'interfaccia visuale e sopratutto evita uno stato di inconsistenza visuale quando anche per errore (casi di click isterico) il riquadro laterale venga chiuso inavvertitamente.
Il mio utente geek test di riferimento risponde dicendo che è sufficiente andare in Visualizza->Riquadro Laterale oppure premere F9.
Ma rispondo che sono due funzioni nascoste e che Manuela deve essere istruita (aumento del carico cognitivo) e che cio comporta il trasferire il carico di memorizzazione dal mondo esterno (l'interfaccia che si osserva direttamente) alla memoria interna (la memoria del nostro cervello).

Test eliminazione tasto "Chiudi" dalla barra della finestra

Nelle mie osservazioni ho notato che Manuela e Barbara (Personas) tendono a confondersi sulla scelta per chiudere l'applicazione usando o il tasto di chiusura finestra o la voce "Esci" dal menu dell'applicazione.
La scelta di Mac OSX è quella di dividere le funzionalita tra gestione manipolazione applicazione (finestra) e gestione applicazione cosi che se chiudo la finestra l'applicazione rimane aperta ma minimizzata mentre se Chiudo l'applicazione viene chiuso tutto.
A mio avviso, nonostante apparentemente razionale, la scelta è piuttosto fuorviante perche ancora oggi viene svolta una scelta da geek tecnologo!!! Dove l'istituzione "Finestra" <> "Applicazione" la fa da padrona.
Nella pratica non è cosi per il 99% dei casi.
Una finestra = Una applicazione tale che la sua manipolazione spaziale ad oggetti deve fornire un feedback consistente di completa integrita.
L'utilizzatore vede un oggetto (Finestra + applicazione in essa contenuta) e lo considera, come le cose nella realta, un oggetto unico composto da attributi (dati vari) e metodi (funzionalita varie).
Con questa premessa nei casi generali ci si ritrova ad avere una duplicazione di una funzionalita chiave quale quella della chiusura dell'applicazione (sia tramite il pulsante di finestra sia tramite la voce del menu dell'applicazione File-> Esci).
Cio comporta confusione specialmente nei casi dove l'applicazione tende a rimanere inconsistente se viene chiusa (dicesi bruscamente) dal pulsante della finestra.
La mia visione sarebbe quella che il gestore di finestre sia finemente integrato con l'applicazione stessa tale che l'azione di chiusura dal pulsante della finestra sia una reale chiamata equivalente alla voce File->Esci o File->Chiudi o File->Quit dell'applicazione.
Da oggi testo sulla mia pelle la completa eliminazione del comando di chiusura della finestra per cercare di notare operativamente gli attriti cognitivi durante un quotidiano utilizzo.

Da questo momento sarò costretto ad usare la voce di menu per chiudere l'applicazione.
Nel caso dovessi trovare difficolta per qualche applicazione che non prevede la voce allora posso far riferimento all'uso del tasto destro (AAAAarrrgh!!)

Patch per GMail Notify

Pagina ufficiale di GMail Notify

Aggiunta patch per permettere la connessione sicura in tunnel https quando si apre nel browser

WineHQ bug hunters...

E' incredibile la professionalita e la super velocita nel seguire i Bug entry nel sito winehq.com

8306
8321
8322
8323

Tempo zero ed ho ricevuto un feedback potentissimo che mi ha aiutato a risolvere piuttosto velocemente i problemi e riesumare un problema nativo di wine che verra presto risolto...

Wine 0.9.36

Compiling wine 0.9.36 after installed all -dev packages related to wine activating all possible options.

Building: ioWineIsNotAnEmulatorFullOptionalFeisty0.9.36 to build a standalone Bundle

Test di Applicazioni Windows

Con la nuova versione di Wine è possibile far girare applicazioni Windows in Infodomestic Linux piu velocemente.
Avrei intenzione di testare per distribuire piccole applicazioni windows.
In test:

FrameShow
Bopupmess
7zip
PicaJetFX

Primo post in Infodomestic Developer Connection

Questa sezione dovrebbe fornire informazioni varie sui sviluppi di Infodomestic Objects nella fattispecie di Linux Panorama.

Prima di buttarmi a capofitto vorrei rendermi conto dell'efficacia di Blogger.

Il servizio di pubblicazione via mail funziona in modo parziale ovvero le mail inviate a titolo di post vengono parcheggiate come Bozze per un eventuale parsing secondario.
Lo trovo un po noioso dover assicurarmi di pubblicare il mio post.

Non riesco ad inserire il lettore feed, mi oscura una parte della finestra AJAX.