Pour mon usage, certaines fonctionnalités font cruellement défaut à
OpenBSD. En vrac :
- support des locales (c'est POSIX ça)
- ACPI (tout les nouveaux PC ont ça maintenant)
- software RAID qui rox (RAIDframe c'est bien mais ça oblige à
booter sur un kernel qui est sur une partition non RAID)
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les
prochaines release d'OpenBSD (un genre de TODO avec les grandes
lignes) ?
le 12/06/2005 à 17:25, Thierry Boudet a écrit dans le message :
Le plus simple ici serait de demander à Marc ou Miod qui doivent être un minimum au courant de ce qui se trame...
Il faut demander aux deux, et faire un diff des réponses.
Je préférerai un cat.
-- Benoit Izac
Miod Vallat
Pour mon usage, certaines fonctionnalités font cruellement défaut à OpenBSD. En vrac : - support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
- ACPI (tout les nouveaux PC ont ça maintenant)
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI, mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait être intéressant, mais a été tué dans l'oeuf par les problèmes de l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce que fait Windows et croiser les doigts en espérant que l'on colle de mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est juste un tout petit peu pas assez libre pour OpenBSD.
Sur le long terme, il devrait y avoir du code ACPI pour les plate-formes dépendant d'EFI (i.e. ia64 et, si l'on en croit la rumeur, les futures machines d'Apple), cependant, pour de basses raisons de visibilité des bus pci et autres resssources indispensables.
- software RAID qui rox (RAIDframe c'est bien mais ça oblige à booter sur un kernel qui est sur une partition non RAID)
À ma connaissance il n'y a rien de prévu, la préférence allant au RAID matériel. tedu avait fait un portage de Vinum, mais ni RAIDframe ni Vinum ne semblent être de bonnes solutions sur le long terme.
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les prochaines release d'OpenBSD (un genre de TODO avec les grandes lignes) ?
/dev/crystalbubble ou madamesoleil.google.com
Pour mon usage, certaines fonctionnalités font cruellement défaut à
OpenBSD. En vrac :
- support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
- ACPI (tout les nouveaux PC ont ça maintenant)
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI,
mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait
être intéressant, mais a été tué dans l'oeuf par les problèmes de
l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la
lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce
que fait Windows et croiser les doigts en espérant que l'on colle de
mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est
juste un tout petit peu pas assez libre pour OpenBSD.
Sur le long terme, il devrait y avoir du code ACPI pour les plate-formes
dépendant d'EFI (i.e. ia64 et, si l'on en croit la rumeur, les futures
machines d'Apple), cependant, pour de basses raisons de visibilité des
bus pci et autres resssources indispensables.
- software RAID qui rox (RAIDframe c'est bien mais ça oblige à
booter sur un kernel qui est sur une partition non RAID)
À ma connaissance il n'y a rien de prévu, la préférence allant au
RAID matériel. tedu avait fait un portage de Vinum, mais ni RAIDframe ni
Vinum ne semblent être de bonnes solutions sur le long terme.
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les
prochaines release d'OpenBSD (un genre de TODO avec les grandes
lignes) ?
Pour mon usage, certaines fonctionnalités font cruellement défaut à OpenBSD. En vrac : - support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
- ACPI (tout les nouveaux PC ont ça maintenant)
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI, mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait être intéressant, mais a été tué dans l'oeuf par les problèmes de l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce que fait Windows et croiser les doigts en espérant que l'on colle de mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est juste un tout petit peu pas assez libre pour OpenBSD.
Sur le long terme, il devrait y avoir du code ACPI pour les plate-formes dépendant d'EFI (i.e. ia64 et, si l'on en croit la rumeur, les futures machines d'Apple), cependant, pour de basses raisons de visibilité des bus pci et autres resssources indispensables.
- software RAID qui rox (RAIDframe c'est bien mais ça oblige à booter sur un kernel qui est sur une partition non RAID)
À ma connaissance il n'y a rien de prévu, la préférence allant au RAID matériel. tedu avait fait un portage de Vinum, mais ni RAIDframe ni Vinum ne semblent être de bonnes solutions sur le long terme.
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les prochaines release d'OpenBSD (un genre de TODO avec les grandes lignes) ?
/dev/crystalbubble ou madamesoleil.google.com
Benoit Izac
Bonjour,
le 12/06/2005 à 22:06, Miod Vallat a écrit dans le message <42ac95da$0$10117$ :
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les prochaines release d'OpenBSD (un genre de TODO avec les grandes lignes) ?
/dev/crystalbubble ou madamesoleil.google.com
Je me contenterai de mon /dev/patience.
Merci pour ces réponses. -- Benoit Izac
Bonjour,
le 12/06/2005 à 22:06, Miod Vallat a écrit
dans le message <42ac95da$0$10117$626a14ce@news.free.fr> :
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les
prochaines release d'OpenBSD (un genre de TODO avec les grandes
lignes) ?
le 12/06/2005 à 22:06, Miod Vallat a écrit dans le message <42ac95da$0$10117$ :
Existe-t-il un endroit où l'on peut lire ce qui est prévu dans les prochaines release d'OpenBSD (un genre de TODO avec les grandes lignes) ?
/dev/crystalbubble ou madamesoleil.google.com
Je me contenterai de mon /dev/patience.
Merci pour ces réponses. -- Benoit Izac
espie
In article <42ac95da$0$10117$, Miod Vallat wrote:
Pour mon usage, certaines fonctionnalités font cruellement défaut à OpenBSD. En vrac : - support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
En OpenBSD-current, on a maintenant l'essentiel de l'API pour locale de citrus. Cette API ne mene pour l'instant sur quasiment rien. A savoir que la seule locale effectivement active, c'est la locale C.
Maintenant, ca veut quand meme dire qu'on a les types wchar_t et mbstate_t, les fonctions de manipulation de wide char, de conversions de multibyte en wide chars, les fonctions de classification de wctype, et les fonctions d'entree-sortie. Il ne manque guere que fwprintf et consorts, et les fonctions de gestion du temps correspondantes.
(enfin, il y a un bout en examen chez mes co-developpeurs qui devrait etre committe tres bientot).
Le support C++ est au meme niveau, c'est-a-dire peut-etre un poil en avance que chez Free/Net, puisqu'un peu de chirurgie dans la libstdc++ a permis de reveiller les facets, qui normalement demandent un support C99 complet pour se sortir du pieu.
Bon, l'etape suivante, c'est de s'arranger pour que setlocale() fasse quelque chose. Dans un premier temps, lire les fichiers de donnees de iswctype. Dans un deuxieme temps, mettre les modules de code multi-byte/wide chars qui vont bien. Priorite a unicode et a jis/euc pour de betes raisons personnelles.
Note: meme si ce qui est committe `n'a pas l'air de faire grand chose', l'essentiel des grosses modifs qui cassent toute la libc (plus d'etats dans les FILE *) ont ete committees/vont l'etre, et les tests necessaires de ports qui detectent plein de trucs qu'ils ne voyaient pas prouvent que cette API est maintenant fonctionnelle, meme si elle est plutot limitee dans l'immediat.
ETA: peut-etre OpenBSD 3.8, ou un peu apres si on decide d'etre plus prudent au bout du compte...
In article <42ac95da$0$10117$626a14ce@news.free.fr>,
Miod Vallat <miod@online.fr> wrote:
Pour mon usage, certaines fonctionnalités font cruellement défaut à
OpenBSD. En vrac :
- support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
En OpenBSD-current, on a maintenant l'essentiel de l'API pour locale
de citrus. Cette API ne mene pour l'instant sur quasiment rien. A savoir
que la seule locale effectivement active, c'est la locale C.
Maintenant, ca veut quand meme dire qu'on a les types wchar_t et mbstate_t,
les fonctions de manipulation de wide char, de conversions de multibyte
en wide chars, les fonctions de classification de wctype, et les fonctions
d'entree-sortie. Il ne manque guere que fwprintf et consorts, et les fonctions
de gestion du temps correspondantes.
(enfin, il y a un bout en examen chez mes co-developpeurs qui devrait etre
committe tres bientot).
Le support C++ est au meme niveau, c'est-a-dire peut-etre un poil en avance
que chez Free/Net, puisqu'un peu de chirurgie dans la libstdc++ a permis
de reveiller les facets, qui normalement demandent un support C99 complet
pour se sortir du pieu.
Bon, l'etape suivante, c'est de s'arranger pour que setlocale() fasse quelque
chose. Dans un premier temps, lire les fichiers de donnees de iswctype.
Dans un deuxieme temps, mettre les modules de code multi-byte/wide chars
qui vont bien. Priorite a unicode et a jis/euc pour de betes raisons
personnelles.
Note: meme si ce qui est committe `n'a pas l'air de faire grand chose',
l'essentiel des grosses modifs qui cassent toute la libc (plus d'etats
dans les FILE *) ont ete committees/vont l'etre, et les tests necessaires
de ports qui detectent plein de trucs qu'ils ne voyaient pas prouvent que
cette API est maintenant fonctionnelle, meme si elle est plutot limitee
dans l'immediat.
ETA: peut-etre OpenBSD 3.8, ou un peu apres si on decide d'etre plus prudent
au bout du compte...
Pour mon usage, certaines fonctionnalités font cruellement défaut à OpenBSD. En vrac : - support des locales (c'est POSIX ça)
Faut demander à Marc, c'est lui qui coordonne cette partie.
En OpenBSD-current, on a maintenant l'essentiel de l'API pour locale de citrus. Cette API ne mene pour l'instant sur quasiment rien. A savoir que la seule locale effectivement active, c'est la locale C.
Maintenant, ca veut quand meme dire qu'on a les types wchar_t et mbstate_t, les fonctions de manipulation de wide char, de conversions de multibyte en wide chars, les fonctions de classification de wctype, et les fonctions d'entree-sortie. Il ne manque guere que fwprintf et consorts, et les fonctions de gestion du temps correspondantes.
(enfin, il y a un bout en examen chez mes co-developpeurs qui devrait etre committe tres bientot).
Le support C++ est au meme niveau, c'est-a-dire peut-etre un poil en avance que chez Free/Net, puisqu'un peu de chirurgie dans la libstdc++ a permis de reveiller les facets, qui normalement demandent un support C99 complet pour se sortir du pieu.
Bon, l'etape suivante, c'est de s'arranger pour que setlocale() fasse quelque chose. Dans un premier temps, lire les fichiers de donnees de iswctype. Dans un deuxieme temps, mettre les modules de code multi-byte/wide chars qui vont bien. Priorite a unicode et a jis/euc pour de betes raisons personnelles.
Note: meme si ce qui est committe `n'a pas l'air de faire grand chose', l'essentiel des grosses modifs qui cassent toute la libc (plus d'etats dans les FILE *) ont ete committees/vont l'etre, et les tests necessaires de ports qui detectent plein de trucs qu'ils ne voyaient pas prouvent que cette API est maintenant fonctionnelle, meme si elle est plutot limitee dans l'immediat.
ETA: peut-etre OpenBSD 3.8, ou un peu apres si on decide d'etre plus prudent au bout du compte...
Eric Masson
(Xavier) writes:
Ah non, ça c'est pour Alf.
On m'appelle ?
Éric
-- Subject: Re: procmail NK> comment créer un filtre (...) Menu -> Edition -> Filtres de courrier -> Nouveau. -+- G in: GNU - WISIWYSS (What I See Is What You Should See) -+-
xavier@groumpf.org (Xavier) writes:
Ah non, ça c'est pour Alf.
On m'appelle ?
Éric
--
Subject: Re: procmail
NK> comment créer un filtre (...)
Menu -> Edition -> Filtres de courrier -> Nouveau.
-+- G in: GNU - WISIWYSS (What I See Is What You Should See) -+-
-- Subject: Re: procmail NK> comment créer un filtre (...) Menu -> Edition -> Filtres de courrier -> Nouveau. -+- G in: GNU - WISIWYSS (What I See Is What You Should See) -+-
Miod Vallat
/dev/crystalbubble ou madamesoleil.google.com
[pinaï] /dev/crystallball
Au prix où coûte le crystal de divination, tout le monde ne peut pas se permettre un ustensile de grande taille, dis !
/dev/crystalbubble ou madamesoleil.google.com
[pinaï] /dev/crystallball
Au prix où coûte le crystal de divination, tout le monde ne peut pas se
permettre un ustensile de grande taille, dis !
Au prix où coûte le crystal de divination, tout le monde ne peut pas se permettre un ustensile de grande taille, dis !
Ducrot Bruno
On 12 Jun 2005 20:06:50 GMT, Miod Vallat wrote:
- ACPI (tout les nouveaux PC ont ça maintenant)
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI, mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait être intéressant, mais a été tué dans l'oeuf par les problèmes de l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce que fait Windows et croiser les doigts en espérant que l'on colle de mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est juste un tout petit peu pas assez libre pour OpenBSD.
En fait, il n'y a pas le choix : il faut coller à ce que fait Windows, ce qui fait tout le charme de l'ACPI, si l'on peut dire.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 12 Jun 2005 20:06:50 GMT, Miod Vallat <miod@online.fr> wrote:
- ACPI (tout les nouveaux PC ont ça maintenant)
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI,
mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait
être intéressant, mais a été tué dans l'oeuf par les problèmes de
l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la
lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce
que fait Windows et croiser les doigts en espérant que l'on colle de
mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est
juste un tout petit peu pas assez libre pour OpenBSD.
En fait, il n'y a pas le choix : il faut coller à ce que fait Windows,
ce qui fait tout le charme de l'ACPI, si l'on peut dire.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Y'a du code importé récemment pour faire deux ou trois trucs avec ACPI, mais rien d'activé pour le moment. ACPI reste quelque chose qui pourrait être intéressant, mais a été tué dans l'oeuf par les problèmes de l'interpréteur Microsoft qui ont conduit à des contournements matériels.
C'est devenu un vrai sac de noeuds. On a le choix entre coller à la lettre à la spec et avoir des problèmes sur du matériel, ou coller à ce que fait Windows et croiser les doigts en espérant que l'on colle de mieux possible. S'y ajoute la licence du code ACPICA d'Intel, qui est juste un tout petit peu pas assez libre pour OpenBSD.
En fait, il n'y a pas le choix : il faut coller à ce que fait Windows, ce qui fait tout le charme de l'ACPI, si l'on peut dire.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
