mais il ne faut pas oublier le problème de licence qui est à l'origine de ce gâchis. Quand il était interdit de distribuer des versions modifiées de Qt, il était légitime de ne pas utiliser ce toolkit pour bâtir un bureau libre. La vraie faute elle est là et elle repose sur les épaules de TrollTech.
La communauté aurait aussi pu développer un "OpenQT" avec une API compatible, le tout sous licence LGPL, plutôt que de partir dans des guerres de religion C vs C++ et réinventer la roue…
comme le font les constructeurs de smartphone chinois avec Android
(…)
Ce que je crois moi c'est qu'ils envisagent une libération à la Solaris: le source est dispo (pour tout le monde ou seulement après signature de NDA) mais tu n'as que le droit d'envoyer tes patches à Jolla.
Mouais, quand on voit le respect de la GPL par les fabricants de chipset / ODMs chinois (" I've written e-mails to few producers (ZOPO, Cubot, THL), and even that I've gotten replies from ZOPO and THL, they don't want to share anything, nor the kernel, nor any other sources ") on peut se dire que même ça est risqué… :(
Même un Linux, ce n'est pas toujours évident (j'ai un vieux smartphone à base de SoC Mediatek pour lequel je n'ai jamais réussi à obtenir les sources => pas possible de recompiler kernel + Cyanogenmod).
Pour rappel, dans le monde ARM, il n'y a pas d'ACPI, et le device-tree n'est pas encore généralisé => pas de kernel générique. Une machine == un kernel. S'il te manque le device-tree ou les board files pour compiler le kernel pour ta machine, tu l'as dans l'OS !
Je viens de faire la MAJ de mon Samsung GS3 LTE (i9305) vers le Android stock 4.3. J'aurais dû faire plus attention : cette MAJ inclue Knox, qui change le bootloader et laisse une trace indélébile (eFuse) si je fais quoi que ce soit non prévu par Samsung (comme rooter mon téléphone, installer CWM recovery, tenter de faire in rollback sur le bootloader, etc.). Pour l'instant, griller le eFuse semble juste interdire le changement de bootloader et l'utilisation de container knox (mais ce n'est pas clair pour moi, car je lis aussi qu'il ne serait plus possible de réinstaller de firmware officiels via Odin une fois le eFuse grillé. Or si j'installe MIUI ou Omnirom, je souhaite garder la possibilité de remettre un firmware officiel, ne serait-ce que parce que certaines fonctionnalités comme EAP-SIM ne sont dispo que sur ces derniers…)
Bref, entre UEFI+trusted boot côté PC, et la même chose (bootloaders verrouillés, eFuse, etc.) côté smartphones, garder le contrôle de sa machine devient de plus incertain (car ça n'est pas que du reverse-engineering à effectuer, mais de la crypto à casser…)
"se concentrer" == commencer par convaincre Mediatek/Qualcomm/Samsung/nvidia de sortir un kernel et des drivers libres ! (et côté baseband, tu peux généralement te gratter, à part OsmocomBB)
Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).
les TIC pèsent, avec 1 500 teraWatt-heure d'électricité consommée par an, pour 10 % de la production mondiale. Soit la production de l'Allemagne et du Japon
Sauf que chacun de ces cores n'est en aucun cas comparable à un core i7. En particulier, ils sont plutôt mauvais pour le traitement out-of-order.
Note que ce que fait Kalray me semble assez proche de ce que fait Adapteva/Parallela http://www.adapteva.com/
Pour les cartes graphiques cela ne resoud pas le probleme de la consommation qui la est vraiment l'avancée technique majeure avec ce processeur
Mais ça progresse très vite ! (et il me semble assez possible que ça réduise significativement l'espace économique qui sera laissé aux Kalray et Adapteva…)
C'est super qu'il s' impliquen sur la question des drivers libres, mais on aimerait aussi voir la FSF faire plus simplement pression sur les Rockchip/Mediatek/AmLogic/HiSilicon… (et sur les ODMs ensuite) pour que ces derniers publient le code-source GPL Android utilisé (ou au moins device-tree et board files), afin de rendre les smartphones/tablette chinois (qui représentent des volumes très significatifs) devenir un peu moins jetables et un peu plus utilisables à long terme (omnirom, etc.), même si ça implique pour l'instant d'utiliser des drivers non libres…
N.b. il existe un projet de serveur X pour Android mais c'est tres limité. J'ignore s' il serait possible d'ecrire "simplement" un wrapper DDX xorg -> drivers binaires android ?
A ce sujet, notons cet excellent post à propos de bzImage, qui montre que l'histoire de Linux n'a pas été non plus exempte de ce type de considérations…
"640 kB ought to be enough for everyone"—Bill Gates, 1981
"This 508 kB kernel size should be enough"—Linus Torvalds, 1991
Yep, il semble malheureusement que Pardus soit morte. Par contre Pisi-Linux tente de prendre la relêve, et il existe un dépôt Github avec l'ensemble des sources. On verra bien…
N.B. sur le même thème, je suis à la recherche du document "SpeedingUpLinuxWithPardus.html" (qui semble ne plus exister nulle part), si quelqu'un en a une copie :)
Il expliquait de manière très intéressante les choix de Pardus concernant leur système de boot original (et tout en Python :)
Il y a très longtemps, j'avais vu cet article de developerworks (malheureusement disparu du site d'origine) qui utilise make -j pour lancer les services en parallèle tout en gérant les dépendances.
Debian possède des alternatives aux symlinks sysvinit, comme file-rc (aussi disponible ici) pour gérer le process de boot avec un unique fichier.
Et pour l'image, il vaut mieux fournir un produit apprécié des consommateurs, c'est moins risqué
On parle bien de l'école là ? Le truc gratuit, public et obligatoire qui permet d'élever le niveau d'instruction d'un pays (pas de répondre aux desiderata des gamins qu'on prend déjà pour des "consommateurs"…)
J'espère personnellement que mes impôts serviront à autre chose qu'à offrir à tous les gamins un gadget techno fermé qui (à l'âge considéré) servira plus à jouer qu'à travailler, dont le bénéfice pédagogique est douteux, dont la durée de vie n'excède pas 4 ans, qui est conçu aux US et fabriqué en Chine (donc aucun bénéfice sur l'emploi en France), et dont l'empreinte environnementale est significative (surtout avec les volumes en jeu).
(le raisonnement reste valable pour Android, à ceci près qu'une tablette Android équivalente à un iPad doit coûter environ 2-3x moins cher, et est davantage hackable pour peu que les sources du kernel soient disponibles (ce qui n'est pas toujours vrai dans le cas des tablettes low-cost chinoises))
Quand je regarde la page du repo Github, je comprends que ça tourne au dessus de Linux/KVM (c'est juste que l'OS guest est allégé), donc j'ai du mal à voir comment ça pourrait être plus léger que des containers.
Le but est d'utiliser les vendeurs de cloud qui font une abstraction du hardware. C'est impossible à faire avec les containers.
Tu as des hébergeurs qui te proposent une VM OpenVZ et d'autres qui te proposent une VM KVM (souvent les mêmes d'ailleurs, souvent plus cher en KVM). Oui, cet OS nécessite KVM et ne marchera pas sur du OpenVZ. Mais faire marcher cet OS n'est pas un but en soi, c'est l'application qui est un but. En fait, je pense que les corner-case pour lesquels OpenVZ est insuffisant sont des cas où il y a besoin de flexibilité sur le noyau (iptables, etc.), et donc de faire tourner un vrai Linux guest. Je ne veux pas critiquer le projet (c'est déjà bien sympa pour les auteurs de mettre le code en open-source, et ça servira sûrement à des gens) mais à mon niveau je ne vois pas de cas d'utilisation pour cet OS "cloud" qui ne soit pas déjà parfaitement adressé par les containers (N.B. je vais faire un peu de pub, mais chez IperWeb on a une VM OpenVZ pour 1.5 €/mois avec 384Mo de RAM, 12Go de stockage et 2To de trafic ! J'ai pas encore trouvé mieux…).
Pour lancer plusieurs VMs pour des services simples (postfix, dns, dhcp, …) je trouve que c'est du gachi d'instancier autant de choses pour juste lancer un seul service
Entièrement d'accord.
Le "juste milieu" c'est peut-être les containers ? (Jails BSD, OpenVZ, VServer, LXC…)
N.B. j'ai deux VM chez un hébergeur, une en OpenVZ et l'autre en KVM, et j'observe toutefois que le OpenVZ a parfois des limitations, par exemple sur iptables (logique, mais c'est pour souligner que ce n'est pas 100% iso-fonctionnel).
J'en profite pour parler d'un hyperviseur qui semble méconnu, conçu pour le monde ARM (sans besoin de support Hardware comme dans les Cortex A15), et qui se base sur le micro-noyau L4. ça s'appelle Codezero et ça permet apparemment de multiplexer Android et Linux sur une Pandaboard ou un Galaxy Nexus. Je n'ai pas essayé mais je suis preneur de tout retour d'expérience !
[^] # Re: Uchronie
Posté par karteum59 . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4. Dernière modification le 14 janvier 2014 à 12:32.
La communauté aurait aussi pu développer un "OpenQT" avec une API compatible, le tout sous licence LGPL, plutôt que de partir dans des guerres de religion C vs C++ et réinventer la roue…
[^] # Re: Mercurial
Posté par karteum59 . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Si >80% du temps est dépensé dans <20% du code, ce n'est pas déconnant…
[^] # Re: Aucune surprise
Posté par karteum59 . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Mouais, quand on voit le respect de la GPL par les fabricants de chipset / ODMs chinois (" I've written e-mails to few producers (ZOPO, Cubot, THL), and even that I've gotten replies from ZOPO and THL, they don't want to share anything, nor the kernel, nor any other sources ") on peut se dire que même ça est risqué… :(
[^] # Re: Aucune surprise
Posté par karteum59 . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2. Dernière modification le 09 janvier 2014 à 21:28.
Même un Linux, ce n'est pas toujours évident (j'ai un vieux smartphone à base de SoC Mediatek pour lequel je n'ai jamais réussi à obtenir les sources => pas possible de recompiler kernel + Cyanogenmod).
Pour rappel, dans le monde ARM, il n'y a pas d'ACPI, et le device-tree n'est pas encore généralisé => pas de kernel générique. Une machine == un kernel. S'il te manque le device-tree ou les board files pour compiler le kernel pour ta machine, tu l'as dans l'OS !
[^] # Re: L'histoire se repette !
Posté par karteum59 . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
Je viens de faire la MAJ de mon Samsung GS3 LTE (i9305) vers le Android stock 4.3. J'aurais dû faire plus attention : cette MAJ inclue Knox, qui change le bootloader et laisse une trace indélébile (eFuse) si je fais quoi que ce soit non prévu par Samsung (comme rooter mon téléphone, installer CWM recovery, tenter de faire in rollback sur le bootloader, etc.). Pour l'instant, griller le eFuse semble juste interdire le changement de bootloader et l'utilisation de container knox (mais ce n'est pas clair pour moi, car je lis aussi qu'il ne serait plus possible de réinstaller de firmware officiels via Odin une fois le eFuse grillé. Or si j'installe MIUI ou Omnirom, je souhaite garder la possibilité de remettre un firmware officiel, ne serait-ce que parce que certaines fonctionnalités comme EAP-SIM ne sont dispo que sur ces derniers…)
Bref, entre UEFI+trusted boot côté PC, et la même chose (bootloaders verrouillés, eFuse, etc.) côté smartphones, garder le contrôle de sa machine devient de plus incertain (car ça n'est pas que du reverse-engineering à effectuer, mais de la crypto à casser…)
[^] # Re: L'histoire se repette !
Posté par karteum59 . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
"se concentrer" == commencer par convaincre Mediatek/Qualcomm/Samsung/nvidia de sortir un kernel et des drivers libres ! (et côté baseband, tu peux généralement te gratter, à part OsmocomBB)
[^] # Re: Et les cartes graphiques ?
Posté par karteum59 . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10.
Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).
[^] # Re: Et les cartes graphiques ?
Posté par karteum59 . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10. Dernière modification le 09 janvier 2014 à 01:17.
Par ailleurs en parlant de consommation, il parait bon de rappeler que l'utilisation d'une machine pèse très peu par rapport à ce que nécessite sa fabrication. Donc le meilleur moyen de consommer moins, c'est d'utiliser nos machines longtemps (même si elles sont grosses, obsolètes et energivores !)
[^] # Re: Et les cartes graphiques ?
Posté par karteum59 . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 7. Dernière modification le 09 janvier 2014 à 00:59.
Sauf que chacun de ces cores n'est en aucun cas comparable à un core i7. En particulier, ils sont plutôt mauvais pour le traitement out-of-order.
Note que ce que fait Kalray me semble assez proche de ce que fait Adapteva/Parallela http://www.adapteva.com/
pas encore
Mais ça progresse très vite ! (et il me semble assez possible que ça réduise significativement l'espace économique qui sera laissé aux Kalray et Adapteva…)
[^] # Re: Il manque...
Posté par karteum59 . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 3.
La plupart des clés USB que je vois passer sont très très loin du 120Mo/s !
[^] # Re: google
Posté par karteum59 . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 5. Dernière modification le 07 janvier 2014 à 20:48.
Hum… et ça rend Skype auditable et interopérable ?
[^] # Re: google
Posté par karteum59 . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 5.
J'ignorais que le code-source et le protocole de Skype étaient disponibles, auditables, et interopérables avec d'autres implémentations…
[^] # Re: Il manque...
Posté par karteum59 . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 2.
Ouais enfin, le débit d'écriture sur une clé USB n'est généralement pas transcendant non plus…
[^] # Re: ubuntu touch
Posté par karteum59 . En réponse à la dépêche Android presque partout. Évalué à 3.
C'est super qu'il s' impliquen sur la question des drivers libres, mais on aimerait aussi voir la FSF faire plus simplement pression sur les Rockchip/Mediatek/AmLogic/HiSilicon… (et sur les ODMs ensuite) pour que ces derniers publient le code-source GPL Android utilisé (ou au moins device-tree et board files), afin de rendre les smartphones/tablette chinois (qui représentent des volumes très significatifs) devenir un peu moins jetables et un peu plus utilisables à long terme (omnirom, etc.), même si ça implique pour l'instant d'utiliser des drivers non libres…
N.b. il existe un projet de serveur X pour Android mais c'est tres limité. J'ignore s' il serait possible d'ecrire "simplement" un wrapper DDX xorg -> drivers binaires android ?
[^] # Re: Mo
Posté par karteum59 . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
A ce sujet, notons cet excellent post à propos de bzImage, qui montre que l'histoire de Linux n'a pas été non plus exempte de ce type de considérations…
"640 kB ought to be enough for everyone"—Bill Gates, 1981
"This 508 kB kernel size should be enough"—Linus Torvalds, 1991
[^] # Re: Mo
Posté par karteum59 . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 5.
Franchement, 640 Ko devraient être suffisants pour tout le monde ! :)
--> []
[^] # Re: Quelques alternatives
Posté par karteum59 . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3.
Yep, il semble malheureusement que Pardus soit morte. Par contre Pisi-Linux tente de prendre la relêve, et il existe un dépôt Github avec l'ensemble des sources. On verra bien…
[^] # Re: Quelques alternatives
Posté par karteum59 . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 4.
N.B. sur le même thème, je suis à la recherche du document "SpeedingUpLinuxWithPardus.html" (qui semble ne plus exister nulle part), si quelqu'un en a une copie :)
Il expliquait de manière très intéressante les choix de Pardus concernant leur système de boot original (et tout en Python :)
# Quelques alternatives
Posté par karteum59 . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3. Dernière modification le 03 décembre 2013 à 22:16.
Si jamais ça peut servir à d'autres…
[^] # Re: non mon fils, un Ipad
Posté par karteum59 . En réponse au journal Merci les barbus (les vrais !!). Évalué à 2.
On parle bien de l'école là ? Le truc gratuit, public et obligatoire qui permet d'élever le niveau d'instruction d'un pays (pas de répondre aux desiderata des gamins qu'on prend déjà pour des "consommateurs"…)
[^] # Re: Oui mais... pourquoi imposer un environnement de bureau
Posté par karteum59 . En réponse à la dépêche Dibab. Évalué à 2. Dernière modification le 25 novembre 2013 à 02:35.
D'après un sondage Linuxfr, j'ai aussi noté ces projets :
[^] # Re: non mon fils, un Ipad
Posté par karteum59 . En réponse au journal Merci les barbus (les vrais !!). Évalué à 5.
[^] # Re: non mon fils, un Ipad
Posté par karteum59 . En réponse au journal Merci les barbus (les vrais !!). Évalué à 3. Dernière modification le 20 novembre 2013 à 19:42.
J'espère personnellement que mes impôts serviront à autre chose qu'à offrir à tous les gamins un gadget techno fermé qui (à l'âge considéré) servira plus à jouer qu'à travailler, dont le bénéfice pédagogique est douteux, dont la durée de vie n'excède pas 4 ans, qui est conçu aux US et fabriqué en Chine (donc aucun bénéfice sur l'emploi en France), et dont l'empreinte environnementale est significative (surtout avec les volumes en jeu).
(le raisonnement reste valable pour Android, à ceci près qu'une tablette Android équivalente à un iPad doit coûter environ 2-3x moins cher, et est davantage hackable pour peu que les sources du kernel soient disponibles (ce qui n'est pas toujours vrai dans le cas des tablettes low-cost chinoises))
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par karteum59 . En réponse au journal OSv : l'OS pour les nuages. Évalué à 3.
Quand je regarde la page du repo Github, je comprends que ça tourne au dessus de Linux/KVM (c'est juste que l'OS guest est allégé), donc j'ai du mal à voir comment ça pourrait être plus léger que des containers.
Tu as des hébergeurs qui te proposent une VM OpenVZ et d'autres qui te proposent une VM KVM (souvent les mêmes d'ailleurs, souvent plus cher en KVM). Oui, cet OS nécessite KVM et ne marchera pas sur du OpenVZ. Mais faire marcher cet OS n'est pas un but en soi, c'est l'application qui est un but. En fait, je pense que les corner-case pour lesquels OpenVZ est insuffisant sont des cas où il y a besoin de flexibilité sur le noyau (iptables, etc.), et donc de faire tourner un vrai Linux guest. Je ne veux pas critiquer le projet (c'est déjà bien sympa pour les auteurs de mettre le code en open-source, et ça servira sûrement à des gens) mais à mon niveau je ne vois pas de cas d'utilisation pour cet OS "cloud" qui ne soit pas déjà parfaitement adressé par les containers (N.B. je vais faire un peu de pub, mais chez IperWeb on a une VM OpenVZ pour 1.5 €/mois avec 384Mo de RAM, 12Go de stockage et 2To de trafic ! J'ai pas encore trouvé mieux…).
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par karteum59 . En réponse au journal OSv : l'OS pour les nuages. Évalué à 3. Dernière modification le 18 novembre 2013 à 16:28.
Entièrement d'accord.
Le "juste milieu" c'est peut-être les containers ? (Jails BSD, OpenVZ, VServer, LXC…)
N.B. j'ai deux VM chez un hébergeur, une en OpenVZ et l'autre en KVM, et j'observe toutefois que le OpenVZ a parfois des limitations, par exemple sur iptables (logique, mais c'est pour souligner que ce n'est pas 100% iso-fonctionnel).
J'en profite pour parler d'un hyperviseur qui semble méconnu, conçu pour le monde ARM (sans besoin de support Hardware comme dans les Cortex A15), et qui se base sur le micro-noyau L4. ça s'appelle Codezero et ça permet apparemment de multiplexer Android et Linux sur une Pandaboard ou un Galaxy Nexus. Je n'ai pas essayé mais je suis preneur de tout retour d'expérience !