Maintenant SELinux est ultra monolithique dans son approche
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
C'est clair - et c'est surement parceque c'est très très
difficile à faire qu'aucune distrib linux ou presque n'active
les ACL ou le mapping de ports par défaut ?
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça. Tout au plus, ça serait pour nfs et rpc, mais il me semble que c'est fait aussi.
Ca fait quand même un peu mal en 2013 d'avoir le serveur
Apache qui se lance en root
et de devoir mettre le stagiaire dans le groupe "www" pour
qu'il puisse modifier les CSS….
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
En ce qui concerne les bases postgresql tu peux faire
quelquechose de très similaire avec des labels multiples sur
FreeBSD en utilisant un partitionnement par tablespace.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ). Et si tu as 1 serveur par personne, tu as quand même une consommation de ressources accrue, genre le cache, etc.
Donc la solution est encore une fois trés largement moins précise, loin de "très similaire".
si ca permet juste à deux machines configurées à
l'identique par un admin unique de dialoguer de façon sécure
c'est moyennement interressant)
encore une fois, c'est ce qui est prévu d'être utilisé par openshift online. Et il y a pas besoin que ça soit configurer à l'identique, juste de suivre les mêmes nomenclatures. Un peu comme dire "ton serveur web écoute sur le port 80 donc le web passe par ce port". Et le fait d'avoir une politique de sécurité unifié n'est pas une contrainte technique mais juste du bon sens. Il est claire que si tu restreint un accés à un type de document, faut le restreindre partout pour que ça soit globalement efficace.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
j'ai comparé les MAC BSD à du SELinux juste pour bien
expliquer que FreeBSD a mieux que les cgroups en stock
donc tu as comparé 2 frameworks de securité pour dire que Freebsd a un truc mieux pour gérer les ressources ? Et tu as comparé un truc granulaire et complet à un truc moins granulaire et qui fait la moitié. J'ai du mal à suivre, il suffit juste de dire "regarde, on remplace les cgroups par les jails pour la partie isolation", et "on remplace les cgroups par rctl pour la partie gestion de groupe", suivi par "du coup, si y a pas systemd, c'est bien parce qu'on pense que ça sert à rien, et qu'il faut pas attendre les BSDs pour avancer sur linux, on se débrouille bien tout seul".
Upstart pourrait le faire, vu que le but est d'avoir des events, et ça me semble logique de relier upstart et juju pour obtenir ça. L'orchestration sur le cloud à ce niveau ne me semble pas déconante, et si ça permet d'unifier et d'avoir qu'une base de code qui fait abstraction de la machine, avec une seule syntaxe de configuration, ça peut donner des choses.
Ensuite, sachant que systemd permet déjà le démarrage à la demande d'un autre système dans un container, faire l'ajout d'un démarrage à la demande d'un système ailleurs, ça peut se faire aussi ( par exemple, j'ai un truc qui monte un tunnel ssh automatiquement, et je pourrais avoir le serveur de l'autre coté à la demande aussi ).
C'est cool, mais c'est non portable, ni openbsd, ni netbsd n'a ça.
Et ça me semble, d'après la page de man, que ça ne gère ni les I/Os, ni le réseau.
De plus, je ne voit pas comment rctl permet de bloquer et tuer tout un groupe de processus. Les jails le font, mais le souci est qu'un jail isole totalement les processus, alors que les cgroups peuvent faire juste du regroupement sans rien d'autre. Et un jail, sauf erreur de ma part, requiert un os complet à part.
Donc bien que ça remplisse fonctionnellement certains besoins des cgroups ( et plus, vu que rctl va plus finement sur les réglages ), ça ne remplace pas les cgroups. ( Le but de suivre et tuer les processus étant pour éviter les races conditions, les cas pénibles, etc, j'ai assez donné d'exemple dans les dernières discussions sur systemd, genre sur bind )
Pour faire court, il y a dans FreeBSD un système qui est
proche de SELinux niveau fonctionnalité, mais nettement plus
utilisable et lisible.
proche, tu veux dire "si on rajoute les trucs manquants" et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
Tout au plus, tu arrives à remplacer un policy MLS de Selinux, avec les limitations que ça ne marche que pour un type plus restreint d'objet ( ie, les process, les fichiers et les interfaces réseaux ) la ou SELinux va plus loin, comme transmettre le lalbel via le réseau, sur une base postgresql, sur les comms dbus, et classifie ça par type de fichier ( socket, répertoire, etc ).
Les comms dbus, ç'est ce qui ressort du travail d'ubuntu pour le confinement des applications bureautiques. Les bases postgresql, c'est pour faire du multitenant pour un hébergeur, que ça soit publique ou interne. Transmettre le label sur le réseau, c'est utilisé par Openshift, pour être sur que ta machine ne parle que avec ton autre machine, ou ce genre de choses.
Donc le système de mac FreeBSD fait déjà des trucs simples , mais ça remplace quand même pas SELInux pour le MLS, loin de la.
Et ce qui intéresse AMHA la plupart des gens, c'est d'une part, de pas configurer la machine ( ie, ne pas passer son temps à faire des sysctl security.mac.portacl.rules=uid:80:tcp:80 pour dire que apache peut faire un bind sur le port 80 ), mais que ça soit fait par défaut. Et d'autre part, pouvoir avoir une granularité plus fine.
Tout les LSMs ou assimilés du monde se vante d'être plus simple que SELinux. Tomoyo, AppArmor, Smack, etc. Mais la simplification n'a pas l'air d'aider les gens à rajouter des politiques pour les softs ou à l'adoption, AppArmor se faisant ramoner la tronche à ce niveau, vu que je pense que c'est ce qui se rapproche le plus de SELinux sur la partie MCS, ie la policy targetted. Ramoner la tronche parce qu'il y a vachement moins de programmes confinés. Ramoner la tronche parce que les dites policys étaient troués, et ça va mettre du temps à tout fermer.
Donc soit c'est pas plus simple que SELinux, soit la complexité vient pas de SELinux mais du système à protéger.
Ce qui veut dire "pas de jeux de tests", "pas de vérification statique des fonctions" et "support assez pauvre des types de données". C'est pas vraiment ce que je qualifie de moderne, au moins au point de vue du développement.
La GPL emmerde ceux qui veulent livrer un Linux avec ZFS.
Bah, la GPL ne dérange pas les gens qui livrent le noyau avec les modules proprios de nvidia ou ce genre de choses :) ( exemple, linux mint )
peut être que le vrai souci, c'est que Nvidia ne va pas te faire de procès alors qu'Oracle ne va pas hésiter, et que vu l'usage de zfs et le public visé, aucune boite ou communauté ne veut prendre le risque ?
Le bouton Activités remplit le même rôle et me paraît
parfaitement adéquat pour du tacile.
ça dépend de la résolution. Sur mon 13", je trouve ça pas terrible quand j'imagine aller au doit sur mon écran, sur un plus grand, ça doit être pire. Pour bien faire, je pense qu'il faut une barre plus grande, même si je reconnait que le geste de tirer le menu depuis le haut ( comme on retrouve sur un télephone android 2.3 ) pour le faire apparaitre est naturel et sans accroche, alors qu'il y a rien de visible..
On peut s'en passer même si c'est moins pratique : activité,
clic droit sur l'application dans le doc.
bah, comme tu dit, c'est moins pratique. Ensuite, justement, le travail en profondeur fait sur les autres applis est prometteur, j'avais pas vu les choses sous cet angle.
Android utilise aussi intensivement le système de recherche
(applications, musique, contacts, etc).
Mais il faut un clavier. C'est pas du tout tactile, vu que pour le moment, caribou se lance pas automatiquement quand il faut taper un truc. Ensuite, c'est aussi parce que le système de recherche est un paradigme qu'on estime connu des gens que Gnome shell s'appuie dessus, afin d'être plus facile à utiliser par des gens qui ont découvert l'informatique à travers Android.
Reste le problème de la taille, mais je serais tout de même
très curieux de tester GNOME 3 sur une tablette.
sur un pc avec écran tactile de bureau, ça avait l'air de mieux se débrouiller que win 8 ( à mon sens ), mais c'était pas nonn plus super. Ensuite, c'était y a 1 ou 2 versions de gnome, et en 5 minutes. Donc rien de très concluant.
J'attends encore de voir quelqu'un me dire "je ne contribue pas à ça, c'est sous GPL". Pour le moment, je vois surtout des gens qui s'estiment rebelles de dire "je fait du BSD, je pense qu'il faut abolire les contraintes", ce qui est assez souvent du même niveau que le libertarien moyen tel que j'en croise parfois au boulot, qui pousse à l'absurde la position de non inférence du reste du groupe.
Quelque part, ils ont pas tort, si ils veulent pas se fatiguer à réfléchir aux aspects autres que le code, c'est leur choix. Je fait pareil quand j'achète des chaussures, je me dit pas "tiens, c'est fait par des ouvriers sous payés". Je fait pareil quand je prends à manger, je me dit pas "c'est fait en dehors de mes normes cultuerelles, que ça soit halal, kasher ou juste les directives de la PETA". Donc je comprends leur position, faut que ça soit bien clair, et je fait le même genre de choix sans arrêt. La différence etant bien sur que je vais pas faire de journal linuxfr pour dire "j'ai mangé un steack à midi, et je trouve que les végétariens sont tous des cons hypocrites"
Et j'attends encore de voir quelqu'un qui me dit "je refuse de contribuer sur ça parce que c'est GPL". Car si la question est de savoir combien de contributions sont perdus, c'est ça qu'il faut regarder.
Pour le moment, les seuls exemples individuels que j'ai ne sont généralisable ( vu qu'en général, c'est après un débat houleux pour me prouver que j'ai tort via leur propre exemple, ce qui est mignon mais statistiquement inutile ). Je parle pas de gens faisant de la BSD, je parle de gens refusant la GPL, ou de contribuer à du code GPL. Je trouve des gens qui refusent la cession de copyright, que ça soit la FSF ou à Canonical, mais en dehors ça, la plupart des individus s'en foutent.
Par contre, ce qu'on trouve c'est des boites qui disent ne pas vouloir pour 2 raisons :
- du FUD, du style de celui dans le journal.
- vouloir faire des trucs qu'une partie des visiteurs de ce site vont trouver éthiquement douteux.
Par exemple, on retrouve
- Netasq, qui utilise freebsd car ça permet de faire du proprio pour garder son avance
- Apple, pareil et en plus les brevets et les DRMs
- Google pour Android, parce que ça permet aux constructeurs de faire du proprio,
D'ailleurs, de manière très amusante, le dernier point montre que finalement, les constructeurs n'ont pas si peur que ça de la GPL, vu que le noyau est sous GPL v2 et fait partie d'Android :
- ils font des patchs sur le kernel qu'ils arrivent pas à pousser upstream ( cf les divers trucs de 3d en userspace )
- ils respectent pas la licence
- ils se mangent des procès
- ils font du proprio, via justement les divers trucs en userspace
Mais surtout, ils continuent. Donc l'excuse de "faut faire de la BSD/MIT/X11 sinon les constructeurs vont pas travailler dessus" me parait des plus faibles au vue de l'exemple du kernel. Et y a pas que le kernel, je voit pas grand monde du coté des constructeurs qui ralent à l'idée de distribuer du code sous LGPL tel qu'on trouve dans Chrome.
Ensuite, peut être que je loupe quelque chose dans le tas.
L'argument que la GPL est compliqué ? Bullshit complet, par rapport à la complication de faire du multimedia ( et de savoir quoi et ou négocier pour les différents codecs, si tu veux espérer toucher en dehors de l'EU ) ou n'importe quoi d'autre comme un contrat, etc. Et au vue de la prolifération des EULAs toute différentes sur tout les softs proprios, ou tout les services webs, qui changent régulièrement, l'excuse ne tient pas la route, ni pour les boites, ni pour les particuliers. C'est même pas le fait de faire appliquer la GPL qui pose souci, vu que quand Twitter ou Facebook change les conditions de service, ça fait le tour du web, et pourtant, les gens continuent à s'appuyer dessus.
Et pourtant, il y a plein de raisons qui font que je ferais du code sous BSD. Le fait de vouloir faire un standard, par exemple. Ton implémentation de référence doit être sous une licence des plus permissive pour que ton standard soit adopté. Le fait de vouloir être utiliser à tout prix pour d'autres raisons ( exemple, openbsd, qui vise à augmenter la sécurité de l'internet ).
Donc voila, je parlerais des contributions perdues à cause de la GPL quand ça ne sera pas "j'ai pas pu faire un procès à mon concurrent pour violation de brevets à cause de la GPL v3" ou "la GPL va me forcer à manger mon premier né cuit à la broche et je suis végétarien". Ou "je suis capable de coder un b-tree en assembleur, mais comprendre la GPL est trop compliqué pour moi car je parle pas assez bien anglais".
C'est marrant que tu cites Apple, car Apple justement ne contribue plus à gcc, on suppose à cause de la gpl v3. En effet, ça poserais trop de souci vis à vis de leur usage offensif des brevets. De la même façon, Apple ne contribue plus à samba et ne l'utilise plus. Et ne fournit pas son implémentation non plus, que je sache.
Faut bien se souvenir que chaque fois qu'on file de l'argent à Apple, on file aussi de quoi alimenter les procès autour des brevets logiciels. Et plus on alimente ce milieu, plus il y a d'autres boites qui y vont comme par exemple, Oracle, et le fait que le patron d'Oracle soit un ami personnel de l'ancien patron d'Apple ( ami du style "Larry a été photographe officiel au mariage de Steve" ) est un lien troublant sur l'usage offensif qu'ils font des brevets. Je me demande même jusqu'à quel point l'attaque de Google par oracle a été influencé par Steve Jobs, qui pensait que Google était des voleurs : http://www.dailymail.co.uk/sciencetech/article-2051793/Steve-Jobs-vowed-destroy-iPhone-rival-Android-thermonuclear-war.html
Mais bien sur, les histoires de GPL sur la BSD, si tu sort que les exemples de softs qui ont connus car il y a eu des contributions, tu peut faire croire qu'il y a pas d'incidence.
Mais la liberté de la GPL n'est pas tant pour les éditeurs et codeurs que pour les utilisateurs. Tu te souviens de la contribution de Microsoft à la pile TCP/IP y a 20 ans ? Non, parce qu'elle n'existe pas.
D'après certaines sources, Microsoft a racheté la pile TCP/IP d'une autre boite du nom de Spider System ( https://www.kuro5hin.org/story/2001/6/19/05641/7357 ), le temps d'écrire sa pile pour Windows. Et toutes les modifs fait par l'autre boite ou Microsoft sont restés proprios. Voir pire encore, comme la pile de Spider System a divergé, ils ont du refaire plein de travail pour rien, ce qui a aboutit à avoir une pile moins performante pendant des années pour un bon paquet de machine sur le réseau naissant.
Dans l'affaire, je doute fort que les utilisateurs soient gagnants, et en ayant moins de correctif de bug, je doute fort que les développeurs upstreams soient gagnant aussi.
Donc oui, les projets sous BSD survivent sans souci. C'est juste qu'ils perdent sans doute en contribution sur le long terme.
Tu as le choix, tu peux faire le don de la liberté à tes utilisateurs, ou faire le don de ta liberté à des boites comme Apple. Je comprends que ça soit un domaine compliqué,et que par exemple, plein de gens n'arrivent pas à concilier l'admiration pour un Mac et en même temps le coté puant et privateur de l'ensemble, et que finalement, la solution soit d'ignorer sous le tapis les problèmes en se disant, ça n'existe pas. Car à partir du moment ou tu reconnais que les brevets logiciels sont un souci, que tu gardes à l'esprit que Apple en fait un usage immodéré, tu as du mal à garder ton portable sous OS X et à te dire "je fait quelque chose contre ça".
Ça s'appelle la résistance au changement. Et c'est pour éviter
ça que les formations sont nécessaires.
Mais il a raison aussi dans le sens ou c'est pas parce que c'est indispensable que ça va être mis en place.
Ceci dit, j'ai régulièrement des utilisateurs qui se plaignent de libreoffice, et j'ai pas le sentiment que ça soit uniquement de la résistance au changement, y aussi des vrais bugs ou des vrais problèmes. Par exemple, pour la gestion de fichier énormes sous un tableur, calc a l'air de pas tenir autant la charge que excel ( avec énorme étant "plus de 100 Mo, avec des formules de partout" ).
Ce qui du coup fait que la formation, qui est sans doute à plus que 60€, est bien plus couteuse que la licence.
Donc la, on voit que le pouvoir politique a sans doute fait le bon choix ( indépendance, notamment pour les questions de langues ) mais en tentant de faire passer ça pour une économie énorme alors que je pense que c'est pas si énorme que ça.
Après, je voulais juste faire rapidement quelque chose, et
niveau hébergement gratuit, rapidement accessible et propre, je
ne voyais que Google AppEngine (tant que les quota ne sont pas
explosés).
Tu as openshift ( https://www.openshift.com/ ), et en plus, le code du service est libre, avec le point bonus que ça tourne ailleurs que sur l'infra d'openshift, vu que ça utilise des piles logiciels standards.
Sinon, sans vouloir faire de mauvais esprit, si github avait été libre tu aurais pu coder un patch directement sur la page ( c'est juste pour enfoncer un peu le clou, c'est mesquin, mais je pense qu'il faut quand même bien voir que le libre peut aussi apporter des choses pour les services "webs" )
Non, gnome 3 ( ou plutôt gnome-shell n'est pas adapté à un portable ou à un téléphone, et n'a pas été présenté comme l'étant pour le moment. J'ai vu personnelement des devs gnome dire clairement le contraire, et expliquer pourquoi ça ne marche pas. Donc forcément, si c'est pas prévu pour, ça va pas marcher.
Je sais pas d'ou vient cette idée ( sans doute un mec sur ce succédanée de bar PMU que sont les forums de phoronix ), mais visiblement, les gens ne pensent pas vraiment à ce qu'ils disent.
Par exemple, l'aperçu à droite des fenêtres, c'est pas du tout adapté à une résolution réduite. Le fait d'utiliser de façon intensive le clavier ( touche windows pour l'apercu, 2 raccourcis différents pour switcher d'application, système de recherche dans l'apercu ) n'est pas adapté à un appareil sans clavier. Le fait d'avoir besoin besoin des 2 boutons de la souris ( menu dans le launcher à gauche ) ne marche pas bien quand tu as pas de souris.
Tout ça, c'est des choses qui ont été rajoutés à Gnome-shell et ce sont autant de choses qui ne vont pas sur les tablettes classiques, et encore moins les portables.
Tout au plus, du travail est en cours pour offrir un meilleur support des écrans tactiles, mais il y a une énorme différence entre un écran tactile de taille correcte ( genre 12" au minimum, 24, 30 au max ), et un portable/tablette, ou ça va de 4" à 10" ( grosso merdo ). et le travail est en cours car c'est ce que Microsoft demande aux fabricants pour Windows 8.
Supporter les tablettes est un combat perdu d'avance pour le moment au vue de l’écosystème proprio moisi autour d'Android, ou tu peux te brosser pour avoir les specs. Les pilotes 3d moisis, on a déjà donné assez avec Nvidia et ATI sur le monde pc traditionnel, si en plus, tu doit rajouter arm et les constructeurs obsédés par le Time to market au détriment de la qualité logiciel, du respect des licenses et autre trucs qui ralentissent autant, tu tombes sur un gouffre financier si tu veux un produit qui marche.
Microsoft a les moyens. Canonical a pas les moyens, mais ils ont la témérité. Gnome non. Nokia avait tenté, ils ont refait une interface. Tout comme Openmoko avait tenté de refaire une interface basé sur e17, ou kde avec plasma. En fait, la aussi, ça marche pas terrible, mais bon, ça, on en parle pas.
Person, je doit reconnaitre que ça me choque un peu de voir un atelier pour apprendre à se servir d'un soft proprio ( virtu vmware, voir virtualbox si tu veux que le truc soit complet ) alors que des alternatives libres existent ( genre kvm et les milliers d'interfaces par dessus, d'openstack à ovirt, archipel, etc, etc ).
Mais bon, comme je suis pas dans les personnes visés ( ou alors plus du coté des formateurs ), je suppose que ça va pas influencer grand chose.
Et dans les versions récentes, tu as les dropin folders. Tu fait un fichier foo.unit.d dans /etc/systemd/system, tu rajoutes tes bouts de config, et il fait l'include tout seul.
C'est encore plus propre pour la gestion par un rpm ou puppet.
Alors, le ssh, ça pu/du changer, car j'ai du aider un pote à faire du ssh depuis sa belle famille en chine vers le serveur de sa boite pour bosser. Et en effet, je voyait pas les paquets arriver, et c'était pas un souci de DNS. Mais c'était il y a 5 ans.
De manière très amusante, mon employeur a un certain nombre de bureaux autour du monde, un des rares à avoir une connexion direct ( ie, pas via un lien dédié ), c'est le bureau de Chine. Je sais pas si c'est des raisons techniques ou politiques ( ou les 2, ou un prix trop grand due à un marché moins concurentiel, ou autre ), sachant que les autres bureaux, c'est plus "le batiment est classé donc on peut pas faire de travaux pour le lien MPLS".
Pourtant on se demande bien ce qu'on ferait sans les grosses
boites. S'il faut se battre contre tous les brevets déposés,
elles sont une manne non négligeable d'idées, de main d'œuvre
(combien d'entreprises travaillent aussi pour le libre ?) et de
pognon.
Bien sur, mais quel rapport avec le fait de laisser les boites reprendre sans contribuer en retour ?
Regardons le kernel Linux, qui a beaucoup de retour de grosses boites et qui est sous GPL v2. Ou gcc.
Et des projets sous BSD ( ou assimilés, genre Apache/MIT ) ont aussi des retours.
Donc on peut difficilement dire qu'il y a une corrélation, ne serais que parce que maintenir un fork de code conséquent est couteux en temps, au delà des soucis de licence.
Google fait ça aussi avec Android (si tu veux un peu d'avance
sur les autres, tu te plies aux règles) et c'est un projet qui
marche plutôt pas mal ;-) tout en restant libre au final.
Ça dépend de ton critère pour "qui marche". D'un point de vue de l'input de la communauté sur le projet, je pense pas que ça soit flagrant, ça reste chasse gardé de Google. Ensuite, je pense que Google fait ça avec android juste parce qu'ils ont pas le choix. Si tu va par la, Apple montre rien et ça marche aussi pour eux. Donc on peut dire que "avoir des parts de marché" n'est pas dépendant dans le mobile de "donner le code source avec du retard".
Ca change de d'habitude pour 99% des projets?
Y a pas mal de projet qui font de la relecture, genre tout les gros. Y a aussi pas mal de gens qui font de la relecture pour trouver des failles de sécurité, et donc ton chiffre de 99% est à mon sens trompeur et incorrect. Il y a des boites ( par exemple RH pour RHEL, Canonical pour la partie main ) qui font de l'audit avant d'intégrer ou de proposer quoi que ce soit. Mais oui, ça change rien si personne ne bosse avec toi d'habitude, et si tu n'as finalement aucune communauté de développeurs autour de ton produit, soit parce qu'il s'y prête pas, soit parce que le caractère du codeur ne s'y prête pas.
Juste un bandeau "fonctionnalité dans la version pour
sponsors, libre le X".
Je parle de la production, pas de l'usage. IE, traduire ou écrire de la documentation sans avoir accès au logiciel est un peu plus dur, et ça aboutit au final à avoir quelque chose de moins bonne qualité. Donc il faut prendre en compte le cout de faire soit même la traduction ou la documentation, ou de donner accès à la version aux bénévoles qui vont le faire dans le cadre du projet libre, ou se satisfaire d'une qualité inférieur ou la traduction est pas relu en situation, tout comme la doc.
Et je rajouterais le fait de faire des tests, des betas, etc. Il me semble évident que le nombre de sponsors testeurs est inférieur ou égal à la communauté entière, vu que les dits sponsors font parti de la communauté par définition. Encore une fois, on aboutit à un truc de moins bonne qualité, ou quelque chose qui requiert plus de travail, si la communauté est fonctionnel ( encore une fois, si elle n'existe pas, ça ne change rien ).
C'est pas comme si personne ne maintenait des branches à part > (libres mais refusées upstream, ou non libre etc…)
Rien de neuf au niveau logistique.
Justement, c'est parce qu'on sait que maintenir des branches est un cout que les gens qui ont un peu plus de bouteille poussent les choses upstream. On a vu ce que ça donne justement avec android et le kernel, et qu'au bout d'un temps, avoir tes branches sur un projet dynamique est lourd.
Au jour le jour, avoir 2 branches de dev ( la branche dispo pour tous, et la branche pour le soft sponsorisé ) fait que tu dois faire 2 fois plus de tests, que tu doit backporter les fonctionnalités et les bugfixes de l'une à l'autre. Ou que tu fait tout dans la branche sponsor, ce qui ralentit fortement les contributions externes ( chose que tu n'as peut être pas sur le projet à la base, ou dont tu te fout, mais du coup, ça me semble aller à l'encontre du développement collaboratif ).
Ensuite, ça dépend grandement de la durée du développement, mais comme tu rajoutes quelques semaines de bloquage de façon artificiellement, ça fait toujours ce temps ou tu doit faire des rebases, etc.
Pourquoi "précariser les codeurs" avec ça?
Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI. Si ensuite, toi, ça te va, ça veut pas dire que ça va pour tous.
Comme dans tout contrat et/ou comment dans tout financement
participatif.
Donc tu payes une pénalité, comme dans un contrat bien fait en faveur pour le client, ou le client paye sans avoir de garantie ( comme dans un contrat moins en sa faveur ) ? Ou tu impliques les avocats, comme dans un contrat classique ?
ça ne m’intéresse pas moi le principal codeur de faire sur mon
temps libre et je ne suis pas ton esclave, mais si tu payes je
veux bien m'y mettre (ou un autre si tu veux) à travers un
sponsoring, si tu peux pas seul un financement participatif
est possible.
J'ai du mal à suivre en quoi ça réponds à la question "combien de temps avant que le codeur refuses quelqu'un qui va faire ça sur son temps libre alors qu'il pourrais avoir de l'argent pour le faire ?"
Des exemples de ce genre, tu en trouve autour des communautés de logiciel open-core.
Ensuite, je sais pas pour toi, mais moi, si y a un truc que j'ai pas envie de faire, c'est rarement rajouter de l'argent qui va me le faire faire, sauf si je suis vraiment à l'arrache ou si il y a vraiment beaucoup d'argent. J'ai pas encore une estime de moi si basse que je vais me vendre à pas cher pour coder un truc que je veux pas coder et en plus m'infliger de faire de la paperasse pour ça. Et pas non plus un compte en banque tellement vide que je n'ai pas le choix.
Mais bon, si ça marche pour toi et plein d'autres, tant mieux.
Je cherche pas à te convaincre du contraire, ça serait totalement idiot et ça m'apporterais rien.
Mais je reste persuadé que ça n'est pas une solution très pérenne pour les systèmes libre tel qu'ils sont aujourd'hui.
Je voit bien par contre que c'est une solution pour les développeurs propriétaires :
- moins de piratage, car au final, les gens qui veulent pas payer vont prendre la version libre
- un minimum d'implication de la communauté pour la traduction/documentation/portage, etc, donc des économies, et une qualité supérieure à un logiciel propriétaire équivalent ( vu qu'il y a rarement des traductions pour les plus petits, et souvent des horreurs pour que ça tourne sans le code source sur divers distributions et OS )
- un financement, car filer le soft gratos, ça paye rarement le loyer
- la possibilité de dire "je fait du libre (en partie )", ce qui est quand même plus glorieux et meilleur pour l'ego que "j'ai fait un shareware", du moins de nos jours sur un CV
- un argument de vente auprès des utilisateurs, histoire de dire "c'est libre, c'est bien (tm)", et de surfer sur la vague ( tout comme le crowdfunding ).
ça ne serait plus du logiciel libre du coup. Tu n'aurais pu par exemple l'intégration dans les distributions, tu n'aurais pas la relecture par d'autres codeurs de la communauté, les gens avec la feature en plus auraient moins de chance d'avoir des réponses sur le forum, et les documentations et traductions devraient être geré à part.
D'un point de vue logistique, ça semble une mauvaise idée.
Quand à l'idée de base, ça reste quand même risqué. Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ? Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?
Comment tu repartis ça dans le cas d'un travail en équipe ?
Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.
C'est pas étonnant. Avoir du matériel libre pose des contraintes que je pense Canonical n'a pas le temps de prendre en compte. par exemple, de la négociation avec les fabricants, ce qui reviens à payer plus cher, ou à sortir plus tard. Et le temps et l'argent ne sont pas des ressources qu'ils ont en abondance.
[^] # Re: Tout va bien, je t'assure
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 4.
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça. Tout au plus, ça serait pour nfs et rpc, mais il me semble que c'est fait aussi.
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ). Et si tu as 1 serveur par personne, tu as quand même une consommation de ressources accrue, genre le cache, etc.
D'autre part, sepostgresql fait plus que ça comme on peut voir sur les objets :
http://selinuxproject.org/page/NB_SQL_9.0
Un tablespace postgresql va pas stocker une colonne, c'est la table, l'index ou la db.
http://www.postgresql.org/docs/9.2/static/sql-createtablespace.html
Donc la solution est encore une fois trés largement moins précise, loin de "très similaire".
encore une fois, c'est ce qui est prévu d'être utilisé par openshift online. Et il y a pas besoin que ça soit configurer à l'identique, juste de suivre les mêmes nomenclatures. Un peu comme dire "ton serveur web écoute sur le port 80 donc le web passe par ce port". Et le fait d'avoir une politique de sécurité unifié n'est pas une contrainte technique mais juste du bon sens. Il est claire que si tu restreint un accés à un type de document, faut le restreindre partout pour que ça soit globalement efficace.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
donc tu as comparé 2 frameworks de securité pour dire que Freebsd a un truc mieux pour gérer les ressources ? Et tu as comparé un truc granulaire et complet à un truc moins granulaire et qui fait la moitié. J'ai du mal à suivre, il suffit juste de dire "regarde, on remplace les cgroups par les jails pour la partie isolation", et "on remplace les cgroups par rctl pour la partie gestion de groupe", suivi par "du coup, si y a pas systemd, c'est bien parce qu'on pense que ça sert à rien, et qu'il faut pas attendre les BSDs pour avancer sur linux, on se débrouille bien tout seul".
[^] # Re: Est ce que la solution...
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 3.
Le cgroups freezer :
https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt
non, c'est pas un perso de dbz :)
[^] # Re: Bah...
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 1.
Upstart pourrait le faire, vu que le but est d'avoir des events, et ça me semble logique de relier upstart et juju pour obtenir ça. L'orchestration sur le cloud à ce niveau ne me semble pas déconante, et si ça permet d'unifier et d'avoir qu'une base de code qui fait abstraction de la machine, avec une seule syntaxe de configuration, ça peut donner des choses.
Ensuite, sachant que systemd permet déjà le démarrage à la demande d'un autre système dans un container, faire l'ajout d'un démarrage à la demande d'un système ailleurs, ça peut se faire aussi ( par exemple, j'ai un truc qui monte un tunnel ssh automatiquement, et je pourrais avoir le serveur de l'autre coté à la demande aussi ).
[^] # Re: Est ce que la solution...
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 3.
C'est cool, mais c'est non portable, ni openbsd, ni netbsd n'a ça.
Et ça me semble, d'après la page de man, que ça ne gère ni les I/Os, ni le réseau.
De plus, je ne voit pas comment rctl permet de bloquer et tuer tout un groupe de processus. Les jails le font, mais le souci est qu'un jail isole totalement les processus, alors que les cgroups peuvent faire juste du regroupement sans rien d'autre. Et un jail, sauf erreur de ma part, requiert un os complet à part.
Donc bien que ça remplisse fonctionnellement certains besoins des cgroups ( et plus, vu que rctl va plus finement sur les réglages ), ça ne remplace pas les cgroups. ( Le but de suivre et tuer les processus étant pour éviter les races conditions, les cas pénibles, etc, j'ai assez donné d'exemple dans les dernières discussions sur systemd, genre sur bind )
[^] # Re: Tout va bien, je t'assure
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 10.
proche, tu veux dire "si on rajoute les trucs manquants" et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
Le systéme de MAC décrit sur le handbook Freebsd ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html ) ne permet pas de restreindre par type d'operation.
Tout au plus, tu arrives à remplacer un policy MLS de Selinux, avec les limitations que ça ne marche que pour un type plus restreint d'objet ( ie, les process, les fichiers et les interfaces réseaux ) la ou SELinux va plus loin, comme transmettre le lalbel via le réseau, sur une base postgresql, sur les comms dbus, et classifie ça par type de fichier ( socket, répertoire, etc ).
Les comms dbus, ç'est ce qui ressort du travail d'ubuntu pour le confinement des applications bureautiques. Les bases postgresql, c'est pour faire du multitenant pour un hébergeur, que ça soit publique ou interne. Transmettre le label sur le réseau, c'est utilisé par Openshift, pour être sur que ta machine ne parle que avec ton autre machine, ou ce genre de choses.
Donc le système de mac FreeBSD fait déjà des trucs simples , mais ça remplace quand même pas SELInux pour le MLS, loin de la.
Et ce qui intéresse AMHA la plupart des gens, c'est d'une part, de pas configurer la machine ( ie, ne pas passer son temps à faire des sysctl security.mac.portacl.rules=uid:80:tcp:80 pour dire que apache peut faire un bind sur le port 80 ), mais que ça soit fait par défaut. Et d'autre part, pouvoir avoir une granularité plus fine.
Tout les LSMs ou assimilés du monde se vante d'être plus simple que SELinux. Tomoyo, AppArmor, Smack, etc. Mais la simplification n'a pas l'air d'aider les gens à rajouter des politiques pour les softs ou à l'adoption, AppArmor se faisant ramoner la tronche à ce niveau, vu que je pense que c'est ce qui se rapproche le plus de SELinux sur la partie MCS, ie la policy targetted. Ramoner la tronche parce qu'il y a vachement moins de programmes confinés. Ramoner la tronche parce que les dites policys étaient troués, et ça va mettre du temps à tout fermer.
Donc soit c'est pas plus simple que SELinux, soit la complexité vient pas de SELinux mais du système à protéger.
[^] # Re: C'était déjà le cas.
Posté par Misc (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 6.
Openrc reste en bash.
Ce qui veut dire "pas de jeux de tests", "pas de vérification statique des fonctions" et "support assez pauvre des types de données". C'est pas vraiment ce que je qualifie de moderne, au moins au point de vue du développement.
[^] # Re: gpl ... seulement si tu veux
Posté par Misc (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 2.
Bah, la GPL ne dérange pas les gens qui livrent le noyau avec les modules proprios de nvidia ou ce genre de choses :) ( exemple, linux mint )
peut être que le vrai souci, c'est que Nvidia ne va pas te faire de procès alors qu'Oracle ne va pas hésiter, et que vu l'usage de zfs et le public visé, aucune boite ou communauté ne veut prendre le risque ?
[^] # Re: Contrainte
Posté par Misc (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 4.
Facile, suffit de tout requalifier ça comme fonctionnalité non documenté dans la version courante.
[^] # Re: Portage facilité ?
Posté par Misc (site web personnel) . En réponse au journal La popularité d'Androïd bénéficiera t-elle à Linux ?. Évalué à 2.
ça dépend de la résolution. Sur mon 13", je trouve ça pas terrible quand j'imagine aller au doit sur mon écran, sur un plus grand, ça doit être pire. Pour bien faire, je pense qu'il faut une barre plus grande, même si je reconnait que le geste de tirer le menu depuis le haut ( comme on retrouve sur un télephone android 2.3 ) pour le faire apparaitre est naturel et sans accroche, alors qu'il y a rien de visible..
bah, comme tu dit, c'est moins pratique. Ensuite, justement, le travail en profondeur fait sur les autres applis est prometteur, j'avais pas vu les choses sous cet angle.
Mais il faut un clavier. C'est pas du tout tactile, vu que pour le moment, caribou se lance pas automatiquement quand il faut taper un truc. Ensuite, c'est aussi parce que le système de recherche est un paradigme qu'on estime connu des gens que Gnome shell s'appuie dessus, afin d'être plus facile à utiliser par des gens qui ont découvert l'informatique à travers Android.
sur un pc avec écran tactile de bureau, ça avait l'air de mieux se débrouiller que win 8 ( à mon sens ), mais c'était pas nonn plus super. Ensuite, c'était y a 1 ou 2 versions de gnome, et en 5 minutes. Donc rien de très concluant.
[^] # Re: Et ça marche aussi en pratique
Posté par Misc (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 10.
J'attends encore de voir quelqu'un me dire "je ne contribue pas à ça, c'est sous GPL". Pour le moment, je vois surtout des gens qui s'estiment rebelles de dire "je fait du BSD, je pense qu'il faut abolire les contraintes", ce qui est assez souvent du même niveau que le libertarien moyen tel que j'en croise parfois au boulot, qui pousse à l'absurde la position de non inférence du reste du groupe.
Quelque part, ils ont pas tort, si ils veulent pas se fatiguer à réfléchir aux aspects autres que le code, c'est leur choix. Je fait pareil quand j'achète des chaussures, je me dit pas "tiens, c'est fait par des ouvriers sous payés". Je fait pareil quand je prends à manger, je me dit pas "c'est fait en dehors de mes normes cultuerelles, que ça soit halal, kasher ou juste les directives de la PETA". Donc je comprends leur position, faut que ça soit bien clair, et je fait le même genre de choix sans arrêt. La différence etant bien sur que je vais pas faire de journal linuxfr pour dire "j'ai mangé un steack à midi, et je trouve que les végétariens sont tous des cons hypocrites"
Et j'attends encore de voir quelqu'un qui me dit "je refuse de contribuer sur ça parce que c'est GPL". Car si la question est de savoir combien de contributions sont perdus, c'est ça qu'il faut regarder.
Pour le moment, les seuls exemples individuels que j'ai ne sont généralisable ( vu qu'en général, c'est après un débat houleux pour me prouver que j'ai tort via leur propre exemple, ce qui est mignon mais statistiquement inutile ). Je parle pas de gens faisant de la BSD, je parle de gens refusant la GPL, ou de contribuer à du code GPL. Je trouve des gens qui refusent la cession de copyright, que ça soit la FSF ou à Canonical, mais en dehors ça, la plupart des individus s'en foutent.
Par contre, ce qu'on trouve c'est des boites qui disent ne pas vouloir pour 2 raisons :
- du FUD, du style de celui dans le journal.
- vouloir faire des trucs qu'une partie des visiteurs de ce site vont trouver éthiquement douteux.
Par exemple, on retrouve
- Netasq, qui utilise freebsd car ça permet de faire du proprio pour garder son avance
- Apple, pareil et en plus les brevets et les DRMs
- Google pour Android, parce que ça permet aux constructeurs de faire du proprio,
D'ailleurs, de manière très amusante, le dernier point montre que finalement, les constructeurs n'ont pas si peur que ça de la GPL, vu que le noyau est sous GPL v2 et fait partie d'Android :
- ils font des patchs sur le kernel qu'ils arrivent pas à pousser upstream ( cf les divers trucs de 3d en userspace )
- ils respectent pas la licence
- ils se mangent des procès
- ils font du proprio, via justement les divers trucs en userspace
Mais surtout, ils continuent. Donc l'excuse de "faut faire de la BSD/MIT/X11 sinon les constructeurs vont pas travailler dessus" me parait des plus faibles au vue de l'exemple du kernel. Et y a pas que le kernel, je voit pas grand monde du coté des constructeurs qui ralent à l'idée de distribuer du code sous LGPL tel qu'on trouve dans Chrome.
Ensuite, peut être que je loupe quelque chose dans le tas.
L'argument que la GPL est compliqué ? Bullshit complet, par rapport à la complication de faire du multimedia ( et de savoir quoi et ou négocier pour les différents codecs, si tu veux espérer toucher en dehors de l'EU ) ou n'importe quoi d'autre comme un contrat, etc. Et au vue de la prolifération des EULAs toute différentes sur tout les softs proprios, ou tout les services webs, qui changent régulièrement, l'excuse ne tient pas la route, ni pour les boites, ni pour les particuliers. C'est même pas le fait de faire appliquer la GPL qui pose souci, vu que quand Twitter ou Facebook change les conditions de service, ça fait le tour du web, et pourtant, les gens continuent à s'appuyer dessus.
Et pourtant, il y a plein de raisons qui font que je ferais du code sous BSD. Le fait de vouloir faire un standard, par exemple. Ton implémentation de référence doit être sous une licence des plus permissive pour que ton standard soit adopté. Le fait de vouloir être utiliser à tout prix pour d'autres raisons ( exemple, openbsd, qui vise à augmenter la sécurité de l'internet ).
Donc voila, je parlerais des contributions perdues à cause de la GPL quand ça ne sera pas "j'ai pas pu faire un procès à mon concurrent pour violation de brevets à cause de la GPL v3" ou "la GPL va me forcer à manger mon premier né cuit à la broche et je suis végétarien". Ou "je suis capable de coder un b-tree en assembleur, mais comprendre la GPL est trop compliqué pour moi car je parle pas assez bien anglais".
[^] # Re: Et ça marche aussi en pratique
Posté par Misc (site web personnel) . En réponse au journal Licences logicielles : Je t'offre une bière, mais tu dois m'en offrir une après !. Évalué à 10.
C'est marrant que tu cites Apple, car Apple justement ne contribue plus à gcc, on suppose à cause de la gpl v3. En effet, ça poserais trop de souci vis à vis de leur usage offensif des brevets. De la même façon, Apple ne contribue plus à samba et ne l'utilise plus. Et ne fournit pas son implémentation non plus, que je sache.
Faut bien se souvenir que chaque fois qu'on file de l'argent à Apple, on file aussi de quoi alimenter les procès autour des brevets logiciels. Et plus on alimente ce milieu, plus il y a d'autres boites qui y vont comme par exemple, Oracle, et le fait que le patron d'Oracle soit un ami personnel de l'ancien patron d'Apple ( ami du style "Larry a été photographe officiel au mariage de Steve" ) est un lien troublant sur l'usage offensif qu'ils font des brevets. Je me demande même jusqu'à quel point l'attaque de Google par oracle a été influencé par Steve Jobs, qui pensait que Google était des voleurs :
http://www.dailymail.co.uk/sciencetech/article-2051793/Steve-Jobs-vowed-destroy-iPhone-rival-Android-thermonuclear-war.html
Mais bien sur, les histoires de GPL sur la BSD, si tu sort que les exemples de softs qui ont connus car il y a eu des contributions, tu peut faire croire qu'il y a pas d'incidence.
Mais la liberté de la GPL n'est pas tant pour les éditeurs et codeurs que pour les utilisateurs. Tu te souviens de la contribution de Microsoft à la pile TCP/IP y a 20 ans ? Non, parce qu'elle n'existe pas.
D'après certaines sources, Microsoft a racheté la pile TCP/IP d'une autre boite du nom de Spider System ( https://www.kuro5hin.org/story/2001/6/19/05641/7357 ), le temps d'écrire sa pile pour Windows. Et toutes les modifs fait par l'autre boite ou Microsoft sont restés proprios. Voir pire encore, comme la pile de Spider System a divergé, ils ont du refaire plein de travail pour rien, ce qui a aboutit à avoir une pile moins performante pendant des années pour un bon paquet de machine sur le réseau naissant.
Dans l'affaire, je doute fort que les utilisateurs soient gagnants, et en ayant moins de correctif de bug, je doute fort que les développeurs upstreams soient gagnant aussi.
Donc oui, les projets sous BSD survivent sans souci. C'est juste qu'ils perdent sans doute en contribution sur le long terme.
Tu as le choix, tu peux faire le don de la liberté à tes utilisateurs, ou faire le don de ta liberté à des boites comme Apple. Je comprends que ça soit un domaine compliqué,et que par exemple, plein de gens n'arrivent pas à concilier l'admiration pour un Mac et en même temps le coté puant et privateur de l'ensemble, et que finalement, la solution soit d'ignorer sous le tapis les problèmes en se disant, ça n'existe pas. Car à partir du moment ou tu reconnais que les brevets logiciels sont un souci, que tu gardes à l'esprit que Apple en fait un usage immodéré, tu as du mal à garder ton portable sous OS X et à te dire "je fait quelque chose contre ça".
[^] # Re: ça fait pas cher du poste
Posté par Misc (site web personnel) . En réponse au journal La Communauté valencienne passe à LibreOffice. Évalué à 2.
Mais il a raison aussi dans le sens ou c'est pas parce que c'est indispensable que ça va être mis en place.
Ceci dit, j'ai régulièrement des utilisateurs qui se plaignent de libreoffice, et j'ai pas le sentiment que ça soit uniquement de la résistance au changement, y aussi des vrais bugs ou des vrais problèmes. Par exemple, pour la gestion de fichier énormes sous un tableur, calc a l'air de pas tenir autant la charge que excel ( avec énorme étant "plus de 100 Mo, avec des formules de partout" ).
[^] # Re: ça fait pas cher du poste
Posté par Misc (site web personnel) . En réponse au journal La Communauté valencienne passe à LibreOffice. Évalué à 1.
Ce qui du coup fait que la formation, qui est sans doute à plus que 60€, est bien plus couteuse que la licence.
Donc la, on voit que le pouvoir politique a sans doute fait le bon choix ( indépendance, notamment pour les questions de langues ) mais en tentant de faire passer ça pour une économie énorme alors que je pense que c'est pas si énorme que ça.
# ça fait pas cher du poste
Posté par Misc (site web personnel) . En réponse au journal La Communauté valencienne passe à LibreOffice. Évalué à 4.
Si on compte 1.5 millions d'euro pour 120 000 postes, ça fait 12€ par poste et par an. C'est pas énorme en pratique, ou je me plante dans mon calcul ?
[^] # Re: rss-bridge
Posté par Misc (site web personnel) . En réponse au journal Flux RSS pour la page "trending" de GitHub. Évalué à 6.
Tu as openshift ( https://www.openshift.com/ ), et en plus, le code du service est libre, avec le point bonus que ça tourne ailleurs que sur l'infra d'openshift, vu que ça utilise des piles logiciels standards.
Sinon, sans vouloir faire de mauvais esprit, si github avait été libre tu aurais pu coder un patch directement sur la page ( c'est juste pour enfoncer un peu le clou, c'est mesquin, mais je pense qu'il faut quand même bien voir que le libre peut aussi apporter des choses pour les services "webs" )
[^] # Re: Portage facilité ?
Posté par Misc (site web personnel) . En réponse au journal La popularité d'Androïd bénéficiera t-elle à Linux ?. Évalué à 6.
Non, gnome 3 ( ou plutôt gnome-shell n'est pas adapté à un portable ou à un téléphone, et n'a pas été présenté comme l'étant pour le moment. J'ai vu personnelement des devs gnome dire clairement le contraire, et expliquer pourquoi ça ne marche pas. Donc forcément, si c'est pas prévu pour, ça va pas marcher.
Je sais pas d'ou vient cette idée ( sans doute un mec sur ce succédanée de bar PMU que sont les forums de phoronix ), mais visiblement, les gens ne pensent pas vraiment à ce qu'ils disent.
Par exemple, l'aperçu à droite des fenêtres, c'est pas du tout adapté à une résolution réduite. Le fait d'utiliser de façon intensive le clavier ( touche windows pour l'apercu, 2 raccourcis différents pour switcher d'application, système de recherche dans l'apercu ) n'est pas adapté à un appareil sans clavier. Le fait d'avoir besoin besoin des 2 boutons de la souris ( menu dans le launcher à gauche ) ne marche pas bien quand tu as pas de souris.
Tout ça, c'est des choses qui ont été rajoutés à Gnome-shell et ce sont autant de choses qui ne vont pas sur les tablettes classiques, et encore moins les portables.
Tout au plus, du travail est en cours pour offrir un meilleur support des écrans tactiles, mais il y a une énorme différence entre un écran tactile de taille correcte ( genre 12" au minimum, 24, 30 au max ), et un portable/tablette, ou ça va de 4" à 10" ( grosso merdo ). et le travail est en cours car c'est ce que Microsoft demande aux fabricants pour Windows 8.
Supporter les tablettes est un combat perdu d'avance pour le moment au vue de l’écosystème proprio moisi autour d'Android, ou tu peux te brosser pour avoir les specs. Les pilotes 3d moisis, on a déjà donné assez avec Nvidia et ATI sur le monde pc traditionnel, si en plus, tu doit rajouter arm et les constructeurs obsédés par le Time to market au détriment de la qualité logiciel, du respect des licenses et autre trucs qui ralentissent autant, tu tombes sur un gouffre financier si tu veux un produit qui marche.
Microsoft a les moyens. Canonical a pas les moyens, mais ils ont la témérité. Gnome non. Nokia avait tenté, ils ont refait une interface. Tout comme Openmoko avait tenté de refaire une interface basé sur e17, ou kde avec plasma. En fait, la aussi, ça marche pas terrible, mais bon, ça, on en parle pas.
# Vmware ?
Posté par Misc (site web personnel) . En réponse à la dépêche Atelier « cloud computing » et virtualbox / vmWare. Évalué à 5.
Person, je doit reconnaitre que ça me choque un peu de voir un atelier pour apprendre à se servir d'un soft proprio ( virtu vmware, voir virtualbox si tu veux que le truc soit complet ) alors que des alternatives libres existent ( genre kvm et les milliers d'interfaces par dessus, d'openstack à ovirt, archipel, etc, etc ).
Mais bon, comme je suis pas dans les personnes visés ( ou alors plus du coté des formateurs ), je suppose que ça va pas influencer grand chose.
[^] # Re: Dossier pour units perso
Posté par Misc (site web personnel) . En réponse au journal Créer un service sous systemd. Évalué à 4.
Et dans les versions récentes, tu as les dropin folders. Tu fait un fichier foo.unit.d dans /etc/systemd/system, tu rajoutes tes bouts de config, et il fait l'include tout seul.
C'est encore plus propre pour la gestion par un rpm ou puppet.
( systemd 198 )
[^] # Re: Depuis Beijing (Pékin donc) pas de problèmes...même wikipédia.
Posté par Misc (site web personnel) . En réponse au journal Rencontre libriste avec des expats en chine et question sur un accès libre à internet. Évalué à 2.
Alors, le ssh, ça pu/du changer, car j'ai du aider un pote à faire du ssh depuis sa belle famille en chine vers le serveur de sa boite pour bosser. Et en effet, je voyait pas les paquets arriver, et c'était pas un souci de DNS. Mais c'était il y a 5 ans.
De manière très amusante, mon employeur a un certain nombre de bureaux autour du monde, un des rares à avoir une connexion direct ( ie, pas via un lien dédié ), c'est le bureau de Chine. Je sais pas si c'est des raisons techniques ou politiques ( ou les 2, ou un prix trop grand due à un marché moins concurentiel, ou autre ), sachant que les autres bureaux, c'est plus "le batiment est classé donc on peut pas faire de travaux pour le lien MPLS".
[^] # Re: Conclusion un peu hâtive, non ?
Posté par Misc (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 4.
Bien sur, mais quel rapport avec le fait de laisser les boites reprendre sans contribuer en retour ?
Regardons le kernel Linux, qui a beaucoup de retour de grosses boites et qui est sous GPL v2. Ou gcc.
Et des projets sous BSD ( ou assimilés, genre Apache/MIT ) ont aussi des retours.
Donc on peut difficilement dire qu'il y a une corrélation, ne serais que parce que maintenir un fork de code conséquent est couteux en temps, au delà des soucis de licence.
[^] # Re: Bien bien !
Posté par Misc (site web personnel) . En réponse au journal Succès de l'extension de mesa en financement participatif. Évalué à 7.
Ça dépend de ton critère pour "qui marche". D'un point de vue de l'input de la communauté sur le projet, je pense pas que ça soit flagrant, ça reste chasse gardé de Google. Ensuite, je pense que Google fait ça avec android juste parce qu'ils ont pas le choix. Si tu va par la, Apple montre rien et ça marche aussi pour eux. Donc on peut dire que "avoir des parts de marché" n'est pas dépendant dans le mobile de "donner le code source avec du retard".
Y a pas mal de projet qui font de la relecture, genre tout les gros. Y a aussi pas mal de gens qui font de la relecture pour trouver des failles de sécurité, et donc ton chiffre de 99% est à mon sens trompeur et incorrect. Il y a des boites ( par exemple RH pour RHEL, Canonical pour la partie main ) qui font de l'audit avant d'intégrer ou de proposer quoi que ce soit. Mais oui, ça change rien si personne ne bosse avec toi d'habitude, et si tu n'as finalement aucune communauté de développeurs autour de ton produit, soit parce qu'il s'y prête pas, soit parce que le caractère du codeur ne s'y prête pas.
Je parle de la production, pas de l'usage. IE, traduire ou écrire de la documentation sans avoir accès au logiciel est un peu plus dur, et ça aboutit au final à avoir quelque chose de moins bonne qualité. Donc il faut prendre en compte le cout de faire soit même la traduction ou la documentation, ou de donner accès à la version aux bénévoles qui vont le faire dans le cadre du projet libre, ou se satisfaire d'une qualité inférieur ou la traduction est pas relu en situation, tout comme la doc.
Et je rajouterais le fait de faire des tests, des betas, etc. Il me semble évident que le nombre de sponsors testeurs est inférieur ou égal à la communauté entière, vu que les dits sponsors font parti de la communauté par définition. Encore une fois, on aboutit à un truc de moins bonne qualité, ou quelque chose qui requiert plus de travail, si la communauté est fonctionnel ( encore une fois, si elle n'existe pas, ça ne change rien ).
Justement, c'est parce qu'on sait que maintenir des branches est un cout que les gens qui ont un peu plus de bouteille poussent les choses upstream. On a vu ce que ça donne justement avec android et le kernel, et qu'au bout d'un temps, avoir tes branches sur un projet dynamique est lourd.
Au jour le jour, avoir 2 branches de dev ( la branche dispo pour tous, et la branche pour le soft sponsorisé ) fait que tu dois faire 2 fois plus de tests, que tu doit backporter les fonctionnalités et les bugfixes de l'une à l'autre. Ou que tu fait tout dans la branche sponsor, ce qui ralentit fortement les contributions externes ( chose que tu n'as peut être pas sur le projet à la base, ou dont tu te fout, mais du coup, ça me semble aller à l'encontre du développement collaboratif ).
Ensuite, ça dépend grandement de la durée du développement, mais comme tu rajoutes quelques semaines de bloquage de façon artificiellement, ça fait toujours ce temps ou tu doit faire des rebases, etc.
Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI. Si ensuite, toi, ça te va, ça veut pas dire que ça va pour tous.
Donc tu payes une pénalité, comme dans un contrat bien fait en faveur pour le client, ou le client paye sans avoir de garantie ( comme dans un contrat moins en sa faveur ) ? Ou tu impliques les avocats, comme dans un contrat classique ?
J'ai du mal à suivre en quoi ça réponds à la question "combien de temps avant que le codeur refuses quelqu'un qui va faire ça sur son temps libre alors qu'il pourrais avoir de l'argent pour le faire ?"
Des exemples de ce genre, tu en trouve autour des communautés de logiciel open-core.
Ensuite, je sais pas pour toi, mais moi, si y a un truc que j'ai pas envie de faire, c'est rarement rajouter de l'argent qui va me le faire faire, sauf si je suis vraiment à l'arrache ou si il y a vraiment beaucoup d'argent. J'ai pas encore une estime de moi si basse que je vais me vendre à pas cher pour coder un truc que je veux pas coder et en plus m'infliger de faire de la paperasse pour ça. Et pas non plus un compte en banque tellement vide que je n'ai pas le choix.
Mais bon, si ça marche pour toi et plein d'autres, tant mieux.
Je cherche pas à te convaincre du contraire, ça serait totalement idiot et ça m'apporterais rien.
Mais je reste persuadé que ça n'est pas une solution très pérenne pour les systèmes libre tel qu'ils sont aujourd'hui.
Je voit bien par contre que c'est une solution pour les développeurs propriétaires :
- moins de piratage, car au final, les gens qui veulent pas payer vont prendre la version libre
- un minimum d'implication de la communauté pour la traduction/documentation/portage, etc, donc des économies, et une qualité supérieure à un logiciel propriétaire équivalent ( vu qu'il y a rarement des traductions pour les plus petits, et souvent des horreurs pour que ça tourne sans le code source sur divers distributions et OS )
- un financement, car filer le soft gratos, ça paye rarement le loyer
- la possibilité de dire "je fait du libre (en partie )", ce qui est quand même plus glorieux et meilleur pour l'ego que "j'ai fait un shareware", du moins de nos jours sur un CV
- un argument de vente auprès des utilisateurs, histoire de dire "c'est libre, c'est bien (tm)", et de surfer sur la vague ( tout comme le crowdfunding ).
[^] # Re: Bien bien !
Posté par Misc (site web personnel) . En réponse au journal Succès de l'extension de mesa en financement participatif. Évalué à 10.
ça ne serait plus du logiciel libre du coup. Tu n'aurais pu par exemple l'intégration dans les distributions, tu n'aurais pas la relecture par d'autres codeurs de la communauté, les gens avec la feature en plus auraient moins de chance d'avoir des réponses sur le forum, et les documentations et traductions devraient être geré à part.
D'un point de vue logistique, ça semble une mauvaise idée.
Quand à l'idée de base, ça reste quand même risqué. Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ? Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?
Comment tu repartis ça dans le cas d'un travail en équipe ?
Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.
# Et pendant ce temps, sur netbsd
Posté par Misc (site web personnel) . En réponse au journal Après Wine, voici Darling pour faire tourner des applications MAC OS X sous Linux. Évalué à 5.
Je sais que des efforts en ce sens ont été fait sur netbsd il y a 10 ans :
http://2004.eurobsdcon.org/uploads/media/EBSD04_21.pdf
[^] # Re: quoi faire
Posté par Misc (site web personnel) . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 2.
Un client IRC planqué sous une table, vu qu'on essaye d'éviter d'avoir des pcs qui traine partout (noble tache qu'on a du mal à accomplir)
[^] # Re: Reddit
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 7.
C'est pas étonnant. Avoir du matériel libre pose des contraintes que je pense Canonical n'a pas le temps de prendre en compte. par exemple, de la négociation avec les fabricants, ce qui reviens à payer plus cher, ou à sortir plus tard. Et le temps et l'argent ne sont pas des ressources qu'ils ont en abondance.