SalvadorDalek a écrit 30 commentaires

Je n'ai jamais vu IBM s'embêter à le faire, mais un cas n'est pas l'autre. Tant que RedHat en interne restera RedHat, ça ira… dès que les politiques, méthodologies et outils standards IBM vont débarquer, il va y avoir une guerre suivie d'un grand mouvement migratoire. Il faut bien se dire qu'en dehors éventuellement du cadre commercial, IBM n'a rien à apprendre à RedHat et tout outil ou méthode de travail d'IBM sera perçu comme une régression (j'imagine IBM débarquant chez RedHat avec un outil genre BigFix ou ITM/GSMA Bluecare et je compatis à l'avance avec les gens de RedHat)

IBM n'a pas d'opinion sur systemd, ils sont encore en phase exploratoire avec systemVinit.

(sans rire, regardez les produits ibm pour lesquels ne sont livrés ni scripts init ni unités systemd, … )

Oracle a acheté SUN pour pouvoir récupérer les brevets sur Java et se faire de la thune en poursuivant les acteurs de l'écosystème Android. L'activité n°1 chez Oracle n'est pas l'informatique mais les poursuites liées aux contrats de licence et aux brevets.

Si c'était un achat immobilier, une rentabilité sur 20 - 25 ans serait peut-être acceptable…

Pour un achat d'une entreprise dans un marché qui évolue aussi vite, ça devient difficile à justifier car un changement de cap est plus que probable au delà de 5 ans (regardons à quoi ressemblait RedHat il y a 5 ans et comparons les produits phares et les domaines prédominants à l'époque et de nos jours)

Imaginons que, par exemple, une partie de l'équipe de CoreOS se barre et fonde une startup livrant un kubernetes pour entreprise basé sur l'expérience de CoreOS et Openshift mais ne craignant pas la nouveauté pour attirer des clients… IBM serait en danger… Imaginons maintenant que cette start-up se fasse réabsorber par Amazon… IBM serait bien embêté.

Ce qu'achète IBM n'est pas une maison, il achète des contrats et du personnel; les contrats ne tiendront pas longtemps sans le personnel de RedHat, et IBM a malheureusement développé une culture tendant à faire fuir les employés dans le but d'optimiser sa force de travail.

J'avais plutôt 20G$ en tête comme valeur… Reste que comme RedHat a un revenu annuel de ~3G$, Il va falloir changer l'entreprise si IBM veut un retour sur investissement intéressant dans la prochaine décennie.

Et comme tout ce qu'à produit RedHat jusqu'à présent était sous licence OpenSource, il n'est pas impossible pour les développeurs de RedHat de repartir avec leur code sous le bras et de relancer des startups.

En fait, si RedHat est en péril mortel ( © Académie Française) , cette manœuvre pourrait aussi être dévastatrice pour IBM en cas d'exode massif dans les 3 ans.

Vous savez, les propriétaires de RedHat, c'est surtout des fonds d'investissement qui vendront si l'offre financière est intéressante. La culture d'entreprise, les valeurs, la liberté, importent peu face à une bonne vente d'actions.

Question culture, je suis réaliste, redhat est une entreprise commerciale dont le but est de vendre ses produits. A ce titre, RedHat a misé sur un écosystème dans lequel ils ont énormément investi, par pragmatisme, et cet investissement a bénéficié à la communauté pendant de nombreuses années.

Maintenant, un changement d'objectif commercial va changer les priorités et dépendances de cette entreprise, et on peut raisonnablement s'attendre à ce que ces changements impactent l'ampleur et la qualité des contributions de RedHat aux projets dont il dépendait.

Le problème n'est pas juste mon supposé rapport de confiance à RedHat mais bien une dépendance réelle de toute une communauté, chiffrable en lignes de code apportées par RedHat.

Question logiciel libre, une anecdote: au RedHat Summit 2018, j'ai assisté à une keynote prétendant retracer l'historique de RedHat, de 'Linux', durant laquelle pas une seule fois les mots GNU ou Free Software n'ont été prononcés.

L'exemple Microsoft est un bon exemple d'entreprise ayant su se transformer. Je n'ai pas une grande confiance en eux, mais j'aurais été moins négatif si ça avait été Microsoft qui avait racheté RedHat.

Bien entendu, il est difficile de présager exactement de la forme future de RedHat après acquisition et bluewashing, mais se voiler la face en répétant 'tout est possible' en écartant tout le passif de Big Blue n'est certainement pas la réaction la plus ancrée dans la réalité.

A moins que RedHat ne reste totalement indépendant et puisse continuer à engager du personnel sous contrat RedHat (tactique IBM: vous restez indépendant, mais vous n'engagez plus, on vous envoie le personnel que nous jugerons bon de vous envoyer) , je ne vois rien de bon ressortir de ce rachat.

En remettant cette nouvelle d'achat en perspective avec les interventions d'IBM au RedHat Summit de cette année, j'ai en tout cas du mal à changer d'avis.

Ayant bossé pour IBM, je peux témoigner:

IBM est carrément hostile au logiciel libre et au copyleft. S'ils contribuent au noyau linux, c'est pour uniquement pour le support du POWER et mainframe.

IBM a un règlement intérieur qui interdit aux employés de travailler sur des projets foss sur leur temps libre.

IBM aime l'open source surtout si IBM peut le refermer et le vendre en tant que logiciel privateur, chose qu'ils ne se privent pas de faire. Les projets copyleft sont naturellement interdits.

Si IBM achète RedHat, les produits et leur évolution seront déterminés par les vaches à lait: Mainframe, Power, DB2, Websphere, suite Tivoli, … et il convient de méditer sur tous les produits que la vision mainframe a flingué, bridé ou dénaturé par le passé.

Maintenant, quel impact pour nous (libristes)? Je dirais que l'on doit s'attendre à une chute des contributions dans tous les projets FOSS sur lesquels RedHat était actif, et plus particulièrement sur tous les projets qui ne concernent pas directement les raisons pour lesquelles IBM a acheté RedHat. Les patches proposés par redhat (si le nom persiste) seront sans doutes plus orientés 'on change un truc dans l'OS car les architectes du produit IBM xyz ne veulent pas toucher à l'application qui marche très bien sous AIX'

Personnellement, je trouve que les antivirus commerciaux sont généralement un problème de sécurité en sois et doivent être intégrés avec beaucoup d'attention ou carrément ignorés en faveur d'antivirus libres dans un contexte plus ciblé.

Quelques problèmes en vrac observés avec les antivirus privateurs non spécialisés…

• Ils tournent au niveau du noyau
• de ce fait ils peuvent parfois retarder la mise en place de mises à jour du noyau et laisser des systèmes vulnérables
• ils augmentent également la surface d'attaque du noyau car en cas de faille dans les fonctions de scan, c'est l'ensemble du noyau (et donc du système) qui est en péril.
• Ils sont peu audités par des tiers
• Ils sont développés dans l'urgence, ce qui peut mener à des problèmes de qualité => impact sur la stabilité et la sécurité
• ils ont souvent des protocoles de commande avec des processus écoutant en tant que root sur le réseau.
• certains demandent même de désactiver des modules de sécurité noyau comme SElinux…
• les antivirus en général sont de moins en moins efficaces.

Face à cela, je préfère sécuriser correctement les OS clients/serveurs et garder SElinux actif, et mettre en place des antivirus libres ou éventuellement proprio, mais uniquement sur les chemins critiques comme le proxy, les serveurs mails, les serveurs de fichiers samba, et de préférence des solutions s'intégrant à la couche service (samba, smtp, …) plutôt qu'au kernel.

Personnellement, je rajouterais au moins

• Mettre en place les Capabilities au lieu du setuid root (meilleure granularité sur les privilèges)
• Activer SELinux au minimum en targetted/enforcing, à fortiori si on parle d'un serveur.
• faire la chasse aux logiciels écoutant sur le réseau et tournant comme root

Pour la config, j'utilise saltstack qui me permet de gérer le cycle de vie de la configuration des serveurs et de gérer les descriptions d'état dans un git.

Bon, ok c'est de l'epson, mais ça marche avec des bouteilles à vider dans des réservoirs plutôt que des cartouches.

Sortant d'une période difficile avec la pire imprimante que j'ai eu en 20 ans (hp photosmart 7510 puis 7520), je désirais m'éloigner de cette marque à tout prix (pannes à répétition, remplacements successifs, impression photo beaucoup trop sombre sans passer par une violente compensation du gamma, …)

Alors bon, c'est clair, l'EcoTank est plus chère à l'achat qu'une imprimante normale où le constructeur truande le consommateur sur les consommables, mais pour le moment ça me semble être honnête, avec une encre plutôt bon marché par rapport aux équivalents cartouche.

Bon un bémol tout de même, la ET-2550 que je possède ne sait pas faire l'impression à bords perdus, semble avoir une résolution réelle de 360dpi avant tramage à plus haute résolution, mais la reproduction des couleurs est plutôt excellente même sur papier glacé très bon marché. Pour le recto-verso, par contre il faut voir les modèles supérieurs.

Je en vois pas au nom de quoi on n'aurait pas le droit de leur en vouloir d'avoir trouvé une méthode pour contourner la licence.

Ce n'est pas parceque quelque-chose est légal qu'il n'est pas moralement condamnable, et ce n'est pas parceque qu'un acte est illégal qu'on ne peut pas éprouver de al sympathie pour ceux qui le commettent.

Ici, ils trichent "légalement". Selon ses convictions individuelles on peut avoir une appréciation variable de leurs actes et en tout cas on a le droit d'avoir une opinion sur ce fait.

Tu peux voir ça comme "dérivé de"… donc un travail intégrant tout ou portion du programme couvert par l'AGPL.

En pratique cela interdit de lier ou d'incorporer le code AGPL à un binaire sous une autre licence incompatible. Vu que ton application invoque le binaire ps2pdf, déjà compilé, et à travers des appels système plutôt que des appels à une librairie dérivée du code de GhostScript, il me semble que ton usage ne représente pas une violation de la licence, ni dans l'esprit ni dans la lettre (ce serait un sacré big bang si lancer un exécutable via les appels système faisait du logiciel appelant un produit dérivé nécessitant un ajustement de licence)

Reste qu'en cas de doute il vaut mieux consulter un juriste spécialisé.

Invoquer le software à la ligne de commande n'est pas la même chose que de le lier en tant que librairie ou en incorporer des bouts.

A mon humble avis cela ne génère pas de contraintes concernant la licence de ton travail ou l'acquisition d'une licence commerciale pour utiliser ps2pdf (bon, c'est sympa aussi de soutenir un projet dont ton travail dépend).

C'est même encore plus permissif (bien que flou) : "A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work."

Sinon, dans le genre, il y a chez Epson les imprimantes EcoTank… pour ma part j'ai craqué pour la ET-2250 qui a une impression de très bonne qualité (mais malheureusement pas à bord perdu).

J'espère qu'elle tiendra l'épreuve du temps (je touche du bois), le prix à l'achat est beaucoup plus élevé que l'équivalent aliéné aux cartouches, le prix des bouteilles de recharge est très raisonnable (mais elles sont rarement dispo en magasin) mais d'un autre côté on a un produit correct et sans bidouilles inutiles (et donc avec une garantie)

Cela nécessite la mise en place d'au moins deux serveurs d'infra, mais cela permet d'avoir un modèle de sécurité exhaustif (ldap, kerberos, pki, sudo, clefs ssh, utilisateurs SELinux, dns, …) et de créer, via intégration avec Samba4, un trust avec AD pour offrir une intégration complète.

Un des gros avantages est que l'installation est assez aisée, clefs en main, par contre il y a pas mal de lecture quand on doit faire certains dépannages.

"Sur un autre sujet, je te signale que le bug n°1 a été fermé il y a bientôt 3 ans :)"

C'est pour celà que je parle de nouveau bug #1 … la prédominance de Canonical sur l'écosystème visible GNU/Linux et ses manœuvres qui tendent plutôt, selon mon opinion, à affaiblir l'écosystème libre.

Le fait de chercher à exploiter des failles dans la GPL ou de s'afficher comme acteur dans l'amélioration d'un OS privateur ne me semble pas aller dans le bon sens pour la défense des libertés, mais ce n'est que mon opinion.

Décidément, Canonical est occupé à pédaler dans une direction inquiétante dernièrement.

Tandis qu'ils s'évertuent à contourner la licence GPL et à balancer du code non-gpl dans le noyeau (ZFS on GNU/Linux), les voici également occupés à porter des outils de base de GNU/Linux pour la plateforme privatrice référencée dans leur ancien bug n°1, et ce en franche collaboration avec l'éditeur de cette dernière …

On peut se demander si de nos jours le Bug n°1 n'est pas que Canonical possède trop de parts de marché dans le monde du libre et utilise cette force pour faire tout et n'importe quoi en se moquant des conséquences sur l'écosystème libre.

Bonjour, juste pour préciser,

le Software Freedom Conservancy représente un certain nombre de développeurs du noyau (donc détenteurs de droits sur le noyau) via son "GPL Compliance Project For Linux Developers". Si ces développeurs décident que le SFC doit agir, il aura la légitimité pour le faire, tout comme il le fait déjà face à VMWare en Allemagne.

Pour rappel, le noyau Linux n'est pas uniquement l’œuvre de Linus Torvalds et dans la mesure où il n'y a pas d'obligation pour les contributeurs de transférer leurs droits au projet ou à l'auteur principal, presque tous jouissent pleinement de leurs droits en tant qu'auteurs. C'est d'ailleurs ce côté qui protège le noyau contre un rachat par une société tierce (comme on a pu le voir avec des projets comme cups) mais rend un changement de license (par exemple vers GLPv3) impossible.

Bien à toi.

2) Capsicum c'est pour les devs qui veulent rendre leur logiciel plus robuste, c'est donc assez différent des politiques de sécurité qui sont plus pour les admins.

Je crois qu'il faut tout de même le dire vite. Dans le cas de SElinux, par exemple, si changer une étiquette sur un fichier, ou faire un audit2allow est tout à fait faisable pour le sysadmin lambda, rédiger un module complet de sécurisation d'une application reste une tâche très complexe qui est généralement faite plutôt en amont soit par les développeurs de l'application eux-mêmes, soit par les mainteneurs de la distribution/du paquet.

Le sysadmin de base, genre niveau RHCE, n'a pas la connaissance pour écrire efficacement des modules pour sécuriser des applications tierces avec des primitives propres pour ne pas provoquer d'effets de bord dans d'autres polices.

Pour complète, je dirais que si le fait de défendre la langue française est tout à fait louable,
le faire de la sorte est très peu courtois pour ne pas dire grossier.

Quelqu'un qui s'intéresse réellement à la langue française plutôt qu'à prendre la pose sur un forum aurait fait autrement que de balancer une commande 'sed' (ce qui n'est pas du Français à ce que je sache) à la figure de l'interlocuteur sans même s'adresser à lui. C'est une attitude dénigrante qui ne fait pas avancer le débat, et cela ne s'inscrit certainement pas dans esprit de collaboration et d'échange.

Dommage également que certains pensent que ce genre d'attitude mérite encouragement.

Salut,

quand je parlais de problème pour déployer les keytabs, je parlais plutôt d'un problème de contenu plutôt que de contenant… Quand tu dois intégre du linux dans un domaine AD dans lequel tu n'as pas les privilèges suffisants pour générer les keytabs, ton problème n°1 n'est pas la diffusion de ceux-ci sur les bonnes machines mais simplement de les obtenir.

Sinon c'est sûr que puppet est un excellent outil pour la configuration de masse.

Bien à toi.

Ouh, intéressant outil, je ne connaissais pas..

à mon avis ça ne règle pas tous les problèmes, mais ça peut offrir une sérieuse base pour en régler tout de même une grosse partie.

Merci

Salut,

AD et Linux, ça a toujours été une petite foire d'empoigne… surtout avant windows 2008 où il fallait faire des extensions de schéma sur AD juste pour avoir les attributs unix de base.

Personnellement, sur de très grands parcs, je n'ai jamais réussi à obtenir un résultat satisfaisant.

En dehors d'une approche IPA, tu peux toujours implémenter une infrastructure ldap (avec un peuplement manuel ou généré par scripts depuis l'AD) et une relation de confiance entre ton domaine kerberos et ton domaine AD de sorte que tu bénéficie de l'authentication transitive de kerberos (SSO) tout en ayant une base d'autorisation ldap saine et adaptée à ta plateforme unix/linux.

Avec cette approche, tu peux en outre gérer proprement les identifiant de tes services dans kerberos et distribuer les fichiers keytabs sans devoir passer trois heures à discuter avec tes administrateurs windows pour essayer de leur faire comprendre de quoi il s'agit et à essayer de comprendre ce qu'ils demandent.

Bien à toi

Mwais, si tu veux et si tu n'as rien d'autre à dire d'intéressant…