bubar🦥 a écrit 6904 commentaires

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 ?

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….

s/Facebook/Amazon
:p

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 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.

C'est Gnome-shell qui doit gérer ça, et je ne vois pas de paramètres permettant de faire cela …

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 ??)

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.

Mes deux cents.

Non je ne connaissais pas, ça a l'air pas mal!

Cyanogen ce n'est pas que pour les neuneus

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

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.

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.

/* mode pinailleur

cyanogène sans code fermé

Tu vas rire…
Cyanogen est pire que Google. D'une part elle est totalement connectée à Google (son système de compte n'est pas indépendant, il repose entièrement sur Google Cloud) D'autre part le code ajouté par Cyanogen n'est pas librement accessible, cela fait presque un an que des "devs noyaux" de cyanogen se font tacler, lire ici par exemple (et leurs comptes g+ ne sont pas piqués des vers) :
http://lists.gpl-violations.org/pipermail/legal/2013-February/003529.html
et d'autres s'amusent à publier des "versions privées" uniquement sur leur twitter ..

Cyanogène, c'est la foire à neuneus, pour l'instant, gageons que les outils et les process de développement s améliorent au fil du temps, pour arriver à avoir un fonctionnement qui soit digne des codes qu'ils utilisent, et de leur projet. ☺

Salut vlotho,

Commences par bien installer Gentoo dessus (je suppose que tu vas la cross-compiler ?). Je n'ai pas encore flasher Coreboot sur le mien (je viens juste de finir d'installer "ma" Fedora, et ça m'a pris du temps…), Coreboot suivra, et l'EC (me faut acheter un programmer externe, tel que «bus pirate» ou autre)

Pour ta question, il semble que l'on ai le choix ;-) Soit coreboot seul, soit coreboot en plus de u-boot (la seconde réponse dépend de cette première) Perso je choisi de suivre la doc du projet. Je mettrai en ligne mon "compte rendu d'installation" et suivra "compte rendu de coreboot", si d'aventure le yes_I_want_a_brick se passait bien … Le SPI fait 4MO, ce qui laisse de la place …mais peut être pas assez pour coreboot+noyau. Ma première tentative sera "coreboot + payload grub" avec noyau sur le disque.

En tout cas, j'ai beaucoup appris sur Das U-Boot, et EFI, et les SPI, ce week-end… (tu devra également nettoyer le merdier de Parasense, ses confs sont "fautées" et son boot.scr mal fait. En tout cas, ne pas t'en inspirer puisque tu pars de Gentoo, pas plus que des conseils de Berranger) Pas facile de faire un tuto…

C'est bien tentant de le faire dès maintenant, ce "step", d'autant que Samsung fournit les sources de tout (EC, SPI, Das U-boot) et intègre bien les modifications en les poussant sur kernel.org (tu verra dans le dernier, pour comparer :) Bref, cette machine est réellement "historique" pour nous, il me semble … Non ?

bonsoir,
pas vraiment de conseils à donner, simplement un appui sur ta remarque à propos de la reconversion.
globalement un 'inge unix' coûte plus cher qu'un 'inge windows'. globalement un 'inge linux' côte à peu près pareil qu'un 'inge windows'. toujours globalement, les linux sont très recherchés, vraiment. et sont souvent multi casquettes (capables sur des aix, sur du celera de l emc ou du netapp, autant sur la couche système que applicative, et sont à l aise aussi sur des équipements réseaux)

donc il n'est pas difficile de voir le mouvement, d'autant plus que les ingés windows sont souvent spécialisés de par le cercle certifs->poste->expérience.

donc va y sans à priori, ton expérience Microsoft sera très probablement un atout, surtout avec des technos comme sssd/ad, samba4/cifs … ce n'est pas seulement l occasion de toucher à un autre système, dont les bases ont être posées par les anciens, c'est aussi l occasion de toucher à des technos particulières comme les clusters, les problématiques d archi du stockage,… les sujets très intéressants sont nombreux sur "unix".

c'est donc le bon moment : le marché (mouvement d employés) bouge peu, mais les postes linux ne cessent d'augmenter, enfin linux commence à s'industrialiser(automatiser/simplifier) en évitant les écueils des autres unix.

tout ça pour dire que :

Trouver une entreprise qui accepte un profil Windows pour le mettre à bosser sur du libre ? A voir, mais les doubles compétences ont l'air moins recherchées que les profils spécialisés

ne sous estime pas ce point. les sysadmins linux manquent, entre un débutant qui n'a pas conscience des contraintes et quelqu'un d'expérience qui fait cette démarche volontaire, mon choix serait vite fait, d'autant plus si j'y ajoute le bien à l'équipe (motivation de cette arrivée plus possibilité de lui déléguer des trucs que des vieux briscards unix rechignent à faire). C'est un bel atout que tu as.

mais ça c'est le business. et si libre et business se marient à merveille, le libre c'est avant tout des communautés…

mes deux cents ☺

D'origine, sur ce modèle c'est Das U-Boot (remplaçable par coreboot)
Certains modèles de chromebooks ont un mix entre u-boot & coreboot
D'autres ont coreboot seul.

Les «Pour» :

Le Coreboot livré est configuré ainsi :

• Coreboot payload grub2 (ce dernier se trouve donc dans le BootFlash / spi)
• grub2 lance le noyau (ce dernier se trouve donc sur le disque dur)
• De plus, toutes les parties non-libres (firmwares vendors) ont été retirées de ce Coreboot.
• La ROM VGA remplacée par une implémentation libre !
• Le support de l'acpi spécifique aux thinkpads ajoutés dans Coreboot (permettant d'avoir le backlight immmédiatement)

C'est donc une excellente solution pour faciliter l'installation d'une distribution, et les mises à jour de cette dernière. De plus, le Coreboot préparé par gluglug propose, via le menu de coreboot, de booter un SeaBIOS et/ou un memtest (ces deux derniers étant donc aussi dans le SPI, comme payloads de coreboot)

Les autres bonnes nouvelles :

• Le bootflash/spi permet aussi de placer le noyau directement en son sein, comme payload direct
• Et même d'y ajouter une BusyBox.

Ce qui ouvre des portes particulièrement intéressantes pour tous ceux qui voudraient aller plus loin avec ce laptop. (Egalement possible d'ajouter un autre kernel + une busybox ou un initrd personnel, si le fait de lancer un kernel monolithique sans initrd ne vous plait pas, et de lancer comme option depuis le menu. Bref, absolument le meilleur des mondes. Ça va être drole de mettre à jour son kernel en faisant un flashrom) Ceci n'a pas été testé par Sir Rowe, mais il vient d'en confirmer la possibilité par mail.

Les «Contre» :

• La carte graphique, qui ne permet rien (un antique "intel media accelerator 950") ou presque :-/
• Pour le SATA 1 seulement, ça suffit dans un usage "IRL" d'un portable, avec un ssd les performances ne seront pas celles du même ssd sur un sata2 ou 3, bien sûr, mais seront suffisantes pour booter en moins de 10 secondes réelles et avoir un bon confort d'usage.
• Pour l'autonomie, elle semble correcte bien qu'elle ne soit pas au niveau d'un chromebook récent…
• Impossible de faire booter directement le noyau comme payload de coreboot, sans chainer le payload grub2, avec le remplaçant du Vbios (ROM VGA libre) Référence (avec un merci à "notre" PatrickG sur la page)

Facilement, pour Coreboot, peut être pas. Cependant il semble bien que les Chromebooks soient l'option de choix pour les libristes, oui.

Le Samsung Chromebook (version ARM) possède deux micrologiciels distincts :

• Un micrologiciel spécifiquement dédié au clavier et aux combinaisons spéciales de touches, ainsi qu' apparement une partie des infos matos (batterie, température).
  • Le projet Coreboot ne dit rien de plus à ce sujet, hormis qu'il ne modifie pas celui-ci.
  • Les sources, et la doc, sont présentes
  • pour flasher celui-ci il faut passer par le port "debug" présent sur la carte mère (pas besoin de flasher ça pour installer coreboot)
• Le "RO SPI" flash contenant le Bootloader basé sur Das U-BOOT
  • Le code source est ici

Pour Flasher Coreboot :

• Passer en "mode dev" ;
• Installer GNU/Linux ;
• Outrepasser la protection à l'écriture du "RO SPI" en enlevant un contacteur placé à côté du port usb2. Un petit anneau de métal fixé ;
• Options pour la compilation de Coreboot
• Options spécifiques à la carte mère "Exynos" de Samsung, présente sur ce modèle de Chromebook, qui est la première carte mère armv7 totalement supportée par le projet Coreboot.
• Flasher en utilisant flashrom, disponible en rpm/deb de la distribution ;

Flasher un portable jusqu'au trognon, c'est pas mal, quant même… Bien que cette étape ne soit pas nécessaire pour installer une distribution GNU/Linux (Fedora KDE fonctionne royalement bien) sur ce chromebook. Pour cela il suffit de passer en "mode dev" (combinaisons spéciales de touches : esc+refresh+power), de booter sur la sdcad (recovery -> ctrl+u), et de copier le système sur la partition.

Nous n'avions jamais atteint un tel niveau d'ouverture sur des matériels grand public, à ma connaissance du moins. En cela, les Chromebooks sont bel et bien le meilleur choix pour GNU.

Un jeu de simulation de course cyclistes et de gestion d'équipes dans le tour de France. Lançable uniquement en positionnant la date à dimanche matin. Pour leurs vieux jours.

Gnome Shell est un environnement simple et efficient. Dont je ne vois aucun intérêt sur un desktop. Vraiment aucun. C'est taillé pour être une interface graphique de serveur. Intégré, simple, efficace. Alors je sais que "une interface graphique sur un serveur c'est nul", et je suis d'accord, mais les commentaires ici même (pourtant) rappelle que configurer un agrégat en graphique c'est bien, configurer des zones de firewall en graphique c'est bien, gérer ses sauvegardes en graphiques c'est bien. Etc, etc … Peut être que c'est bien de retrouver exactement le même environnement sur ses serveurs, ses stations et son portable ? Je ne sais pas, chacun ses goûts.

La fonction ultime sera peut être (??) que ma session gnome-shell se connecte à un serveur et non pas moi qui me connecte à une session graphique sur un serveur … vous voyez ?

En tout cas, pour mon desktop personnel, mon intransportable workstation, mon chromebook arm… c'est du KDE. Pas seulement parcequ'il est configurable en 30 secondes (pas seulement parceque j'aime l'humour d'avoir encore à cliquer sur "left button - one click" 'central/double button - two clicks" "right button - three clicks") mais aussi parceque c'est important le ressenti : pouvoir passer à 50ms (au lieu de 500ms par défaut) pour l'activation du passage en visu des bureaux, passer la réaction/vitesse de la souris à x2, rapettiser la taille du wm, ne se servir que de lui + le krunner comme d'une session desktop … Bref tout ce qui fait que KDE nous convient exactement parcequ'il est configurable rapidement et finement. Aussi parceque, contrairement aux 3~4 pôv extensions gnome-shell, c'est un bureau solide aux mises à jour : ça fait combien de temps que je n'ai pas resetter mon .kde ?? oulalala je ne sais même plus. Tout fonctionne, et je vois quant même les nouveautés (le passage au nouveau module (gadget ? sic) pour NM)

Bref, ici c'est du pure KDE, et des serveurs sans x.

Mes deux cents.

Ha, tiens ?
C'est quoi le modèle ? Perso, sur mon Acer (V3 771G, avec la particularité d'avoir un optimus amputé car sans lien direct écran - seconde carte gfx), le LiveCD KDE passe nickel (il boot et donne accès immédiatement à toutes les fonctions en graphiques) tandisque les installations se passent ainsi :

• netinstall bugg si on choisit fr_fr, il ne faut pas changer la map clavier ni la localisation, sinon anaconda pète un bug fatal
• dvd install nécessite "basic graphics mode" + "nomodeset" , reboot nécessite ajout de "acpi_backlight=vendor" sur le kernel fedora
• cd install nécessite "basic graphics mode" + "nomodeset", reboot nécessite ajout de "acpi_backlight=vendor" sur le kernel fedora

Voilà, une fois installé, je compile le kernel vanille et tout va bien (sans utiliser le backlight=vendor, qui créeait des freeze aléatoires faisant penser à un pb de ram, alors que c'est un pb d'acpi). Tout va bien, avec un i915 seul, ou avec nouveau… ou les deux à la fois.

Bonsoir,

Pendant longtemps j'ai suivi les docs, et les résultats de mes tests, pour faire des montées de version. Quelque soit la distribution utilisée, cela a bien fonctionné (cependant c'était sur Mandrake, et ensuite uniquement avec yum, je n'ai essayé preupgrade qu'une fois et c'est un mauvais souvenir). Je mettais même un point d'honneur à utiliser kexec, afin de minimiser le temps d'interruption (ayant une workstation dell avec 6 disques scsi, avec une carte nvidia, vers ~2005, et la grande chance que tout fonctionne dessus pour kexec malgré le handicap nvidia). Puis je suis passé à la préparation des montées de versions : dès l'installation la prévision de la montée de version par réservation d'une partition dédiée à accueillir une copie du système sur lequel la mise à jour est appliquée par chroot, puis on boot sur l'autre racine : ça passe et la racine initiale devient la préparation, sinon on revient sur la racine initiale.

Un jour j'ai essayé la sauvegarde et l'installation. Je ne suis plus jamais revenu en arrière. Parceque je suis feignant et je n'aime pas me casser la tête, enfin le gain de temps est considérable.

quant à

à placer dans une soirée mondaine le mercredi.

j peux pas j'ai piscine
désolé