Damien Caliste a écrit 25 commentaires

C'est pour ça qu'il me semble avoir conseillé le Jolla en mettant en avant la pile logicielle plus que l'aspect licence de l'ensemble, c'était même mis en remarque initiale ;) Par ailleurs, rapporter des infos sur le Jolla (tel qu'il est aujourd'hui et pas tel qu'il pourrait être suivant qu'on écoute les uns ou suit l'exemple des autres, ne veut pas dire implicitement que je trouve les autres solutions mauvaises ou inadaptées aux propos de ce journal. Le lecteur attentif saura faire son choix en fonction des informations fournies.

Comme d'habitude, j'ai l'impression qu'on s'enflamme inutilement (même pour un vendredi) :
- excuse-moi si j'ai mal interprété tes propos, mais en lisant ta réponse, il me semble que pour toi Sailfish se résume à Silica (i.e. la partie C++ des composant QML pour l'affichage). Dans ce sens, il n'y a effectivement pas à discuter, c'est close source et visiblement Jolla n'est pas pressé de libérer tout ça, voir même de le faire un jour. Silica, c'est une bonne partie de la totalité du code réalisé par Jolla, donc Jolla ne fait pas de l'Open Source, ok, c'est un point de vue, je le respecte.

Maintenant, pour essayer d'être équitable, il faut rajouter que Jolla contribue aussi à des briques libres et c'était le propos de mon commentaire précédent. Sailfish repose sur Mer (qui est utilisé dans Plasma active si j'ai bien suivi) et Jolla a écrit une bonne partie du middleware de Mer pour la téléphonie (avec plus ou moins de bonne gestion de gouvernance de projet, cf. certains messages sur la mailing list de dev de Mer). Donc pour revenir à ta question, si on enlève Silica de Sailfish, il nous reste un téléphone avec tout le code libre nécessaire pour faire de la téléphonie, gérer une gallerie de photos, s'interfacer avec OwnCloud et autre (sauf drivers, mais c'est une autre histoire qui ne dépend pas de Jolla, mais de Qualcomm et autre constructeurs) mais pas d'interface…

Je rejoins enfin un commentaire précédent sur ce dernier point, s'il n'y a pas d'interface, c'est aussi peut-être par manque de main d'œuvre des projets libres pour amorcer la pompe : j'aimerai bien mettre Ekiga comme numéroteur SIP mais il n'y a pas d'interface adaptée au touch screen. Et avant de me dire de contribuer, je rajouterai que c'est effectivement ce que je fais, pour ma part j'ai porté une appli d'affichage d'OSM afin de ne pas utiliser le truc HERE fourni avec l'appareil.

Donc, pour finir, je ne dirais pas que la pile qui tourne sur mon téléphone est complètement close-source et avoir des bouts de proprio dedans ne me fait pas jeter le bébé avec l'eau du bain. En revanche, je suis parfaitement d'accord avec toi pour dire que laisser Silica closed source et certaines appli sympa comme le mailer closed source ne me rend pas Jolla sympathique. Mais comme ils en sont à leurs débuts, je leur laisse le bénéfice du doute et serai le premier à critiquer s'ils se mettent à remplacer des bouts actuellement libres par des trucs proprio.

Remarque initiale : je ne dis pas que SailfishOS est le Graal du libre, loin de là et il existe des solutions de téléphonie bien plus complètes d'un point de vue licences libres (FirefoxOS ou openmoko qui me viennent à l'esprit).

Maintenant, comparer SailfishOS (sa base libre et une partie de son interface proprio) à BSD et MacOS, je trouve que ça ne reflète pas la réalité. Pour avoir utilisé un tout petit peu MacOS (mais mes remarques viennent peut-être du fait que je ne connais pas du tout BSD), je ne retrouve que difficilement mes billes sur MacOS :
- par exemple la libtool du système n'est pas la même et tu dois installer toi-même la GNU libtool pour pouvoir compiler la plupart des logiciels libres auxquels on est habitué.
- il n'y a pas de gestion de paquets et de dépendances dans l'OS (alors que sailfishOS utilise yum, pkcon et rpm), ce qui oblige à installer des outils tiers comme Macport.
- le serveur graphique et les bibliothèques graphiques (Cocoa, aqua ou je ne sais quoi) sont proprio et propres à MacOS, alors que Sailfish utilise Wayland et Qt.
- MacOS participe-t-il au développement du libre ? Je ne sais pas trop répondre à cette question, peut-être un peu dans Cups, mais je n'en sais rien. Par contre Sailfish, en temps que gros utilisateur de Qt, sous Wayland, utilisant plein de bibliothèques nouvelles comme QGeoPosition… a rapporté et patché plein de bugs dans Qt dont le résultat est dispo pour la communauté en général dans Qt 5.2 et Qt 5.3.
- MacOS utilise-t-il les recommandations de Freedesktop ? SailfishOS oui, les icônes du lanceur sont des .desktop standards par exemple.

Bref, je trouve que SailfishOS se rapproche assez du Linux de mon ordi (qui malheureusement a lui aussi des firmwares fermés, un BIOS pas mieux…) et c'est pour ça que j'apprécie cette distribution. Après, je suis le premier à demander l'ouverture du code de certaines de appli maison dont l'UI est fermée comme le logiciel de courriel par exemple.

J'ai un Jolla depuis début janvier. Je confirme les dires de la première réponse à ton commentaire et je rajouterai ceci :
- c'est un plaisir d'avoir un téléphone dont on est root parce que le constructeur te le permet pleinement ;
- c'est une distribution Linux presque standard qui tourne dessus, avec BTRFS en file system, systemd pour l'init, wayland pour l'affichage et Qt5.2 pour le reste (+ gstreamer, glib, cairo et j'en passe), cf. mer project.
- c'est hyper simple de faire un programme pour le téléphone, je connaissais avant glib et gtk seulement mais j'ai fait en quelques centaines de lignes de QML+JS une appli qui affiche la liste d'appel de sa freebox et l'intègre avec le répertoire du téléphone.
- la partie C++ des composant QML du téléphone est propriétaire :(, mais les parties en QML sont en licence BSD (il me semble), donc on peut lire et modifier à sa guise une partie de l'interface. Certaines choses se libèrent petit à petit (la couche UI du navigateur qui est basée sur Gecko ou l'appli de gestion des documents). La partie middleware est dans une licence libre et dispo sur github (la gestion C++ du répertoire, les plugins de synchronisation calDAV…).

Bref, il manque des choses par rapport à un appareil grand public, c'est clair, mais c'est tellement confortable, je trouve, d'avoir un ordi-phone qui ressemble a son ordi que je préfère vivre avec les petits manques.

Edit : ah, j'oubliais, pour les drivers, point de salut, ça utilise ceux d'Android, donc pas libres :(

La région semble aussi ne pas avoir voulu laisser cet événement dans l'ombre avec plusieurs campagnes publicitaires dont on peut lire ici quelques mots :
http://m3gumi.wordpress.com/tag/gnulinux/

C'est un partenaria avec Iberia la compagnie aérienne espagnole pour qu'elle fasse la promotion de la distribution à sa clientelle en vol.

Je suis d'accord avec toutes tes remarques mais voici une petite précision quant à celle-ci :

On est sur la page d'accueil, en http, donc pas sécurisé, et voila qu'on demande sur cette page non sécurisée d'entrer son numéro de compte et le code secret !!!

À cette adresse (https://www.caisse-epargne.fr/asp/modele2.aspx?np=aide_conne(...) ), ils annoncent que si tu entres sur la page http (sans s), avant d'envoyer tes données, il demande à passer en https. Bon après je suis assez ignorant du fonctionnement des requettes et je ne peux pas juger l'exactitude de ces informations.

En tout cas, c'est clair que le vrai problème de sécurité, c'est le code secret à 6 chiffres. Pas moyen de mettre un vrai mot de passe avec des caractères non alpha numérique, une douzaine de caractères... Ils ont fait un petit sondage il y a quelques semaines et je leur avais demandé ça dans les remarques générales sur la sécurité. Sait-on jamais, si plusieurs personnes ont répondu comme moi, ça arrivera peut-être jusqu'à l'organe décisionnel.

En plus des informations pertinentes du commentaire précédent, suivant le compilateur que tu utilises, tu peux changer la valeur d'une variable d'environnement pour que ton programme marche sans rien y changer :

Avec le compilateur 'g95', cette variable d'environnement s'appelle G95_ENDIAN, avec le compilateur d'Intel ('ifort'), on peut faire la même chose mais la variable a un nom différent : F_UFMTENDIAN. Quant aux autres compilateurs, renseigne-toi en lisant leur documentation, c'est sûrement possible aussi, mais pas toujours (cf. gfortran).

Selon l'environnement dans lequel tu te trouves, pour changer les variables d'environnement, il faut faire :
- avec bash : 'export G95_ENDIAN=LITTLE' ;
- avec ksh/csh : 'setenv G95_ENDIAN=LITTLE' ;
- avec DOS : 'set G95_ENDIAN=LITTLE' (enfin, je crois me souvenir, mais mon utilisation du DOS remonte à plusieurs années)...

Enfin, la plupart des compilateurs permet de choisir à la compilation si la lecture se fera en little ou en big-endian. Souvent, cette option de compilation s'appelle -mlittle-endian ou -mbig-endian. Là encore, pour ton compilateur spécifique vérifie qu'il supporte ces options dans le manuel.

Dernière remarque : ceci est valable pour du Fortran90. Pour le Fortran77, je n'en sais rien.

Bonjour,

Tu trouveras à cette adresse comment faire un "hello world" en GTK avec une gestion du projet par les autotools :
http://bo.majewski.name/bluear/gnu/GTK/plain/index.htm

Et une petite amélioration pour internationaliser ton projet :
http://bo.majewski.name/bluear/gnu/GTK/i18n/index.htm

Ensuite, il y a le tutoriel officiel de GTK :
http://www.gtk.org/tutorial/
Il explique et donne des exemples pour différents widgets.

Après je ne peux que te conseiller de lire au fur et à mesure de tes besoins les doc des API de Glib et GTK (http://developer.gnome.org/doc/API/2.0/gtk/index.html et plus généralement http://www.gtk.org/api/ ).

Quand tu commenceras à maitriser le GTK, tu auras envie d'étendre ou de créer de nouveaux widgets. Il y a dans les archives du Gnome Journal, http://www.gnomejournal.org/archives/ , deux articles sur la façon de créer soit-même des widgets nouveaux (journaux de décembre et février dernier).

Enfin pour bien comprendre la façon dont les widgets s'imbriquent entre eux (le positionnement...), je te conseille aussi d'utiliser Glade (http://glade.gnome.org/ ). Tu peux réaliser rapidement des interfaces avec, tester différents placements, ensuite libre à toi de t'inspirer du code généré pour écrire le tien, le garder tel quel ou enfin utiliser libglade pour charger directement le XML décrivant ton interface.

Oui, oui, quand je disais « merger », je pensais rapidement intégrer tes modifications à la main. Bref, c'est fait et je propose le SRPM (donc avec les sources et les images pour les icônes ; et le spec) sur le site. À priori, il marche, en tout cas, il crée bien un RPM sur ma Debian... Enfin, tout ça sera visible dès que le site sera mis à jour, d'ici demain ou après-demain. J'ai aussi corrigé la coquille de traduction dans le menu.

Pour les autres changements, comme la création du répertoire ~/.v_sim, par défaut ; ça sera dans la prochaine version.

Pour OpenPBS, c'est un système de queue, qui permet de lancer des tâches qui seront mises en attente pour passer sur les machines du cluster (cf. http://www.openpbs.org ). En très résumé, on peut choisir le nombre de processurs (distribués ou par noeud), la quantité de mémoire, le temps CPU max, le type de file d'attente (haute priorité, basse priorité)... Ensuite, le système de queue fait passer notre job selon ces critères et la configuration faite par l'administrateur (par exemple, on favorise les jobs demandant beaucoup de mémoire...). Pour l'utilisateur, OpenPBS fonctionne avec des scripts shell : on fait un script avec des commentaires parsés par OpenPBS, script qui sera appelé quand notre job passera.

Bien sûr, pour orchestrer tout ça, il faut un scheduler. Là où j'ai travaillé, celui d'OpenPBS n'était pas considéré comme très performant et on lui avait préféré Maui ( http://mauischeduler.sourceforge.net/ ). Bon, étant du côté utilisateur, je ne saurais pas vraiment expliquer pourquoi...

Enfin, tout ceci est installable sur nos PC, mais ça ne sert à rien sur une machine seule. Par contre tous ces logiciels sont installés sur les machines frontales des clusters (celles qui servent à la connexion des utilisateurs) qui sont souvent des PC Linux.

Tout d'abord un grand merci pour ton intérêt et ton travail.

Quand j'étais au CEA, je travaillais sur une Mandriva donc c'était facile pour moi pour faire des paquets pour cette distribution. Maintenant, je suis à l'Université de Louvain la Neuve en Belgique et mon poste de travail est une Fedora 4 (d'où les paquets dispo.).

Bref, je mettrais sur le site cette semaine les trois icônes (Source 1-2-3) qui permettent de construire le paquet. Je mettrais aussi le fichier spec adapté à Mandriva (la gestion du menu est différente de chez Fedora, donc si c'est ce spec là que tu as utilisé, c'est normal que le menu n'ai pas été créé). En tout cas, je vais essayer de "merger" ton spec avec celui que j'avais fait pour les versions 3.1.x.

Merci pour la typo aussi, ça sera corrigé durant la semaine prochaine.

Pour le rafraîchissement de la fenêtre OpenGL, effectivement, elle ne se rafraîchit pas automatiquement pour éviter de faire trop ramer la machine si il y a trop d'atomes. Par contre cette fenêtre a un flag d'utilisation du backing-store, donc si ton serveur X dispose de ça, le rafraîchissement est fait par le serveur X. Si le serveur n'a pas de backing-store, tu peux forcer le rafraîchissement en allant dans l'onglet OpenGL et en cochant la case en bas. Je reconnais que ceci n'est pas très intuitif et je suis en train de le corriger dans la version de développement.

Effectivement V_Sim ne crée pas non plus son répertoire par défaut $HOME/.v_sim. Personnellement je trouve ça ennuyeux un logiciel qui crée des répertoires partout. Mais en même temps si les utilisateurs préfèrent autrement, je peux le modifier facilement ;)

Dans le répertoire de travail (Current Working Directory), il cherche au démarrage un fichier v_sim.par, dans ce fichier tu pourras virer la coloration saumon en changeant la valeur de la clef 'config_skin' par 'None'. Sinon, créer à la main un répertoire $HOME/.v_sim et met ce fichier dedans. Tu peux en générer un en cliquant sur le bouton "ressources" dans le panneau de commande (en bas à gauche).

Pour les fichiers en entrée, le format XYZ est un format classique en chimie, tu mets des lignes contenant 'Nom_élément pos_x pos_y pos_z' et hop ça marche. En ce moment, je cherche à intégrer OpenBabel qui est un projet qui permet de lire tout un tas de formats habituels.

Enfin, pour l'hébergement, le projet est libre, mais toujours assez lié au CEA. J'attends de voir ce qu'ils vont proposer comme hébergement. C'est surtout assez politique de laisser l'hébergement au CEA pour le moment. Toutefois, si le besoin de mailing-list et aussi de bug report devient vraiment urgent (pour l'instant, le nombre d'utilisateurs est assez faible) je migrerai le développement vers un hébergement communautaire.

Bon, je m'arrête, mais c'est toujours interssant (enfin j'espère) de donner des infos ;)

Ok, merci, je regarde ce script et ça devrait apporter quelque solution à mon problème.

M'enfin, il reste que mes recherches Google étaient toutes trop particulières avec des mots clefs comme netcdf-3, ...

Sinon, je me demande si les autotools ne pourrait pas gérer cela tous seuls sans avoir à écrire des scripts m4 particuliers pour chaque bibliothèque qu'on souhaite utiliser et qui pourrait être dans des répertoires différents de /usr/include et autre.

Vérifie que ta locale LC_NUMERIC n'est pas "fr" ou apparentée pour laquelle le séparateur décimal est une virgule et non un point.

Dans ce cas, tu peux utiliser setlocale() de <locale.h> si ton programme est en C pour mettre LC_NUMERIC à C par exemple.

Eh ouais, les goûts et les couleurs étant des sujets de trolls interminables, il y a bien sûr une option dans le fichier de configuration (v_sim.par) qui sert à ne pas charger le fichier de ressources GTK (v_sim.rc) pour avoir le rendu de base de GTK comme pour les autres logiciels, ou bien qui sert aussi à en spécifier un autre.

Si ça râle à cause d'une initialisation de GLX, c'est peut-être que les drivers OpenGl n'ont pas été installés sur ta machine. Par exemple, est-ce que quand tu tapes glxgears tu vois une petite fenêtre avec des engrenages qui tournent? Si ce n'est pas le cas, tu dois installer OpenGl en utilisant les drivers fournis par le constructeur de ta carte vidéo (souvent des pilotes accélérés) ou par ta distribution (qui peuvent être accélérés ou non selon la marque de ta carte). Pour une implémentation logiciel d'OpenGl, il faut installer libmesaglu et libmesagl. Note toutefois que les noms ont peut-être bien changés avec le passage à Xorg.

Si tu as vu les petits engrenages, c'est qu'il y a (encore?) un bug dans le codage de la partie qui appelle OpenGl dans V_Sim, pfouuu....

Normalement, ça fonctionne. Nous l'utilisons ici sur machines alpha sous Linux. Ça marche comme sur Intel, même si la compilation sur 64bits a permis de corriger quelques petites erreurs par-ci par-là.

Ok, merci beaucoup à vous, j'avais complètement oublié le flag 'b' quand on ouvre un fichier. Donc ça marche (d'autant mieux que j'écrivais déjà des unsigned char et non des char).

Pour afficher une image perso avec GTK (j'entends par là, dont on possède la couleur pour chaque pixel en mémoire) et suffit de creer une image avec gdk_image_new(...) (cf http://developer.gnome.org/doc/API/2.0/gdk/gdk-Images.html(...) pour le GdkVisual, il suffit de récupérer celui par défaut avec gdk_visual_get_system() ), puis de la remplir pixel par pixel avec des appels à gdk_image_put_pixel(...).

Ensuite l'objet GdkImage ainsi créé est simplement affiché dans un widget GtkImage (cf. http://developer.gnome.org/doc/API/2.0/gtk/GtkImage.html(...) ) grâce à la fonction gtk_image_set_from_image(...).

Et sinon, oui, GTK gère le Cliquer-déposer, mais je n'ai jamais utilisé, la documentation se trouve là par contre : http://developer.gnome.org/doc/API/2.0/gtk/gtk-Drag-and-Drop.html(...) mais pour ça je ne peux pas t'aider bien plus, désolé...

Le système de fichiers vfat ne permet pas de créer de liens (commande ln), c'est bien possible que Gnome râle à cause de ça.

Une solution consisterait à avoir un /home en ext3/reiserfs/... avec dedans un répertoire documentsPersonnels qui est un lien vers un point de montage vfat. Comme ça tout le monde est content, Linux et ses amis peuvent créer pleins de répertoire .monApplication/xxx dans /home/utilisateurToto avec des liens dedans et l'utilisateur Toto peut quand même avoir une zone pour ses fichiers facilement lisible entre Linux et Windows.

C'est aussi la conclusion à laquelle était arrivé un ami après avoir constaté le même problème que toi (sur un portable sous windows, les parties rendue par WMP ne sortaient pas sur le retro).

Pour contourner le problème tout en gardant l'accélération de Xv, il avait suffi de basculer l'affichage du portable sur sortie-externe seule (touches fn+Fxx). Cependant, je soupçonne ceci d'être dépendant du matériel utilisé (et plus exactement de comment est branchée la sortie par rapport à la mémoire de la carte vidéo) donc de ne pas fonctionner partout.

Par contre la première solution (passer à X11 et perdre l'accélération matérielle) devrait marcher tout le temps.

Bonjour,

Bon pour avoir de l'openGL qui marche sous linux il y a plusieurs possibilités (arrêtez moi si je me trompe) :
- la première qui marche partout, est d'utiliser un rendu logiciel (c'est X et le CPU qui se paluchent le boulot). Pour cela il faut utiliser les paquets « mesa ». En général ils sont installés par défaut par ta distribution, mais sinon un petit coup de urpmi, apt-get ou ton logiciel préféré de gestion des paquets devrait te permettre de récupérer tout ça. Une fois que ces paquets sont installés il faut dire à X d'utiliser une extension permettant au serveur X et à OpenGL de dialoguer. Cette extension s'appelle glx il faut rajouter la ligne adéquate dans ton XF86Config-4 (qui est souvent déjà là) :

Section "Module"

        Load  "dbe"

        Load  "extmod"

        Load  "fbdevhw"

        Load  "glx"               # c'est cette ligne-ci

        Load  "record"

        Load  "freetype"

        Load  "type1"

EndSection

- une autre solution consiste à utiliser le processeur de la carte graphique pour faire le boulot (c'est son job après tout!). Et là ça devient un peu plus compliqué. Si ta carte est une NVidia, va sur leur site, télécharge le driver et laisse toi guider par leur installateur. Si tu as une ATI ça dépend du modèle mais en générale et aussi pour certaine autre carte le DRI est une bonne solution (il faut charger l'extension X dri et charger le module du noyau correspondant à ta carte graphique).

Finalement pour tester si tu as opengl d'installé, le plus simple est de lancer le programme glxgears qui est un petit programme de démo. Une façon plus style est de taper glxinfo et de regarder ce que ça affiche.

Dans tous les cas il faut relancer X pour voir les modifications s'appliquer.

Par ailleurs n'ai pas peur de modifier le fichier XF86Config-4, ce n'est pas dangeureux à partir du moment où tu en as fais une copie. Si X ne veut plus démarrer suite à une modification malencontreuse restaure ta sauvegarde et zou c'est reparti (en console la commande pour copier un fichier est « cp », excuse moi si je t'annonce des banalités, hein!).

En faisant man proc on a de plus amples informations sur ce que contiennent comme valeurs les fichiers dans /proc/id, en particulier pour le fichier stat. Donc la mémoire utilisée se trouve dans ce fichier, que se soit la memoire totale nécessaire au programme et à ses fils où la mémoire spécifique... Une autre documentation détaillée est donnée dans le répertoire des sources du noyau dans Documentation/filesystem/proc.txt. Alors bien sûr pour avoir le pourcentage de mémoire il va te falloir récupérer la mémoire totale (aussi dans /proc) et faire une petite division, mais ça c'est la partie facile ;)

Pour la charge processeur, je n'ai pas de réponse simple, voir pas de réponse du tout, je ne comprends pas ce que contient le fichier /proc/id/cpu et la documentation dont je t'ai parlé n'est pas très détaillée à ce sujet.

Bonjour,

Je m'étais fait un petit truc exactement comme tu cherches pour le mettre sur mon compte chez free pour pouvoir échanger des fichiers avec des amis. Le répertoire est protégé par htaccess donc je ne peux pas te montrer en « vrai », mais tu trouveras une sopie d'écran sur http://dcaliste.free.fr/linux/upload.png(...)

Ça affiche donc le contenu d'un répertoire donné avec un log à côté contenant les échanges effectués. on peut supprimer, upload ou downloader les fichiers présents.

Le code PHP est présent sur http://dcaliste.free.fr/linux/upload.tar.bz2(...) il n'y a pas de license parce que c'est bidon et j'autorise qui veut bien à le réutiliser sans avoir besoin de me reciter.

C'est adapté pour la charte graphique de mes quelques pages donc tu devras l'adapter à ton goût.

Il me semble que par défaut dans Mandrake, quand il y a une carte réseau sur la machine, il cherche un serveur DHCP pour fournir la connexion. Donc si la carte eth0 n'est relié à rien ça peut mettre un petit peu de temps avant de mettre Échec en rouge au démarrage (qui correspond à l'échec de connexion par DHCP).

Si la connexion wifi te convient, la solution de fred point de désactiver eth0 dans drakconf est une bonne idée.

Bonjour,

Je ne suis pas certain mais la puce de C-Media Electronics ressemble fortement à une puce généralement présente sur les cartes sons intégrées à la carte mère. Voici l'hypothèse à laquelle je pense :
- tu avais une carte son intégrée et tu as acheté une nouvelle carte son que tu as inséré dans ta machine.
Mais souvent (en tout cas sur toutes les cartes mères un peu anciennes maintenant) il faut bouger un cavalier sur la carte pour désactiver la carte son intégrée et tu as oublié ce détail.
Si c'est effectivement le problème, jete un coup d'oeil à la doc de ta carte mère pour voir où se trouve ce cavalier ou si c'est désactivable dans le BIOS. Normalement tout est écrit dans la doc.

Bien j'espère que ce commentaire t'auras été d'une quelconque utilité.