Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.
Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.
Si tu ne vois pas la différence, on peut arrêter là la discussion.
Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
Par contre:
- les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
- l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.
Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.
Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.
Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.
Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
* la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
* la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.
Je vais finir par une conclusion à la Zenitram:
C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?
C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.
Le vieil init est encore officiellement supporté par la distro, pour rappel.
Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.
Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.
Ce sont juste des doutes et des interrogations. Je ne suis pas devin, donc effectivement nous verrons bien. Mais il est essentiel de garder un œil critique sur ce composant qui est aujourd'hui au cœur de notre OS.
Hé bien tous ces trucs viennent avec systemd mais ne font pas partie du binaire systemd, tout comme Linux est livré avec tout en tas de pilotes qui ne sont que des modules.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
Je comprends mieux. Pour moi, le sujet du journal n'est pas Linux, mais une migration vers Linux. Le prestataire qui aide à le faire est pour moi une information importante, car elle explique le "pourquoi" et le "comment" de la migration (support et conseil pour la migration du client, etc).
C'est un peu comme faire un journal "j'ai pas réussi à installer Linux, c'était trop difficile". On n'est pas très avancés si on ne sait même pas quels choix ont été faits pour arriver à cet échec.
Et ce n'est pas plus mal (c'est "Linux" qui est important, pas le prestataire)
Ce à quoi j'allais répondre que je n'étais pas d'accord (support, certifs, tout ça c'est le prestataire qui le fournit, pas "Linux"), mais apparemment toi non plus… Que voulais-tu donc dire ?
Tout le problème réside dans la façon dont est stockée ta chaîne de caractères dans le fichier source, qui est ensuite compilé.
Pour peu que ton "é" soit encodé sur 2 octets, t[1] sera insuffisant pour l'afficher correctement. Bien sûr, en supposant que ton affichage de terminal soit adapté à ce printf…
Il faut remettre les choses dans leur contexte: le TouchPad est le premier essai de webOS sur un format tablette. L'OS n'a quasiment jamais été mis à jour, à part par la communauté dans la mesure du possible.
Le manque d'applications s'explique lui aussi par la durée de vie très courte de ce produit. Certaines initiatives ont un peu amélioré les choses (LunaCE, Preware, système de patchs…) mais l'utilisateur lambda non bidouilleur a certainement dû rester sur sa faim.
Et une bonne raison de ne pas libérer une pièce maîtresse, une!
Le portage, dans la plupart des cas, ne nécessiterait même pas de recompiler les binaires de l'UI. C'était le cas aussi pour le portage sur le N9, qui pourtant n'est même pas un Android. La pièce maîtresse est ici libhybris, un projet initié par un employé de Jolla… en GPL.
Est-ce que tu crois sérieusement que ça inciterait des constructeurs à lancer un produit à base de Sailfish sans aucune coopération avec Jolla??
Non, je ne le crois même pas du tout. Donc du coup, la bonne raison du paragraphe précédent, on en fait quoi ?
Oui ben ils tournent ça comme ils veulent, mais moi quand je décide que "le plus pratique/faisable pour mon UI, c'est du proprio", j'assume et je dis que j'ai préféré le proprio pour mon UI. Ou alors faudra m'expliquer ce que "préférer" veut dire.
La différence, elle est entre "préférer faire du proprio pour ce cas particulier" et "préférer faire du proprio dans tous les cas".
Libérer complètement le code, c'est se retrouver dans la position d'Android.
Ou pas. Jolla n'est pas Google. Ne pas libérer le code apporte aussi le risque que la communauté se désintéresse d'eux, et vu la taille de leur structure c'est à prendre en compte.
Tu bosses pour leur département marketing??
Non, j'essaie juste de montrer qu'un procès d'intention, pour une entreprise aussi jeune, est injustifié. Je n'ai jamais dit "Ils libèreront leur code, c'est sûr !", par contre, toi tu affirmes que l'UI "ne risque pas d'être libérée pour cause de business!". On n'en sait rien, c'est tout.
Oui, comment faire pour réguler tout ça de façon intelligente, en gardant un design cohérent et sans introduire de bugs ? Il faudra certainement des infrastructures et des personnes en plus, comment on finance tout ça ?
Ils ont l'audace de réfléchir à l'ensemble du tableau avant d'agir. J'ai l'impression que c'est presque un crime, par ici.
Si Jolla peut être installé facilement sur n'importe quel terminal
Je t'invite à te renseigner justement sur leur architecture. Avec libhybris, tu peux "assez facilement" aller conquérir d'autres terminaux Android. Ils ont fait une rapide démo sur un Nexus 7, récemment.
Il n'est pas dit encore quel chemin ils prendront pour ce genre de portage: vendre l'OS ou le proposer gratuitement.
Et on en vient à la conclusion: oui, pour Jolla, une UI proprio, c'est mieux!
Ça n'enlève rien aux qualités de l'OS ni de la solution, mais dire que Jolla préfère le Libre, c'est une blague!!
Non, pour Jolla, le mieux, c'est le plus pratique/faisable. Jolla ne préfère ni le libre (où ai-je dit ça ?), ni le proprio. Ils sont pragmatiques.
Par exemple, libérer le code source et ne pas avoir assez de ressources ensuite pour gérer les contributions risque de mécontenter les contributeurs. SailfishOS est encore en "Beta": à une phase aussi précoce, sortir un produit commercial avec de possibles multiples forks existants risque aussi de donner une image confuse de ce qui est proposé, et de rebuter des partenaires. Le faire plus tard, lorsque le produit est stabilisé et un peu mieux connu tel quel, peut avoir du sens. Ou pas.
La seule chose que tu arrives à dire, c'est qu'ils font comme Google
Non, c'est toi qui compares toujours avec Google et Android. Tu compares les contributions d'un mastodonte avec celles d'une PME de 80 personnes. Tu compares le "niveau de libritude" (je suis surpris, venant de toi) d'Android qui se dit libre (mais ne l'est pas) et de Sailfish qui n'a pas cette prétention.
Toi, si carré sur la définition de "logiciel libre", vient nous dire maintenant que "open" c'est forcément "open source"… Non, ils sont "ouverts" au sens premier du terme: ils sont à l'écoute des communautés avec qui ils sont en contact. Ils surfent sur la collaboration entre communautés. Pas sur le logiciel libre, comme tu te plais à le répéter.
L'un n'est pas meilleur que l'autre au niveau libre, les deux participent à l'écosystème libre quand ça les arrange seulement
Cite moi une seule entreprise qui participe à l'écosystème libre alors que ça ne les arrange pas… Tu es le seul dans cette discussion à chercher à savoir qui est le plus beau. Les deux participent. Et ?
Ce n'est pas que de la prétention… Ils ont interagit fortement avec la communauté du libre. Ils ont fait avancer les choses sur plusieurs projets libres (Qt, QtWayland, Maliit, libhybris…). Rien que ça est déjà un bon point, même si bien sûr au final leur objectif est de vendre un téléphone.
Il est bien possible que l'écosystème qui se formera autour de ce nouvel OS fasse la part belle aux LL, comme sur le N900.
Peut-être ai-je tout faux, bien sûr. Mais jusqu'à maintenant, il n'y a pas eu de double langage ou de langue de bois. Il y a un vrai dialogue avec les utilisateurs.
L'intérêt coté LL n'est pas dans l'UI proprio, bien sûr. L'intérêt est dans toutes les briques libres qui ont dues être utilisées et améliorées pour faire tourner cette UI.
Non, on en conclut simplement que tu peux avoir une bonne maîtrise de ta machine. Sur un OS desktop, c'est une évidence, mais sur un OS de smartphone ça l'est moins. "Jailbreak", "Root", ROMs obscures, données non maîtrisées, sont aujourd'hui le quotidien des utilisateurs de smartphone.
Tu leur fais un procès d'intention, sans argument, ça fleure la mauvaise foi.
Alors élevons le débat, basons-nous sur des faits: sur sailfishos.org, on trouve le texte suivant: "We are currently in the process of putting in place the processes and licensing structures that will enable you, the community, to take part in developing Sailfish." -> ce n'est peut-être que marketing, mais Google n'a jamais fait le moindre geste dans ce sens pour ses Google Apps.
Par ailleurs, ta phrase "Le proprio n'est peut-être pas mieux, mais il est bien utilisé pour que l'utilisateur final achète chez eux et pas ailleurs" n'a pas de sens pour Jolla: ce que tu achètes, c'est le téléphone Jolla, vendu avec son UI. Tu veux aller ailleurs ? Il suffit d'acheter un autre téléphone… Les Google apps sont différentes: tu achètes un téléphone non Google (l'OS est normalement neutre), mais au final la façon dont tout est imbriqué te force à avoir un compte chez Google.
Note qu'on peut installer l'OS de Jolla sur un N9, et Jolla a aidé la communauté sur certains points techniques.
Ce que Jolla met en avant, c'est son dialogue avec la communauté du libre. De mon point de vue, c'est ça qui plaît, avant tout. Personne n'oublie que l'UI est proprio, il n'y a pas de "poudre".
Jolla n'a jamais prétendu vouloir faire du 100% libre. L'UI est proprio (c'est leur choix), les drivers aussi (c'est une contrainte).
Par contre, ils prétendent interagir fortement avec la communauté du libre, en se basant sur des briques libres (Qt, Wayland, Mer, Nemo mobile) et en poussant en amont ce qui peut l'être ( voir par exemple http://www.macieira.org/~thiago/qt-stats/current/qt-all-no-digia.employer.relative.png ).
Ils sont en permanence à l'écoute sur IRC (#jollamobile, #sailfishos), discutent ouvertement des problèmes et des défauts (together.jolla.com).
Le téléphone Jolla est accessible en root facilement (pas de hack bizarre), il est assez facile de construire des applis (merci QtQuick), et on est sur du connu: pile glibc "classique", wayland, Qt.
Je ne connais pas les raisons pour lesquelles Jolla a mis son UI sous licence proprio, mais ce n'est certainement pas en pensant "le proprio c'est mieux". Pour les drivers, ce sont les drivers Android pour cette architecture qui sont utilisés à travers une bibliothèque de compatibilité libhybris: j'imagine que le facteur temps (sortir un produit rapidement) a joué pour beaucoup. Aussi, Jolla n'a pas le poids nécessaire pour qu'un constructeur fasse l'effort de leur fournir un driver dédié, libre de surcroît.
Bref, c'est en effet dommage que l'UI soit proprio, mais au final je trouve le bilan par rapport à la communauté du libre assez positif.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10. Dernière modification le 27 novembre 2014 à 15:53.
Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.
Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.
Si tu ne vois pas la différence, on peut arrêter là la discussion.
Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
Par contre:
- les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
- l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.
Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.
Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6.
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.
Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
Oh allons, pitié, disons, un bug ? Un script particulièrement pourri qu'il aurait conçu ? Le risque zéro n'existe pas en informatique.
Mais sinon, j'en déduis que tu es d'accord avec le reste ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -1.
Je savais que je n'aurais pas dû parler de ce détail: tu n'as retenu que ça de mon commentaire. C'est le reste qui est important.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7.
Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
* la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
* la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.
Je vais finir par une conclusion à la Zenitram:
C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 9.
C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.
Le vieil init est encore officiellement supporté par la distro, pour rappel.
Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.
Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Entre installer un système d'init et mettre à jour des logiciels et bibliothèques, le risque n'est pas le même… Je pensais que c'était évident.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6. Dernière modification le 27 novembre 2014 à 09:59.
Si son système marche bien actuellement, pourquoi prendre le moindre risque ? L'init SysV est encore maintenu par Debian, après tout.
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par Christophe . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
C'est Lipstick, en effet. Par contre, la base de code utilisée est sur Github:
https://github.com/nemomobile/lipstick
https://github.com/nemomobile/lipstick-colorful-home
[^] # Re: Description de systemd ?
Posté par Christophe . En réponse à la dépêche systemd versions 212 à 215. Évalué à 4.
Ce sont juste des doutes et des interrogations. Je ne suis pas devin, donc effectivement nous verrons bien. Mais il est essentiel de garder un œil critique sur ce composant qui est aujourd'hui au cœur de notre OS.
[^] # Re: Description de systemd ?
Posté par Christophe . En réponse à la dépêche systemd versions 212 à 215. Évalué à 5.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
(et merde, on est seulement lundi…)
[^] # Re: SLES
Posté par Christophe . En réponse au journal Swiss Re migre de Solaris vers Linux, et bientôt Windows vers Linux. Évalué à 4.
Je comprends mieux. Pour moi, le sujet du journal n'est pas Linux, mais une migration vers Linux. Le prestataire qui aide à le faire est pour moi une information importante, car elle explique le "pourquoi" et le "comment" de la migration (support et conseil pour la migration du client, etc).
C'est un peu comme faire un journal "j'ai pas réussi à installer Linux, c'était trop difficile". On n'est pas très avancés si on ne sait même pas quels choix ont été faits pour arriver à cet échec.
[^] # Re: SLES
Posté par Christophe . En réponse au journal Swiss Re migre de Solaris vers Linux, et bientôt Windows vers Linux. Évalué à 2.
Là, je suis perdu. Plus haut, dans une autre réponse, tu dis:
Ce à quoi j'allais répondre que je n'étais pas d'accord (support, certifs, tout ça c'est le prestataire qui le fournit, pas "Linux"), mais apparemment toi non plus… Que voulais-tu donc dire ?
# Encodage du code source
Posté par Christophe . En réponse au message affichage caractère.. Évalué à 4.
Tout le problème réside dans la façon dont est stockée ta chaîne de caractères dans le fichier source, qui est ensuite compilé.
Pour peu que ton "é" soit encodé sur 2 octets, t[1] sera insuffisant pour l'afficher correctement. Bien sûr, en supposant que ton affichage de terminal soit adapté à ce printf…
[^] # Re: A mon sens LE meilleur OS mobile totalement libre
Posté par Christophe . En réponse à la dépêche webOS se relance en LuneOS. Évalué à 2.
Il faut remettre les choses dans leur contexte: le TouchPad est le premier essai de webOS sur un format tablette. L'OS n'a quasiment jamais été mis à jour, à part par la communauté dans la mesure du possible.
Le manque d'applications s'explique lui aussi par la durée de vie très courte de ce produit. Certaines initiatives ont un peu amélioré les choses (LunaCE, Preware, système de patchs…) mais l'utilisateur lambda non bidouilleur a certainement dû rester sur sa faim.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à -1.
Le portage, dans la plupart des cas, ne nécessiterait même pas de recompiler les binaires de l'UI. C'était le cas aussi pour le portage sur le N9, qui pourtant n'est même pas un Android. La pièce maîtresse est ici libhybris, un projet initié par un employé de Jolla… en GPL.
Non, je ne le crois même pas du tout. Donc du coup, la bonne raison du paragraphe précédent, on en fait quoi ?
La différence, elle est entre "préférer faire du proprio pour ce cas particulier" et "préférer faire du proprio dans tous les cas".
Ou pas. Jolla n'est pas Google. Ne pas libérer le code apporte aussi le risque que la communauté se désintéresse d'eux, et vu la taille de leur structure c'est à prendre en compte.
Non, j'essaie juste de montrer qu'un procès d'intention, pour une entreprise aussi jeune, est injustifié. Je n'ai jamais dit "Ils libèreront leur code, c'est sûr !", par contre, toi tu affirmes que l'UI "ne risque pas d'être libérée pour cause de business!". On n'en sait rien, c'est tout.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 4.
Oui, comment faire pour réguler tout ça de façon intelligente, en gardant un design cohérent et sans introduire de bugs ? Il faudra certainement des infrastructures et des personnes en plus, comment on finance tout ça ?
Ils ont l'audace de réfléchir à l'ensemble du tableau avant d'agir. J'ai l'impression que c'est presque un crime, par ici.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 0.
Je m'auto-réponds: il semble qu'ils n'aient pas l'intention de vendre l'OS dans le futur.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 0.
Je t'invite à te renseigner justement sur leur architecture. Avec libhybris, tu peux "assez facilement" aller conquérir d'autres terminaux Android. Ils ont fait une rapide démo sur un Nexus 7, récemment.
Il n'est pas dit encore quel chemin ils prendront pour ce genre de portage: vendre l'OS ou le proposer gratuitement.
Non, pour Jolla, le mieux, c'est le plus pratique/faisable. Jolla ne préfère ni le libre (où ai-je dit ça ?), ni le proprio. Ils sont pragmatiques.
Par exemple, libérer le code source et ne pas avoir assez de ressources ensuite pour gérer les contributions risque de mécontenter les contributeurs. SailfishOS est encore en "Beta": à une phase aussi précoce, sortir un produit commercial avec de possibles multiples forks existants risque aussi de donner une image confuse de ce qui est proposé, et de rebuter des partenaires. Le faire plus tard, lorsque le produit est stabilisé et un peu mieux connu tel quel, peut avoir du sens. Ou pas.
Cette question a été abordée sur Jolla, initiée par Jolla eux-même: https://together.jolla.com/question/680/co-creation-leading-to-co-development/
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 1.
Non, c'est toi qui compares toujours avec Google et Android. Tu compares les contributions d'un mastodonte avec celles d'une PME de 80 personnes. Tu compares le "niveau de libritude" (je suis surpris, venant de toi) d'Android qui se dit libre (mais ne l'est pas) et de Sailfish qui n'a pas cette prétention.
Toi, si carré sur la définition de "logiciel libre", vient nous dire maintenant que "open" c'est forcément "open source"… Non, ils sont "ouverts" au sens premier du terme: ils sont à l'écoute des communautés avec qui ils sont en contact. Ils surfent sur la collaboration entre communautés. Pas sur le logiciel libre, comme tu te plais à le répéter.
Cite moi une seule entreprise qui participe à l'écosystème libre alors que ça ne les arrange pas… Tu es le seul dans cette discussion à chercher à savoir qui est le plus beau. Les deux participent. Et ?
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 1.
Ce n'est pas que de la prétention… Ils ont interagit fortement avec la communauté du libre. Ils ont fait avancer les choses sur plusieurs projets libres (Qt, QtWayland, Maliit, libhybris…). Rien que ça est déjà un bon point, même si bien sûr au final leur objectif est de vendre un téléphone.
Il est bien possible que l'écosystème qui se formera autour de ce nouvel OS fasse la part belle aux LL, comme sur le N900.
Peut-être ai-je tout faux, bien sûr. Mais jusqu'à maintenant, il n'y a pas eu de double langage ou de langue de bois. Il y a un vrai dialogue avec les utilisateurs.
L'intérêt coté LL n'est pas dans l'UI proprio, bien sûr. L'intérêt est dans toutes les briques libres qui ont dues être utilisées et améliorées pour faire tourner cette UI.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 5.
Non, on en conclut simplement que tu peux avoir une bonne maîtrise de ta machine. Sur un OS desktop, c'est une évidence, mais sur un OS de smartphone ça l'est moins. "Jailbreak", "Root", ROMs obscures, données non maîtrisées, sont aujourd'hui le quotidien des utilisateurs de smartphone.
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
Non. C'est bien joli de baser toute ta critique là-dessus, mais Jolla n'a jamais promu cette image de "logiciel libre".
[^] # Re: Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à -1.
Tu leur fais un procès d'intention, sans argument, ça fleure la mauvaise foi.
Alors élevons le débat, basons-nous sur des faits: sur sailfishos.org, on trouve le texte suivant: "We are currently in the process of putting in place the processes and licensing structures that will enable you, the community, to take part in developing Sailfish." -> ce n'est peut-être que marketing, mais Google n'a jamais fait le moindre geste dans ce sens pour ses Google Apps.
Par ailleurs, ta phrase "Le proprio n'est peut-être pas mieux, mais il est bien utilisé pour que l'utilisateur final achète chez eux et pas ailleurs" n'a pas de sens pour Jolla: ce que tu achètes, c'est le téléphone Jolla, vendu avec son UI. Tu veux aller ailleurs ? Il suffit d'acheter un autre téléphone… Les Google apps sont différentes: tu achètes un téléphone non Google (l'OS est normalement neutre), mais au final la façon dont tout est imbriqué te force à avoir un compte chez Google.
Note qu'on peut installer l'OS de Jolla sur un N9, et Jolla a aidé la communauté sur certains points techniques.
Ce que Jolla met en avant, c'est son dialogue avec la communauté du libre. De mon point de vue, c'est ça qui plaît, avant tout. Personne n'oublie que l'UI est proprio, il n'y a pas de "poudre".
# Aucune surprise
Posté par Christophe . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 10.
Jolla n'a jamais prétendu vouloir faire du 100% libre. L'UI est proprio (c'est leur choix), les drivers aussi (c'est une contrainte).
Par contre, ils prétendent interagir fortement avec la communauté du libre, en se basant sur des briques libres (Qt, Wayland, Mer, Nemo mobile) et en poussant en amont ce qui peut l'être ( voir par exemple http://www.macieira.org/~thiago/qt-stats/current/qt-all-no-digia.employer.relative.png ).
Ils sont en permanence à l'écoute sur IRC (#jollamobile, #sailfishos), discutent ouvertement des problèmes et des défauts (together.jolla.com).
Le téléphone Jolla est accessible en root facilement (pas de hack bizarre), il est assez facile de construire des applis (merci QtQuick), et on est sur du connu: pile glibc "classique", wayland, Qt.
Je ne connais pas les raisons pour lesquelles Jolla a mis son UI sous licence proprio, mais ce n'est certainement pas en pensant "le proprio c'est mieux". Pour les drivers, ce sont les drivers Android pour cette architecture qui sont utilisés à travers une bibliothèque de compatibilité libhybris: j'imagine que le facteur temps (sortir un produit rapidement) a joué pour beaucoup. Aussi, Jolla n'a pas le poids nécessaire pour qu'un constructeur fasse l'effort de leur fournir un driver dédié, libre de surcroît.
Bref, c'est en effet dommage que l'UI soit proprio, mais au final je trouve le bilan par rapport à la communauté du libre assez positif.