Quel est le rapport entre java et android ? Le langage se ressemble ? Il utilise le bytecode java dans l'une de ses étapes de build ?
Android est un écosystème à part entière. Il a peut-être des ponts avec java, mais c'est comme confondre c et c++.
Hein ?
Java, c'est le langage privilégié pour développer des applications sous Android (avec Kotlin). Android a sa propre VM et n'utilise pas OpenJDK, mais je ne vois pas la différence niveau langage. Je ne comprends pas du tout le parallèle avec la comparaison C et C++.
Bien sûr, une grosse partie d'Android est écrite en C et en C++, peut-être as-tu compris cela quand on parlait de développement Android ? En tout cas, pendant la compilation d'Android, beaucoup de code java est compilé.
Après trois quarts d'heure de récupération des sources de LineageOS 17.1 (Android 10) et une heure trois quart de comptage de lignes de code (cloc), voici les résultats :
Yes, mais c'est aussi vrai avec Javascript. Etherpad, par exemple, consomme un max de mémoire même sans rien faire et de CPU, côté serveur. Je suspecte que le langage n'importe pas autant que les choix de conception cela dit dans ce cas. J'ai lu que gitlab était très gourmand en ressources aussi (Ruby).
Pour moi, Android est justement un exemple de plateforme où on peut trouver des applications Java très légères.
Le développement d'applications Android c'est une autre histoire. C'est beaucoup trop lourd et pénible par rapport à ce que ça devrait être. Et alors si en plus l'application utilise Javascript et npm, là tu as tout gagné.
Mais je reconnais qu'en Java, on a très vite la mauvaise habitude de mettre des classes et d'empiler des abstractions sur des abstractions à tout bout de champs.
Pourquoi Java serait plus lourd que Javascript, Python, Ruby, PHP ou n'importe quelle technologie répandue côté serveur ? C'est un langage qui a une excellente VM (JIT efficace, très bon garbage collector). C'est probablement plus rapide que Python ou Javascript, qui sont extrêmement dynamiques sur tous les tableaux.
Bien sûr, l'écosystème Java est rapidement lourd (perso je ne suis pas fan du tout), mais si on veut programmer un truc léger en Java, j'imagine qu'on peut le faire… en tout cas au moins autant qu'en Python ou en Javascript.
Il y aurait probablement moyen de faire plus léger en C, C++, Rust, D ou autre langage compilé d'une rapidité et d'une efficacité en mémoire comparable à celles du C, mais ce n'est pas très répandu.
Et je dis ça en tant que quelqu'un qui n'aime pas particulièrement Java et qui aime plutôt bien Python et Javascript.
Côté client en tout cas, OneDev semble répondre vite, et a l'air de fonctionner plutôt bien sans Javascript pour les opérations qui n'en ont pas vraiment besoin. Tout ça, contrairement à GitLab où on voit pas mal de logos de chargement un peu partout.
C'est intéressant. Cependant, malgré le titre, l'article ne semble pas parler du coût des mails lui-même, seulement du coût des datacenters (en tout cas, je n'ai pas vu).
Un mail texte c'est quelques Kio.
J'utilise les mails depuis 2004. Un du -h dans mon dossier /var/mail/vmail/ donne 8G. Une partie des mails sont dupliqués, je pourrais gagner de la place. J'ai aussi tous mes SMS depuis 2017 (435M - oui il y en a beaucoup et stocker les SMS en mail c'est horriblement inefficace - comptez moins de la moitié en version SQLite + images sur le téléphone).
J'aurais probablement intérêt à sortir ces mails du serveur et les stocker sur un ordi qui dort la plupart du temps. C'est en cours de réflexion.
J'ai aussi une boîte pro depuis 2014. Un du -h donne 3.2 G. Il y a beaucoup trop de PDFs en pièces jointes dans cette boîte.
D'accord, tout ça c'est beaucoup et il faut assurer la redondance (donc au moins ×2 ou ×3) (mais bon, je n'utilise pas de compression - j'espère que les gros le font !). Mais en même temps, une heure de vidéos était envoyé sur YouTube chaque minute en 2012. Aujourd'hui j'imagine que c'est beaucoup plus. L'équivalent du poids de ma boite mail sur ma vie entière est utilisé par YouTube en quelques minutes. Et je ne parle que de YouTube (imaginez le nombre de liens, journaux et commentaires envoyés chaque seconde sur LinuxFr par exemple !! Ah ah).
Alors ok, il faut bien voir que YouTube et LinuxFr sont des ressources communes à l'échelle planétaire, contrairement à ma boite mail qui est bien individuelle et en plus, beaucoup des mails dans ma boite sont aussi dans une ou plusieurs autres boites - celles de mes correspondants, voire plus pour les mailing lists).
Je veux bien croire que si tout le monde réduit un peu ses envois et utilise des moyens appropriés pour le transfert de documents, on peut avoir un effet non négligeable, mais combien dans l'absolu et combien en proportion par rapport aux quantités de données autres stockées dans les datacenters ?
Peu de réponses, surtout du questionnement au final :-)
Si les sources de Windows 7 étaient libérées, je suis certain que beaucoup de gens trouveraient quoi faire avec. À commencer, peut-être bien, par le projet Wine.
Et puis si c'est libre, tu peux retirer les problèmes d'invasions de la vie privées :-)
RMS déteste Windows, mais si demain une version libre sans surveillance était publiée, il serait probablement content, parce qu'il ne s'est jamais opposé à Windows pour ses qualités techniques, en tout cas publiquement.
Et si demain, Microsoft décide de publier les versions actuelles de Windows sous licence libre, eh bien on a gagné une partie du « combat ». Pas tout, j'imagine qu'on aurait quand même des problèmes similaires à ceux qu'on a avec Android aujourd'hui.
À priori, on peut utiliser Qt dans le cadre d'un projet non libre tant qu'on n'utilise pas les parties GPL.
À mon avis, il n'y a pas besoin de fuir Qt. Tant qu'il existe des versions libres (ce qui est plus ou moins garanti par l'accord FreeQt), quelqu'un d'autre aura toujours le droit de redistribuer les versions libres de Qt si le mode de distribution par la Qt Company devenait trop contraignant.
Ça marche aussi avec le clavier AOSP standard (et le clavier Google du coup, puisque c'est la même chose avec un ou deux trucs proprio en plus). C'est dans les paramètres du clavier.
Et puis pourquoi ne pas créer une alerte quand son $HOME est presque plein
Ça KDE s'en charge tout seul, mais la fausse manip impliquait une copie vers $HOME qui remplissait la partoche à toute vitesse. Donc ça a juste aidé un diagnostique plus rapide mais pas à prévenir le remplissage total de la partition.
Et puis perso, ce genre d'alerte, c'est la dernière chose que je pense à mettre en place sur autre chose qu'un serveur en production. Heureusement que l'environnement de bureau s'en charge :-)
(d'autant que j'aborde la question dans le journal : « Je m’en vais ajouter une tâche Cron journalière pour copier ce fichier d'historique dans mon dossier synchronisé, par exemple dans $DOSSIER/zsh_history-${HOST} »)
Chaque session de shell a son historique, mais inscrit les commandes dans un historique commun. Flèche du haut rappelle la ligne précédente dans la session actuelle, mais un appui sur la touche entrée avant flèche du haut charge l'historique produit par les autres sessions parallèles. Très pratique.
Personne n'est parfait et on ne prévoit pas tout !
En particulier, mes fichiers importants sont sauvegardés en temps réel avec Nextcloud, instance elle-même sauvegardée chaque nuit dans un sous-volume Btrfs à part sur une autre machine. Ce qui fait que mes données sont à deux endroits physiques à chaque instant, puis à un troisième endroit physique la nuit suivante. J'ai une version journalière de chacun de ces fichiers sur trois ans (sauf les jours où ça s'est planté…). Mais synchroniser l'historique zsh en temps réel comme ça ce n'est pas fou et j'ai dû retirer l'historique zsh de la synchronisation. J'ai reporté la gestion de cette sauvegarde « à plus tard ».
Et bien sûr, pour des raisons de narration, j'en ai rajouté des tonnes. Je survivrais à la perte de mon historique zsh. L'avoir est tout de même un gros confort, d'où une recherche de solution malgré tout. Et vous voyez, je n'ai finalement rien perdu.
Vous avez l'air d'écrire vos commentaires comme si tout le monde était capable de tout prévoir parfaitement. Je n'aime pas trop qu'on vienne me faire la leçon, ce n'est pas le but de ce journal.
Ça marchait avec la caisse d'épargne, mais depuis quelques temps la version accessible est juste le clavier virtuel avec prononciation des touches quand elles sont appuyées…
Sans parler du fait qu'avec leurs claviers virtuels qui bougent tout le temps :
pas possible de se fier à une quelconque mémoire spatiale, je ne serais pas étonné que des gens choisissent des mots de passes plus simple à cause de ça
je ne suis pas fier quand mon écran est potentiellement visible par d'autres personnes…
Je ne vois pas pourquoi Microsoft financerait un produit concurrent. Leurs formats sont de toute façon déjà omniprésents, ils n'ont absolument pas besoin d'augmenter un nombre qui est déjà quasi au max.
Cela dit, c'est vrai que les dépêches sur OnlyOffice sont vraiment très fréquentes ici et ça a l'air de déranger certaines personnes. Après, si la suite évolue rapidement, c'est peut-être justifié aussi.
Il semble bien y avoir une fonction terminal (en beta) pour tester. Cherche « Terminal » dans la page. Il y a aussi des liens avec l'intégration continue. Ça paraîtrait dangereux d'envoyer des changements dans un dépôt sans pouvoir les tester avant de toute façon.
J'ai l'impression que les fonctionnalités décrites correspondent au Web IDE chez Gitlab, qui est, lui, libre et qu'on peut héberger soi-même si besoin.
Je n'ai essayé ni l'un ni l'autre donc je ne sais pas comment ils se comparent, mais si j'avais besoin d'une telle fonctionnalité, je pense que me tournerais vers cette deuxième solution et j'invite les autres à faire de même.
Posté par raphj .
En réponse au lien KDE sur Android ? .
Évalué à 2.
Dernière modification le 14 décembre 2019 à 22:23.
Je suis heureux de voir qu'il y a aussi une version d'Okular pour Android. Pareil, c'est expérimental, bogué, lent mais l'ergonomie paraît intéressante.
Très enthousiasmant. J'aime beaucoup KDE, et utiliser ses applications sur le téléphone serait sympathique. Et, qui sait, ça faciliterait peut-être une transition vers un téléphone sous GNU/Linux plus tard ?
Qui montre quelques applications KDE en version Android. Intéressant.
Sinon, oui, oui, et oui, on peut utiliser KDE sous Android à l'aide du Serveur X XSDL et d'un chroot Debian (par exemple). J'ai pu partir en vacances avec seulement mon téléphone et un clavier souple grâce à ça. Beaucoup plus léger et moins volumineux que l'ordinateur + le téléphone.
Plasma marche mieux qu'Xfce avec ce serveur X et je n'ai pas essayé Gnome (avec GTK2, les listes déroulantes ne fonctionnent pas bien, et j'avais déjà observé ça sur une tablette tactile x86 tournant sous une distribution GNU/Linux standard). Et est relativement léger, en fait, malgré son démarrage très lent (c'est certainement mieux sur les version très récente, il y a eu du progrès de ce côté).
Petit problème, il a fallu que j'installe le chroot sur une carte SD parce que la mémoire interne du téléphone est montée avec noexec. Du coup, tout est lent à cause de la carte SD lente… À voir s'il y a moyen de faire quelque chose avec les chroot Termux, qui peuvent s'installer sur la mémoire interne mais qui ont certaines limitations.
Malheureusement, il y a des problèmes avec X Server XSDL depuis Android Pie sur mon téléphone lié à PulseAudio (cross-compilé pour Android ARM64) apparemment. J'ai réussi à restaurer une copie fonctionnelle à l'aide d'une sauvegarde oandbackup (sauf PulseAudio qui ne fonctionne plus) faite sur une version précédente d'Android, mais une nouvelle installation de l'application ne fonctionne plus. Elle n'est plus mise à jour depuis quelques temps, un petit dépoussiérage suffirait peut-être.
[^] # Re: Hmm
Posté par raphj . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 5. Dernière modification le 06 février 2020 à 12:57.
Hein ?
Java, c'est le langage privilégié pour développer des applications sous Android (avec Kotlin). Android a sa propre VM et n'utilise pas OpenJDK, mais je ne vois pas la différence niveau langage. Je ne comprends pas du tout le parallèle avec la comparaison C et C++.
Bien sûr, une grosse partie d'Android est écrite en C et en C++, peut-être as-tu compris cela quand on parlait de développement Android ? En tout cas, pendant la compilation d'Android, beaucoup de code java est compilé.
Après trois quarts d'heure de récupération des sources de LineageOS 17.1 (Android 10) et une heure trois quart de comptage de lignes de code (cloc), voici les résultats :
Presque autant de Java que de C++ et de C :-) (même si, d'accord, c'est peut-être du Java avec des spécificité…)
[^] # Re: Hmm
Posté par raphj . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 8. Dernière modification le 05 février 2020 à 14:39.
Yes, mais c'est aussi vrai avec Javascript. Etherpad, par exemple, consomme un max de mémoire même sans rien faire et de CPU, côté serveur. Je suspecte que le langage n'importe pas autant que les choix de conception cela dit dans ce cas. J'ai lu que gitlab était très gourmand en ressources aussi (Ruby).
Pour moi, Android est justement un exemple de plateforme où on peut trouver des applications Java très légères.
Le développement d'applications Android c'est une autre histoire. C'est beaucoup trop lourd et pénible par rapport à ce que ça devrait être. Et alors si en plus l'application utilise Javascript et npm, là tu as tout gagné.
Mais je reconnais qu'en Java, on a très vite la mauvaise habitude de mettre des classes et d'empiler des abstractions sur des abstractions à tout bout de champs.
[^] # Re: Hmm
Posté par raphj . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 10. Dernière modification le 05 février 2020 à 11:25.
Pourquoi Java serait plus lourd que Javascript, Python, Ruby, PHP ou n'importe quelle technologie répandue côté serveur ? C'est un langage qui a une excellente VM (JIT efficace, très bon garbage collector). C'est probablement plus rapide que Python ou Javascript, qui sont extrêmement dynamiques sur tous les tableaux.
Bien sûr, l'écosystème Java est rapidement lourd (perso je ne suis pas fan du tout), mais si on veut programmer un truc léger en Java, j'imagine qu'on peut le faire… en tout cas au moins autant qu'en Python ou en Javascript.
Il y aurait probablement moyen de faire plus léger en C, C++, Rust, D ou autre langage compilé d'une rapidité et d'une efficacité en mémoire comparable à celles du C, mais ce n'est pas très répandu.
Et je dis ça en tant que quelqu'un qui n'aime pas particulièrement Java et qui aime plutôt bien Python et Javascript.
Côté client en tout cas, OneDev semble répondre vite, et a l'air de fonctionner plutôt bien sans Javascript pour les opérations qui n'en ont pas vraiment besoin. Tout ça, contrairement à GitLab où on voit pas mal de logos de chargement un peu partout.
[^] # Re: Ortografe fransaize
Posté par raphj . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2020. Évalué à 3.
Cette vidéo est géniale. Merci pour le commentaire, c'est grave à lui que j'ai remarqué le lien.
Bah, c'était des rires causés par les éléments ridicules soulevés.
[^] # Re: coût des mails
Posté par raphj . En réponse au lien Réduisez le nombre de courriels si vous voulez lutter contre le réchauffement climatique. Évalué à 2.
Merci pour la correction et la précision :-)
# coût des mails
Posté par raphj . En réponse au lien Réduisez le nombre de courriels si vous voulez lutter contre le réchauffement climatique. Évalué à 10. Dernière modification le 28 janvier 2020 à 23:25.
C'est intéressant. Cependant, malgré le titre, l'article ne semble pas parler du coût des mails lui-même, seulement du coût des datacenters (en tout cas, je n'ai pas vu).
Un mail texte c'est quelques Kio.
J'utilise les mails depuis 2004. Un du -h dans mon dossier /var/mail/vmail/ donne 8G. Une partie des mails sont dupliqués, je pourrais gagner de la place. J'ai aussi tous mes SMS depuis 2017 (435M - oui il y en a beaucoup et stocker les SMS en mail c'est horriblement inefficace - comptez moins de la moitié en version SQLite + images sur le téléphone).
J'aurais probablement intérêt à sortir ces mails du serveur et les stocker sur un ordi qui dort la plupart du temps. C'est en cours de réflexion.
J'ai aussi une boîte pro depuis 2014. Un du -h donne 3.2 G. Il y a beaucoup trop de PDFs en pièces jointes dans cette boîte.
D'accord, tout ça c'est beaucoup et il faut assurer la redondance (donc au moins ×2 ou ×3) (mais bon, je n'utilise pas de compression - j'espère que les gros le font !). Mais en même temps, une heure de vidéos était envoyé sur YouTube chaque minute en 2012. Aujourd'hui j'imagine que c'est beaucoup plus. L'équivalent du poids de ma boite mail sur ma vie entière est utilisé par YouTube en quelques minutes. Et je ne parle que de YouTube (imaginez le nombre de liens, journaux et commentaires envoyés chaque seconde sur LinuxFr par exemple !! Ah ah).
Alors ok, il faut bien voir que YouTube et LinuxFr sont des ressources communes à l'échelle planétaire, contrairement à ma boite mail qui est bien individuelle et en plus, beaucoup des mails dans ma boite sont aussi dans une ou plusieurs autres boites - celles de mes correspondants, voire plus pour les mailing lists).
Je veux bien croire que si tout le monde réduit un peu ses envois et utilise des moyens appropriés pour le transfert de documents, on peut avoir un effet non négligeable, mais combien dans l'absolu et combien en proportion par rapport aux quantités de données autres stockées dans les datacenters ?
Peu de réponses, surtout du questionnement au final :-)
[^] # Re: Esprit potache es-tu là ?
Posté par raphj . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 5. Dernière modification le 28 janvier 2020 à 09:33.
Si les sources de Windows 7 étaient libérées, je suis certain que beaucoup de gens trouveraient quoi faire avec. À commencer, peut-être bien, par le projet Wine.
Et puis si c'est libre, tu peux retirer les problèmes d'invasions de la vie privées :-)
RMS déteste Windows, mais si demain une version libre sans surveillance était publiée, il serait probablement content, parce qu'il ne s'est jamais opposé à Windows pour ses qualités techniques, en tout cas publiquement.
Et si demain, Microsoft décide de publier les versions actuelles de Windows sous licence libre, eh bien on a gagné une partie du « combat ». Pas tout, j'imagine qu'on aurait quand même des problèmes similaires à ceux qu'on a avec Android aujourd'hui.
[^] # Re: Difficile d'en sortir
Posté par raphj . En réponse au journal The Qt Company annonce un changement dans ses « offres ». Évalué à 8.
À priori, on peut utiliser Qt dans le cadre d'un projet non libre tant qu'on n'utilise pas les parties GPL.
À mon avis, il n'y a pas besoin de fuir Qt. Tant qu'il existe des versions libres (ce qui est plus ou moins garanti par l'accord FreeQt), quelqu'un d'autre aura toujours le droit de redistribuer les versions libres de Qt si le mode de distribution par la Qt Company devenait trop contraignant.
[^] # Re: Changer la disposition des touches
Posté par raphj . En réponse au journal Utiliser Vim avec Android, un tuto avec de belles images. Évalué à 2.
Ça marche aussi avec le clavier AOSP standard (et le clavier Google du coup, puisque c'est la même chose avec un ou deux trucs proprio en plus). C'est dans les paramètres du clavier.
# C'est une forge logicielle ?
Posté par raphj . En réponse au lien Pornhub ouvre un miroir sur Tor (pornhubthbh7ap3u.onion). Évalué à 6. Dernière modification le 27 janvier 2020 à 01:26.
Pas le temps de cliquer et d'aller voir, comment se compare-t-elle à github et gitlab ou sourcehut ?
Comment s'appelle son outil de gestion de versions ? Est-ce décentralisé aussi ?
Est-ce libre ? Il y a des chances si c'est publié ici je suppose !
Y a-t-il un comparatif avec des plateformes similaires ?
Est-ce que tor permettra aux iraniens d'accéder aux codes hébergés sur la plateforme ?
[^] # Re: Philosophiquement parlant
Posté par raphj . En réponse au lien Intel's Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance. Évalué à 4.
Mince, en fait le monde est codé en React.
[^] # Re: La base de la base
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 4. Dernière modification le 26 décembre 2019 à 09:38.
Ça KDE s'en charge tout seul, mais la fausse manip impliquait une copie vers
$HOMEqui remplissait la partoche à toute vitesse. Donc ça a juste aidé un diagnostique plus rapide mais pas à prévenir le remplissage total de la partition.Et puis perso, ce genre d'alerte, c'est la dernière chose que je pense à mettre en place sur autre chose qu'un serveur en production. Heureusement que l'environnement de bureau s'en charge :-)
[^] # Re: La base de la base
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 1. Dernière modification le 26 décembre 2019 à 09:22.
(d'autant que j'aborde la question dans le journal : « Je m’en vais ajouter une tâche Cron journalière pour copier ce fichier d'historique dans mon dossier synchronisé, par exemple dans
$DOSSIER/zsh_history-${HOST}»)[^] # Re: La base de la base
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 3.
Exactement : historique partagé.
Chaque session de shell a son historique, mais inscrit les commandes dans un historique commun. Flèche du haut rappelle la ligne précédente dans la session actuelle, mais un appui sur la touche entrée avant flèche du haut charge l'historique produit par les autres sessions parallèles. Très pratique.
[^] # Re: La base de la base
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 8. Dernière modification le 26 décembre 2019 à 09:17.
Personne n'est parfait et on ne prévoit pas tout !
En particulier, mes fichiers importants sont sauvegardés en temps réel avec Nextcloud, instance elle-même sauvegardée chaque nuit dans un sous-volume Btrfs à part sur une autre machine. Ce qui fait que mes données sont à deux endroits physiques à chaque instant, puis à un troisième endroit physique la nuit suivante. J'ai une version journalière de chacun de ces fichiers sur trois ans (sauf les jours où ça s'est planté…). Mais synchroniser l'historique zsh en temps réel comme ça ce n'est pas fou et j'ai dû retirer l'historique zsh de la synchronisation. J'ai reporté la gestion de cette sauvegarde « à plus tard ».
Et bien sûr, pour des raisons de narration, j'en ai rajouté des tonnes. Je survivrais à la perte de mon historique zsh. L'avoir est tout de même un gros confort, d'où une recherche de solution malgré tout. Et vous voyez, je n'ai finalement rien perdu.
Vous avez l'air d'écrire vos commentaires comme si tout le monde était capable de tout prévoir parfaitement. Je n'aime pas trop qu'on vienne me faire la leçon, ce n'est pas le but de ce journal.
[^] # Re: Il manque un s
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 5. Dernière modification le 25 décembre 2019 à 10:26.
« Un jour, j’ai rincé ma machine en essayant d’envoyer un texto à Dédé. Non, c’est une longue histoire… »
Merci pour la correction :-)
# Il manque un s
Posté par raphj . En réponse au journal Restaurer l’historique de zsh. Évalué à 2.
D’ailleurs, heureusement que je n’ai pas de pote dont le diminutif est
rm. Ah ah.Bon la vraie raison de ce commentaire est le signalement de ce manquement à notre belle grammaire dans le journal :
[^] # Re: En Suisse
Posté par raphj . En réponse au journal L’authentification molasse. Évalué à 5.
Ça marchait avec la caisse d'épargne, mais depuis quelques temps la version accessible est juste le clavier virtuel avec prononciation des touches quand elles sont appuyées…
[^] # Re: En Suisse
Posté par raphj . En réponse au journal L’authentification molasse. Évalué à 8.
Sans parler du fait qu'avec leurs claviers virtuels qui bougent tout le temps :
[^] # Re: Spam
Posté par raphj . En réponse à la dépêche ONLYOFFICE : les dernières actualités de l’année 2019. Évalué à 6.
Je ne vois pas pourquoi Microsoft financerait un produit concurrent. Leurs formats sont de toute façon déjà omniprésents, ils n'ont absolument pas besoin d'augmenter un nombre qui est déjà quasi au max.
Cela dit, c'est vrai que les dépêches sur OnlyOffice sont vraiment très fréquentes ici et ça a l'air de déranger certaines personnes. Après, si la suite évolue rapidement, c'est peut-être justifié aussi.
[^] # Re: Libre chez gitlab ?
Posté par raphj . En réponse au journal Faciliter les contributions au code. Évalué à 5. Dernière modification le 17 décembre 2019 à 16:02.
Il semble bien y avoir une fonction terminal (en beta) pour tester. Cherche « Terminal » dans la page. Il y a aussi des liens avec l'intégration continue. Ça paraîtrait dangereux d'envoyer des changements dans un dépôt sans pouvoir les tester avant de toute façon.
Je me trompe peut-être cela dit.
# Libre chez gitlab ?
Posté par raphj . En réponse au journal Faciliter les contributions au code. Évalué à 10. Dernière modification le 17 décembre 2019 à 06:35.
J'ai l'impression que les fonctionnalités décrites correspondent au Web IDE chez Gitlab, qui est, lui, libre et qu'on peut héberger soi-même si besoin.
https://docs.gitlab.com/ee/user/project/web_ide/
Je n'ai essayé ni l'un ni l'autre donc je ne sais pas comment ils se comparent, mais si j'avais besoin d'une telle fonctionnalité, je pense que me tournerais vers cette deuxième solution et j'invite les autres à faire de même.
# Okular
Posté par raphj . En réponse au lien KDE sur Android ? . Évalué à 2. Dernière modification le 14 décembre 2019 à 22:23.
Je suis heureux de voir qu'il y a aussi une version d'Okular pour Android. Pareil, c'est expérimental, bogué, lent mais l'ergonomie paraît intéressante.
Très enthousiasmant. J'aime beaucoup KDE, et utiliser ses applications sur le téléphone serait sympathique. Et, qui sait, ça faciliterait peut-être une transition vers un téléphone sous GNU/Linux plus tard ?
Merci pour le partage en tout cas.
[^] # Re: Index le gestionnaire de fichier de plasma mobile
Posté par raphj . En réponse au lien KDE sur Android ? . Évalué à 3.
Merci pour cette découverte. J'essaierai ça.
Cependant, que penses-tu d'Amaze ? Je le trouve bien ce gestionnaire de fichier pour Android :-)
# Quelques applications KDE sous Android
Posté par raphj . En réponse au lien KDE sur Android ? . Évalué à 4. Dernière modification le 14 décembre 2019 à 22:11.
Ça a l'air d'être lié à ce lien : https://binary-factory.kde.org/view/Android/
Qui montre quelques applications KDE en version Android. Intéressant.
Sinon, oui, oui, et oui, on peut utiliser KDE sous Android à l'aide du Serveur X XSDL et d'un chroot Debian (par exemple). J'ai pu partir en vacances avec seulement mon téléphone et un clavier souple grâce à ça. Beaucoup plus léger et moins volumineux que l'ordinateur + le téléphone.
Plasma marche mieux qu'Xfce avec ce serveur X et je n'ai pas essayé Gnome (avec GTK2, les listes déroulantes ne fonctionnent pas bien, et j'avais déjà observé ça sur une tablette tactile x86 tournant sous une distribution GNU/Linux standard). Et est relativement léger, en fait, malgré son démarrage très lent (c'est certainement mieux sur les version très récente, il y a eu du progrès de ce côté).
Petit problème, il a fallu que j'installe le chroot sur une carte SD parce que la mémoire interne du téléphone est montée avec noexec. Du coup, tout est lent à cause de la carte SD lente… À voir s'il y a moyen de faire quelque chose avec les chroot Termux, qui peuvent s'installer sur la mémoire interne mais qui ont certaines limitations.
Malheureusement, il y a des problèmes avec X Server XSDL depuis Android Pie sur mon téléphone lié à PulseAudio (cross-compilé pour Android ARM64) apparemment. J'ai réussi à restaurer une copie fonctionnelle à l'aide d'une sauvegarde oandbackup (sauf PulseAudio qui ne fonctionne plus) faite sur une version précédente d'Android, mais une nouvelle installation de l'application ne fonctionne plus. Elle n'est plus mise à jour depuis quelques temps, un petit dépoussiérage suffirait peut-être.