On a effectivement des mises à jour quotidiennes intrusives, avec
des impacts bizarroïdes pour le non-initié (ex : maj de Firefox
pendant qu'il tourne).
Nan, mais y a pas que le non initié qui va trouver l'impact bizarre :)
Pour régler ce souci, flatpak (et ostree, tel qu'utilisé par Fedora Atomic Workstation) sépare la mise à jour de son application. En utilisant des containers et des images, tu peux faire la mise à jour sans que ça impacte et sans doute un jour par défaut.
Le soft ne va utiliser la mise à jour que lors du prochain lancement, ce qui réduit certains effets pourris.
Et la question des mises à jour trop fréquente, c'est un souci qui n'arrive pas partout. J'utilise une RHEL 7 sur mon pc portable, et j'apprécie de ne pas avoir des mises à jours sans arrêt. Par contre, sur Fedora, je me souviens de discussion il y a déjà 5 ans pour réduire la fréquence des mises à jours. Ça n'a pas abouti, mais la demande est assez courante.
Quant à abrt, même si je ne nie pas le problème, n'ayant jamais
subi ce bug, il n'est sans doute pas si évident que ça à
reproduire et corriger. Puis la plupart des gens ne faisant pas
de rapports de bugs, ils peuvent sans problème le désactiver.
Et ensuite rale sur le fait que les trucs sont instables et non corrigés :/
Le directeur de cette boite israélienne inconnue jusqu'ici dirige
aussi le hedge fund NineWells qui a de grosses positions "short"
sur AMD (autrement dit : ils font un bénéfice si l'action
baisse).
J'aurais à priori tendance à dire que c'est sans doute illégal vis à vis de la SEC. Ça le serait si c'était des employés AMD (insider trading), mais la, vu que c'est des externes, je suis moins sur.
En tant qu'utilisateur, j'en ai juste rien à faire, mais je ne
peux quand même pas remonter le bug.
Alors, je pense que le noeud du problème est la. Si tu va sur bugzilla, c'est pour contribuer et ça requiert un minimum de connaissance technique hélas pour ça. Par pour du support.
Ce que tu sembles vouloir, c'est du support comme tu demanderais à ta banque ou ailleurs, ce qui est différent. Et je sais pas si tu as lu la GPL ou les licences du même genre, mais c'est marqué que c'est globalement pas inclus, partout.
Par la, je veux pas dire que "fallait lire avant d'accepter". Je veux dire que l'idée qu'aider les gens est optionnel et n'est pas un but fait parti des principes fondateurs du logiciel libre, à tort ou à raison.
Et ça se voit partout dans ce qui est mis en place.
Tu donnes l'exemple du support sur irc. C'est globalement mauvais et le niveau 0 de support, loin des bonnes pratiques du métier.
Pas de concept de shift (genre, tu sais pas si il y a une personne qui va te répondre).
Pas de suivi des gens ou des problémes (genre, si tu reviens le lendemain, les gens vont ou ne vont pas avoir de contexte).
Pas de process sur qui fait quoi et comment. C'est courant d'avoir 3/4 personnes qui vont aider 1 personne d'un coup, ce qui serait risible si c'était au téléphone. Y a globalement pas de formation ou de bonnes pratiques, c'est directement les gens qui savent et basta.
Et je parle même pas du média en lui même, qui est pas non plus super intuitif. Tu t'en sort quand tu es techie, bien sur.
Quand je raconte ça, les gens en général me disent "oui, mais ç'est pas du support professionnel, c'est des volontaires". Je dirais que oui, mais c'est pas une raison. Si tu prends une association du style Artisan du monde, les gens ont des shifts pour tenir la caisse dans les boutiques. Si tu prends des développeurs, ils vont utiliser les mêmes outils dans le libre et dans une startup.
Mais pas pour le support, qui ressemble plus au café du commerce qu'autre chose en général. Parce que le support, c'est dévalué, c'est éprouvant. Mais aussi parce que le support, c'est ce que les gens vont payer dans certains business modèles autour du logiciel libre.
Donc oui, le support est pas terrible. Et franchement, je pense pas que ça change dans le futur. Framasoft a un formulaire de contact, c'est sans doute un peu mieux, mais pas de beaucoup. C'est aussi des gens payés pour ça. Des gens ont tentés stackoverflow ou askbot. C'est un peu mieux, mais ça donne pas forcément des trucs de qualités. Et visiblement, les gens ne conseillent pas ça (la preuve, tu as pas mentionné ça). Je sais que Tails a fait des trucs à ce niveau aussi, mais j'ai oublié quoi. Mais tails fait plein de trucs bien.
Sans un changement des mentalités au niveau du libre entier, non, je vois pas le support changer.
Non, mais je parle du matériel pour refaire une fausse empreinte digital en pratique (ou d'une fausse iris).
Parce que bien sur, un adversaire avec suffisament de pognon pourrait sans doute rentrer chez moi, et utiliser ça pour deverouiller mon appareil. mais ça requiert des préparations, une proximité physique, et sans doute du matos cher.
Et si on parle d'un état, y a des chances que l'état est justement déjà une photos des empreintes. Mais quid justement d'un adversaire avec moins de ressources (exemple, un collégue malicieux, un stalker, un ex petit ami tourné sur la technique), quel investissement est requis ?
stockage des informations biométrique : autant que je sache,
on ne sait pas1 stocker ces infos sous une forme qui serait
équivalente à un haché-salé d'un mdp ; on stocke "en plain text",
ce qui est pour moi très embêtant, notamment dans un système
centralisé (comme en Inde, par exemple ou en France)2 ;
Mais ça n'est pas gênant que si on arrive à recréer un truc équivalent à ton empreinte et/ou ton oeil à partir de ces informations ?
J'avais cru comprendre que justement, c'est une approximation de ton doigt qui est pris et qu'on regarde le positionnement des différents sillons, etc. Même si on arrive à refaire des empreintes sans trop de matos (cf demo du CCC y a longtemps) avec par exemple un verre, je suis pas sur qu'il existe de quoi refaire une empreinte sur la base des infos stockés dans une base (ça ou la même chose pour l'iris).
Je me demande aussi si il n'y a pas des problématiques d’accessibilité. L'informatique soit fait par et pour les gens en bonne santé en général, mais je me demande à quel point le fait de faire certains gestes peut être chiant pour certains.
Le souci, c'est aussi d'avoir une monnaie connecté au reste du monde.
Sinon, bitcoin en tant que monnaie qui s'echange que avec elle même, ça me parait globalement stable. C'est quand tu mets une valeur en monnaie traditionnelle que ça part en vrille, surtout parce que c'est non centralisé (et non régulé):
Ensuite, je sais que l'IDS du taf bloque un protocole lié à Bitcoin, pour éviter que quelqu'un installe une ferme de minage en douce dans les bureaux (et sans doute aussi pour voir les bécanes infectés), donc ce genre de méthode va sans doute à un moment poser souci.
Je suis d'accord que le concept de blockchain est utile pour plein de choses, mais le lien liste quand même un paquet de souci à régler avant que ça soit utile à grand échelle. Et ça, c'est sans même attaquer les problèmes classiques d'un logiciel, comme l'UX, les mises à jour, etc, qui sont autant de choses à régler pour une monnai basé sur un livre de compte distribué.
On arrive quand même à ~ 50 hacks principalement sur les 3/4 dernières années. Ça fait plus que 1 par mois.
Donc l'idée est sans doute séduisante, mais ça scale pas, c'est rempli d'escrocs et c'est mal foutu.
Et faut pas oublier que Bitcoin a 8 ans. C'est aussi vieux que golang, ou à peine plus jeune qu'Android sorti 1 an avant. Je veux bien que ça mette du temps à avancer, mais j'aurais tendance à croire qu'en 8 ans, on aurait pu prévoir ou voir les soucis existants quand même.
En effet, si c'est le cas, ma réponse serait différente.
A savoir qu'il y a toujours pas de changement de casse dans les commandes. La commande systemctl est en minuscule. Si je m'en tiens à l'exemple, le reproche est sur l'argument, mais dans ce cas, c'est cohérent parce que l'argument est un bout de configuration, une option dans les fichiers .services et autres.
C'est la propriété "CPUQuota" qui est changé. Et la, je pense que personne ne va dire "on a jamais eu de CamelCase dans la configuration d'un soft", parce que c'est faux. L'exemple le plus parlant serait Apache, mais je peux citer aussi OpenSSH comme logiciel présent dans le systéme de base de tout les BSD.
Les commandes utilisent aussi la casse pour avoir plus d'options (entre -C et -c pour tar), c'est donc pas non plus rare.
Alors oui, du coup, l'usage du CamelCAse déborde vers la CLI, et je comprends que ça puisse déranger les gens, sans doute parce que comme tout compromis fait, quelqu'un ne va pas être 100% satisfait.
Il y a sans doute des gens qui préfèrent tout en minuscule parce que c'est plus facile à retenir, et d'autres qui préfèrent en CamelCase parce que c'est plus facile à lire. Mais tu peux difficilement satisfaire tout le monde (sauf à supporter tout, mais d'un coup, tu va avoir de l'inconsistence dans la doc ).
De la même façon que tu ne peux pas avoir un truc rapide à taper comme "cp" et en même temps avoir un truc clire comme "copy".
Tu gères comment la dépendances entre les services au démarrage ?
Sur NetBSD et FreeBSD, c'est via des headers proches de la LSB (donc provides, requires) dans les scripts d'init.
Sur OpenBSD, ça n'a pas l'air de le faire, mais j'ai regardé en détail (j'ai juste fait du ssh et des rapides coups d'oeils à des scripts au pif).
Le démarrage conditionnel ?
Sur OpenBSD, via une fonction dans le script d'init (exemple, le script de démarrage de nfsd avec la fonction rc_pre() ).
Sur FreeBSD et NetBSD, tu déclares une variable start_precmd qui pointe vers une fonction , comme pour OpenBSD.
Au final, la différences est de savoir si tu exposes un langage de programmation complet, avec tout ce que ça entraine comme bons et mauvais cotés, ou pas. J'ai tendance à favoriser 'approche configuration plutôt que l'approche programmation, vu que tu arrives assez vite à rajouter de la complexité, et à avoir du code dupliqué partout. Mais je comprends aussi que des gens préfèrent l'autre approche.
Te rends-tu compte que ni la complétion ni le man ne m'ont
aidé???
On a pas du lire la même page de man.
set-property NAME ASSIGNMENT...
Set the specified unit properties at runtime where this is
supported. This allows changing configuration parameter properties
such as resource control settings at runtime. Not all properties
may be changed at runtime, but many resource control settings
(primarily those in systemd.resource-control(5)) may. The changes
are applied instantly, and stored on disk for future boots, unless
--runtime is passed, in which case the settings only apply until
the next reboot. The syntax of the property assignment follows
closely the syntax of assignments in unit files.
C'est la page de man de systemctl sur une RHEL 7. On peut pas dire que ça soit la dernière version ou quelqu'un aurait vite fait corriger la doc pour te contredire, c'est une version 219, qui date quand même d'il y a un ou deux ans. Et parce que je part pas du principe que tu mens, j'ai aussi vérifié sur une Fedora, et la page de man dit grosso modo la même chose.
Encore une fois, je veux bien reconnaitre qu'il y a beaucoup à lire, parce que il y a beaucoup de features, mais dire "la page de man ne m'a pas aidé" me semble être un raccourci qui n'a pas l'air de resister à un examen rapide de la dite page de man, sauf si tu as eu une page de man différente.
Il n'y a jamais eu de "casse" dans les commandes systèmes sous
Unix/Linux*.
Foutaises.
La migration de ifconfig vers ip a commencé y a plus de 10 ans.
L'interface de firewall sous Linux a changé 3 fois avant d'arriver à iptables/netfilter et va encore changer avec nftables.
Solaris a eu des changements de systémes d'init et des tas de commandes nouvelles avec Solaris 10 (sauf erreur de ma part).
Apt-get est devenu Apt sur debian (ou Aptitude pendant un temps, bien que les 2 vont sans doute cohabiter pendant longtemps). Yum est devenu DNF.
Et même au niveau du noyau, quand j'ai commencé, c'est sur /dev/hda1 que j'avais mon bootloader lilo, avec un /dev statique remplacé par devfs assez rapidement.
Ou sur FreeBSD, le fait d'avoir intégré zfs a forcément entrainé des changements de commandes pour gérer les partitions.
C'est dingue, on en est à ne me plus tolèrer la critique sur
systemd alors qu'on ne rejete aucunement toute le framework.
C'est bien la preuve que c'est rien de personnel que de répondre sur le point précis sans se préoccuper du reste.
Ce qui est surtout amusant, c'est qu'au final, il n'y avait pas eu de régulation pendant trés longtemps, sauf depuis décembre 2015. Autant dire que 2 ans, ça a pas du changer des masses.
Bien que la façon dont ça a été fait est scandaleuse, et tout un tas de choses autour, les discussions autour des conséquences ont quand même jamais trop pointés ce qui est arrivé avant, quand ça n'était pas un souci, et je trouve que ça manque.
Non pas que je fasse confiance à Comcast et consort pour pas faire de la merde, mais j'ai quand même aussi du mal avec les hyperboles réthoriques (surtout que les gens n'ont pas de problème à tous aller chez le même fournisseur de mail, et ou on s’aperçoit que les gens sont parfaitement ok avec un monopole tant qu'il fait bien son boulot, mais vont évoqués des grands principes quand c'est plus le cas)
Autant pour moi, c'était pas dans la page de man de rctl sur le freebsd 10 que j'ai regardé.
J'ai beaucoup de mal à voir la pertinence d'une limitation sur
ces ressources, sauf peut-être dans le cas d'une jail ou
d'un process (et encore).
L'idée principal, c'est si tu veux pas que tes backups fassent des I/O qui pourrait ralentir ton site web, ce genre de choses. J'aurais en effet tendance à dire que si tu es à ce niveau de détails, tu as sans doute plus besoin de racheter une machine ou des disques plus rapides, mais ça ne parait pas inutile.
Rien à voir avec de la psychorigidité, tu fais comment pour
retenir tout ça???
Comme tout le reste, tu lit la doc, elle est la pour ça.
Les devs passent leur temps à chercher des trucs sur Google, les sysadmins aussi. Croire que ça n'arrive pas, ou que ça n'est pas la norme, c'est malsain.
Malsain parce que c'est faire croire que les ingés ont des capacités mémoriels au dela du raisonnable, et faire douter les gens qui ont des capacités normales en se disant "j'arrive pa sà retenir, je suis pas normal", ou pour les plus égocentriques "j'arrive pas à retenir, le soft doit être de la merde".
Je dit pas qu'on doit pas faire un effort pour la cohérence, mais non, on peut pas tout retenir, et c'est normal, et c'est pas requis. Savoir que tu peux limiter le cpu devrait suffire.
Quant aux "shares" cpu en %, ça ne semblent pas implémentés
sous FreeBSD, il n'y a qu'une capacité temporelle (cputime)
En l'occurrence, je pense que tu te trompes.La page de man parle de "pcpu":
pcpu %CPU, in percents of a single CPU core Ensuite, c'est tout à la fin de la page de man, donc je comprends que ça puisse passer inaperçu.
Les ports ne sont pas testés et comment pourrait-il en être
autrement ?
Deja, en mettant en place un process pour ça. Je sais bien que c'est plus facile à dire qu'à faire, mais si je prends l'exemple d'une distribution comme Fedora, il y a un systéme en 2 temps. D'abord le paquet va dans updates-testing, puis dans update quand suffisament de gens ont validés le paquet. Installer un paquet depuis la version updates-testing, c'est un switch à donner. Revenir en arriére est aussi simple.
Tu as une incitation à vérifier les paquets (bien que faible), et je pense que le processus pourrait aller plus loin, en laissant les gens s'inscrire comme testeur officiel d'un paquet, et donc en ayant des notifications pour le paquet en ayant directement les versions de tests, etc.
Ou encore, aller vers plus d'automatisation. Avoir un truc qui automatiquement déploie le paquet (style piuparts), avoir un outil qui lance des tests basiques (exemple, un playbook ansible qui install un serveur httpd de base et qui le lance, verifie que ça écoute sur le port 80).
FreeBSD, y a pas tout ça que je sache. Du coup, oui, structurellement, le test est difficile si on suppose que ça va tomber sur une et une seule personne, à savoir le committer.
Et pourtant, la communauté FreeBSD est composé de gens avec des compétences, mais il n'y a pas l'air d'avoir d'efforts pour les utiliser.
Ensuite et encore une fois, je ne dit pas que c'est facile. Les ports étant distribués via svn (sauf erreur de ma part), et avoir une branche par version de test ne me parait pas terrible. Le tooling autour bouge bien, mais l'infrastructure est pas maintenu de maniére ouverte, sans doute plus pour des raisons de ressources et d'historique que pour autre choses. Du coup, oui, faire changer les choses va prendre du temps.
Mais c'est faisable, et dire "Debian a du monde, et pas FreeBSD", c'est à mon avis confondre cause et conséquence. Debian a des gens qui testent parce c'est faisable (faciliter de mise à jour vers testing, incitation social à le faire, etc). Fedora a du monde qui teste pour les mes raisons avec des mécanismes différents. FreeBSD n'a pas l'air d'avoir ça, donc ça n'arrive pas.
Ensuite, je peux me tromper, peut etre que c'est autre chose.
C'est pas non plus strictement équivalent, vu que system (et Linux) est aussi capable de limiter les I/Os, ce qui ne semble pas être le cas sur FreeBSD (en tout cas, pas sur FreeBSD 10 d'après la doc).
Je reconnait que FreeBSD a des trucs en plus, mais à choisir entre le fait de limiter le nombre de PTY et limiter le disque, j'ai quand même le sentiment que le partage du disque va plus souvent me servir.
En vrai, le problème de la version d'un OS n'en est pas un.
Quand tout bouge tout le temps, on automatise beaucoup le
provisionnement des serveurs/VM et l'install des softs. L'OS
entre dans le tronc commun et n'est plus vraiment un point
différenciant (sauf dans des cas très particuliers).
Ceci dit, il y a suffisament de changement pour que l'automatisation puisse devenir un truc relou à maintenir. Par exemple, j'ai fait beaucoup d'automatisation via Ansible, et l'intégration avec l'OS a son importance (genre la gestion du firewall, du reaseau, etc, qui change de version majeur de RHEL en version majeur de RHEL).
Aujourd'hui, au niveau pro, je reste sur Debian car c'est une des
distribs les plus utilisées et possédant un des écosystèmes les
plus gros et varié. Contrairement à FreeBSD, justement.
Et ça, c'est une différence nette entre les 2 qui rend la 1ère
bien plus "professionnelle" que le second…
Oui, pour reprendre encore une fois Ansible, j'ai du rajouter une paire de trucs pour NetBSD (support de la detection de pkgin, divers facts, etc), justement parce que la communauté semble moins active. J'ai toujours pas trouvé de méthode propre pour l'installation automatique de VM FreeBSD via virt-install, et j'ai pas d'image officiel pour usage dans un cloud openstack (Rackspace dans mon cas) pour NetBSD.
Pour OpenVz, je n'ai pas dit que c'était de la faute de l'un
ou l'autre. Mais qu'est ce que vient foutre un outil de
Virtualisation dans tout les OS si la version d'après plus rien
n'est supporté, sérieusement c'est quoi cette organisation ?
En l'occurrence, c'est OpenVZ qui a fait le choix d'être en dehors du kernel.
Après des années et des années de "oui, on réécrit ça en
upstream dans le kernel, c'est pour bientôt" je ne sais pas si
ça a fini par évoluer." J'crois que faut utiliser "Devuan" un
un truc comme ça enfin encore une énième bidouille. J'ai lâche
l'affaire, bref j'ai bien perdu mon temps avec OpenVZ. Ca va
que c'était pour un usage perso, mais j'imagine si j'avais
monté un business articulé entièrement autour de cette solution
bonjour le merdier …
Alors je pense que si tu avais monter un business, soit tu l'aurais fait sur la version communautaire, et dans ce cas, tout le monde t'aurais dit "ne pas prendre des trucs non mergés upstream". Soit tu aurais payé auprés de la boite derrière openvz, et le support est la pour toi.
Pour Iptable, clairement ça me semble à la ramasse, j'ai pas
envie de préciser ceux qui ont touchés les deux savent de quoi
je parle.
Y a pas 3 firewalls sur FreeBSD ?
Parce que bon, tu parles de coherence, mais si j'ai le choix entre pf (ou un fork différent d'openbsd), ipfw, et ipf, ça fait un peu tache dans la partie "cohérence".
De surcroit, aucun n'est extensible comme le serait netfilter (ou du moins, pf n'avais pas l'air à l'époque ou c’était mon taf de faire du firewall, mais peut être que c'est le cas maintenant)
Mais qui à la maison ou sur son Kimsufi ou chez soit a besoin
d'implétementer HAST/CARP ?!
J'veux dire remplacer des AIX par des RedHat pour faire tourner
des batchs, c'est un peu de la blague quand même ?!
Visiblement non. À un moment, faut se dire 2 choses. Soit tu as une idée de génie et le reste du monde ne sait pas ce qu'il fait. Soit tu as pas toutes les infos, et c'est pas une idée de génie.
La, tu as pas l'air d'avoir des idées de génie.
Si y a un truc que j'adore au taf c'est te connecter sur une
machine tomber sur une vieille merde du genre RH 5.4, alors que
y a 2 minutes t'étais quand même une 6.5 récente (rire), et pif
ya plus rien qu'est pareil rien n'est ISO, un vrai merdier.
Comment veux-tu gérer un parc ISO ? Moi j'appelle pas ça être
carré.
Ma foi, va demander à tes admins la raison de pas avoir fait la mise à jour. Je sais que c'est pas une question de cout, c'est le même prix dans un cas et dans l'autre. C'est peut être une question de temps, mais RHEL 7 est deja sorti y a longtemps, donc c'est pas vraiment "en regarde et on mets à jour plus tard".
Il est fort probable que la raison soit sans doute plus complexe que tu crois, et que FreeBSD ne change rien à ça.
Et je me suis dit "ça a l'air cool comme présentation, mais est ce que par hasard, je l'aurais pas déjà vu ?". Et oui, la présentation a déjà été donné à Defcon 25:
Le whitelist/blacklist oui mais le reste IPtables fait très bien…
Et pas besoin de troller avec fail2ban qui ne répond pas du tout
au même besoin. Si pour toi, bloquer en fonction du nombre de
tentatives de connexion c'est une bonne idée, alors franchement,
je sais pas où tu bosses…
Netfilter/iptable a le support d'ipset, ce qui est grosso modo suffisant pour faire des blacklists/whitelists.
Et iptables/netfilter fait en effet aussi le matching par paquet vu par seconde, etc.
Tu veux dire "sont leaders" quand on retire les boites qui font de l'open source depuis le début ? (Suse, Canonical, Red hat pour les distributions, mais aussi du Dalibo, Objectif libre, Logilab pour citer des français plus petits) ?
Parce que bon, c'est bien joli de citer les 20% de Google, mais au final, la grosse partie du code produit est proprio et le resteras.
[^] # Re: Excellent point, à nuancer
Posté par Misc (site web personnel) . En réponse au journal Linux « for desktop », débutants, détails et fausses bonnes idées. Évalué à 3.
Nan, mais y a pas que le non initié qui va trouver l'impact bizarre :)
Pour régler ce souci, flatpak (et ostree, tel qu'utilisé par Fedora Atomic Workstation) sépare la mise à jour de son application. En utilisant des containers et des images, tu peux faire la mise à jour sans que ça impacte et sans doute un jour par défaut.
Le soft ne va utiliser la mise à jour que lors du prochain lancement, ce qui réduit certains effets pourris.
Et la question des mises à jour trop fréquente, c'est un souci qui n'arrive pas partout. J'utilise une RHEL 7 sur mon pc portable, et j'apprécie de ne pas avoir des mises à jours sans arrêt. Par contre, sur Fedora, je me souviens de discussion il y a déjà 5 ans pour réduire la fréquence des mises à jours. Ça n'a pas abouti, mais la demande est assez courante.
[^] # Re: Finalement adoptée
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 2.
Et ensuite rale sur le fait que les trucs sont instables et non corrigés :/
[^] # Re: juste une arnaque
Posté par Misc (site web personnel) . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 2.
Donc, entre temps, j'ai cru lire que "non", c'est pas illégal. Ceci dit, ce n'est pas la première fois que ça arrive:
https://www.darkreading.com/vulnerabilities---threats/medsec-muddy-waters-and-the-future-of-iot-security-/d/d-id/1326806
Il y a 2 ans, il y a eu le même genre de choses pour des pacemakers.
[^] # Re: juste une arnaque
Posté par Misc (site web personnel) . En réponse au journal [~Signet] Failles de sécurité dans les CPU : AMD revient dans la course !. Évalué à 2.
J'aurais à priori tendance à dire que c'est sans doute illégal vis à vis de la SEC. Ça le serait si c'était des employés AMD (insider trading), mais la, vu que c'est des externes, je suis moins sur.
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par Misc (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 6.
Alors, je pense que le noeud du problème est la. Si tu va sur bugzilla, c'est pour contribuer et ça requiert un minimum de connaissance technique hélas pour ça. Par pour du support.
Ce que tu sembles vouloir, c'est du support comme tu demanderais à ta banque ou ailleurs, ce qui est différent. Et je sais pas si tu as lu la GPL ou les licences du même genre, mais c'est marqué que c'est globalement pas inclus, partout.
Par la, je veux pas dire que "fallait lire avant d'accepter". Je veux dire que l'idée qu'aider les gens est optionnel et n'est pas un but fait parti des principes fondateurs du logiciel libre, à tort ou à raison.
Et ça se voit partout dans ce qui est mis en place.
Tu donnes l'exemple du support sur irc. C'est globalement mauvais et le niveau 0 de support, loin des bonnes pratiques du métier.
Pas de concept de shift (genre, tu sais pas si il y a une personne qui va te répondre).
Pas de suivi des gens ou des problémes (genre, si tu reviens le lendemain, les gens vont ou ne vont pas avoir de contexte).
Pas de process sur qui fait quoi et comment. C'est courant d'avoir 3/4 personnes qui vont aider 1 personne d'un coup, ce qui serait risible si c'était au téléphone. Y a globalement pas de formation ou de bonnes pratiques, c'est directement les gens qui savent et basta.
Et je parle même pas du média en lui même, qui est pas non plus super intuitif. Tu t'en sort quand tu es techie, bien sur.
Quand je raconte ça, les gens en général me disent "oui, mais ç'est pas du support professionnel, c'est des volontaires". Je dirais que oui, mais c'est pas une raison. Si tu prends une association du style Artisan du monde, les gens ont des shifts pour tenir la caisse dans les boutiques. Si tu prends des développeurs, ils vont utiliser les mêmes outils dans le libre et dans une startup.
Mais pas pour le support, qui ressemble plus au café du commerce qu'autre chose en général. Parce que le support, c'est dévalué, c'est éprouvant. Mais aussi parce que le support, c'est ce que les gens vont payer dans certains business modèles autour du logiciel libre.
Donc oui, le support est pas terrible. Et franchement, je pense pas que ça change dans le futur. Framasoft a un formulaire de contact, c'est sans doute un peu mieux, mais pas de beaucoup. C'est aussi des gens payés pour ça. Des gens ont tentés stackoverflow ou askbot. C'est un peu mieux, mais ça donne pas forcément des trucs de qualités. Et visiblement, les gens ne conseillent pas ça (la preuve, tu as pas mentionné ça). Je sais que Tails a fait des trucs à ce niveau aussi, mais j'ai oublié quoi. Mais tails fait plein de trucs bien.
Sans un changement des mentalités au niveau du libre entier, non, je vois pas le support changer.
[^] # Re: Et sur le fond?
Posté par Misc (site web personnel) . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 2.
Non, mais je parle du matériel pour refaire une fausse empreinte digital en pratique (ou d'une fausse iris).
Parce que bien sur, un adversaire avec suffisament de pognon pourrait sans doute rentrer chez moi, et utiliser ça pour deverouiller mon appareil. mais ça requiert des préparations, une proximité physique, et sans doute du matos cher.
Et si on parle d'un état, y a des chances que l'état est justement déjà une photos des empreintes. Mais quid justement d'un adversaire avec moins de ressources (exemple, un collégue malicieux, un stalker, un ex petit ami tourné sur la technique), quel investissement est requis ?
[^] # Re: Et sur le fond?
Posté par Misc (site web personnel) . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 2.
Mais ça n'est pas gênant que si on arrive à recréer un truc équivalent à ton empreinte et/ou ton oeil à partir de ces informations ?
J'avais cru comprendre que justement, c'est une approximation de ton doigt qui est pris et qu'on regarde le positionnement des différents sillons, etc. Même si on arrive à refaire des empreintes sans trop de matos (cf demo du CCC y a longtemps) avec par exemple un verre, je suis pas sur qu'il existe de quoi refaire une empreinte sur la base des infos stockés dans une base (ça ou la même chose pour l'iris).
[^] # Re: Et les « gestures » ?
Posté par Misc (site web personnel) . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 4.
Je me demande aussi si il n'y a pas des problématiques d’accessibilité. L'informatique soit fait par et pour les gens en bonne santé en général, mais je me demande à quel point le fait de faire certains gestes peut être chiant pour certains.
[^] # Re: Disons que ça se développe mais ce n’est pas nouveau…
Posté par Misc (site web personnel) . En réponse au journal Minage en douce. Évalué à 4.
Le souci, c'est aussi d'avoir une monnaie connecté au reste du monde.
Sinon, bitcoin en tant que monnaie qui s'echange que avec elle même, ça me parait globalement stable. C'est quand tu mets une valeur en monnaie traditionnelle que ça part en vrille, surtout parce que c'est non centralisé (et non régulé):
https://davidgerard.co.uk/blockchain/2017/12/17/why-you-cant-cash-out-pt-1-why-bitcoins-price-is-largely-fictional/
[^] # Re: Pourquoi pas? (mais pas en douce!)
Posté par Misc (site web personnel) . En réponse au journal Minage en douce. Évalué à 3.
Ce qui est fait sur https://0x00sec.org/
Ensuite, je sais que l'IDS du taf bloque un protocole lié à Bitcoin, pour éviter que quelqu'un installe une ferme de minage en douce dans les bureaux (et sans doute aussi pour voir les bécanes infectés), donc ce genre de méthode va sans doute à un moment poser souci.
[^] # Re: Disons que ça se développe mais ce n’est pas nouveau…
Posté par Misc (site web personnel) . En réponse au journal Minage en douce. Évalué à 10.
Pourtant, il y a un paquet de souci avec le concept de blockchain publique, ce qui grosso modo est un prérequis à l'idée de monnaie distribué:
https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428
Je suis d'accord que le concept de blockchain est utile pour plein de choses, mais le lien liste quand même un paquet de souci à régler avant que ça soit utile à grand échelle. Et ça, c'est sans même attaquer les problèmes classiques d'un logiciel, comme l'UX, les mises à jour, etc, qui sont autant de choses à régler pour une monnai basé sur un livre de compte distribué.
Pour preuve, des liens que j'ai vu passer y a moins de 2 semaines:
https://codesuppository.blogspot.fr/2017/12/iota-tangled-mess.html?m=1
https://twitter.com/TedOnPrivacy/status/940588631709896704
Et c'est des expériences corroboré par les histoires d'un collègue qui a tenté d'acheter et de vendre du bitcoin.
Un autre lien aussi assez révélateur sur l'état de l'ecosystème:
https://magoo.github.io/Blockchain-Graveyard/ 47 incidents
Tu peux rajouter une autre liste (qui fait doublon, mais avec 3 autres soucis pas dans la première):
https://storeofvalue.github.io/posts/cryptocurrency-hacks-so-far-august-24th/
On arrive quand même à ~ 50 hacks principalement sur les 3/4 dernières années. Ça fait plus que 1 par mois.
Donc l'idée est sans doute séduisante, mais ça scale pas, c'est rempli d'escrocs et c'est mal foutu.
Et faut pas oublier que Bitcoin a 8 ans. C'est aussi vieux que golang, ou à peine plus jeune qu'Android sorti 1 an avant. Je veux bien que ça mette du temps à avancer, mais j'aurais tendance à croire qu'en 8 ans, on aurait pu prévoir ou voir les soucis existants quand même.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.
En effet, si c'est le cas, ma réponse serait différente.
A savoir qu'il y a toujours pas de changement de casse dans les commandes. La commande systemctl est en minuscule. Si je m'en tiens à l'exemple, le reproche est sur l'argument, mais dans ce cas, c'est cohérent parce que l'argument est un bout de configuration, une option dans les fichiers .services et autres.
C'est la propriété "CPUQuota" qui est changé. Et la, je pense que personne ne va dire "on a jamais eu de CamelCase dans la configuration d'un soft", parce que c'est faux. L'exemple le plus parlant serait Apache, mais je peux citer aussi OpenSSH comme logiciel présent dans le systéme de base de tout les BSD.
Les commandes utilisent aussi la casse pour avoir plus d'options (entre -C et -c pour tar), c'est donc pas non plus rare.
Alors oui, du coup, l'usage du CamelCAse déborde vers la CLI, et je comprends que ça puisse déranger les gens, sans doute parce que comme tout compromis fait, quelqu'un ne va pas être 100% satisfait.
Il y a sans doute des gens qui préfèrent tout en minuscule parce que c'est plus facile à retenir, et d'autres qui préfèrent en CamelCase parce que c'est plus facile à lire. Mais tu peux difficilement satisfaire tout le monde (sauf à supporter tout, mais d'un coup, tu va avoir de l'inconsistence dans la doc ).
De la même façon que tu ne peux pas avoir un truc rapide à taper comme "cp" et en même temps avoir un truc clire comme "copy".
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.
Sur NetBSD et FreeBSD, c'est via des headers proches de la LSB (donc provides, requires) dans les scripts d'init.
Sur OpenBSD, ça n'a pas l'air de le faire, mais j'ai regardé en détail (j'ai juste fait du ssh et des rapides coups d'oeils à des scripts au pif).
Sur OpenBSD, via une fonction dans le script d'init (exemple, le script de démarrage de nfsd avec la fonction rc_pre() ).
Sur FreeBSD et NetBSD, tu déclares une variable start_precmd qui pointe vers une fonction , comme pour OpenBSD.
Au final, la différences est de savoir si tu exposes un langage de programmation complet, avec tout ce que ça entraine comme bons et mauvais cotés, ou pas. J'ai tendance à favoriser 'approche configuration plutôt que l'approche programmation, vu que tu arrives assez vite à rajouter de la complexité, et à avoir du code dupliqué partout. Mais je comprends aussi que des gens préfèrent l'autre approche.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.
On a pas du lire la même page de man.
set-property NAME ASSIGNMENT...
Set the specified unit properties at runtime where this is
supported. This allows changing configuration parameter properties
such as resource control settings at runtime. Not all properties
may be changed at runtime, but many resource control settings
(primarily those in systemd.resource-control(5)) may. The changes
are applied instantly, and stored on disk for future boots, unless
--runtime is passed, in which case the settings only apply until
the next reboot. The syntax of the property assignment follows
closely the syntax of assignments in unit files.
C'est la page de man de systemctl sur une RHEL 7. On peut pas dire que ça soit la dernière version ou quelqu'un aurait vite fait corriger la doc pour te contredire, c'est une version 219, qui date quand même d'il y a un ou deux ans. Et parce que je part pas du principe que tu mens, j'ai aussi vérifié sur une Fedora, et la page de man dit grosso modo la même chose.
Encore une fois, je veux bien reconnaitre qu'il y a beaucoup à lire, parce que il y a beaucoup de features, mais dire "la page de man ne m'a pas aidé" me semble être un raccourci qui n'a pas l'air de resister à un examen rapide de la dite page de man, sauf si tu as eu une page de man différente.
Foutaises.
La migration de ifconfig vers ip a commencé y a plus de 10 ans.
L'interface de firewall sous Linux a changé 3 fois avant d'arriver à iptables/netfilter et va encore changer avec nftables.
Solaris a eu des changements de systémes d'init et des tas de commandes nouvelles avec Solaris 10 (sauf erreur de ma part).
Apt-get est devenu Apt sur debian (ou Aptitude pendant un temps, bien que les 2 vont sans doute cohabiter pendant longtemps). Yum est devenu DNF.
Et même au niveau du noyau, quand j'ai commencé, c'est sur /dev/hda1 que j'avais mon bootloader lilo, avec un /dev statique remplacé par devfs assez rapidement.
Ou sur FreeBSD, le fait d'avoir intégré zfs a forcément entrainé des changements de commandes pour gérer les partitions.
C'est bien la preuve que c'est rien de personnel que de répondre sur le point précis sans se préoccuper du reste.
[^] # Re: Monopole ?
Posté par Misc (site web personnel) . En réponse au journal la neutralité du net bronsonisée. Évalué à 3.
Ce qui est surtout amusant, c'est qu'au final, il n'y avait pas eu de régulation pendant trés longtemps, sauf depuis décembre 2015. Autant dire que 2 ans, ça a pas du changer des masses.
Bien que la façon dont ça a été fait est scandaleuse, et tout un tas de choses autour, les discussions autour des conséquences ont quand même jamais trop pointés ce qui est arrivé avant, quand ça n'était pas un souci, et je trouve que ça manque.
Non pas que je fasse confiance à Comcast et consort pour pas faire de la merde, mais j'ai quand même aussi du mal avec les hyperboles réthoriques (surtout que les gens n'ont pas de problème à tous aller chez le même fournisseur de mail, et ou on s’aperçoit que les gens sont parfaitement ok avec un monopole tant qu'il fait bien son boulot, mais vont évoqués des grands principes quand c'est plus le cas)
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 2.
Autant pour moi, c'était pas dans la page de man de rctl sur le freebsd 10 que j'ai regardé.
L'idée principal, c'est si tu veux pas que tes backups fassent des I/O qui pourrait ralentir ton site web, ce genre de choses. J'aurais en effet tendance à dire que si tu es à ce niveau de détails, tu as sans doute plus besoin de racheter une machine ou des disques plus rapides, mais ça ne parait pas inutile.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 5.
Comme tout le reste, tu lit la doc, elle est la pour ça.
Les devs passent leur temps à chercher des trucs sur Google, les sysadmins aussi. Croire que ça n'arrive pas, ou que ça n'est pas la norme, c'est malsain.
Malsain parce que c'est faire croire que les ingés ont des capacités mémoriels au dela du raisonnable, et faire douter les gens qui ont des capacités normales en se disant "j'arrive pa sà retenir, je suis pas normal", ou pour les plus égocentriques "j'arrive pas à retenir, le soft doit être de la merde".
Je dit pas qu'on doit pas faire un effort pour la cohérence, mais non, on peut pas tout retenir, et c'est normal, et c'est pas requis. Savoir que tu peux limiter le cpu devrait suffire.
En l'occurrence, je pense que tu te trompes.La page de man parle de "pcpu":
pcpu %CPU, in percents of a single CPU core
[^] # Re: Oui et non
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.
Deja, en mettant en place un process pour ça. Je sais bien que c'est plus facile à dire qu'à faire, mais si je prends l'exemple d'une distribution comme Fedora, il y a un systéme en 2 temps. D'abord le paquet va dans updates-testing, puis dans update quand suffisament de gens ont validés le paquet. Installer un paquet depuis la version updates-testing, c'est un switch à donner. Revenir en arriére est aussi simple.
Tu as une incitation à vérifier les paquets (bien que faible), et je pense que le processus pourrait aller plus loin, en laissant les gens s'inscrire comme testeur officiel d'un paquet, et donc en ayant des notifications pour le paquet en ayant directement les versions de tests, etc.
Ou encore, aller vers plus d'automatisation. Avoir un truc qui automatiquement déploie le paquet (style piuparts), avoir un outil qui lance des tests basiques (exemple, un playbook ansible qui install un serveur httpd de base et qui le lance, verifie que ça écoute sur le port 80).
FreeBSD, y a pas tout ça que je sache. Du coup, oui, structurellement, le test est difficile si on suppose que ça va tomber sur une et une seule personne, à savoir le committer.
Et pourtant, la communauté FreeBSD est composé de gens avec des compétences, mais il n'y a pas l'air d'avoir d'efforts pour les utiliser.
Ensuite et encore une fois, je ne dit pas que c'est facile. Les ports étant distribués via svn (sauf erreur de ma part), et avoir une branche par version de test ne me parait pas terrible. Le tooling autour bouge bien, mais l'infrastructure est pas maintenu de maniére ouverte, sans doute plus pour des raisons de ressources et d'historique que pour autre choses. Du coup, oui, faire changer les choses va prendre du temps.
Mais c'est faisable, et dire "Debian a du monde, et pas FreeBSD", c'est à mon avis confondre cause et conséquence. Debian a des gens qui testent parce c'est faisable (faciliter de mise à jour vers testing, incitation social à le faire, etc). Fedora a du monde qui teste pour les mes raisons avec des mécanismes différents. FreeBSD n'a pas l'air d'avoir ça, donc ça n'arrive pas.
Ensuite, je peux me tromper, peut etre que c'est autre chose.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.
C'est pas non plus strictement équivalent, vu que system (et Linux) est aussi capable de limiter les I/Os, ce qui ne semble pas être le cas sur FreeBSD (en tout cas, pas sur FreeBSD 10 d'après la doc).
Je reconnait que FreeBSD a des trucs en plus, mais à choisir entre le fait de limiter le nombre de PTY et limiter le disque, j'ai quand même le sentiment que le partage du disque va plus souvent me servir.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 6.
Ceci dit, il y a suffisament de changement pour que l'automatisation puisse devenir un truc relou à maintenir. Par exemple, j'ai fait beaucoup d'automatisation via Ansible, et l'intégration avec l'OS a son importance (genre la gestion du firewall, du reaseau, etc, qui change de version majeur de RHEL en version majeur de RHEL).
Oui, pour reprendre encore une fois Ansible, j'ai du rajouter une paire de trucs pour NetBSD (support de la detection de pkgin, divers facts, etc), justement parce que la communauté semble moins active. J'ai toujours pas trouvé de méthode propre pour l'installation automatique de VM FreeBSD via virt-install, et j'ai pas d'image officiel pour usage dans un cloud openstack (Rackspace dans mon cas) pour NetBSD.
C'est ça aussi l'écosystéme et son intégration.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 8.
En l'occurrence, c'est OpenVZ qui a fait le choix d'être en dehors du kernel.
Alors je pense que si tu avais monter un business, soit tu l'aurais fait sur la version communautaire, et dans ce cas, tout le monde t'aurais dit "ne pas prendre des trucs non mergés upstream". Soit tu aurais payé auprés de la boite derrière openvz, et le support est la pour toi.
Y a pas 3 firewalls sur FreeBSD ?
Parce que bon, tu parles de coherence, mais si j'ai le choix entre pf (ou un fork différent d'openbsd), ipfw, et ipf, ça fait un peu tache dans la partie "cohérence".
De surcroit, aucun n'est extensible comme le serait netfilter (ou du moins, pf n'avais pas l'air à l'époque ou c’était mon taf de faire du firewall, mais peut être que c'est le cas maintenant)
CARP est implementé dans FreeBSD 10:
https://www.freebsd.org/doc/handbook/carp.html
Je suis d'accord, c'est pour ça que j'utilise un outil de gestion de config qui fait une abstraction sur tout ça.
En prenant une distribution d'entreprise, tu as la doc. Vu que tu dit que Debian et RHEL, c'est kifkif, je vais donc comparé avec RHEL et surprise, tu as une tonne de doc traduite et vérifié sur
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
Visiblement non. À un moment, faut se dire 2 choses. Soit tu as une idée de génie et le reste du monde ne sait pas ce qu'il fait. Soit tu as pas toutes les infos, et c'est pas une idée de génie.
La, tu as pas l'air d'avoir des idées de génie.
Ma foi, va demander à tes admins la raison de pas avoir fait la mise à jour. Je sais que c'est pas une question de cout, c'est le même prix dans un cas et dans l'autre. C'est peut être une question de temps, mais RHEL 7 est deja sorti y a longtemps, donc c'est pas vraiment "en regarde et on mets à jour plus tard".
Il est fort probable que la raison soit sans doute plus complexe que tu crois, et que FreeBSD ne change rien à ça.
# En prévision de Vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.
En voyant le programme du 34C3, j'ai vu https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8968.html
Et je me suis dit "ça a l'air cool comme présentation, mais est ce que par hasard, je l'aurais pas déjà vu ?". Et oui, la présentation a déjà été donné à Defcon 25:
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
Du coup, je laisse les gens tirer les conclusions, c'est sur les slides (teaser: 115 bugs de sécu en 90 jours)
[^] # Re: Ah les BSDistes
Posté par Misc (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.
Netfilter/iptable a le support d'ipset, ce qui est grosso modo suffisant pour faire des blacklists/whitelists.
Et iptables/netfilter fait en effet aussi le matching par paquet vu par seconde, etc.
[^] # Re: Jeton à l'avance
Posté par Misc (site web personnel) . En réponse au journal Le LUKS, version 2. Évalué à 6.
Oui, genre tang/clevis, comme expliqué sur https://blog.delouw.ch/2017/10/01/leveraging-network-bound-disk-encryption-at-enterprise-scale/
Tang est dispo dans Centos 7.4 et Fedora, mais j’espère que ça va vite être adopté par les autres distributions Linux.
[^] # Re: Et les poles open-source de ces entreprises ?
Posté par Misc (site web personnel) . En réponse au sondage Travailler pour les GAFAM. Évalué à 3.
Tu veux dire "sont leaders" quand on retire les boites qui font de l'open source depuis le début ? (Suse, Canonical, Red hat pour les distributions, mais aussi du Dalibo, Objectif libre, Logilab pour citer des français plus petits) ?
Parce que bon, c'est bien joli de citer les 20% de Google, mais au final, la grosse partie du code produit est proprio et le resteras.