lundi 05 janvier

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : BSD

[25] Les CD OpenBSD 3.6 sont disponibles (en avance).
[9] Des nouvelles de FreeBSD 5.3
[55] OpenBSD 3.5 est dans les bacs.
[19] FreeSBIE et GNUStep Live CD
[195] Theo de Raadt décide le fork de Apache
[78] Concours de création d'un nouveau logo pour NetBSD
[4] Surfons sur l'arbre à ports
[17] Le Sagem Fast 800 bientôt supporté par *BSD !
[30] FreeBSD 5.1 sorti
[8] NetBSD sur PDA

Liens connexes

Dépêche modérée par

Ragnagna

Dépêche éditée par

BSD : NetBSD 2.0 vient de sortir.

Posté par patrick_g (page perso, ). Modéré le 10 décembre 2004.

Depuis le 6 décembre l'ISO de la version 2.0 du système NetBSD est disponible (l'annonce officielle vient seulement de paraître sur le site).
NetBSD est un système d'exploitation libre complet dont la philosophie générale est la compatibilité la plus large possible avec les différents types de matériels existants. Il appartient à la famille des BSD qui se caractérise par une licence plus permissive que la GPL de GNU/Linux (pas de Copyleft) et qui comprend OpenBSD (orienté sécurité) et FreeBSD (plus généraliste).

Les nouveautés sont nombreuses dans cette version 2.0 et concernent principalement:

Les performances générales (support des native threads et mécanisme de Scheduler Activation) ;
La montée en charge (scalabilité) ;
Le nouveau système de fichier UFS2 (déjà utilisé par FreeBSD 5.x) ;
La sécurité (signature des exécutables, chiffrement des disques, contrôle des appels système avec systrace) ;
La compatibilité Java ;
Nouvelle chaîne de compilation basée sur GCC 3.3.3 ;
Les nouveaux ports (AMD64, SMP pour les i386, les SPARC et les MacPPC).

> Lire la suite (48 commentaires, moyenne: 2,6). [dépêche : 541 caractères]

Il est à noter que sur le site de NetBSD il n'est pas fait mention du port du système vers les architectures PPC64 ou Itanium ce qui semble étrange et quelque peu décevant. Le portage vers Acorn32 ou Dreamcast, aussi enthousiasmant soit-il, reste très marginal et ne saurait suppléer à l'absence des deux architectures majeures d'IBM et Intel sur un OS dont la portabilité est le but affiché.
Néanmoins la conception même de NetBSD facilitant les portages nul doute que nous verront très vite arriver ces processeurs dans l'arbre de NetBSD.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] Hum

Posté par cho7 () le 10/12/2004 à 10:05. (lien). Évalué à -10.

Ca va encore partir en troll ca...

--
"[...]The memories fire, the rhythms fall slow
Black beauty I love you so"

durée des RC

Posté par thaodalf () le 10/12/2004 à 11:04. (lien). Évalué à 2.

ca fait pas 6 mois ou plus que netBSD 2 est en beta test / RC ?

[^]Re: durée des RC

Posté par Krunch (Jabber id, page perso, ) le 10/12/2004 à 11:15. (lien). Évalué à 7.
C'est probable, en tout cas ça fait plus d'une semaine que la 2.0 est taguée dans le CVS. http://www.feyrer.de/NetBSD/blog.html#20041129(...) (trouvé sur gcu.info)
En attendant c'est le premier changement de version majeur en 10 ans.

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
- [^]Re: durée des RC
  
  Posté par patrick_g (page perso, ) le 10/12/2004 à 11:30. (lien). Évalué à 4.
  sachant que le premier Itanium (Merced) est sorti y'a plus de 4 ans je crois qu'on aurait pu s'attendre à un port vers ce CPU.
  c'est quand même ultra-bizarre que ce soit toujours pas dispo non ? Intel ne fournit pas une babasse de test aux devs de NetBSD ?
  
  je sais je sais : si je veux le port je bosse et j'envoie un patch et toussa...
  - [^]Re: durée des RC
    
    Posté par PsychoFox () le 10/12/2004 à 12:56. (lien). Évalué à 3.
    ben si tu veux un port, donne leur un itanium, c'est aussi simple que ça. S'ils en ont pas, ils peuvent pas le faire, et faut pas attendre que intel ne donne quoique ce soit...
    - [^]Re: durée des RC
      
      Posté par Arachne (page perso, ) le 10/12/2004 à 13:15. (lien). Évalué à 2.
      Et pourquoi Intel ne donnerait pas un Itanium à l'équipe de NetBSD ? Bon OK c'est pas un des OS les plus utilisés, mais ça ne leur couterait pas cher. Je suis prêt à parier que les contribs du kernel ont eu droit au leur. Tiens ça ma donne envie d'envoyer un mail à Intel.
      - [^]Re: durée des RC
        
        Posté par patrick_g (page perso, ) le 10/12/2004 à 13:28. (lien). Évalué à 4.
        surtout qu'il suffit d'un vieux CPU même plus vendu puisque c'est l'arcitecture qui compte !
        Intel y gagne : la pub qui sera faite sur leur don + le portage d'un OS d'excellente qualité.
        
        [^]Re: durée des RC
        
        Posté par PsychoFox () le 10/12/2004 à 15:02. (lien). Évalué à 3.
        ben apparemment ils s'en foutent. Il suffit de voir le peu de dons faits par les entreprises pour des projets comme openbsd et freebsd.
        
        A part 2-3 exceptions, toutes les donations sont faites par des particuliers.
        
        [^]Re: durée des RC
        
        Posté par patrick_g (page perso, ) le 10/12/2004 à 15:26. (lien). Évalué à 3.
        petite estimation :
        un vieux serveur itanium monoprocesseur d'il y a 2-3 ans doit couter à peine quelques milliers de dollars (2000 ?) donc ça ne représente que quelques minutes du budget marketing annuel d'Intel donc le directeur marketing d'Intel est un gros connard incapable qui pour économiser 2000 dollars se prive d'une bonne pub et d'un bon OS.
        petite conclusion :
        Il faut qu'Intel vire son directeur marketing.
        
        [^]Re: durée des RC
        
        Posté par chl (page perso, ) le 10/12/2004 à 15:43. (lien). Évalué à 2.
        petite estimation
        petite conclusion
        
        ma conclusion a moi, est plutot que tu penses trop petit.
        
        [^]Re: durée des RC
        
        Posté par durandal () le 10/12/2004 à 16:21. (lien). Évalué à 5.
        Pas toujours ! ;)
        le directeur marketing d'Intel est un gros connard incapable
        
        Sinon pour moi quelques secondes du budget marketing annuel d'Intel suffiront, merci ;)
        
        [^]Re: durée des RC
        
        Posté par mdlh () le 10/12/2004 à 17:12. (lien). Évalué à 7.
        il est marrant de lire:
        
        Le directeur marketing d'Intel est un gros connard sur le fait qu'Intel n'aurait pas donne de machine Itanium au projet, alors qu'on ne sait pas si Intel l'a fait ou pas....
        
        Par contre, pour avoir vu le nombre de machines Itanium donnees par Intel et autres pour ce genre de developpement, si NetBSD n'en a pas recu, c'est qu'ils ont reellement loupe la vague.
        
        Je me souvient plus de quel projet *BSD il s'agissait, mais il y a quelques annees nu des developeurs kernel Linux pour IA64 faisait mention des developeurs BSD pour Itanium. La question n'est pas de savoir ce qu'il disait, mais le fait est qu'il y avait une equipe de portage a cette epoque.
        
        [^]Re: durée des RC
        
        Posté par Gniarf () le 10/12/2004 à 18:15. (lien). Évalué à 8.
        t'es gentil, ce n'est pas le coût du matériel qui compte ici, mais le coût de la prise de décision et les coûts de suivi des relations NetBSD/Intel ensuite.
        
        des tas de gens impliqués pour des tas d'heures, ça ne sera pas $ 2000.
        
        --
        "Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008

[^]Re: durée des RC

Posté par madflo (page perso, ) le 10/12/2004 à 11:49. (lien). Évalué à 4.
C'était peut être en RC depuis quelques mois, mais je pense que faire une news pour annoncer le tag RELEASE est une bonne chose (même si là c'est un peu tardif) :

a) ca limite le nombre de news (on va pas annoncer chaque étape du release engineering de Free/Net/Open/BSD).
b) des releases de NetBSD, ça n'arrive pas tous les ans non plus.
c) ca permet "aux jeunes" de découvrir d'autres choses.
- [^]Re: durée des RC
  
  Posté par thaodalf () le 10/12/2004 à 12:09. (lien). Évalué à 1.
  c'etait plus ppour signaler mon etonnement face a la sortie. je penser (oui c'est mal ;)) que la release etait deja sortie il y a quelque mois vu que il y a 6 mois minimun ils en etaient déja aux RCs.
  
  c'etait pas une critique mais un étonnement.
  - [^]Re: durée des RC
    
    Posté par madflo (page perso, ) le 11/12/2004 à 09:59. (lien). Évalué à 1.
    Certes, mais n'oublions pas que -RELEASE n'est apposé que pour la... release ;)
    
    Avant, on a pu voir différents tags RC, comme par exemple : netbsd-2-0-RC5, netbsd-2-0-RC4, netbsd-2-0-RC3, netbsd-2-0-RC2, netbsd-2-0-RC1; à chaque étape du processus de release engineering pour la version 2.0.
    
    Par contre, je comprends tout à fait ton étonnement, d'après l'annonce [1] du début du process de release engineering, c'était prévu pour la fin mai... 2004 ;)
    
    [1] : http://mail-index.netbsd.org/netbsd-announce/2004/03/28/0000.html(...)

[+] ça ou LFS

Posté par Loïc Jaouen () le 10/12/2004 à 11:26. (lien). Évalué à -6.

News a rapprocher de celle de LFS.

Sur des machines exotiques ou avec peu de RAM... ben on peu installer LFS ou NetBSD par exemple (il existe quelque autres distro linux avec ulibc une slackware par exemple ou LEAF).

[^]Re: ça ou LFS

Posté par Volnai () le 10/12/2004 à 12:23. (lien). Évalué à 6.
Je ne comprends pas bien en quoi il faut rapprocher ça de LFS, ou même de slackware.

Combien d'architecture sont supportées par LFS et Slack ? NetBSD en supporte quand même pas mal http://www.netbsd.org/Releases/formal-2.0/NetBSD-2.0.html(...)

LFS est une "distribution" Linux à faire sois même pendant des heures, pas Netbsd, qui est un ...BSD (D'ailleurs on est pas sur linuxfr ici ? :) )

Et que vient faire la ulibc ici ?? Netbsd utilise la libc BSD si je ne m'abuse ?
- [^]Re: ça ou LFS
  
  Posté par gallenza () le 10/12/2004 à 14:26. (lien). Évalué à 1.
  De plus NetBSD est fait pour tourner même avec très peu de RAM et des CPU très faibles (25 Mhz par exemple), et que quand bien même une LFS tournerait sur des erchitectures exotiques, il audrait plusieurs semaines pour le compiler !!!
  - [^]Re: ça ou LFS
    
    Posté par Pooly (page perso, ) le 10/12/2004 à 15:38. (lien). Évalué à 5.
    T'es pas forcment obliger de compiler sur la machine ou t'installe... tu cross-compile, t'installe sur un montage NFS. Mais apres je garantie pas que toute la build tool-chain soit dans la norme LFS ;-)
    
    --
    W-Fenec : Webzine rock/métal/indus
- [^]Re: ça ou LFS
  
  Posté par Loïc Jaouen () le 11/12/2004 à 02:59. (lien). Évalué à 2.
  J'ai pas été clair on dirait:
  
  > Je ne comprends pas bien en quoi il faut rapprocher ça de LFS, ou même de slackware.
  
  parce que les deux tournent sur des petites configs
  
  > Combien d'architecture sont supportées par LFS et Slack
  
  beaucoup vu que tu construis toi même toolchain, distrib et tout et tout, tu dois pouvoir supporter la liste des platformes de gcc:
  http://gcc.gnu.org/install/specific.html(...)
  
  > Et que vient faire la ulibc ici
  
  Elle apporte quelques platformes en plus, et permet d'avoir un linux de la même empreinte (footprint) que NetBSD
  
  > LFS est une "distribution" Linux à faire sois même pendant des heures, pas Netbsd
  
  Là je suis d'accord :)
  
  HS: J'en profite pour noter une bizarrerie pour ceux qui veulent pas attendre la fin de la compilation: uwoody, une debian woody en ulibc (x86): http://uclibc.org/news.html(...)
  - [^]Re: ça ou LFS
    
    Posté par Barnabé () le 11/12/2004 à 12:01. (lien). Évalué à 6.
    Dire que la liste des architectures suportées par LFS est la liste des plateformes de gcc est un peu rapide. Tellement rapide que ça ressemble fortement à une grosse erreur...
    - [^]Re: ça ou LFS
      
      Posté par Loïc Jaouen () le 13/12/2004 à 13:17. (lien). Évalué à 0.
      Bien sûr que c'est très rapide, d'ailleurs j'ai usé du conditionnel.
      
      Ceci dit, si le CPU est supporté par:
      - le noyeau
      - une libc
      - le compilateur gcc
      
      alors je vois pas ce qui empêche d'avoir un système qui tourne.
      
      Reste à voir comment et avec quoi ça tourne;
      - matériel 1ère partie: le CPU; des CPU avec et sans MMU n'offrent pas les mêmes possibilités
      - matériel 2ème partie; le reste (tout ce qui est sur la carte mêre ou qui se branche d'une manière ou d'une autre sur la machine); si par exemple, le contrôleur réseau, d'une machine n'est pas reconnu, c'est gênant... tout dépend ce qu'on considère comme un système fonctionnel
      - logiciel; à la liste noyeau, libc, gcc, j'ajouterai busybox pour avoir un minimum d'interaction avec la machine
      
      C'est cette partie logicielle qui fait qu'effectivement une architecture supportée par gcc ne l'est pas *forcément* par LFS... LFS n'utilise pas BusyBox et il faudrait voir la liste de paquets nécessaire à LFS (chapitre 3) et les patches qui vont avec, rien ne dit que ça va tourner sur toutes les platformes du strict trio noyeau,libc et gcc, ni que tel paquet ne va pas systématiquement crasher une platforme sans MMU.
      
      Mais je serais heureux de savoir si je me trompes (j'essaie peut-être en vain de mettre linux sur un vieu routeur de récup' :).
      
      Ref.:
      http://kernel.org/(...) --- scroll down to "What is Linux?"
      http://gcc.gnu.org/install/specific.html(...)
      http://gcc.gnu.org/gcc-3.4/buildstat.html(...)
      http://www.kniggit.net/wwol26.html(...)
      http://www.linuxfromscratch.org/(...) --- chap. 3 du livre
      http://uclibc.org/about.html(...)
      http://busybox.net/FAQ.html#arch(...)
  - [^]Re: ça ou LFS
    
    Posté par Volnai () le 11/12/2004 à 17:49. (lien). Évalué à 3.
    Bof, je ne suis toujours pas convaincu...
    
    Les deux tournent sur de petites configs ? ah ben faut rapprocher ca de Openbsd alors, ou de palmOS tant qu'on y est...
    
    Je ne pense pas que le fait de tourner sur de petites configuration soit spécifique à LFS, mais est plutot du au noyaux linux. Dans l'absolu, rien ne m'empeche de prendre une grossse distrib genre Suse, et de la degrossir au maximum pour qu'elle tourne sur une petite machine.
    
    Ensuite pour le nombre d'architectures supportés, il me semblait (peut être que je me trompe) que le noyaux Linux ne tournait que sur vingtaine de d'architectures differentes (je ne trouve plus d'info là dessus d'ailleurs, si quelqu'un a un lien...), Netbsd est lui plus proche de la cinquantaine, et je ne comprends pas bien en quoi la ulibc rajouterais des architectures à celles supportés par le noyaux ? Le rapport avec Gcc n'est pas si simple a mon avis.
    - [^]Re: ça ou LFS
      
      Posté par fmaz fmaz () le 12/12/2004 à 12:17. (lien). Évalué à 4.
      Pour ce qui est du nombre d'architecture supportée, il faut
      faire attention car debian (entre autre) et NetBSD n'ont pas
      la même définition. Ainsi plusieurs architectures NetBSD peuvent
      correspondre à une seule architecture debian

traduction

Posté par Lucas (page perso, ) le 10/12/2004 à 11:33. (lien). Évalué à 1.

* La montée en charge (scalabilité).

En général, une meilleure traduction de scalability est (aptitude au) passage à l'échelle. Ce n'est pas vraiment la même chose que la montée en charge ...

[^]Re: traduction

Posté par patrick_g (page perso, ) le 10/12/2004 à 12:01. (lien). Évalué à 3.
c'est sans doute une meilleure traduction mais j'y pige que pouic !
Qu'est-ce que tu entends par "aptitude au passage à l'échelle" ?
C'est le fait que quand on ajoute des CPU alors la puissance augmente linéairement ?
- [^]Re: traduction
  
  Posté par Krunch (Jabber id, page perso, ) le 10/12/2004 à 15:29. (lien). Évalué à 5.
  Regarde le graphique de la page 4 du PDF qui a été donné plus bas: http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...) La "scalablity" c'est le fait de continuer de fonctionner normalement sous utilisation intensive. La traduction du Jargon Français c'est "extensibilité". http://www.linux-france.org/prj/jargonf/S/scalability.html(...)
  
  --
  Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
  pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
  - [^]Re: traduction
    
    Posté par patrick_g (page perso, ) le 10/12/2004 à 16:02. (lien). Évalué à 5.
    donc le terme "montée en charge" était parfaitement adéquat !
    - [^]Re: traduction
      
      Posté par Christophe Garault (page perso, ) le 11/12/2004 à 13:15. (lien). Évalué à 3.
      > donc le terme "montée en charge" était parfaitement adéquat !
      
      "aptitude à la montée en charge" m'a toujours semblé être la meilleure traduction.
  - [^]Re: traduction
    
    Posté par Barnabé () le 12/12/2004 à 14:13. (lien). Évalué à 1.
    Le problème, je crois, c'est que le terme anglais scalability a plusieurs sens.
    Dans le cadre de l'article que tu cites, il y a effectivement un sens de « capacité à supporter la montée en charge ».
    
    Par contre, ca peut aussi vouloir dire « capacité à s'adapter à des systèmes de tailles différentes », voir par exemple http://www.osnews.com/story.php?news_id=161(...)

[^]Re: traduction

Posté par Sven Werlen (page perso, ) le 10/12/2004 à 14:03. (lien). Évalué à 4.
Je comprend pas pourquoi on veut toujours traduire les termes techniques. Personnellement, je trouve que ça ne fait qu'embrouiller les gens et on finit par ne plus parler du même sujet. Je ne comprend pas "monté en charge" en encore moins "aptitude au passage à l'échelle", et pourtant c'est exactement ce dont je me préoccupe en ce moment.

Pour moi, scalibility ou éventuellement scalabilité sont les seuls termes que j'utiliserais.
- [^]Re: traduction
  
  Posté par Zorro () le 11/12/2004 à 08:46. (lien). Évalué à 4.
  Heu... C'est marrant, mais moi, c'est exactement l'inverse... Tu me dis scalability, je vois même ce que c'est censé évoquer. Alors que si tu me dis montée en charge, je vois de quoi tu parles.
  C'est dommage, parce que les jargons ne servent au final qu'à exclure les autres.

Thread

Posté par Brice2Nice () le 10/12/2004 à 12:25. (lien). Évalué à 4.

enfin des thread qui marchent, snif c'est trop beau

[^]Re: Thread

Posté par GhZaaark3 () le 10/12/2004 à 14:03. (lien). Évalué à 3.
Enfin des Threads qui marchent pour NetBSD, ou alors au sens plus généraliste et tout os confondu genre: Enfin de vrais Threads qui marchent! Je ne connais pas NetBSD, donc loin de moi l'idée de troller.

--
moué...
- [^]Re: Thread
  
  Posté par xipe () le 10/12/2004 à 14:54. (lien). Évalué à 3.
  C'est enfin des thread qui marche sous netbsd ;-)
  Car il est vrai que les thread sous netbsd n etait pas
  top sur les NetBSD version 1.5/1.6 sur lesquels j ai pu
  developper.

LiveCD

Posté par dab () le 10/12/2004 à 14:59. (lien). Évalué à 9.

A noter qu'il existe également un livecd pour l'architecture x86 ( je ne sais pas pour les autres).
De quoi tester Netbsd sans toucher à son disque dur.

ftp://iso.fr.netbsd.org/pub/NetBSD/iso/2.0/i386live.iso(...)
ftp://iso.fr.netbsd.org/pub/NetBSD/iso/2.0/i386live.iso.torrent(...)

[^]Re: LiveCD

Posté par Krunch (Jabber id, page perso, ) le 10/12/2004 à 15:18. (lien). Évalué à 3.
Et pour ceux qui veulent pas graver un CD, il y a QEMU (ou Xen ou VMWare ou ...).

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Détails techniques

Posté par patrick_g (page perso, ) le 10/12/2004 à 15:02. (lien). Évalué à 7.

A noter également un pdf très intéressant (avec des graphiques montrant que Net BSD 2.0 roxe des mamans ours par rapport à la version 1.6) que j'ai omis de mettre dans les liens :

http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...)

(il pèse 150 ko alors pourquoi se priver ?)

[^]Re: Détails techniques

Posté par Victor STINNER (page perso, ) le 11/12/2004 à 19:18. (lien). Évalué à 3.
http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...)

Je trouve que les nouvelles fonctionnalités ressemblent *beaucoup* à FreeBSD 5.x (kqueue, systrace, ...). A ce que j'en ai compris, ils ont repris du code et l'ont rendu portable sur un max. d'architectures. C'est classe ça ! Ce serait encore mieux si FreeBSD et NetBSD deviennaient un SuperBSD qui serait la combinaison des forces de chacun ... Bon, c'est pas pour demain.

J'suis trop fort, j'ai retrouvé le bench' en question :
http://linuxfr.org/2003/10/19/14323.html(...)

En gros, ça montre en image que Linux 2.6.x et FreeBSD 5.x supportent sans problème une forte monté en charge.

---

Je ne dis pas : "boûh les vilains ! ils repompent FreeBSD !". Au contraire, c'est super que voir que tous les OS libres évoluent dans le bon sens :-)

@+ Haypo
- [^]Re: Détails techniques
  
  Posté par fmaz fmaz () le 12/12/2004 à 12:20. (lien). Évalué à 2.
  D'ailleurs, sur la page en question, le gars se dit impressionné
  par l'équipe NetBSD qui a tenu compte de ses remarques et qui
  a gommé presque tous les problèmes en quelques semaines.

[+] Logo

Posté par cykl (Jabber id, ) le 10/12/2004 à 17:14. (lien). Évalué à -2.

C'est quand même domage de gacher du si beau code par un logo si moche

http://netbsd.org/images/NetBSD-smaller.png(...)

[+] [^]Re: Logo

Posté par dalmassd () le 10/12/2004 à 17:16. (lien). Évalué à -1.
t'as qu'a en faire un!

[^]Re: Logo

Posté par GhZaaark3 () le 10/12/2004 à 17:20. (lien). Évalué à 2.
En tout cas, il est beaucoups, beaucoups mieux que l'ancien, le reste c'est une question de goût.

--
moué...
- [+] [^]Re: Logo
  
  Posté par chl (page perso, ) le 10/12/2004 à 19:20. (lien). Évalué à -2.
  "En tout cas, il est beaucoups, beaucoups mieux que l'ancien, le reste c'est une question de goût."
  
  J'aurais pas dit ça comme ça :
  "En tout cas, le choix d'un logo c'est une question de gout, certains le trouvent mieux que l'ancien, d'autres l'inverse".
  - [^]et apart le logo est elle bien ?
    
    Posté par ... (PrEdAt0r) () le 19/12/2004 à 10:14. (lien). Évalué à 0.
    apart le logo , est ce que cette NetBSD 2.0 est bien ? je veux dire par la , STABLE , rapide ...... ? merci
    
    --
    J'utilise l'Open Source alors faites dont comme moi , libérez vous !

Pilote de disque crypto

Posté par mosfet () le 11/12/2004 à 09:49. (lien). Évalué à 1.

Je me demandais s'il existait sous linux l'equivalent du "cryptographic disk driver" ou pilote de disque crypté en francais dans le texte ?

[^]Re: Pilote de disque crypto

Posté par Julien Danjou (page perso, ) le 11/12/2004 à 11:47. (lien). Évalué à 1.
Regarde du cote de dmcrypt

Revenir en haut de page

Articles précédents : BSD

Liens connexes

Dépêche modérée par

Dépêche éditée par

BSD : NetBSD 2.0 vient de sortir.

[+] Hum

durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[^]Re: durée des RC

[+] ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

[^]Re: ça ou LFS

traduction

[^]Re: traduction

[^]Re: traduction

[^]Re: traduction

[^]Re: traduction

[^]Re: traduction

[^]Re: traduction

[^]Re: traduction

Thread

[^]Re: Thread

[^]Re: Thread

LiveCD

[^]Re: LiveCD

Détails techniques

[^]Re: Détails techniques

[^]Re: Détails techniques

[+] Logo

[+] [^]Re: Logo

[^]Re: Logo

[+] [^]Re: Logo

[^]et apart le logo est elle bien ?

Pilote de disque crypto

[^]Re: Pilote de disque crypto