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.
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. ☺
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 4.
Dernière modification le 05 janvier 2014 à 21:06.
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…
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 3.
Dernière modification le 24 décembre 2013 à 11:31.
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.
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 6.
Dernière modification le 22 décembre 2013 à 15:19.
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)
Posté par bubar🦥 .
En réponse au journal Gluglug.
Évalué à 10.
Dernière modification le 06 janvier 2014 à 00:20.
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.
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.
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.
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.
Dans les techno citées, pas une ne remplace le liquide…
Qui par définition est « liquide »… Pourtant ça ne serait pas dur de faire un terminal de stockage et d'encaissement. Tu "sors" 500€ de ta banque, que tu déposes sur ton terminal, et tu transfères ce "liquide" sur le terminal du marchand. Ceci sans aucune empreinte de plus que le liquide. Et dans les mêmes limites avec ton service bancaire (quantité, droit de retrait, etc)…
Mais non, toutes ces technos visent à enregistrer même les transactions les plus banales et minimes, même pour une baguette de pain ou un échange entre amis. Tout, tout tout ils sauront tout … C'est ça qui gène à la fois le développement de méthode de paiement, sur le net et de mains-àmains, vraiment -réellement- alternatives au billets et pièces.
L'avenir est tout tracé.
L'argent liquide coûtera plus cher que l'argent électronique. L'abandon se fera petit à petit à cause de ça. Et nous, nous perdrons la dernière parcelle de liberté : celle de l'échange direct et sans trace.
Parmi conseils prodigués par Mr Bortzmeyer lors de ses conférences, il recommande de mettre en place un serveur de test (ayant dnssec) sur une période de 6 mois. 6 mois /o\
Parmi les interrogations légitimes face à dnssec, à laquelle il n'y a pas de réponse, il reste l'abandon des politiques de coupures de flux au delà d'une certaine taille de paquet, dnssec demande de gros paquet, et du coup facilite le dns2tcp. Dnssec c'est un peu le haut débit du dns2tcp…
DNSSEC me semble (humblement, hein) un "yeux plus gros que le ventre" : améliorons d'abord le fonctionnement des DNS actuels, et des équipements autour, avant de s'attaquer à un tel morceau.
L'enseignement de la matière, est inexistant voire très sommaire
+1 C'est regrettable de n'avoir que peu de cours sur le sujet.
Pas d'histoire de l'économie, peu de champs, en fait l'économie (en dehors des filières spécialisées sur le sujet ou un sujet proche) se servent des quelques cours disponibles pour survoler la situation. +1 car en théorie c'est toujours mieux d'avoir un minimum de repères, mais la spécialisation à marche forcée d'un côté, et la quantité de données d'un autre côté, font qu'il est difficile d'aborder tout les sujets. Et perso, s'il y avait encore des cases de libres, je préfèrerai les consacrer à la culture scientifique.
en plus, comme on va le voir plus loin, ne fait pas forcément passer le bon message.
L'enseignement n'a pas "à faire passer de message", mais à donner des repères culturels puis les outils permettant de construire un regard critique. (" Faire passer un message" se fait très à la marge, quelque soit la matière enseignée )
Si ce que tu veux c'est faire du bourrage de crâne avec une telle quantité de données que les seuls choix finaux, sur l'orientation du futur citoyen/décideur/whatever, sont des ajustements à la marge d'une idéologie dominante, alors ce n'est plus de l'enseignement.
parce qu'il ne voit plus la librairie qu'a à le gérer
Je ne suis pas sûr d'avoir bien compris cette phrase, et la "perte de librairies" (non, pas de bibliothèques) je n'ai 'jamais vu/entendu parler' de ça. Par contre lors de (re)boot sur des Redhat 6, TiNa perd ses librairies lorsqu'elles sont distantes sur des baies, parceque le noyau refait dynamiquement l'attribution des devices alors que TiNa veut des wwn. Refaire à la main ces attributions lors des reboot, pour avoir un tina fonctionnel, c'est pas terrible. Mais les prochaines versions auront intégrés un patch (sic, juste une conf udev) pour permettre de faire du persistant binding quelque soit la techno sous-jacente. Sinon, refaire à la main les wwn pour que TiNa retrouve ses petits, à chaque boot, c'est pas terrible.
installe en cochant tout ce qui était dispo dans anaconda
Il faut le pendre haut et court.
Même si l'impact est nul, avec des mises à jour aux petits oignions, c'est crade. Là c'est probablement une amélioration si tu proposes un kickstart « voilà ce qu'est "redhat pour serveur autonome" ici, et tu t'y tiens » à ton intégrateur/installeur.
je trouve yum lent
On parle de machines de guerre qui hébergent souvent les informations du coeur de métier, et vous parlez de savoir si toto prend une seconde de moins que titi pour réaliser une proposition de mises à jour ? Non mais … LOL Et puis, celui gérant les mises à jour avec yum, faut le pendre aussi, hein :p
puppet n'est pas dispo dans les dépots
Et OpenShift & OpenStack, ça n'existe pas ? Sérieux, là, dire "n'existe pas chez redhat" c'est faux. Puppet n'existe pas pour les versions serveurs de base, et il y a des raisons à cela. Et si tu en as besoin parceque tu a choisi Puppet pour une partie de l'administration de ton parc, ben c'est ton choix pas celui de l'éditeur.
je refuse de faire l'administration de ce truc, pour moi, c'est une verrue sur mon réseau.
ça a du sens, l'homogénéité facilite tout.
[EDIT : fai indique ne pas supporter officiellement redhat] Pour Puppet, je ne rejoins pas le commentaire plus bas disant d'utiliser le dépôt fourni par le projet. Ton approche est la même que celle décrite plus haut : prudents, on prends la version de l'éditeur, pour toi, Debian. Heureusement l'intérêt de Puppet sur des serveurs de sauvegardes tina est très faible …
Correctif : pour cette mauvaise aventure, qui a générée ce troll fort sur Novell SuSE, Novell n'est pas absolument pas en cause (c'est l'intégrateur qui a bidouillé à l'arrache ce qui a entrainé des incohérences)
Je fais amende honorable sur ce troll là, et présente mes excuses à la communauté OpenSUSE présente sur ce site.
Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell… Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)
[^] # 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.
[^] # Re: Android sans Google
Posté par bubar🦥 . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 6. Dernière modification le 05 janvier 2014 à 23:57.
/* mode pinailleur
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. ☺
[^] # Re: Chromebook
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 4. Dernière modification le 05 janvier 2014 à 21:06.
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 ?
[^] # Re: Yeap
Posté par bubar🦥 . En réponse au message Reconversion professionnelle vers le libre. Évalué à 8. Dernière modification le 30 décembre 2013 à 23:53.
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 :
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 ☺
[^] # Re: Chromebook
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 3. Dernière modification le 24 décembre 2013 à 11:31.
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.
# Encore des précisions
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 6. Dernière modification le 22 décembre 2013 à 15:19.
Les «Pour» :
Le Coreboot livré est configuré ainsi :
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 :
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» :
[^] # Re: Chromebook
Posté par bubar🦥 . En réponse au journal Gluglug. Évalué à 10. Dernière modification le 06 janvier 2014 à 00:20.
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 :
Pour Flasher Coreboot :
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.
[^] # Re: Dommage
Posté par bubar🦥 . En réponse à la dépêche Offrez des CD/DVD de jeux libres pour les fêtes. Évalué à 4.
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.
[^] # Re: GNOME Shell est laid
Posté par bubar🦥 . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 5. Dernière modification le 20 décembre 2013 à 00:17.
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.
[^] # Re: damn...
Posté par bubar🦥 . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 3. Dernière modification le 19 décembre 2013 à 23:42.
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 :
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.
[^] # Re: Utilisateur lambda...
Posté par bubar🦥 . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 2. Dernière modification le 19 décembre 2013 à 23:31.
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.
[^] # Re: Rhombicuboctaèdre...
Posté par bubar🦥 . En réponse à la dépêche Firefox 26. Évalué à 1.
quant à
j peux pas j'ai piscine
désolé
[^] # Re: Non
Posté par bubar🦥 . En réponse au journal Steam OS version facile. Évalué à 4. Dernière modification le 17 décembre 2013 à 21:15.
On peut ajouter que le fichier FreeDesktop présenté ici peut être amélioré avec un :
Type=Service
X-DBUS-StartupType=Unique
voir en plus :
X-KDE-StartupNotify=true
X-KDE-autostart-phase=BaseDesktop
Puis placer le tout dans son ~/.kde/share/autostart (non, pas .kde/Autostart, pas non plus .config/autostart, mais bien .kde/share/autostart lol)
ps : le & dans Exec c'est sale
[^] # Re: Gné
Posté par bubar🦥 . En réponse au journal Paylib va enfin remplacer paypal !. Évalué à 3. Dernière modification le 05 décembre 2013 à 00:02.
Dans les techno citées, pas une ne remplace le liquide…
Qui par définition est « liquide »… Pourtant ça ne serait pas dur de faire un terminal de stockage et d'encaissement. Tu "sors" 500€ de ta banque, que tu déposes sur ton terminal, et tu transfères ce "liquide" sur le terminal du marchand. Ceci sans aucune empreinte de plus que le liquide. Et dans les mêmes limites avec ton service bancaire (quantité, droit de retrait, etc)…
Mais non, toutes ces technos visent à enregistrer même les transactions les plus banales et minimes, même pour une baguette de pain ou un échange entre amis. Tout, tout tout ils sauront tout … C'est ça qui gène à la fois le développement de méthode de paiement, sur le net et de mains-àmains, vraiment -réellement- alternatives au billets et pièces.
L'avenir est tout tracé.
L'argent liquide coûtera plus cher que l'argent électronique. L'abandon se fera petit à petit à cause de ça. Et nous, nous perdrons la dernière parcelle de liberté : celle de l'échange direct et sans trace.
[^] # Re: != Ubuntu
Posté par bubar🦥 . En réponse au journal Valve rejoint la fondation Linux. (ainsi que d'autres). Évalué à 1. Dernière modification le 04 décembre 2013 à 22:48.
+1 sur Gentoo.
Gentoo, what's else ?
[^] # Re: DNSSec
Posté par bubar🦥 . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 6. Dernière modification le 25 novembre 2013 à 18:03.
Parmi conseils prodigués par Mr Bortzmeyer lors de ses conférences, il recommande de mettre en place un serveur de test (ayant dnssec) sur une période de 6 mois. 6 mois /o\
Parmi les interrogations légitimes face à dnssec, à laquelle il n'y a pas de réponse, il reste l'abandon des politiques de coupures de flux au delà d'une certaine taille de paquet, dnssec demande de gros paquet, et du coup facilite le dns2tcp. Dnssec c'est un peu le haut débit du dns2tcp…
DNSSEC me semble (humblement, hein) un "yeux plus gros que le ventre" : améliorons d'abord le fonctionnement des DNS actuels, et des équipements autour, avant de s'attaquer à un tel morceau.
[^] # Re: Pourquoi les gens comprennent aussi bien l'économie que les (pseudo-)experts ?
Posté par bubar🦥 . En réponse au journal L'économie cette méconnue. Évalué à 3.
tl;dr dirait on, mais l'intro est tellement bonne que j'ai lu jusqu'au bout :-)
Sciences naturelles VS sciences humaines, ça me plait assez, adopté.
Merci.
# Enseignement
Posté par bubar🦥 . En réponse au journal L'économie cette méconnue. Évalué à 3.
+1 C'est regrettable de n'avoir que peu de cours sur le sujet.
Pas d'histoire de l'économie, peu de champs, en fait l'économie (en dehors des filières spécialisées sur le sujet ou un sujet proche) se servent des quelques cours disponibles pour survoler la situation. +1 car en théorie c'est toujours mieux d'avoir un minimum de repères, mais la spécialisation à marche forcée d'un côté, et la quantité de données d'un autre côté, font qu'il est difficile d'aborder tout les sujets. Et perso, s'il y avait encore des cases de libres, je préfèrerai les consacrer à la culture scientifique.
L'enseignement n'a pas "à faire passer de message", mais à donner des repères culturels puis les outils permettant de construire un regard critique. (" Faire passer un message" se fait très à la marge, quelque soit la matière enseignée )
Si ce que tu veux c'est faire du bourrage de crâne avec une telle quantité de données que les seuls choix finaux, sur l'orientation du futur citoyen/décideur/whatever, sont des ajustements à la marge d'une idéologie dominante, alors ce n'est plus de l'enseignement.
[^] # Re: Troll
Posté par bubar🦥 . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 3. Dernière modification le 24 novembre 2013 à 16:09.
/* mode troll, topix troll :-)
Je ne suis pas sûr d'avoir bien compris cette phrase, et la "perte de librairies" (non, pas de bibliothèques) je n'ai 'jamais vu/entendu parler' de ça. Par contre lors de (re)boot sur des Redhat 6, TiNa perd ses librairies lorsqu'elles sont distantes sur des baies, parceque le noyau refait dynamiquement l'attribution des devices alors que TiNa veut des wwn. Refaire à la main ces attributions lors des reboot, pour avoir un tina fonctionnel, c'est pas terrible. Mais les prochaines versions auront intégrés un patch (sic, juste une conf udev) pour permettre de faire du persistant binding quelque soit la techno sous-jacente. Sinon, refaire à la main les wwn pour que TiNa retrouve ses petits, à chaque boot, c'est pas terrible.
Il faut le pendre haut et court.
Même si l'impact est nul, avec des mises à jour aux petits oignions, c'est crade. Là c'est probablement une amélioration si tu proposes un kickstart « voilà ce qu'est "redhat pour serveur autonome" ici, et tu t'y tiens » à ton intégrateur/installeur.
On parle de machines de guerre qui hébergent souvent les informations du coeur de métier, et vous parlez de savoir si toto prend une seconde de moins que titi pour réaliser une proposition de mises à jour ? Non mais … LOL Et puis, celui gérant les mises à jour avec yum, faut le pendre aussi, hein :p
Et OpenShift & OpenStack, ça n'existe pas ? Sérieux, là, dire "n'existe pas chez redhat" c'est faux. Puppet n'existe pas pour les versions serveurs de base, et il y a des raisons à cela. Et si tu en as besoin parceque tu a choisi Puppet pour une partie de l'administration de ton parc, ben c'est ton choix pas celui de l'éditeur.
ça a du sens, l'homogénéité facilite tout.
[EDIT : fai indique ne pas supporter officiellement redhat] Pour Puppet, je ne rejoins pas le commentaire plus bas disant d'utiliser le dépôt fourni par le projet. Ton approche est la même que celle décrite plus haut : prudents, on prends la version de l'éditeur, pour toi, Debian. Heureusement l'intérêt de Puppet sur des serveurs de sauvegardes tina est très faible …
[^] # Re: On est presque vendredi
Posté par bubar🦥 . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à 2.
Correctif : pour cette mauvaise aventure, qui a générée ce troll fort sur Novell SuSE, Novell n'est pas absolument pas en cause (c'est l'intégrateur qui a bidouillé à l'arrache ce qui a entrainé des incohérences)
Je fais amende honorable sur ce troll là, et présente mes excuses à la communauté OpenSUSE présente sur ce site.
[^] # Re: On est presque vendredi
Posté par bubar🦥 . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à 3. Dernière modification le 16 novembre 2013 à 10:45.
Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell… Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)
[^] # Re: trucs & machins...
Posté par bubar🦥 . En réponse au message [RESEAU] Fragmentations de paquets tcp. Évalué à 2.
Tu as raison, alors voici de la doc en sup :
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-June/008395.html
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm
# rêve ?
Posté par bubar🦥 . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à 1.
C'est plutôt un cauchemar …