totof2000 a écrit 9656 commentaires

NetBSD pourrait t'éviter l'option "recompilation", les packages précompilés existent déjà. Une installation de base NetBSD prend peu de place.

La seconde peut faire l'affaire, mais nécessitera une recompilation, et je ne suis pas sur que tout marche (je n'ai essayé que sur quelques utilitaires).

A partir du moment ou les ayant-droits l'autorisent, et sont rémunérés pour, ça ne devient plus illégal.

Pour ma part, j'ajouterais que pour les tests il est possible d'utiliser qemu : il peut émuler plein d'archi différentes (x86, Arm ...). Pas besoin de l'architecture cible pour essayer. Même si qemu ne propose pas exactement l'environnement cible que le PI doit mettre en place, la démarche dans les 2 cas reste la même.

Si en tant que salarié, tu as la possibilité de faire changer d'avis ton management pour des solutions moins clefs-en-main mais plus adaptées aux besoins et/ou moins coûteuses à long terme, estime-toi heureux. Mais si tu penses que ton successeur saura rebuilder le système le base de NetBSD sans procédures, estime-toi inconscient !

C'est vrai que le monde du travail n'est plus ce qu'il était.

En pratique, nombre de personnes, y compris des administrateurs système, appellent leur support plutôt que de faire "man rpm".
Et quand la boite ne paye pas de support logiciel ? Ca arrve et dans de très rosses structures : pas de support logiciel pour les OS. Et la t'es bien obligé de faire man rpm. Après comme tu dis la plupart des "admins" n'ont d'admin que le nom.

Je ne dis pas que c'est mal, je dis seulement qu si c'est juste pour faire de l'objet, Moode, c'est peut-être un peu fort non ?

Si tu suis cette logique tu n'utilises plus boost/qt, et que dire de ruby qui invente un dsl pour chaque besoin ?
La tu mélanges : on parle d'un besoin que je qualifierais d'"applicatif" avec le DSL par exemple et e combler un manque du langage avec moose. Deux choses diffférentes qui ne se placent pas au même nivrau.

Avec un langage comme Ruby (ou Python), je fais de l'objet nativement. Rien a voir avec les DSL.

Non, pas d'accord. En tout cas si c'est le cas pour d'autres langages, ce n'est pas aussi flagrant qu' en Perl.

Effectivement je me suis arrêté à Perl5.
Moose est le framework Perl conseillé aujourd'hui pour faire de l'objet
S'il faut sortir l'artillerie lourde pour juste palier les faiblesses d'un langage, je préfère utiliser un langage dont le paradigme Objet est prévu au départ (et me servir de Perl sans faire du Perl Objet).

T'as raison, je devrais probablement consulter :).

Merci de soutenir ceux qui prétendent que le systeme de brevets est pourri.

Bah, à brevets stupides, méthodes stupides.
On peut pas demander a une boite d'etre 100% sure qu'elle est bien celle qui a trouve cette idee la premiere
Entre être 100% sur et breveter a tout va n'importe quoi, il y a peut être un juste millieu, sinon c'est qu le système de brevets en lui même n'est pas efficace donc il n'a pas raison d'exister.
Et pour le coup, déposer un brevet, quelque part, c'est prétendre et affirmer qu'on a inventé quelque chose.
Sinon tu trouves normal que ce soit la personne qui a eu l'idée en premier mais qui n'apas déposé de brevet, de payer une fortune en frais de justice ou avocats pour prouer qu'elle a eu cette idée avant ? Tu trouves normal que si elle n'a pas les moyens depayer, on la rackette et fasse payer une idée qu'elle a eu ?

c'est le boulot de l'office des brevets, sinon il sert a rien cet office des brevets...
Bravo tu as bien résumé la situation : l'office des brevets ne sert à rien, car il ne fait pas son boulot, et il n'est même pas en mesure d'être certain à 100% que les brevets déposés sont valides.

Dans ce cas, c'est l'arroseur arrosé ....

Ca pousserait les entreprises à faire un peu plus de recherches et de ne pas déposer n'importe quoi.

Comme pour beaucoup de distributions, avoir un gestionnaire de paquets fait partie des attentes des usagers. Un NetBSD minimal n'en a pas. Ce n'est pas une critique.
Disns que pour un pauvre serveur NFS yen a pas besoin, ca fait partie du système de base. Si on veut d'autres trucs effectivement, on peut souhaiter un gestonaire de paquets. Mais j'ai dit NetBSD pour l'exemple, j'aurais pu citer une autre distrib telle slackware.

Oui, ton serveur NFS tournera. Mais les compétences nécessaires pour prendre en charge les alertes de sécurité (j'imagine que tu prends des vacances, par exemple) n'incluent pas savoir compiler et tester un noyau NetBSD...

Et pourquoi ? C'est loin d'être compliqué à faire. Une fois que lalerte est sortie :
- cvs update
- une commande éqivalent au make cofig de Linux dont j'ai oublié le nom (mais il ne te pose pas de question, tout est renseigné dans le fichier de config du noyau)
- un make qui te génère ton noyau

- une copie du nouveau noyau sur l'ancienne machine
- reboot.

JE mets moins de 20 mn chez moi pour le faire.

Pour le systeme c'est pas plus compliqué. En se débrouilant ben ça peut même s'automatiser. Ya bien plus compliqué dans la vie d'un admin système.

Donc même pour un "simple" serveur NFS, si tu n'as pas une armée de barbus à disposition (figure of speech), NetBSD ne remplira pas forcément tes attentes professionnelles.
Tout dépend de ce que l'on attend et de ce que l'on met comme moyen. Et pour l'avoir vécu certaines solutions "maison" sont bien plus efficacees que des solutions "clé en main" proposées pour bien cher par des fournisseurs dits "Pro"

Une vaste majorité des grandes entreprises, et un nombre conséquent d'universités, hôpitaux, administrations, utilisent des NAS/SAN à la NetApp en partie pour simplifier l'administration...
Je ne connais pas spécialement ce que ça vaut en administration une baie NetApp parrapport au cout(et ça je sais par contre). La tu me parle de moyenne/grande structure. Mais imagine que tu démarres une activitédans une petite structure ? Souvent tu fais avec les moyens du bord parce que t'as pas les moyens de payer une baie NetApp. Et dans cette petite structure, tu apprécieras forcémant de pouvoir installer le même OS sur un serveur ayant 500 To de disque que sur un serveur n'ayant que 2 Gb (exemple peut être extrême meis l'idée est là).

"It just works", ce n'est pas seulement pour les étudiants trendy. D'aucuns diront nivellement par le bas.
Oui mais la question principale : qu'es-ce que ça me coute, qu'est-ce que ça m'apporte, et sur quel horizon ? Les choix effectués dans une grosse structure ou une moyenne structure ayant déjà une activité bien rodée ne seront pas les mêmes que ceux d'une petite structure qui démarre.

Ainsi s'il y a une erreur d'analyse, elle sera corrigée avant le codage.
Et tu risques de ne jamais avancer. D'autre part pour ton projet, je te conseille d'utiliser UML (qui est une norme utilisée partout) plutot que Merise qui a le désavantage d'être plutot franco-français et qui a tendance à devenir un peu désuet.

ne méthodologie MERISE ou UP ne sera pas forcément adaptée au cas du développement d'un logiciel libre.


Merise et UP n'ont rien à voir. schématiquement, Merise décrit la structure de ta base, Up est plus une méthode d'organisation de développement (comme XP par exemple). Je pense plutôt que tu veux parler de Merise et UML non ?

Sinon je me suis déjà posé la question : dans vbeaucoup de projets, des documents d'analyse tels que schémas UML, ou autre seraient les bienvenus, mais en quel format ? En général il faut un logiciel pour gérer ce genre de schéma et côté libre je n'ai toujours pas trouvé réellement mon bonheur, alors que pour du code source, un simple éditeur de texte suffit amplement.

Ca veut dire quoi "Utilisable" ?

Un serveur NFS par exemple : y a-t-il besoin d'installer l'artillerie lourde juste pour ça ? Un netbsd de base est amplement suffisant (tient sur moins de 200 Mo), et c'est utilisable pour ce que l'on veut en faire.

Slitaz est pour toi.
Non, je veux la même distribution tant sur mon poste de travail à 1 Peta de disque que sur mon petit filer avec 2 GB de carte CF.

De toute façon pour ça slackware me suffit amplement. Je n'ai pas pris NetBSD, parce que LVM ne sera dispo qu'en version 6.

hein ? Tu te rends compte de ce que tu dis ?

Copmment je fais pour l'installation initiale sur ma CF de 500 Mo si mon installation minimale prend 10 Go ?

J'exagère un peu, mais l'idée est là.

Entre asseptisé et agressif brutal, ya peut-être un juste milieu à avoir.
Parfois la forme que tu utilises cache le fond de ta pensée, et certains ont tendance à se focaliser plus sur la forme que sur le fond.

Vu la direction que prend MySQL avec Oracle, tu devrais envisager la bascule avant de passer en prod ...

Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application.

Le duck typing n'est pas gênant en soi, il faut juste s'y habituer. Non moi ce qui me gène, c'est d'un côté on demande aux développeurs python de tout écrire de manière explicite, tout en ayant ce concept de duck typing dans le langage. Incohérence, quand tu nous tiens ....

i tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?
Comprend pas ton exemple.

Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

Si c'était le cas, tous les gros projets seraient écrits en ADA.

SPIP existait, je le sais, mais le nombre de trucs du genre qui existait se comptait sur les doigts de la main. D'ailleurs, d'autres frameworks qui sont maintenant populaires ont vu aussi le jour. Le problème de templeet est qu'il n'a pas été aussi populaires que d'autres. Mais pouvait-on le savoir à sa création?

Si j'en reviens aux autres framewors, aurait-il fallu s'abstenir de les coder sous prétexte que SPIP existait ?
à la question de savoir si templeet avait les mêmes fonctionnalités que SPIP, l'auteur de templeet répondait que non
Autres besoins, autres fonctionnalités ?

Non. C'est quoi ça ?

Ridicule pour toi ... parce que tu n'as pas besoin d'une distrib qui puisse s'installer tant sur un petit disque de 2 Gb que sur une machine disposant de 500 Gb de disque.