Ses avantages sont multiples :
1. Proposer des variantes des paquets officiels (tels que linux-ck)
2. Proposer des paquets qui ne sont pas présents sur les dépôts binaires
3. Proposer un système de votes permettant à certains scripts de rejoindre les rangs des paquets binaires officiels sur le dépôt [community]
4. Permettre d'abandonner des paquets binaires vers l'AUR (comme lors du passage à systemd, le PKGBUILD de sysvinit s'est retrouvé sur l'AUR)
5.Permettre à n'importe qui de proposer un nouveau PKGBUILD (aprèsavoirrespectécertainesrègles) ou de reprendre la maintenance de scripts existants.
Maintenant c'est vrai qu'on trouve des PKGBUILD excellents, d'autres moins bons, et pas mal qui sont abandonnées. C'est loin d'être surprenant quand on sait que l'AUR est ouvert à tous. Mais il ne faut pas oublier que même les dépôts officiels sont régulièrement nettoyés : une rolling release est tout sauf figée.
Et c'est parce que l'AUR n'est pas contrôlé (c'est à ceux qui proposent des scripts et ceux qui les installent qui ont la charge de les contrôler) que pacman ne supporte pas l'AUR directement. En effet, sans wrapper il faut télécharger le tarball voulu, et ensuite vérifier le PKGBUILD, et enfin le construire avec makepkg -s et l'installer avec pacman -U.
Si on veut quelque chose de bien mieux contrôlé (et donc bien plus fermé) que l'AUR, on reste sur les paquets des dépôts binaires officiels, qui sont très bien fournis (environ 5026 paquets pour l'architecture x86_64 seule, avec le dépôt multilib activé si je fais un coup de "abs" et que je fais un "tree" sur /var/abs).
Ils sont souvent abandonnées pour une bonne raison (liste non-exhaustive) :
1.Le logiciel upstream est abandonné
2.La personne ayant proposé le script n'en a plus besoin et ne souhaite plus le maintenir (si l
3.C'est un paquet Archlinux abandonné vers l'AUR
4.Les paquets officiels ont rendu le script non-nécessaire (par exemple : xfwm4.8-tiling ne sert plus à grand chose depuis xfwm4.10 qui a intégré le tiling semi-automatique et l'a même amélioré)
5. etc…
Enfin, concrètement y'a-t-il tant de scripts abandonnées sur l'AUR ?
Si on prend les stats d'aujourd'hui disponibles sur le site officiel :
Paquets 45011
Paquets orphelins 9660
Paquets ajoutés au cours des 7 derniers jours 128
Paquets mis à jour au cours des 7 derniers jours 1065
Paquets mis à jour dans l'année écoulée 18984
Paquets jamais mis à jour 11226
Utilisateurs enregistrés 53269
Utilisateurs de confiance (TU) 36
21% de scripts orphelins, c'est moins d'un quart.
Et à titre perso, pourquoi l'AUR est si utile ?
pacman -Qmm
aurupload 0.7.5-1
Me permet de script l'envoi d'archives sources sur l'AUR
cdemu-daemon-lts 2.1.0-5
Permet de monter des ISO, NRG, .BIN/.CUE, et autres formats sur un /dev/sr1 émulé grâce à vhba-module. Pour vhba-module-lts.
corsix-th 0.21-1
Version libre de Theme Hospital
desura 1-19
Une sorte de Steam mais pour les jeux indés (et ceux bien avant que Steam se soit ouvert aux indés)
dfc-git 20130819-1
df -h, mais en mieux (version de développement un brin plus à jour que la dernière relase officielle)
doukutsu 1.2-4
Jeu : Cave Story
elementary-xfce-icons 0.3-1
Thème d'icônes de Xubuntu
fs-uae 2.2.3-1
Émulateur Amiga qui est aussi bon que WinUAE
g-fs-uae 0.0.61-2
interface graphique pour fs-uae
gcdemu 2.1.0-1
interface graphique pour cdemu-daemon
gufw 14.04.0-1
GUI de UFW
kega-fusion 3.63-16
Émulateur sega genesis / sms.
libjpeg6 6b1-2
Dépendance de Desura.
libxfce4ui-devel 4.11.0-1
Version de dév de libxfce4ui4.12. Dépendance de xfwm4.11
linux-ck 3.10.20-1
Linux avec le -ck patchset et le BFQ.
linux-ck-headers 3.10.20-1
fichiers d'en-tête linux-ck
nvidia-ck 331.20-14
Pilote nvidia proprio pour linux-ck
openxcom 0.9-3
Jeu : OpenXCom
package-query 1.2-2
Dépendance de yaourt.
pnmixer-xfce4 3-1
Mixer pour le tableau de bord Xfce supportant ALSA et PulseAudio, notifications OSD, etc. …
pytyle2-hg 2.0.0-2
Full tiling pour xfwm4 ou équivalent
soundfont-titanic 1.2-1
banque de sons MIDI
suspend-usb-device-git 20121113.12-1
Permet d'éteindre un disque dur externe avant de le débrancher (thunar ne le propose pas toujours…)
systemd-ui 2-2
consulter l'état des services systemd avec une interface graphique
ttf-ms-fonts 2.0-10
Polices de caractères Microsoft
vhba-module-ck 20130607-4
Module kernel pour cdemu-daemon. Variante pour linux-ck
vhba-module-lts 20130607-9
Module kernel pour cdemu-daemon. Variante pour linux-lts
virtualbox-ck-host-modules 4.3.4-4
Modules kernel pour virtualbox. Variante pour linux-ck
xfce-theme-albatross 1.5.1-1
Thème GTK Xubuntu 10.04
xfce4-hardware-monitor-applet-git 1.4.4.r53.4f7535e-1
Nouveau greffon tiers pour le tableau de bord Xfce qui existe depuis quelques semaines seulement.
xfce4-places-plugin 1.6.0-1
Raccourcis pour le tableau de bord Xfce, et accès aux "documents récents"
xfce4-volumed-pulse 0.2.0-3
Variante pulseaudio de démon de volume Xfce, provenant de Xubuntu
xfce4-whiskermenu-plugin 1.2.2-1
Menu alternatif pour le tableau de bord Xfce (ressemble un peu à celui de KDE4)
xflux 20130901-2 f.lux pour Xorg
xfwm4-devel 4.11.0-1
version de dév de xfwm4.12 (pas mal de nouveautés, dont le support du vblank)
yaml-cpp0.3 0.3.0-1
Dépendance de OpenXCom
yaourt 1.3-1
Wrapper pour l'AUR.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
le journal binaire de systemd-journald peut comporter des données purement binaires (core dump, ATA SMART blobs, firmware dumps, SCSI sense data, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
L'intérêt du shell, à mon avis, c'est que c'est le langage par défaut d'administration de la machine, et celui qu'on trouve par défaut en console. On y est confronté à un moment ou un autre, et normalement, on apprend à le connaître et à le maîtriser. C'est, pour l'utilisateur final, une certaine garantie quant à la possibilité de toucher à son init.
On peut toujours se toucher l'init avec systemd, je vois pas le rapport. Les unit files sont documentés, et beaucoup plus simple que des scripts d'init. Et la soixantaine de binaires qui viennent avec systemd donne largement de quoi se toucher l'init.
Et de fait, lorsqu'on veut faire quelque chose qui sort des clous, le plus simple reste d'écrire un script shell. Je crois que même avec systemD, dans certains cas particulier, l'administrateur n'a pas d'autre choix que d'écrire un script shell qui va bien.
Y'a toujours une compatibilité avec les scripts shells, mais tu passes alors à côte de pas mal d'intérêts de systemd (comme éviter de lancer au minimum deux processus - un shell, lequel lance le programme/script - pour une tâche d'init, avoir quelque chose de plus facilement lisible et déboguable qu'un script shell, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je ne pense pas que ce soit les seuls possibilités de filtrage (par exemple une unité peut être 'masqued' : inactive et non-activable à moins de faire 'unmask' d'abord. J'avais fait ça manuellement à une époque pour certains services que je ne voulais vraiment pas voir démarrés).
Ce n'est pas nécessaire. On peut standardiser les logs dans un format texte, on y arrive bien pour d'autres choses (au hasard je html ; ca reste du texte, et la syntaxe est plutôt précise).
Bonne chance pour standardiser les messages de logs de tous les logiciels existants.
Et puis :
Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!
[…] And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.
Et bon, honnêtement, si je n'ai pas d'OS avec journalctl sous le coude, je trouve que le texte est quand même énormément plus facile à traiter que du binaire.
Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?
Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Les outils Unix sont conçus spécifiquement pour traiter du texte ; ca reste le format universel pour Unix. Sinon, il y a un truc qui a 40 ans environ qui s'appelle "expressions régulières", très efficace pour parser du texte en O(n) quand c'est bien fait. Le gros intérêt est que ca existe ailleurs que sous Linux.
Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.
Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte. Pis, du texte en langue humaine, le genre de langages très peu standardisé (où personne n'arrive à se mettre d'accord sur une chose aussi bête que le format des dates !).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
L'utilisation d'un format binaire permet aussi de standardiser les logs (par exemple au niveau des dates). Fini les regex qui changent en même temps que les programmes tiers changent leurs messages de logs.
L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.
Je suis sûr qu'on peut trouver d'autres avantages à un format binaire dans le lien que j'ai donné, mais ce lien ne parle pas spécifiquement de ça, et démêler tout ça serait plus d'efforts que j'en ai envie pour un n-ième troll au sujet de "binaire vs textuel".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
"Break-ins on high-profile web sites have become very common, including the recent widely reported kernel.org break-in. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected."
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Simplicity: little code with few dependencies and minimal waste through abstraction.
Zero Maintenance: logging is crucial functionality to debug and monitor systems, as such it should not be a problem source of its own, and work as well as it can even in dire circumstances. For example, that means the system needs to react gracefully to problems such as limited disk space or /var not being available, and avoid triggering disk space problems on its own (e.g. by implementing journal file rotation right in the daemon at the time a journal file is extended).
Robustness: data files generated by the journal should be directly accessible to administrators and be useful when copied to different hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully. Journal file browsing clients should work without the journal daemon being around.
Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally.
Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance
Integration: the journal should be closely integrated with the rest of the system, so that logging is so basic for a service, that it would need to opt-out of it in order to avoid it. Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that.
Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.
General Purpose Event Storage: the journal should be useful to store any kind of journal entry, regardless of its format, its meta data or size.
Unification: the numerous different logging technologies should be unified so that all loggable events end up in the same data store, so that global context of the journal entries is stored and available later. e.g. a firmware entry is often followed by a kernel entry, and ultimately a userspace entry. It is key that the relation between the three is not lost when stored on disk.
Base for Higher Level Tools: the journal should provide a generally useful API which can be used by health monitors, recovery tools, crash report generators and other higher level tools to access the logged journal data.
Scalability: the same way as Linux scales from embedded machines to super computers and clusters, the journal should scale, too. Logging is key when developing embedded devices, and also essential at the other end of the spectrum, for maintaining clusters. The journal needs to focus on generalizing the common use patterns while catering for the specific differences, and staying minimal in footprint.
Universality: as a basic building block of the OS the journal should be universal enough and extensible to cater for application-specific needs. The format needs to be extensible, and APIs need to be available.
Clustering & Network: Today computers seldom work in isolation. It is crucial that logging caters for that and journal files and utilities are from the ground on developed to support big multi-host installations.
Security: Journal files should be authenticated to make undetected manipulation impossible.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
bonus track, conversation d'il y a 2 ans, digne d'un pebkac…
"l'ordinateur me demande si il doit installer le programme de nettoyage du registre gratuit"
"bin, tu veux l'installer ?"
"non!"
"et donc ?"
"bin, je sais pas, je fais quoi ? oui ou non ?"
"a ton avis?"
"non, mais ça m'énerve, moi j'y comprend rien a l'informatique"
Ils n'avaient pas Adblock Plus/Edge dans leur Firefox ? ;-)
edit : Web Of Trust aussi est sympa (avec l'icône vert/gris/rouge selon le site dans la barre d'outils, et ses avertissements en avant plan sur les sites potentiellement dangereux) pour éviter les sites pourris.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Tu mets les briques systèmes et les applications/DE (qui vivent dans les couches supérieurs) au même niveau, alors que ça n'a rien à voir.
systemd et wayland sont des briques systèmes donc y'a intérêt à les uniformiser. Déjà pour uniformiser les API, ensuite pour éviter de se mettre pas mal de monde à dos (ceux qui écrivent des pilotes graphiques pour wayland, ceux qui écrivent des services/daemons pour systemd)
D'ailleurs :
On a plusieurs API pour le son dans le noyau ? Non, il n'y a que ALSA (et à la limite une couche de compatibilité avec OSS).
On a plusieurs kernels ? Non, il n'y a que Linux.
On a plusieurs système de TTY ? Non, il n'y a que l'implémentation fournie par le noyau.
On a plusieurs implémentations d'OpenGL, juste histoire d'avoir le choix et de multiplier les bugs ? Non, y'a pas grand chose à part mesa.
On a plusieurs implémentations d'initrd ? bah non.
On a plusieurs manières de rendre une application accessible à l'utilisateur moyen dans son DE ? Bah non y'a pas grand chose à part les fichiers .desktop
etc…
Et l'uniformité au niveau du système de base, c'est bien pour les développeurs, et par conséquent les utilisateurs. Ça leur évite de fuir Linux. On a déjà trop de systèmes d'init (openrc, upstart, systemd, sysv, tout ça pour quoi ?), trop d'APIs pour la même chose (ALSA vs OSSv3 vs OSSv4, par exemple. Heureusement il y a des wrappers comme OpenAL ou la SDL ou PulseAudio-le-wrapper-universel, mais ça rajoute forcément de la latence).
D'ailleurs la réponse est là : plein de distributions y passent à systemd ou y sont déjà passés (Archlinux, Fedora, RHEL, …), et Wayland est désigné comme étant le successeur de Xorg par beaucoup de distributions (à part Ubuntu, même si c'était le cas il y a pas si longtemps), avec une phase de transition (serveur XWayland).
systemd et wayland vont-ils faire disparaître les dizaines de lecteurs PDFs, et imposer evince par exemple ?
Non, parce que ça n'a aucun rapport avec la choucroute.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Et pas besoin de Xfce 4.10. Xfce 4.8 permet aussi de le faire.
Debian avec Xfce
Xubuntu est tout autant léger, et modernise largement Xfce (support PulseAudio, thème GTK3, …). :)
La différence éventuelle en usage mémoire n'aura aucun effet remarquable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Il me semble un peu farfelue d'attaquer la stabilité de Debian quand son système(Ubuntu) est basé sur une Debian. Une Debian Testing faut-il le précisé.
Faux et archi-faux. Ubuntu utilise des paquets provenant de Sid pour une (bonne) partie de ce que Canonical ne prend pas directement en charge, ce qui est assez différent.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
J'avais une machine similaire (un ASUS 1005HA) qui fonctionnait au poil sous Xubuntu 12.04 LTS, une dérivée communautaire officielle de Ubuntu.
Xfce est un bureau léger et fiable. Xubuntu 12.04 est soutenue par l'équipe Xubuntu jusqu'en avril 2015.
La prochaine version LTS sera la 14.04.
Il existe des PPAs si tu en as besoin, tel que celui pour Gimp 2.8 ou celui fournie par l'équipe Xubuntu pour Xfce 4.10 et Xfce 4.12.
Pour créer un support d'installation sur une clé USB de Xubuntu pour l'installer sur ton ordi, tu peux utiliser LinuxLiveUSB Creator sous Windows. Ou usb-creator sous Ubuntu et dérivées (Lubuntu, Kubuntu, Xubuntu, …).
Enfin, pour alléger Xubuntu après l'installation si tu en ressens le besoin (Xubuntu est très léger, mais le CPU Intel Atom reste très lent) tu peux faire ceci :
Dans Gestionnaire de paramètres => Session et démarrage => Démarrage automatique, décocher :
- "Vérifier s'il existe de nouveaux pilotes" (si la machine ne nécessite pas de pilotes propriétaires)
- "Applet de file d'attente d'impression" (si pas d'imprimante)
- "Démon de volume XFCE" (si on n'utilise pas les touches multimédia liés au volume, il ne sert à rien)
- "'Notificateur de mises à jours" (ralentit la machine, mais si on le décoche il faut penser à vérifier les mises à jours manuellement de temps en temps)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pacman
Posté par xcomcmdr . En réponse au journal Frugalware, une distribution pas comme les autres.. Évalué à 10.
Ce n'est pas un dépôt de paquets binaires, mais un dépôt de scripts de création de paquets communautaire.
Ses avantages sont multiples :
1. Proposer des variantes des paquets officiels (tels que linux-ck)
2. Proposer des paquets qui ne sont pas présents sur les dépôts binaires
3. Proposer un système de votes permettant à certains scripts de rejoindre les rangs des paquets binaires officiels sur le dépôt [community]
4. Permettre d'abandonner des paquets binaires vers l'AUR (comme lors du passage à systemd, le PKGBUILD de sysvinit s'est retrouvé sur l'AUR)
5.Permettre à n'importe qui de proposer un nouveau PKGBUILD (après avoir respecté certaines règles) ou de reprendre la maintenance de scripts existants.
Maintenant c'est vrai qu'on trouve des PKGBUILD excellents, d'autres moins bons, et pas mal qui sont abandonnées. C'est loin d'être surprenant quand on sait que l'AUR est ouvert à tous. Mais il ne faut pas oublier que même les dépôts officiels sont régulièrement nettoyés : une rolling release est tout sauf figée.
Et c'est parce que l'AUR n'est pas contrôlé (c'est à ceux qui proposent des scripts et ceux qui les installent qui ont la charge de les contrôler) que pacman ne supporte pas l'AUR directement. En effet, sans wrapper il faut télécharger le tarball voulu, et ensuite vérifier le PKGBUILD, et enfin le construire avec makepkg -s et l'installer avec pacman -U.
Si on veut quelque chose de bien mieux contrôlé (et donc bien plus fermé) que l'AUR, on reste sur les paquets des dépôts binaires officiels, qui sont très bien fournis (environ 5026 paquets pour l'architecture x86_64 seule, avec le dépôt multilib activé si je fais un coup de "abs" et que je fais un "tree" sur /var/abs).
Ils sont souvent abandonnées pour une bonne raison (liste non-exhaustive) :
1.Le logiciel upstream est abandonné
2.La personne ayant proposé le script n'en a plus besoin et ne souhaite plus le maintenir (si l
3.C'est un paquet Archlinux abandonné vers l'AUR
4.Les paquets officiels ont rendu le script non-nécessaire (par exemple : xfwm4.8-tiling ne sert plus à grand chose depuis xfwm4.10 qui a intégré le tiling semi-automatique et l'a même amélioré)
5. etc…
Enfin, concrètement y'a-t-il tant de scripts abandonnées sur l'AUR ?
Si on prend les stats d'aujourd'hui disponibles sur le site officiel :
21% de scripts orphelins, c'est moins d'un quart.
Et à titre perso, pourquoi l'AUR est si utile ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Canon IP2700
Posté par xcomcmdr . En réponse au message Conseil imprimante Linux. Évalué à 2. Dernière modification le 07 décembre 2013 à 09:18.
Parfaitement compatible Windows (de XP à Windows 8) et Linux (ça s'installe tout seul avec system-config-printer).
Avant on a eu une Lexmark Z1400 Series (Windows ou pilote Java pour Mac (!), mais pas Linux), et une Canon i320 (Windows only)
edit : ce ne sont pas des lasers, et les cartouches ont tendance à coûter le prix de l'imprimante quelque soit la marque. :/
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques réponses en vrac
Posté par xcomcmdr . En réponse au journal Mon réseau social centralisé. Évalué à 2.
Un Chromequoi ?
C'est le geek qui a un Chromebook. Mme Michu elle a Windows XP.
(oui moi aussi je peux lui donner n'importe quoi à Mme Michu)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3. Dernière modification le 05 décembre 2013 à 21:58.
le journal binaire de systemd-journald peut comporter des données purement binaires (core dump, ATA SMART blobs, firmware dumps, SCSI sense data, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd
Posté par xcomcmdr . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à -1.
Le problème, c'est justement le langage shell
On peut toujours se toucher l'init avec systemd, je vois pas le rapport. Les unit files sont documentés, et beaucoup plus simple que des scripts d'init. Et la soixantaine de binaires qui viennent avec systemd donne largement de quoi se toucher l'init.
Y'a toujours une compatibilité avec les scripts shells, mais tu passes alors à côte de pas mal d'intérêts de systemd (comme éviter de lancer au minimum deux processus - un shell, lequel lance le programme/script - pour une tâche d'init, avoir quelque chose de plus facilement lisible et déboguable qu'un script shell, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques alternatives
Posté par xcomcmdr . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 7. Dernière modification le 03 décembre 2013 à 22:54.
Il suffit de demander à archive.org
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: État des services une fois le système démarré
Posté par xcomcmdr . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 6.
systemd :
lancés et ok :
lancés mais ont échoué :
désactivés :
Je ne pense pas que ce soit les seuls possibilités de filtrage (par exemple une unité peut être 'masqued' : inactive et non-activable à moins de faire 'unmask' d'abord. J'avais fait ça manuellement à une époque pour certains services que je ne voulais vraiment pas voir démarrés).
Voir le man de systemctl.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 0. Dernière modification le 03 décembre 2013 à 21:37.
Bonne chance pour standardiser les messages de logs de tous les logiciels existants.
Et puis :
Tu arrives à avoir un OS avec journald et ses logs binaires, mais sans journalctl ? Où, quand, comment, pourquoi ?
Et puis bon, c'est pas comme si journald n'était pas compatible avec syslog (il te manquera juste les méta-données, les blobs binaires au sein du journal ("ATA SMART health data, SCSI sense data, coredumps or firmware dumps"), l'access control & chiffrement du journal - comment savoir si le journal a été modifié ou non sans ça ? -, et la structuration du journal).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2. Dernière modification le 03 décembre 2013 à 21:22.
Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.
Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte. Pis, du texte en langue humaine, le genre de langages très peu standardisé (où personne n'arrive à se mettre d'accord sur une chose aussi bête que le format des dates !).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
L'utilisation d'un format binaire permet aussi de standardiser les logs (par exemple au niveau des dates). Fini les regex qui changent en même temps que les programmes tiers changent leurs messages de logs.
L'anglais (ou n'importe quelle langue humaine, d'ailleurs), c'est de la merde à parser.
Je suis sûr qu'on peut trouver d'autres avantages à un format binaire dans le lien que j'ai donné, mais ce lien ne parle pas spécifiquement de ça, et démêler tout ça serait plus d'efforts que j'en ai envie pour un n-ième troll au sujet de "binaire vs textuel".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
A propos de l'utilisation d'un format binaire :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GNU/SystemD/Linux
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Tout est expliqué ici
Pour résumer :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: mon expérience avec Linux Mint
Posté par xcomcmdr . En réponse à la dépêche Distribution Linux Mint 16 « Petra ». Évalué à 3. Dernière modification le 02 décembre 2013 à 19:21.
Ils n'avaient pas Adblock Plus/Edge dans leur Firefox ? ;-)
edit : Web Of Trust aussi est sympa (avec l'icône vert/gris/rouge selon le site dans la barre d'outils, et ses avertissements en avant plan sur les sites potentiellement dangereux) pour éviter les sites pourris.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: résistance au changement
Posté par xcomcmdr . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 5.
Tu mets les briques systèmes et les applications/DE (qui vivent dans les couches supérieurs) au même niveau, alors que ça n'a rien à voir.
systemd et wayland sont des briques systèmes donc y'a intérêt à les uniformiser. Déjà pour uniformiser les API, ensuite pour éviter de se mettre pas mal de monde à dos (ceux qui écrivent des pilotes graphiques pour wayland, ceux qui écrivent des services/daemons pour systemd)
D'ailleurs :
On a plusieurs API pour le son dans le noyau ? Non, il n'y a que ALSA (et à la limite une couche de compatibilité avec OSS).
On a plusieurs kernels ? Non, il n'y a que Linux.
On a plusieurs système de TTY ? Non, il n'y a que l'implémentation fournie par le noyau.
On a plusieurs implémentations d'OpenGL, juste histoire d'avoir le choix et de multiplier les bugs ? Non, y'a pas grand chose à part mesa.
On a plusieurs implémentations d'initrd ? bah non.
On a plusieurs manières de rendre une application accessible à l'utilisateur moyen dans son DE ? Bah non y'a pas grand chose à part les fichiers .desktop
etc…
Et l'uniformité au niveau du système de base, c'est bien pour les développeurs, et par conséquent les utilisateurs. Ça leur évite de fuir Linux. On a déjà trop de systèmes d'init (openrc, upstart, systemd, sysv, tout ça pour quoi ?), trop d'APIs pour la même chose (ALSA vs OSSv3 vs OSSv4, par exemple. Heureusement il y a des wrappers comme OpenAL ou la SDL ou PulseAudio-le-wrapper-universel, mais ça rajoute forcément de la latence).
D'ailleurs la réponse est là : plein de distributions y passent à systemd ou y sont déjà passés (Archlinux, Fedora, RHEL, …), et Wayland est désigné comme étant le successeur de Xorg par beaucoup de distributions (à part Ubuntu, même si c'était le cas il y a pas si longtemps), avec une phase de transition (serveur XWayland).
systemd et wayland vont-ils faire disparaître les dizaines de lecteurs PDFs, et imposer evince par exemple ?
Non, parce que ça n'a aucun rapport avec la choucroute.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon expérience avec scratch
Posté par xcomcmdr . En réponse au message Programmer avec ses pieds et en musique. Évalué à 3. Dernière modification le 30 novembre 2013 à 20:16.
libgosu. (pas encore testé mais a l'air très bien)
Avant j'utilisais rubygame, mais c'est abandonné depuis très longtemps.
Y'a aussi ruby-sfml
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: back to the future
Posté par xcomcmdr . En réponse au message Pour le retour du GFABasic. Évalué à 3.
C'était plutôt un 520ST, voire un 520STf, non ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# mauvaise compatibilité
Posté par xcomcmdr . En réponse au journal Quand Microsoft se paie la tête des Chromebooks.... Évalué à 7.
Source ?
Pas si sûr
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: shareware ou logiciel libre payant ?
Posté par xcomcmdr . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 1.
"mais je ne me souviens PAS."
Merci pour mes yeux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quand la religion bloque le progres...
Posté par xcomcmdr . En réponse au journal Disséquer du binaire sous linux. Évalué à 9.
On peut le pertinenter.
Je sais, c'est une idée révoltante. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# clé usb
Posté par xcomcmdr . En réponse au message Une distribution qui corresponde à mes besoins.... Évalué à 3.
Tu veux vraiment mettre un OS sur une clé usb ?
Je l'ai fait, et je l'ai flinguée en peu de temps. Une clé usb supporte largement moins de cycles d'écritures qu'un disque dur ou un SSD.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ubuntu pour Unity
Posté par xcomcmdr . En réponse au message quelle version pour mon netbook?. Évalué à 2.
J'ai plus d'espace vertical avec Xfce qu'avec Unity.
image plus grande
Et pas besoin de Xfce 4.10. Xfce 4.8 permet aussi de le faire.
Xubuntu est tout autant léger, et modernise largement Xfce (support PulseAudio, thème GTK3, …). :)
La différence éventuelle en usage mémoire n'aura aucun effet remarquable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Debian et stabilité
Posté par xcomcmdr . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 4.
Faux et archi-faux. Ubuntu utilise des paquets provenant de Sid pour une (bonne) partie de ce que Canonical ne prend pas directement en charge, ce qui est assez différent.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Boot sur un ASUS récent
Posté par xcomcmdr . En réponse à la dépêche openSUSE 13.1 est là. Évalué à 4.
Secure boot != TCPA.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Archlinux
Posté par xcomcmdr . En réponse au message quelle version pour mon netbook?. Évalué à 5.
Je suis moi-même un utilisateur fervent d'Archlinux, mais pour un(e) débutant(e) c'est vraiment à déconseiller…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Xubuntu
Posté par xcomcmdr . En réponse au message quelle version pour mon netbook?. Évalué à 5. Dernière modification le 20 novembre 2013 à 14:58.
J'avais une machine similaire (un ASUS 1005HA) qui fonctionnait au poil sous Xubuntu 12.04 LTS, une dérivée communautaire officielle de Ubuntu.
Xfce est un bureau léger et fiable. Xubuntu 12.04 est soutenue par l'équipe Xubuntu jusqu'en avril 2015.
La prochaine version LTS sera la 14.04.
Il existe des PPAs si tu en as besoin, tel que celui pour Gimp 2.8 ou celui fournie par l'équipe Xubuntu pour Xfce 4.10 et Xfce 4.12.
Ubuntu a aussi une énorme communauté française sur ubuntu-fr, et une doc bien fournie.
Pour créer un support d'installation sur une clé USB de Xubuntu pour l'installer sur ton ordi, tu peux utiliser LinuxLiveUSB Creator sous Windows. Ou usb-creator sous Ubuntu et dérivées (Lubuntu, Kubuntu, Xubuntu, …).
Enfin, pour alléger Xubuntu après l'installation si tu en ressens le besoin (Xubuntu est très léger, mais le CPU Intel Atom reste très lent) tu peux faire ceci :
Dans Gestionnaire de paramètres => Session et démarrage => Démarrage automatique, décocher :
- "Vérifier s'il existe de nouveaux pilotes" (si la machine ne nécessite pas de pilotes propriétaires)
- "Applet de file d'attente d'impression" (si pas d'imprimante)
- "Démon de volume XFCE" (si on n'utilise pas les touches multimédia liés au volume, il ne sert à rien)
- "'Notificateur de mises à jours" (ralentit la machine, mais si on le décoche il faut penser à vérifier les mises à jours manuellement de temps en temps)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)