Ce n'est pas vraiment une mise à jour majeure, dans le sens où il y a peu d'évolution au niveau fonctionnalités, mais toujours plus de support au niveau matériel. De plus cette version d'OpenBSD apporte un support des netbook eeepc, voir l'ancienne dépêche.
La chanson accompagnant cette version : Games Attention : il y a une mise à jour importante du protocole pfsync, il n'est pas possible de mixer un pfsync plus vieux avec cette version.
Il est également recommandé de télécharger OpenBSD depuis un miroir officiel (il semble y avoir des sites FTP qui proposent des téléchargements non officiels avec tous les risques que cela suppose). Bien entendu il est encore mieux de commander les CD officiels ! Le projet est développé par des volontaires et il est financé par la vente de T-shirts, de posters et de CD. Si vous le souhaitez vous pouvez également faire un don. Si vous utilisez régulièrement OpenBSD n'oubliez pas de soutenir son développement.
A titre informatif voici une suite d'article paru sur undeadly pour la mise en place d'une plate-forme de firewall redondé avec OpenBSD : Partie 1, 2, 3, 4
Place aux changements :
Matériel :
Le port de OpenBSD vers les plate-formes gumstix et OpenMoko a commencé. Amélioration du support matériel :
- Support de nouveaux sensors ou amélioration : cac(4), mpi(4), gpiodcf(4) (pour DCF77/HBG), schsio(4) (pour SMSC SCH311x), it(4) (pour IT8720F), owtemp(4) (pour Maxim/Dallas DS18B20 et DS1822), km(4) pour les processeur AMD de la famille 11h (Turion X2 Ultra), lm(4) (pour W83627DHG), lmenv(4), sdtemp(4) (pour ST STTS424).
- em(4) gère maintenant les chipsets (ICH9 IGP M et IGP M AMT) et la détection d'état du lien a été amélioré.
- sdmmc(4) gère maintenant les cartes SDHC.
- msk(4) gère maintenant les cartes basées sur du Yukon-2 FE+ (88E8040, 88E8042).
- iwn(4) gère maintenant les cartes wifis basées sur du Intel WiFi Link 5100/5300.
- wpi(4) et iwn(4) gère maintenant le support matériel du chiffrage CCMP.
- ath(4) gère maintenant le WPA-PSK.
- age(4), un nouveau pilote pour les cartes réseaux basées sur du Attansic L1 gigabit.
- ale(4), un nouveau pilote pour les cartes réseaux basées sur du Atheros AR81xx (ou Attansic L1E). Présent par entre autre dans les eeepc.
- mos(4), un nouveau pilote pour les cartes réseaux basées sur du Moschip MCS7730/7830 10/100 USB.
- jme(4), un nouveau pilote pour les cartes réseaux basées sur du JMicron JMC250/JMC260 10/100/1000.
- run(4), un nouveau pilote pour les cartes wifis basées sur du Ralink USB IEEE 802.11a/b/g/Draft-N.
- auacer(4), un nouveau pilote pour les cartes audios basées sur du Acer Labs M5455 audio.
- ifb(4), un nouveau pilote framebuffer (accéléré) pour les cartes Sun Expert3D, Expert3D-Lite, XVR-500, XVR-600 et XVR-1200.
- wildcatfb(4), un nouveau pilote framebuffer (non-accéléré) pour les cartes Sun Expert3D, Expert3D-Lite, XVR-500, XVR-600 et XVR-1200.
- sunffb(4), un nouveau pilote framebuffer (accéléré) pour les cartes Sun Creator, Creator 3D et Elite 3D.
- vdsk(4), un nouveau pilote pour les disques virtuels des domaines logiques sun4v.
- vnet(4), un nouveau pour les adaptateurs réseaux virtuels des domaines logiques sun4v.
- vrng(4), un nouveau pilote pour le générateur de nombres aléatoires des CPU Sun UltraSPARC T2/T2+.
- ips(4), un nouveau pilote pour les contrôleurs Raid SATA/SCSI IBM ServeRAID.
- udfu(4), un nouveau pilote pour les mises à jours firmware (DFU), par exemple pour l'openmoko.
- Beaucoup d'améliorations au niveau de acpi(4).
- umsm(4) gère de nouveaux périphériques EVDO/UMTS.
- mfi(4) gère maintenant les dernières générations de cartes MegaRAID SAS.
- vsbic(4), un nouveau pilote pour les contrôleurs MVME327A SCSI et les contrôleurs de disquette sur les plates-formes mvme68k/mvme88k.
- re(4) gère maintenant les cartes réseaux basées sur du chipsets 8168D/8111D, ainsi que la réception multicast sur les chipsets 8110SB/SC.
- ehci(4) gère maintenant les transferts isochrones.
- Les sorties S/PDIF ont été ajouté aux pilotes ac97(4), auich(4), auvia(4) et azalia(4).
- Le mixer azalia(4) a été simplifié, la gestion des encodages 20-bit/24-bit a été ajoutée.
- Le pilote framebuffer gbe(4) gère maintenant l'accélération.
- ypldap(8), un serveur YP utilisant LDAP comme backend.
- xcompmgr(1) a été ajouté à xenocara (Xorg).
- resolver(3) de la libc peut maintenant être forcé à utilisé des résolutions via TCP via une nouvelle option de resolv.conf(5). De plus, on peut maintenant spécifier un port non-standard pour les serveurs DNS via ce même fichier.
- apropos(1) a maintenant 2 nouvelles options (-S et -s) pour permettre la recherche par architecture et section de manuel.
- aucat(1) peut maintenant fonctionner en mode serveur. Les périphériques audio peuvent maintenant être partagé entre les différentes applications. Les applications peut fonctionner avec des périphériques à échantillonnage fixe ou sur des périphériques avec un encodage inhabituel. Les périphériques audio gérant le Multi-canal peuvent être divisé en plus petit sous-périphériques.
- aucat(1) peut maintenant fonctionner en mode sans périphérique, par exemple pour effectuer du mixage, démultiplexage, ré-échantillonage ou du ré-encodage sur les fichiers...
- ifconfig(8) peut maintenant lister les canaux supporté par un périphérique 802.11.
- De nouvelles vues ont été ajouté à systat(8) : malloc, bucket et pool. Des améliorations ont été effectuées sur les vus déjà existantes.
- vnconfig(8) peut maintenant créer des périphériques avec des géométries arbitraire via l'option -t.
- Les systèmes de fichiers FFS sont maintenant supportés sur la plupart des périphériques, par exemples les CD-ROM, qui ont une taille de secteur différentes de 512 bytes.
Améliorations diverses et nettoyage du code :
- malloc(3) a maintenant une nouvelle mesure d'atténuation des attaques; les structures critiques de 'bookkeeping' sont maintenant protégées à l'exécution via mprotect(2) et allouées à des adresses aléatoires quand cela est possible.
- Une nouvelle version du code gdtoa a été intégrée, celle-ci apporte une meilleure gestion du C99 pour printf(3) et ses amis..
- Améliorations majeures du support de C99 dans libm (dont le support des nombres complexes).
- sppp(4) et pppoe(4) gèrent maintenant des logins / password allant jusqu'à 255 caractères.
- Reconnaissance de différentes variantes de FAT et FAT32.
- Reconnaissance automatiques des bandes avec des enregistrement de 64K.
- Amélioration des supports des options dans dhcpd(8).
- Lorsque vous démarrez à partir d'un CD-ROM, le système de fichiers racine est supposé être sur le CD-ROM, au lieu de toujours demander de l'emplacement.
- Les disklabels construit à partir des disklabels natifs sont désormais soumis aux mêmes tests de consistances que tous les autres disklabels.
- Plus d'affichage des informations de géométrie pour les disques sd(4), puisque cela est presque toujours fictif de nos jours.
- Corrections de support des frames ERROR de tftp, ainsi OpenBSD pxeboot peut maintenant être démarré depuis un serveur tftp pointilleux.
- Beaucoup de pilote scsi(4) réessaye des opérations qui ne peuvent avoir lieu tout de suite plutôt que de laisser tomber de suite.
- MBR et les disklabels DPME ne sont maintenant plus écrit avec des checksums invalides dans certaines circonstances.
Changements de l'installation/mise à jour :
- crunchgen(1) et crunchide(1) ont été mergés en crunchgen(8), qui est maintenant installé par défaut.
- mksuncd(1) est maintenant dans 'base'.
- L'installation via CD-ROM est maintenant géré sur les plates-formes SGI.
- Le mot de passe root peut maintenant contenir des antislash (\).
- Le processus d'installation permet maintenant de configurer plusieurs interfaces via DHCP.
- Le processus de mise à jours utilise maintenant les fichiers protocoles et services du média d'installation.
- Le média d'installation n'a plus besoin de contenir le fichier disktab.
- La vitesse du port série est maintenant correctement sélectionné sur les plates-formes macppc.
Nouvelles fonctionnalités :
- Ajout d'une option à ssh(1) pour forcer l'utilisation de syslog plutôt que stderr.
- Dans le fichier sshd_config(5), la directive ForceCommand accepte maintenant des arguments pour le serveur internal-sftp.
- ssh(1) supporte maintenant la redirection dynamique de ports.
- Gestion du protocole SOCKS4A pour les ports redirigés dynamiquement via ssh(1).
- sshd(8) accepte maintenant les directives PermitEmptyPasswords / AllowAgentForwarding dans les Match blocks.
Corrections de bugs :
- Correction d'un crash de ssh(1) apparu avec openssh5-1 lorsque le client reçois une bannière de 0 byte de long.
- Les extensions de protocole eow@openssh.com et no-more-sessions@openssh.com ne sont envoyées qu'aux serveurs s'annonçant comme étant OpenSSH.
- Éviter l'affichage du message d'avertissement "Non-public channel" dans sshd(8), depuis que ssh(1) envoi un numéro de canal incorrect (~2004); ssh(1) envoi maintenant le numéro correct pour les messages SSH2_MSG_CHANNEL_SUCCESS et SSH2_MSG_CHANNEL_FAILURE.
- Éviter un double-free dans ssh(1) dans la gestion de l'option -L.
- Correction du comportement de fail-on-error dans sftp(1) en mode batch pour les statistiques d'opérations distantes.
- Éviter de bloquer ssh(1) lors d'une connexion à un serveur qui a la directive MaxSessions à 0.
Plus de 5500 ports, amélioration mineure de la robustesse des outils d'installation.
Des paquets déjà compilés pour chaque architecture :
- i386: 5379
- sparc64: 5174
- alpha: 5132
- sh: 1543
- amd64: 5312
- powerpc: 5162
- sparc: 2651
- arm: 4120
- hppa: 4689
- vax: 1718
- mips64: 3278
Entre autres :
- Gnome 2.24.3.
- GNUstep 1.18.0.
- KDE 3.5.10.
- Mozilla Firefox 3.0.6.
- Mozilla Thunderbird 2.0.0.19.
- MySQL 5.0.77.
- OpenOffice.org 2.4.2 and 3.0.1.
- PostgreSQL 8.3.6.
- Xfce 4.4.3.
- OpenArena 0.8.1 (uniquement pour amd64, i386 et macppc)
Le système inclut par défaut des composants majeurs provenant de sources extérieures :
- Xenocara (basé sur X.Org 7.4 + patches, freetype 2.3.7, fontconfig 2.4.2, Mesa 7.2, xterm 239 et d'autres)
- Gcc 2.95.3 (+ patches) et 3.3.5 (+ patches)
- Perl 5.10.0 (+ patches)
- Une version améliorée et sécurisée de Apache 1.3, avec la gestion de SSL/TLS et DSO.
- OpenSSL 0.9.8j (+ patches)
- Groff 1.15
- Sendmail 8.14.3 avec libmilter
- Bind 9.4.2-P2 (+ patches)
- Lynx 2.8.5rel.4 avec la gestion des protocoles HTTPS et IPv6 (+ patches)
- Sudo 1.7
- Ncurses 5.2
- Le dernier pile IPv6 de KAME
- Heimdal 0.7.2 (+ patches)
- Arla 0.35.7
- Binutils 2.15 (+ patches)
- Gdb 6.3 (+ patches)
Aller plus loin
- Le site officiel (7 clics)
- L'annonce officielle par Theo de Raadt (0 clic)
- Les nouveautés d'OpenBSD 4.5 (2 clics)
# KDE 3.5
Posté par ʭ ☯ . Évalué à 3.
.... blague à part, KDE 4.2 m'a presque convaincu de lâcher le 3.5. Allez, ce sera peut-être pour le 4.3 ?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: KDE 3.5
Posté par Kyle_the_hacker . Évalué à 4.
[^] # Re: KDE 3.5
Posté par Romeo . Évalué à 2.
Gnome a aussi quelques releases de retard (2.24 / 2.26).
Je dois avouer que je suis pas du tout gêné, Openbox lui est parfaitement à jour :)
Par contre sur certains logiciels, on peut voir que ça porte vite, midori/webkit par exemple est bien plus rapidement disponible que sur une debian sid.
[^] # Re: KDE 3.5
Posté par gaston . Évalué à 4.
Concernant GNOME, un gros travail d'intégration et de peaufinage est en cours sur le 2.24 (uniquement deux personnes travaillent dessus), il vaut mieux consolider l'existant que suivre aveuglément les nouvelles version, sachant que le 2.26 dépend beaucoup plus de HAL, policykit et pulseaudio, qui ne sont pas encore portés.
Pour webkit/midori, vu que je suis en train de l'utiliser pour taper ce post.. j'essaie de suivre le rythme des sorties, environ une par mois :)
L'intégration de logiciels tiers est un travail demandant du temps, de la rigueur, du peer-rewiewing, sachant qu'il n'y a environ qu'une 20/30aine de développeurs travaillant dessus.. on ne peut pas tout avoir :)
[^] # Re: KDE 3.5
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: KDE 3.5
Posté par Farfouille . Évalué à 2.
http://wiki.xfce.org/midori_faq#user_styles
http://userscripts.org/tags/adblock
Sinon, midori plante régulièrement et très souvent chez moi. Je lui préfère Arora, beaucoup plus stable et tout aussi rapide et léger.
http://code.google.com/p/arora/
[^] # Re: KDE 3.5
Posté par kimelto . Évalué à 1.
[^] # Re: KDE 3.5
Posté par Farfouille . Évalué à 1.
http://www.pps.jussieu.fr/~jch/software/polipo/manual/Censor(...)
http://www.pps.jussieu.fr/~jch/software/polipo/manual/Forbid(...)
http://www.pps.jussieu.fr/~jch/software/polipo/manual/Offlin(...)
# Folklore geek
Posté par eastwind☯ . Évalué à 10.
# Bravo
Posté par psychoslave__ (site web personnel) . Évalué à 3.
s/driver/pilote/
s/news/dépêche/
Merci à Julien.
[^] # Re: Bravo
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Ici : «Le processus d'installation permet maintenant de configuré plusieurs interfaces via DHCP.»
C'est évidemment «configurer».
[^] # Re: Bravo
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Bravo
Posté par lasher . Évalué à 1.
[^] # Re: Bravo
Posté par Étienne . Évalué à 3.
extension étant féminin, il faut accorder envoyées
Pour la négation, il faudrait soit mettre ... sont uniquement envoyées aux serveurs... ou bien ne sont envoyées qu'aux serveurs...
Sinon félicitation pour l'exhaustivité de la dépêche.
Étienne
# Un bon projet
Posté par psychoslave__ (site web personnel) . Évalué à 8.
À mon humble avis, la chose la plus repoussante dans le projet, c'est l'installateur (surtout la partie qui demande de calculer le nombre de cylindre pour la partition du disque).
J'ai bien conscience qu'OpenBSD ne cherche pas à attirer une masse énorme d'utilisateurs et préfère garder un bon ratio développeurs/utilisateurs, et peut être l'installateur sert-il un peu de filtre à ce niveau. Cela étant, un minimum de convivialité avec un installateur en ncurses comme celui de archlinux ne serait pas un mal. D'autant que rien n'empêche de garder l'installateur en mode texte.
Enfin voila pour ma petite critique.
[^] # Re: Un bon projet
Posté par H. Guillaume . Évalué à 1.
l'installateur me bloque.
Alors, ya de la doc,
*
Mais un peu les boules de perdre mes autres partoches en faisant une mauvaise manip.
[^] # Re: Un bon projet
Posté par lasher . Évalué à 0.
[^] # Re: Un bon projet
Posté par bubar🦥 (Mastodon) . Évalué à 1.
[^] # Re: Un bon projet
Posté par Mr Kapouik (site web personnel) . Évalué à 10.
Bien évidement ça marche aussi avec "m" pour les méga octet et "k" pour les kilo octet.
Au moment de la config des disque label si on tape la commande "p" qui sert à afficher les labels existant, on peut taper "p m" pour les afficher en Méga Octet.
Et pour info j'ai réussi à faire installer OpenBSD à un windowsien convaincu en lui donnant la documentation (bon certe il eut un peu de mal).
L'installeur est repoussant seulement : il n'est pas si dur que cela et offre l'avantage d'être complet et clair à utiliser.
[^] # Re: Un bon projet
Posté par herodiade . Évalué à 5.
En pratique, la création ajustée manuellement de partitions DOS avec fdisk ne devrait pas concerner la majorité des utilisateurs (je pense). On en a besoin lorsque on ne souhaite pas dédier l'ensemble du disque à OpenBSD (sinon, il suffit de répondre "yes" à la question "Do you want to use *all* of wd0 for OpenBSD?" et toute cette partie fdisk est zappée comme indiqué dans la doc http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...) ) ; même dans ce cas, il suffit de créer une seule partition (en général l'installeur indique les valeurs min/max, qu'il suffit de recopier pour dire "allouer l'espace restant"). La création de partition DOS est en fait une étape permettant la cohabitation avec les systèmes utilisant ce système. Mais je reconnais volontiers que cette étape mériterai une ergonomie revisitée.
Le partitionnement fin (faire des partitions distinctes pour /, /var, la swap, etc.) tel qu'il est pratiqué par OpenBSD, c'est la création de labels avec disklabel et non les partitions fdisk, et heureusement disklabel est plus "user friendly" (il permet d'indiquer les tailles en bytes, kilobytes, megabytes, gigabytes, etc. au choix).
Cette distinction, ou plutôt ce double mode de partitionnement est souvent déconcertant et opaque pour les nouveaux venus, ce qui est bien dommage.
Donc oui, un fdisk permettant d'indiquer les dimensions en KB, MB et GB serait une bonne chose, mais peut-être encore plus utile serait une doc expliquant clairement ces notions.
Sur ce point, cette page de la doc NetBSD, avec des zolis diagrammes graphiques, est exemplaire ; dommage que la FAQ d'OpenBSD ne l'ai pas reprise ou imitée, mais en attendant vous pouvez la lire : elle s'applique telle quelle pour Open aussi:
http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst(...)
> un installateur en ncurses comme celui de archlinux ne serait pas un mal.
Il faut garder à l'esprit qu'une des contraintes de l'installeur est qu'il doit pouvoir contenir, au grand complet (avec tout les outils nécessaires, le kernel, etc.) sur une et une seule disquette, ce qui limite pas mal les options ;). Ca ne laisse pas de place pour du "futile" comme une libcurse. OpenBSD est sûrement l'un des derniers unix modernes à permettre l'installation à partir d'une seule disquette ; vu le déclin rapide de ce média (est-ce qu'il y a encore des constructeurs qui assemblent des ordis avec un lecteur de disquette de nos jours ?) on peut supposer que cette contrainte pourrait être abandonnée dans quelques temps ...
Sinon je tient à dire que pour un utilisateur habitué, la simplicité et la concision de cet installeur s'avère confortable ; on installe son système en 15mn montre en main et hop, il ronronne :).
[^] # Re: Un bon projet
Posté par Romeo . Évalué à 2.
En effet afin de gagner toujours un peu plus de place Theo de Raadt a estimé que ce n'était pas une fonctionnalité nécessaire sur un média d'installation. Ceci par contre est à mon avis regrettable, mais bon cette suppression n'est clairement pas discutable :)
[^] # Re: Un bon projet
Posté par suJeSelS . Évalué à 3.
[^] # Re: Un bon projet
Posté par reno . Évalué à 5.
Et moi je pense que ceux qui utilisent les OS alternatifs, il y en a une majorité qui font du multiboot et donc qui ne peuvent pas scratcher tout le disk, donc nous sommes en contradiction.
Quelqu'un a t'il des statistiques sur l'utilisation du multiboot?
>>Sinon je tient à dire que pour un utilisateur habitué, la simplicité et la concision de cet installeur s'avère confortable<<
Pour un utilisateur habitué quasiment tout est simple..
C'est bien plus difficile de fournir un outil simple a utiliser pour un nouvel utilisateur!
[^] # Re: Un bon projet
Posté par patrick_g (site web personnel) . Évalué à 5.
Tous ces gens utilisent donc la totalité du disque et ne font pas de multiboot avec OpenBSD.
Mais bon c'est juste un sentiment qui ne s'appuie sur aucune statistique.
[^] # Re: Un bon projet
Posté par herodiade . Évalué à 3.
> plus de gens qui utilisent OpenBSD comme routeur ou firewall
C'est aussi ce que j'avais supposé.
Et supposé par ailleurs que la maturité des outils comme kvm, xen, qemu, virtualbox et compagine devait sérieusement entamer la part d'utilisateurs restants, les curieux qui veulent jeter un oeil : de nos jours il est sans doute plus pratique pour eux de tester en restant dans leur environnement familier, et d'avoir accès aux divers OS simultanément.
Pure supposition pifométrique bien entendu ;), et ça n'enlève rien au constat que le fdisk d'OpenBSD pourrait être moins abscons.
@reno :
> Pour un utilisateur habitué quasiment tout est simple..
> C'est bien plus difficile de fournir un outil simple a utiliser pour un nouvel utilisateur!
Là où les français parlent seulement d'ergonomie, les anglais distinguent subtilement l'usability (efficacité de l'outil pour le type d'utilisateur cible) et la discoverability (facilité d'auto-apprentissage, de découvert de l'outil).
Pour un habitué tout est simple, certes, mais il existe des outils qui leurs permettent d'aller plus vite, d'autres dont la complexité apporte autre chose que de l'efficacité. Par exemple vim, emacs et eclipse ont une assez mauvaise discoverability comparé à MS Word, mais une bien meilleure usability pour certains types d'utilisation.
Voila pourquoi je disais que l'installeur d'OpenBSD est confortable et rapide pour un habitué (je n'ai pas dit qu'il est "simple").
[^] # Re: Un bon projet
Posté par psychoslave__ (site web personnel) . Évalué à 9.
[^] # Re: Un bon projet
Posté par lasher . Évalué à 2.
J'avais l'impression que de plus en plus de gens passaient par la virtualisation pour tester de nouveaux OS... En tout cas c'est ce que je fais.
[^] # Re: Un bon projet
Posté par suJeSelS . Évalué à 2.
Ceci dit il faut maintenant mettre à jour mon routeur/pare-feu :-D
[^] # Re: Un bon projet
Posté par gaston . Évalué à 7.
[^] # Re: Un bon projet
Posté par psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: Un bon projet
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Néanmoins, j'ai installé récemment un NetBSD 5 et un FreeBSD 7.2, et je dois dire que je suis toujours grandement impressionné par la facilité avec laquelle on installe ces systèmes (en ncurses).
Inversement, j'ai été un peu repoussé par PC-BSD et son installeur graphique (d'autant plus qu'il a chié sur ma carte vidéo et que j'avais juste 2/3 de l'ecran…)
A mon avis, si une équipe planche sur une meilleure interface des outils de partionnement et label, t'as de quoi avoir le truc le plus efficace qui soit.
Note pour les devs: serait-il possible,à la fin d'une installation, d'associer un nombre/mot à l'installation ? du genre "il a choisi telle option, je met ce bit à 1, telle autre, tel bit à 0", histoire à la fin d'obtenir un nombre unique qui correspond à la configuration ?
Ainsi, si tu dois réinstaller ton OS (ou dupliquer sa conf ailleurs), t'as juste à entrer le numéro, et l'nstalleur "rejoue" toute ta configuration.
(Je crois qu'autrefois, mandrake proposait de créer une disquette qui permettait ce genre de réinstallation facile)
[^] # Re: Un bon projet
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Un bon projet
Posté par Nicolas Legrand (site web personnel) . Évalué à 4.
Combien ça prend de temps d'installer un OpenBSD ? Cinq minutes :
http://www.youtube.com/watch?v=-UnkASCsL3Q
Et c'est la même interface pour la mise à jour. On peut jongler rapidement entre les scripts, d'install, d'upgrade, le shell, on peut monter des partitions éditer des fichiers, faire des chroot... Bref je n'en connais pas qui apporte autant de chose dans un aussi petit, aussi mignon exécutable. J'ai presque du mal à comprendre pourquoi tout le monde ne fait pas comme lui. Quand je pense à utiliser un autre système qu'Open, les screenshots des installeurs me découragent tout de suite.
Cette installeur est une vraie merveille. À Solution Linux, j'ai dit à un dev Open (Marc Espie) qu'il ne fallait surtout pas le changer, il a rigolé en disant « t'en fais pas. » C'est tant mieux !
# eeePC
Posté par barmic . Évalué à -1.
Pourquoi chaque projet ce sent obligé de se conformer aux eeepc. Il y a pleins d'autre netbook. On est tous contre les monopoles et la première chose que l'on fait s'est s'en réinventer un au niveau matos pour les netbook.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: eeePC
Posté par Nicolas Legrand (site web personnel) . Évalué à 10.
Franchement lancer la pierre à des mecs qui continuent de compiler entièrement leur système sur des antiquités comme des VAX, des Motorola 680x0, des SGI et j'en passe, parce qu'il supporte le matériel de l'eeepc je trouve ça un peu rude.
Jette donc un œil à l'atelier de Miod Vallat :
http://gentiane.org/~miod/machineroom/2009/03/visit02.html
[^] # Re: eeePC
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: eeePC
Posté par Thierry . Évalué à 4.
Et encore, tu n'as pas vu la cave à fromages...
[^] # Re: eeePC
Posté par kowalsky . Évalué à 2.
J'ai pleuré des heures l'autre jour au bureau en voyant toute ces Sun au bureau en pensant que Sun était devenu une branche d'Oracle...
Ne clickez pas sur ce lien, si vous avez un coeur, ne clickez pas.
Bouuuuuhouuuh...
[^] # Re: eeePC
Posté par barmic . Évalué à 4.
Tout le travail netbook se concentre sur les netbook asus, je trouve ça très dommage. D'autant plus que d'autres netbook sont sortis avec des philosophies plus communautaires encore que les eeepc (je pense notamment à l'un d'eux qui n'utilise pas une CPU x86 ni x86_64).
A l'heure actuel, il devient difficile de ne pas croiser de la doc pour un eeePC et c'est dur d'en trouver pour les autres.
Un exemple simple de la sous exposition des concurrents, la dernière version du noyau prend en charge en natif la carte wifi du Wind U100X de MSI, mais pour trouver l'info il faut s'accrocher.
Là dessus vous me dirais que je n'ai qu'a en faire et vous aurais raison. Mais
1) je n'ai qu'un wind et non pas la multitude de netbook possible
2) je n'utilise pas (et ne test pas) des centaines de distributions
Demain je verrais si j'ai de quoi parler du Wind sur le wiki Debian.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Marche pô....
Posté par guillaje (site web personnel) . Évalué à 1.
Mais au premier démarrage, c'est le drame : la séquence de boot reste figée après le message : setting tty flags
Any idea ? (Google n'est pas d'une grande aide...)
versions :
- QEMU PC emulator version 0.9.1 (kvm-84)
- Noyau Linux 2.6.28-11-generic x86_64
[^] # Re: Marche pô....
Posté par guillaje (site web personnel) . Évalué à 1.
[^] # Re: Marche pô....
Posté par Romeo . Évalué à 2.
QEMU PC emulator version 0.10.2, Copyright (c) 2003-2008 Fabrice Bellard
$ wget ftp://ftp.eu.openbsd.org/pub/OpenBSD/4.5/i386/install45.iso
$ qemu-img create openbsd.img 1G
$ qemu -boot d -hda openbsd.img -k fr -cdrom install45.iso
Installation normal, tout depuis le cd.
$ qemu -hda openbsd.img -k fr
ok
"chez moi ça marche"
[^] # Re: Marche pô....
Posté par guillaje (site web personnel) . Évalué à 1.
[^] # Re: Marche pô....
Posté par Romeo . Évalué à 2.
kvm_amd 29580 0
kvm 127464 1 kvm_amd
Anéfé...
# modprobe -r kvm_amd kvm
On recommence, ça marche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.