Too Cool for Internet Explorer

lunedì 4 giugno 2007

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

mercoledì 30 maggio 2007

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

giovedì 24 maggio 2007

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.

lunedì 21 maggio 2007

[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

venerdì 18 maggio 2007

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