Et puis le cumul des mandats est un sacré sac de noeuds. Par exemple à titre personnel je suis fondamentalement contre ce cumul, à tout les niveaux, et pencherai même pour une interdiction de cumul des rémunérations et émoluments afin de forcer à faire bouger les derniers récalcitrants …
Cependant, d'un autre point de vue, le cumul des mandats peut être aussi l'accélérateur calme d'une refonte des dits mandats. Le fait de cumuler des fonctions est finalement l'exemple parfait -absolument parfait- de cet état de faits : trop d'élus, trop de postes aux fonctions redondantes, aux responsabilités et périmètres devenus flous et se chevauchant. Le fait de pouvoir cumuler est bien l'ultime preuve que certaines fonctions sont remplies par ailleurs (ou bien sont inutiles ? hum, cela serait un peu trollesque ça).
Bref, les deux se défendent. Par contre, le non-cumul des rémunérations semble être le meilleur outil, dans les deux cas.
Bonsoir,
Et Kaspersky détaille le mode d'infection sur linux : un xpi au travers d'un firefox (qui serait lancé en root, en ayant désactivé l'option par défaut "avertir qu'un site souhaite installer une extension".
Perso j'ai cliquer partout sur les dit-sites, j'ai insisté à fond, pas moyen de choper quoi que ce soit.
Encore du FUD à destination des gens qui ne lisent pas les docs, mais qui ont le pouvoir de faire dépenser des milliers d'euros en antivirus pour linux, sans même avoir exigés de leur sysadmin la connaissance basique de pam.
On pourra noter que l'alliance Genivi vient de finaliser la version 5.0 de sa matrice de conformité. Et que celle ci éjecte gtk pour faire la part belle à Qt.
« the release is principally concerned with expanding support for windowing and graphics technologies. These include the X11 and newer Wayland windowing environments, as well as the Qt. 5.0 framework, and unstated “new GPUs" »
Il manque également les références exactes des modèles. Là, même en téléchargeant le .doc (pourquoi pas pdf ?) on ne les trouve pas … le descriptif est complet mais aucne référence du modèle constructeur qui permettrait de faire une recherche sur le net, rapide. En l'état c'est de l'obfuscation.
Je ne trouve pas déconnant du tout de payer plus cher un matériel chez un petit revendeur, qui plus est s'il propose du pré-installé gnu/linux. Mais l'absence de référence m'arrête net. Ceci dit, depuis que l'informatique grand public s'est transformée en vente d'ordinateur portable, couplé à l'arrivée de la grande distribution sur le marché, qui peut croire encore qu'il peut vivre de vente de matériel en dehors de ces circuits ?
Qu'est ce qui va me faire acheter dans une telle boutique alors que pour 650€ j'ai un I7 4GO ram en 17pouces, avec un dd de 750Go et un ssd (ajouté) de 128Go au supermarché du coin ? Alors, quoi ? Que je sache qu'ils sont actifs d'une manière ou d'une autre m'inciterais à regarder sous un autre angle leurs offres.
Je viens d'essayer rapidos ITOP, et c'est vraiment très bien. QQ critiques : polices de caractères trop grosses, rendant l'interface inutilement large (syndrome gnome ?:p). Des progrès en ergonomie (il faut cliquer sur "modifier" le petit bouton en haut à droite, une fois un changement crée, pour pouvoir ajouter des taches. Car sinon le comportement par défaut lorsqu'on clique sur "taches" du nouveau changement puis sur "créer"… créeait en fait un nouveau ticket dissocié au changement. Pareil une fois une nouvelle tache crée : il faut créer un ticket associé dans le même temps). Cette ergonomie perfectible alourdie énormément le workflow, le circuit de . Il ne s'agit pas là que de "nouvelles habitudes à prendre". (Et ça, c'est très très difficile à remonter via le ticketing habituel d'un bugzilla)
L'interception de matériel acheté sur Amazon a touché Andrea Shepard, une core dev. de TOR. Ainsi, son nouveau portable est passé par la case "Virginie" avant de lui être livré chez elle à Seatle. Probablement pour l'installation d'un malware par des gens du programme TAO.
Sitipabô ? D'où l'importance de pouvoir disposer de portable tel que le samsung arm chromebook, qui, s'il est loin d'être une foudre de guerre, permet de tout flasher, y compris l'EC …
Oui, c'est pourquoi les auteurs utilisent Inception sur Thunderbold / DisplayPort, mais lorsque l'usager est loggué. Afin de dumper la ram, puis d'en extraire le mot de passe de FileVault2 (c'est étrange qu'il n'y pas une option du style auth-nocache pour filevault et bitlocker) Bon, la vidéo a été supprimée de Youtube mais il reste l'article qui a deux ans.
moi ça m'espante
et je vais de ce pas acheter un adaptateur pour mon Acer …
Cette bibliothèque n'est pas en cause, elle n'est mentionnée que pour ceux souhaitant lire plus, son site étant particulièrement fourni en informations lisibles par tous. C'est la gestion du DMA par l'IEE1394 qui est en cause, donc directement la norme…
Sous les Linux anciens, utilisant encore ohci1394, il suffit de passer une option au chargement du module : phys_dma=0 afin de désactiver cela. Sur les Linux plus récents, c'est la nouvelle pile "juju" qui s'occupe de l'IEE1394, et ses différents modules n'ont visiblement pas repris cette option [ need info ] Il y en a même deux qui sont spécifiquement dédiés au debug (au lieu d'avoir seulement une option debug), sur le noyau Fedora ces deux modules ne sont pas compilés. Mais blacklister firewire_core semble être de toutes façons la solution la plus simple. Plus d'intrusion possible par ces voies là, paf la faille.
Comment dire autrement que «ton noiré magnifique, intelligente utilisation de l'espace jusqu'alors inutilisé du gestionnaire de fenêtres pour le gestionnaires de fichiers, mais qu'est ce que ça fait du bien de revenir à un desktop léger, véloce, efficient" … byebye gnome3 : 3 ça doit vouloir dire 3 jours….
Posté par bubar🦥 .
En réponse au journal Firefox en GTK3.
Évalué à 2.
Dernière modification le 21 janvier 2014 à 19:47.
Oui, d'où l'ajout d'une capture d'écran de plus dans le journal (les 3 premières venant d'un site de news sur Gnome, la dernière c'est mon bureau [j'ai pas fait gaffe à l'édition du journal, mais l'ai laissé car c'est plutôt drole au final] : on y voit ce fameux nouveau menu qui est vraiment beau)
Posté par bubar🦥 .
En réponse au journal Linux facile.
Évalué à 5.
Dernière modification le 21 janvier 2014 à 19:29.
échec signifie "le roi est mort", plus généralement "in-succès".
L'échec ne se réfère donc pas seulement à un manqué mais aussi à une étape. Or, où est l'étape qui permettrai de définir "l'échec" des distributions ?
D'abord, la majorité des distributions n'a pas vocation à être maintenue sur le long terme. Elles ne s'en sont pas fait un objectif, il n'y a pas d'étape là. (encore plus avec celles en rolling-release).
Ensuite, ne prenons que les distributions qui visent, ou ont visées, le "grand public" : leur planning est clair, et la maintenance de chaque version annoncée. Elles s'y tiennent.
Enfin, il y a les distributions qui visent le "plus de 10 ans", et Redhat par exemple a un support sur 13 années.
Ce qui permet de faire la transition sur le type de support. Car dans ton journal tu inclus l'un dans l'autre : la maintenance et la disponibilité de nouveaux pilotes et logiciels. Or ce sont deux choses distinctes. Redhat, par exemple, réalise des backports de drivers pendant une certaine période du support global, se dernier se finissant uniquement avec des mises à jours de sécurité.
Donc :
Le logiciel libre évolue vite, très vite.
Un système gnu/linux offre plus par défaut que les systèmes propriétaires, il a donc plus de maintenance à faire.
Et auquel vient se greffer un très grand nombre de logiciels, à l'intégration plus ou moins réussie, et à la vie plus ou moins éphémère. Comme pour les systèmes proprios.
En conclusion je dirais que la seule chose qui compte c'est un process de mise à jour / mise à niveau qui soit irréprochable. Passer d'une version N à N+1 doit se faire aussi facilement que des mises à jour de N.
j'ai vu presque personne dire "je suis sysadmin, je surkiffe trop upstart
j'ai le sentiment que personne parmi les sysadmins que je connais ne cherche à tirer parti des fonctions
alors que la communauté Ubuntu est censé être une des plus grande niveau utilisateur.
Cela rejoint le titre du journal auquel celui ci fait référence. Il y a quelque chose entre ces deux mondes. Ou pas, dans cet exemple.
un frein pour la distribution
Ce n'est pas contradictoire. Il semble important pour (notre regard sur) systemd que Debian l'adopte. Sans cela, il continuera de vivre sans problème, et d'être présent dans de nombreuses distributions ou sous-distributions, mais disons que le regard porté sur systemd ne sera pas le même… Que Debian adopte systemd semble être un gage d'assurance pour tous. Ce n'est pas contradictoire et ça semble important.
mais le cas chez Ubuntu
Ubuntu s'est isolée toute seule avec le sujet mir, ça serait dommage qu'elle entraine Debian avec elle sur l'init.
Je ne tiendrais pas la discussion technique que tu souhaites, mais plus simplement y apporter un point de vue de sysadmin qui suit l'actualité (et peut être relancer ce thread) Et ça me fait bien marrer de voir kdbus aujourd'hui porté dans la branche principale après les commentaires rageux d'il y a quelques années «mais ils sont fous / c'est dégueulasse / on en a pas besoin» lorsque ghk a mis cette demande (venant de l'automotive) dans sa branche. Il y a un petit goût de déjà vu … :) Concernant systemd, c'est déconcertant la facilité avec laquelle il est maintenant possible de réaliser des choses un peu complexes auparavant, execreload, limitnofile, environnment, conditionpath, stopwhenunneeded, … (et je ne parlerai pas des TTY*, que je n'ai pas pigés et qui me posent qq soucis). C'est un plaisir, un régal, que de pouvoir faire aussi facilement des confs comme ça, je n'avais pas connu plus simple.
Mon tit point de vue de tit sysadmin c'est que systemd gagne haut la main, en explosant tout le reste. Je veux bien "argumenter" là dessus, à défaut d'avoir une discussion de développeur. Nous avons là un système d'init plus simple à utiliser (pour un sysadmin mais aussi -surtout- un intégrateur) tout en permettant plus de possibilités.
A mon humble avis cette discussion est close depuis 2 ans, en fait.
Et toujours à mon bien humble avis, si Debian adopte systemd, ça sera le moment où systemd entrera en production, la communauté peut le prendre en charge non une seule entité. si Debian n'adopte pas systemd par contre, donc n'y fourre plus son nez dedans, là ça sera un frein sévère à systemd (à mes yeux)
(Maintenant on peut troller sur le format binaire (et le niveau de verbosité, et la compacité des informations sur un seul endroit) du journal, qui est horreur : les logs sont faites pour être utilisées, journal visiblement beaucoup moins…lol)
Choisir systemd+openrc me paraît être le choix le plus raisonnable
Maintenir deux systèmes d'init ne (me) parait pas raisonnable. Doubler le travail (même si openrc demande bien moins d'efforts) ne semble pas raisonnable.
D'autant que cela déporte la question sur «quel init par défaut», qui se déportera sur «quelle arch», et qui quasi-inévitablement aura en résultat «bien, 4 ans après, le systeme d'init par défaut est utilisé sur 99% des plateformes intel et arm via l'usage de 90% de linux, le reste étant dû au port de kfreebsd puis au quelques choix rares et volontaires d'autres choses que l'init par défaut sur intel/arm/linux». Hum, c'est une projection (d'autres argueront que d'ici là, la glib ne sera plus utilisable/portable sur le noyau freebsd parceque …) certes. Mais même si les résultats étaient différents, à la base cela demande double travail.
Cyanogen ne sont pas des neuneus, et ce n'est pas que pour les neuneus. Mais ils constituent une foire à neuneus. C'est très différent. J'utilise aussi avec plaisir Cyanogen sur ma tablette. Et sans sourciller, et sans contradiction avec ce que dis précédemment. Cyanogen .. je vois ça (le "je" est important pour replacer le truc à sa juste valeur, pas grand chose) comme étant une foire à neuneus car c'est de la précipitation permanente. Ils ont des devs génieux chez XDA en général.
Je ne juge pas de ça. Mais il me semble que le mode de fonctionnement et les outils utilisés ne sont pas à la hauteur du travail produit. On dirait des excités du code fermés qui découvrent le code ouvert. Voilà, c'est tout. C'est à dire qu'il ne faut pas juger du taf mais des méthodes : ils n'utilisent pas (pour une raison inconnue) de service (dé)centralisé de versions, qui soit ouvert. C'est ça qui me chagrine. En vrai, on peut voir ça comme des "génies qui ne savent pas" (pour encore exagérer les propos), et il est fort probable que le mieux soit de les encourager… Parcequ'à terme c'est sûr et certain que leurs reflexes primitifs (publication de "versions privées", absence d'usage d'outils de versionning ouverts) ne soient pas représentatifs de ce qu'ils souhaitent.
Restons optimistes, la "foire à neuneus" n'est quà prendre dans son contexte, ie les méthodes et le fonctionnement. Pas le travail et les réalisations.
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 2.
Dernière modification le 06 janvier 2014 à 19:18.
D'après Coreboot, bus-pirate fait l'affaire. D'après la doc de Bus-Pirate, la 4 n'est pas encore destinée à tous, et la 3 est conseillée. C'est donc aussi la 3 que je vais acquérir.
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 2.
Gentoo est bien installé en chroot
Chroot d'une Gentoo standard dans la Gentoo ChromeOS ? Ou bien chroot dans la Arch ? Peu importe, remarque…
sd sur laquelle j'ai installé arch
Je pense que le mieux est de commencer par virer ChromeOS. Car à partir du moment où l'objectif est de totalement refaire le système, alors à objectif atteint plus de ChromeOS possible (plus de clef pour booter dessus). Quelque soit la distrib que tu choisis pour cela.
Je ne sais pas si on peu appeler ça du cross compilling
Je ne sais pas si le stage1 existe encore, mais je pensais plutôt partir d'un stage3 dans une machine virtuelle (de nos jours c'est plus rapide que de mettre en place une chaine de cross-compilation, sans pour autant perdre du temps à la compil, ça dépend de la machine hote, enfin chacun fait comme il voit, avec ses habitudes et sleon ses besoins) Arm sur un x86 puissant.
Bref tu as une Gentoo + une Arch qui bootent dessus :)
2 microprogrammes obligatoires
Il n'y a rien d'obligatoire. Ni "en théorie" ni en réalité, puisque l'EC n'est pas du tout une étape obligatoire pour Coreboot. Seul le SPI compte pour cela (donc faire sauter le petit anneau et sa vis, pour passer le SPI en read-write totalement). Flasher l'EC est optionnel, et pas du tout nécessaire pour Coreboot. Mais comme c'est possible, et qu'on a les sources, j'y vais aussi :-) Enfin, seul l'EC nécessite un programmateur externe. Le SPI n'a besoin que de passer en RW pour être atteignable par flashrom directement.
Tu parle de la doc du projet … tu dois parler de Chromium ?
De celle de Coreboot pour l'essentiel.
La doc de ChromiumOS dit "don't do that" :-)
dans ce cas il faut quand même flasher l'EC ?
Non, pas besoin, donc.
il y en a pas beaucoup
Du moins, la doc n'est pas très florissante. Et c'est un attrait. Par ailleurs, je compte remonter mes petites modifications (sur Das U-BOOT) à Parasense en premier lieu, afin de le remercier pour avoir rendu cette possibilité plus facilement accessible via son image pour carte SD. Pour la doc, je ne suis pas à même d'écrire autre chose qu'un compte rendu, d'autres jugeront si ça vaut le coup de l'intégrer dans un wiki.
Mais vraiment, c'est vrai que les docs ne courrent pas les rues…
ps : je n'utilise pas Jabber, désolé. uniquement irc et les tribunes.
[^] # Re: Parti de gauche
Posté par bubar🦥 . En réponse à la dépêche Isabelle Attard députée favorable au Logiciel Libre, Jeudi 20 février, 20h au TRIANGLE à Rennes. Évalué à 1. Dernière modification le 17 février 2014 à 18:07.
Et puis le cumul des mandats est un sacré sac de noeuds. Par exemple à titre personnel je suis fondamentalement contre ce cumul, à tout les niveaux, et pencherai même pour une interdiction de cumul des rémunérations et émoluments afin de forcer à faire bouger les derniers récalcitrants …
Cependant, d'un autre point de vue, le cumul des mandats peut être aussi l'accélérateur calme d'une refonte des dits mandats. Le fait de cumuler des fonctions est finalement l'exemple parfait -absolument parfait- de cet état de faits : trop d'élus, trop de postes aux fonctions redondantes, aux responsabilités et périmètres devenus flous et se chevauchant. Le fait de pouvoir cumuler est bien l'ultime preuve que certaines fonctions sont remplies par ailleurs (ou bien sont inutiles ? hum, cela serait un peu trollesque ça).
Bref, les deux se défendent. Par contre, le non-cumul des rémunérations semble être le meilleur outil, dans les deux cas.
Hop. ;-)
[^] # Re: fin de l'histoire ?
Posté par bubar🦥 . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 2.
Ce n'est pas parcequ'il serait bien conçu qu'il fait re-sortir les problèmes de drivers. NON. C'est parcequ'il a été adopté.
[^] # Re: Mauvais lien
Posté par bubar🦥 . En réponse au journal Le Masque, un virus multi-plateforme de 2007. Évalué à 10.
Bonsoir,
Et Kaspersky détaille le mode d'infection sur linux : un xpi au travers d'un firefox (qui serait lancé en root, en ayant désactivé l'option par défaut "avertir qu'un site souhaite installer une extension".
Perso j'ai cliquer partout sur les dit-sites, j'ai insisté à fond, pas moyen de choper quoi que ce soit.
Encore du FUD à destination des gens qui ne lisent pas les docs, mais qui ont le pouvoir de faire dépenser des milliers d'euros en antivirus pour linux, sans même avoir exigés de leur sysadmin la connaissance basique de pam.
# GNU/Nunux «on ice» Tutures
Posté par bubar🦥 . En réponse à la dépêche Revue de presse de l'April pour la semaine 6 de l'année 2014. Évalué à 4. Dernière modification le 10 février 2014 à 19:58.
On pourra noter que l'alliance Genivi vient de finaliser la version 5.0 de sa matrice de conformité. Et que celle ci éjecte gtk pour faire la part belle à Qt.
Référence :
- MentorGraphics
« the release is principally concerned with expanding support for windowing and graphics technologies. These include the X11 and newer Wayland windowing environments, as well as the Qt. 5.0 framework, and unstated “new GPUs" »
# Remerciement
Posté par bubar🦥 . En réponse à la dépêche NVIDIA contribue la gestion du GPU ARM Tegra K1 dans Nouveau. Évalué à 7. Dernière modification le 07 février 2014 à 22:27.
Encore mes remerciements à tous ceux qui sont impliqués dans ces projets !!! ;-) (bn, ok la paraphrase saynul, mais le coeur y est)
[^] # Re: Juste une remarque
Posté par bubar🦥 . En réponse au journal Nouvelle boutique en ligne Linux. Évalué à 7.
Juste une autre remarque : ils peuvent se référencer sur http://linuxpreinstalle.com/
[^] # Re: Garanties loteries ?
Posté par bubar🦥 . En réponse au journal Nouvelle boutique en ligne Linux. Évalué à 10. Dernière modification le 06 février 2014 à 21:33.
Il manque également les références exactes des modèles. Là, même en téléchargeant le .doc (pourquoi pas pdf ?) on ne les trouve pas … le descriptif est complet mais aucne référence du modèle constructeur qui permettrait de faire une recherche sur le net, rapide. En l'état c'est de l'obfuscation.
Je ne trouve pas déconnant du tout de payer plus cher un matériel chez un petit revendeur, qui plus est s'il propose du pré-installé gnu/linux. Mais l'absence de référence m'arrête net. Ceci dit, depuis que l'informatique grand public s'est transformée en vente d'ordinateur portable, couplé à l'arrivée de la grande distribution sur le marché, qui peut croire encore qu'il peut vivre de vente de matériel en dehors de ces circuits ?
Qu'est ce qui va me faire acheter dans une telle boutique alors que pour 650€ j'ai un I7 4GO ram en 17pouces, avec un dd de 750Go et un ssd (ajouté) de 128Go au supermarché du coin ? Alors, quoi ? Que je sache qu'ils sont actifs d'une manière ou d'une autre m'inciterais à regarder sous un autre angle leurs offres.
[^] # Re: GLPI ?
Posté par bubar🦥 . En réponse au journal Itop... l'ITSM opensource. Évalué à 3.
Je viens d'essayer rapidos ITOP, et c'est vraiment très bien. QQ critiques : polices de caractères trop grosses, rendant l'interface inutilement large (syndrome gnome ?:p). Des progrès en ergonomie (il faut cliquer sur "modifier" le petit bouton en haut à droite, une fois un changement crée, pour pouvoir ajouter des taches. Car sinon le comportement par défaut lorsqu'on clique sur "taches" du nouveau changement puis sur "créer"… créeait en fait un nouveau ticket dissocié au changement. Pareil une fois une nouvelle tache crée : il faut créer un ticket associé dans le même temps). Cette ergonomie perfectible alourdie énormément le workflow, le circuit de . Il ne s'agit pas là que de "nouvelles habitudes à prendre". (Et ça, c'est très très difficile à remonter via le ticketing habituel d'un bugzilla)
SUPER!
[^] # Re: des hackers ? vilains crackers, oui !
Posté par bubar🦥 . En réponse au journal ce que l'on sait sur TAO les hackers de la NSA. Évalué à 2. Dernière modification le 26 janvier 2014 à 23:12.
L'interception de matériel acheté sur Amazon a touché Andrea Shepard, une core dev. de TOR. Ainsi, son nouveau portable est passé par la case "Virginie" avant de lui être livré chez elle à Seatle. Probablement pour l'installation d'un malware par des gens du programme TAO.
Sitipabô ?
D'où l'importance de pouvoir disposer de portable tel que le samsung arm chromebook, qui, s'il est loin d'être une foudre de guerre, permet de tout flasher, y compris l'EC …
On peut s'étonner du manque de subtilité de faire apparaitre le cheminement complet… Andrea s'en étonne aussi : https://twitter.com/puellavulnerata/status/426597381727989760/photo/1
[^] # Re: Punaise
Posté par bubar🦥 . En réponse au journal Toi aussi, amuses toi avec le FireWire. Évalué à 4. Dernière modification le 26 janvier 2014 à 17:02.
Oui, c'est pourquoi les auteurs utilisent Inception sur Thunderbold / DisplayPort, mais lorsque l'usager est loggué. Afin de dumper la ram, puis d'en extraire le mot de passe de FileVault2 (c'est étrange qu'il n'y pas une option du style auth-nocache pour filevault et bitlocker) Bon, la vidéo a été supprimée de Youtube mais il reste l'article qui a deux ans.
moi ça m'espante
et je vais de ce pas acheter un adaptateur pour mon Acer …
[^] # Re: Punaise
Posté par bubar🦥 . En réponse au journal Toi aussi, amuses toi avec le FireWire. Évalué à 10.
Depuis que Apple a inventé cette merveille, donc ~1994
\o/
[^] # Re: faut relativiser
Posté par bubar🦥 . En réponse au journal Toi aussi, amuses toi avec le FireWire. Évalué à 10. Dernière modification le 26 janvier 2014 à 15:20.
Cette bibliothèque n'est pas en cause, elle n'est mentionnée que pour ceux souhaitant lire plus, son site étant particulièrement fourni en informations lisibles par tous. C'est la gestion du DMA par l'IEE1394 qui est en cause, donc directement la norme…
Sous les Linux anciens, utilisant encore ohci1394, il suffit de passer une option au chargement du module : phys_dma=0 afin de désactiver cela. Sur les Linux plus récents, c'est la nouvelle pile "juju" qui s'occupe de l'IEE1394, et ses différents modules n'ont visiblement pas repris cette option [ need info ] Il y en a même deux qui sont spécifiquement dédiés au debug (au lieu d'avoir seulement une option debug), sur le noyau Fedora ces deux modules ne sont pas compilés. Mais blacklister firewire_core semble être de toutes façons la solution la plus simple. Plus d'intrusion possible par ces voies là, paf la faille.
Non ?
# gnome3
Posté par bubar🦥 . En réponse au journal Firefox en GTK3. Évalué à -2.
Comment dire autrement que «ton noiré magnifique, intelligente utilisation de l'espace jusqu'alors inutilisé du gestionnaire de fenêtres pour le gestionnaires de fichiers, mais qu'est ce que ça fait du bien de revenir à un desktop léger, véloce, efficient" … byebye gnome3 : 3 ça doit vouloir dire 3 jours….
[^] # Re: Bien essaye
Posté par bubar🦥 . En réponse au journal La GPL est un échec (FreeBSD 10 est sorti). Évalué à 6.
s/Facebook/Amazon
:p
[^] # Re: on dirait chrome
Posté par bubar🦥 . En réponse au journal Firefox en GTK3. Évalué à 2. Dernière modification le 21 janvier 2014 à 19:47.
Oui, d'où l'ajout d'une capture d'écran de plus dans le journal (les 3 premières venant d'un site de news sur Gnome, la dernière c'est mon bureau [j'ai pas fait gaffe à l'édition du journal, mais l'ai laissé car c'est plutôt drole au final] : on y voit ce fameux nouveau menu qui est vraiment beau)
# échec ?
Posté par bubar🦥 . En réponse au journal Linux facile. Évalué à 5. Dernière modification le 21 janvier 2014 à 19:29.
échec signifie "le roi est mort", plus généralement "in-succès".
L'échec ne se réfère donc pas seulement à un manqué mais aussi à une étape. Or, où est l'étape qui permettrai de définir "l'échec" des distributions ?
D'abord, la majorité des distributions n'a pas vocation à être maintenue sur le long terme. Elles ne s'en sont pas fait un objectif, il n'y a pas d'étape là. (encore plus avec celles en rolling-release).
Ensuite, ne prenons que les distributions qui visent, ou ont visées, le "grand public" : leur planning est clair, et la maintenance de chaque version annoncée. Elles s'y tiennent.
Enfin, il y a les distributions qui visent le "plus de 10 ans", et Redhat par exemple a un support sur 13 années.
Ce qui permet de faire la transition sur le type de support. Car dans ton journal tu inclus l'un dans l'autre : la maintenance et la disponibilité de nouveaux pilotes et logiciels. Or ce sont deux choses distinctes. Redhat, par exemple, réalise des backports de drivers pendant une certaine période du support global, se dernier se finissant uniquement avec des mises à jours de sécurité.
Donc :
En conclusion je dirais que la seule chose qui compte c'est un process de mise à jour / mise à niveau qui soit irréprochable. Passer d'une version N à N+1 doit se faire aussi facilement que des mises à jour de N.
[^] # Re: double "tap" zoom?
Posté par bubar🦥 . En réponse au journal Firefox en GTK3. Évalué à 1. Dernière modification le 20 janvier 2014 à 21:37.
C'est Gnome-shell qui doit gérer ça, et je ne vois pas de paramètres permettant de faire cela …
[^] # Re: Bien essaye
Posté par bubar🦥 . En réponse au journal La GPL est un échec (FreeBSD 10 est sorti). Évalué à 2. Dernière modification le 20 janvier 2014 à 21:33.
Rigolo même un lundi :-)
ps : tu postes à -5 ou bien tu es moinssé aux moindres faits et gestes ?? (-75 de karma ne fait pas poster à -5, si ??)
[^] # Re: Et pour une poignée de liens en plus
Posté par bubar🦥 . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10. Dernière modification le 18 janvier 2014 à 13:39.
Cela rejoint le titre du journal auquel celui ci fait référence. Il y a quelque chose entre ces deux mondes. Ou pas, dans cet exemple.
Ce n'est pas contradictoire. Il semble important pour (notre regard sur) systemd que Debian l'adopte. Sans cela, il continuera de vivre sans problème, et d'être présent dans de nombreuses distributions ou sous-distributions, mais disons que le regard porté sur systemd ne sera pas le même… Que Debian adopte systemd semble être un gage d'assurance pour tous. Ce n'est pas contradictoire et ça semble important.
Ubuntu s'est isolée toute seule avec le sujet mir, ça serait dommage qu'elle entraine Debian avec elle sur l'init.
[^] # Re: Et pour une poignée de liens en plus
Posté par bubar🦥 . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10. Dernière modification le 18 janvier 2014 à 10:26.
Je ne tiendrais pas la discussion technique que tu souhaites, mais plus simplement y apporter un point de vue de sysadmin qui suit l'actualité (et peut être relancer ce thread) Et ça me fait bien marrer de voir kdbus aujourd'hui porté dans la branche principale après les commentaires rageux d'il y a quelques années «mais ils sont fous / c'est dégueulasse / on en a pas besoin» lorsque ghk a mis cette demande (venant de l'automotive) dans sa branche. Il y a un petit goût de déjà vu … :) Concernant systemd, c'est déconcertant la facilité avec laquelle il est maintenant possible de réaliser des choses un peu complexes auparavant, execreload, limitnofile, environnment, conditionpath, stopwhenunneeded, … (et je ne parlerai pas des TTY*, que je n'ai pas pigés et qui me posent qq soucis). C'est un plaisir, un régal, que de pouvoir faire aussi facilement des confs comme ça, je n'avais pas connu plus simple.
Mon tit point de vue de tit sysadmin c'est que systemd gagne haut la main, en explosant tout le reste. Je veux bien "argumenter" là dessus, à défaut d'avoir une discussion de développeur. Nous avons là un système d'init plus simple à utiliser (pour un sysadmin mais aussi -surtout- un intégrateur) tout en permettant plus de possibilités.
A mon humble avis cette discussion est close depuis 2 ans, en fait.
Et toujours à mon bien humble avis, si Debian adopte systemd, ça sera le moment où systemd entrera en production, la communauté peut le prendre en charge non une seule entité. si Debian n'adopte pas systemd par contre, donc n'y fourre plus son nez dedans, là ça sera un frein sévère à systemd (à mes yeux)
(Maintenant on peut troller sur le format binaire (et le niveau de verbosité, et la compacité des informations sur un seul endroit) du journal, qui est horreur : les logs sont faites pour être utilisées, journal visiblement beaucoup moins…lol)
[^] # Re: OpenRC
Posté par bubar🦥 . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 3. Dernière modification le 18 janvier 2014 à 11:11.
Maintenir deux systèmes d'init ne (me) parait pas raisonnable. Doubler le travail (même si openrc demande bien moins d'efforts) ne semble pas raisonnable.
D'autant que cela déporte la question sur «quel init par défaut», qui se déportera sur «quelle arch», et qui quasi-inévitablement aura en résultat «bien, 4 ans après, le systeme d'init par défaut est utilisé sur 99% des plateformes intel et arm via l'usage de 90% de linux, le reste étant dû au port de kfreebsd puis au quelques choix rares et volontaires d'autres choses que l'init par défaut sur intel/arm/linux». Hum, c'est une projection (d'autres argueront que d'ici là, la glib ne sera plus utilisable/portable sur le noyau freebsd parceque …) certes. Mais même si les résultats étaient différents, à la base cela demande double travail.
Mes deux cents.
[^] # Re: Android sans Google
Posté par bubar🦥 . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 2.
Non je ne connaissais pas, ça a l'air pas mal!
[^] # Re: Android sans Google
Posté par bubar🦥 . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 3. Dernière modification le 07 janvier 2014 à 20:14.
Cyanogen ne sont pas des neuneus, et ce n'est pas que pour les neuneus. Mais ils constituent une foire à neuneus. C'est très différent. J'utilise aussi avec plaisir Cyanogen sur ma tablette. Et sans sourciller, et sans contradiction avec ce que dis précédemment. Cyanogen .. je vois ça (le "je" est important pour replacer le truc à sa juste valeur, pas grand chose) comme étant une foire à neuneus car c'est de la précipitation permanente. Ils ont des devs génieux chez XDA en général.
Je ne juge pas de ça. Mais il me semble que le mode de fonctionnement et les outils utilisés ne sont pas à la hauteur du travail produit. On dirait des excités du code fermés qui découvrent le code ouvert. Voilà, c'est tout. C'est à dire qu'il ne faut pas juger du taf mais des méthodes : ils n'utilisent pas (pour une raison inconnue) de service (dé)centralisé de versions, qui soit ouvert. C'est ça qui me chagrine. En vrai, on peut voir ça comme des "génies qui ne savent pas" (pour encore exagérer les propos), et il est fort probable que le mieux soit de les encourager… Parcequ'à terme c'est sûr et certain que leurs reflexes primitifs (publication de "versions privées", absence d'usage d'outils de versionning ouverts) ne soient pas représentatifs de ce qu'ils souhaitent.
Restons optimistes, la "foire à neuneus" n'est quà prendre dans son contexte, ie les méthodes et le fonctionnement. Pas le travail et les réalisations.
mes deux petits cents
[^] # Re: Chromebook
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 2. Dernière modification le 06 janvier 2014 à 19:18.
D'après Coreboot, bus-pirate fait l'affaire. D'après la doc de Bus-Pirate, la 4 n'est pas encore destinée à tous, et la 3 est conseillée. C'est donc aussi la 3 que je vais acquérir.
[^] # Re: Chromebook
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 2.
Chroot d'une Gentoo standard dans la Gentoo ChromeOS ? Ou bien chroot dans la Arch ? Peu importe, remarque…
Je pense que le mieux est de commencer par virer ChromeOS. Car à partir du moment où l'objectif est de totalement refaire le système, alors à objectif atteint plus de ChromeOS possible (plus de clef pour booter dessus). Quelque soit la distrib que tu choisis pour cela.
Je ne sais pas si le stage1 existe encore, mais je pensais plutôt partir d'un stage3 dans une machine virtuelle (de nos jours c'est plus rapide que de mettre en place une chaine de cross-compilation, sans pour autant perdre du temps à la compil, ça dépend de la machine hote, enfin chacun fait comme il voit, avec ses habitudes et sleon ses besoins) Arm sur un x86 puissant.
Bref tu as une Gentoo + une Arch qui bootent dessus :)
Il n'y a rien d'obligatoire. Ni "en théorie" ni en réalité, puisque l'EC n'est pas du tout une étape obligatoire pour Coreboot. Seul le SPI compte pour cela (donc faire sauter le petit anneau et sa vis, pour passer le SPI en read-write totalement). Flasher l'EC est optionnel, et pas du tout nécessaire pour Coreboot. Mais comme c'est possible, et qu'on a les sources, j'y vais aussi :-) Enfin, seul l'EC nécessite un programmateur externe. Le SPI n'a besoin que de passer en RW pour être atteignable par flashrom directement.
De celle de Coreboot pour l'essentiel.
La doc de ChromiumOS dit "don't do that" :-)
Non, pas besoin, donc.
Du moins, la doc n'est pas très florissante. Et c'est un attrait. Par ailleurs, je compte remonter mes petites modifications (sur Das U-BOOT) à Parasense en premier lieu, afin de le remercier pour avoir rendu cette possibilité plus facilement accessible via son image pour carte SD. Pour la doc, je ne suis pas à même d'écrire autre chose qu'un compte rendu, d'autres jugeront si ça vaut le coup de l'intégrer dans un wiki.
Mais vraiment, c'est vrai que les docs ne courrent pas les rues…
ps : je n'utilise pas Jabber, désolé. uniquement irc et les tribunes.