zul a écrit 443 commentaires

L'architecture de Linux étant ce qu'elle était c'est difficile de compter apres la fusion. Si on considère que les fichiers en 64 dans arch/x86, ca fait a priori au minimum 34113 lignes (commentaires inclus, j'ai pas fait une analyse poussé).

Pour le remarque sur la glibc, j'ai rien compris. Il y'a bien du code spécifique à l'architecture x86_64 dans la glibc (enfin la dernière fois que j'ai regardé le très estimable code de la glibc). Donc ce n'est pas probablement pas 0. Je n'ai pas du tout compris la remarque sur i386 (la possibilité de tourner en mode x86 est possible, mais quel intérêt d'avoir une 'glibc 32 bits' sur un noyau 64 bits.

Si vous voulez vraiment une feature dans NetBSD, vous pouvez faire un don à NetBSD dans ce but, et un devéloppeur sera en retour payé pour effectuer cette tâche (ou alors encore mieux, juste écrire le patch :D).

Ce n'est malheureusement pas suffisant.

Evidemment, ca marche juste hors de la boite parce qu'Intel paye des développeurs pour écrire un driver sous Linux. Par contre, sous les autres systèmes libres, que dalle. On doit se baser sur le driver Linux pour écrire un driver (et sans se faire corrompre par la licence).

damien at openbsd dot org fait un excellent travail sur ces sujets, mais ce n'est pas parfait. D'autant plus que l'architecture pour écrire un driver wifi sous Linux n'est probablement ce qu'on a vu de plus simple (41K lignes de code dans iwlwifi/origin pour Linux, 9K lignes de code pour OpenBSD pour "la même chose").

Actuellement, ufs utilise softdep pour assurer l'intégrité des métadatas tout ça. Ca marchotte, c'est théoriquement plus mieux qu'un journal mais bon en pratique c'est pas si génial que ça (en particulier ca nécessite quand même un fsck au boot (même si FreeBSD utilise un background fsck)).

FreeBSD a implémenté au dessus de geom gjournal, quelquechose qui permet de faire un journal au niveau block. On peut donc s'en servir pour journaliser n'importe quoi théoriquement ce qui est au dessus, en particulier ufs. Après, je sais pas si c'est aussi efficace que si le fs gérait lui même son journal.

Désolé alors et merci pour l'explication. La lecture de la doc m'ayant indiqué que c'etait un mot clé, j'en avais déduit qu'il s'agissait d'un truc spécial, probablement pas objet mais à priori ce n'est qu'un sucre syntaxique.

Personnellement je trouve dommage de rajouter des mots clés "inutiles" comme ça mais bon au moins le modèle objet est "cohérent".

La MSDN indique clairement que ce sont 1/ des types primitifs 2/ des mots clés du langage. En aucun cas des objets.

Documentation du mot clé int
http://msdn2.microsoft.com/fr-fr/library/5kzh1b5w.aspx

Liste des mots clés
http://msdn2.microsoft.com/fr-fr/library/x53a06bb.aspx

Non désolé.

int en java, c'est un type non objet. Integer est un objet autour de int.
en C#, la documentation de la MSDN indique que int est un mot clé correspondant en C à un int32_t. (Même remarque pour char et autres types natifs).

Dans ces deux cas, ils ne dérivent en rien d'Object et ne sont absolument pas des objets. Faut arrêter la désinformation à un moment ...

J'hesite entre branlette intellectuelle et nazisme objet (ce qui est globalement la même chose) pour qualifier la différence. Enfin comme qui dirait, si ca vous fait plaisir :)

Sémantiquement, c'est la même chose sinon. C'est un ensemble de fonctions travaillant sur des objets d'une certaine catégorie. Y'en a un qui est encapsulé dans une classe, et l'autre dans un namespace, mais au final, ca reste strictement la même chose. (on pourrait à la rigueur argué d'avoir un namespace un peu plus poussé genre std::collection::sort mais bon vu la taille de la STL, c'est à mon avis contre productif (la STL c'est petit pour une librairie standard, pas besoin d'avoir 3 milliards niveaux de namespaces)).

Pareil, je vois psa bien la différence entre le java et le C++ sur cette question.
En C++, si on veut utiliser un comparateur spécialisé on utilise un object foncteur qui fait ça comme en java, et on le passe à sort (comme en java quoi).

std::sort dans l'esprit, c'est une méthode statique d'Iterator. Aucune différence par rapport à java.

Peut-on m'expliquer la différence intrasèque ?

Enfin bon le modèle objet de C++ est probablement pas le plus pur, surement par cette volonté d'être multiparadigme. Quand à celui de java, il n'a aucune excuse mais il n'est pas bien meilleur.

usr signifie Unix System Ressource (j'admets c'est pas completement evident)
sbin signifie System Binary (qui pour le coup dit bien ce qu'il fait).

Le terme intuitif est un terme très galvaudé (surtout chez les utilisateurs de Windows mais ils semblent que ca atteint aussi les utilisateurs de Linux). Le terme intuitif n'est souvent synonyme que "on a vu ça un milliard de fois donc c'est la norme", ce qui tient plus de l'apprentissage que de l'intuitif. (question HS: l'homme moderne est il encore intuitif d'une quelconque manière ?).

Un système de fichier sur une base relationnelle, c'est intéressant, mais je n'ai pas encore vu d'implémentation convaincantes. Mais en soit c'est une idée intéressante qui permettrait de faire repenser beaucoup de choses.

Sinon, non je n'ai pas testé GoboLinux, je me suis juste posé des questions sur "cette nouveauté" et en quoi techniquement ca apporterait quelquechose. Notons qu'ils ont au moins fait le bon choix niveau desktop (troll inside, vendreci c'est permis).

Je suis fatigué des gens qui répondent sans lire les commentaires.
Je ne vois pas le rapport entre ce que j'ai dit et la taille des disques durs ...

rm -rf démontre surtout de la facilité de détruire la cohérence du système de gestion de package. Si on a ecrit des systèmes de gestion de package, c'est qu'il y'a des problèmes autrement plus compliqués que de simplement supprimer les packages (oui on devrait supprimer le principe de dépendance et faire des gros statiques partout, on a de la place aussi ... \o/).

Si tu es un administrateur du dimanche qui fait n'importe quoi avec ton système, le système ne peut pas t'aider. C'est hautement débile de faire un chmod -R 777 /. Déja que chmod -R 777 n'importe quoi c'est hautement stupide en général, sur la racine, on atteint des sommets.

A la main, c'est probablement difficile à réparer, probablement pas impossible en reprenant les régles de bases ci-dessus pour tout ce qui est système. Une solution envisageable est d'utiliser mtree(8) pour générer une spécification du système à un temps t et de vérifier à t+1 que c'est la même ( et de corriger sinon). (mtree est un utilitaire qui génère le hash des différents fichiers, stocke leur attributs et cie, des choses qui ne doivent normalement pas bougé sauf si intervention de l'administrateur, plus ou moins intelligente (ca permet entre autre de "vérifier" basiquement l'intégrité d'un système).

En quoi GoboLinux améliorerait l'efficacité de l'administrateur dans ce cadre ?

Je pense au contraire que la hiérarchie de système unix correspond à des choix réfléchis et intelligent.

La distinction entre bin et sbin est importante. sbin devrait contenir des utilitaires permettant la configuration du système. Le fait que tous ces utilitaires restent dans sbin permet de restreindre facilement qui a le droit de les utiliser (en utilisant simplement les acl de base unix, pas un truc over complexe à configurer genre SeLinux). A noter que seul les fichiers dans bin et sbin devraient avoir le bit +x.

Les répertoires lib et include sont a mon avis important si on ne veut pas se taper 50 000 répertoires en dépendances (ou alors the great union hack).

La distinction est assez clair entre / /usr /usr/local ... Elles representent chacune des sources distinctes de provenance ou d'utilisation des fichiers (typiquement single user, multi user (system), systeme de package).

/usr/games existe parce que tout le monde n'a pas le droit de jouer :). Il faut être un copain de root pour le faire. Ca serait assez pénible de modifier les droits fichier par fichier plutot que de changer globalement les droits du répertoire /usr/games (et /usr/local/games).

share, libdata et libexec ont une importance un peu moins forte et pourrait peut-être être simplifié.

Globalement, la hiérarchie de fichier est pensé pour être facilement sécurisé, en mettant en place des politiques globales et simples à mettre en place (par rapport à des choses très fines et un peu overkill dans ce cas comme SeLinux, Mac sous FreeBSD, ....).

A propos du rm -rf. Je n'y crois absolument pas. Ca laisse le système de lien completement en vrac et ca casse tout le système de dépendance. C'est la meilleur façon de créer des problèmes (le seul cas ou ca serait possible, c'est dêtre sur à 100% qu'il n'y ait aucune dépendance). En plus, les rm -rf en root, j'evite :). Enfin c'est assez facile de pas supprimer le bon truc :)

Il est possible que de nombreuses distributions prennnent leur aise avec la FHS, elles n'ont qu'a être strictes envers ce FHS.

Evidemment, ces remarques s'entendent majoritairement pour une utilisation multi utilisateur. Pour une utilisation mono utilisateur ou l'utilisateur peut tout faire, les deux architectures n'ont qu'assez peu d'importance.

Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...

Mauvais système, changer système.
Les systèmes que j'utilise ont une hierarchie claire (et Unix)

/bin et /sbin sont là pour le système. Il s'agit du minimum vital pour booter le système, l'initiliaser (vu que /usr peut-être sur une partition différente).

/usr/bin et /usr/sbin appartiennent aussi au système. C'est le reste des outils nécessaires à la configuration du système en tant que telle

/usr/local/bin et /usr/local/sbin sont les logiciels que j'installe "à la main", en tant qu'administrateur. Il est globalement vide parce que c'est mal de pas utiliser son système de package.

/usr/pkg/bin et /usr/pkg/sbin c'est là où sont installés tous les logiciels tiers installés par pkgsrc.

/opt n'a jamais existé sur mes machines et c'est probablement une hérésie, je te l'accorde.

Si je veux savoir quel fichier appartient à quel package, j'utilise mon gestionnaire de package. Tout ça est très ordonné et hiérarchisé. Je ne vois pas ce qui est complexe, voir même la partie ou il est dur de gerer plusieurs programmes à la main (l'installer dans /usr/local et mettre /usr/local/{bin,sbin} dans le $PATH à la main ?

Sauf que si tout marche, l'utilisateur ne doit pas voir l'arborescence de fichiers. Il veut installer un nouveau logiciel, il va dans son gestionnaire de package, il installe. Les paquets utiles apparaissent dans le menu d'applications. L'utilisateur voit sa petite maison et c'est tout ce qu'il devrait avoir à voir.

Perso, je ne vois pas non plus l'interêt d'un gobolinux a par augmenter d'un niveau d'indirection tous les chemins (vu que les programmes vont chercher dans /lib:/usr/lib:/usr/local/lib:.... les bibliothèques). La hiérarchie semble plus simple au premier abord, sauf que quand on regarde la tonne de simlink tiré dans tous les sens, ca devient bien moins évident. Ca ne résoult même pas (si j'ai bien compris) le problème des multiples versions d'une même librairie partagée). Et si tu te contente de rm -rf ton /applications/firefox, tu 'detruit' toute gestion de dépendance dans ton système de pkg et tu laisse des symlinks dans tous les sens.

Après j'ai peut-être du mal à saisir le concept.

Je me demande si ca a vraiment un sens de comparé fedora et ubuntu dans leurs utilisations. Le public n'est à mon avis pas le même.

Fedora est une distribution importante pour la communauté du logiciel libre parce qu'elle permet de distribuer / tester grandeur nature des solutions nouvelles.

Ubuntu se veut un point d'entrée dans le monde du logiciel libre. Il faut que ça marche, quitte à faire des sacrifices sur les licences.

Quelques examples :
- fedora7 livré le 'nouveau driver intel' pour les intel 3945. Bah il ne marchait pas pour une majorité de cartes. Alors ça a permis de remonter plein de bugs et c'est bien pour la communauté, mais pour un mec qui essaye linux, ca ne 'juste marche pas'. Au contraire, ubuntu avait conservé l'ancier driver (avec le truc immonde propriétaire en userland) et ca marchait. Depuis que le 'nouveau driver' intel marche, il a été inclus dans ubuntu

- le support des codecs qui se telecharge tout seul dans gstreamer a été implémenté d'abord dans ubuntu et ensuite dans fedora. Ubuntu voulait rapidement quelquechose qui permette à tous de lire des vidéos, même si ca pouvait poser certains problèmes légaux dans certains pays.

- Quand on voit la feature liste de F9, on voit par exemple intégration de KDE4.0 à la place de KDE3.5. C'est très bien pour la communauté, mais ca me semble typiquement un mauvais choix pour kubuntu. KDE 4.0 aura de nombreux bugs, et surement des pertes de fonctionnalités par rapport à KDE 3.5 (c'est pas moi qui le dit, c'est un dev KDE :)). C'est "normal" pour des changements de cet envergure, il va falloir les corriger. Mais pour une distribution point d'entrée, il serait surement bon d'attendre un peu avant de releaser un KDE 4.0.

- Sinon le network manager de fedora y'a du boulot, je n'ai pas vraiment été agreablement surpris parce qui s'appelle network manager dans F8. :)

Je me risque à des petits pronostics :
- le point d'entrée dans Linux est de plus en plus ubuntu.
- un certain nombre d'user vont vouloir aller chercher plus loin / entrer plus fortement dans la communauté et vont essayer des solutions genre Fedora ou Debian.
- la majorité des utilisateurs n'en ont rien à foutre de la communauté et vont continuer à utiliser la solution dans laquelle ils sont entrées :).

Conclusion
=> augmentation forte du nombre d'utilisateurs d'ubuntu
=> augmentation plus faible du nombre d'utilisateurs de fedora / debian et cie
=> NetBSD vaincra ( un jour peut-etre )

En mode non hvm ? Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.

Et je note que tous les tutoriaux que j'ai trouvé sur Internet implique de passer par debootstraop ou rpmstrap etc ... Si on pouvait simplement utiliser l'iso, pourquoi utiliser des méthodes si complexe (en particulier quand tu veux installer une debian domU dans un netbsd dom0, tu as pas forcement debootstrap ...).

Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi. Je m'en sers majoritament pour faire des tests NetBSD.

D'abord, tu compare deux modes de développements assez différents. Et ensuite, tu as la mémoire courte.

Con Kolivas a arrété le dev linux pour des raisons qui lui sont propres mais fortement liés à la politique du monde Linux.
La non-intégration de Reiser4 est pas mal politique aussi.

Sinon, les contributions de mycroft@ au moment où on a reussi à le virer était plus que négigeable, voir franchement négative. Dans ce cadre, ce me parait normal de le pousser dehors (je te rappelle que NetBSD utilise (hélas) un système de source centralisé que mycroft@ avait plus tendance à pourrir qu'autre chose).

Linux devient aussi simple que Windows (à savoir des front-end partout pour pas faire grand chose comme ça, ça a l'air plus simple mais au final, on sait globalement pas du tout ce qu'on fait).

Surtout que globalement, il y'a aucune plus value à l'installation de xen. Il aurait copié collé le fichier d'example de conf de xen, et editer les paramètres à la main, ca aurait été bien plus rapide.

En plus, la partie tricky dans les installations de Xen sous Linux, c'est la mise en place du système de fichier qui va permettre l'installation (le .../pub dans l'example). Et ça evidemment, il a oublié de montrer comment il l'a mise en place. En plus j'aimerai bien voir comment il se débrouille avec d'autres distribs linux (genre pour voir comment ils s'en sort avec une debian ou une gentoo).

Sous NetBSD, tu prend ton iso x86, tu lui fais pointer dessus, tu prend le kernel Xen_domU_install, tu fais pointer dessus et tu lance. Ah oui il a fallu éditer le fichier de conf à la main. So hard :). (non je n'ai pas de super vidéo à vous montrer :) (oui on utilise le processus d'install normal, après tout quelle est la différence ?)

Et pas besoin d'installer super virtu-manager pour faire ça. La simplicité est ailleurs.

C'est un port des différents outils de Plan9 (le système de Bell Labs qui a crée un 'vrai' Unix). Ils ont plein de petits outils plus ou moins utiles (très trucs comme 9wm, rio, 9term, ...). Ca contient entre autre le shell qui permet de faire du Plan9 Scripting.

Si ce paquet est installé, on peut attaquer wmii (qui est basé sur les idées de Plan9) avec 9P. Sinon de base, on peut utiliser un shell script classique.

8 en 7 ans d'apres Secunia pour Sendmail
1 en 7 ans d'apres Secunia pour Postfix.

En particulier 2 en 2006 (pour Sendmail). Et la decision a été prise en 2006.

Pour le reste, je vous laisse seule juge, j'ai exprimé les raisons du switch de NetBSD, vous n'êtes pas obligé d'être d'accord :).

Pas de commentaire à faire sur le sujet, le mieux c'est de l'essayer et de se faire sa propre opinion.

A noter qu'il a dit ça après s'être fait gentimment ejecté du projet pour cause de ses commits furieux et de ses flames sans interêt pour le projet. Ceci eclaire peut-etre cela.

Je trouve étonnant que les autres BSD continuent de distribuer Sendmail. Sendmail a clairement été ciblé comme l'outil externe ayant le plus faille de securité, donc celui pour lequel le plus de travail était nécessaire ( à chaque fois, ca veut dire patcher sendmail dans les branches maintenus (deux branches maintenues) puis faire des rapports de sécurité, puis espèrer que tout le monde mette à jour assez vite). Postfix est globalement moins sale niveau code et moins entâché niveau sécurité. Et le fichier de config est lisible.

Concernant la vitesse de dévelloppement de NetBSD, il serait intéressant de savoir comment tu compare la vitesse de developpement des différents systèmes. Faire des releases tous les 6 mois n'accèlérent pas vraiment le processus de dev mais ca donne l'impression de bouger plus. Une mesure intéressante serait de regarder le nombre de commit moyen par développeur et de regarder que les commits utiles (genre pas les whitespace, pas les typos, et pas les 'pull from master repo' (je ne cible personne :D)).

I hope you will enjoy it.

Le lundi de pentecôté c'est pas la journée de solidarité envers les personnes âgées ? Ce qui est bien, c'est qu'on sait où rentre l'argent mais la transparence de la sortie, elle est bien moindre (voir inexistante).

Sinon, comme le montre ce thread, dès qu'on gratte un peu la licence globale, on voit bien que ca ne résoult pas grand chose, et que ce va surtout être une nouvelle taxe dans la poche des majors. Mais je suis quand même sur que beaucoup moins de personnes viendront raler après ça (dans ceux qui défendent les artistes, et pas ces cons de majors qui nous vendent de la soupe (dixit eux-même)).

Dans un monde parfait ou le GC fait parfaitement son boulot, oui :)
Dans le monde réel, demander à la GC de faire le ménage permet parfois/souvent (dependant du motif d'allocation) de réussir son allocation.

Et puis tu peux vouloir evacuer certaines données qui ne sont pas si utiles que ca pour le calcul (même si pour la précision, tu aurai préféré les avoir).

Le problème n'est pas si évident.

C'est là où on aimerait retrouver toutes les facilités d'eiffel pour ce genre de chose. (on se demande même pourquoi si peu de langages permettent d'implementer facilement des contrats : on arrive a peu pres à écrire des préconditions, mais pour les post-conditions, et les invariants de boucle c'est un peu tendu).

Le principe d'exception permet à mon avis de résoudre assez facilement le problème de signaler les erreurs. La difficulté je trouve c'est souvent quoi faire de l'exception ? Si on la catche tout de suite c'est presque aussi chiant que la gestion d'erreur classique. Si on le fait trop loin de ce qui l'a déclenché, c'est difficile de rattrapper le coup (que faire dans ce cas là à partir dire 'y'a une erreur').

Typiquement, une erreur d'allocation, on pourrait attendre deux secondes, faire le ménage dans le GC et retenter l'allocation mais ca sous-entend des choses assez lourdes derrière pour reprendre le fil de l'execution au bon endroit.

Au niveau architecture reseau, c'est ce qui me me semble le plus simple. Enfin ce qui serait bien ca serait d'avoir un firewall sur la FreeBOX (enfin c'est là ou ca me parait le mieux)