Ok je vois. Donc on ne ferme l'accès qu'à des ressources précisées explicitement. Me reste à comprendre comment ça marche mais pour ça je ne connais qu'une solution… va falloir que je teste :)
Je suis récemment tombé sur ceci (enfin, c'est tombé dans ma boîte mail pour être exact, provenance directe de la mailing list internationale de debian):
Le 17.09.2014 09:13, Jörg-Volker Peetz a écrit :
Take a look at bug #754987. If I remember correctly, Michael Biebl also
suggested on this list to replace the line
do_everything > /dev/null 2> /dev/null &
in file /lib/udev/net.agent
by
( do_everything ) > /dev/null 2> /dev/null &
Regards,
Jörg-Volker.
Pas sûr que ça aide, mais dans mon cas j'avais udev qui freezait pendant 30s au boot, et cette manip à résolut le problème. Bon, il faut préciser que ma situation est différente: je n'utilise pas systemd avec ma jessie (j'ai upgrade, et n'ai pas fait l'effort de passer à systemd, c'est même le contraire, je fait ce que je peux pour éviter) et il semblerait que certaines MaJ liées à systemd aient inséré des bugs dans ce qui marchait auparavant très bien.
Mais on est pas vendredi :)
Toujours est-il que pour ce genre de chose la ml est très intéressante à suivre, bien qu'il y ait beaucoup trop de bruit/parasitage autour de systemd en ce moment. À mon goût du moins.
Donc, quand d'habitude on fait un simple chmod +x foo.sh, avec SELinux, il y à d'autres actions à faire, sans quoi rien ne peut se lancer?
Ou est-ce que, par défaut, un certain niveau de "partage" est activé? Parce que sinon pour le dev/scripting ça doit être assez pénible… non?
En mettant la même résolution aux deux écrans, un truc dans ce genre devrait marcher: xrandr --ouput $SCREEN1 --pos 0x0 --mode $RESOLUTION --output $SCREEN2 --mode $RESOLUTION --pos 0x0
Bien sûr, ça ne marche que pour la session actuelle, sauf si tu le mets dans un script exécuté à chaque démarrage de ta session. Par exemple: editor ~/.bash_profile (en supposant que tu es sous debian, ou editor lance ton éditeur par défaut, bien sûr).
Enfin bon, je suis très surpris que tu n'aies pas un quelconque bidule graphique pour le configurer de manière "intuitive". Tu devrais fouiller dans les forums relatifs à ton DE (qui doit être gnome, j'imagine?).
Je suis d'accord, surtout s'il faut de l'authentification et du chiffrement, ssh reste le plus simple, et de loin.
Maintenant, si c'est trop "overkill" il y à toujours telnet, netcat, ce genre de choses. Mais c'est crade et pas sécurisé. Quoiqu'on puisse peut-être "sécuriser" un "tunnel netcat", avec "un peu" de glue et des trucs comme openssl, gnupg, etc. Mais franchement, réinventer ssh en plus crade, je vois pas l'intérêt.
Et qu'est-ce qui empêche un malware sur lequel tu doubles-clickes de s'ajouter ce label? (c'est une vraie question, j'avoue ne m'être jamais intéressé à ce genre de trucs…)
Un avantage pour ce type d'installation, c'est qu'il est possible d'utiliser SSH.
Hum… moui, mais en fait non. La ligne de commande n'est pas la seule chose disponible via ssh, comme le prouve d'ailleurs très bien l'installateur Debian.
Bon, ok, il faut guider quelqu'un pour qu'il aille chercher les bonnes options, ce qui est probablement plus simple avec une bonne vieille commande dans l'installateur de Arch (quoique… pas si sûr en fait) mais une fois fait, et c'est au tout début (juste après la langue si je me plante pas) c'est bonheur à 100%.
Il faudrait que je prenne la peine aussi de tester si c'est aussi faisable avec l'installateur graphique. Je ne serais pas surpris que ça fonctionne aussi: après tout, ssh c'est pour faire un tunnel. Qu'il aboutisse sur un sh quelconque ou sur un protocole graphique distant, ne change rien à ce point.
Au pire, ce qu'il faudrait se serait développer un script d'installation avec une gui, pourquoi pas. Se serait intéressant, mais comment s'y prendre ? Y a des outils pour créer cela ?!
Des outils pour générer un installateur, pas que je sache. Par contre, pour scripter en shell en ayant des boîtes de dialog, ça peut se trouver.
Bon, désolé, les liens sont les liens vers le dépôt Debian, mais je n'y peut rien, je ne connais que les noms des paquets pas l'URI de leur site officiel (qu'on doit pouvoir retrouver facilement j'imagine).
Ah, et puis ça sera pas du gtk ni qt, mais du terminal. Pas sexy, mais bon… efficace à priori (mais pas à postériori parce que je ne fais qu'utiliser des outils qui en dépendent, j'en ai pas écrit.)
De toutes façons la version stable est la seule recommandée pour une utilisation en production, utiliser une testing ou une unstable pour faire tourner un serveur est possible, mais nécessite d’aimer le sport.
Officiellement, pour tous les usages, seule la stable est recommandée. Dans la pratique, à mon faible niveau, en fonction de la personne à qui je m'adresse je conseillerais parfois plutôt la testing… de là à imaginer que certains admin puissent préférer unstable pour certains usages, il n'y à pas grand chose.
Mais bon, c'est sûr que pour suivre quelles sont les MaJ réellement pertinentes et les autres, ça ne doit pas être simple (on peut récup les changelog de Debian, certes, mais le problème est qu'il faut aussi aller consulter les logs officiels des projets puisque Debian ne les intègre pas… malheureusement. Je me demande pourquoi d'ailleurs?) vue la fréquence de MaJ.
Ceci étant dit, ça doit quand même être moins rock'n roll qu'une distro en rolling release j'imagine? Et je ne serai pas surpris qu'il y ait des serveurs qui tournent sous arch par exemple, vue la popularité de cette distro (enfin, c'est l'impression que j'ai, qu'arch est populaire. Après, pour un serveur, je n'en ai aucune idée…)
Pas nécessairement, mais pourquoi pas? Je n'ai jamais eu l'occasion de manipuler ce genre de bêtes, et je n'ai pas non plus entendu grand chose dessus.
Je ne pensais qu'aux libs, en fait, mais je ne savais de toute façon pas qu'il existait encore une licence "proprio", merci de l'info.
Par contre, j'ai beaucoup de mal à voir l'intérêt de publier un soft en même temps sous GPL et sous LGPL… quelqu'un voit un intérêt?
PS: quelqu'un aurait un lien vers une source officielle au sujet des licences? J'ai essayé de trouver l'info sur le site de Qt et de digia, mais n'ai rien trouvé de probant. Probablement mal cherché…
Il y à pas mal de choses ici et là sur la toile pour découvrir le shell, tu devrais t'en sortir en quelques recherches de ton moteur favori. Sinon, quelques commandes à connaître: man man, man info, man xdg-open, man cd, man ls, info bash. Avec ça, tu devrais être capable de faire les trucs de base et de découvrir le reste.
Ah, et aussi, tu pourrais apprécier midnight commander et l'auto-complétion. Pour cette dernière: si tu es sous Debian, installes le paquet bash-completion, édites le fichier /etc/bash.bashrc et dé-commentes les lignes après "# enable bash completion in interactive shells" (en fait, enlèves les # de début de ligne). Lances un nouveau terminal, et quand tu tapperas une commande, pour découvrir les paramètres possibles, appuies sur la touche tabulation à 2 reprises.
[edit]
Et si tu veux écouter de la musique ou regarder des vidéo en ligne de commande: mpd+mpc pour la musique, mpv pour les vidéos.
On peut aussi rappeler que Qt à également eu 2 licences à une époque. De mémoire, virtualbox également. Bref, ce ne sont pas les projets en double licence qui manquent, et qui sont restés libres (voire dans le cas de Qt se sont débarrassés de leur côté proprio).
Heu, non, ce ne sont pas les admin, mais les utilisateurs conservateurs, nuance. Au fil des discussions sur la ml, j'ai découvert que certains admin utilisent aussi l'unstable (en fonction des usages du serveur bien entendu).
D'ailleurs, point surprenant, certains considèrent (lu sur debian-user@lists.debian.org) que la pire des versions de Debian pour un serveur, c'est testing, parce qu'elle n'à pas les MaJ de sécu de la stable, et évolue moins vite qu'unstable, et du coup ce serait plus simple pour un attaquant de péter une testing qu'une unstable ou une stable. Je doute que je restitue correctement l'argument, ça remonte à plusieurs mois en arrière, mais j'avais trouvé ça très pertinent.
En comparatif, on a:
ArchLinux: créer un paquet se fait en 5 commandes shell
Debian: largement plus d'une dizaine (wget pour télécharger, tar pour décompresser, mkdir debian, echo 9 >debian/compat, …
Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?
Enfin bon… puisque tu te bases sur un modèle Arch pour dire que la procédure brute de Debian est pourrie, alors, une question:
qu'est-ce qui t'empêche d'écrire un script qui, en ne prenant que l'URI de la tarball:
télécharge une tarball
la décompresse
y crée un dossier debian, en fonction d'un modèle "bien fichu"
D'ailleurs, je serais assez surpris qu'aucun outil n'existe encore pour faire des trucs aussi triviaux de manière automatique…
Alors, franchement, j'ai "formé" un collègue à l'utilisation basique de git, ça m'a pris 1H. Moi, j'en avais beaucoup plus chié, mais je connais la cause: contrairement à lui, j'avais utilisé svn, qui est centralisé…
Après, je dis pas, pour des choses un peu complexes, ce n'est pas toujours hyper simple. Mais bon, il faut voir le contexte: on ne peut pas avoir un outil complet qui ne soit pas plus complexe qu'un outil qui n'offre que peu de fonctionnalités, je pense.
En tout cas, je constate que ça tape pas mal sur git, mais je n'ai vu aucun autre nom de VCS décentralisé dans les commentaires de cet article…
Darcs, mercurial, bazaar, fossil par exemple, pourquoi personne ne les soumets en alternatives? Ils sont décentralisés, libres, et ont sûrement chacun des points forts, mais alors, encore une fois, pourquoi personne n'a mis l'un d'eux en opposition à git???
Je suis d'accord avec toi sur un point, pour le coup: le fait d'installer par défaut automatiquement les recommended, je trouve ça à chier. Parce que, ok, l'espace disque c'est pas cher, mais bon, installer les recommended ce n'est pas juste de l'espace disque: ce sont également des programmes qui sont chargés quand on utilise celui qui les à installés. Ils ne seraient pas recommandés s'ils n'étaient pas utilisés, après tout.
Maintenant, ça se désactive (il s'agit de l'une de mes premières actions d'ailleurs), et puis, tous les utilisateurs ne savent pas forcément de quoi ils ont besoin, et installer automatiquement les recommended permets, j'imagine, d'éviter que les gens disent que ça ne marche pas out-of-the-box… même si pour moi Debian ne devrait pas cibler ce type de public (qui ne fait pas attention à ce qu'il installe ni aux "conseils" du système).
Par contre, pour ce qui est de démarrer automatiquement les daemons lors d'une install, je trouve ça plutôt logique (et d'ailleurs, il existe des exceptions à cette règle) puisque quand on installe un daemon, en règle générale, c'est qu'il sera utile la plupart du temps. Pourquoi contraindre l'utilisateur (qui n'est pas nécessairement root en plus) à démarrer manuellement un service style dbus, cups, sshd?
Et si tu as installé un serveur ftp, http ou samba (entres autres), c'est probablement que ta machine devra fournir un service à n'importe quel moment, non?
Et puis allez, je prend un peu d'avance: de toute façon avec systemd ils ne seront démarrés qu'à la demande :P
J'ai l'impression que Debian ne cible pas les "vieux barbus de la vieille école", mais un équilibre entre eux et le néophyte pur. Si je devait conseiller une distro à quelqu'un qui ne connaît pas linux mais est capable de comprendre ce qu'il fait et de lire le man, je pense que Debian est un bon départ: c'est une distro qui ne nécessite pas énormément de maintenance, mais qui permets malgré tout un bon niveau de personnalisation (bon, maintenant je pense qu'il va être temps pour moi de passer à autre chose, mais c'est pas le sujet)
En plus des dalles déjà tactiles, il me semble qu'il est possible d'ajouter un composant sur l'écran pour le rendre "tactile" (de mémoire, un périph qui est une sorte de grille infrarouge).
En tout cas, pour avoir subi un écran tactile cathodique, j'ai appris à utiliser le clavier en mode souris sous windows, et je suis assez traumatisé pour essayer autant que faire se peut de dégager les applications qui ne sont pas capables de se passer de périphérique de pointage…
Je viens de regarder des screenshot, j'espère être tombé sur les bons… mais ils corroborent ce que je pensais, à savoir que pacman est l'équivalent d'apt-, avec le très très gros avantage d'être en couleur on dirait (pour pacman, pas apt-).
Pour pkgfile, j'ai un très gros doute sur les screen que j'ai trouvés, mais ça semble être un outil graphique?
Pour le coup, ils n'ont rien à voir avec aptitude, ni l'un ni l'autre.
Enfin, si, aptitude en ligne de commande peut être comparé à pacman, mais ça semble s'arrêter là. Perso, je parlais plutôt d'aptitude en mode ncurses, parce que pour être honnête, je ne vois que peu d'intérêt à l'utiliser en ligne de commande, vue la lourdeur du truc (et pourtant j'adore cet outil…).
Le gros intérêt d'aptitude comparé à d'autres logiciels comme synaptic c'est qu'en plus d'avoir une IHM très bien foutue (j'ai testé synaptic il y à longtemps, c'était très pénible à utiliser), c'est du ncurses, donc utilisable via ssh sur une machine sans serveur graphique. Et avoir une interface en ncurses permets vraiment de gagner du temps, surtout au début quand on viens du monde windows… comme ça à été mon cas. Même maintenant, je m'en sers encore parce que je trouve ça tout de même bien pratique d'avoir en un clin d'œil toutes les infos dont j'ai besoin sur une liste de paquets, et qu'il permets aussi une simplicité impressionnante quand il s'agit de choisir entre plusieurs alternatives.
Enfin, je suis pas un commercial, mais j'adore vraiment cet outil. Dommage qu'il ne soit pas possible de faire sauter ce p***** de solver et qu'il soit aussi lent à démarrer. Entres autres défauts (l'outil est résolument mono-threadé, et n'exploite pas à 100% les informations liées aux paquets, par exemple).
Quant à savoir pourquoi il n'est pas installé,
L'intérêt je ne le vois pas, mais je me suis aussi très mal exprimé sur ce coup :)
En fait, aptitude se divise (par défaut) en 2 zones d'écrans: l'une avec une arborescence (1er niveau: paquets pouvant être MaJ, paquets installés, non installés, obsolètes ou locaux, virtuels, tâches… 2ème niveau: section genre admin, devel, lib… 3ème niveau: main/contrib/non-free, et enfin les noms des paquets) l'autre avec des infos sur le paquet sélectionné, qui à 3 onglets: description, dépendances liées (info dont je ne me sers jamais, et qui permets de voir pourquoi ça pourrait être installé, le point sur lequel je me suis mal exprimé) et pourquoi c'est installé (je trouve cet écran un "poil" redondant avec celui d'avant, d'une certaine façon).
Après, c'est sûr, ce n'est pas scriptable facilement une IHM ncurses, mais je parlait au niveau utilisateur. Si j'avais besoin de scripter des actions sur les paquets, je jouerais plutôt avec apt-* et dpkg.
Pour un paquet propre, probablement :) merci pour cette correction. (dans le cas d'un truc que l'on ne souhaite pas s'embêter à publier, pour une raison ou une autre, on peut directement construire le paquet binaire, et là c'est un répertoire DEBIAN qu'il faut. Et comme je n'ai jamais pris le temps de construire des paquets debian propres pour le moment…)
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 2.
Ok je vois. Donc on ne ferme l'accès qu'à des ressources précisées explicitement. Me reste à comprendre comment ça marche mais pour ça je ne connais qu'une solution… va falloir que je teste :)
# modif à tester dans ... hum des scripts systèmes?
Posté par freem . En réponse au message Boot très lent avec systemd. Évalué à 3.
Je suis récemment tombé sur ceci (enfin, c'est tombé dans ma boîte mail pour être exact, provenance directe de la mailing list internationale de debian):
Pas sûr que ça aide, mais dans mon cas j'avais udev qui freezait pendant 30s au boot, et cette manip à résolut le problème. Bon, il faut préciser que ma situation est différente: je n'utilise pas systemd avec ma jessie (j'ai upgrade, et n'ai pas fait l'effort de passer à systemd, c'est même le contraire, je fait ce que je peux pour éviter) et il semblerait que certaines MaJ liées à systemd aient inséré des bugs dans ce qui marchait auparavant très bien.
Mais on est pas vendredi :)
Toujours est-il que pour ce genre de chose la ml est très intéressante à suivre, bien qu'il y ait beaucoup trop de bruit/parasitage autour de systemd en ce moment. À mon goût du moins.
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 2.
Donc, quand d'habitude on fait un simple
chmod +x foo.sh, avec SELinux, il y à d'autres actions à faire, sans quoi rien ne peut se lancer?Ou est-ce que, par défaut, un certain niveau de "partage" est activé? Parce que sinon pour le dev/scripting ça doit être assez pénible… non?
# xrandr
Posté par freem . En réponse au message Deux écrans un seul bureau?. Évalué à 2.
En mettant la même résolution aux deux écrans, un truc dans ce genre devrait marcher:
xrandr --ouput $SCREEN1 --pos 0x0 --mode $RESOLUTION --output $SCREEN2 --mode $RESOLUTION --pos 0x0Bien sûr, ça ne marche que pour la session actuelle, sauf si tu le mets dans un script exécuté à chaque démarrage de ta session. Par exemple:
editor ~/.bash_profile(en supposant que tu es sous debian, ou editor lance ton éditeur par défaut, bien sûr).Enfin bon, je suis très surpris que tu n'aies pas un quelconque bidule graphique pour le configurer de manière "intuitive". Tu devrais fouiller dans les forums relatifs à ton DE (qui doit être gnome, j'imagine?).
[^] # Re: pourquoi pas ssh ?
Posté par freem . En réponse au message Moule/Framework pour application répartie sur plusieurs ordinateurs ?. Évalué à 2.
Je suis d'accord, surtout s'il faut de l'authentification et du chiffrement, ssh reste le plus simple, et de loin.
Maintenant, si c'est trop "overkill" il y à toujours telnet, netcat, ce genre de choses. Mais c'est crade et pas sécurisé. Quoiqu'on puisse peut-être "sécuriser" un "tunnel netcat", avec "un peu" de glue et des trucs comme openssl, gnupg, etc. Mais franchement, réinventer ssh en plus crade, je vois pas l'intérêt.
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 3. Dernière modification le 23 septembre 2014 à 16:08.
Et qu'est-ce qui empêche un malware sur lequel tu doubles-clickes de s'ajouter ce label? (c'est une vraie question, j'avoue ne m'être jamais intéressé à ce genre de trucs…)
[^] # Re: Que recherches-tu dans une distribution?
Posté par freem . En réponse au journal Archlinux, quoi de plus que Frugalware?. Évalué à 2.
Hum… moui, mais en fait non. La ligne de commande n'est pas la seule chose disponible via ssh, comme le prouve d'ailleurs très bien l'installateur Debian.
Bon, ok, il faut guider quelqu'un pour qu'il aille chercher les bonnes options, ce qui est probablement plus simple avec une bonne vieille commande dans l'installateur de Arch (quoique… pas si sûr en fait) mais une fois fait, et c'est au tout début (juste après la langue si je me plante pas) c'est bonheur à 100%.
Il faudrait que je prenne la peine aussi de tester si c'est aussi faisable avec l'installateur graphique. Je ne serais pas surpris que ça fonctionne aussi: après tout, ssh c'est pour faire un tunnel. Qu'il aboutisse sur un sh quelconque ou sur un protocole graphique distant, ne change rien à ce point.
[^] # Re: Public cible
Posté par freem . En réponse au journal Archlinux, quoi de plus que Frugalware?. Évalué à 2.
Des outils pour générer un installateur, pas que je sache. Par contre, pour scripter en shell en ayant des boîtes de dialog, ça peut se trouver.
Bon, désolé, les liens sont les liens vers le dépôt Debian, mais je n'y peut rien, je ne connais que les noms des paquets pas l'URI de leur site officiel (qu'on doit pouvoir retrouver facilement j'imagine).
Ah, et puis ça sera pas du gtk ni qt, mais du terminal. Pas sexy, mais bon… efficace à priori (mais pas à postériori parce que je ne fais qu'utiliser des outils qui en dépendent, j'en ai pas écrit.)
[^] # Re: Retour personnel
Posté par freem . En réponse au message cherche retours d'expériences sur le Lemote YeeLoong 8089B . Évalué à 2.
C++ en fait. Mais oui, la prog est mon activité favorite sur PC :)
[^] # Re: Intérêt de cette machine ?
Posté par freem . En réponse au message cherche retours d'expériences sur le Lemote YeeLoong 8089B . Évalué à 2.
Le fait que même le BIOS soit libre.
[^] # Re: ici
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 2.
Officiellement, pour tous les usages, seule la stable est recommandée. Dans la pratique, à mon faible niveau, en fonction de la personne à qui je m'adresse je conseillerais parfois plutôt la testing… de là à imaginer que certains admin puissent préférer unstable pour certains usages, il n'y à pas grand chose.
Mais bon, c'est sûr que pour suivre quelles sont les MaJ réellement pertinentes et les autres, ça ne doit pas être simple (on peut récup les changelog de Debian, certes, mais le problème est qu'il faut aussi aller consulter les logs officiels des projets puisque Debian ne les intègre pas… malheureusement. Je me demande pourquoi d'ailleurs?) vue la fréquence de MaJ.
Ceci étant dit, ça doit quand même être moins rock'n roll qu'une distro en rolling release j'imagine? Et je ne serai pas surpris qu'il y ait des serveurs qui tournent sous arch par exemple, vue la popularité de cette distro (enfin, c'est l'impression que j'ai, qu'arch est populaire. Après, pour un serveur, je n'en ai aucune idée…)
[^] # Re: mips
Posté par freem . En réponse au message cherche retours d'expériences sur le Lemote YeeLoong 8089B . Évalué à 2.
Pas nécessairement, mais pourquoi pas? Je n'ai jamais eu l'occasion de manipuler ce genre de bêtes, et je n'ai pas non plus entendu grand chose dessus.
[^] # Re: Prometteur mais...
Posté par freem . En réponse au journal Humhub, (encore) un réseau social libre. Évalué à 2.
Je ne pensais qu'aux libs, en fait, mais je ne savais de toute façon pas qu'il existait encore une licence "proprio", merci de l'info.
Par contre, j'ai beaucoup de mal à voir l'intérêt de publier un soft en même temps sous GPL et sous LGPL… quelqu'un voit un intérêt?
PS: quelqu'un aurait un lien vers une source officielle au sujet des licences? J'ai essayé de trouver l'info sur le site de Qt et de digia, mais n'ai rien trouvé de probant. Probablement mal cherché…
# Quelques commandes pour décoller
Posté par freem . En réponse au message retranscription en ligne de commande. Évalué à 2. Dernière modification le 12 septembre 2014 à 14:46.
Il y à pas mal de choses ici et là sur la toile pour découvrir le shell, tu devrais t'en sortir en quelques recherches de ton moteur favori. Sinon, quelques commandes à connaître:
man man,man info,man xdg-open,man cd,man ls,info bash. Avec ça, tu devrais être capable de faire les trucs de base et de découvrir le reste.Ah, et aussi, tu pourrais apprécier midnight commander et l'auto-complétion. Pour cette dernière: si tu es sous Debian, installes le paquet bash-completion, édites le fichier /etc/bash.bashrc et dé-commentes les lignes après "# enable bash completion in interactive shells" (en fait, enlèves les # de début de ligne). Lances un nouveau terminal, et quand tu tapperas une commande, pour découvrir les paramètres possibles, appuies sur la touche tabulation à 2 reprises.
[edit]
Et si tu veux écouter de la musique ou regarder des vidéo en ligne de commande: mpd+mpc pour la musique, mpv pour les vidéos.
[^] # Re: ici
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 3.
C'est vrai que l'auteur aurait du les représenter en queue de pie :)
[^] # Re: Prometteur mais...
Posté par freem . En réponse au journal Humhub, (encore) un réseau social libre. Évalué à 2.
On peut aussi rappeler que Qt à également eu 2 licences à une époque. De mémoire, virtualbox également. Bref, ce ne sont pas les projets en double licence qui manquent, et qui sont restés libres (voire dans le cas de Qt se sont débarrassés de leur côté proprio).
[^] # Re: ici
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 4.
Heu, non, ce ne sont pas les admin, mais les utilisateurs conservateurs, nuance. Au fil des discussions sur la ml, j'ai découvert que certains admin utilisent aussi l'unstable (en fonction des usages du serveur bien entendu).
D'ailleurs, point surprenant, certains considèrent (lu sur debian-user@lists.debian.org) que la pire des versions de Debian pour un serveur, c'est testing, parce qu'elle n'à pas les MaJ de sécu de la stable, et évolue moins vite qu'unstable, et du coup ce serait plus simple pour un attaquant de péter une testing qu'une unstable ou une stable. Je doute que je restitue correctement l'argument, ça remonte à plusieurs mois en arrière, mais j'avais trouvé ça très pertinent.
[^] # Re: Point par point
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 1.
Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?
Enfin bon… puisque tu te bases sur un modèle Arch pour dire que la procédure brute de Debian est pourrie, alors, une question:
qu'est-ce qui t'empêche d'écrire un script qui, en ne prenant que l'URI de la tarball:
D'ailleurs, je serais assez surpris qu'aucun outil n'existe encore pour faire des trucs aussi triviaux de manière automatique…
[^] # Re: doc de git?
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 6.
Mouai.
Alors, franchement, j'ai "formé" un collègue à l'utilisation basique de git, ça m'a pris 1H. Moi, j'en avais beaucoup plus chié, mais je connais la cause: contrairement à lui, j'avais utilisé svn, qui est centralisé…
Après, je dis pas, pour des choses un peu complexes, ce n'est pas toujours hyper simple. Mais bon, il faut voir le contexte: on ne peut pas avoir un outil complet qui ne soit pas plus complexe qu'un outil qui n'offre que peu de fonctionnalités, je pense.
En tout cas, je constate que ça tape pas mal sur git, mais je n'ai vu aucun autre nom de VCS décentralisé dans les commentaires de cet article…
Darcs, mercurial, bazaar, fossil par exemple, pourquoi personne ne les soumets en alternatives? Ils sont décentralisés, libres, et ont sûrement chacun des points forts, mais alors, encore une fois, pourquoi personne n'a mis l'un d'eux en opposition à git???
[^] # Re: Point par point
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 6.
Je suis d'accord avec toi sur un point, pour le coup: le fait d'installer par défaut automatiquement les recommended, je trouve ça à chier. Parce que, ok, l'espace disque c'est pas cher, mais bon, installer les recommended ce n'est pas juste de l'espace disque: ce sont également des programmes qui sont chargés quand on utilise celui qui les à installés. Ils ne seraient pas recommandés s'ils n'étaient pas utilisés, après tout.
Maintenant, ça se désactive (il s'agit de l'une de mes premières actions d'ailleurs), et puis, tous les utilisateurs ne savent pas forcément de quoi ils ont besoin, et installer automatiquement les recommended permets, j'imagine, d'éviter que les gens disent que ça ne marche pas out-of-the-box… même si pour moi Debian ne devrait pas cibler ce type de public (qui ne fait pas attention à ce qu'il installe ni aux "conseils" du système).
Par contre, pour ce qui est de démarrer automatiquement les daemons lors d'une install, je trouve ça plutôt logique (et d'ailleurs, il existe des exceptions à cette règle) puisque quand on installe un daemon, en règle générale, c'est qu'il sera utile la plupart du temps. Pourquoi contraindre l'utilisateur (qui n'est pas nécessairement root en plus) à démarrer manuellement un service style dbus, cups, sshd?
Et si tu as installé un serveur ftp, http ou samba (entres autres), c'est probablement que ta machine devra fournir un service à n'importe quel moment, non?
Et puis allez, je prend un peu d'avance: de toute façon avec systemd ils ne seront démarrés qu'à la demande :P
J'ai l'impression que Debian ne cible pas les "vieux barbus de la vieille école", mais un équilibre entre eux et le néophyte pur. Si je devait conseiller une distro à quelqu'un qui ne connaît pas linux mais est capable de comprendre ce qu'il fait et de lire le man, je pense que Debian est un bon départ: c'est une distro qui ne nécessite pas énormément de maintenance, mais qui permets malgré tout un bon niveau de personnalisation (bon, maintenant je pense qu'il va être temps pour moi de passer à autre chose, mais c'est pas le sujet)
[^] # Re: le tactile c'est pas nouveau
Posté par freem . En réponse au journal Linux, c'est déjà demain - écran tactile. Évalué à 2.
En plus des dalles déjà tactiles, il me semble qu'il est possible d'ajouter un composant sur l'écran pour le rendre "tactile" (de mémoire, un périph qui est une sorte de grille infrarouge).
En tout cas, pour avoir subi un écran tactile cathodique, j'ai appris à utiliser le clavier en mode souris sous windows, et je suis assez traumatisé pour essayer autant que faire se peut de dégager les applications qui ne sont pas capables de se passer de périphérique de pointage…
[^] # Re: mouaif
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 4.
Et du coup les gens ont du faire du copier/coller dans des dossiers trunk, tags et branch. Supayr.
[^] # Re: Et pourtant il y a bien trop de packages
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 2.
Je viens de regarder des screenshot, j'espère être tombé sur les bons… mais ils corroborent ce que je pensais, à savoir que pacman est l'équivalent d'apt-, avec le très très gros avantage d'être en couleur on dirait (pour pacman, pas apt-).
Pour pkgfile, j'ai un très gros doute sur les screen que j'ai trouvés, mais ça semble être un outil graphique?
Pour le coup, ils n'ont rien à voir avec aptitude, ni l'un ni l'autre.
Enfin, si, aptitude en ligne de commande peut être comparé à pacman, mais ça semble s'arrêter là. Perso, je parlais plutôt d'aptitude en mode ncurses, parce que pour être honnête, je ne vois que peu d'intérêt à l'utiliser en ligne de commande, vue la lourdeur du truc (et pourtant j'adore cet outil…).
Le gros intérêt d'aptitude comparé à d'autres logiciels comme synaptic c'est qu'en plus d'avoir une IHM très bien foutue (j'ai testé synaptic il y à longtemps, c'était très pénible à utiliser), c'est du ncurses, donc utilisable via ssh sur une machine sans serveur graphique. Et avoir une interface en ncurses permets vraiment de gagner du temps, surtout au début quand on viens du monde windows… comme ça à été mon cas. Même maintenant, je m'en sers encore parce que je trouve ça tout de même bien pratique d'avoir en un clin d'œil toutes les infos dont j'ai besoin sur une liste de paquets, et qu'il permets aussi une simplicité impressionnante quand il s'agit de choisir entre plusieurs alternatives.
Enfin, je suis pas un commercial, mais j'adore vraiment cet outil. Dommage qu'il ne soit pas possible de faire sauter ce p***** de solver et qu'il soit aussi lent à démarrer. Entres autres défauts (l'outil est résolument mono-threadé, et n'exploite pas à 100% les informations liées aux paquets, par exemple).
L'intérêt je ne le vois pas, mais je me suis aussi très mal exprimé sur ce coup :)
En fait, aptitude se divise (par défaut) en 2 zones d'écrans: l'une avec une arborescence (1er niveau: paquets pouvant être MaJ, paquets installés, non installés, obsolètes ou locaux, virtuels, tâches… 2ème niveau: section genre admin, devel, lib… 3ème niveau: main/contrib/non-free, et enfin les noms des paquets) l'autre avec des infos sur le paquet sélectionné, qui à 3 onglets: description, dépendances liées (info dont je ne me sers jamais, et qui permets de voir pourquoi ça pourrait être installé, le point sur lequel je me suis mal exprimé) et pourquoi c'est installé (je trouve cet écran un "poil" redondant avec celui d'avant, d'une certaine façon).
Après, c'est sûr, ce n'est pas scriptable facilement une IHM ncurses, mais je parlait au niveau utilisateur. Si j'avais besoin de scripter des actions sur les paquets, je jouerais plutôt avec apt-* et dpkg.
[^] # Re: Et pourtant il y a bien trop de packages
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 0.
Aptitude est ton amie.
[^] # Re: Pourquoi git est-il un problème?
Posté par freem . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 3.
Pour un paquet propre, probablement :) merci pour cette correction. (dans le cas d'un truc que l'on ne souhaite pas s'embêter à publier, pour une raison ou une autre, on peut directement construire le paquet binaire, et là c'est un répertoire DEBIAN qu'il faut. Et comme je n'ai jamais pris le temps de construire des paquets debian propres pour le moment…)