daemontux a écrit 190 commentaires

Ben si, suffit d'utiliser la connexion du voisin (reste encore pas mal de gens en WEP).
Et là, double avantage :
_on se fait chopper,
_le jour où le voisin se fait chopper sans avoir rien fait, ça crée un super militant anti-HADOPI !

Sauf que c'est censuré. Perso j'écoutais presque jamais, mais maintenant qu'ils ont viré Guillon j'écouterai plus du tout.

X11 sur un réseau non-local est lent. Très lent. Il faut être motivé pour l'utiliser sur une connexion moyenne à travers Internet.

Et ici il ne s'agit pas juste d'accéder à une application distante, mais de gérer une ferme de serveurs fournissant des applications ou des bureaux complets à la demande, fonctionnant sur des clients n'ayant qu'un navigateur Web et Java (donc pas nécessairement de client X...).

Et tu m'expliqueras comment je bénéficie du son sur une application qui s'éxécute à distance en montant le volume via sshfs... À la limite ça me permet de lire les fichiers avec une application locale, mais le but étant d'utiliser une appli distante...

Les perfs des applis en rails semblent varier énormément d'un serveur à l'autre. En tout cas mod_rails (aka phusion passenger) sous Apache, ça consomme et si on veut pas que ça rame il faut activer des options qui le font ramer encore plus.

Je n'ai utilisé qu'une instance de redmine avec peu d'utilisateurs, mais quand je l'ai passée de webrick à Apache elle s'est mis à bouffer une quantité de ram énorme.

On m'a depuis conseillé mongrel de rrière nginx (ou tout seul si on n'a que du ruby à faire tourner).

Par contre je plussoie, Redmine est excellent, très propre et élégant, supporte git/bzr/svn/hg par défaut, a plein de plugins, progresse bien, il est facile de binder les comptes utilisateurs avec ceux de svn etc... bref que du bon !

Il ne doit pas y avoir que sous Gentoo que ça pose des problèmes.

Je l'ai utilisé il y a quelques-mois, sous Debian mais en prenant la version dans les gems, pas le paquet Debian (version 2.2.9), pour faire tourner un Redmine, qui jusque-là était resté avec le webrick par défaut. Et bien c'est lent. Pour ne pas avoir plusieurs secondes (!) d'attente à chaque accès au site après un certain temps sans s'y connecter, il m'a fallu demander à ce que des instances soient pré-spawnées, mais là c'est la conso en RAM qui douille (je viens de regarder, il prend 180 mégas alors qu'il n'y a pas d'utilisateurs connectés)...

Et je ne suis pas le seul à avoir ce problème. Après peut-être qu'il y a une config magique qui m'a échappé (pourtant j'ai essayé plusieurs choses), mais en attendant je le tiens pour lent et gourmand.

C'est vrai par contre qu'il est assez agréable à installer et utiliser.

Chromium est surtout mal intégré (encore plus que Firefox).

Son ergonomie est différente de celle des autres applications, ses widgets ne sont pas standards (même en mode gtk ses onglets ne sont pas des onglets gtk normaux) et surtout il gère lui même ses bordures de fenêtres, ce qui fait qu'il s'intègre mal (par exemple dans une distrib qui mettrait ses boutons à droite il les aurait à gauche) et génère apparement pas mal de rapports de bug (notamment chez kwin, voir le débat/troll actuel à propos des client-side window decorations).

Par défaut il vaut mieux un truc qui s'intègre un minimum au reste (déjà pour que Firefox ne fasse pas alien certaines distribs font un tas de changement pour qu'il utilise les notifications standard, packagekit etc et encore c'est pas suffisant).

C'est vrai que Firefox est une grosse bouse, mais s'il faut le remplacer autant faire un choix qui permette d'avoir un bureau élégant et cohérent.

D'après ce que j'ai vu sur les screenshots, les applis KDE s'intègrent bien sous Haïku niveau look & feel (sauf peut-être les icônes). D'aileurs en général Qt s'intègre bien partout (même sous Gnome ^^). Et puis ça reste du C++, comme le reste de Haïku.

Bref je pense que l'intégration d'applis KDE est une bonne chose et je ne pense pas que ça crée (trop) d'incohérence.

De plus je pense qu'il y a une belle opportunité de combiner Nepomuk & co avec les possibilités de BeFS (stocker les tags Nepomuk dans les attributs étendus des fichiers, utiliser les live queries pour fournir les résultats des requêtes), apportant du coup à Haïku une belle collection d'applications sachant tirer parti de ses capacités.

Compiz a un plugin fuse pour être contrôlé depuis le système de fichiers je crois.

On peut aussi manipuler relativement facilement des fenêtres via la libwnck. En l'utilisant via python-wnck on se fait en quelques lignes des petits scripts pour adapter finement le comportement des fenêtres à ce qu'on souhaite (ou on les manipule directement via le shell python).

Mais c'est vrai que wmii a l'air pas mal, ça fait longtemps qu'il est sur ma liste des wm à essayer mais... la flemme quoi...

on peut s'inquiéter de l'avenir de JavaFX
Larry Ellison avait je crois déclaré qu'il aimerait refaire l'UI d'OpenOffice en JavaFX, donc ils ne vont pas le laisser tomber. Le libérer comme c'était prévu par contre j'ai des doutes.

Sinon pour Java c'était une de leurs principales raisons de racheter Sun donc ils ne l'abandonneront pas, mais la philosophie d'Oracle est très différente de celle de Sun (en gros c'est des cons), ce qui explique peut-être le départ de James Gosling. La question est de savoir s'ils maintiendront un peu d'ouverture dans le processus de développement de Java et s'ils continueront à tout mettre sous licence libre (ils avaient déjà tenté de fournir un garbage collector uniquement aux utilisateurs ayant souscrit du support, cf http://tech.slashdot.org/story/09/05/29/1711203/Java-Gets-Ne(...)

le problème des bateaux et des camions, c'est qu'ils sont beaucoup trop lent par rapport aux trains
Les camions/bus ont l'avantage de pouvoir être ajoutés aux villes déjà construites alors qu'avec les trains il faut tout casser pour poser les rails et les villes nous l'interdisent.

Les bateaux sont au moins utiles pour le pétrole à transporter depuis les stations en mer et lorsqu'il y a besoin d'acheminer des matériaux d'une île à une autre (ce serait pas mal s'il y avait une longueur maximale aux ponts soi-dit en passant, ce qui forcerait à ne pas utiliser les trains pour relier des points séparés par une trop grande étendue d'eau). Et le transport de passagers par bateaux me semble assez rentable dans certaines situations. Dommage par contre que l'on y rencontre pas de concurrence en mode solo, l'IA ne faisant pas de bateaux.

Maildir utilise des sous-dossiers dans chaque dossier de mails et des noms uniques d'une façon qui permet en gros d'éviter à plusieurs applications qui travailleraient en même temps sur un dossier maildir de s'emmêler les pinceaux, sans avoir à utiliser de système de lock.

MH lui a des fichiers numérotés de façon incrémentale, ce qui nécessite des systèmes de lock pour que plusieurs applications puissent taper dedans sans risque.

1) Oui surtout quand on est au taff et que le boss est pas loin
C'est de la veille technologique.

Mais pourquoi 3 milliards de fois plus lentement que MS Office qui possède au moins autant de possibilités ?
Chez-moi, oowriter (go-oo 3.2, ubuntu) se lance en moins d'une seconde. Word se lancerait donc désormais en moins de 3.33e-10 secondes ?

C'est vrai qu'openoffice fut lent, mais sur une machine pas trop vieille les versions récentes et notamment cette 3.2 ont des performances vraiment plus qu'honorables !

D'ailleurs, petit aparté (vu qu'on est vendredi), XNU ça ne représente pas un peu ce que hurd aurait du être ?
Non. Si Hurd et XNU utilisent le micro-noyau Mach, Hurd est multi-serveurs, c-à-d que les services de l'OS (système de fichier, pile réseau etc) sont des processus avec leur propre espace d'adressage, donc si l'un plante il emporte pas tout le système avec lui, mais le coût de la communication entre tous ses processus et les changements de contexte associés provoque de gros problèmes de performances.

Quand à XNU, ils ont juste collé un gros gros bout de code BSD dans le même espace d'adressage que Mach, ce qui leur donne un truc qu'ils appellent "noyau hybride" qui en gros n'apporte rien par rapport à un noyau monolithique (si le fs ou la pile réseau plante, ils peuvent très bien emporter tout le système avec eux, vu qu'ils partagent l'espace d'adressage du noyau).

Après je peux avoir oublié des trucs ou dit des conneries je suis pas expert sur le sujet ^^.

Microsoft gagne autant d'argent car il est le seul à avoir le droit d'exploiter les logiciels qu'il a développés. Et ceci car il en détient les droits d'auteur, qui sont... un monopole d'exploitation temporaire* d'une oeuvre, accordé par l'État.

Microsoft bénéficie donc bien d'un monopole accordé par l'État (tout comme GNU ou des tas de softs libres d'ailleurs).

* en théorie, vu que la durée est allongée chaque fois que Disney le réclame...

KDE était déjà une marque de KDE e.V. si je dis pas de conneries. C'est juste une réorganisation du nommage des différends composants pour rendre les choses plus claires.

Mono, toujours en retard sur son équivalent propriétaire
Ça dépend dans quel domaine. Certes, WPF ou silverlight ne sont pas ou pas entièrement implémentés, mais à côté de ça mono est multi-plateformes (y compris androïd, iphone), capable de faire du ahead-of-time, de tourner sur du mainframe/supercomputer (en gérant des tableaux 64 bits, ce que .Net ne sait pas faire) ou d'utiliser les instructions SIMD du proc, certaines parties du framework (comme Mono.Tasklets pour les coroutines) n'ont pas d'équivalent .Net et ils ont quelques projets intéressants codés pour mono (voir le client bittorrent monsoon qui peut être lancé via moonlight ou le shell C#).

Sans vouloir faire l'apologie de mono, je voulais juste faire remarquer que contrairement à ce que certains semblent penser ce ne sont pas simplement des "suiveurs" qui se contentent de recopier ce que fait Microsoft avec du retard, ils innovent de leur côté et dans certains domaines c'est .Net qui est en retard...

D'après osnews.com, pour avoir libdispatch, FreeBSD a notamment :
# Modified libdispatch to use POSIX semaphores instead of Mach semaphores
# Adapted libdispatch to use portable POSIX time routines
Ça peut quand même pas faire de mal pour le portage sous d'autres Unices, même si bien évidemment ça ne fait pas tout.

C'est développé au MIT (à l'origine en tout cas), pas sous license MIT. Il y a une restriction sur l'usage commercial notamment. Sur http://info.scratch.mit.edu/Source_Code :
"The Scratch source code license allows you to distribute derivative works based on the Scratch source code for non-commercial uses subject to the following restrictions [...]"

Effectivement c'est le cas sous BeOS : des threads partout, partout, partout. J'ai lu un article où un créateur du système originel expliquait qu'en gros BeOS n'est pas tellement plus rapide, mais fait en sorte que parmi tous les threads il y en ai toujours un pour répondre à l'utilisateur, et c'est ce qui donne l'impression de réactivité.

Linux ne posant pas de problème à ce niveau je pense, il "suffirait" d'utiliser les threads plus intensivement dans les applications utilisateur pour obtenir cette réactivité.

"Et puis avec un fichier structuré un simple *2txt et tu as l'équivalent de ton cat de BeOS."
Oui, mais les autres applications qui pourraient vouloir accéder au texte sans devoir interagir avec la mise en forme ?

Pour le moment, les applis Gnome/KDE semblent se tourner vers un usage de métadonnées stockées ailleurs que dans le fs, et mettent des bases de données un peu partout pour divers usages (desktop-couch en ce moment chez gnome, akonadi qui vient avec mysql chez kde...).

Un système de fichier plus élaboré permettrait peut-être de s'en passer, tout en allant vers quelque-chose de plus interopérable, élégant et ne cassant pas la philosophie Unix du "tout est fichier". Non ?

Le XML a vocation à être générique alors poser un brevet sur un cas d'utilisation particulier c'est vraiment, vraiment con. C'est un peu comme si je déposais un brevet sur l'utilisation de la colle universelle pour coller du papier.

Enfin on sait qu'en matière de brevets (pas que d'ailleurs...) la connerie n'arrête pas Microsoft. Quand on voit ce sur quoi porte le brevet utilisé contre TomTom (un hack crade de rétro-compatibilité)...

En plus on voit à quel point l'UPSTO est une organisation sérieuse :
Castro, Elizabeth, "XML for the World Wid Web", publsihed by Peachpit Press, 2001, pp. 182-184. cited by examiner .
Deux fautes de frappe en une phrase et elle est copiée-collée à l'identique deux lignes plus bas... Ils relisent pas leurs brevets avant de les publier ? Où ils les lisent carrément pas ?

Pour qu'il y ait vente, logiquement cela suppose que le client paye... Donc ton exemple est tout moisi ^^.

Tout à fait d'accord. Je ne voudrais pas paraître impolis, mais au delà de ses compétences techniques probablement très bonnes, ce Brad Spengler m'a tout l'air d'être un gros con.

On a à faire à un professionnel de la sécurité et il nous sort des clichés de kévin qui n'a jamais utilisé Linux en guise d'argument. S'il veut vraiment se donner des airs supérieurs en dénigrant le travail des autres, qu'il le fasse au moins sur des arguments valables.

En fait, il me fait un peu penser à Hans Reiser (qui était lui aussi compétent mais également un gros troll, utilisant ostensiblement Windows pour ses présentations lors de conférences et complètement asocial sur les ML du kernel). Si j'étais la femme de Brad je m'inquiéterais... ^^