Ghis a écrit 127 commentaires

Vus la formulation de la question, il insulte même carrément 'bon nombre de démocraties'.
heureusement pour lui, on ne sait pas de façon explicite lesquelles.

Un avantage de OSS est que contrairement à ALSA il est multi-plateforme.
Du coup je suppose que les applications ALSA ne sont pas portables sur d'autre OS que Linux.
Si c'est le cas c'est tout de même un gros problème non ?

Oui mais mais moi je dis un panneau Pop-up, donc je dirais un Pop-up.

De toute façon le Français c'est la langue ou on ne sait jamais si les mots sont filles ou garçons.

Oui, TimeMachine (ou plein n'importe quel autre soft de backup).

Apparemment il aurait soumit des papiers, mais ils ont été refusé par les comités de lectures. Ensuite à savoir si c'est parce que le papier n'était pas pertinent ou si c'est parce que le comité de lecture n'était pas tout a fait impartial (cela dis l'un n'empêche pas l'autre).

l'Anthropisation, se sont les changements qui ont pour origine l'action de l'homme.

Kevin, le fils de madame Michu, peut déjà facilement faire ce qu'il veut à l'abris des indiscrets regards d'Hadopi. Et maintenant c'est madame Michu qui s'y met.
Il va falloir un Hadopi3 qui surveille si l'on recherche des mots clés comme OneSwarm, Tor, torrent... Puis un Hadopi4 qui mettra des micros dans les lampes de chevets pour surveiller nos conversations au cas ou le sujet serait évoqué de vive voix.

Un autre truc que j'avais trouvé sympas ce sont les plugins systèmes.
Par exemple tu rajoutes un plugin ogg dans le répertoire qui va bien et hop, toutes tes applications qui utilisent du son sont capable de lire ou écrire le format ogg.
Cela fonctionne pour les formats de son, de video, d'image, de compression...

Je ne pense pas que cela explique tout mais,
pour BeOS le noyau, le FS, le Navigateur de Fichier, les core utils.... bref tout les élément du système ont été pensé comme un tout très cohérent par des ingénieurs qui travaillaient ensembles sur un projet avec peut de contraintes (pas d'héritage à trainer, pas de contrainte d'autres groupes de développements...).
Pour Linux chaque morceaux de l'OS est relativement autonome, du coup si il existe des FS qui proposent des fonctions équivalent à ce que fessait BeFS, il est peut probable que tout les autres éléments de l'OS se structurent autour afin d'en tiré le meilleurs partis au travers de toutes les couches qui compose l'OS (du FS à l'interface utilisateur, en passant pas le noyau, les utilitaires systèmes...).

Bien sur que ces couches existent sous Haiku puisqu'il detecte le materiel, mais ce n'est probablement pas un empilement d'un grand nombres de projets d'origines hétéroclites et parfois partiellement redondant que l'on fait tant bien que mal cohabiter (oui je sais j'exagere). De toute façon vus qu'Haiku est sous licence libre ceux qui comprennent les obscures incantations contenus dans le code sources de l'OS pourrons toujours aller y jeter un oeil.

Ensuite le temps de boot d'un ordinateur Desktop grand public a toujours été un problème important, surtout en 1995 (époque ou la tradition voulait que l'on éteigne régulièrement sont ordinateur de bureau, et donc qu'on le rallume au moins autant de fois). C'est juste qu'à l'époque Linux ne visait pas encore le créneau de l'OS Desktop grand public.

Dans Haiku (tout comme BeOS en 1995) il n'y a pas de configuration à faire, le système se débrouille tout seul et malgré tout arrive à booter en quelques secondes, et pour cela pas besoin de 50 couches issus de 30 projets différents.

Bon ensuite BeOS c'est une seule boite qui la conçu et c'est prévus pour du Desktop, Linux c'est à une histoire bien plus complexe et un spectre d'utilisation plus large (Desktop, Serveur, Embarqué).

Ton petit journal est très intéressant, il montre que pour une première version Alpha Haiku s'en sort plutôt bien. Bien sur, il lui reste bien sur pas mal de chemin, mais le plus gros à l'air d'avoir été fait.

Voici quelques petites remarques que je te laisse en vracs:

- Si tu compresses tes fichiers (en zip si ma mémoire est bonne), tu pourras faire passer tes fichiers sur une clé USB en FAT sans perdre tes Metadonnées.

- Pour le navigateur de fichier, en prenant l'habitude d'utiliser des livequery, on arrive à ne plus trop s'embêter avec 36 fenêtres ou des hiérarchies répertoires/fichiers, on peut souvent créé juste des vues qui affichent les fichiers voulus.

- Pour les mails, je m'étais fait un système de livequery (comme ton exemple avec les contacts)
j'avais un système de vues qui m'affichaient les fichiers type:mail avec satus=unread spam=false ... et l'affichage dans les colonnes d'attribus des fichiers les noms, date, nombre de pièces jointes... pareil pour les reads, les send, les mail que je voulais filtrer... Cela me suffisait amplement pour faire des choses déjà assez sophistiquées.

- Ensuite il y a certaines choses que tu ne sembles pas avoir apprécié qui sont de l'ordre de l'habitude (comme pour les bords de fenêtres qui déplace une fenêtre plutôt que de la redimensionner). Cela m'a fait sourire car je me souvient d'avoir fait ce même type de remarques mais dans l'autre sens quand j'étais passé de BeOS à Linux. Un OS c'est comme des pantoufles il faut un peut de temps pour s'y sentir bien, mais une fois qu'on en à pris l'habitude il deviens difficile d'en changer.

J'avais moi aussi été très impressionné par les possibilités de ce système de fichier et de de sa bonne exploitation à tout les niveau du système. Ca avait changé ma façon de travailler avec les fichiers.

Par exemple le daemon qui recevait les mails les stockait en vrac dans un répertoire sous forme de fichiers au format texte avec un type Mime:Mail et des metadonnées comme From, To, subject, Spam, Status....
Ensuite il suffisait de créér sur son bureau des répertoire virtuel (livequery) qui contenaient une genre de requête SQL (par exemple: Affiche les fichiers avec typeMime=mail, satus=unread, Spam=false) puis de faire afficher par le navigateur de fichier les metadonnées attendus pour un mail (titre du mail, auteur, status, date...) Et hop on avais un petit gestionnaire de mail.

De même que les ID3 pour les MP3 ou les EXIFS pour les images servaient à renseigner les metadonnées, on pouvait utiliser le navigateur de fichier comme un gestionnaire multimedia assez puissant.

Ce système étant très bien intégré à tout les niveaux du système. On en venait à l'utiliser assez naturellement, on finissait même par ne plus avoir besoin de penser en terme de hiérarchie de répertoires/fichiers.

Ce système était très réactif, chaque changement sur un fichier était immédiatement répercuté au niveau des livequery, on ne ressentait aucune latence même sur une machine dont le processeur n'était pourtant pas une bête de guerre (166Mhz).

Tu as une image Virtual Box construite sur un Ubuntu 9.04 qui date du moi de juin 2009.
http://download.gna.org/etoile/EtoileDevImage06102009.zip

Mais pour le moment ce projet n'est vraiment utilisable, mais j'espère qu'il finira par arriver à maturité, car je le trouve plein de bonnes idées (et puis j'aime bien tout ce qui tourne autour du trop délaissé GNUStep).

Konqueror ? c'est du bricolage à coté.

J'aurais du mal à bien expliquer les détails, mais voici ce que j'avais fait pour les mails:
- J'avais un daemon qui recevait mes mails, il les écrivait en vrac dans un répertoire sous un format texte avec un type Mime: Mail. Lors de l'écriture du mail, il était rajouté au ce fichier des attributs étendus genre From, To, subject, Spam, Status....
- Sur mon bureau j'avais créé des répertoires virtuels qui affichaient les fichier correspondant à un genre de requête SQL, genre: Affiche les fichiers avec type=mail, satus=unread, Spam=false. On pouvait bien sur tout faire en ligne de commande.

Pour le cas des fichiers type images ou des MP3 des utilitaires existaient pour renseigner automatiquement les attributs étendus avec les données exifs ou ID3

le tout était géré au plus bas niveau système de fichier et réagissait sans aucune latence, sur une machine dont le processeur n'était pourtant pas une bête de guerre (166Mhz). On finissait assez naturellement par ne plus avoir besoin de penser en therme de hiérarchies de répertoires/fichier.

Sur MacOS ou sur Linux il existe des systèmes essayant de reproduire ce genre de chose mais aucun n'est convainquant car construit a des couche plus haute et non intégrés dans le systeme.

BeOS est un des systèmes qui m'a le plus marqué (avec les os de l'Amiga et du NeXT).
Il y avait plein de bonnes idée dedans comme notamment son système de fichier et ses livequery qui m'avaient beaucoup marqué. Cela permettaient par exemple d'utiliser l'explorateur de fichier comme gestionnaire de mail, de photos, de musique, de documentations... je n'ai jamais rien retrouvé d'aussi puissant que les livequery.

par défaut le noyau démarre en 32 bit sur les machines desktops, et 64 pour les serveurs.
Mais il est possible de modifier ce comportement.

Par contre il semble que tout le reste du système soit en 64bits, en effet, quand mon mac mini à fini de booter et que je liste les processus, tous sont en mode 64bit sauf le noyau.

l'incrémental c'est ce que j'ai appelé la chronologie, en gros tu programmes les snapshot des répertoires qui t'intéresse dans cron (avec des intervalles pas ne sont pas forcement identique pour chacun) et ça roule, je crois que c'est ce que fait Sun avec OpenSolaris et son clone de TimeMachine.

Ensuite est ce que c'est mieux de séparer la partie incrémentale et la partie copie de sauvegarde dans deux systèmes diffèrent, peut être que oui, peut être que non, si quelqu'un à une expériences.

Si ton disque crame, ton snapshot crame avec.

Cela dis vus que les les snapshot s'occupent déjà bien de la partie chronologique du backup, je suppose qu'il suffit ensuite de faire un simple clonage périodique du disque ZFS sur un autre pour assuré la partie externalisation.

Sur OSX il y a Mathusalem qui est pas mal, mais son auteur ne semble en avoir abandonné son développement. Peut être qu'il serait portable sous GNUstep qui sait (il est sous licence libre)
http://code.google.com/p/mathusalem/


Sinon Sun a intégrés une fonction du même genre que TimeMachine dans le gnome de son OpenSolaris, c'est basé sur les snapshot ZFS. Peut être que cela viendra sous Linux (avec btrfs) ou Net/FreeBSD (avec ZFS), mais bon le snapshot ça ne remplace pas un Backup (on reste sur le meme disque).

C'est vrais que la suite de Apple est très intuitive à utiliser, c'est dommage qu'Open office ne se soit pas inspiré de l'ergonomie de cette dernière. En fait ces principes d'ergonomie remontent au travail fait pour NeXTStep.

Dans le libre, Il y a Bean, un petit traitement de texte qui reprend ces même principes d'utilisations, Il est possible de le faire tourner sous n'importe quel Unix à l'aide de GNU-Step.

http://www.bean-osx.com/Bean.html

Sa mascotte est un poisson, qui était le symbole des premiers chrétiens. Ichtus (poisson en grec) était l'acronyme de Iesous Christos Théou Uios Sôter soit ”Jésus-Christ Fils de Dieu Sauveur”.

Ce ne serait pas plutot rake l'équivalent de make en ruby ?

D'ailleurs Rake vaux quoi par rapport au commentaire du journal ?

Je trouve Ruby bien plus agréable que python (probablement une question de goûts).
Il est vrais que python est globalement un peut plus mature, mais dans le domaine précis qui t'intéresse (le web) Ruby se révèle avoir beaucoup de succès.

Bref tes goûts entrerons probablement comme un des principaux critères de choix.

Sous BeOS c'est en noir sur fond blanc, MacOSX s'inspirait il de BeOS ???