je suis en train de m'amuser à faire un cd live et même si c'est pas le
truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois
que ça puisse être (in)utile à d'autres.
Comme c'est extrêmement basique, il n'y a pas d'autodétection du
matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre
chose que qemu j'en serais très étonné.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
l'indien
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-) Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le
truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois
que ça puisse être (in)utile à d'autres.
Comme c'est extrêmement basique, il n'y a pas d'autodétection du
matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre
chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon
véritable objectif, d'ailleurs toute idée pour réduire la taille
m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif,
tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
Comme ça, c'est "chipable" dans une flash standard de carte mère.
L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64
ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas
que ce soit utile en soi, mais c'est une bonne approche pour faire des
distrib pour matériel embarqué qui ont typiquement ces contraintes.
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-) Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
Ronald
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et sur 8Mo en se limitant à une utilisation spécifique et juste le strict nécessaire.
Mais bon, j'ai déjà du mal à descendre à 60Mo sans sacrifier trop de fonctionnalités, je crois que je vais être obligé de faire de la place et supprimer une partie des locales et des entrées terminfo.
OpenOffice je n'y pense même pas, j'ai trouvé lout mais je n'ai pas encore vu en détail ce que ça donne.
Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en ressources, il faut se les fixer soit même.
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2, avec -kernel.
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas
le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès
fois que ça puisse être (in)utile à d'autres. Comme c'est
extrêmement basique, il n'y a pas d'autodétection du matériel,
autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que
qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon
véritable objectif, d'ailleurs toute idée pour réduire la taille
m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif,
tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et
sur 8Mo en se limitant à une utilisation spécifique et juste le strict
nécessaire.
Mais bon, j'ai déjà du mal à descendre à 60Mo sans sacrifier trop de
fonctionnalités, je crois que je vais être obligé de faire de la
place et supprimer une partie des locales et des entrées terminfo.
OpenOffice je n'y pense même pas, j'ai trouvé lout mais je n'ai pas
encore vu en détail ce que ça donne.
Comme ça, c'est "chipable" dans une flash standard de carte mère.
L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait
64 ko, ça permet d'avoir une distrib "ROM-based".
Bon, je ne prétend
pas que ce soit utile en soi, mais c'est une bonne approche pour faire
des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en
ressources, il faut se les fixer soit même.
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2,
avec -kernel.
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et sur 8Mo en se limitant à une utilisation spécifique et juste le strict nécessaire.
Mais bon, j'ai déjà du mal à descendre à 60Mo sans sacrifier trop de fonctionnalités, je crois que je vais être obligé de faire de la place et supprimer une partie des locales et des entrées terminfo.
OpenOffice je n'y pense même pas, j'ai trouvé lout mais je n'ai pas encore vu en détail ce que ça donne.
Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en ressources, il faut se les fixer soit même.
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2, avec -kernel.
Nicolas George
Ronald wrote in message :
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes de base et une ou deux polices) en environ trois méga-octets sans compression, si on choisit un serveur tiny-X.
Ronald wrote in message <pan.2005.03.24.01.51.25.975214@reply.to>:
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes
de base et une ou deux polices) en environ trois méga-octets sans
compression, si on choisit un serveur tiny-X.
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes de base et une ou deux polices) en environ trois méga-octets sans compression, si on choisit un serveur tiny-X.
Ronald
Le Thu, 24 Mar 2005 02:18:40 +0000, Nicolas George a écrit :
Ronald wrote in message :
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes de base et une ou deux polices) en environ trois méga-octets sans compression, si on choisit un serveur tiny-X.
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo, c'est vrai que les polices ne sont pas vraiment nécessaires avec les serveurs kdrive, mais par contre c'est au niveau du choix des clients que ça risque d'être limité suivant les libs nécessaires, si c'est pour lancer des applications console dans un xterm, autant utiliser directement la console en exploitant le framebuffer, et avoir juste Xfbdev pour une utilisation comme terminal X, ça permet d'avoir un système plus complet même si c'est au détriment de la convivialité supposée de l'interface graphique, enfin, c'est mon avis.
Le Thu, 24 Mar 2005 02:18:40 +0000, Nicolas George a écrit :
Ronald wrote in message <pan.2005.03.24.01.51.25.975214@reply.to>:
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes
de base et une ou deux polices) en environ trois méga-octets sans
compression, si on choisit un serveur tiny-X.
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo,
c'est vrai que les polices ne sont pas vraiment nécessaires avec les
serveurs kdrive, mais par contre c'est au niveau du choix des clients que
ça risque d'être limité suivant les libs nécessaires, si c'est
pour lancer des applications console dans un xterm, autant utiliser
directement la console en exploitant le framebuffer, et
avoir juste Xfbdev pour une utilisation comme terminal X, ça permet
d'avoir un système plus complet même si c'est au détriment de la
convivialité supposée de l'interface graphique, enfin, c'est mon avis.
Le Thu, 24 Mar 2005 02:18:40 +0000, Nicolas George a écrit :
Ronald wrote in message :
16Mo sans X alors, ça devrait être possible et pas trop spartiate
On peut faire tenir un X11 opérationnel (serveur, bibliothèques clientes de base et une ou deux polices) en environ trois méga-octets sans compression, si on choisit un serveur tiny-X.
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo, c'est vrai que les polices ne sont pas vraiment nécessaires avec les serveurs kdrive, mais par contre c'est au niveau du choix des clients que ça risque d'être limité suivant les libs nécessaires, si c'est pour lancer des applications console dans un xterm, autant utiliser directement la console en exploitant le framebuffer, et avoir juste Xfbdev pour une utilisation comme terminal X, ça permet d'avoir un système plus complet même si c'est au détriment de la convivialité supposée de l'interface graphique, enfin, c'est mon avis.
Nicolas George
Ronald wrote in message :
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo,
C'est à peu près ça. J'en ai un ici de 700 ko, plus 270 ko pour libfreetype (je ne compte pas la libc, ni la libz, qui sont nécessaires en elles-mêmes). C'est compilé pour ARM, des binaires pour ix86 seraient probablement un poil plus petits.
mais par contre c'est au niveau du choix des clients que ça risque d'être limité suivant les libs nécessaires, si c'est pour lancer des applications console dans un xterm, autant utiliser directement la console en exploitant le framebuffer
C'est un peu vrai, mais pas complètement. En cherchant convenablement, on peut trouver quelques applications sympa basées sur Xt et Athena. C'est pas le grand luxe, mais on peut avoir quelque chose d'utilisable.
Ronald wrote in message <pan.2005.03.24.06.52.46.916439@reply.to>:
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo,
C'est à peu près ça. J'en ai un ici de 700 ko, plus 270 ko pour libfreetype
(je ne compte pas la libc, ni la libz, qui sont nécessaires en elles-mêmes).
C'est compilé pour ARM, des binaires pour ix86 seraient probablement un poil
plus petits.
mais par contre c'est au niveau du choix des clients que
ça risque d'être limité suivant les libs nécessaires, si c'est
pour lancer des applications console dans un xterm, autant utiliser
directement la console en exploitant le framebuffer
C'est un peu vrai, mais pas complètement. En cherchant convenablement, on
peut trouver quelques applications sympa basées sur Xt et Athena. C'est pas
le grand luxe, mais on peut avoir quelque chose d'utilisable.
De mémoire même un Xvesa ou Xfbdev en utilisant uclibc, approche du Mo,
C'est à peu près ça. J'en ai un ici de 700 ko, plus 270 ko pour libfreetype (je ne compte pas la libc, ni la libz, qui sont nécessaires en elles-mêmes). C'est compilé pour ARM, des binaires pour ix86 seraient probablement un poil plus petits.
mais par contre c'est au niveau du choix des clients que ça risque d'être limité suivant les libs nécessaires, si c'est pour lancer des applications console dans un xterm, autant utiliser directement la console en exploitant le framebuffer
C'est un peu vrai, mais pas complètement. En cherchant convenablement, on peut trouver quelques applications sympa basées sur Xt et Athena. C'est pas le grand luxe, mais on peut avoir quelque chose d'utilisable.
l'indien
On Thu, 24 Mar 2005 02:51:26 +0100, Ronald wrote:
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et sur 8Mo en se limitant à une utilisation spécifique et juste le strict nécessaire.
Oui, je pense à une distribution basé sur des outils en frame-buffer. Ou, à la rigueur, un terminal X/VNC/rdesktop.
[...]
Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en ressources, il faut se les fixer soit même.
Et oui...
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2, avec -kernel.
Essaie la release-candidate: <http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4-rc_bin.tar.bz2> J'ai encore fixé d'autres choses. A noter que le boot sur disquette fait crasher qemu chez moi (mais c'est peut-être spécifique à l'amd64). Par contre, avec -kernel, c'est censé bien marcher. Le boot sur CD également. Pour un boot PREP sur disque, je ne sais pas...
On Thu, 24 Mar 2005 02:51:26 +0100, Ronald wrote:
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas
le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès
fois que ça puisse être (in)utile à d'autres. Comme c'est
extrêmement basique, il n'y a pas d'autodétection du matériel,
autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que
qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon
véritable objectif, d'ailleurs toute idée pour réduire la taille
m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif,
tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et
sur 8Mo en se limitant à une utilisation spécifique et juste le strict
nécessaire.
Oui, je pense à une distribution basé sur des outils en frame-buffer.
Ou, à la rigueur, un terminal X/VNC/rdesktop.
[...]
Comme ça, c'est "chipable" dans une flash standard de carte mère.
L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait
64 ko, ça permet d'avoir une distrib "ROM-based".
Bon, je ne prétend
pas que ce soit utile en soi, mais c'est une bonne approche pour faire
des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en
ressources, il faut se les fixer soit même.
Et oui...
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2,
avec -kernel.
Essaie la release-candidate:
<http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4-rc_bin.tar.bz2>
J'ai encore fixé d'autres choses.
A noter que le boot sur disquette fait crasher qemu chez moi (mais c'est
peut-être spécifique à l'amd64). Par contre, avec -kernel, c'est censé
bien marcher. Le boot sur CD également.
Pour un boot PREP sur disque, je ne sais pas...
Le Wed, 23 Mar 2005 22:52:23 +0100, l'indien a écrit :
On Wed, 23 Mar 2005 21:04:48 +0100, Ronald wrote:
'lut tous
je suis en train de m'amuser à faire un cd live et même si c'est pas le truc le plus révolutionnaire, je l'ai quand même mis en ligne dès fois que ça puisse être (in)utile à d'autres. Comme c'est extrêmement basique, il n'y a pas d'autodétection du matériel, autoconfiguration, etc ... et si ça tourne tel quel sur autre chose que qemu j'en serais très étonné.
~66Mo au total, ouais c'est encore trop pour une clé de 64Mo, mon véritable objectif, d'ailleurs toute idée pour réduire la taille m'intéresse :(
8 ou 16 Mo, y compris la detection du matériel, c'est un bon objectif, tout à fait réaliste. Enfin, si tu ne met pas Open-Office ;-)
16Mo sans X alors, ça devrait être possible et pas trop spartiate, et sur 8Mo en se limitant à une utilisation spécifique et juste le strict nécessaire.
Oui, je pense à une distribution basé sur des outils en frame-buffer. Ou, à la rigueur, un terminal X/VNC/rdesktop.
[...]
Comme ça, c'est "chipable" dans une flash standard de carte mère. L'idéal serait d'avoir avec la partie BIOS. Comme celui dans qemu fait 64 ko, ça permet d'avoir une distrib "ROM-based". Bon, je ne prétend pas que ce soit utile en soi, mais c'est une bonne approche pour faire des distrib pour matériel embarqué qui ont typiquement ces contraintes.
C'est toujours intéressant, vu que sur pc il n'y a que peu de limites en ressources, il faut se les fixer soit même.
Et oui...
Au fait qemu-system-ppc tourne en prep avec OpenHack'Ware 0.4-pre2, avec -kernel.
Essaie la release-candidate: <http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4-rc_bin.tar.bz2> J'ai encore fixé d'autres choses. A noter que le boot sur disquette fait crasher qemu chez moi (mais c'est peut-être spécifique à l'amd64). Par contre, avec -kernel, c'est censé bien marcher. Le boot sur CD également. Pour un boot PREP sur disque, je ne sais pas...
