et cfengine? Je pose la question en toute innocence, mais je crois que c'est l'ancêtre, son but étant d'arriver a un état stable en tout temps? pas réussi à l'utiliser, mais pas eu le temps d'étudier non plus…
Pour partager du code le mieux ça reste de faire de la composition
C'est difficile de tout expliquer dans des commentaires ici et là. ;-)
A l'essentiel: Guix compose. :-)
On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
Même les devs de systemd ont supporté le fait d'avoir des shells scripts, pour dire! (et pourtant, j'aime pas systemd).
Cette histoire d'inherit est un artefact dans la grande histoire de Guix. :-)
J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.
Désolé, tu viens de contre-vendre le projet.
Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
Ce format "binaire", est tellement simple, que c'est tout sauf stupide, et certainement pas du conservatisme (oui, je crache sur KISS ici).
Je plussoie l'ensemble, mais j'ai tout de même une précision à apporter: il est tout à fait possible (et facile) de transformer un serveur MPD en diffuseur de son.
Concrètement, tu choisis ta source de sortie: elle peut être alsa (le module son du noyau), jackd (un daemon de gestion du son qui semble très aimé par les audiophiles), http, et bien d'autres.
Cela implique qu'il est possible d'utiliser n'importe quel lecteur ailleurs dans la maison (dont mpd, mais pas que) sur des machines dont le seul rôle serait d'émettre vers une sortie audio (casque, enceinte filaire ou bluetooth, etc), et du coup il est possible de centraliser le stockage des playlists (radio internet) et la sonothèque sur une seule machine sans forcément configurer un partage de fichiers.
Pour info, sur la conf de debian il semble que les sorties suivantes existent (via grep audio_output /etc/mpd.conf -A3 | grep '\<type' | sed 's![^"]*\(.*\)!* \1!g'):
J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf… tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)… eux, c'est juste des frontaux.
Concernant les services, c'est presque la même histoire que pour les paquets. ;-)
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.
J'ai peut-être mal compris ce qu'était un méta-paquet.
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
Merci de vos réponses, c'est un peu ce que je craignais pour «Fn». J'aurai préféré modifier son comportement puisque c'est honnêtement cette touche la qui fout le plus le bordel au final… bon, ben vais me rabattre sur «menu», je m'en servais à une époque, mais depuis que j'ai adopté le tiling et le terminal en masse, j'ai quasi oublié son existence.
En terme de gestion de paquets, le paradigme de Guix vient avec :
coexistence de différents outils incompatibles entre eux : profile et environment
générations / transactions : roll-back
configuration déclarative : fichier manifest
voyage dans le temps : time-machine
Autant les 3 premiers points peuvent être obtenus avec des gestionnaires de paquets "classiques" modulo un peu de d'habitude quand même, autant le voyage dans le temps est impossible—à ma connaissance.
Marrant, moi j'aurais dis que c'est le roll-back qui est chiant avec Debian. Le repro-build, c'est en cours pour Debian, et de ce que j'en sais (pas grand chose, outre mes compétences de développeur non-debian) je dirais que la cause est plutôt les recettes de compilations, notamment celles à base de CMake.
Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
Est-ce vraiment pertinent de prendre en compte le réseau? Pour moi, l'impact du gestionnaire de paquets, c'est sur l'overhead du calcul des dépendances et de l'install proprement dite qu'il faut le faire, pas sur le DL.
Toute la question est la définition de même version. Comme je demandais, est-ce que, considérant toutes les autres options exactement les mêmes,libfoo-1.2.3 compilée avec GCC 7 est-elle la même version que celle compilée avec GCC 8 ?
J'avais regardé un peu comment marchent ces 2 systèmes de paquet (guix/nix). En gros, les versions des paquets sont en fait un hash, pas la version réelle.
Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-)
À ce stade la, on est loin des guillemets…
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql… long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
Ça à l'air pas mal, mais il y a un point que j'aurai aimé qu'il précise: la température. Certains PC portables ont la bonne idée de tirer ou expulser l'air du dessous de la machine, ce qui les rends délicats a utiliser en «mode portable». D'autres encore en arrivent à avoir des surfaces clavier/touchpad brûlantes.
Du coup j'avoue être un peu déçu que ce point n'apparaisse nulle part.
Bon, c'est exactement la remarque que je craignais : Gopher est un protocole pas une application !
Je pensais avoir fait comprendre que le je comprenais… mais dans la pratique, il y a quoi qui permettre une navigation confortable, en mode graphique?
Mes explications ont-elles été suffisantes ou bien dois-je développer certains points ?
Citer un navigateur gopher moderne serait un excellent point :)
Tu pourrais aussi y ajouter un serveur, parce que si quelqu'un est convaincu par le navigateur, il serait dommage qu'il ne trouve que des serveurs obsolètes.
Honnêtement, je considère que le web actuel est flingué. Je ne sais utiliser que le web et des mailings lists que je trouve sur des sites webs, mais j'aimerais une alternative, un truc qui ne soit pas rebutant (le ncurses, je m'en sers en permanence, mais par choix, pour des applications dont je connais une alternative graphique).
Si vraiment tu veux pousser, commence une dépêche, colles-y des liens, j'essaierais d'aider.
Opera 12 clamait le permettre site par site. Je l'utilisais, et le faisais.
De nos jours, le seul autre navigateur le permettant, sans modules complémentaires, c'est otter. Qui ne s'intègre pas dans debian.
Donc, actuellement non, parce que ne peux plus le faire avec un navigateur qui fonctionne sous Debian stable sans faire confiance a un plugin.
D'autant que je suis devenu de moins en moins confiant sur le fait que de larges organisations de développeurs aient la moindre considérations envers un web respectueux de la vié privée, léger, rapide même avec moins de 200Kio/s pour le brouteur, etc etc.
Je garde malgré tout un oeil et une pensée sur otter-browser (je peux en lire le code, mon cerveau segfault pas), ou les navigateurs proprio qui au moins filent des options utilisables (hint: pas chrome ni safari ni edge à ma connaissance).
Ma réponse étant expéditive, je comprends qu'il y ait eu confusion.
J'ai maintenant tendance a prendre mon temps avant de répondre sur dlfp, que mes frustrations éventuelles liées à la combo boulot + écrit avec des inconnus + mauvaise compréhension s'évacue.
Donc, merci pour ta réponse, et désolé pour le laps.
Je pense que tu n'as pas trouvé ce que tu recherchais car le projet n'a pas encore atteint cette étape (et produit la documentation associée) !
Du coup, je peux toujours dire que, a l'heure actuelle, y'a pas d'alternative. On ne peux juger que les faits, pas les espoirs.
Concernant le choix de rust, il est complètement justifié du côté de Mozilla,
Attention, je considère, comme pas mal de monde, que Rust a de l'avenir.
Je me garde juste de le considérer comme une panacée, il a une sévère concurrence, et si C++ à fait des choix douteux, c'est justement pour partir sur le pied de l'évolution, contre la révolution. Améliorer l'existant, pas jeter aux orties le passé.
À ma connaissance, c'est le seul langage qui l'ai fait, aucun autre n'étant réellement compatible avec le seul langage qui, de fait, est utilisable binairement par tous les autres: le C. Pas besoin de réécrire les headers C en C++, et c'est la sa grande force que tout le monde oublie. Oui, ça implique de supporter les cast du C, et pleins d'autres choses, mais bon…
Enfin pour le débat C/C++/Java/Rust, je ne suis pas développeur, mais dans mon secteur on trouve plus de gens qui connaissent Python ou Go que C ;)
Ce débat est stérile.
Les pseudo dev C++ dirons que java est lent (mais il tournais sur de l'embarqué y'a 20 ans, rappelez-vous…), les dev C disent que C++ est bloaté, les dev pythons disent que les autres langages sont durs à utiliser… toutes ces affirmations sont à la fois vraies et fausses.
Je suis dev de métier, issu d'une "culture" auto-didacte. Je gère aussi le déploiement et les systèmes embarqués de ma boîte, je considère les méthodes agiles comme étant plus un ramassis de buzzwords (ah, on dirait que j'ai pas assez fait abstractions des «nouveautés» du boulot…).
Le language impacte les perfs, bien sûr. Il impacte aussi la facilité de maintenance d'un projet (trop de langages dans un seul projet => plus de complexité a maintenir).
Dans le cas d'un projet open-source, ça impacte aussi le nombre de contributeurs potentiels: OpenMW était à l'origine écrit en D, ils sont passés au C++ notamment pour cette raison, et maintenant le moteur est proche de la V1 (bon, je pense que le type qui s'est attelé à la gestion "pure" du projet a aussi vachement aidé ce fait, il semble être un meneur d'hommes comme il y en a peu).
Perso, la seule chose que je respecte chez les collègues, c'est quand ils prouvent ce qu'ils disent, ou font preuve d'humilité.
Je passe probablement pour un extra-terrestre, mais malgré mon comportement d'ours un peu mal léché, les gens ont tendance à dire m'apprécier comme collègue, et soit je suis sûr de ce que je dis (et si on me démontre le contraire, je m'excuse en public) soit j'émets une hypothèse, et entre les deux, le ton diffère.
Ce que j'aime avec ce site, c'est que c'est un peu la même mentalité: sur un contenu technique, si tu fais pas preuve d'humilité et que tu prouves pas tes dires, ben, tu te fais moinsser. Les sujets politiques, humoristiques et technico-politiques, c'est différent, mais bon, le sentimental y rentre en compte, et y'a toujours moyen d'y apprendre pleins de trucs.
Comme je l'ai dis, je cherche, et j'ai 2 pistes, mais bon, elles viennent d'un site qui m'est inconnu.
D'une part, protonmail, le nom ne m'est pas inconnu, la totalité du site (en tout cas la page d'accueil) est sous httpS, selon ublock il ne semble y avoir qu'un seul domaine… c'est plutôt rassurant, même si je n'ai pas trop confiance en ma compréhension de comment sont faites les mesures.
Sur leur site, tout semble nickel, les promesses sont belles. C'est tentant.
D'autre part, j'ai zoho, totalement inconnu, mais bon, je passe pas mon temps a chercher ce genre de trucs, selon mon navigateur, 150 cookies sont bloquéés (quand même!) et ublock indique la connection a 13 domaines. Ça inspire moins, clairement.
Dans les deux cas, rien ne semble bloqué par ublock origin, mais je commence depuis quelques temps/semaines a me poser de sérieuses questions sur la configuration de cet outil, ou son intégration à vivaldi.
Je continue de chercher, le but étant d'arrêter de squatter des mails à la sécurité aléatoire, d'intégrer une signature (minimum) G(nu)PG via client lourd pas bloaté.
Histoire de pas avoir honte quand mon me demande mon @mail, in fine.
Il a été intéressant de mon point de vue de dev qui trouve l'adminsys intéressante, sans y avoir de vraies compétences (notamment, dans la partie propre, il expose les forces… enfin, ça semble surtout la force: perfs avec le cache avec plus de features) de ZFS.
Par contre, ce journaliste est mesquin, clairement à charge. Et le point auquel tu réponds, justement, est pourtant clairement répondu par Torvalds 3 jours avant la parution de l'«article». Et même pas un NB, PS, ou autre pour le préciser.
Oui, dans le mail de Mr. Torvalds, il donne son avis personnel. Oui, il est une icône.
Mais putain, sur le thread (qui est nommé, c'est important Do not blame anyone. Please give polite, constructive criticism) on constate que lui n'utilise pas de noms d'oiseaux (ou je suis pas tombé dessus) mais s'en mange: Please, **Linus, stop being arrogant and ignorant**, read this release note and tell us why you think ZFS is more of a buzzword and has no real maintenance.. Les propos de l'article sont propres sur eux, mais je trouve que le mec se base quand même vachement, justement, sur la postérité de Torvalds qui était avant moins, disons, composé. Donc, ce que reproche à Torvalds l'auteur de l'article, il l'utilise lui-même (vu le nom de l'article et son départ Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it, le reste, lis justement ton lien)!
Ah, concernant la citation, il est important de noter que quelqu'un a dis la même, plus d'une heure avant, sans les insultes. Et que l'auteur des insultes se cache derrière un pseudo, lui. Ou elle, d'ailleurs, ne soyons pas sexistes.
Bon, il faut le dire, j'ai pas trouvé de mentions claire avant de l'implémentation de ZFS critiquée. Les insultes sont donc relativement admissibles, étant antérieures au mail de Torvalds ou il explicite deux choses:
Si vous parles de ZFS, vous parlez de la version d'Oracle;
Cette version étant proprio, vous savez peut-être si c'est actif, pas moi;
Traductions à l'arrache de ceci: If you are talking about ZFS, you're talking about the Oracle version. Do you think it has a lot of development going on? I don't know.
Tout ça, ça date du 10 janvier. L'article lui date du 13.
Je vais pas tout relever, mais j'ai vraiment eu l'impression que le type est un sysadmin qui touche pas au code, se mange pas les emmerdes de compat' d'ABI vs améliorations, ou les problèmes légaux (qui sont clairement abordés par Torvalds)… non, il se contente de dire "ah, il a été raison sur 3/4 de ses points, mais le point ou il précise «Personnellement» il ose dire son opinion!".
Désolé, je trouve son comportement franchement déplacé. Et d'ailleurs, vu que c'est paru et manifestement taillé pour un média de communication, faudrait p'tet virer la poutre de son oeil avant de parler de l'écharde dans l'oeil du voisin: la ML de linux, moins de monde la lit qu'arstechnica, il a donc probablement plus de poids de désinformation que Torvalds.
Ça me semble pourtant clair… le fait de faire une recherche n'affecte que les éléments que tu parcoures, les éléments ne correspondants pas a la recherche sont toujours affichés, ce qui implique que le nombre de paquets présentés dans aptitude est multiplié par le nombre d'architectures activées, ce qui est autant de pollution gênant l'usage.
L'OP cherche une solution non pas afin de savoir quels paquets correspondent a l'architecture native de sa machine, mais afin de masquer les autres.
Implémenter du chiffrement end to end sur une solution existante est galère
Implémenter du chiffrement tout court est galère et piégeux, c'est justement le genre de trucs sur lesquels j'aurais plus tendance a avoir confiance si le soft a un minimum d'ancienneté.
D'ailleurs, quant on vois une clé privée sur github, ça fait, genre, vraiment pas envie.
l'objectif final de system-d.org est la mise en réseau des projets créés sur l'outil, ce qui n'est pas possible sur Agora qui doit être auto-hébergé
Hum… donc le souci est qu'Agora ne peut gérer qu'un seul projet? Parce que le fait que ça soit auto-hébergé, c'est aussi le cas pour vous, puisque vous l'hébergez vous-même. Il est donc, de fait, auto-hébergé au moins une fois :)
je connaissais pas Agora en commençant le projet il y a 3 ans, ni la programmation, ni linux, ni le libre, j'ai appris vite, j'ai fait plein de choix sans tout connaître.
Donc, c'est le 1er projet important, celui qui a justifié l'apprentissage de la programmation?
j'aime pas le PHP a cause des points virgules
Soit. Mais il y a une grosse base d'utilisateurs, c'est important pour avoir des contributeurs. Bon, JS aussi, certes.
Il y a aussi le fait que j'ai l'impression que les framework PHP gigotent moins que ceux du JS. Question pérennité, pour le côté serveur, j'ai du coup nettement plus confiance en PHP, Ruby ou Python qu'en ecmascript (en plus d'une allergie développée en devant intégrer de l'étron-JS fait par un collègue dans un système, ça aide pas. J'ai déjà vu des techno de merde, mais celle-ci est la seule que je sois arrivé à haïr).
le jour ou des personnes le taperons en masse sur google et encore loin d'arriver,
Bof. Autour de moi, les utilisateurs normaux comme avancés ont plus tendance a utiliser google comme un DNS au final. Les favoris? Idem, je vois très peu de monde les utiliser (il faut dire que ce n'est plus trop à l'honneur dans les interfaces des navigateurs, aussi).
Donc, oui, les gens vont taper ça sur leur moteur de recherche. Moi, avec "system d" et "system-d" sur DDG, j'ai:
site de bricolage
le même site, différente page
wikipedia pour systemd le daemon
une vidéo youtube qui parle d'un journal de bricolage
un facebook de bricolage
le site d'un mag de bricolage
un site de consultants en RH
la flemme, faut scroller
D'ailleurs, je suis surpris de tomber que sur des résultats francophones, pour le coup.
Avec "systemd":
site de bricolage
wikipedia pour systemd le daemon
manapge de ubuntu
page sur lealinux
doc archlinux
linuxtricks
page debian
scroll…
Perso, quand je choisis un nom pour un projet (des programmes), le 1er truc que je fais, c'est une recherche dans les paquets debian, puis sur internet sur le nom, histoire d'éviter les collisions. Sans même penser au référencement, hein.
Bon, faut noter, j'ai utilisé DDG et non google, en théorie ils ne trackent pas donc ne m'enferment pas dans une bulle, les résultats devraient donc être plus neutres que si j'avais utilisé google (encore que, je n'utilise que très peu les services google, donc bon…).
Tu dois être blasé, parce que perso, sur le peu de vidéo que j'ai regardé (j'y ai en gros passé mon samedi, le dimanche j'étais moins intéressé) et j'en ai eu plusieurs qui m'ont intéressé, dont celle que tu mentionnes.
Par exemple, j'ai trouvé intéressante celle sur les bootloaders, et la pauvre qualité de leurs codes (j'avoue avoir ri quand ils ont montré des bouts de code de uboot… m'a rappellé des souvenirs).
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
et cfengine? Je pose la question en toute innocence, mais je crois que c'est l'ancêtre, son but étant d'arriver a un état stable en tout temps? pas réussi à l'utiliser, mais pas eu le temps d'étudier non plus…
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à -1.
J'me permets, parce que c'est facile…
On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
Même les devs de systemd ont supporté le fait d'avoir des shells scripts, pour dire! (et pourtant, j'aime pas systemd).
J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
Désolé, tu viens de contre-vendre le projet.
Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
Ce format "binaire", est tellement simple, que c'est tout sauf stupide, et certainement pas du conservatisme (oui, je crache sur KISS ici).
[^] # Re: PS: je ne suis pas audiophile
Posté par freem . En réponse au message Solution pour un serveur son à la maison. Évalué à 4.
Je plussoie l'ensemble, mais j'ai tout de même une précision à apporter: il est tout à fait possible (et facile) de transformer un serveur MPD en diffuseur de son.
Concrètement, tu choisis ta source de sortie: elle peut être alsa (le module son du noyau), jackd (un daemon de gestion du son qui semble très aimé par les audiophiles), http, et bien d'autres.
Cela implique qu'il est possible d'utiliser n'importe quel lecteur ailleurs dans la maison (dont mpd, mais pas que) sur des machines dont le seul rôle serait d'émettre vers une sortie audio (casque, enceinte filaire ou bluetooth, etc), et du coup il est possible de centraliser le stockage des playlists (radio internet) et la sonothèque sur une seule machine sans forcément configurer un partage de fichiers.
Pour info, sur la conf de debian il semble que les sorties suivantes existent (via
grep audio_output /etc/mpd.conf -A3 | grep '\<type' | sed 's![^"]*\(.*\)!* \1!g'):[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.
Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf… tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)… eux, c'est juste des frontaux.
Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
Je reconnaît que ce point était hors sujet pour le coup :)
Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier: flock() places advisory locks only; given suitable permissions on a file, a process is free to ignore the use of flock() and perform I/O on the file. me font me demander d'à quel point nix/guix peuvent réellement garantir quoique ce soit.
[^] # Re: ça dépend de la touche
Posté par freem . En réponse au message modifier le comportement de la touche «fn» ou «context». Évalué à 2.
Merci de vos réponses, c'est un peu ce que je craignais pour «Fn». J'aurai préféré modifier son comportement puisque c'est honnêtement cette touche la qui fout le plus le bordel au final… bon, ben vais me rabattre sur «menu», je m'en servais à une époque, mais depuis que j'ai adopté le tiling et le terminal en masse, j'ai quasi oublié son existence.
[^] # Re: Quelques "killer features"
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
Marrant, moi j'aurais dis que c'est le roll-back qui est chiant avec Debian. Le repro-build, c'est en cours pour Debian, et de ce que j'en sais (pas grand chose, outre mes compétences de développeur non-debian) je dirais que la cause est plutôt les recettes de compilations, notamment celles à base de CMake.
Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4. Dernière modification le 20 janvier 2020 à 22:53.
Est-ce vraiment pertinent de prendre en compte le réseau? Pour moi, l'impact du gestionnaire de paquets, c'est sur l'overhead du calcul des dépendances et de l'install proprement dite qu'il faut le faire, pas sur le DL.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
J'avais regardé un peu comment marchent ces 2 systèmes de paquet (guix/nix). En gros, les versions des paquets sont en fait un hash, pas la version réelle.
Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
[^] # Re: Mal connaître sa distribution
Posté par freem . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 2.
À ce stade la, on est loin des guillemets…
DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
Je sais que la compression est supportée, mais je ne sais exactement comment.
Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql… long, lourd et pénible).
À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
[^] # Re: Cool
Posté par freem . En réponse au lien Premières journées avec le Pinebook pro (un portable ARM libre à 200 $). Évalué à 2.
Ça à l'air pas mal, mais il y a un point que j'aurai aimé qu'il précise: la température. Certains PC portables ont la bonne idée de tirer ou expulser l'air du dessous de la machine, ce qui les rends délicats a utiliser en «mode portable». D'autres encore en arrivent à avoir des surfaces clavier/touchpad brûlantes.
Du coup j'avoue être un peu déçu que ce point n'apparaisse nulle part.
[^] # Re: nano
Posté par freem . En réponse au journal Broot le bien nommé. Évalué à 2.
Merci pour ce moment de bonheur.
En bonus, j'ai même appris quelques trucs en lisant…
# pas au siècle dernier...
Posté par freem . En réponse au journal KHTML c'est fini. Évalué à 8.
Tu voulais dire, au millénaire dernier?
Bon, ok, je sors.
[^] # Re: seule alternative crédible ?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 2.
Non, je dis juste que je préfère n'accorder ma confiance qu'a un nombre retreint de tiers, nuance.
Par l'usage intensifs de plugins, sans audit du code, on fait confiance a tous les fournisseurs de plugins en plus du logiciels qui les intègre.
[^] # Re: Et si on jetait le bébé avec l'eau du bain?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 3.
Je pensais avoir fait comprendre que le je comprenais… mais dans la pratique, il y a quoi qui permettre une navigation confortable, en mode graphique?
Citer un navigateur gopher moderne serait un excellent point :)
Tu pourrais aussi y ajouter un serveur, parce que si quelqu'un est convaincu par le navigateur, il serait dommage qu'il ne trouve que des serveurs obsolètes.
Honnêtement, je considère que le web actuel est flingué. Je ne sais utiliser que le web et des mailings lists que je trouve sur des sites webs, mais j'aimerais une alternative, un truc qui ne soit pas rebutant (le ncurses, je m'en sers en permanence, mais par choix, pour des applications dont je connais une alternative graphique).
Si vraiment tu veux pousser, commence une dépêche, colles-y des liens, j'essaierais d'aider.
[^] # Re: seule alternative crédible ?
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 1.
Opera 12 clamait le permettre site par site. Je l'utilisais, et le faisais.
De nos jours, le seul autre navigateur le permettant, sans modules complémentaires, c'est otter. Qui ne s'intègre pas dans debian.
Donc, actuellement non, parce que ne peux plus le faire avec un navigateur qui fonctionne sous Debian stable sans faire confiance a un plugin.
D'autant que je suis devenu de moins en moins confiant sur le fait que de larges organisations de développeurs aient la moindre considérations envers un web respectueux de la vié privée, léger, rapide même avec moins de 200Kio/s pour le brouteur, etc etc.
Je garde malgré tout un oeil et une pensée sur otter-browser (je peux en lire le code, mon cerveau segfault pas), ou les navigateurs proprio qui au moins filent des options utilisables (hint: pas chrome ni safari ni edge à ma connaissance).
[^] # Re: Un autre avis négatif sur Brave
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 4.
C'est habituel, de flooder ce média débile qu'est twitter comme ça? Je trouve ça drôle.
N'empêche, il aurait quand même pu caler un lien vers un artcile blog de brave sur le 1er lien, pour nous faciliter la lecture.
[^] # Re: La fondation mozilla partage une lourde part de responsabilité dans le fait que...
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 2.
J'en suis ravi.
Du coup, tu as des projets, même en pré-alpha, qui l'incorporent, ou c'est « juste » un objectif?
PS: c'est triste, d'être obligé de coller une espace pour mettre en gras des guillemets
[^] # Re: La fondation mozilla partage une lourde part de responsabilité dans le fait que blink
Posté par freem . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 5.
J'ai maintenant tendance a prendre mon temps avant de répondre sur dlfp, que mes frustrations éventuelles liées à la combo boulot + écrit avec des inconnus + mauvaise compréhension s'évacue.
Donc, merci pour ta réponse, et désolé pour le laps.
Du coup, je peux toujours dire que, a l'heure actuelle, y'a pas d'alternative. On ne peux juger que les faits, pas les espoirs.
Attention, je considère, comme pas mal de monde, que Rust a de l'avenir.
Je me garde juste de le considérer comme une panacée, il a une sévère concurrence, et si C++ à fait des choix douteux, c'est justement pour partir sur le pied de l'évolution, contre la révolution. Améliorer l'existant, pas jeter aux orties le passé.
À ma connaissance, c'est le seul langage qui l'ai fait, aucun autre n'étant réellement compatible avec le seul langage qui, de fait, est utilisable binairement par tous les autres: le C. Pas besoin de réécrire les headers C en C++, et c'est la sa grande force que tout le monde oublie. Oui, ça implique de supporter les cast du C, et pleins d'autres choses, mais bon…
Ce débat est stérile.
Les pseudo dev C++ dirons que java est lent (mais il tournais sur de l'embarqué y'a 20 ans, rappelez-vous…), les dev C disent que C++ est bloaté, les dev pythons disent que les autres langages sont durs à utiliser… toutes ces affirmations sont à la fois vraies et fausses.
Je suis dev de métier, issu d'une "culture" auto-didacte. Je gère aussi le déploiement et les systèmes embarqués de ma boîte, je considère les méthodes agiles comme étant plus un ramassis de buzzwords (ah, on dirait que j'ai pas assez fait abstractions des «nouveautés» du boulot…).
Le language impacte les perfs, bien sûr. Il impacte aussi la facilité de maintenance d'un projet (trop de langages dans un seul projet => plus de complexité a maintenir).
Dans le cas d'un projet open-source, ça impacte aussi le nombre de contributeurs potentiels: OpenMW était à l'origine écrit en D, ils sont passés au C++ notamment pour cette raison, et maintenant le moteur est proche de la V1 (bon, je pense que le type qui s'est attelé à la gestion "pure" du projet a aussi vachement aidé ce fait, il semble être un meneur d'hommes comme il y en a peu).
Perso, la seule chose que je respecte chez les collègues, c'est quand ils prouvent ce qu'ils disent, ou font preuve d'humilité.
Je passe probablement pour un extra-terrestre, mais malgré mon comportement d'ours un peu mal léché, les gens ont tendance à dire m'apprécier comme collègue, et soit je suis sûr de ce que je dis (et si on me démontre le contraire, je m'excuse en public) soit j'émets une hypothèse, et entre les deux, le ton diffère.
Ce que j'aime avec ce site, c'est que c'est un peu la même mentalité: sur un contenu technique, si tu fais pas preuve d'humilité et que tu prouves pas tes dires, ben, tu te fais moinsser. Les sujets politiques, humoristiques et technico-politiques, c'est différent, mais bon, le sentimental y rentre en compte, et y'a toujours moyen d'y apprendre pleins de trucs.
# 2 «pistes»
Posté par freem . En réponse au message [cherche] hébergeur mails. Évalué à 2.
Comme je l'ai dis, je cherche, et j'ai 2 pistes, mais bon, elles viennent d'un site qui m'est inconnu.
D'une part, protonmail, le nom ne m'est pas inconnu, la totalité du site (en tout cas la page d'accueil) est sous httpS, selon ublock il ne semble y avoir qu'un seul domaine… c'est plutôt rassurant, même si je n'ai pas trop confiance en ma compréhension de comment sont faites les mesures.
Sur leur site, tout semble nickel, les promesses sont belles. C'est tentant.
D'autre part, j'ai zoho, totalement inconnu, mais bon, je passe pas mon temps a chercher ce genre de trucs, selon mon navigateur, 150 cookies sont bloquéés (quand même!) et ublock indique la connection a 13 domaines. Ça inspire moins, clairement.
Dans les deux cas, rien ne semble bloqué par ublock origin, mais je commence depuis quelques temps/semaines a me poser de sérieuses questions sur la configuration de cet outil, ou son intégration à vivaldi.
Je continue de chercher, le but étant d'arrêter de squatter des mails à la sécurité aléatoire, d'intégrer une signature (minimum) G(nu)PG via client lourd pas bloaté.
Histoire de pas avoir honte quand mon me demande mon @mail, in fine.
[^] # Re: Raison
Posté par freem . En réponse au lien Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it. Évalué à 5.
Merci pour le lien.
Il a été intéressant de mon point de vue de dev qui trouve l'adminsys intéressante, sans y avoir de vraies compétences (notamment, dans la partie propre, il expose les forces… enfin, ça semble surtout la force: perfs avec le cache avec plus de features) de ZFS.
Par contre, ce journaliste est mesquin, clairement à charge. Et le point auquel tu réponds, justement, est pourtant clairement répondu par Torvalds 3 jours avant la parution de l'«article». Et même pas un NB, PS, ou autre pour le préciser.
Oui, dans le mail de Mr. Torvalds, il donne son avis personnel. Oui, il est une icône.
Mais putain, sur le thread (qui est nommé, c'est important
Do not blame anyone. Please give polite, constructive criticism) on constate que lui n'utilise pas de noms d'oiseaux (ou je suis pas tombé dessus) mais s'en mange:Please, **Linus, stop being arrogant and ignorant**, read this release note and tell us why you think ZFS is more of a buzzword and has no real maintenance.. Les propos de l'article sont propres sur eux, mais je trouve que le mec se base quand même vachement, justement, sur la postérité de Torvalds qui était avant moins, disons, composé. Donc, ce que reproche à Torvalds l'auteur de l'article, il l'utilise lui-même (vu le nom de l'article et son départLinus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it, le reste, lis justement ton lien)!Ah, concernant la citation, il est important de noter que quelqu'un a dis la même, plus d'une heure avant, sans les insultes. Et que l'auteur des insultes se cache derrière un pseudo, lui. Ou elle, d'ailleurs, ne soyons pas sexistes.
Bon, il faut le dire, j'ai pas trouvé de mentions claire avant de l'implémentation de ZFS critiquée. Les insultes sont donc relativement admissibles, étant antérieures au mail de Torvalds ou il explicite deux choses:
Traductions à l'arrache de ceci:
If you are talking about ZFS, you're talking about the Oracle version. Do you think it has a lot of development going on? I don't know.Tout ça, ça date du 10 janvier. L'article lui date du 13.
Je vais pas tout relever, mais j'ai vraiment eu l'impression que le type est un sysadmin qui touche pas au code, se mange pas les emmerdes de compat' d'ABI vs améliorations, ou les problèmes légaux (qui sont clairement abordés par Torvalds)… non, il se contente de dire "ah, il a été raison sur 3/4 de ses points, mais le point ou il précise «Personnellement» il ose dire son opinion!".
Désolé, je trouve son comportement franchement déplacé. Et d'ailleurs, vu que c'est paru et manifestement taillé pour un média de communication, faudrait p'tet virer la poutre de son oeil avant de parler de l'écharde dans l'oeil du voisin: la ML de linux, moins de monde la lit qu'arstechnica, il a donc probablement plus de poids de désinformation que Torvalds.
[^] # Re: Je ne comprends pas
Posté par freem . En réponse au lien La Cour de cassation confirme la redevance sur les musiques libres diffusées dans les magasins. Évalué à 2.
pour: "à part une assoce dont je me souviens plus le nom" oui, merci.
[^] # Re: ben comme tu le fais deja ?
Posté par freem . En réponse au message peut-on utiliser un filtre d'affichage dans aptitude ?. Évalué à 3.
Ça me semble pourtant clair… le fait de faire une recherche n'affecte que les éléments que tu parcoures, les éléments ne correspondants pas a la recherche sont toujours affichés, ce qui implique que le nombre de paquets présentés dans aptitude est multiplié par le nombre d'architectures activées, ce qui est autant de pollution gênant l'usage.
L'OP cherche une solution non pas afin de savoir quels paquets correspondent a l'architecture native de sa machine, mais afin de masquer les autres.
[^] # Re: Autres projets ?
Posté par freem . En réponse à la dépêche System-D.org, plate‑forme libre pour projets collaboratifs. Évalué à 4.
Implémenter du chiffrement tout court est galère et piégeux, c'est justement le genre de trucs sur lesquels j'aurais plus tendance a avoir confiance si le soft a un minimum d'ancienneté.
D'ailleurs, quant on vois une clé privée sur github, ça fait, genre, vraiment pas envie.
Hum… donc le souci est qu'Agora ne peut gérer qu'un seul projet? Parce que le fait que ça soit auto-hébergé, c'est aussi le cas pour vous, puisque vous l'hébergez vous-même. Il est donc, de fait, auto-hébergé au moins une fois :)
Donc, c'est le 1er projet important, celui qui a justifié l'apprentissage de la programmation?
Soit. Mais il y a une grosse base d'utilisateurs, c'est important pour avoir des contributeurs. Bon, JS aussi, certes.
Il y a aussi le fait que j'ai l'impression que les framework PHP gigotent moins que ceux du JS. Question pérennité, pour le côté serveur, j'ai du coup nettement plus confiance en PHP, Ruby ou Python qu'en ecmascript (en plus d'une allergie développée en devant intégrer de l'étron-JS fait par un collègue dans un système, ça aide pas. J'ai déjà vu des techno de merde, mais celle-ci est la seule que je sois arrivé à haïr).
[^] # Re: Choix du nom
Posté par freem . En réponse à la dépêche System-D.org, plate‑forme libre pour projets collaboratifs. Évalué à 5.
Bof. Autour de moi, les utilisateurs normaux comme avancés ont plus tendance a utiliser google comme un DNS au final. Les favoris? Idem, je vois très peu de monde les utiliser (il faut dire que ce n'est plus trop à l'honneur dans les interfaces des navigateurs, aussi).
Donc, oui, les gens vont taper ça sur leur moteur de recherche. Moi, avec "system d" et "system-d" sur DDG, j'ai:
D'ailleurs, je suis surpris de tomber que sur des résultats francophones, pour le coup.
Avec "systemd":
Perso, quand je choisis un nom pour un projet (des programmes), le 1er truc que je fais, c'est une recherche dans les paquets debian, puis sur internet sur le nom, histoire d'éviter les collisions. Sans même penser au référencement, hein.
Bon, faut noter, j'ai utilisé DDG et non google, en théorie ils ne trackent pas donc ne m'enferment pas dans une bulle, les résultats devraient donc être plus neutres que si j'avais utilisé google (encore que, je n'utilise que très peu les services google, donc bon…).
[^] # Re: Vidéos à regarder
Posté par freem . En réponse à la dépêche 36c3 « Resource exhaustion » — 36ᵉ édition du Chaos Communication Congress. Évalué à 2.
Tu dois être blasé, parce que perso, sur le peu de vidéo que j'ai regardé (j'y ai en gros passé mon samedi, le dimanche j'étais moins intéressé) et j'en ai eu plusieurs qui m'ont intéressé, dont celle que tu mentionnes.
Par exemple, j'ai trouvé intéressante celle sur les bootloaders, et la pauvre qualité de leurs codes (j'avoue avoir ri quand ils ont montré des bouts de code de uboot… m'a rappellé des souvenirs).