xcomcmdr a écrit 3537 commentaires

Mais pour d'autres usages tels que édition/traitement de texte malheureusement non (LibreOffice est très bien mais malheureusement ni iso-fonctionnel, ni pleinement compatible avec MS-Office, et malheureusement beaucoup plus lourd - de vieilles versions de Office (e.g. Office XP) s'ouvrent en un clin d'oeil, alors que LibO est un veau sur le vieux netbook de mon père…)

Faut aussi remettre les choses en perspective. Windows XP, tout comme Office XP, est taillé pour des machines qui datent de 2001.
La configuration typique en 2001, c'était ça :
CPU Intel Pentium II 233 MHz
66 MHz FSB
Memory 1x 64 MB SDRAM PC-66 (generic)
Motherboard Abit AB-BX6, Intel 440BX Chipset
Graphics Card Nvidia Riva TNT2 Ultra

Bon allez, peut-être ça avec de la chanche thune, plein de thune :
Intel Pentium 4 1500 MHz
CPU Intel Pentium 4 1500 MHz
400 MHz FSB
Memory 2 x 128 MB RIMM PC-800 (Samsung)
Motherboard ASUS P4T Revision: 1.06
Bios: 1001
Hard Drive 30,7 GB IBM DTLA - 307030
UDMA 100, 7200 rpm, 2 MB Cache
Graphics Card
RIVA TNT2 ULTRA
Memory: 32 MB SDRAM
Chip speed: 145 MHz
Memory speed: 200 MHz

Avec, pour Office XP, un format (.doc, .xls) binaire difficile à comprendre parce que optimisé pour la vitesse, pas la compréhension humaine (et il y a aussi beaucoup de dette technique derrière, mais ça c'est autre chose).

Et puis, un netbook aujourd'hui se tape un disque dur à 5400 RPM, qui est de loin le premier goulot d'étranglement dans le temps de chargement d'une application.

Le CPU, la RAM (1 Gb ça suffit largement à XP et à LibreOffice), c'est secondaire pour le temps de chargement.

Après pour les performances sur opérations CPU-bound, un Intel Atom c'est toujours un très mauvais choix…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

(rôle des différentes briques logicielles, système d'init, services etc…)

J'ai pris la version facile : je l'ai fait avec Archlinux.

Surtout lors du passage de SysV à systemd, c'était bien drôle.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Windows 8 ouvre les PDFs sans devoir rajouter un logiciel tiers, faut se mettre à jour.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Par défaut depuis Vista, même dans le cas d'un seul utilisateur local, ce dernier n'est pas administrateur.

Si l'utilisateur est Administrateur, c'est qu'il a modifié son compte en ce sens (c'est pas très sécurisé, mais c'est son problème).

Le dernier Windows où le premier utilisateur créé était Administrateur, c'était XP.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben non, vu qu'il y a des tests releases

Et la dernière date de 2006.

Et pourquoi il y a des tests releases ?
Parce que ça bug ! ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Mais tu es quand même administrateur du poste sur tous les Windows récents, par défaut (même si ensuite tu peux ajuster les droits comme tout OS moderne).

Non, plus depuis Vista (2006) et sa fameuse UAC (=~gksu).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Sauf que j'ai démontré que même les logiciels soi-disant "triviaux" (rm, ls, …) évoluaient toujours.

J'ose à peine encore demander un exemple d'un logiciel "fini superbement".

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Windows à toujours considéré que tout le monde était administrateur.

Ce n'était plus vrai dès 1993 avec windows NT 3.1

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est bien, je n'ai jamais dit ça. Mais pour le comprendre, faut sortir du cliché "logiciel qui n'évolue pas = logiciel parfait." ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Passer à WPF c’est pas faire évoluer une application mais la réécrire.

Mais LOL. Elle doit être bien mal fichue ton application si changer la couche de présentation t'oblige à la réécrire de zéro.

Par contre GNU bc n’a pas eu de release depuis 2000, c’est qu’il doit être mort et inutilisable, n’ayant plus sa place que dans les musée de l’informatique, n’est-ce pas ?

C'est dommage, bc aurait pu rajouter des modes de calcul, par exemple.
Ce n'est pas parce que un logiciel n'évolue plus qu'il est feature-complete, hein. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.

Et depuis Windows 7 elle est passée à WPF pour l'aspect présentation, et s'est enrichie de modes de fonctionnement additionnels. Comme quoi, même les outils "triviaux" changent.

En fait, même notepad a changé.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

ajout : dans coreutils je doute que ce soient les logiciels triviaux qui subissent les mises à jour.

Ben si : rm, cp, et ls, au moins.

J'oublie rien. J'ajoute même que ce genre de truc ne DOIT PAS faire partie du cœur du logiciel, pour pas se retrouver dans 20 ans 150 000 lignes de code mort servant à gérer des langages obsolètes.

Que cela fasse partie du coeur ou non ne change pas le fait que le logiciel évolue bel et bien constamment quand il est maintenu.

Pour répondre à la majeure partie de ton commentaire : la conclusion de ta démonstration c'est qu'un logiciel n'est jamais fini, tu ne peux pas l'utiliser comme hypothèse.

Tu n'y réponds pas du tout. Je t'ai donné des exemples de logiciels triviaux qui évoluent encore, et tu en es encore à dénier la réalité, sans le moindre exemple du contraire.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben non. Même les logiciels triviaux évoluent toujours.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Les bugs (failles de sécurités incluses) sont en nombre fini dans un logiciel quelconque, en les corrigeant un par un sans en introduire de nouveau, au bout d'un moment, il n'y en a plus.

Ben non, les "bugs" ça inclut les nouvelles fonctionnalités, les changements quand le compilateur change et que ça impacte ton système de build, ou que tu veux en profiter (par exemple même le support pour C90 n'est pas universel…)

Et corriger un bug sans en introduire de nouveau, c'est pas si simple que ça…

Des exemples, les logiciels triviaux : cat, rm, echo, cp, true, false…

Qui évoluent toujours.

max-laptop% pacman -Qo /usr/bin/cat
/usr/bin/cat appartient à coreutils 8.22-2
max-laptop% pacman -Qi coreutils

Nom : coreutils
Version : 8.22-2
Description : The basic file, shell and text manipulation utilities of
the GNU operating system
Architecture : x86_64
URL : http://www.gnu.org/software/coreutils
Licences : GPL3
Groupes : base
Fournit : --
Dépend de : glibc pam acl gmp libcap openssl
Dépendances opt. : --
Requis par : ca-certificates linux mkinitcpio netctl util-linux
Optionnel pour : usbutils
Est en conflit avec : --
Remplace : --
Taille installé : 13388,00 KiB
Paqueteur : Allan McRae allan@archlinux.org
Compilé le : mar. 17 déc. 2013 02:59:13 CET
Installé le : lun. 06 janv. 2014 23:26:23 CET
Motif d’installation : Explicitement installé
Script d’installation : Oui
Validé par : Signature

Dans les logiciels non triviaux : un bibliothèque pour manipuler des objets X. Si elle est correcte, portable, et si ses performances sont satisfaisantes, pourquoi y toucher ?

Parce qu'on l'utilise et qu'on découvre des bugs ? Qu'on se rend compte que l'API est mauvaise ?
Qu'on veut cibler une nouvelle plateforme ?

Les autres logiciels changent, les besoins changent, les compilateurs changent, les langages changent (exemple : passage de Python2 à Python3)…. Tôt ou tard, ton logiciel sera condamné à évoluer.

Sinon, des logiciels répondant à un usage précis qui ne change pas, par exemple éditer du texte, les usages n'ont pas changé depuis les les années 60

Ça dépend, si tu édites du code, on a néovim qui sort aujourd'hui encore…

il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.

Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, … (pour le code)

Voire le correcteur ortographique/grammaticale (pour les trucs du genre LibreOffice Writer), l'insertion d'images/tableaux au sein du texte, le support pour l'impression, etc…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

T'es pas obligé d'utiliser Virtualbox en plein écran, tu peux maximixer la fenêtre, ce qui te laisse la barre des tâches Windows en dessous.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben oui c'est un logiciel mort.

Quid des failles de sécurité ? Des bugs ? (montre moi un seul logiciel parfait !) Des nouveaux usages, nouveaux besoins ?

Un cas où tout cela ne change pas, ça n'existe pas. Quand le logiciel ne change pas, c'est qu'il est mort.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Dans le cas de Debian, ce qui n'est pas normal, c'est que le mainteneur est intervenu hors workflow du projet. A mon sens, une distrib n'a pas a faire des patchs à chaud sur ce genre de libs

Ce genre de patch ne serait jamais arrivé sur Arch (tant que ça compile/fonctionne, on y touche surtout pas). ;-)

------------> []

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Hey dude : chill the crap out ! :o

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Dommage qu'il n'y ait pas d'applications Metro (quand au nombre de Windows 8 en circulation, il est ridiculement faible. Or, je ne crois pas qu'une application Metro soit compatible Windows 7).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est quoi un émulateur, si ce n'est une VM ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le but de systemd est de profiter des spécificités de Linux, et de fournir un ensemble d'outils en espace utilisateur permettant d'utiliser et de profiter des cgroups, pas de faire quelque chose de générique.

On peut faire un système d'init qui s'adapte selon le kernel, mais dans ce cas on écrit autre chose qu'un systemd.

L'exemple de Cairo est donc hors sujet, d'autant plus que c'est une bibliothèque graphique, pas un système d'init (le problème est totalement différent).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Oh ben ça se voit que certains ne savent pas lire.

Systemd, une fois compilé, est composée d'une soixantaine de binaires (notamment pour des raisons de sécurité), pour la plupart remplaçeables.

systemd /usr/bin/bootctl
systemd /usr/bin/hostnamectl
systemd /usr/bin/journalctl
systemd /usr/bin/kernel-install
systemd /usr/bin/localectl
systemd /usr/bin/loginctl
systemd /usr/bin/machinectl
systemd /usr/bin/systemctl
systemd /usr/bin/systemd-analyze
systemd /usr/bin/systemd-ask-password
systemd /usr/bin/systemd-cat
systemd /usr/bin/systemd-cgls
systemd /usr/bin/systemd-cgtop
systemd /usr/bin/systemd-coredumpctl
systemd /usr/bin/systemd-delta
systemd /usr/bin/systemd-detect-virt
systemd /usr/bin/systemd-inhibit
systemd /usr/bin/systemd-machine-id-setup
systemd /usr/bin/systemd-notify
systemd /usr/bin/systemd-nspawn
systemd /usr/bin/systemd-run
systemd /usr/bin/systemd-stdio-bridge
systemd /usr/bin/systemd-tmpfiles
systemd /usr/bin/systemd-tty-ask-password-agent
systemd /usr/bin/timedatectl
systemd /usr/bin/udevadm

(il y en a aussi beaucoup que je n'utilise jamais, du genre hostnamectl ou timedatectl)

Là, on met juste le code de plusieurs bibliothèques en commun pour réduire le code dupliqué, ça ne change strictement rien pour les utilisateurs (à part qu'il y a potentiellement moins de bugs, et un peu moins de mémoire utilisée).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

J'ai essayé Linuxfr pendant un mois avec différents navigateurs mais j'ai laissé tomber, trop de bruit pour rien.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

tu n'as que 140 caractères et c'est noyé d'informations sans intérêt.

HAHAHA

Facebook n'est pas vraiment utilisé pour suivre l'actualité de sites externes.

HAHAHA ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Certains accords, qui semblaient unifier, certains acteurs majeurs du monde unix (AT&T et Sun) a déjà créé ce qu'on a appelé la guerre des unix. Cela a été une des causes de l'essor de linux, pendant ces chamailleries entre tous les acteurs, linux s'est incrusté dans le vide créé. Ici, on doit encore voir ce que va donner…

Tu oublies que tous ces Unix étaient propriétaires et proposaient des standards propriétaires, ce qui étaient un frein majeur pour pouvoir migrer d'un Unix à l'autre.
Linux n'a pas ce frein.

De plus, l'Unix Wars était un guerre commerciale féroce (souvent via des procès, de ce que j'en comprends).

Certes, RedHat, Canonical, SUSE, et compagnie sont des concurrents. Mais ce sont surtout des entreprises qui coopèrent (standards freedesktop, Upstart utilisé dans Fedora, Canonical qui passe à systemd, …), et qui n'opèrent parfois même pas sur le même segment du marché (Canonical s'oriente vers le desktop, RedHat pas vraiment).

Bref, si on veut regarder une guerre avec des avocats et des procès, il y a bien plus d'actions du côté des patent trolls (SCO vs. IBM, par exemple). ;-)

Cela est source d'incompatibilité avec les autres acteurs du monde des unix ;

C'était déjà incompatible avant. Même sans changer de kernel. Essaie d'utiliser un script rc pour Debian sur Fedora pour rigoler.

Il y a de plus en plus de logiciel de très haut niveau qui dépendent de systemd

Euh, juste la gestion de l'alimentation dans de GNOME 3.8, et pour de bonnes raisons : ConsoleKit n'évolue plus depuis 2 ans, et est trop bogué pour être utilisable.

GNOME peut toujours être compilé et exécuté sans systemd, au pire quelques fonctionnalités ne seront pas disponibles.

Les dits services que logind fournit peuvent être réimplémentés. L'API est stable et documentée, le code est libre et hébérgé sur fd.o.

Au niveau sécurité, la diversité est souvent un des atouts majeur. Maintenant, il y a un angle commun d'attaque supplémentaire. Une faille dans systemd, ce sont toutes les distributions qui sont touchées.

Je préfère un systemd qui a reçu un audit de sécurité, qui est maintenu par une équipe réactive, qu'un système d'init inconnu au bataillon.

La diversité c'est bien. Exécuter tel ou tel programme parce qu'il est différent sans avoir audité la sécurité du programme et de son code, savoir s'il est maintenu (ou maintenable), etc… c'est encore pire que pas de diversité.

Une des choses qui a amené le développement rapide des différents init est : la compétition. Est-ce que, maintenant qu'il n'y a plus de concurrents,

C'est vite dit ça. Déjà, il y a toujours beaucoup d'OS libres qui n'utilisent pas Systemd.

La 14.04 de Ubuntu, une LTS soutenue pour les 5 ans à venir, utilise toujours Upstart.
La 12.04 de Ubuntu, soutenue jusqu'en avril 2017 aussi d'ailleurs.
Gentoo utilise toujours OpenRC.
Slackware utilise toujours son propre système d'init.
Les BSD se fichent royalement de systemd.
AROS aussi s'en fiche.
(j'en oublie peut-être. Tiens, ils utilisent quoi chez Mageia ? Et chez OpenIndiana ?).

Il existe aussi encore beaucoup d'autres systèmes d'init (BootScripts, runit, initng, …)

Du côté des OS proprios, lequel a adopté systemd ? ;-)

Est-ce que redhat va désormais encore être aussi actif ou était-ce juste une manœuvre de prise de contrôle ?

Voyons, est-ce que les mainteneurs de Debian, Ubuntu, Arch Linux, Fedora, et tant d'autres distributions sont contrôlés par RedHat ?
Ça me semble quand même hautement improbable.

Des rancœurs sont nées. Le débat n'a pas été serein. Certains qui sont contre systemd (quelque soit la raison) et certains qui sont pour qu'on laisse le choix se sentent floués, bafoués. Pour beaucoup, cela est un passage en force. Cela peut laisser des traces pendant une très longue période.

Les trolls s'en remettront.

Pleins de très bonnes idées se sont déjà révélées des désastres…

Oui, comme ConsoleKit, HAL, GTK1, SysV (d'où la naissance, au moins, de upstart, openrc, et systemd), Xorg, …
Mais on ne peut pas apprendre sans erreurs.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)