Misc a écrit 6314 commentaires

Ça n'a pas empêché la direction d'edenwall de l'époque de proposer une version windows d'EAS sans code source tout en se liant à qt, openssl, la lib sasl et d'autres. Bien que n'étant pas toutes sous une license GPL, certaines des bibliothèques utilisés l'ont été, et la direction avait dument été informé des problèmes via le tracker interne ( et des réunions internes aussi ).

Effectivement, rien n'indique que c'était le but de Netasq, et je ne fait que supposer. Et je tiens à préciser qu'en aucun cas je pense que ça soit une volonté délibéré de nuire que je suppose, juste une erreur qui est hélas trop courante, comme tu le soulignes. Le site web d'Edenwall n'était pas des plus lisibles concernant la stratégie "logiciel libre" et si des personnes au courant du libre se plantent royalement comme ça, j'imagine que d'autres n'ayant pas l'habitude ont aussi pu se planter. Netasq utilise du freebsd ( si je me souviens bien ), qui est quand même bien plus simple en terme de retour vu qu'il suffit juste de remonter ce qui a du sens d'un point de vue technique et de la maintenance sans grande obligation ( ce qu'ils font avec la pile ipsec, par exemple, et en ayant des développeurs netbsd dans leur équipe ).

Comme tu le dis, c'est un sujet complexe et je ne sais pas combien de temps est ce qu'il a fallu à la FSF France pour analyser la situation avec des experts, mais je ne suis pas sur que les 3 mois entre le dépôt de dossier au tribunal ( mi octobre ) et l'annonce de la liquidation ( mi aout ) ont suffit à faire une analyse aussi poussé que la votre, en rajoutant l'analyse économique, et autre pour la reprise.

Rien n'indique que Netasq était au courant concernant les soucis de coproriété du code, et nous sommes d'accord pour dire que la situation n'était pas claire avant la publication, et je sais que la direction avait fait pression au sein d'Edenwall pour que les choses changent vis à vis de la copropriété ( de façon fort maladroite, liant des augmentations risibles à la suppression des clauses de co propriété et je pense que c'est aussi pour beaucoup dans la dégradation de l'ambiance au sein de l'équipe technique ). D'ailleurs, le simple fait de vouloir supprimer ces clauses était maladroit et inutile car les anciens salariés, encore co propriétaire, n'ont pas été contacté, et aucune offre pour reprendre la propriété n'avait été fait.

Mon analyse est qu'il s'agissait sans doute une manœuvre visant à rassurer les investisseurs externes, qui ont vite compris que la société devraient être revendu au vue des ventes laborieuses. Et sans la propriété du code, ça ne vaut presque rien. D'ailleurs, c'est aussi pour ça que la société est parti pour presque rien ( entre 30 000 et 40 000 euros ).

Ayant obtenu plus d'information sur le rachat, et au vue de ces infos, je pense que tu as raison, et que Netasq n'a que faire de la publication du code et ne cherche pas à refaire une version commercial du produit, et que ce n'est pas vraiment ce qu'ils ont voulu reprendre. L'idée la plus probable est donc qu'ils ont cherché à reprendre soit prelude-ids, soit reprendre certains contrats à bas prix.

Il reste donc à voir ce que prelude-ids va devenir. J'ai lu que C-S a voulu reprendre le produit ( d'après twitter ), mais nous verrons ce que netasq a dans les cartons pour ça. Ça serait dommage qu'un logiciel vieux de 10 ans disparaisse aussi stupidement de l'internet.

Que je sache, GeneralZod ne bosse pas chez Red Hat, j'ai vu une conf de lui il y a 2 semaines ou il explique qu'il fait des paquets Debian pour son taf ( mais ça, il le dit pas sur dlfp ). ( j'ai pas retenu le nom de la startup ou il bosse par contre ).

En l’occurrence, dans le cas de pulseaudio, je vois pas en quoi ça impacte les sysadmins. Si le souci est de devoir revalider, je pense que le sysadmin 1) fait soit déjà le taf pour tout le reste de la stack qui bouge ( surtout le kernel ) 2) fait soit faire ça par un fabricant ( Novell, Red hat, etc ).

Ensuite, non, le système d'init basé sur des scripts shells est sous optimal :
- soft à la con qui gére mal le concept ( genre bind, qu'il faut éteindre de façon asynchrone avec un outil en cli, genre apache avec des process forkés qui sont pas toujours tués, voir non géré dans le cas de cgi ). L'usage des cgroups permet de tuer proprement tout ça.

• aucun foutu standard pour les scripts d'init, donc le code est dupliqué à qui mieux mieux
  ce qui implique aucune API haut niveau potable pour connaitre l'etat d'un process ( et je parle pas des erreurs subtiles liés à par exemple la gestion des fichiers de pid ). Systemd gére ça via une API dbus, ce qui permet d'avoir une véritable sémantique plus propice à l'automatisation et sans faire X forks/exec.

• des problémes de maintenances à la con dés que tu veux toucher à un script d'init, vu que c'est pas de la config, mais traité comme tel par certain ssysadmins. Systemd permet l'utilisation de template propre, et d'utiliser 2 fichiers, un pour les modifs, un pour la distrib.

Le reste ( limitation d'io, du cpu, montage de chroot/namespace privé ), c'est bonus. Mais pour moi, le systéme d'init à base de script était fondamentalement moisi du point de vue d'une distribution et d'un sysadmin. C'est pour rien que Gentoo a refait un truc à sa sauce, que Solaris et Apple ont pris cette voie, et que Ubuntu a commencé à bosser sur upstart. Le script de démarrage d'une distro basé sur RH/sysV est quand même un monstre en shell, bloated et qui fait le café, et c'est faire preuve d'un mauvais gout que de vouloir garder ça.

Debian a un repertoire /etc/rcS.d/ ce qui permet d'avoir moins de souci, mais qui ne règle pas les autres points ( vu que update-rc.d ou chkconfig, c'est kifkif ).

Donc, je rappelle :
"pulseaudio, ç'est juste une couche faut faire plus"

et
"systemd, c'est trop bloated, ça fait trop de chose".

Visiblement, Lennart doit lire linuxfr car il écoute les conseils schizophrènes de la foule de commentateurs. Ce qui n'empéche pas les gens de trouver des raisons de râler, bien sur :)

Parce que linux est passé d'un systéme pour innovateur à un systéme pour simple utilisateur. j'ai toujours dit que ce que les gens cherchent ( "séparation systéme/ application", "longue durée de vie" ), c'est un *bsd. Sauf que quand je dit ça, personne ne le fait, tout le monde reste bloqué. Et maintenant, tout le monde rale parce que du nettoyage de fond est fait, mais personne n'ose franchir le pas quand même.

Javascript a été choisi pour plusieurs raisons. Déjà, parce que c'est la ou les efforts d'optimisation se font de nos jours. Google et firefox se batte à grand coup de benchmarks, et cela rends le langage plus attractif que d'autres. Ensuite, la popularité du web fait que le projet espère attirer des développeurs ( à comparer avec scheme utilisé pour sawfish, le gestionnaire de gnome 2.0 ). L'utilisation d'un language plus souple que le C permet aussi de faciliter la création d'extension.

Ensuite, l'idée était de remplacer le système de thème de gnome par du css, et je pense qu'il est indéniable d'affirmer que plus de gens connaissent les CSS que les thémes gnome. JS me semble donc aller aussi de paire avec les CSS

J'ai trouvé une paire d'explication ici : http://gnomejournal.org/article/74/behind-the-scenes-with-owen-taylor mais je pense que tu peux trouver dans doute des gens qui ont poser les mêmes questions que toi ailleurs, avec peut être des réponses ( perso, je connait pas javascript, donc ça me change pas grandement ).

Si si, le mot est transparent.

Donc dans gnome-shell en version 3.0, il aurait fallu mettre quoi ? Sachant que pour le moment, les extensions sont non stables ( ie, pas d'ui pour les retirer avant aujourd'hui, pas d'api stable ). Soit ne pas mettre l'icone ( ce qui revient à "pas d'accessibilité" ), soit la mettre sous la forme actuelle. La gestion des extensions est toujours à minima pour le moment et ce depuis toujours, car, à tort ou à raison, ça n'était pas la priorité.

Si on me dit "bah fallait attendre d'avoir une API stable pour les extensions avant de sortir gnome-shell", je rappelle qu'il a déjà été retardé d'un an, et qu'à un moment, il faut faire une release si tu veux avoir du véritable feedback de la part des utilisateurs ( "release soon, release often" ). Si Kde 4 a bien montré un truc, c'est que garder ton produit en beta n'aide pas, car les gens qui testent trouvent ça super, mais pas le reste du monde.

Donc faire une API sans savoir exactement ce que veulent les gens, c'est relativement dur, et c'est couteux à supporter. Donc le choix a été fait d'ajouter ça après. Une fois qu'une API sera défini, oui, je pense qu'il faudra migrer les divers outils. En attendant non, l'infra ne le permet pas sans paraitre totalement hypocrite.

en même temps, on accepte ce genre de liberté d'entité privé pour leur gain personnel, en quoi on doit refuser ça à des entité publiques ( donc plus transparentes ) pour le bien de la société ?

SI on légitime d'un coté pour le privé, on légitime aussi pour le publique.

De plus, le fait d'accepter ces pratiques fait qu'un marché se developpe, et que les solutions sont ensuite revendus à des états peu scrupuleux, puis proposer aux notres. Il faut bien voir d'ou tout ceci commence.

Je suis d'accord, je pense aussi que c'est plus propre et je suis entiérement d'accord sur le fait que ç'est une des forces du logiciel libre à l'oeuvre. Pour moi, la majorité des gens sortent gagnants de l'histoire. Mais pas tous sortent aussi gagnant les uns que les autres.

Tout dépend en effet du deal. Si le but était de racheter les restes de la boite afin de s'assurer qu'aucune nouvelle entreprise ne proposent des services, je suis pas sur que Netasq soit si gagnant.
Si le but était de proposer des services exclusifs aux anciens clients, je pense pas que ça soit tip top de perdre l'exclusivité.

Et du point de vue de l'incertitude juridique ( qui en effet était un souci ), c'est simple. Soit Netasq aurait eu envie de la lever, et donc il suffisait de publier ça sous une licence libre ( solution équivalente à la présente et moins couteuse ), soit ils ne voulaient pas et voulait garder ça comme étant leur propriété ( et ils étaient prêt à payer ). Donc cette publication ne change soit rien pour eux ( donc je vois pas comment ils sortent gagnant par rapport à la non re-publication, à part sur e fait qu'ils ont pas à gérer ça ), soit elle va pas dans leur sens ( ie, un éventuel changement de licence ) et ils sortent pas gagnant de leur point de vue.

La seule façon d'envisager qu'ils en sortent gagnant serait de se dire que la publication a empeché de se fourvoyer dans une erreur et de leur couter de l'argent. C'est vrai dans le fond au vue des contrats, de la jurisprudence et du reste, mais je trouve ça un chouia vantard quand même :). Au final, c'est pas pour rien que la plupart voir tout les procés autour du logiciel libre se termine en faveur du libre.

Donc oui, les clients sont gagnants, les ex-salariés sont gagnants, le libre dans son ensemble est gagnant, les entreprises innovantes peuvent proposer des services et sont gagnantes, et Netasq n'est pas trop perdant. Mais si quelqu'un avait eu d'autres idées ( et j'aurais tendance à dire que c'est le cas sans quoi certains mails ne seraient pas parti ), je pense qu'il s'estime moins gagnant, voir perdant.

Je pense que les gens de Gnome estiment que l'accessibilité est assez importante pour faire parti du coeur de gnome-shell. Et attendre d'avoir une exception implique d'avoir une API pour les extensions ce qui n'existent pas encore pour le moment. Donc plutot que de dire "on oublie l'accessibilité jusqu'à ce qu'on puisse avoir une extension en 2012", ben ils ont mis ça dans le core.

Gnome-shell n'a pas pour vocation non plus à suivre un design de micro noyau :)

Le plus gros souci, c'est que personne ne voit le gros truc avec marqué "alpha" sur le site....

Gmail a visiblement réussi à marquer l'esprit des gens et à faire oublier le concept de pré version, et la transparence qui avec la publication du logiciel libre.

Bah tu oublie le client pour IOS, tu oublie pour android ( ou du moins, de façon industrielle ). Pour windows, c'est chaud. Pour OS X, il y a des soucis pratiques de tests ( vu que pas de vm avec os x, faut X machines avec X fois OS X, y compris les versions plus en vente, so fun ). AU final, pour linux, c'est vachement plus simple vu que tu as un truc libre, et tu peux facilement tester sans souci, et déléguer la gestion de l'intégration à la distribution.

Le souci, c'est qu'un des anciens commercial et dirigeant ( je dirais pas fondateur car il est arrivé juste en même temps que moi, genre une semaine avant, et j'était l'employé numéro 4 ) cherche à reprendre la boite ( aprés s'être fait virer par le PDG qui a bien constaté que le business modéle n'était pas suffisant et que certains n'appliquait pas ses directives ).

Il a tenté de s'allier avec des compagnies improbables comme Qosmos ( les mêmes qu'on voit http://owni.fr/2011/12/01/spy-files-wikileaks/ ), ou Thales ( même carte ), pour finalement aller du coté de Netasq.
Edenwall ayant fait faillite ( https://linuxfr.org/users/moules/journaux/edenwall-la-descente-aux-enfers ), le plan était de racheter une partie suite à la liquidation.

Mais voila, en publiant le code source tel qu'il aurait du être publié depuis longtemps, le deal est mal barré, car il y a du coup plus rien à choper, à part des procés, mais je suppose que les nouveaux investisseurs sont au courant, et ils sont plus à 50000 euros prés si ils veulent vraiment investir ce qu'il faut ). Pas de locaux, pas de brevets, pas de matos spécifique, pas de contrats juteux ( pole d'innovation, etc ).

Il y a bien la marque edenwall ( qui n'a pas une grande valeur ), les clients ( mais ils sont tous deja parti ) et le logiciel client proprio. Client en question qui est un gros hack pour les vieux windows à coup d'un équivalent de netstat et qui est la faiblesse de la solution dans un monde ou les gens utilisent de plus en plus d'appareils persos ( portables, tablettes ) au boulot. Les problèmes de maintenances étaient relativement nombreux et couteux au vue du manque de standardisation de ces APIs coté windows, et vu le nombre de versions, l'absence de code source et la non participation d'une communauté, ç'était juste le bordel.

Et je ne parle pas non plus des problémes liés aux logiciels de protections ( les trucs qui font qu'un antivirus bloque tout de suite le soft ), rendant le logiciel impossible à débugguer chez le client, entrainant des délais et des couts qui n'ont pas été prévu au début.

Donc du coup, lui, il est bien en pétard vu que le deal va sans doute tomber à l'eau ( sauf à être assez con pour aller frontalement contre la FSF france et le monde du libre en général ), mais ça se comprends. Mais bon, tout 'est pas perdu, il y a quand même du boulot dans l'informatique et je suis sur qu'il y a plein de gens prêt à embaucher un commercial ( à condition que sa réputation ne soit pas pourri par des gens peu scrupuleux et avec beaucoup de réseau, bien sur ).

Et pis sinon, il suffit juste de trouver de refaire la même boite, le code est libre et y a pas de raison que ça se passe mal une deuxiéme fois.

Il y a surtout le fait que les sites comme megaupload et co gagnent de l'argent mais n'en dépensent pas pour faire les films/séries. Sinon en pratique, c'est juste le modèle de la télé, soit tu regardes le programme et tu as des pubs, soit tu payes pour ne pas subir une rareté plus ou moins artificielle ( à savoir " X minutes de visionnage", ou ce genre de chose ).

À comparer avec le modèle canal + ou des chaines chiffrés du cable, et le modèle TF1.

Il n'y a donc rien de novateur

Je suis assez surpris, j'ai pas vu de plantage du tout, et je me sert lourdement de virt-manager. Que l'interface soit à revoir à certains endroits, je suis d'accord, mais c'est aussi pour ça que boxes a été lancé.

Sinon, haproxy fait ça : https://dgl.cx/2010/01/haproxy-ssh-and-ssl-on-same-port

Ce qui rends les bugs mineurs, c'est surtout le fait d'attendre que Canonical fasse le taf, vu que tout est deverminé par les ingés de la société de l'ile de man.

Bah comme mac os x, ça reste proche du libre, sauf quand il y a des trucs plus importants que l'éthique ou les convictions /o

Le vrai souci d'ubuntu est surtout la : http://randall.executiv.es/pig

C'est pas mint.

Dans ce cas, tu peux louer un serveur ( dedibox, lost oasis, gandi, ovh , y a le choix ). Tu as ton ip et le reverse. C'est plus cher que Google, c'est vrai. Ou plutôt, le cout n'est pas aussi caché que celui de Google.

En fait, même avec la db des paquets détruits, le systéme marche. Il faut ensuite juste installé les paquets par dessus les binaires existants.

J'ose croire que Oracle utilise au moins Openoffice et des sparcs. J'ose croire que Microsoft utilise au moins sql server. Et j'ose croire que HP n'utilise pas de l'IBM. Alors oui, si on retire les concurents de microsoft, d'ibm, de SAP et d'oracle, peut etre que ton affirmation est vrai. Et peut être que vue la taille d'une multinationale classique, toutes les combinaisons de technologies ont de fortes chances de se réaliser.

Dans le cas de SAP, il a regardé ce que les clients demandent ?

À noter aussi que club.mandriva.com n'existe pas , et que la page wiki http://wiki.mandriva.com/fr/Club_Mandriva fait par la communauté pour expliquer ( chose qui n'a jamais été très claire chez Mandriva par manque de ressources ) pointe sur des liens invalides. Donc en effet, le club n'existe plus du tout, et en effet, il semble avoir bougé sur club.mandriva.com il y a des années.