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)
| Release focus: Minor bugfixes Author: Homepage: | ||||
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]
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)
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)
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)
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
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)
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.
License: Freeware
Changes:
Changes were made to the help file.
Murrine: Aperto il sito del Progetto.
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.
Iscriviti a:
Post (Atom)
HCCard OpenID ClaimID
Luca Cappelletti
Rome