Fabien PRORIOL a écrit 121 commentaires

Un peu rapide quand même; l'IHM est de plus en plus libre, ce qui ne l'est pas, c'est les appli "system" comme les SMS, les Contact, la liste d'appel…
Mais c'est en train de changer, depuis les accords avec les russes et les asiatiques, une des conditions est d'avoir un systeme libre, donc, ça risque de le devenir de plus en plus… reste un autre points non libre: dalvik (pour executer des applications android), mais la, ça ne dépend pas d'eux… a suivre…

Je ne vois pas le rapport.
C'est comme si tu disais que le problème serait résolu par autotools, Yocto n'est qu'un environnement pour concevoir une distribution (et qui est
globalement orientée pour les systèmes embarqués).

Non, Yocto n'est pas l'équivalent des autotools !!!
cmake, qmake oui, Yocto, c'est l'equivalent de scratchbox ou de buildroot.

Exemple simple; y'a 2 mois, je me suis dis, sur Jolla ce qu'il me manque c'est un vrai lecteur video; pour le moment, j'utilise VLC pour android dessus, car le player natif est, ben, franchement, inutilisable…

Je me suis dis, ça doit être assez simple, VLC (sur la branche master) fonctionne pour Wayland, il existe une interface Qt, bref, tout ce qu'a Jolla…
Je me suis donc lancer dans la création d'un package VLC pour Mer Project.
Et me voici dans Scratchbox…… ….. …. …. 3 jours plus tard, aucune avancé, je rame, il manque des bouts de tout les coté, packager quelque chose est compliqué…. le tester, presque autant….

Sous Yocto, ben, je trouve un layer avec VLC (et oui ça existe déjà), je me met dans mon environement et lance 'bitbake vlc', et un moment plus tard, j'ai déjà le rpm/deb/ipk (au choix)… En plus, ça passe tout un tas de sanity check pour moi !!!!
Si la recette n'existe pas, elle est facile a écrire.
La recette actuel fait 106 ligne, et encore, uniquement parsqu'elle est "complete" niveau PACKAGECONFIG, c'est a dire qu'elle permet d'activé ou non n'importe quel option du configure selon le resultat souhaité.

De plus, c'est très facile a partagé sur un layer sur GitHub, et facile a intégrer au projet de départ…. bref, c'est "simple" de contribuer quand on connait Yocto, de plus Yocto, c'est de plus en plus utilisé dans l'industrie.
A l'inverse, Scratchbox n'est utilisé que pour Mer et ses dérivés; c'est inutilisable, et surtout, ça ne sert a rien de se former la dessus, puisque a part Mer/Jolla, on ne le retrouve null part ailleurs.

On peut avoir un système libre sur téléphone qui fonctionne aussi bien que ceux sur PC. Pour cela il ne faut pas changer la manière de faire la
partie applicative, mais de changer la base du système. Pour que tu puisses utiliser une Fedora ou Debian adaptés pour téléphone (avec les
applications qui vont bien), c'est surtout le noyau et le chargeur de démarrage qu'il faut changer pour incorporer de quoi exploiter les composants
de la carte. Après en espace utilisateur tu peux faire ce que tu veux (du Android, du Plasma Mobile, du truc machin) et cela fonctionnera sans avoir
besoin d'uniformiser la plateforme logicielle (ce qui ne peut fonctionner de part la nature du LL).

Non, pas vraiment, en embarqué, tu a besoin de configurer certain paquet différemment; par exemple, si tu utilise NetworkManager pour gérer ton réseau (pourquoi pas), tu ne souhaite pas forcement activer et "tirer les dépendances" de polkit; et pour ça tu dois donc appeler le configure sans lui demander polkit, et recompiler, ce que permet facilement Yocto; sous debian, tu dois repackager le package, voir les dépendance qui l'utilise…
Yocto est fait pour ça justement. Et c'est "simple" a utiliser une fois dedans (même si c'est assez technique pour y rentrer dedans, c'est presque plus simple que d'apprendre a packager un paquet debian).

Un des gros point problèmatique de tout ces "OS Libre", c'est qu'il ne peux y avoir de synergie commune, chacun refait son truc dans son coin.
GNU/Linux, est le logiciel libre en générale fonctionne parsqu'il est composé de plein de briques "standardisé, interchangeable".

Aujourd'hui, si maemo/meego/mer rend une participation difficile pour un libriste, c'est qu'il est basé sur scratchbox, est que, c'est loin d'être évident.
FirefoxOS utilisait sont propre système, et chaqu'un refaisait sont truc a sa sauce…

Je pense que si on souhaite avoir une chance de voir avancé ce genre d'initiative, il faudrait basé tout les projets sur Yocto (OpenEmbedded)…
L'avantage, c'est que c'est standard, poussé par l'industrie et la FSF, suporté par Xilinx, Freescale, Qualcomm…, ça permet de faire, au choix, du xorg, du wayland, sur du systemd, ou du sysv… on peut passer de l'un a l'autre facilement, et chacun peu tester selon sont besoin facilement.
Ensuite, c'est de la cross compilation pure, c'est basé sur Git, et le découpage en Layer permet de proposer sont travail au autre sans avoir forcement 1 seul projet central.

Pour ce qui est de la partit graphique, le projet de KDE (plasma mobile) me semble prometteur, et basé sur des techno (Qt5 et KF5) qui sont simple a utiliser, et habituel a beaucoup de linuxien (contrairement au truc genre xulrunner), tout en ettant performant (même si les EFL (Tizen) sont plus adapté pour le petit embarqué (SmartWatch), mais on parle de téléphone la… avec des CPU de + de 1Ghz, et des GB de ram…).

Ensuite, cette platforme permet d'utiliser par exemple une rasberry pour le dévellopement de la partie "non GSM", avoir une solution de platforme de dévellopement low cost est aussi un point cruciale.
Ne pas être "trop" dépendant du HardWare est indispensable (c'est le principale problème de projet comme OpenMoko).

Je voulais faire un Layer/Portage de Plasma Mobile sur Yocto, malheureusement, pour le moment mon temps libre ne le permet pas, mais comme mon travail professionnel c'est justement du Yocto, et que je connais bien Qt, il faura que je trouve du temps…

En attendant, je suis toujours sur Jolla (j'ai eu premier, puis la tablet, puis le JollaC aujourd'hui en tant que developpeur) depuis le début du projet (et avant, j'ai eu uniquement en smartphone un N900 et un N9), donc, autant dire que ce projet me tiens a coeur, et que je le supporte plainement… mais cette année, je vais lacher un peu et acheter je pense un S8 a sa sortie je pense… Pas de hardware digne de ce non, un OS qui n'avance malheureusement pas assez vite… je garderais un oeil dessus, mais pour le moment, je craque…

A suivre, en esperant des jours meilleurs…

Simplement le cas des machines virtuels.
Tu as un serveur de machine VMWare par exemple, que tu accède par RDC (environnent professionnel imposé par l'entreprise), et tu as besoin d’accéder a une clé USB (de licence par exemple, ou simplement une clé ou un disque USB), tu la branche alors sur ton PC, tu exporte sur IP, et tu y accède sur ta machine virtuel.

Une Wandboard (IMX6 avec donc du SATA) et un disque SSD SATA devrait mois consommer…
Tout dépend de la quantité d'espace de stockage que tu souhaite…

Perso, sur mes NAS/Serveur… je ne stock que les données "vivantes", dont je sais que je risque d'en avoir besoin "rapidement". Cela ne représente que quelque centaine de Go maximum et donc, un SSD 256Go suffit.

Pour le stockage de masse (archives, quelque To), j'utilise dans ce cas des Disques SATA 3.5 que j'utilise comme des cartouches dans un rack sans tiroir genre ICY BOX IB-170SK-B qui peut d'ailleurs aussi se relier a la wandboard, du coup, le disque ne consomme que lorsqu'il est présent.
Une regle udev pour le montage automatique, un script pour le démontage et le tour est joué.

Merci d'expliquer…
Sur le lien que tu pointe, je ne vois aucun lien avec ReacOS

J’espère sincèrement qu’ils vont remonté la pente.
Je soutiens cet OS alternatif depuis le Nokia N900, en passant par le N9, et aujourd’hui le Jolla Phone et Tablet…

Peut être est-t-il intéressant de faire un petit bilan de ce qui aurais pu être meilleur.

Déjà, ne pas jouer la carte du 100% Open Source est une erreur.
Finalement, en étant 100% libre est communautaire, il auraient surement drainé plus de passionnés, plus de contributeur, notamment sur leur applications aujourd’hui insuffisante comme les mail ou les contacts. C’est vraiment la dessus qu’ils auraient pu faire la différence… et on vois que pour certain investisseur, justement, le 90% libre joue en leur défaveurs (Yota et les Russes par exemple).

Le choix plus technique de poursuivre avec Scratchbox2, en effet, aujourd’hui, l’usage de machine virtuel pour gérer le SDK, c’est une usine a gaz, et c’est a mon avis contre productif.
J’ai essayer de porter VLC pour la tablet, mais franchement, la lourdeur de ce système m’a découragé.
Aujourd’hui, des systèmes comme Yocto/OpenEmbedded aurait apporté énormément. Déjà, parsque la base de l’OS sous ce système est déjà prêt (Wayland, Systemd, Qt5….), il ne manquerait qu’a porter les briques pure Jolla. Ensuite, c’est beaucoup plus simple de participer au projet (collaboration basé sur Git est vraiment ouvert), c’est soutenu par beaucoup d’industriels, c’est très simple a utiliser, et franchement, c’est moins l’usine a Gaz que Mer, c’est mieux documenter, et l’évolution et le suivie est plus rapide.
Mer, ils sont les seuls a le déveloper et réelement a l’utiliser, du coup, en plus de dévelloper le code Sailfish, ils doivent aussi gérer l’update des differents packages (y’a qu’a voir le travail et le temps qu’ils ont mis pour gstreamer!!!), bref, plein de temps passer a faire ce qu’il auraient pu utiliser simplement sous Yocto.

Espéreront qu’ils relèvent la tête rapidement, et que tout leurs travail ne soit pas perdu.

Heu… a ce niveau, j'ai bien plus confiance en SailfishOS qu'en un Android made in Google ou un iOS de Apple !!!

En effet, le SDK sailfish viens avec un émulateur complet (sous virtualbox), pour la tablette (x86) et pour le téléphone (armv7).
Mais c'est sure, il faut quand même avoir le temps pour le faire… Après, si votre projet est open source, je pourrais y jeter un oeil pour le portage, mais pour le moment, au moins jusqu'en Aout, je suis très pris dans une construction de maison domotique…

De toute façon, au vu des technologies que vous prévoyez d'utiliser, faire une appli SailfishOS native me semble pas très compliqué (sur openrepo par exemple)… justement, python/linux et tout ça, c'est sur Sailfish que c'est le plus facile a faire…
Après, le problème, c'est plus les règle en vigueur pour la déployer sur le store jolla qui pour le moment sont contraignante (1 seul exécutable par projet par exemple).
En plus, si le projet Android est open source, y'aura moyen de contribuer au portage…

Je pense que ce qu'il voulait dire, c'est que tu synchronise les fichiers crypté de encfs, donc, si ton serveur est compromis (et pas seulement ta connexion ssh) tes données reste protégé.
Il ne parle pas du cas ou ton PC lui même est compromis.

Coté Windows 8.1 qui fait bien son taff… y'a quand même des limites…
Pas plus tard que hier, sur mon portable qui contient une Arch Linux, mais aussi un Windows d'origine installer par asus, sans rien d'ajouter a part mon logiciel ETS5 (pour KNX, j'utilise windows 1 fois tout les 3 mois juste pour ça), je dois redémarrer sous windows, et la y'a des mise a jour a faire… pas de soucis, vu que depuis 3 mois je l'ai pas lancé, je me dis, c'est normal… du coup je lance… 1,4 Go de téléchargement de mise a jour !!!!!
Rien que pour windows bien-sur !!!

Bon, je suis étonné, mais bon, plus personne n'a de Modem 56k, je continue, 1h plus tard il me dis de rebooté, je reboot… installation des fonctionnalité… 10% … 20% … 1/4 d'heure après 70%…. 30 min plus tard 100% (ouf on y est presque)… 1/4 d'heure plus tard 100%…. 30 min après, toujours 100%………… 2h plus tard tj 100%.
Bon, c'est sur, la c'est bloqué, je redémarre, ça se retrouve a 100%, mais toujours bloqué…
Après 2h de recherche sur internet, c'est un problème courant, mais AUCUNE solution, du coup je fait une restauration du system, qui dure 2h, (il est déjà tard, et j'ai rien fait sur mon installation KNX !!!).

Bref, chaque fois que j'ai besoin de ce truc de windaube, je me demande toujours comment les gens le supporte…

Pour ce qui est de KDE et de ton explication… le pb de KDE 4 dans c'est début, a surtout été la faute des distributions…
l'équipe de KDE était très claire:
4.0: Uniquement une démos pour que les partit de KDE puisse être développé
4.1: Pour les développeurs de plasmoid & co pour qu'il puisse faire les développement
4.3: La première version pour que les utilisateurs puisse tester (mais encore expérimental)
4.4: LA version grand publique

Malheureusement, a partir de la 4.0 les distributions se sont jeté dessus (argument marketing, nous on a KDE 4 avant les autre…).
Du coup des rapports de bug par centaines d'utilisateurs qui criaient de partout que KDE c'était de la merde…
Les développeurs ont été totalement déborder en devant faire face au bug "urgent" pour les utilisateurs, mais qui du coup, on malheureusement fait faire des choix dans la panique…
Résultat, il a fallut attendre un KDE 4.6 pour avoir une stabilité digne de ce nom, et la réputation de KDE à été taché, des dev découragé… mais finalement, KDE 4 est un bon projet, Qt4 apporte de bonne chose par rapport a Qt3 et les dév ont fait du bon boulot, par contre, kubuntu and co, c'est vraiment des marketeu qui ont semé une pagaille pas possible !!!

Aujourd'hui arrive Plasma 5 (et oui le nom de KDE 5), il apporte pas mal de bonne chose, Qt 5 est plus léger que le 4, baloo est plus rapide que stigri… des bonnes choses… sauf, je te rejoint sur 1 point, pourquoi il a fallut s'inspiré de ce thème ignoble de Win 8.1 ?
C'est quoi cette mode au truc tout plat de partout, c'est horrible, on a l'impression de revenir 10 ans en arrière !!!
On est pas obligé de suivre les modes a la c*n de microsoft !!!
Je prédit qu'avec la régression des interfaces en cours, la prochaine mode sera au interface noir et blanc!!!
Par contre, (a cause de Qt5 et des choix commerciaux de digia), il faut une carte graphique 3D, pars que pour faire plus plat que avant, il faut maintenant absolument de la 3D !!!! absurde non ?
Bon on peut toujours remettre le thème Oxygène, mais pour le moment, il est buggué, et ne change pas totalement les déco de fenêtre de partout.
J’espère que c'est juste un problème de maturité et que dans quelque version, on retrouvera un thème Oxygène ressemelant a celui de KDE 4, et avec des icônes Oxygène aussi.

Enfin, je préfère quand même ça a ce Windows, et si j'arrivais a faire tourné ce KNX sous linux, je m'en passerais volontiers !!!

Ok, en gros, y'a pas de choix simple; en effet, j'ai vu:

jabberd14 (C) (j'ai utiliser assez longtemps, mais semble abandonné depuis 2007!!!)
jabberd2 (C++), qui se veux être une ré-écriture, mais encore incomplet, et surtout, pas dans debian
ejabberd (erlang), en effet celui la me convient pour le moment, je l'ai même couplé avec le LDAP de Kolab, et ça fonctionne plutôt bien, mais c'est du erlang… et du coup, j'y comprend rien, même les log ou les fichiers de config sont tordu…

Après étant allergique au Java, j'ai pas testé OpenFire.
Prosody, jamais testé encore… je ne suis pas forcement fan de Lua, mais pas allergique non plus…

Bonjour, et merci pour tes articles…

Personnellement, j'utilise mon propre serveur, mais une question me reviens toujours…

Quel est aujourd'hui le meilleur serveur ? Je veux dire par la, avec un maximum d'XEP d’implémenté par exemple.

Je pensais après différente lecture a jabberd2, mais bizarrement, il n'existe pas sous Debian… pourquoi ???
Je cherche souvent a éviter les truc usine a gaz (en Java par exemple), et privilégie les serveur écrit en C++ ou autre langage compilé, mais bon, pour le moment, du coup, j'ai mis ejaberd, mais je ne sais pas vraiment si c'est un bon choix…
A terme, j'aimerais proposer des truc comme video-conference, voir SaT, mais je ne sais pas si c'est possible avec ce serveur…

Encore Merci

Plutôt que Teensy, pensez a regarder les ST Nucleo…
Pour une dizaine d'euro on a du 32bit jusqu'a 84MHz (pour les F4), autour de 50 GPIOs, possibilité d'avoir environ 20 PWM sur les F401, et 16 voix sur un ADC 16bit de bonne qualité… y'a même un DAC sur certaine…
Je quoi qu'il y aurait de quoi faire un jolie petit oscillo avec
De quoi mettre les Arduino et Teensy au placard…

J'utilisent XMPP depuis des années, j'ai mon propre serveur, mais j'ai encore de grosse lacune dans la compréhension de ce protocole au delà du simple MSN.

Je suis sen train de construire une maison bioclimatique avec beaucoup de domotique (avec entre autre du KNX, du DALI et beaucoup de truc fait main, avec des STM32 (un peu comme arduino) et un serveur Wandboard), et je me demande si ce protocole pourait pas être une solution au dessus de KNX pour la communication de mes différents objet…

Après, peut être que XMPP est un peu lourd a implémenter sur un microcontroleur, mais les STM32 sont quand même puissant… alors a voir…

Si des personnes on joué avec XMPP en embarqué, je suis preneur…

Je m'auto complète, malheureusement, je ne peux pas/plus modifier/corrigé mon commentaire…

Finalement, cette mode de sandboxing revient a créer sous linux la même chose qui existe sous Mac ou Windows… En gros, chaque logiciel est distribué avec ses propres libraries plutôt que de packager tout séparément…

Finalement, on devrait créer sous Linux le dossier /Program Files// non ?

Certe ça simplifie le packaging et la distribution, mais on perd un gros morceau de l’intérêt des distributions Linux par rapport aux autres OS…

Finalement, le schéma est un peu triste…

• Y'a plein de distributions, c'est géniale pour la diversité…
• C'est compliqué a packager les logiciels…
• Ben trouvons un pseudo-standard, mettons nous d'accord pour rendre plus générique les choses entre les distribution, on a besoin de standard…
• A oui mais les distributions sont pas d'accord, et puis sa casse la diversité…
• Pas grave, finalement, mettons tout dans des sandboxes comme sa plus de problème…

En exagérant, finalement, dans les sandbox on devrait mettre la libc et le kernel linux et le lancer sous qemu non ???

Finalement, cette mode de sandboxing revient a créer sous linux la même chose qui existe sous Mac ou Windows…

Certe ça simplifi le packaging et la distribution, mais on perd un gros morceau de l’intérêt des distributions Linux par rapport aux autres OS…

Illumos, c'est un autre noyau monolitique… donc, par rapport a Linux qui est déjà fonctionnel et qui marche très bien, ben, pas trop d'avantage.
Hurd en revanche est un noyau de nouvelle génération, mais en effet, le mettre au point est plus long et dure que prévu…

Surtout, la différence de prix papier vs numérique est vraiment faible en France…
Chez nous, il n'y a quasi aucune différence de prix entre format de poche et numérique.

Au US, c'est pas la même situation, sur Amazone, les livre numérique sont presque 3 fois moins cher que le papier; dans ce cas le modèle est viable, chez nous, c'est une arnaque…

Mon seul regret c'est que ODF ne permet pas encore vraiment l’interopérabilité…
Je jongle souvent entre Caligra et LibreOffice, et c'est souvent la catastrophe…

Finalement, ceux qui n'aime pas systemd peuvent se mettre a Gentoo, ça leur ferait en plus un grand bien, quelque part de marché en plus…

Surtout que Gentoo et vraiment une très bonne distribution; bien que souvent mis de coté…

Pour me petite graine, perso, j'utilise toujours les sous-modules git pour des projets Yocto, la ou beaucoup utilisent "repo".

Je n'ai toujours pas trouvé l'avantage de repo sur submodule, a par un autre outils a installer et maîtriser en plus de Git…

Pour le défaut de repo vis a vis des branches, c'est le même problème sous git submodule…
Dommage…

Simplement parsque aujourd'hui, les sources de udev se retrouvent dans systemd, qu'il faut de plus en plus de travail pour récupérer udev sans systemd (demande au dev de Gentoo ce qu'ils en pensent…)

L'intrication des projets n'a jamais été une bonne solution, l'utilisation des uns par les autre en est une, l'inter-opérabilité et justement la modularité en est une autre.
Le problème de systemd, c'est de ne pas chercher a rendre une solution inter-opérable, mais d'imposer des choix et des intrications à une vitesse ou personne ne peux réfléchir correctement à une bonne solution inter-opérable.

Pourtant, l'inter-opérabilité était ce qui faisait la force de Linux.

Les reproche fait sur systemd ne sont pas d'ordre technique, ni de qualité de codage, mais plutôt pour sont coté politique qui met [volontairement] toute les autres solutions impossible à maintenir sans une ressource (nombre de développeur) qui augmenterait exponentiellement…

Moderniser l'init est une bonne chose, mais a condition de ne pas tuer ce qui à fait de Linux ce qu'il est aujourd'hui…

Personnellement, j'utilise Kolab, certe c'est pas 100% français, mais c'est libre, ça utilise que des briques standard (cyrus, postfix…), et ça répond a tout les besoins cité ci-dessus…
On trouve même le moyen de le couplé avec un serveur XMPP…