Oui, ça parait logique. j'ai visiblement oublier un smiley pour montrer que ma réponse était ironique, et de toute façon, c'est pas la defense de la marque qui motive Canonical, juste trouver des fonds.
Ben et si tu utilises pas le kernel ? On peut dire que Ubuntu tourne pas sur LXC, docker et openvz, ni dans un chroot, sauf sur Ubuntu (de la même version) ?
Oui, et c'est même plus rigoureux vu qu'il faut être CCP (Certified Cloud Provider). C'est pour ça que tu as pas RHEL dispo sur OVH, sauf si tu installes toi même. C'est aussi pour ça que Rackspace fait payer plus cher les machines sous RHEL.
Mais je pense que le différence n'est pas de savoir si la demande de Canonical est fondé (car je pense que oui, c'est legitime et rien d'anormal dans l'absolu).
La différence avec Red Hat, c'est que ça a toujours été clair depuis le début qu'il faut rebuilder RHEL. Et ça a toujours été clair dans l'esprit des gens que Red Hat est une boite commercial dont le but est de gagner de l'argent, et que RHEL n'était pas gratuite (sans pinailler sur http://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/ ).
Et en effet, ça dépend. Si tu utilises docker, lxc, openvz sur autre chose que de l'ubuntu, le noyau va être différent. Même Digital Ocean, qui utilise un noyau custom pour leur cloud (pour raison techniques) a été approché: https://twitter.com/jedgar/status/744901488468725760
Le fait que OVH monte au créneau concernant cette demande
démontre que proposer Ubuntu est une plus-value pour eux,
Non, je vois plus le tweet (qu'on peut pas vraiment qualifier de "monter au créneau", faut pas déconner) aussi comme une façon de demander aux gens "voila, on doit augmenter les prix, ça va avoir quoi comme impact". Car bon, il a aussitôt demandé de répondre à un sondage (avec le résultat suivant: https://twitter.com/olesovhcom/status/744982993014501378 )
C'est pas totalement déconnant d'être transparent sur ce point, et si il y a montage au créneau, c'est plus les journalistes qui vont faire des news (et donc monétiser la discussion, avec tout ce que ça implique comme conflit d'intérêt complexe), et/ou les gens qui en discutent (ie, nous sur Linuxfr entre autres).
ça justifie qu'ils reversent de l'argent à Canonical car c'est
bien la marque qu'ils utilisent et pas seulement l'OS (modifié
ou non).
Vu les réponses, ie 69% de "je préfère changer de distro", je pense qu'il faut pas sur estimer la popularité d'Ubuntu et ce qui attire les gens chez OVH (ie, AMHA, c'est plus le bas prix que le fait d'avoir Ubuntu à disposition, vu qu'il y a que 6% qui vont payer, et juste 25% qui vont forcer l'usage d'Ubuntu).
Même si 5000 personnes sur twitter à chaud, c'est pas forcément représentatif, mais ça me parait pas non plus sorti du chapeau.
Et en effet, si on lit le fil twitter, on voit que Octave dit: https://twitter.com/olesovhcom/status/745142044687949824
"est-ce qu'on demanderait à nos clients de payer si on pouvait fixer le soucis juste avec le kernel d'origine ?".
11 ans plus tard, on en entends plus parler, les 10 millions ont du servir (j'espére qu'ils dorment pas à rien faire), et au final, c'est toujours Canonical qui a la main mise partout.
et l'équipe Centos a aussi des soucis avec le fait de mettre des trucs sous le nom Centos qui sont pas comme une Centos de base. Ils sont juste plus cool sur les modifications.
Ca depend, y en pas mal (digital ocean, rackspace) qui retirent/désactive (parfois violement) aussi des features de sécurité (firewall, selinux), car ça réduit leur cout de support sur le court terme (en échange de souci sur le long terme pour tous).
Je pense que tu confonds licence et marque. Sauf erreur de ma part, les logiciels sont toujours sous GPL/BSD/MIT/etc, et c'est la licence. Canonical ne peut pas changer ça d'eux mêmes.
Ce qui coince, c'est l'usage de la marque, ce qui est une autre histoire légèrement différente.
Et en l’occurrence, Canonical ne veut pas que OVH arrête de proposer un produit Ubuntu non approuvé, ils veulent juste arrêter que ça se fasse sans que Canonical ne touche sa part du gâteau (ce qui n'est pas totalement illégitime dans l'absolu)
Car à un aucun moment ils ont dit "il ne faut plus proposer ce produit". Ce qui a été dit, c'est "on veut toucher 1€ par serveur, sinon, vous n'avez plus le droit de dire que c'est de l'ubuntu".
On voit bien que la marque est fongible dans les dollars.
Et c'est pas des frais pour couvrir la vérification (comme le serait une accréditation ou une certification), vu que c'est pas un paiement fixe.
Je ne pense pas que ça soit illégitime dans l'absolu que Canonical demande ça, mais ils ont quand même bien entretenu le flou sur le sujet pendant longtemps (cf https://bugs.launchpad.net/ubuntuone-servers/+bug/375345, cf https://mjg59.dreamwidth.org/39913.html , cf l'emphase énorme sur "Ubuntu, c'est la communauté, on a fondé une association et donc pas une boite", et autres annonces du début du projet).
Et bien sur, au début, ils ont sans doute miser sur le fait d'être partenaire, certifié, etc, sauf que comme ils ont pas séparés la marque communautaire de la marque non-communautaire, ça a aboutit à ça.
Et bien sur, Octave étant pas du genre à se taire et sortir le pognon, Canonical a réussi une fois de plus à se tirer dans le pied. Maintenant, et grace au bruit autour de ça, une partie des gens qui vont vouloir faire de l'IoT avec Ubuntu (qui est un marché que Canonical semble viser) vont se dire qu'il y a un risque.
Et c'est pas le fait de faire payer le problème, ça, les gens comprennent. C'est le fait de payer après que les gens aient commencé à croire que c'était sans problème et gratuit.
Ce n'est pas pour des raisons de sécurité qu'ils ont limité à 3
mois ? Juste éviter d'avoir un certificat compromis qui se
trimbale trop longtemps ?
Oui.
Encore une mauvaise pratique de sécurité.
Oui, mais je peux imaginer qu'il y a ds cas ou ça a du sens. Letsencrypt repose quand même fortement sur le fait que tu arrives à automatiser autant que possible tout.
C'est parfois pas le cas pour des questions de moyens et de limitations techniques. Moi, j'utilise letsencrypt à fond pour les sites que mon travail implique de déployer mais j'ai aussi tout automatisé via ansible. Quelqu'un qui va faire ça à la main parce qu'il ne connait pas ansible et consorts, ou qui va devoir ajouter à la main le certificat dans son boitier F5 via une interface web, ça va sans doute l'arranger d'avoir ça.
Bien sur, la solution est d'embaucher des sysadmins capables d'automatiser tout (ou plus proasiquement de laisser le temps aux dits sysadmins de se former) et/ou remplacer les boitiers à 10 000 boules, mais ça reviens à des questions de moyens qui se corrige pas d'un coup.
Tout de suite, les propos insultants, c'est triste.
(et pour répondre à la personne qui demande mes sources, c'est des discussions avec des anciens de Sun au boulot, ce qui revient à me dire "me croire sur parole", car ça serait interdit par mon contrat de travail que de publier les mails)
Tu opposes 2 licences, mais rien n'aurais empêché Sun/Oracle de basculer les choses sous GPL v3 à la sortie, Ou de rendre les licences compatibles en changeant la dite licence. Ou de mettre plusieurs licences. Si QT arrive à avoir du code qui peut être libre et non-libre à la fois, j'ai aucun doute qu'une boite avec des avocats comme Oracle puisse avoir une solution si c'était vraiment le but.
Donc bon, non, je pense que j'ai vu plus loin que le bout de mon nez. Tu es libre de ne pas le croire et te dire que je suis jaloux de zfs, mais si je voulais vraiment zfs, je prendrais un freebsd, ç'est un système libre au même titre que Linux, donc je vois pas vraiment en quoi ça me poserais des soucis.
La différence est sans doute que Stallman l'a fait pour une raison politique en vue de préserver le code de qu'il voyait comme un péril, la ou Sun l'a fait juste pour faire chier ses concurrents et se garder un avantage commercial.
Bien sur, c'est pareil si tu trouves qu'on peut mettre au même niveau un acte commercial visant à défavoriser la concurrence et un acte visant à soutenir une idéologie. Mais c'est croire que les logiciels libre sont en concurrence entre eux, et que faire du pognon est une idéologie équivalente à faire progresser la science et les libertés des gens.
Il y a besoin d'être mainteneur pour avoir un avis sur systemd?
non, mais y a besoin de faire le taf pour que l'avis compte.
Tout le monde peut avoir un avis, mainteneur ou non. Et donc,
tout le monde peut être pro, anti, ou entre les deux.
Bien sur, mais au final, ceux qui font le boulot décident. Et quand je vois le temps que Devuan a mis pour sortir une beta (sachant que Mageia a mis 4 mois pour sortir la première stable, avec infra, gouvernance, etc), le fait d'avoir eu 0 exode des utilisateurs (cf le journal sur devuan), j'ai tendance à dire qu'avoir un avis est plus facile que faire le taf. Et même si c'est triste, c'est la dur loi du logiciel libre. Si personne fait le taf, le taf est pas fait.
Là, franchement, il est hyper complexe, il peut remplacer le
vénérable init mais aussi fstab,
mais supporte encore /etc/fstab.
crontab
mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.
iptables
non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.
su
pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).
udev…
udev a été mergé par les devs upstreams, au cas ou tu as oublié.
En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.
Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit
avec des choix très discutables sur la gestion de l'UEFI
Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.
On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.
ou plus récemment sur la survie des process après logout
(nohup ca veut dire ce que ca veut dire, il n'y a pas besoin
d'une option pour ca).
Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.
Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).
S'il faut à tout prix remplacer l'init,
alors en fait, si tu regardes un peu l'histoire:
- gentoo a remplacé son init (openrc)
- ubuntu a remplacé son init (upstart)
- apple a remplacé son init (launchd)
- sun a remplacé son init (smf)
Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).
Donc ouais, depuis un bout de temps, les unix veulent changer leur init.
il y a d'autres
alternatives mais qui ont a priori le tort de ne faire que ce
qu'ils doivent faire (par exemple openrc souvent cité, mais
aussi runit qui est, lui, vraiment impressionnant de rapidité).
En fait non, le tort, c'est d'avoir intéressé personne.
Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".
Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.
Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à
Donc non, je ne comprends pas ce mouvement de foule qui ne
jure que par systemd.
C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.
Et puis le processeur baseband GSM ne sera jamais ouvert en
logiciel libre. Et c'est l'endroit parfait pour les logiciels
espions.
Pas vraiment. Déjà, le dit processeur a l'air d'avoir des besoins assez fort en terme de temps réel (il traite le signal radio), donc rajouter des trucs risque de perturber le fonctionnement du baseband GSM.
Ensuite, l'espace est vachement limité. Le firmware que j'avais regardé, c'était sur une base de nucleus ( de Mentor graphics), et c'était 5M tout mouillé. Y a sans doute moyen de faire des choses, mais je pense pas que tu va réussir à faire un truc de folie qui soit générique, et il te faut avoir les ingénieurs radios et embarqués (et ça court pas vraiment les rues, vu le peu d'engouement qu'il y a sur osmocombb). Et bon, on parle de supporter la 3G, et la 4G aussi. Et parfois tout le reste (FM, GPS, etc).
Et enfin, ce genre de firmware sont proprios, et sans doute sous NDA, avec des lourdes certifications (car bon, tu mets pas n'importe quoi n'importe comment sur le marché). Quand tu t'appelles Apple, tu peux 1) négocier pour le changer 2) payer la certif autant que possible. Si tu es pas Apple, bah, dommage, fallait naitre milliardaire.
La on parle de gens qui font une campagne de financement de 50k sur un marché qui va intéresser quasiment personne. Ça serait déjà un miracle de sortir un tel avec ça.
Le fait d'avoir des firmwares proprios est un souci, et je suis sur que la majorité sont pourris (cf les divers talks qu'il y a eu sur le sujet).
Je ne nie pas ce fait. mais malgré ça, toutes les attaques documentés et utiliser en pratique (ie, en dehors du POC et ou d'une conf) sont sur
1) des failles dans SS7
2) es failles dans l'OS (ou tu as largement plus la place de faire des tas de choses)
3) des failles dans les applicatifs.
Que je sache, même dans les groupes qui sont le plus à fond sur l'étude des dits firmwares, ça n'a pas été au delà de "ç'est de la merde et ça plante dés qu'on change un paramètre du signal". Ou les boites commerciales à la Gamma Group et/ou Hacking Team ont été au plus simple (ou au plus réaliste).
L'état de l'art est que ça plante sans grande raison si tu touches trop. Et si le firmware fait de la merde, plante le réseau GSM, tu peux être sur que 1) l'opérateur va le voir 2) l'opérateur va contacter le porteur du tel 3) l'opérateur va faire vite le lien entre "ça fait 5 tels du même fabricant" et "ça fait de la merde" 4) l'opérateur va faire ce qu'il faut.
Je sais pas vraiment pour toi, mais un truc limité, fragile, qui est globalement plus complexe à programmer, j'appelle pas ça "un endroit parfait". L'os est plus intéressant pour un attaquant:
- API standard et public (ie, tu peux tester sur ton tel, tu réutilises le code sans passer 6 mois)
- API de haut niveau (genre, tu as de quoi lire un fichier, de quoi envoyer un fichier, de quoi fouiller tout ce qui existe)
- des ressources et vachement moins besoin de répondre à la microseconde
- une connectivité internet la plupart du temps
- des applis préinstallées sans doute moisies (et donc exploitable)
Il y a le fait que les sites vont te forcer à suivre une certains façon d'interagir avec eux, et que tu est bien plus limité au niveau du filtrage que tu va pouvoir faire, même si des personnes motivés arrivent à faire des choses impresionnantes.
L'exemple le plus probant, c'est travail de Randi Lee Harper qui a écrit ggautoblocker, un système de blocage sur twitter ce qui a visiblement mis hors d'eux les membres du mouvement gamergate (parce qu'on pouvait d'un coup les ignorer de façon efficace, et que visiblement, le fait qu'une personne choisisse de ne pas les lire est une atteinte à leur liberté d'expression, car c'est bien connu que se faire insulter et menacer n'est visiblement pas un truc qu'on devrait pouvoir bloquer…). Elle a également écrit des articles sur le sujet, comme:
Et ensuite, ben tu as le risque de perte de mots de passes et d'infos. C'est pas que les gros réseaux sociaux sont moins sécurisés, mais c'est des cibles bien plus attirantes pour trouver des mots de passes en masse. Encore une fois, Linkedin, dont les conséquences d'une fuite en 2012 commencent à se faire voir. Et en effet, même si ton instance de diaspora est pas à jour et tes 5 utilisateurs risquent de perdre leur mot de passe, personne ne va passer plus de 5 minutes pour ça dans la majorité des cas, car ça n'a aucune valeur (pour le compte moyen, j'entends, je peux imaginer en effet des cas particuliers).
Après je connais pas mal de gens dans la même position qui
attendent que Devuan sorte en stable pour tester et migrer,
Donc si je comprends bien, aucun des gens de ton entourage ne semble vouloir s'investir et contribuer malgré la demande du projet ?
mais bon je crois qu'on s'en fout tous un peu de savoir la
popularité de telle ou telle distrib', l'important c'est
d'avoir une distrib qui correspond à ce qu'on cherche, et qui
fonctionne.
En général, le fait de fonctionner est corrélé directement avec la popularité de la distro, ou dans le cas des dérivés, de la distribution parente (surtout dans le cas des dérivés, qui en général ne sont pas capable de s'en sortir sans la distro parente)
Je peux juste dire que la ML Devuan est très active
et très
intéressante, et qu'il y a une effervescence pas
inintéressante autour du projet :)
Je suis toujours sous le choc de n'avoir réussi à trouver aucune faille de sécurité malgré des choix technologiques audacieux (comprendre: "un soft en pascal qui lance un backend C qui fait des appels à grep,sed et awk pour filtrer les réseaux") qui ont alerté mon instinct.
Je suis content que des gens s'attaquent au souci de ne pas avoir assez de gestionnaire de réseau ( car bon, on a networkd, network manager, connman, wicd et sans doute une paire d'autres, y a clairement de la place pour encore 2 ou 3…), mais j'ai quand même des doutes sur un truc qui semble pire que wicd au niveau code ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692417 ).
Ensuite, on verra quand ça sortiras.
Donc je note que la date de l'exode en masse, c'est le jour de la sortie de devuan stable ( avec un peu de chance, avant le freeze de Debian en février 2017).
C'est plutôt le nombre de contributeurs qui m'intéresse. S'il
y a des utilisateurs mais personne pour maintenir, ça n'ira
pas loin et les utilisateurs passeront à autre chose.
En effet, mais pour le moment, je pense que les gens qui sont la sont 1) habitué à tester des tas de trucs obscures 2) trop impliqué pour changer d'avis.
Maintenant, perso, j'aurais pas forké comme ça (cad, changer tout puis sortir une version, j'aurais fait l'inverse histoire d'en effet avoir une communauté en premier)
on a essayé de profiter des délais administratifs pour lui
couper l'herbe sous le pied à l'arrache et monter une pseudo
fondation dont on sait meme pas encore a quoi elle va servir…
Si je peux me permettre, je pense que le terme français juridiquement correct est "association". (on m'a rabaché qu'une fondation est un truc différent en droit français).
Je pense aussi que même si c'est peut être ce qui est arrivé, la création d'une structure de ce genre me parait trop rapide pour que ça se soit fait sans qu'il le sache et juste après son départ.
Ensuite, peut être que c'est plus rapide qu'en france, bien sur.
Et je trouve aussi curieux qu'un actionnaire reprenne ses billes du jour au lendemain, forcant à rembourser le prêt ou ce genre de choses. Encore une fois, c'est peut être légal, mais je suis pas sur que les nuances de l'histoire correspondent à la réalité.
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 3.
Oui, ça parait logique. j'ai visiblement oublier un smiley pour montrer que ma réponse était ironique, et de toute façon, c'est pas la defense de la marque qui motive Canonical, juste trouver des fonds.
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 3.
Ben et si tu utilises pas le kernel ? On peut dire que Ubuntu tourne pas sur LXC, docker et openvz, ni dans un chroot, sauf sur Ubuntu (de la même version) ?
[^] # Re: Les licences, ça se respecte
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 6.
Oui, et c'est même plus rigoureux vu qu'il faut être CCP (Certified Cloud Provider). C'est pour ça que tu as pas RHEL dispo sur OVH, sauf si tu installes toi même. C'est aussi pour ça que Rackspace fait payer plus cher les machines sous RHEL.
C'est un chouia plus documenté sur https://www.redhat.com/en/technologies/cloud-computing/cloud-access
Mais je pense que le différence n'est pas de savoir si la demande de Canonical est fondé (car je pense que oui, c'est legitime et rien d'anormal dans l'absolu).
La différence avec Red Hat, c'est que ça a toujours été clair depuis le début qu'il faut rebuilder RHEL. Et ça a toujours été clair dans l'esprit des gens que Red Hat est une boite commercial dont le but est de gagner de l'argent, et que RHEL n'était pas gratuite (sans pinailler sur http://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/ ).
[^] # Re: Les licences, ça se respecte
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 7.
C'est pour ça qu'il y a tout le thread:
https://twitter.com/olesovhcom/status/744609239075799044
Oles dit aussi qu'il y a des cas ou c'est le kernel de base, et d'autres ou ils ont besoin de faire un backport pour le matériel:
https://twitter.com/olesovhcom/status/744985741420273664
Et semble dire aussi que Canonical n'a pas dit pourquoi:
https://twitter.com/olesovhcom/status/744975213541064705
Et que c'est juste venu "on veut 1 million d'euro par an maintenant":
https://twitter.com/olesovhcom/status/745146459910070272
https://twitter.com/olesovhcom/status/745147968777396225
Et en effet, ça dépend. Si tu utilises docker, lxc, openvz sur autre chose que de l'ubuntu, le noyau va être différent. Même Digital Ocean, qui utilise un noyau custom pour leur cloud (pour raison techniques) a été approché:
https://twitter.com/jedgar/status/744901488468725760
OVH n'est pas contre payer, mais on peut pas vraiment dire que Canonical fasse ça proprement, et c'est pas la première fois, vu qu'ils ont déjà réussi à se mettre à dos les gens en 2013 avec Fixubuntu, http://arstechnica.com/information-technology/2013/11/canonical-abused-trademark-law-to-target-a-site-critical-of-ubuntu-privacy/
Ce qui a aboutit aux excuses de Mark:
https://plus.google.com/+MarkShuttleworthCanonical/posts/5jdibY5iR9b
et d'un boss de Canonical:
http://blog.canonical.com/2013/11/08/trademarks-community-and-criticism/
et de Mark encore:
http://www.markshuttleworth.com/archives/1299
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 7.
Non, je vois plus le tweet (qu'on peut pas vraiment qualifier de "monter au créneau", faut pas déconner) aussi comme une façon de demander aux gens "voila, on doit augmenter les prix, ça va avoir quoi comme impact". Car bon, il a aussitôt demandé de répondre à un sondage (avec le résultat suivant: https://twitter.com/olesovhcom/status/744982993014501378 )
C'est pas totalement déconnant d'être transparent sur ce point, et si il y a montage au créneau, c'est plus les journalistes qui vont faire des news (et donc monétiser la discussion, avec tout ce que ça implique comme conflit d'intérêt complexe), et/ou les gens qui en discutent (ie, nous sur Linuxfr entre autres).
Vu les réponses, ie 69% de "je préfère changer de distro", je pense qu'il faut pas sur estimer la popularité d'Ubuntu et ce qui attire les gens chez OVH (ie, AMHA, c'est plus le bas prix que le fait d'avoir Ubuntu à disposition, vu qu'il y a que 6% qui vont payer, et juste 25% qui vont forcer l'usage d'Ubuntu).
Même si 5000 personnes sur twitter à chaud, c'est pas forcément représentatif, mais ça me parait pas non plus sorti du chapeau.
Et en effet, si on lit le fil twitter, on voit que Octave dit:
https://twitter.com/olesovhcom/status/745142044687949824
"est-ce qu'on demanderait à nos clients de payer si on pouvait fixer le soucis juste avec le kernel d'origine ?".
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 6.
Bah donc ovh peut juste faire "Ubuntu OVH" et voila, ça va être comme Ubuntu Gnome.
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 4.
Tu veux dire comme la création de la fondation Ubuntu:
https://insights.ubuntu.com/2005/07/01/new-ubuntu-foundation-announced/
11 ans plus tard, on en entends plus parler, les 10 millions ont du servir (j'espére qu'ils dorment pas à rien faire), et au final, c'est toujours Canonical qui a la main mise partout.
[^] # Re: Mise à jour d l'article sur Clubic
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 5.
Centos a aussi une trademark policy: https://www.centos.org/legal/trademarks/
et l'équipe Centos a aussi des soucis avec le fait de mettre des trucs sous le nom Centos qui sont pas comme une Centos de base. Ils sont juste plus cool sur les modifications.
[^] # Re: Pratique courante ?
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 3.
Ca depend, y en pas mal (digital ocean, rackspace) qui retirent/désactive (parfois violement) aussi des features de sécurité (firewall, selinux), car ça réduit leur cout de support sur le court terme (en échange de souci sur le long terme pour tous).
[^] # Re: C'est comme Firefox
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 10.
Je pense que tu confonds licence et marque. Sauf erreur de ma part, les logiciels sont toujours sous GPL/BSD/MIT/etc, et c'est la licence. Canonical ne peut pas changer ça d'eux mêmes.
Ce qui coince, c'est l'usage de la marque, ce qui est une autre histoire légèrement différente.
Et en l’occurrence, Canonical ne veut pas que OVH arrête de proposer un produit Ubuntu non approuvé, ils veulent juste arrêter que ça se fasse sans que Canonical ne touche sa part du gâteau (ce qui n'est pas totalement illégitime dans l'absolu)
Car à un aucun moment ils ont dit "il ne faut plus proposer ce produit". Ce qui a été dit, c'est "on veut toucher 1€ par serveur, sinon, vous n'avez plus le droit de dire que c'est de l'ubuntu".
On voit bien que la marque est fongible dans les dollars.
Et c'est pas des frais pour couvrir la vérification (comme le serait une accréditation ou une certification), vu que c'est pas un paiement fixe.
Je ne pense pas que ça soit illégitime dans l'absolu que Canonical demande ça, mais ils ont quand même bien entretenu le flou sur le sujet pendant longtemps (cf https://bugs.launchpad.net/ubuntuone-servers/+bug/375345, cf https://mjg59.dreamwidth.org/39913.html , cf l'emphase énorme sur "Ubuntu, c'est la communauté, on a fondé une association et donc pas une boite", et autres annonces du début du projet).
Et bien sur, au début, ils ont sans doute miser sur le fait d'être partenaire, certifié, etc, sauf que comme ils ont pas séparés la marque communautaire de la marque non-communautaire, ça a aboutit à ça.
Et bien sur, Octave étant pas du genre à se taire et sortir le pognon, Canonical a réussi une fois de plus à se tirer dans le pied. Maintenant, et grace au bruit autour de ça, une partie des gens qui vont vouloir faire de l'IoT avec Ubuntu (qui est un marché que Canonical semble viser) vont se dire qu'il y a un risque.
Et c'est pas le fait de faire payer le problème, ça, les gens comprennent. C'est le fait de payer après que les gens aient commencé à croire que c'était sans problème et gratuit.
[^] # Re: Les licences, ça se respecte
Posté par Misc (site web personnel) . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 10.
C'est sur que ne pas respecter les marques du projet Ubuntu, ç'est pas un truc que Canonical ferait eux mêmes:
https://bugs.launchpad.net/ubuntuone-servers/+bug/375345
[^] # Re: StartEncrypt
Posté par Misc (site web personnel) . En réponse au journal Petites news dans le monde des autorités de certifications. Évalué à 4.
Oui.
Oui, mais je peux imaginer qu'il y a ds cas ou ça a du sens. Letsencrypt repose quand même fortement sur le fait que tu arrives à automatiser autant que possible tout.
C'est parfois pas le cas pour des questions de moyens et de limitations techniques. Moi, j'utilise letsencrypt à fond pour les sites que mon travail implique de déployer mais j'ai aussi tout automatisé via ansible. Quelqu'un qui va faire ça à la main parce qu'il ne connait pas ansible et consorts, ou qui va devoir ajouter à la main le certificat dans son boitier F5 via une interface web, ça va sans doute l'arranger d'avoir ça.
Bien sur, la solution est d'embaucher des sysadmins capables d'automatiser tout (ou plus proasiquement de laisser le temps aux dits sysadmins de se former) et/ou remplacer les boitiers à 10 000 boules, mais ça reviens à des questions de moyens qui se corrige pas d'un coup.
[^] # Re: APFS
Posté par Misc (site web personnel) . En réponse au journal Le malaise.. Évalué à 5.
Tout de suite, les propos insultants, c'est triste.
(et pour répondre à la personne qui demande mes sources, c'est des discussions avec des anciens de Sun au boulot, ce qui revient à me dire "me croire sur parole", car ça serait interdit par mon contrat de travail que de publier les mails)
Tu opposes 2 licences, mais rien n'aurais empêché Sun/Oracle de basculer les choses sous GPL v3 à la sortie, Ou de rendre les licences compatibles en changeant la dite licence. Ou de mettre plusieurs licences. Si QT arrive à avoir du code qui peut être libre et non-libre à la fois, j'ai aucun doute qu'une boite avec des avocats comme Oracle puisse avoir une solution si c'était vraiment le but.
Et même eux ont déjà changé la licence d'un code pour le rendre compatible GPL v2, c'est déjà ce qui est arrivé avec Sun RPC:
https://lwn.net/Articles/319648/
http://spot.livejournal.com/315383.html?nojs=1
Donc bon, non, je pense que j'ai vu plus loin que le bout de mon nez. Tu es libre de ne pas le croire et te dire que je suis jaloux de zfs, mais si je voulais vraiment zfs, je prendrais un freebsd, ç'est un système libre au même titre que Linux, donc je vois pas vraiment en quoi ça me poserais des soucis.
[^] # Re: Désinformation ?
Posté par Misc (site web personnel) . En réponse au journal Le malaise.. Évalué à 6.
C'est différent du People's Front of Judea ?
[^] # Re: APFS
Posté par Misc (site web personnel) . En réponse au journal Le malaise.. Évalué à 7.
La différence est sans doute que Stallman l'a fait pour une raison politique en vue de préserver le code de qu'il voyait comme un péril, la ou Sun l'a fait juste pour faire chier ses concurrents et se garder un avantage commercial.
Bien sur, c'est pareil si tu trouves qu'on peut mettre au même niveau un acte commercial visant à défavoriser la concurrence et un acte visant à soutenir une idéologie. Mais c'est croire que les logiciels libre sont en concurrence entre eux, et que faire du pognon est une idéologie équivalente à faire progresser la science et les libertés des gens.
[^] # Re: LinuxFR est pro-Systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 3.
non, mais y a besoin de faire le taf pour que l'avis compte.
Bien sur, mais au final, ceux qui font le boulot décident. Et quand je vois le temps que Devuan a mis pour sortir une beta (sachant que Mageia a mis 4 mois pour sortir la première stable, avec infra, gouvernance, etc), le fait d'avoir eu 0 exode des utilisateurs (cf le journal sur devuan), j'ai tendance à dire qu'avoir un avis est plus facile que faire le taf. Et même si c'est triste, c'est la dur loi du logiciel libre. Si personne fait le taf, le taf est pas fait.
[^] # Re: LinuxFR est pro-Systemd
Posté par Misc (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 10.
mais supporte encore /etc/fstab.
mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.
non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.
pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).
udev a été mergé par les devs upstreams, au cas ou tu as oublié.
En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.
Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit
Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.
On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.
Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.
Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).
alors en fait, si tu regardes un peu l'histoire:
- gentoo a remplacé son init (openrc)
- ubuntu a remplacé son init (upstart)
- apple a remplacé son init (launchd)
- sun a remplacé son init (smf)
Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).
Donc ouais, depuis un bout de temps, les unix veulent changer leur init.
En fait non, le tort, c'est d'avoir intéressé personne.
Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".
Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.
Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à
C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.
[^] # Re: mwais
Posté par Misc (site web personnel) . En réponse au journal UnaOS - UnaPhone - Un smartphone axé autour de la vie privée ?. Évalué à 2.
Alors je me réponds à moi même, le papier le plus à jour sur les basebands que j'ai trouvé, c'est un truc de 2012:
https://www.usenix.org/system/files/conference/woot12/woot12-final24.pdf
(mais je reste quand même sur ma conclusion)
[^] # Re: mwais
Posté par Misc (site web personnel) . En réponse au journal UnaOS - UnaPhone - Un smartphone axé autour de la vie privée ?. Évalué à 2.
Pas vraiment. Déjà, le dit processeur a l'air d'avoir des besoins assez fort en terme de temps réel (il traite le signal radio), donc rajouter des trucs risque de perturber le fonctionnement du baseband GSM.
Ensuite, l'espace est vachement limité. Le firmware que j'avais regardé, c'était sur une base de nucleus ( de Mentor graphics), et c'était 5M tout mouillé. Y a sans doute moyen de faire des choses, mais je pense pas que tu va réussir à faire un truc de folie qui soit générique, et il te faut avoir les ingénieurs radios et embarqués (et ça court pas vraiment les rues, vu le peu d'engouement qu'il y a sur osmocombb). Et bon, on parle de supporter la 3G, et la 4G aussi. Et parfois tout le reste (FM, GPS, etc).
Et enfin, ce genre de firmware sont proprios, et sans doute sous NDA, avec des lourdes certifications (car bon, tu mets pas n'importe quoi n'importe comment sur le marché). Quand tu t'appelles Apple, tu peux 1) négocier pour le changer 2) payer la certif autant que possible. Si tu es pas Apple, bah, dommage, fallait naitre milliardaire.
La on parle de gens qui font une campagne de financement de 50k sur un marché qui va intéresser quasiment personne. Ça serait déjà un miracle de sortir un tel avec ça.
Le fait d'avoir des firmwares proprios est un souci, et je suis sur que la majorité sont pourris (cf les divers talks qu'il y a eu sur le sujet).
Je ne nie pas ce fait. mais malgré ça, toutes les attaques documentés et utiliser en pratique (ie, en dehors du POC et ou d'une conf) sont sur
1) des failles dans SS7
2) es failles dans l'OS (ou tu as largement plus la place de faire des tas de choses)
3) des failles dans les applicatifs.
Que je sache, même dans les groupes qui sont le plus à fond sur l'étude des dits firmwares, ça n'a pas été au delà de "ç'est de la merde et ça plante dés qu'on change un paramètre du signal". Ou les boites commerciales à la Gamma Group et/ou Hacking Team ont été au plus simple (ou au plus réaliste).
L'état de l'art est que ça plante sans grande raison si tu touches trop. Et si le firmware fait de la merde, plante le réseau GSM, tu peux être sur que 1) l'opérateur va le voir 2) l'opérateur va contacter le porteur du tel 3) l'opérateur va faire vite le lien entre "ça fait 5 tels du même fabricant" et "ça fait de la merde" 4) l'opérateur va faire ce qu'il faut.
Je sais pas vraiment pour toi, mais un truc limité, fragile, qui est globalement plus complexe à programmer, j'appelle pas ça "un endroit parfait". L'os est plus intéressant pour un attaquant:
- API standard et public (ie, tu peux tester sur ton tel, tu réutilises le code sans passer 6 mois)
- API de haut niveau (genre, tu as de quoi lire un fichier, de quoi envoyer un fichier, de quoi fouiller tout ce qui existe)
- des ressources et vachement moins besoin de répondre à la microseconde
- une connectivité internet la plupart du temps
- des applis préinstallées sans doute moisies (et donc exploitable)
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Misc (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 2.
Je suis pas vraiment sur qu'on puisse blâmer la calvitie sur systemd.
[^] # Re: Centralisation
Posté par Misc (site web personnel) . En réponse au journal Les réseaux sociaux sont ils liberticides et comment ne pas l’être. Évalué à 2.
Je pense qu'il y a d'autres soucis au dela de la centralisation et de la confiance.
Il y a le fait que le réseau social a tout intéret à t'inciter à rester, et va donc utiliser des trucs d'un point de vue de l'interface pour ça (l'exemple le plus connu, c'est Linkedin par exemple, mais ça a fait pas mal de bruit y a pas longtemps avec https://medium.com/@tristanharris/how-technology-hijacks-peoples-minds-from-a-magician-and-google-s-design-ethicist-56d62ef5edf3 ).
Il y a le fait que les sites vont te forcer à suivre une certains façon d'interagir avec eux, et que tu est bien plus limité au niveau du filtrage que tu va pouvoir faire, même si des personnes motivés arrivent à faire des choses impresionnantes.
L'exemple le plus probant, c'est travail de Randi Lee Harper qui a écrit ggautoblocker, un système de blocage sur twitter ce qui a visiblement mis hors d'eux les membres du mouvement gamergate (parce qu'on pouvait d'un coup les ignorer de façon efficace, et que visiblement, le fait qu'une personne choisisse de ne pas les lire est une atteinte à leur liberté d'expression, car c'est bien connu que se faire insulter et menacer n'est visiblement pas un truc qu'on devrait pouvoir bloquer…). Elle a également écrit des articles sur le sujet, comme:
https://medium.com/@randileeharper/solving-twitter-dogpiles-7d7b102116c8#.88bp24g1c
https://medium.com/art-marketing/putting-out-the-twitter-trashfire-3ac6cb1af3e#.k485laj89
https://medium.com/@randileeharper/diving-into-the-cesspool-fixing-youtube-3775a8afcd82#.nlni6ibf0
Et ensuite, ben tu as le risque de perte de mots de passes et d'infos. C'est pas que les gros réseaux sociaux sont moins sécurisés, mais c'est des cibles bien plus attirantes pour trouver des mots de passes en masse. Encore une fois, Linkedin, dont les conséquences d'une fuite en 2012 commencent à se faire voir. Et en effet, même si ton instance de diaspora est pas à jour et tes 5 utilisateurs risquent de perdre leur mot de passe, personne ne va passer plus de 5 minutes pour ça dans la majorité des cas, car ça n'a aucune valeur (pour le compte moyen, j'entends, je peux imaginer en effet des cas particuliers).
[^] # Re: double licence et fin du CLA: pas le choix ?
Posté par Misc (site web personnel) . En réponse au journal NextCloud : le fork d'OwnCloud. Évalué à 3.
Ou un CLA sur des modules en plus, voir en récrivant un par un les modules existants.
[^] # Re: Ça manque d'info pour lancer un troll
Posté par Misc (site web personnel) . En réponse au journal Devuan β. Évalué à 10.
Donc si je comprends bien, aucun des gens de ton entourage ne semble vouloir s'investir et contribuer malgré la demande du projet ?
En général, le fait de fonctionner est corrélé directement avec la popularité de la distro, ou dans le cas des dérivés, de la distribution parente (surtout dans le cas des dérivés, qui en général ne sont pas capable de s'en sortir sans la distro parente)
Alors je doit reconnaitre que j'éprouve un intérêt, mais sans doute pas du même genre. Par exemple, ma dernière trouvaille, c'est https://git.devuan.org/edbarx/netman/tree/master
Je suis toujours sous le choc de n'avoir réussi à trouver aucune faille de sécurité malgré des choix technologiques audacieux (comprendre: "un soft en pascal qui lance un backend C qui fait des appels à grep,sed et awk pour filtrer les réseaux") qui ont alerté mon instinct.
Démonstration:
https://git.devuan.org/edbarx/netman/blob/master/backend_src/src/file_functions.c#L98
Je suis content que des gens s'attaquent au souci de ne pas avoir assez de gestionnaire de réseau ( car bon, on a networkd, network manager, connman, wicd et sans doute une paire d'autres, y a clairement de la place pour encore 2 ou 3…), mais j'ai quand même des doutes sur un truc qui semble pire que wicd au niveau code ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692417 ).
Ensuite, on verra quand ça sortiras.
Donc je note que la date de l'exode en masse, c'est le jour de la sortie de devuan stable ( avec un peu de chance, avant le freeze de Debian en février 2017).
Parfait, enfin une réponse claire et précise.
[^] # Re: Ça manque d'info pour lancer un troll
Posté par Misc (site web personnel) . En réponse au journal Devuan β. Évalué à 3.
Il y a aussi un gitlab:
https://git.devuan.org/
Et on peut voir les gens dans les groupes.
Genre pour le groupe devuan:
https://git.devuan.org/groups/devuan/group_members
En effet, mais pour le moment, je pense que les gens qui sont la sont 1) habitué à tester des tas de trucs obscures 2) trop impliqué pour changer d'avis.
Maintenant, perso, j'aurais pas forké comme ça (cad, changer tout puis sortir une version, j'aurais fait l'inverse histoire d'en effet avoir une communauté en premier)
[^] # Re: That escalated quickly...
Posté par Misc (site web personnel) . En réponse au journal NextCloud : le fork d'OwnCloud. Évalué à 3.
Si je peux me permettre, je pense que le terme français juridiquement correct est "association". (on m'a rabaché qu'une fondation est un truc différent en droit français).
Je pense aussi que même si c'est peut être ce qui est arrivé, la création d'une structure de ce genre me parait trop rapide pour que ça se soit fait sans qu'il le sache et juste après son départ.
Ensuite, peut être que c'est plus rapide qu'en france, bien sur.
Et je trouve aussi curieux qu'un actionnaire reprenne ses billes du jour au lendemain, forcant à rembourser le prêt ou ce genre de choses. Encore une fois, c'est peut être légal, mais je suis pas sur que les nuances de l'histoire correspondent à la réalité.