On y est ! Ubuntu 20.10 sera la première version de la distribution à être proposée pour Raspberry Pi 4 dans sa déclinaison pour ordinateur de bureau (Desktop). Canonical vient de l'annoncer et organisera un live sur YouTube le 23 octobre prochain.
Canonical ne se rapproche pas que de Microsoft à travers son sous-système Linux. L'entreprise derrière la distribution Ubuntu multiplie depuis des mois les initiatives en faveur du Raspberry Pi. On a désormais droit à la publication d'une image spécifique à chaque nouvelle version, mais uniquement pour l'édition Server.
Linux Desktop sur Raspberry Pi : c'est déjà possible
Certes, il est possible d'installer manuellement une interface graphique et de l'utiliser comme un système pour PC de bureau, mais ce n'est pas exactement la même chose. C'est surtout une façon de faire en retrait avec Raspbian OS ou ce que propose par exemple Manjaro, qui met en ligne des images avec i3, KDE Plasma, Sway ou Xfce.
Nombreux sont ceux qui attendaient qu'Ubuntu fasse un choix similaire. Et si des déclarations ici ou là laissaient penser que c'était imminent, rien n'avait clairement été annoncé dans ce sens. Les dernières sorties publiques de Canonical concernaient surtout le monde de l'entreprise et la mise en place des appliances (qui n'ont pas que des avantages).
La feuille de route diffusée l'année dernière n'évoquait tout simplement pas le sujet.
Canonical confirme, une présentation sera organisée en ligne
Mais un live, qui sera organisé sur YouTube le lendemain de la sortie d'Ubuntu 20.10, le 23 octobre à 18h, vient tout changer. Il s'agit cette fois d'une annonce officielle, qui ne laisse plus place au doute :
« Découvrez tout ce qu'il y a à savoir sur la nouvelle image Ubuntu Desktop pour Raspberry Pi. La communauté Ubuntu et Canonical sont fiers d'annoncer que la nouvelle version 20.10 de la distribution apportera l'expérience Ubuntu Desktop complète aux Raspberry Pi 4 de 4 et 8 Go. »
On note que les modèles de 1 et 2 Go semblent exclus, pour des raisons évidentes de confort sur un système complet avec interface graphique, selon la quantité de mémoire disponible. Reste à savoir si l'installation sera tout de même possible. Il y a de grandes chances que ce soit le cas, peut-être avec des avertissement sur les limites d'un tel choix.
Il faudra également se pencher sur la question de l'accélération graphique de l'interface, des scènes 3D ou du contenu vidéo. C'est souvent ce qui pêche sur le Raspberry Pi 4 utilisé comme une machine classique. Des optimisations spécifiques auront-elles été mises en œuvre ? On le découvrira d'ici un peu moins de deux semaines.
Commentaires (13)
#1
C’est bien intéressant. Mais …
Le 1er qui sort un appreil sous RISC-V avec un BIOS/UEFI … il pète le game. On pourra installer l’OS de son choix à l’image de ce qu’on fait sur les desktop x86
#2
#3
D’accord, le raisonnement est rapide et un peu hardcore. Mais bon, imaginons qu’on puisse acheter des téléphones sans OS et qu’on installe un Windows ou un GNU/Linux depuis une clé USB ?
Pourquoi pas ? Plus de problème d’obsolescence logicielle programmée. Combien de téléphone a t’on mis au rebut parce qu’il n’y avait plus de mise à jour pour rester compatible avec les évolutions internet ? Est ce que mécaniquement et électroniquement l’appareil était fini ? Nan. Mais les fabricants sont contents parce que nous sommes obligés de faire comme au tennis : « balles neuves »
UEFI pour RISC-V dans Linux 5.10 :
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-UEFI-RISC-V
(la première RC de linux 5.10 devrait sortir dans quelques jours)
#4
On peut toujours tout imaginer, même des choses sans lien avec la réalité du marché.
Pour RISC-V c’est déjà une réalité (notamment dans l’embarqué), mais ces réactions du genre “NVIDIA investi dans ARM du coup RISC-V va tout emporter” alors qu’avant c’était “ARM va bouffer x86 AHAH” sans plus de cohérence d’analyse derrière, disons que ça me laisse… circonspect.
#5
Le problème des téléphones ne se limite pas à l’archi du CPU. Bien souvent tout l’écosystème autour est archi fermé : modem, GPU, gestion de l’alimentation. Et ces périphériques utilisent des “drivers” propriétaires, et bien fermés.
Passer au risc V ne changerait donc pas la donne pour un téléphone question ouverture aux OS tiers.
#6
Avoir un BIOS sur autre chose que le x86 ou Intel l’a imposé, ainsi que l’UEFI ultérieurement, serait vraiment la dernière des conneries à faire.
Se coller le boulet d’un démarrage initial plus long que celui du système derrière, cela agace l’utilisateur.
Côté développeurs, c’est pire encore avec Intel ne fournissant pas de support (+niveau de documentation absolument déplorable) sur le démarrage (ils vous disent carrément d’aller faire faire le boulot par un des rares éditeurs de BIOS, il y a bien coreboot+blob binaire FSP parfois disponible mais le FSP est loin de permettre ce qu’offre les reference code Intel RC/MRC, sources du FSP, fournis aux seuls Phoenix/AMI/Insyde…).
Sur ARM, il y a bien Microsoft (qui n’a jamais réussi à ne pas se faire mâcher le boulot de la détection HW/énumération PCI ni à se passer de services BIOS puis UEFI pour son runtime) qui a poussé à coller ce tas de m…
Mais RISC-V, ce serait vraiment la dernière chose à faire que d’aller vers ce truc sub-optimal (3 phases quasi étanches: SEC/PEI/DXE, avec des morceaux venant d’Intel/Editeur BIOS… et autant de doublons, souvent multipliés encore par les provenances, de code commun: Comment démarrer vite avec ça?).
Tout cela pour fournir quoi? Un driver model et un sous shell à la syntaxe qui n’est pas sans rappeler le DOS et les fichier.BAT, très inférieur à ce qu’offre un U-BOOT par exemple et pour le dixième de l’empreinte et du temps de démarrage.
Pour résumer le problème, voir l’implémentation de référence EDK2 fournie par Intel (et intégrée par les éditeurs de BIOS, avec leur propre couche et les RC/MRC): Un nombre de lignes de code comparable au kernel Linux. Pour un firmware de démarrage initial!!! Et encore, un BIOS/UEFI commercial ne s’y limite pas (couche éditeurs+les 2 reference codes canoniques d’Intel qui pèsent aussi bien lourd).
Intel et Microsoft devaient avoir qq dinosaures de l’époque DOS à occuper avant la retraite et qui ont été ms à la spécification de cet immondice…
#7
Tout comme le PowerPC reste une réalité (hélas déclinante, plus guère tirée par l’infra télécom en particulier qui se cloudifie et s’intelise) dans l’embarqué qui n’a jamais bouté le x86 du PC. Pourtant l’inélégance comparée et le poids des ans, même à la fin des années 90, laissaient à penser que cela viendrait.
Et on attends encore!
#8
J’ai un iphone 3g dans mon tiroir et je ne sais pas quoi en faire… Si c’était possible d’installer un OS minimaliste je pourrais au moins le transformer en réveil matin, horloge, baromètre ou autre connerie.
A contrario j’avais dans mon placard un vieux pi 2b, il y à un mois je suis tombé dessus et en moins d’une heure j’avais un media center fonctionnel avec vlc + reseau local. Depuis je regarde film + série dessus en l’ayant juste redémarré, une fois.
#9
Dans une moindre mesure, mon Pinebook Pro (netbook ARM) pourrait être plus facilement flashé pour changer d’OS.
Il est livré avec Manjaro par défaut, j’avais envie de voir comment il se comportait sous Fedora. Mais pour le flasher il faut passer par la micro SD, utiliser un utilitaire (qui ne marchait pas, dommage), ou alors se palucher tout à la main pour créer l’image. Bref, devant le fait que je ne suis pas à l’aise avec ces outils et que j’avais peur de le briquer, j’ai laissé tomber.
Si j’avais pu booter sur une clé USB et lancer l’install comme n’importe quel PC x86, j’aurais été plus rassuré.
#10
Pas de bêta disponible je suppose? Je n’ai rien trouvé en tout cas.
#11
Ce que tu dis est sensé et effectivement pour avoir un peu joué avec des éditeurs de bios AMI, ça a l’air d’être un énorme merdier rempli d’historique. Ça fait parti des rares domaines où j’ai fini par abandonner tellement je ne comprenais rien au fonctionnement, au passage respect aux mecs qui reversent et debrident les bios, je ne sais pas où ils ont appris ça mais je dis bravo. L’assembleur, le reverse elf/pe ca va mais le BIOS c’est incompréhensible surtout qu’il y a quasiment 0 documentation que ce soit ami, phoenix ou le troisième.
Par contre il faut absolument une méthode universelle pour booter le matériel Arm/tisc et je pense que c’était le message initial. Ça fait un peu chier de devoir se soumettre à chaque manière de faire pour chaque board.
#12
Non j’ai cherché hier, les bêta ne sont que pour les versions classiques, par sur ARM/Desktop
#13
+1: quand les fabricants de proc ARM passeront enfin tous à de l’UEFI (EBBR ou SBBR), on gagnera vraiment en confort !
J’ai installé hier une fedora 33-beta ARM sur RPI4 avec de l’UEFI, il n’y a aucune difference avec une installation en x86… (Il manque encore quelques binding pour les drivers Wifi & BT, mais rien qui m’empêche de l’utiliser ; encore que je démarre uniquement avec de l’ACPI, faudrait tester avec ACPI+device tree … )