karteum59 a écrit 873 commentaires

Bravo et merci aux contributeurs !

Trois remarques/questions:

• le principal truc qui m'empêche d'utiliser LibO au bureau (en travail collaboratif sur des documents .docx) est qu'il parse l'ensemble du document pour le convertir dans sa représentation interne, et du coup on perd de l'information au passage lors de la reconversion en .docx à l'enregistrement (mise en forme cassée, etc). J'ai cru comprendre qu'un travail était en cours pour que le document enregistré à la fin ne touche que les noeuds OOXML nécessaires (correspondant aux zones du document modifiées par l'utilisateur), comme le font les suite Office sur Android. Ce serait vraiment bien => est-il possible d'en savoir plus ? (N.B. accessoirement, je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)).
• suggestion: une fonctionnalité qui me manque (et qui n'existe nulle part à ma connaissance) est la possibilité de faire des "branches" (un peu à la git) correspondant à différentes formulations de texte, et discuter/voter ensuite sur la formulation préférée.
• je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)

"Crowfunding" c'est du financement d'élevage de corbeaux ? :)

--> []

Ce serait pas un peu le même concept que la Gameduino ?

(et je découvre accessoirement que la Gameduino 2 permet de belles choses ! :)

Aptitude est un frontal convivial à dpkg, l'installeur de paquets. Apt est un autre frontal, en ligne de commande. Synaptic est une interface graphique pour Apt.

Il me semblait avoir lu que aptitude était deprecated (au moins sur Ubuntu, je ne suis pas sûr concernant Debian) ?

un solveur de dépendance

aptitude a un solveur différent de apt-get mais ça n'a jamais totalement marché pour moi. Par contre je lis des choses intéressantes concernant ce que saurait faire le solveur du projet Mancoosi avec apt-get.

Si depuis des années, Qt est libre et que KDE n'ai pas parvenu à (clairement) s'imposer face au bureau GNOME, il faut peut-être en tirer la conclusion qui est que, GNOME a lui aussi ses avantages et qu'il convient mieux à certains utilisateurs et (soyons fou) que Gtk+ convient mieux à certains développeurs aussi.

Peut-être que le soutien "politique" de la FSF et de RedHat aident aussi… (et puis, le souhait un peu légitime d'avoir "one desktop to rule them all" pour éviter la fragmentation. Puisque ça ne devait pas être KDE, ils ont tout fait pour que ce soit Gnome. Manque de bol, il était techniquement très inférieur).

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…

il y a 11 fichiers C (dont 1 en contrib et 1 pour linux) qui totalisent 4800 lignes de code contre 66000 en python.

Si >80% du temps est dépensé dans <20% du code, ce n'est pas déconnant…

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 !

et le problème serait réglé.

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

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 !)

Sur le papier le MPPA 256 c'est (…)

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

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…)

La plupart des clés USB que je vois passer sont très très loin du 120Mo/s !

Hum… et ça rend Skype auditable et interopérable ?

Skype est gratuit aussi, mais "ça pue" va comprendre

J'ignorais que le code-source et le protocole de Skype étaient disponibles, auditables, et interopérables avec d'autres implémentations…

Ouais enfin, le débit d'écriture sur une clé USB n'est généralement pas transcendant non plus…

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

Pourquoi mettre 1Go alors que 32 Mo suffisent ?

Franchement, 640 Ko devraient être suffisants pour tout le monde ! :)
--> []

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 :)

Si jamais ça peut servir à d'autres…

• 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.
• Cet article parle de cinit
• initng
• serel

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"…)