Voici un simple marque page pour vous faire part d'un article de Lennart (en anglais) à propos de changements à venir qui pourrait changer profondément la gestions des applications sur Linux.
Je vous laisse lire l'article en détail (c'est un peu long).
# Wahou
Posté par ʭ ☯ . Évalué à 8.
M'enfin, voilà encore un pavé dans la mare : une proposition d'hiérarchie des systèmes de fichiers qui permette d'atteindre le Graal :
Bien sûr, cela part d'un postulat à la Android/OsX : les applications viennent avec leur propres librairies, donc les trous de sécurité sont à combler appli par appli…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Wahou
Posté par zul (site web personnel) . Évalué à 4.
Non, pas vraiment, c'est un "peu mieux", dans le sens que les applications vont dépendre d'un "runtime", qui contient à priori les "bibliothéques" de base. Mais contrairement à aujourd'hui où il n'y a qu'un "runtime", tu pourra en avoir n en parallèle (il suffit de jouer avec LD_LIBRARY_PATH ou RPATH ou ld.so.conf pour faire la même chose aujourd'hui).
[^] # Re: Wahou
Posté par jyes . Évalué à 9.
Je ne vois pas la révolution, ni le pavé dans la marre, par rapport à 0install qui n’a jamais vraiment décollé. Ça utilise systemd et BTRFS donc c’est forcément mieux, mais à part ça ?
[^] # Re: Wahou
Posté par Jiehong (site web personnel) . Évalué à 5.
La solution proposée semble plus générique, puisque tu peux te retrouver avec plusieurs versions de ton /usr, et même avec ton /home (tout l'avantage des sous-volumes de Btrfs).
Mais l'idée semble aussi de le faire fonctionner avec ext4/xfs.
Bref, on va se retrouver avec une autre manière de faire, et on verra bien si elle décolle, puisque c'est bien le plus important. Une solution qui ne décolle pas, c'est une solution ratée.
[^] # Re: Wahou
Posté par rewind (Mastodon) . Évalué à 2.
Ça dépend, si tu l'imposes… (koff koff… systemd… koff koff)
</troll>[^] # Re: Wahou
Posté par Atem18 (site web personnel) . Évalué à 2.
Tu rigoles, mais la plupart du temps, c'est comme cela que ça marche. Par exemple, Apple a imposé l'Iphone comme téléphone de référence en 2007. Et encore aujourd'hui, beaucoup de personnes se référent à l'Iphone pour parler de téléphone, alors que de nombreux autres existent sur le marché.
[^] # Re: Wahou
Posté par thamieu . Évalué à 5.
À part ça systemd a lui vraiment décollé. Comme il sera avec le temps de plus en plus difficile de s'en passer, il imposera sa méthode là où 0install proposait la sienne.
Ça va foutre des mainteneurs de paquets au chômage, ça.
[^] # Re: Wahou
Posté par Kaane . Évalué à 10.
Ça va foutre des mainteneurs de paquets au chômage, ça.
C'est ce que se disait IBM avec System/370 - compatibilité maximale avec l'existant (System/360) et prise en compte bas niveau des hiérarchies pour éviter les émulateurs à la con et les compilations depuis les sources.
Ah, la terminologie "System 370 compatible" - si vous avez un dino sous la main, demandez-lui de vous raconter. C'est drôle…
C'est ce que c'est dit Multics, avec ses répertoires fixes et son unique langage de programmation PL/I. Le bas niveau (gestion I/O et mémoire) étant écrit en assembleur et ne devant jamais être accessible à qui que ce soit autre que les fabriquants. Unix ne serait pas ce qu'il est sans toutes les erreurs de Multics.
Netware/ZenWorks est un bel exemple de truc qui aurait vraiment pu marcher. Quel dommage que les protocoles routables aient gagnés la guerre. Au moment ou Novell s'est réveillé et a commencé à rendre leur protocole routable (au début avec du tunneling) ben il y avait plus personne.
Dans le genre il y en a eu un paquet d'autres… Qui ont fini par se vautrer aussi, il faut croire que l'informatique n'aime pas les carcans et les structures rigides.
Ceci dit j'ai toute confiance en Lennart pour réussir avec brio là ou IBM, Digital, le MIT, Novell et tant d'autres ont échoués, mais bon si j'étais mainteneur de paquet je commencerai pas ma reconversion immédiatement quand même.
[^] # Re: Wahou
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Extrait :
[^] # Re: Wahou
Posté par Adrien . Évalué à 10.
T'inquiète, il restera toujours des projets upstream avec des licences foireuses, des bugs dans tous les sens, des bibliothèques mal ou pas gérées, pas de gestion de qualité (tests, etc.).
Bref, le plus gros travail de mainteneurs de paquet n'est pas de faire le paquet. C'est de le faire bien, et le gérer dans la distribution.
# Une anecdote en passant
Posté par Mais qui suis-je ? :) . Évalué à 10.
Une petite anecdote sur la gestion des executables sous Linux/Unix, j’ai travaillé pour un gros projet de recherche en physique. Il s’avère que c’était plus simple d’écrire notre propre gestionnaire de paquet (en Python) que de tenter de fournir des paquets pour toutes les distributions des utilisateurs du code (surtout quand une fraction de ces user n’a pas le mot de passe du root)
Le principe est simple, un script python va télécharger les diverses dépendances (sur nos propre dépots) les compilers (avec les options qui vont bien) et regler LD_LIBRARY_PATH et PATH comme il faut pour que les dépendances suivantes les aie etc… Il suffit ensuite de sourcer un ficher sh/csh pour avoir le bon environnement pour trouver toute les dépendances. Et ca a été un gros gain de temps pour installer/mettre à jours l’environnement logiciel par rapport à ce que c’était avant
[^] # Re: Une anecdote en passant
Posté par GaMa (site web personnel) . Évalué à 9.
<HS>
C'est possible de savoir où c'était ?
J'ai été presta au CEA et j'ai codé un outil python qui faisait globalement ce que tu décris (et un peu plus).
Soit on parle du même outil, soit chacun refait ses trucs dans son coin.
<\HS>
Matthieu Gautier|irc:starmad
[^] # Re: Une anecdote en passant
Posté par ZeroHeure (site web personnel) . Évalué à 5.
Ce n'était pas plus simple de faire un paquet pour 0install ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Une anecdote en passant
Posté par morgotth . Évalué à 5.
Ou Nix.
Et la liste semble encore longue :)
[^] # Re: Une anecdote en passant
Posté par Antoine . Évalué à 10.
Note qu'aujourd'hui, Conda et Binstar automatisent tout ça :
http://conda.pydata.org/
https://binstar.org/
Conda est l'outil qui crée et installe les paquets, Binstar est un service permettant d'héberger tes propres paquets… Conda vient aussi avec des dépôts standard gérés par Continuum, avec pas mal de paquets autour de Python et du calcul scientifique.
(disclaimer : Continuum est l'entreprise pour laquelle je travaille)
[^] # Re: Une anecdote en passant
Posté par diorcety . Évalué à 3. Dernière modification le 01 septembre 2014 à 20:09.
LD_LIBRARY_PATH c'est bien si ton programme n'appel pas de programme en dehors de ton package, autrement l'env sera propagé.
Le mieux que j'ai trouve c'est de faire un wrapper qui appel le linker dynamique de ton package
Par exemple:
/myroot/lib/ld-2.17.so --library-path /myroot/lib:/myroot/usr/lib /myroot/bin/myprogram
# btrfs
Posté par M . Évalué à 2.
On va devoir tous passer sur brtfs si on utilise systemd ?
…
[^] # Re: btrfs
Posté par rewind (Mastodon) . Évalué à 1.
Oui, ce qui m'étonne, c'est que pour un problème de l'espace utilisateur, on propose une solution du noyau. Parce que là, ça revient à se lier à un système de fichier, c'est très embêtant. Je pense qu'on pourrait faire le même genre de chose avec git, sans souci (une branche par config) puisque git a été conçu au départ par Linus comme un système de fichiers.
[^] # Re: btrfs
Posté par WhiteCat . Évalué à 3. Dernière modification le 01 septembre 2014 à 19:58.
git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.
Ce projet semble aller exactement dans le même sens que "Fedora-Next".
[^] # Re: btrfs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Si, et heureusement : un gestionnaire de versions qui copierait intégralement chaque version gaspillerait pas mal de place. Dans ses concepts de base, Git peut être vu comme gardant chaque version intégralement, mais s'y ajoute une couche de déduplication, même interne aux fichiers.
[^] # Re: btrfs
Posté par Shuba . Évalué à 2.
La déduplication interne ne marche que pour le texte ou ça s'applique aussi aux données binaires?
[^] # Re: btrfs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
À mon avis, uniquement au texte, mais je n'en suis absolument pas sûr : à vérifier.
[^] # Re: btrfs
Posté par navaati . Évalué à 3.
Si deux binaires sont strictement identiques, la déduplication a forcément lieu puisque git adresse les objets par leur hash.
Par contre je peux pas dire si il est très efficace en cas de petite différence.
[^] # Re: btrfs
Posté par Albert_ . Évalué à -2.
git est une grosse merde ambulante pour la gestion des binaires. D'ou la naissance de projet tel que git annex.
[^] # Re: btrfs
Posté par rakoo (site web personnel) . Évalué à 7.
Elle s'applique aux données binaires.
[^] # Re: btrfs
Posté par oinkoink_daotter . Évalué à 3.
Oui, via un système de diff. BTRFS fonctionne différemment. Il est capable de repérer (au prix d'une consommation mémoire extravagante de l'ordre de 3Go par To) les blocs identiques au niveau système de fichier et est donc capable de retrouver les blocs identiques entre des fichiers qui ne sont pas liés du tout, ce que ne peut faire git. Après, je ne connais pas le détail de fonctionnement des deux outils, mais j'imagine que par contre ZFS ne serait pas capable de factoriser deux fichiers dont l'un des deux a un offset de quelques octets par rapport à l'autre.
[^] # Re: btrfs
Posté par oinkoink_daotter . Évalué à 5.
Oulah, il est tout pourri mon commentaire oO'. Ce qui est écrit ne s'applique qu'à ZFS, pas à BTRFS.
Par contre la deduplication sur BTRFS a l'air de se chercher pour le moment, entre les bedup dedup, les truc inband et le reste …
[^] # Re: btrfs
Posté par GnunuX (site web personnel) . Évalué à 5.
Git pour des binaires ? Vraiment ?
De plus, tu fais comment pour qu'une application utilise les libs d'une branche quand, en même temps, une autre application utilise une lib d'une autre branche ?
[^] # Re: btrfs
Posté par xcomcmdr . Évalué à 7.
Ben non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: btrfs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Ouais, on dit ça maintenant, mais j'attends de voir. Avec Lennart, je me méfie. (Mais si, je vous assure, je ne fait que maintenir udev dans le même dépôt que systemd mais ça restera tout à fait indépendant, je vous jure. Mais bien sûr, et maintenant ?)
[^] # Re: btrfs
Posté par ariasuni . Évalué à 1.
A-t-il jamais promis cela?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: btrfs
Posté par Batchyx . Évalué à 3.
De toute façon il peut pas prétendre supporter les systèmes embarqués avec brtfs vu que pas mal d'entre eux ont de la flash sans FTL qui ont besoin de FS spécialisés comme ubifs ou yaffs2 pour éviter que la flash crame dans l'heure.
[^] # Re: btrfs
Posté par deasy . Évalué à 1.
Il me semblait que btrfs est adapté à la nand.
# vers la "privatisation" du système
Posté par hervé Couvelard . Évalué à -10.
Au fur et à mesure que l'on empile surcouche sur surcouche, que l'on complexifie la chose pour "arranger tout le monde, que l'on choisit des solutions techniques peut être meilleures mais qui ont besoin de plus de concepts pour être compris, on s'éloigne du libre.
Ce n'est pas libre parce que c'est gratuit, c'est libre parce que le commun des mortels peut avec un peu de travail et de volonté entrer dans le coeur et comprendre (chacun à son niveau). Bien sur, celui qui a choisi ubuntu aura du mal avec debian ou slack ou fedora ou gentoo ou suse ou … mais dans l'ensemble il fera vivre l'écosystème.
Demain si on veut unifier tout en complexifiant les concepts, seuls les "ingénieurs" arriveront à comprendre et le libre sera privatisé, au main d'une poignée.. avec peut être des utilisateurs (si c'est gratuit) et la base des contributeurs potentielles se restreindra et les 1% deviendront peut être 5%, mais à quel prix.. celui d'utilisateurs qui seront comme sous windows, incapable de résoudre un soucis si ils n'arrivent pas à télécharger l'utilitaire merdique qui installera en même temps une extension firefox que les gens ne sauront pas désintaller car la fonctionnalité sera trop profondément enfouie dans les sous menus.
Alors je peux bien comprendre que cet avenir est un avenir radieux pour les grosses boites comme canonical ou red hat mais pour l'utilisateur de base… pourquoi se faire chier avec un truc différent, qui aura toujours les même problèmes avec les pilotes, avec le matériel, et qui en plus aura les même inconvénient que windows : uniforme, incompréhensible, hors de porté.
Demain les virus et autre saloperies windowsienne n'auront même plus à s'embêter au niveau compatibilité entre les machines, on leur offre un autoroute de compatibilité, c'est cool…
[^] # Re: vers la "privatisation" du système
Posté par navaati . Évalué à 7.
Si tu t'intéressais au lieu de râler, yaurais plus de gens pour comprendre le système.
Pasque franchement, c'est pas si compliqué. Et je trouve que c'est moins compliqué que les ignobles montagnes de shell qu'y avait avant (oui je viens de me plonger dans le code de debian-installer et c'est juste un gros traumatisme)
[^] # Re: vers la "privatisation" du système
Posté par nanard . Évalué à -10.
Oui mais bon, le gros du probléme c'est qu'on s'éloigne d'une façon radical de la phylosophie d'Unix "Un outils fait une chose et il le fait bien". Perso systemd je suis pas fan, je connais pas vraiment, mais je suis pas fan, tu te rends compte que pendant un moment il était aussi question que systemd gére le DNS et le ntp !! wtf.
Bordel, pour gagner 10 seconde au démarrage que de changements, c'est ridicule.
Mea culpa je n'ai pas lue l'article en question dans ce journal.
Allez tous vous faire spéculer.
[^] # Re: vers la "privatisation" du système
Posté par navaati . Évalué à 10.
Wep donc nan, faut arrêter avec ça aussi.
Bordel de marde, systemd ne gère pas le dns et le ntp. Le projet systemd fournit des outils qui les gèrent, mais ça n'est absolument pas dans l'init systemd, et ce sont des outils totalement optionnels.
Sinon, c'est comme si tu disais « ZOMG, OpenBSD gère SMTP ! On est loin de la philosophie Unix "Un outils fait une chose et il le fait bien" » à cause de OpenSMTPd sans vouloir comprendre que le projet OpenBSD n'est pas le noyau OpenBSD.
[^] # Re: vers la "privatisation" du système
Posté par Letho . Évalué à 9. Dernière modification le 01 septembre 2014 à 23:18.
Heu… Désolé, mais non.
Le kernel Linux n'est sans doute pas la chose à laquelle il est techniquement le plus facile de contribuer. Je dois en conclure qu'il n'est pas libre ? La liberté d'un logiciel, c'est une question de licence, pas de complexité plus ou moins grande du code concerné.
Ce que tu semble déplorer, c'est que les distributions Linux adoptant ce genre de technos deviennent de moins en moins « KISS ». Peut-être. Les technos en question n'en sont pas moins libres et documentées.
Quant à l'utilisateur souhaitant contribuer, je pense qu'il considérera que pouvoir distribuer simplement son logiciel est un plus, pas une régression. Et pour celui s'intéressant au basses couches du système, je ne doute pas qu'il saura s'adapter.
[^] # Re: vers la "privatisation" du système
Posté par Kaane . Évalué à 10.
Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.
Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.
Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome… (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)
Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.
Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd…)
Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.
[^] # Re: vers la "privatisation" du système
Posté par gnumdk (site web personnel) . Évalué à 9.
Ah, moi j'ai surtout l'impression d'attendre avec impatience d'avoir systemd sur le prod parce que avec lui, j'aurais peut être plus d'information quand un service reste bloqué sur un /etc/init.d/service start … Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…
[^] # Re: vers la "privatisation" du système
Posté par Kaane . Évalué à 4.
Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…
Autant les logs activé dès les premières phases du boot je suis assez fan, autant ça fait longtemps que le plantage/le freeze d'un daemon au démarrage ne bloque plus le boot à moins qu'il ne soit strictement nécessaire (c'est clair que si lo plante, ou si le FS échoue le montage en RW c'est foutu - mais c'est le cas pour tout le monde.)
L'immense majorité de systèmes d'init de nos jours font du démarrage parallèle et sont capables d'envoyer des SIGTERM/SIGKILL à un daemon qui reste bloqué. Ca fait des années que tous les BSD ont ce type de système, et même sous Debian (pourtant gros partisans du SysV init jusque très récemment) depuis Wheezy on a tout ce qu'il faut.
[^] # Re: vers la "privatisation" du système
Posté par gnumdk (site web personnel) . Évalué à 4.
Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…
Je rien vu dans les logs, pas eu le temps de chercher…
[^] # Re: vers la "privatisation" du système
Posté par Kaane . Évalué à 5.
Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…
Attention, le fait qu'il soit possible d'écrire des scripts propres ne veut pas dire que tous les scripts sont propres.
Même sous systemd si je suis assez bête pour créer un service qui fait "while 1" avec un timeout à 0 et que je rend tout mon boot dépendant strictement de la fin de l’exécution de ce service - ben mon boot va figer.
Pour freezer le boot d'un systemd il faut y aller, alors que sous les inits classiques il faut faire attention pour éviter toute possibilité de freeze. C'est un plus de systemd (mais qui a un prix au niveau logs/processus/mémoire) mais clairement pas une exclusivité.
Ceci dit quand on commence à définir des scopes et des slices à la mano, on a vite fait de faire des boots qui freezent. (Peu de gens joueront à ce jeu. Certes)
[^] # Re: vers la "privatisation" du système
Posté par gnx . Évalué à 4.
Exactement. Quand j'étais passé de DOS/Windows à Linux, c'était parce que j'avais plaisir d'une part à voir ce qui était sous le capot au lieu d'avoir affaire à un truc mystérieux/aléatoire et à pouvoir éventuellement le contrôler/configurer et d'autre part à pouvoir à comprendre rapidement des parties importantes en lisant leur code. Accessible, compréhensible, démystificateur.
Maintenant, le code est bien sûr toujours libre, mais vais-je étudier les millions de lignes de code du noyau, les millions de lignes d'un navigateur, les dizaines de millions de ligne d'un bureau, les dizaines de milliers de ligne de C++ cryptique d'un projet qui appelle la libfoo qui elle appelle la libbar qui elle appelle la libtoto ?
Eh bien non, je n'utilise quasiment plus Linux que comme si c'était un Windows, et ceci alors qu'en tant que vieux con, je me prive pourtant d'un certain nombre de surcouches dites « modernes » qui singent Windows/OS X pour être Michu-compatibles.
Quand tu écrivais « en complexifiant les concepts, seuls les "ingénieurs" arriveront à comprendre », tu aurais pu ajouter « … comprendre la partie sur laquelle ils se sont spécialisés », car la complexification devient telle que personne ne peut s'intéresser à beaucoup de parties. À part peut-être le génie hanséatique, Dieu nous préserve.
[^] # Re: vers la "privatisation" du système
Posté par groumly . Évalué à 10.
Ouais, on devrait freezer tous les projets libres.
Hors de question d'avancer si gnx n'est pas capable de comprendre le source code.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: vers la "privatisation" du système
Posté par hervé Couvelard . Évalué à 5.
Il y a une "petite" différence entre freezer des projets, garder une compatibilité des libs pendant 15 ans et de simplement tout chambouler, parce que tu as les moyens de payer, pour "unifier".
Il me semble que ceux qui râlent le plus sur le manque d'uniformisation sont ceux qui n'utilisent pas. Maintenant vous pensez que changer les fera venir ? ils continueront à trouver autre chose. C'est un truc que j'ai appris au cours de mon existence : les gens ont des objections pour ne pas faire une chose. Ces objections sont des "excuses" pour ne pas faire, et très rarement des causes. Si tu changes pour leur faire plaisir, tu perds une partie de ceux que tu as, et tu ne gagnes pas ceux qui avaient ces objections : ils en trouvent d'autre.
J'ai la bêtise de penser que les modifications, sont, comme en médecine, un équilibre entre bénéfice/risque. Maintenant si cela va à tout le monde, parfait, mais je peux dire que j'ai vu la communauté évoluer au cours des 10 dernières années, et la notion de liberté se pastélliser au profit de la notion d'efficacité, au profit de l'uniformisation soit disant nécessaire (mais pour qui ?).
Oui le code est toujours libre, mais ce n'est pas la question. D'ailleurs le code doit être commenté en anglais avec des noms de variables en anglais aussi, pourquoi pas en coréen ? ou en chinois ? il resterait tout aussi libre, mais peut être moins accessible.
Maintenant ce que l'on voit surtout ce sont les gens s'écharper parce qu'ils sont convaincu de leur vérité, qui sont condescendants en diable. Ils ne peuvent même pas imaginer que dans le discours de l'autre il y a une piste de réflexion intéressante, c'est tellement simple de basher.
tiens : ouais pas la peine de discuter tant que groumly ne comprendra pas de quoi on parle.
ou : on peut faire ce que l'on veut parce que groumly y voit pas ce que cela implique.
[^] # Re: vers la "privatisation" du système
Posté par ariasuni . Évalué à 3.
En espéranto! → […]
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: vers la "privatisation" du système
Posté par dinomasque . Évalué à 1.
C'est marrant, c'est le contraire pour moi.
Je maitrisais à fond mon système MS-DOS (les arcanes d'autoexec.bat et de config.sys pour maximiser la mémoire conventionnelle requise par les jeux gourmands n'avaient plus de secrets pour moi).
Je maîtrisais tout bien mon Windows 3.1.
Ensuite j'ai plus rien maîtrisé du tout avec Windows 95 et pis les Linux que j'ai eu ensuite et qui étaient d'une complexité effarante (dès 1997 !). Plus ça va, plus c'est pire, aujourd'hui quand tout ne marche pas en plug&play sous Linux, c'est l'enfer à réparer/bidouiller sans maîtriser des zilliards de composants systèmes.
J'ai fait mon deuil de la compréhension des OS modernes; en choisissant ceux qui "juste marchent" (BeOS, Mac OS X, …), il n'y a plus trop de questions à se poser.
BeOS le faisait il y a 20 ans !
[^] # Re: vers la "privatisation" du système
Posté par Dr BG (site web personnel) . Évalué à 10.
T'es sûr que ce n'est pas simplement l'envie de bidouiller qui décroit avec l'age ? Perso, je pense que c'est mon cas.
Je n'ai pas franchement l'impression que mon système actuel soit plus compliqué à bidouiller que la RedHat 5.2 que j'installais dans ma jeunesse (je me trompe peut-être), mais je sais que j'ai moins envie de le bidouiller parce que :
1 - Ça m'amuse moins ;
2 - Ça merde moins, donc j'ai moins besoin de le faire.
[^] # Re: vers la "privatisation" du système
Posté par gnumdk (site web personnel) . Évalué à 8.
Je pense d'ailleurs que c'est pour cela que nous sommes nombreux sous ArchLinux, histoire de donner plus de chance à l'action… Et encore, c'est assez rare…
[^] # Re: vers la "privatisation" du système
Posté par dinomasque . Évalué à 5.
Oui, tout à fait.
J'ai un pote qui en a eu marre de "bidouiller" lui aussi mais qui a eu envie de mettre les mains dans le cambouis quand même. Il est passé sur OpenBSD, un système qui se veut "simple" dans le sens ou quelqu'un qui veut ouvrir le capot peut arriver à comprendre comment fonctionne le système avec des efforts raisonnables.
C'est plutôt les incantations vaudou pour faire marcher Windows et les lignes de commande à copier/coller sans les comprendre des forums linuxiens pour tenter de faire marcher un truc qui ne marchera de toute façon pas qui m'ont fatigué.
BeOS le faisait il y a 20 ans !
[^] # Re: vers la "privatisation" du système
Posté par dinomasque . Évalué à 7.
Félicitations ! Tu es mûr pour essayer OpenBSD :)
BeOS le faisait il y a 20 ans !
[^] # Re: vers la "privatisation" du système
Posté par deasy . Évalué à 2.
Trop gros, passera pas.
# Enfin
Posté par Bruno Coudoin (site web personnel) . Évalué à 10.
C'est vraiment bien de voir une initiative pour faire évoluer la distribution des applications sur les distributions. Le modèle actuel fonctionne bien pour certains cas d'utilisation mais il échoue à adresser certains besoins basiques comme par exemple pouvoir utiliser une version spécifique d'un logiciel ou même d'en avoir plusieurs d'installées.
En tant que développeur 'upstream' mon principal reproche que je fais au système de packaging actuel c'est qu'on se retrouve coupé des utilisateurs. Impossible de dire quand ton application sera disponible sur telle distro. Tu te retrouves souvent avec des utilisateurs qui ont plusieurs années de retard sur la version de ton soft tu coup tu perds la dynamique sur les retours de bugs.
La proposition de Lennart me semble excellente car il résout une équation délicate, garder ce qui est bien dans le modèle actuel des distributions tout en ouvrant de nouvelles possibilités.
[^] # Re: Enfin
Posté par hervé Couvelard . Évalué à 5.
C'est vrai en partie, maintenant peut être que tu devras gérer en plus les problématiques d'effets de bords avec ta dernière applis qui merdera sur certaines machines ,parce que les libs systèmes sont un peu différentes et en conflit avec ta version des lib et avec des appels croisés. (en ce cas, autant faire des paquets statiques.)
Le truc avec les distributions c'est que l'écosystème est plus ou moins testé et cohérent. tu tires des packages pour TA version, compilés avec les bonnes libs. C'est vrai que si tu as 4 versions de distro de retards tu auras un très vieux soft. Mais qu'est-ce qui se passera avec ce système si tu as 4 versions de distro de retard ? la libc sera plus la bonne et sera plus compatible ascendante avec celle qui a servi à compiler, donc paff pastèque.
Le problème de fond de la non compatbilité c'est plus les versions de lib que l'arborescence (un targz compilé statique avec un script pour les ld_preload) et ca marche pour tout. Alors oui, on peut embarquer toutes ses versions de libs en compilant statique et ca marche SAUF pour les libc trop vielle.
Maintenant attendons le résultat, mais je ne suis pas persuadé que ca aide les empaqueteurs. Tu devras juste te démerder pour faire ton paquet miracle et prier pour que ca merde pas. Et si ca merde sur un environnement quelconque, tu seras bien seul pour comprendre pourquoi ca ne marche pas dans un environnement que tu ne connais pas et que l'utilisateur connaîtra encore moins.
Les paquets spécifiques aux distros ca permet à ceux qui les font de bien connaître ce qui se passe.
[^] # Re: Enfin
Posté par Bruno Coudoin (site web personnel) . Évalué à 8.
Vis à vis d'un développeur upstream c'est la situation actuelle. Ton appli est packagé pour chaque distros avec un ensemble et une combinaison de librairie que tu n'a jamais testé. Tu peux avoir fais des efforts pour valider ton appli avec une combinaison de dépendance mais il y a peu de chance que la distro fasse les mêmes choix.
Concernant les problèmes de libc multiples, si tu regardes bien la proposition de Lennart c'est supporté : "Note that in this design apps are actually developed against a single, very specific runtime, that contains all libraries it can link against (including a specific glibc version!). Any library that is not included in the runtime the developer picked must be included in the app itself."
# et la sécurité ?
Posté par eric gerbier (site web personnel) . Évalué à 3.
Coté utilisateur, c'est cool, on peut installer des soft sans attendre que ces faignants d'administrateur s'occupent de nous :).
Coté administrateur, comment on maintient une machine à jour des correctifs de failles de sécurité ?
[^] # Re: et la sécurité ?
Posté par Atem18 (site web personnel) . Évalué à 0.
D'après ce que j'ai compris, il te suffira de télécharger le nouveau "bundle" et de redémarrer le "container". Et tout devrait fonctionner comme si de rien n'était.
[^] # Re: et la sécurité ?
Posté par claudex . Évalué à 8.
En gros, c'est de la security by Appstore, autant dire qu'il n'y en a pas. (que le premier développeur upstream qui s'abonne aux mailings lists de toutes ses dépendances pour suivre les failles de sécurité et les applique rapidement me jette la première bière).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et la sécurité ?
Posté par xcomcmdr . Évalué à 3.
C'est pas que j'ai confiance dans les AppStores, mais s'il est "trop dur" de rester à jour au niveau des correctifs de sécurité, les solutions techniques pour améliorer la sécurité tout de même ne sont pas inexistantes :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: et la sécurité ?
Posté par claudex . Évalué à 4.
Une sandbox, c'est bien pour ton système, pas du tout pour ton appli. Ça veut quand même dire que si c'est ton client mail qui se fait toucher, toutes les adresses récentes peuvent se faire spammer. Si c'est ton navigateur, n'en parlons pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et la sécurité ?
Posté par xcomcmdr . Évalué à 3.
On a vu à quel point le mythe de "code relu par tout le monde" a vécu avec OpenSSL. Faire une vraie relecture du code (ou pas, d'ailleurs…) n'empêche pas d'utiliser des solutions techniques (sandbox, secure boot, binaires signés numériquement, capabilities par application, …) visant à améliorer vraiment la sécurité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: et la sécurité ?
Posté par GnunuX (site web personnel) . Évalué à 4.
Je m'intérroge sur le sens de cette phrase …
Je vois 2 solutions :
[^] # Re: et la sécurité ?
Posté par xcomcmdr . Évalué à 3.
Ahah, très drôle. Sauf que c'est à côté de la plaque.
Il l'a relu après que la faille soit dans la nature depuis des années, exploitée, et exploitable.
Normalement, le but de la relecture de code, c'est d'éviter les failles. Pas de les découvrir après que le code ait été écrit et déployé en faisant "oops!".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: et la sécurité ?
Posté par barmic . Évalué à 4.
Rien est jamais garantie en terme de qualité logiciel. Celui qui te dis que le fait de faire de la relecture, d'utiliser tel langage, tel analyseur statique ou autre donne la garantie de ne pas avoir de faille est un bouffon. De même pour le sandboxing par exemple. Java et javascript ont des modes de sandboxe qui ont eu leur jolie CVE exploitables et exploitées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: et la sécurité ?
Posté par xcomcmdr . Évalué à 1.
Et c'est pour ça que le mythe de la relecture linuxien/LL : "c'est du code relu par tout le monde, donc de qualité" c'est pour les gogos.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: et la sécurité ?
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 03 septembre 2014 à 22:46.
au moins le code libre le permet, c'est toujours mieux^Wplus crédible qu'un Microsoft qui tente de se faire passer pour un chantre de la sécurité (sans doute que tellement attaqué^Wtroué auparavant, il ne peut pas faire autrement… ne pas me lancer sur java :p).
[^] # Re: et la sécurité ?
Posté par claudex . Évalué à 3.
Je n'ai jamais dit qu'une sandbox était un mauvais point mais que ça n'améliorait pas la sécurité de l'application pour elle-même (sauf si elle fait des sandbox internes mais ce n'est pas le sujet) et que ça peut être une fuite d'information presque aussi grave que pour tout le système. Je ne vois pas ce qu'OpenSSL vient faire dans l'histoire, à ce que je sache, la plupart des applications des marketplaces ne sont pas libre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et la sécurité ?
Posté par hervé Couvelard . Évalué à 4.
ouais, mais on en revient à la même situation qu'avant : nouveau bundle, nouvelles versions des libs : les paquets universels qui s'appuient sur la version que tu avais ne marche plus. Problèmes entre les paquets qui attendent une version et ceux qui en attendent une autre… ca ne semble pas changer grand chose. enfin.
[^] # Re: et la sécurité ?
Posté par eric gerbier (site web personnel) . Évalué à 2.
En séparant les rôles, comment moi, qui suis administrateur d'une machine sur laquelle mes utilisateurs installent
n'importe quoileurs applications, je fais pour maintenir un bon niveau de sécurité, sachant que eux ne, feront pas les mises à jours ?De mon point de vue, utilisateur et administrateur, ce n'est pas le même métier, pas les mêmes compétences.
# Il a le mérite de bien vendre sa "came".
Posté par Le Gab . Évalué à 2.
Qu'on le veuille ou non, Lennart fait un vrai travail pédagogique. Et de réussir à garder "ce calme" alors qu'il est trollé à longueur de billets, ça force le respect.
Sinon l'idée est séduisante mais un poil overkill, non? On voit aussi qui cela cible, on parle utilisateur mais je crois avoir lu au moins 10 occurences de "vendor", c'est pas vraiment le terme qu'on utilise pour parler de producteurs de LL.
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par xcomcmdr . Évalué à 4. Dernière modification le 02 septembre 2014 à 23:17.
Sa "came" est alléchante et bien présentée, et logique.
On peut pas en dire autant de 99% des trolls
anti-systemdanti-Lennart.;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par Jiehong (site web personnel) . Évalué à 3.
Il y a même un site de trolls dédié au sujet tant il est apprécié !
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par Misc (site web personnel) . Évalué à 3.
C'est rien, tu as loupé "systemd apporte l'apocalypse"
http://www.infoworld.com/d/data-center/systemd-harbinger-of-the-linux-apocalypse-248436?page=0,0
J'ai presque l'impression de voir une parodie de foxnews.
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par claudex . Évalué à 3.
Euh si, on voit souvent ce terme.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par Antoine . Évalué à 3.
"vendor", c'est grosso modo le distributeur en anglais. Ce n'est pas forcément l'auteur du logiciel.
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par claudex . Évalué à 3.
Oui, c'est vrai, je pensais distribution et assimilés.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# De la dureté des diamants ou l'importance de la spécification d'interfaces.
Posté par GTof . Évalué à 6.
L'approche a beau être très intéressante, et à le mérité d'apporter une réponse dans certains cas mais elle ne répond pas au véritable problème: avoir des API/ABI/Spécification durables. Même si l'idée est intéressante sur le papier elle abouti à une multiplication des runtimes. Mettons que j'ai une application qui cesse d'être maintenue, dois je garder un snapshot d'une distribution compatible? Que ce passe t'il si j'ai une vingtaine ou une cinquantaine d'application non maintenues? Dois je me retrouver avec autant de snapshots? On va finir par avoir sur chaque machine la collection complète de toutes les révisions d'une distribution majeure.
Et même en le faisant cela n'empêcherait pas certaines incompatibilités. Mettons que sur ma machine, ma carte graphique requiert des drivers recents qui eux ont besoin de biblothèques récentes (libY.so). Mettons également que je souhaite faire tourner une application OpenGL vieille de 10 ans ne fonctionnant qu'avec une version précise (et ancienne) de cette même libY.so . Il n'est pas possible (tout au moins avec le chargeur dynamique GNU) de charger en mémoire deux versions d'une même bibliothèque avec même nom de fichier et même SONAME.
Fournir une application avec ces dépendances est une bonne idée (d'ailleurs déjà largement exploitée) mais pour être rellement fonctionelle il faut pouvoir faire tourner l'application dans le même environnement que celui pour lequel elle a été conçue. Ceci inclus même les composant les plus fondamentaux de l'OS que sont la libc, X, … . Il n'y a donc pas d'autre choix que de faire tourner chaque (groupe d') application dans une machine virtuelle. Ca tombe bien, Linux est bon dans le domaine.
Il n'en reste pas moins que même si la solution peut être viable, elle demande quand même une multiplication des runtimes. Se forcer a avoir des API/ABI durables est certes plus contraignant mais plus simple sur le long terme.
[^] # Re: De la dureté des diamants ou l'importance de la spécification d'interfaces.
Posté par Anthony Jaguenaud . Évalué à 7.
Si tu peux. La bibliothèque standard sur ton PC est dans /lib ou /usr/lib. Il suffit de lancer ton appli vieille de 10 ans dans un environnement avec un LD_LIBRARY_PATH qui contient le chemin de ta libY.so vieille avant celle libY.so de ton /lib .
L'OS n'a aucun mal à avoir plusieurs version de la même lib en RAM.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.