kuniyoshi a écrit 72 commentaires

  • [^] # Re: gestion des supports USB (clef)

    Posté par  . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 2.

    Je viens de regarder sur l'une de mes machines virtuelles exploitées par un système OpenBSD -current (noyau/base uniquement et pas de logiciels tierces partie donc). Les services nsd et unbound font (nativement) partie de la base du système OpenBSD par conséquent ce n'est pas étonnant que leurs fichiers de configuration se situent dans /var/. Par contre, je n'ai pas vu heimdall. Allez… je vais voir sur mon système OpenBSD -current Desktop qui exploite mon portable. :)

  • [^] # Re: gestion des supports USB (clef)

    Posté par  . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 2.

    Je ne sais pas pour NSD mais je confirme que les fichiers de configuration de slim et de conky ne sont pas dans /usr/local/etc/ (qui n'existe pas je le répète) mais dans /etc/.

    Mais je vais aller tout de même aller vérifier dans /var/slim/etc/ et /var/conky/etc/… si ces répertoires existent. Si c'est le cas, je trouverais cela étrange de copier des fichiers de configuration de "bêtes" logiciels tierce partie (comme slim ou conky) dans /var/ ?! Non ?

    J'y vais et je vous tiens au courant !!

  • [^] # Re: gestion des supports USB (clef)

    Posté par  . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 7.

    Bonjour et merci pour l'information ! :)

    Voici ma motivation : Je vais être honnête. J'ai installé DragonFly BSD par curiosité pour une utilisation de type Desktop. (Cet aspect m'a toujours intéressé, du moins dans un premier temps, avec un nouvel OS.) Je vais donner mon point de vue sur ce DragonFly BSD (pour exploiter un poste de travail donc) et ce en ne l'ayant utilisé que sur une après-midi. Par conséquent, cet avis est un plus de l'ordre du ressenti ! Autrement dit, je ne cherche pas à troller. Loin de là ! Par contre, je vais naturellement essayer de comparer DragonFly BSD RELEASE à un système FreeBSD RELEASE (architecture : amd64) mais aussi à un système OpenBSD -current (architecture : amd64) que j'utilise actuellement quotidiennement.

    Prérequis : L'installation de DragonFly BSD a été une installation chiffrée.
    Objectif : Installer un système DragonFly BSD (Mate) sur un poste de travail.

    (1) Installation chiffrée

    Le chiffrement n'a pas pu se faire sur la totalité du disque. (Le système de fichiers « /boot » n'a pas été chiffré.) Peut-être est-ce lié au système de fichiers HAMMER et/ou à LVM ? En fait, je n'ai pas bien compris quel était le rôle de LVM au sein de DragonFly BSD. Il me semblait que HAMMER était un « clone BSD » de ZFS mais cela ne semble pas être le cas. Sinon comment expliquer la présence LVM ?

    À titre de comparaison, une installation chiffrée avec FreeBSD/ZFS ou OpenBSD/UFS permet de chiffrer tout le disque.

    (2) Parefeu pf

    Sur les trois systèmes, le parefeu pf est utilisable. Par contre, la version de pf la plus récente est celle d'OpenBSD. Et pour cause !

    (3) Architectures gérées

    DragonFly BSD RELEASE existe uniquement en version x86_64. (La version « embarquée » de wine l'est aussi.) La version x86_64 de FreeBSD RELEASE permet (encore) la gestion des logiciels construits pour une architecture x86 (y compris par le biais de wine pour les logiciels créés pour un système Windows de Microsoft). Quant à OpenBSD, ce système ne permet pas d'utiliser wine et, depuis peu, ne permet plus d'émuler un noyau linux.

    Sur tous ces derniers aspects, FreeBSD RELEASE est le plus polyvalent des trois systèmes.

    (4) Couche graphique

    Tout fonctionne assez bien (voire très bien) sur les trois systèmes. À noter que l'environnement Mate n'existe pas sur OpenBSD. Cependant, l'environnement Xfce en version 4.12* est présent pour le remplacer. La localisation en français de l'environnement graphique (y compris les terminaux de type Xterm) est plus simple à mettre en place sur OpenBSD. En effet, avec les systèmes FreeBSD et DragonFly BSD, j'ai dû générer puis configurer le fichier xorg.conf (ce qui n'est pas le cas d'OpenBSD). Par contre, OpenBSD/Xfce -current plante parfois (liés aux logiciels comme LibreOffice, Mozilla Firefox, Thunar, …). Toutefois, il ne faut pas perdre de vue qu'OpenBSD -current est un système d'exploitation en développement constant. Compte tenu de ce simple fait, OpenBSD -current est assez stable !! Sur ce plan, FreeBSD/Mate RELEASE n'a jamais planté sur le même portable. Quant à DragonFly BSD RELEASE, hier, tout a bien fonctionné… mis à part un petit souci avec la fermeture du logiciel FrozenBubble qui a occasionné un changement de résolution (800 sur 600) mais rien de bien « méchant ».

    (5) Gestionnaire des paquets binaires (logiciels tierce partie)

    D'un côté « pkg » sur FreeBSD/DragonFly et de l'autre « pkg_add » pour OpenBSD. Les deux gestionnaires de paquets fonctionnent très bien. Il est cependant à noter que la séparation nette entre le couple noyau/base et les logiciels tierce partie est moins « nette » sur OpenBSD !! En effet, sur OpenBSD -current, les mises à jour du couple noyau/base et celles des logiciels tierce partie sont, de fait, liées. De plus, l'arborescence /usr/local/etc/ n'existe pas sur OpenBSD. Tous les fichiers de configuration sont situés dans /etc/. Étrange d'ailleurs ?!

    (6) Suites bureautiques

    La suite Office « LibreOffice » est livrée en version 5* sur les trois systèmes.

    Sur les trois, la version de LibreOffice la plus récente (5.2* contre 5.0* pour les deux autres BSD) est celle d'OpenBSD -current mais, pour ma part, ce n'est pas très gênant.

    (7) Navigateurs Web

    Dans les trois cas, le navigateur Mozilla Firefox est proposé dans une version 49*.

    Ce que je n'ai pas pu tester avec le système DragonFly BSD : (Je n'ai donc pas d'avis sur ces sujets.)

    (1) Les mises à jour du couple noyau/base

    Pour DragonFly BSD : Il me semble qu'il faut recompiler les sources à la « main ».

    Pour FreeBSD -RELEASE : Les mises à jour (binaires) s'effectuent via le logiciel freebsd-update.

    Pour OpenBSD :

    • pour -release/-stable : Il faut compiler les sources à la « main » ;
    • pour -current : Il faut redémarrer la machine sur un noyau « bsd.rd » (bien « choisi » pour avoir une synchronisation éventuelle avec les logiciels tierce partie) afin d'« écraser » l'ancien système de base par le nouveau (mise à jour « full » binaires).

    (2) Le système de fichiers HAMMER (LVM ?)

    Je ne peux donc pas le comparer au système de fichier ZFS (que je connais un peu). Toujours est-il qu'en utilisation Desktop, tout a été transparent. Cela ne m'a pas frappé. Je n'ai rien à dire sur ce point. En mémoire vive, ce système de fichiers ne semble ni plus lourd ni moins lourd que ZFS (à machine égale). Quant à OpenBSD, il s'agit du système de fichiers UFS qui de toute façon plus léger mais plus vieux aussi.

    (3) Le(s) compilateur(s) lié(s) au langage C

    (4) Vitualisation native (type « KVM » avec un noyau linux)

    Pour FreeBSD RELEASE : Bhyve
    Pour OpenBSD -current : vmm/vmd
    Pour DragonFly BSD RELEASE : ?

    Ma conclusion (temporaire) :

    Je trouve le système d'exploitation DragonFly BSD intéressant en tant que système d'exploitation pouvant gérer un poste de travail mais il est objectivement encore jeune pour une telle utilisation (notamment en comparaison de son « père » FreeBSD qui lui est fait de l'ombre). Néanmoins je pense que cet OS a un avenir et du potentiel sur mon poste travail. Pour le vérifier, je compte désormais le tester régulièrement. Mais, mon portable restera exploité par OpenBSD -current qui est certes un système d'exploitation plus simple (plus "kiss"), plus léger et qui m'apporte entière satisfaction… pour l'instant. ;-)

    Voilà l'avis d'un simple utilisateur.

  • [^] # Re: gestion des supports USB (clef)

    Posté par  . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 3.

    Salut.

    Je viens de régler les deux problèmes évoqués ci-dessus (supports USB + SMP pris en charge correctement)… En effet, je suis revenu sur OpenBSD -current ! :)

  • # gestion des supports USB (clef)

    Posté par  . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 1.

    Bonjour.

    Cet article m'a donné envie d'installer (pour la deuxième fois de ma vie !) DragonFlyBSD sur mon portable Lenovo thinkPad X200s (que est compatible avec les *BSD). Il faut savoir que sur ce même portable, j'utilise au quotidien OpenBSD -current (et aussi un système FreeBSD RELEASE mais moins souvent en ce moment je l'admets). Par conséquent, sans trop de surprises, ce portable semble bien reconnu et exploité par DragonFlyBSD.

    Néanmois, j'ai un souci. J'essaie de monter une clef USB.

    Après l'avoir connectée, la commande dmesg me retourne

    ugen3.2: <Verbatim> at usbus3
    umass0: <Verbatim STORE N GO, class 0/0, rev 2.00/1.00, addr 2> on usbus3
    da8 at umass-sim0 bus 0 target 0 lun 0
    da8: <Verbatim STORE N GO 1.0> Removable Direct Access SCSI-2 device
    da8: 40.000MB/s transfers
    da8: 7651MB (15669248 512 byte sectors: 255H 63S/T 975C)

    Lorsque je regarde dans /dev/, j'ai effectivement le fichier lié à ma clef à savoir da8 mais contrairement à FreeBSD, il n'existe pas de fichier du type da8s1 pour monter la clef. Pas grave, j'ai tenté à l'arrache (en root).

    (1) Un premier essai lorsque l'unique partition de la clef était formatée en vfat32 :

    # mount -t msdos /dev/da8 /mnt

    (2) Un deuxième essai après avoir formaté l'unique partition de cette clef en ext3 (à l'aide de fdisk de mon système Debian)

    # mount -t ext2fs /dev/da8 /mnt

    Dans les deux cas, le shell me retourne que le montage n'est pas possible (ce qui ne me surprend pas en fait !).

    Retour donné par le shell dans le cas de la clef formatée en ext3 :

    mount_ext2fs: /dev/da8: Input/output error

    Une idée ?

    Autre fait étrange : Pour l'instant du moins, le noyau de cet OS ne reconnaît qu'un core sur les deux de mon Core 2 Duo ?! Néanmoins, je pense que je ne vais pas tarder à aller voir du côté de /boot/loader.conf ou alors est-ce peut-être lié au fait que le noyau utilisé n'est pas la version MP ?!

    ps : Message envoyé de DragonFlyBSD 4.6.1 (arch : amd64) ! :)

  • [^] # Re: T410 ou X220?

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    Le X220 écran 12", pas de lecteur dvd

    Le lecteur DVD interne ne sert plus à rien de nos jours. Je suppose que la "bête" sait démarrer sur un support branché via un port USB. Il te faudra alors juste un lecteur DVD externe ou mieux une clef USB bootable. Ah oui un écran mat, c'est mieux… enfin de mon point de vue ! ;-)

  • [^] # Re: T400

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    Non! je compare pas les deux processeurs… J'ai juste dit comme ça que j'avais un vieux PC qui tourne avec debian8 et qui rame beaucoup car je pensais qu'il avait 2Go de ram (en fait il a 1Go!!…)
    Du coup je me suis dit: s'il rame autant avec 2Go c'est que ça doit être lourd et doit avoir besoin d'au moins minimum 4Go…

    Ah ok ! ;-)

    Du coup… Tu fais quoi comme taf? Ça a l'air intéressant et tu as l'air de t'y connaitre bien en environnement linux…

    Rien à voir avec le monde de l'informatique en fait. Juste un enseignant… un peu éclairé ! ;-)

    Moi je suis à des milliers d'années lumières !! Eheheh

    Regarde cette vidéo : (Nous sommes tous petits… petits… petits… :-))

    https://www.youtube.com/watch?v=GoW8Tf7hTGA

    ps : "Pub" interne : http://obsd4a.net/qa/

    @+ sur… OpenBSD maybe ;-)

  • [^] # Re: T410 ou X220?

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    Pour ma part (à l'instinct !!), le X220 mais je ne connais ni l'un ni l'autre.

    De plus, quelle est la résolution de chaque écran ? Le proc ? La quantité de mémoire vive initiale ? Durée de la batterie (surtout pour le X220) ? État général de chaque machine ?… Difficile de comparer ainsi. Juste une certitude : L'ultra-portable X220 prendra moins de place de fait !

  • [^] # Re: T410, X220, HP Probook...

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 2.

    J'ai eu un T420 en mains et il est juste magnifique.

    Si tu achètes de l'occasion (surtout en portable), il faut parfois faire des compromis. Effectivement, le moniteur est à regarder mais les charnières aussi. Si avant de l'acheter, tu as aussi la possibilité de voir quelques éléments internes (propreté, état du ventilateur du processeur, vis éventuellement manquantes, slots pour les barrettes de mémoire vive, la place nécessaire pour y intégrer un SSD non SLIM avec éventuellement le "mécanisme" adapté pour un tel "disque", …), c'est mieux en fait !

    Je l'ai pas acheté parce qu'il avait un petit soucis à l'écran(un minuscule endroit à l'écran qui était plus lumineux, comme s'il manquait de l'étain sur un miroir).

    Mon avis : Tu as peut-être raté une occaz' ! ;-)

    Je ne connais pas les autres Lenovo ThinkPad que tu cites (T410 ou X220) mais si ils sont de la même qualité que le T400 ou le X200s (en plus récents), tu "risques" de tester du bon matériel ! ;-)

  • [^] # Re: T400

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    En fait je n'utilise plus le T400 en tant que poste de travail mais en tant que parefeu/serveur d'appoint (voir ci-dessus). Lorsque je l'utilisais comme poste de travail, il était exploité par Wheezy et je n'ai jamais eu de soucis mais attention je parle d'un poste de travail généraliste ce qui exclut les jeux vidéos ainsi que les vidéos HD (que je n'ai jamais essayées). Pour travailler, pas de souci.

    Sinon, pour ma version du portable T400 (il y a peut-être plusieurs version ?!), le processeur est un Centrino 2 vPro (possédant nativement la virtualisation physique) et cette machine est dotée de 8 Go de mémoire (DDR3). Si tu lis ce que j'ai écrit ci-dessus, mon système FreeBSD (arch : amd64) qui exploite actuellement mon T400 (avec ZFS qui n'est pas spécialement réputé pour être léger comme système de fichiers !) lance au démarrage deux machines virtuelles OpenBSD (arch : amd64, grâce à VirtualBox et sans couche graphique) qui me servent de parefeux redondants (CARP + pfsync), un serveur DNS local unbound (exploité par un système FreeBSD jailé, arch : amd64) pour l'ensemble de mes systèmes jailés, un serveur Web (exploité par un système FreeBSD jailé, arch : amd64) et un miroir local de dépôt de Debian (exploité par un système Debian GNU/kFreeBSD jailé, arch : amd64). De plus, je rappelle qu'il s'agit d'une installation chiffrée ce qui alourdit l'ensemble… a priori. Néanmoins, l'ensemble fonctionne très bien (et sans ralentissements visibles du moins). Il s'agit d'un serveur/parefeu d'appoint donc cette machine n'est pas constamment allumée. (Et bien oui, cette machine est un portable après tout qui n'a pas été conçu pour servir de serveur !)

    … AMD Athlon XP 3200, et ça rame à mort!! presque inutilisable le truc!

    J'espère que tu n'essaies pas de comparer pas un AMD Athlon XP 3200 à un Centrino 2 vPro qui même si il s'agit d'un vieux processeur ne souffre d'aucune comparaison possible avec l'Athlon précité ! ;-)

    Ma machine de travail est un ultra-portable X200s qui est très similaire au T400 (Centrino 2 vPro, 8 Go de mémoire vive DDR3, SSD) mais plus portable évidemment. Je travaille dessus de façon quotidienne. Exploitée par Debian 8/Mate (arch : amd64), je lance parfois jusqu'à une dizaine de machines virtuelles (grâce à VirtualBox), le navigateur Firefox ouvert avec quelques dizaines d'onglets (protocole utilisé : wifi), Libroffice lancé et une compilation lourde d'un document LaTeX (de type livre de 300 pages avec des images) en parallèle. Alors dans ce cas bien précis, je dois bien avouer qu'il commence à ralentir… un peu, si peu finalement !!! ;-)

    Bref tu l'auras compris, je suis très satisfait de cette machine de travail. Je l'ai acheté en occasion et elle tient bon. Voilà !

  • [^] # Re: le Dell a l'air OK

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    Pour ma part je travaille très bien avec une connexion wifi (liée à ma Box par contre) d'une machine exploitée par Debian stable ou FreeBSD -release ou OpenBSD -current sur mon ultra-portable ThinkPad X200s. Sur ces trois OS, la connexion wifi est stable. La seule différence visible entre les deux systèmes BSD et Debian stable réside dans le fait suivant : pas de configuration graphique du wifi pour les systèmes *BSD.

    Sinon, la carte wifi fonctionne (et est reconnue) d'emblée sur FreeBSD. Par contre, il faut télécharger le module via ethernet pour OpenBSD -current à l'aide de la commande fw_update.

    Ce qui a été dit ci-dessus sur le X200s vaut aussi pour le T400 !!!

  • # T400

    Posté par  . En réponse au message Machine pour une Debian8. Évalué à 1.

    Ayant testé Debian 8 sur un Lenovo ThinkPad T400, je peux confirmer que tout fonctionne. Un upgrade matériel a été effectué au niveau de la mémoire vive passant de 2 Go à 8 Go !! Actuellement, il est exploité par un système FreeBSD (arch : amd64 + installation chiffrée + ZFS) et tout fonctionne très bien (la virtualisation physique aussi). Cette machine me sert de routeur/parefeu d'appoint. En effet, j'ai réussi à installer deux systèmes virtuelles OpenBSD jouant comme parefeux redondant (via CARP + pfsync) entre ma Box et mon réseau interne. Les machines virtuelles (créées via VirtualBox) sont lancées de façon automatique démarrage de FreeBSD. En parallèle, le système de fichiers ZFS me permet de créer (cloner en fait) des jails de systèmes FreeBSD (serveur DNS local, …) et Debian GNU/kFreeBSD (pour créer par exemple un miroir de dépôts pour mes systèmes Debian de mon réseau interne !!!!). Non rien à dire. Ça fonctionne comme prévu ! ;-)

    Pas de soucis donc !!! À acheter en occasion les yeux fermés… pour une utilisation bureautique, pour de la virtualisation basique (via VirtualBox par exemple), pour faire de la programmation, pour une utilisation serveur/parefeu d'appoint… En outre, cette machine est à la fois silencieuse et solide. (ThinkPad oblige !)

  • [^] # Re: Poubelle ?

    Posté par  . En réponse au message Laptop vieillissant : changer ou bidouiller ?. Évalué à 2.

    Bah, c'est surtout que ces trucs ne sont pas conçus pour durer aussi longtemps.

    Si tu parles de portables premier prix, je suis d'accord avec toi.

    Si tu parles des portables en général, pas d'accord ! ;-) En effet, j'ai un vieux Lenovo ThinkPad X200s (de 2009 il me semble) exploité par un système OpenBSD -current amd64 (je travaille régulièrement dessus)… et bien il fonctionne très bien. Bon il faut bien voir qu'il s'agit d'un portable de la gamme PRO (lié à la grande époque de la division PC d'IBM) acheté d'occasion mais je suis toujours impressionné par cette machine : silencieuse, solide (je l'ai déjà faite tomber sur une cheminée en brique !), fonctionnelle avec des OS libres/open source. À titre de comparaison, les portables HP que j'ai déjà utilisé par le passé (même de la gamme PRO) ont tous rendu l'âme ! :-( De plus, ils étaient effectivement tous bruyants (mais il est vrai que je n'ai jamais eu l'occasion de les tester avec un SSD).

  • [^] # Re: Voici un lien

    Posté par  . En réponse au message Installer scratch sur debian. Évalué à 1.

    Salut NeoX.

    Qu'entends-tu par "non, tu installes la version web, une seule installation, le service web en localhost…" ?

    Serait-il possible d'utiliser une version Web (Flash nécessaire je suppose) sur une machine locale ? Si oui, peux-tu nous indiquer un lien officiel qui propose cette version ?

    Merci pour ta réponse.

  • [^] # Re: Voici un lien

    Posté par  . En réponse au message Installer scratch sur debian. Évalué à 1.

    mais dès que j'essaie d'installer une Scratch-488.air avec, je me retrouve avec le même soucis d'installation.

    448… Scratch-448.air tu veux dire ! ;-)

    D'après ce que j'ai compris, pour "AdobeAirInstaller.bin" comme pour les archives .air, le truc essaie de re-créer une archive .deb puis l'installe sur le système. Comme il n'arrive pas à créer cette archive, pas moyen d'installer.

    A priori, je dirai que ce n'est pas le cas. De mon expérience, les binaires du fichier AdobeAirInstaller.bin s'installent dans le répertoire "/opt/". C'est aussi le cas des binaires de "Scratch-448.air". Dans les deux cas, il n'y a pas de création de paquets au format ".deb".

    Tiens je pense à un truc. Pour ma part, depuis le début de mon intervention sur ce sujet, je fais référence à des systèmes Debian stable (pas de testing ni de sid). Est-ce ton cas ?

    Peut-être que je trouverai ce Scratch-2.0-488.deb quelque part ?

    Un tel paquet n'existe pas ! J'ai déjà cherché. Crois-moi.

    Ça mer permettrai d'installer l'application… Pour les mises à jour, tant pis…

    Pour ma part, j'ai réussi à créer un paquet au format ".deb" de Scratch 2 dans sa version 447. Attention ce paquet ne contient que la partie non-libre. (Pas d'Adobe Air dans ce paquet donc !) Mais j'ai laissé tomber la construction/maintenance d'un tel paquet avec l'arrivée de la version 448. En effet, les mises à jour de ce logiciel "semi-libre" sont trop fréquentes (toutes les six semaines je dirais). Il aurait alors fallu que je crée (que j'adapte le code source de Scracth 2 dans le paquet en fait) un nouveau paquet toutes les six semaines car la mise à jour du logiciel une fois installé ne fonctionnait pas. Ce n'est clairement pas la bonne solution avec un tel logiciel.

    Le truc, c'est que c'est pas moi qui veut l'utiliser, c'est pour mes filles qui sont au collège…

    Et… encore plus "drôle" pour nous, les non-windowsiens ! Tu n'es visiblement pas au courant mais les professeurs de techno vont probablement utiliser dans le cadre des EPI (sur la robotique par exemple, Arduino, …) un logiciel dérivé de Scratch 2 : mBlock. Ce logiciel ne s'installe que sur un système Windows de Microsoft et ou un système MacOS X d'Apple. J'ai testé. Il s'installe bien sur un système Debian stable en utilisant le logiciel libre wine. Mais c'est lourd ! :-(

    http://www.pedagogie.ac-nantes.fr/technologies-et-sciences-des-ingenieurs/documentation/didacticiels-tutoriels/mblock-videos-d-initiation-919548.kjsp?RH=1160751856953
    http://www.mblock.cc/

    Si c'était moi, elles feraient du python ;°)…

    Juste pour information, les professeurs de mathématiques n'ont (initialement) pas été formés pour enseigner la science informatique. Et c'est ce que l'on va leur demander avec cette réforme. Le langage visuel de programmation Scratch 2 peut déjà paraître bien "obscur" pour certains (la majorité ?) d'entre eux. Alors tu penses bien qu'enseigner un langage "textuel" de programmation comme python est actuellement hors de portée pour la majorité des enseignants de mathématiques… et de technologie.

    et je vais pas installer un windows pour ça, quand même !

    Oh que non ! D'autant plus qu'il faut avoir une licence non OEM (licence "boîte" il me semble) pour pour pouvoir virtualiser légalement un système Windows. Et puis virtualiser un système Windows pour pouvoir utiliser un logiciel qui pèse environ 60 Mo, ce n'est pas très efficace. :-(

    Voici une alternative (langage visuel de programmation) entièrement libre utilisant la technologie HTML5 (et qui peut être copiée en local sur un système comme Debian) :

    http://snap.berkeley.edu/

    Dans les programmes officiels, Scracth 2 n'est pas explicitement nommé pour l'enseignement de l'algorithmique et de la programmation mais dans les faits il sera majoritairement utilisé sur le terrain ! (Une raison : L'exercice d'algorithmique/programmation du sujet 0 de mathématiques du nouveau DNB fait apparaître explicitement… le logiciel Scratch 2.)

    De plus, elle sont 2, donc 2 wine à configurer : elles ont chacune leur compte !

    Je sais, c'est lourd. Mais si tu te diriges vers cette solution, il va falloir procéder à deux installations distinctes (une pour chaque compte) de Scratch 2 à l'aide de wine. (Même chose pour les mises à jour d'ailleurs parce qu'il faudra tout ré-installer ! :-() En effet, lors d'une installation avec le logiciel wine d'un logiciel construit pour Windows, de multiples références liées au compte (nom de l'utilisateur, …) sont créées. C'est ainsi !!! Je te l'accorde. Ce n'est pas pratique du tout.

  • [^] # Re: Voici un lien

    Posté par  . En réponse au message Installer scratch sur debian. Évalué à 1.

    Là je ne sais pas quoi te dire. Où as-tu récupéré Adobeair.bin. Ici je suppose :

    https://scratch.mit.edu/scratch2download/

    Pour information, je sais l'installation "chatouilleuse" (on va dire !) mais j'ai toujours réussi à l'installer sur un système Debian 8 (amd64 ou i386). Ton souci est étrange. As-tu mis à jour ton système Debian ?

    Sinon tu as deux autres façons d'utiliser Scratch 2 sur un système Debian :

    • en utilisant le version online. (No comments sur le côté pratique !) https://scratch.mit.edu/
      Dans ce cas, il faut que la technologie Flash d'Adobe soit installée comme un plugin de ton navigateur Web.

    • en installant la version de Scratch 2 construite pour un système Windows à l'aide du logiciel libre wine.
      Mais dans ce cas, cette installation non native prend de la place sur le compte de l'utilisateur car le répertoire ".wine" pèse lourd. Cela fonctionne cependant.

    Que ce soit une installation native ou non native, les mises à jour (fréquentes) de ce logiciel "semi-libre" peuvent poser problème. Autrement dit même si tu parviens à l'installer, les ennuis liés à ce logiciel ne seront pas terminés pour autant ! :-(

    À la fin de ce tutoriel (partie n°9)

    https://www.cyrille-borne.com/forum/showthread.php?tid=656&pid=5669

    j'explique comment utiliser le logiciel libre wine… sur un système FreeBSD. Les idées exposées peuvent être transposées pour un système Debian GNU/Linux… le cas échéant. Courage avec Scratch 2 ! :-(

  • # Voici un lien

    Posté par  . En réponse au message Installer scratch sur debian. Évalué à 1.

    Suivre les détails de cet article.

    https://www.cyrille-borne.com/article2440/installer-scratch-2-sur-une-debian-64-bits

    Testé et validé sur Debian 8/Gnome 3, Debian 8/Mate et Debian 8/Xfce.

  • [^] # Re: slim

    Posté par  . En réponse au message Problème extinction avec XFCE sur FreeBSD . Évalué à 1.

    Je viens de remettre en fonction le système FreeBSD 10.3-RELEASE (en version Desktop) que j'avais installé il y a déjà plus de quatre mois. Je viens de mettre à jour le couple noyau/base system ainsi que les logiciels tierce-partie. Et bien comment dire… tout fonctionne comme il y a quatre mois !!! ;-) Pas de soucis lors des mises à jour donc !

    Sinon, je n'ai pas bien compris ton souci.

    (1) Si tu as installé un gestionnaire de session comme slim ou gdm, tu devrais pouvoir éteindre/redémarrer ton système en tant que simple utilisateur. Enfin… a priori !

    (2) Sinon, je suppose que tu démarres ta session graphique via un "startx". Dans ce cas :

    (a) soit tu "joues" avec PolicyKit (comme cela a été mentionné ci-dessus).
    (b) soit tu fais en sorte que ton simple utilisateur puisse utiliser la commande "sudo shutdown -p now" (dans une console virtuelle par exemple depuis MATE).

    Alors. Quel est le contexte exact ?

  • # slim

    Posté par  . En réponse au message Problème extinction avec XFCE sur FreeBSD . Évalué à 1.

    Bonsoir.

    As-tu installé le chargeur de session slim ?

    Sinon un lien qui pourrait t'aider dans ta découverte de ce bel OS qu'est FreeBSD : ;-)

    https://www.cyrille-borne.com/forum/showthread.php?tid=656&pid=5669

  • [^] # Re: FreeBSD-RELEASE + semi-rolling release

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 0. Dernière modification le 14 avril 2016 à 16:13.

    Effectivement. Pour avoir aussi utilisé NetBSD (très brièvement) et OpenBSD (plutôt pour la création de passerelles filtrantes), cela semble être une caractéristique des systèmes *BSD. Par contre, il me semble que les développeurs du système OpenBSD (contrairement à leurs homologues de NetBSD) ne recommandent pas d'installer des logiciels tierce-partie via pkg_add ou en les compilant depuis les ports (sauf besoins spécifiques). Ils recommandent l'utilisation générique du couple base/noyau d'OpenBSD. Néanmoins, c'est tout à fait faisable mais dans ce cas l'utilisateur s'éloigne de "l'esprit" du projet.

    Sinon, dans l'organisation générale du sytème et dans l'esprit (exemple : système des ports*), je trouve qu'un système FreeBSD est plus proche d'un système NetBSD. Sur ces deux aspects, OpenBSD est plus en retrait. Mais, il s'agit juste de mon avis ! (Il y a tout de même quelques "passerelles" entre tous ces projets : pf, openssh,… Rien n'est figé.)

    NB : *A priori, le système des ports de FreeBSD est inspiré de celui de NetBSD ("pkgsrc" de mémoire).

  • [^] # Re: kern.vt.enable_bell

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 1.

    Ok. Merci.

    Je suis en train d'apprendre à utiliser FreeBSD (dans sa version RELEASE). Cela fait environ cinq ans que je "tourne" autour de ce système comme je l'ai fait il y a quelques années avec le système Debian GNU/Linux stable (que j'ai finalement adopté en simple boot sur toutes mes postes de travail). En effet, j'essaie actuellement de le "modeler" pour que :

    • d'une part, il exploite au mieux mon ultra-portable LENOVO ThinkPad X200s ;
    • d'autre part, il exploite cette machine en tant que poste de travail (notamment dans le cadre de ma mission de professeur de mathématiques).

    Pour ce faire, je me base sur ce que je connais bien. J'essaie donc de reproduire les fonctionnalités de mes systèmes Debian GNU/Linux. FreeBSD n'est clairement pas aussi "user-friendly" (cela me rappelle mes débuts sur les systèmes GNU/Linux !) mais j'apprécie de plus en plus son côté "carré" (voire "obscur" ;-)). Donc, je persévére !

    Pour ceux ou celles qui seraient intéressés par mes tentatives multiples et répétées pour atteindre l'objectif ci-dessus, voici un lien :

    http://cyrille-borne.com/forum/showthread.php?tid=656

    Pour l'instant j'apprends… notamment sur le mode de fonctionnement de la communauté qui se "cache" derrière FreeBSD… d'où, ma question précédente ! :-)

    NB :
    Exemple : Récemment, j'ai découvert ce site. (Je ne sais pas si ce site est représentatif de l'état d'esprit de la communauté des *BSD mais a priori, je ne pense pas.)

    http://www.gcu-squad.org/

    et notamment

    http://www.gcu-squad.org/rule --> J'utilise l'UTF-8 !

    puis

    http://www.gcu-squad.org/rules

    C'est spécial mais drôle je trouve ! :-)

  • [^] # Re: kern.vt.enable_bell

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 2.

    Bah je me suis juste rendu compte que la commande "sysrc -f /etc/sysctl.conf kern.vt.bell_enable" ne fonctionnait pas sur mon système. Or cette commande m'intéressait, car j'avais des "bip" désagréables dans mes consoles "Xterm" sur mon environnement Xfce. Et je voulais à tout prix régler ce souci désagréable. Et bien, c'est désormais chose faite ! ;-)

  • [^] # Re: kern.vt.enable_bell

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 0.

    Êtes-vous un développeur officiel du projet FreeBSD… un contributeur ?

  • [^] # Re: FreeBSD-RELEASE + semi-rolling release

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 0.

    Merci pour votre réponse. Pour ce qui est du système GNU/Linux ArchLinux, je l'ai déjà utilisé mais je ne prétends pas le maîtriser. Les mises à jour se font de façon continue (base, noyau linux et logiciels tierce-partie). Mais en fait, je ne crois pas que cela soit bien judicieux de faire une distinction entre ces trois éléments dans ce contexte. (La séparation entre tous ces éléments n'étant pas aussi scricte et "carrée" que sur un système FreeBSD.) De mon expérience avec ArchLinux, l'ensemble de l'OS bouge au fur et à mesure en fonction des nouveautés logicielles (après quelques tests de stabilité… je suppose). De fait, il n'y a pas de version pour ArchLinux. Si un utilisateur d'ArchLinux plus expert passe par ici, il pourrait peut-être confirmer ?! Par contre une chose est certaine : avant l'arrivée du système d'initialisation systemd, le système ArchLinux centralisait la configuration de ses services dans le fichier "/etc/rc.conf" comme le système FreeBSD. Ce n'est plus le cas désormais.

  • # kern.vt.enable_bell

    Posté par  . En réponse à la dépêche FreeBSD 10.3. Évalué à 4.

    Tout est dans le titre ! Lorsque la commande "sysctl -a | grep bell" est lancée, elle donne les informations suivantes sur mon système FreeBSD 10.3-RELEASE :

    kern.vt.enable_bell: 0
    hw.syscons.bell: 0

    Contrairement à ce qui est mentionné au début de la dépêche :

    la variable sysctl kern.vt.bell_enable permet de changer l'état de la sonnerie du terminal vt ;

    Est-ce une coquille ?