Vivi a écrit 819 commentaires

ah cool, je connaissais pas

klog reçoit les messaged du kernel et les transmet à syslog qui les écrit sur le disque.

Je connaissais pas metalog. Mais ça me paraît pas une super idée de bufferiser les logs : quand il y a un gros problème c'est bien de pouvoir l'écrire tout de suite avant que tout se pète la gueule.

déjà les scripts init.d gèrent les dépendances via les numéros qui déterminent l'ordre de démarrage.

Ensuite pour le coup du démarrage parallèle j'ai bien peur que dans la majorité des cas ça ne va pas pratiquement pas accélerer le bazar, voir le ralentir. En démarrant en paralèle tu sollicites encore plus le disque qui n'arrête pas de seeker partout.
En plus dans le cycle de démarrage, y'a syslog qui ne se met en marche avec le kernel qui lui balance alors tout le contenu de son buffer de messages ; ensuite tous les daemons qui sont lancés lui envoient leurs messages de démarrage. Et syslog ne cache rien, il sync tout ce qu'il reçoit sur le disque, ce qui énerve encore plus le disque.

tant qu'on y est ...

La FAQ chez maxtor : http://www.maxtor.com/en/support/downloads/maxboost_beta/faq.cfm(...)

Un petit extrait :

Doesn't Windows have its own caching scheme built in?

Yes, Windows has its own caching scheme residing at the file system level; however, MaxBoost provides performance improvements above and beyond the Windows caching scheme.

How is this different from the cache built into the drive?

MaxBoost provides a larger cache and an advanced caching algorithm that complements the cache built into the drive.

à mort les buffers de taille constante

To begin with, GNU will be a kernel ...

Heureusement qu'ils n'ont pas attendu d'avoir fini ça pour passer au reste !

\o/

Moi, j'utilise ça :

:0
* ^Subject: ({Virus\?} )?((La(te)?st)|New(est)?|Current) )?((Microsoft|Internet|Net(work)?) )?((Security|Critical) )?(Up(grade|date)|Pa(ck|tch))$
/dev/null

Si tu n'es pas capable de l'expliquer clairement, ce n'est pas clair pour toi.

c'est vraiment de la connerie en barre ça. Désolé, mais si l'auditoire n'a pas les connaissances de bases nécessaires, il ne captera rien à ce que tu lui racontes, même si tu es trés clair. Les problèmes/aspects/concepts complexes ne s'expliquent clairement qu'en utilisant des abstractions : si le type en face de toi ne connaît pas ces notions, c'est pas la peine !

En général, l'appli n'est pas très utilisable sans son composant.

certes ;)

Mais pense au cas inverse, où l'appli plante mais le composant continue à tourner en arrière plan comme un malade.

bah, le composant c'est un serveur, si personne ne l'utilise il toune pas "comme un malade", il ne fait rien, comme n'importe quel daemon. Et puis ORBit est capable de détecter si une connexion est coupée et peut donc arrêter le composant.

et il y a bien sûr Objective Caml

y'a déjà plein de projets de boot scripts qui demarre les services en parallèle (me rappelle plus des noms par contre). Je me rappelle que sur une liste RedHat, ils (les dev. RedHat) disaient que ça servait quasiment à rien car ce qui prend du temps en bootant c'est d'aller chercher les exécutables à droite à gauche. En faisait ça en parallèle, c'est encore pire : tu énerves ton disque et ça prend souvent plus de temps au final.

Par contre, l'idée de gérer les dépendances par make, c'est marrant. Mais bon, make est dans /usr/bin, il faudrait le déplacer dans /bin et c'est un peu "overkill" comme méthode.

Every language has some libraries to access C code. So wrapping C code for another language is easy. Wrapping C++ is more complicated. That's why there were so many Gnome wrappers and so few KDE wrappers

on est d'accord

While producing a wrapper is quite easy for C, maintaining it is very burdensome, because every maintainer must add manually all the wrapping code. As gnome and gtk evolves, this turns out to be quite painful. This why many wrapper only do gtk and/or wrap old versions of Gtk or Gnome.

Y'a eu beaucoup de changements lors du passage Glib/GTK -> Glib2/GTK2. Maintenant les API sont beaucoup plus régulières et une trés grande part du wrapping peut se faire automatiquement.

While producing a wrapper for C++ is initially harder, once you have done it, you can automate most of the task.

je vois pas pourquoi ça serait plus facile qu'en C.

Since KDE is written in a higher language than Gnome, there is less need to program in another easier to use language.

merci de me laisser choisir le langage dans lequel je veux développer

Avec plusieurs processus, il te faut pas mal de debuggage en parallele, pas forcement facile a mettre en place:
deux process à debugger: un pour le composant, un pour l'appli.

Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.
non pas forcèment : tu lances le serveur sous contrôle du débuggeur, c'est tout.


> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.

Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops.

Hum, pas sûr. GNOME c'est un desktop ET une plateforme de développement. Les applis développées avec les bibliothèques GNOME peuvent avoir besoin des capacités réseau des composants par ex. Il se trouve que le desktop construit avec les bib. GNOME n'en tire pas parti parce qu'il n'en a pas trop besoin.

Moi, perso je m'en fout un peu du desktop : j'utilise qq applis GNOME, un peu le panel. Par contre c'est bien d'avoir des bibliothèques de développement puissantes et flexibles.

Le principe est sympa mais en pratique çà ne marche pas si bien que çà me semble t'il.

le problème, c'est que c'est quand même beaucoup de boulot pour qu'un langage puisse utiliser le bazar. Il faut se cogner des trucs trés bas niveau (CLR/CIL).

je préférais quand c'était du C bas niveau, même si là encore c'était pas tres cohérent.

pareil

quelques trucs en vrac ...

à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes.

entièrement d'accord. À mon avis, ils ont fait une grosse erreur là. Y'a plein de gens qui aimerait développer des trucs bonobo mais qui ne comprennent pas trop les techniques. Y'a 2-3 tutoriaux de quelques lignes qui traînent mais en pratique ça ne sert pas beaucoup.

Corba a coûté très cher a Gnome en temps de développement et en complexité,

bof, toute la couche CORBA est cachée dans bonobo, la complexité sous-jacente n'apparaît pas quand on programme une appli bonobo.

l'échange d'informations par property bag est lourd à mettre en place.. Cela veut dire que le développeur Gnome doit modifier pas mal son code pour gérer la communication avec le composant bonobo. KPart de son côté remplace un appel de méthode par un appel de méthode.

humpf, je sais pas trop : rien ne t'empêche de définir des méthodes CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.

La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.

A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que tu peux avoir le composant dans un processus séparé.

c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome

mouais. supérieures ? tu nous dis "Bonobo, c'est compliqué et y'a pas de docs, kparts c'est plus simple. Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop". De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.

Quand on pense que developper Gnome en C bas niveau avait été choisi au détriment d'autres langages (plus adaptés au developpement d'applications graphiques pour le desktop), pour des raisons de stabilité et de standardisation...

ah non, pas du tout efface. Le C est choisi car c'est le langage avec lequel les autres langages peuvent le plus facilement interfacer. Dans cette optique, le C est choisi pour écrire des bibliothèques (GTK+, gnomeui, bonobo, etc.). Maintenant l'idée à la mode pour assurer la compatibilité entre langages est de passer par le runtime Mono/.NET.

à ce propos voir :

http://www.hinterlands.org/ver/txt/(...)

ça explique comment en téléphonant à verisign et en leur expliquant que tu refuses les confitions du ToU, ils peuvent retirer ton bloc IP de leur liste de blocs à qui il servent le wildcard. Mais c'est pour l'UK (et rien ne dit qu'ils fassent vraiment).

utilise GARNOME

quand tu veux les compiler toi-même, c'est d'avoir obligatoirement une version de Mozilla complète, compilée soi-même aussi.

non non pas du tout. ca marche trés bien avec les binaires ... si tu as tous les paquets -devel aussi évidemment.

y'a une nouvelle version, la 1.3.8 qui est sortie hier et maintenant il y a quasiment toutes les options du galeon1. Ils ont aussi refait le manager de bookmarks qui est bien puissant maintenant.

Rhythmbox c'est pas mal, j'ai juste eu du mal à réussir à trouver un ripper qui renseigne correctement le champ Track

je confirme, rhythmbox c'est pas mal. Dommage qu'il ne puisse pas lire autant de formats que XMMS. Sinon pour les tags, y'a un programme qui s'appelle easytag et qui est assez puissant pour renommer/modifier les tags automatiquement. (Par contre c'est pas vraiment easy au niveau interface !)

oui tout à fait, argv[0] contient le nom du lien.

Sinon oui, on doit pouvoir faire pareil : y'a donc deux petit fichiers de conf à écrire, un lien symbolique à faire.

hum, non ça n'utilise pas sudo du tout mais des modules PAM

le système fonctionne ainsi :

- tu as une appli qui a besoin des droits root pour fonctionner (typiquement un redhat-config-machin). L'appli se trouve dans /usr/sbin ;

- dans /usr/bin il y a un lien symbolique portant le même nom (redhat-config-machin) vers le programme /usr/bin/consolehelper ;

- quand un utilsateur non-root exécute redhat-config-machin, comme il n'a pas /usr/sbin dans son PATH, c'est consolehelper qui est appelé ;

- consolehelper va authentifier l'utilisateur via PAM en utilisant le fichier /etc/pam.d/redhat-config-machin qui indique quels sont les modules PAM à utiliser. Il va ensuite exécuter le programme voulu avec l'utilisateur voulu, tels que définis dans le fichier /etc/security/console.apps/redhat-config-machin . En fait consolehelper ne fait pas grand chose car il n'est pas suid root, c'est /usr/sbin/userhelper qui fait tout ça.

- il y a une version GTK de consolehelper qui fait qu'on obtient une jolie fenêtre demandant le mot de passe ;

- le bazar utilise souvent le module pam_timestamp qui évite d'avoir à retapper le mot de passe s'il a été entré il y a peu. Une applet du panel GNOME (pam-panel-icon) indique quand c'est le cas.

Et avoir deux frameworks multimedia distincts dans la "developer platform", tu m'excuseras mais on a vu mieux au niveau cohérence.

xine n'est pas dans la list des modules GNOME