Après une ré-écriture quasi intégrale d'éléments clés du noyau (ordonnanceur, système de mémoire virtuelle, systèmes de fichiers), cette 13ième version apporte son grand lot de nouveautés, en posant de nouvelles bases qui font de cette version 5.0 une des plus importantes, si ce n'est la plus importante, du projet. Une grande partie du noyau a été ré-écrite, dans l'optique d'un meilleur support des architectures informatiques actuelles et à venir, notamment avec l'apparition des multi-cores et de la généralisation du SMP.
On note en particulier:
- la refonte de l'ordonnanceur et de la gestion des processus, avec un bien meilleur support des LWPs (Processus_léger)
- le système de mémoire virtuelle ré-écrit en granularité fine
- le modèle de threads, qui passe d'un modèle M:N (basé sur les scheduler activations) à un modèle 1:1, inspiré de Solaris, plus proche de POSIX, et surtout, plus facile à maintenir que l'ancienne implémentation.
- des systèmes de fichiers retouchés, afin de les adapter aux nouvelles primitives de synchronisation
- amélioration (très) importante de performances sur machine multicore, avec l'apparition d'allocateurs tenant compte de la topologie des caches CPUs
- FFS journalisé (via WAPBL)
- support de l'ACPI
- un framework complet de gestion de l'énergie
- préemption complète du noyau pour les threads temps réel
- I/O asynchrones POSIX
- support des extensions temps-réel POSIX
- concepts de sets CPUs, affinités, offline/online (similaire à Solaris)
- support de FUSE (via PUFFS)
- jemalloc() en standard
- un énorme framework de test de régressions sur le noyau (via ATF, automated testing framework)
- support de Xen 3.3 sur i386 et amd64
- passage de Xfree vers X.org sur la plupart des ports, dont l'x86 (i386 et amd64)
- support UDF en écriture (pour les DVD surtout)
- et pleines d'autres (opérations atomiques, algorithmes lockless, etc.)
La version 6, sur laquelle le travail a déjà commencé, devrait apporter le support des NUMA, de ZFS, une pile réseau remise à neuf, le support du PCI-passthrough et du save/restore de Xen, une grande modularité dans le noyau, et le support de patchs binaires.
Aller plus loin
- L'annonce officielle (3 clics)
- Le site officiel (3 clics)
- Le blog du projet (1 clic)
- Les nouveautés (fonctionnalités, benchmarks...) (3 clics)
- La nouvelle sur NetBSDfr (7 clics)
- Les torrents pour télécharger (7 clics)
# Hmmm...
Posté par GEDsismik (site web personnel) . Évalué à 3.
Espérons que les montées de versions soient toujours aussi simples.
# Benchmark
Posté par patrick_g (site web personnel) . Évalué à 10.
Ce qui serait vraiment utile c'est que quelqu'un fasse un bon gros benchmark de tous ces BSD contre le dernier noyau Linux stable afin de voir ou on en est.
Un peu comme ce qu'on avait eu ici à l'époque : http://bulk.fefe.de/scalability/
En tout cas merci pour la belle news.
[^] # Re: Benchmark
Posté par gaston . Évalué à 2.
[^] # Re: Benchmark
Posté par patrick_g (site web personnel) . Évalué à 8.
Avant d'affirmer que cet éventuel benchmark futur ne voudrait rien dire peut-être faudrait-il l'examiner techniquement et juger de sa représentativité et de la pertinence de ses conclusions ?
Ou alors tu rejettes les futures conclusions par avance parce que tu soutiens aveuglément l'un des OS en course...OpenBSD au hasard ?
Enfin bon tant qu'une bonne âme ne se lance pas dans ce travail de benchmark tout ça reste hypothétique.
A noter qu'un des liens de la news propose un tel benchmark : http://www.netbsd.org/~ad/50/
Évidemment comme c'est un test réalisé par un dev de NetBSD il faut se méfier un peu mais bon ça reste intéressant.
[^] # Re: Benchmark
Posté par gaston . Évalué à 1.
Personnellement, quand je dois choisir un OS pour une tâche particulière, je ne me base pas sur des graphes, mais je les essaie, et j'expérimente.
Quand a ton 'attaque personnelle' sur OpenBSD, c'est tellement bas... à ma connaissance il n'est pas 'en course' avec les autres. C'est tellement important d'avoir la plus grosse de nos jours après tout...
[^] # Re: Benchmark
Posté par patrick_g (site web personnel) . Évalué à 5.
Ou est-ce que j'ai dit ça ? On se base sur un bon benchmark pour comparer les performances c'est tout.
Il est évident, comme tu le souligne, qu'il y a beaucoup d'autres critères pour choisir un OS que les performances pures.
Dans mon post initial j'ai juste souhaité un comparatif "afin de voir ou on en est" (sous-entendu sur les performances). Je n'ai jamais dit que ce benchmark désignerait le meilleur OS tout critère confondus.
Concernant OpenBSD ce n'était en aucun cas une attaque personnelle. J'aime beaucoup cet OS, bien plus que FreeBSD par exemple (je ne connais pas du tout NetBSD) et je pense que sur son créneau particulier il est quasi-imbattable.
[^] # Re: Benchmark
Posté par bubar🦥 (Mastodon) . Évalué à 3.
[^] # Re: Benchmark
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Benchmark
Posté par ptit_o . Évalué à 0.
Je n'ai aucune connaissance pour pouvoir affirmer, que l'un est supérieur aux autres, mais simplement une nette préférence dans les systèmes BSD, en tant que desktop. Pour moi NetBSD reste la référence au niveau des BSD (peut être, du fait qu'il a été le premier système que j'ai installé).
[1] à chaque fois de nouveaux drivers pas forcément bien aboutis.
[^] # Re: Benchmark
Posté par bubar🦥 (Mastodon) . Évalué à 4.
tu prends un bout de code du kernel netbsd, un autre faisant une tache similaire sur openbsd et enfin un autre (toujours pour une tache similaire) à linux.
Puis tu files ce bout de code à 1.groupe d' étudiant. 2.groupe de nerds. Sans leur dit d' où ça vient mais juste ce que ça fait.
Ensuite tu ramasses les copies :p
Blague à part, une phrase apprise lorsque j' étais bien jeune, educ spé, toussa :
"un test ne teste que ce qu' il teste, au moment où il le teste"
con, non ? et pourtant, marrant ça s' applique pas qu' au wisk ou swiz mais aussi ici :p
[^] # Re: Benchmark
Posté par Laurent Cligny (site web personnel) . Évalué à 10.
De tels tests rigoureux entre systèmes permettent à tout le monde d'avancer, si on sait se projeter au delà du concours de celui qui à la plus grosse (performance).
[^] # Re: Benchmark
Posté par bubar🦥 (Mastodon) . Évalué à 0.
Bon allez je sors de votre news avec mes 2 blagues pourries à 2 balles. Désolé. Et merci pour cette dépêche claire et concise. Moi qui ne connait pas du tout NetBSD ça donne envie d' aller voir.
[^] # Re: Benchmark
Posté par gweisenh . Évalué à 4.
disponible ici http://www.netbsd.org/~ad/50/ via l'excellent webblog de
Hubert Feyrer : http://www.feyrer.de/NetBSD/blog.html/nb_20090430_0022.html
Dans la sortie des systèmes *BSD, j'ajoute que la Libellule fait parti de la fête avec une nouvelle version de
DragonFlyBSD en 2.2.1: http://www.shiningsilence.com/dbsdlog/2009/04/29/4135.html
# OldSchool
Posté par kowalsky . Évalué à 3.
Vive les BSD, vive NetBSD.
ps : et vive Linux quand même ! :)
[^] # Re: OldSchool
Posté par Maclag . Évalué à 5.
[^] # Re: OldSchool
Posté par Farfouille . Évalué à 2.
XDirectFB : http://www.directfb.org/index.php?path=Projects%2FXDirectFB
Xynth : http://alperakcan.org/?open=projects&project=xynth
[^] # Re: OldSchool
Posté par Brioche4012 (site web personnel) . Évalué à 2.
Sinon, je n'ai jamais entendu parler de cette fusion entre Xorg et Linux. Cela me semble être une hérésie absolue. Pourriez vous donner un lien ou on pourrait en apprendre davantage?
Ah, et puis je vais essayer netbsd par curiosité. Je n'ai jamais été fichu d'installer un *BSD, donc cette fois sera peut etre la bonne!
[^] # Re: OldSchool
Posté par patrick_g (site web personnel) . Évalué à 3.
Bah je pense que c'est juste l'intégration de la gestion des modes de la carte graphique dans le noyau.
Va lire ce journal pour avoir des détails : http://linuxfr.org/~yannig/28193.html
# NetBSD Desktop Project
Posté par B16F4RV4RD1N . Évalué à 3.
Alors bien sûr, on va avoir les vieux geeks (ou bien les jeunes geeks qui aiment se torturer l'esprit) qui vont argumenter, "pkg_add -r logiciel" c'est trop super (super de piocher au petit bonheur la chance pour espérer trouver le nom correct des paquets, et dans le meilleur des cas de récupérer un paquet obsolète). Ah ben non sinon, il faut taper cd /usr/ports/chemin_complet/du_logiciel puis make && make install et 25 minutes après on a un beau paquet sdl tout neuf...
Et puis pour tout mettre à jour, portupgrade et compagnie, bref, autant de méthode différentes, longues, hasardeuses pour celui qui souhaite avoir rapidement des logiciels unix à jour (sauf quand on veut faire un bête serveur http).
L'idée des ports et de pkgsrc c'est bien, mais c'est pas très pratique et moderne quand on compare à apt-get de Debian ou pacman (yaourt) de Archlinux. Et quel dommage de ne pas avoir des paquets binaires à installer de façon conviviale comme dans ces 2 exemples de distributions linux. (sur archlinux yaourt n'existe qu'en version console, et pourtant c'est un plaisir à utiliser)
Pour preuve que chez NetBSD on n'a pas que de vieux geeks aigris ou de jeunes geeks masochistes, car ils cherchent à sorti NetBSD des années 1980, et souhaitent fournir un installateur moderne et pratique pour l'utilisateur des années 2009.
Ces pistes de réflexions se trouvent ici, dommage que cela n'ait pas l'air de bouger depuis février dernier : http://wiki.netbsd.se/Desktop_Project
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: NetBSD Desktop Project
Posté par Adrien . Évalué à 3.
Debian/kNetBSD ?
[^] # Re: NetBSD Desktop Project
Posté par pikapika . Évalué à 1.
on peut encore trouver le vieux systeme ici : http://www.srcf.ucam.org/debian-netbsd/
[^] # Re: NetBSD Desktop Project
Posté par pikapika . Évalué à 1.
[^] # Re: NetBSD Desktop Project
Posté par zecrazytux (site web personnel) . Évalué à 3.
mais puffy et beastie font ça tellement bien...
ps: fais gaffe à tes gosses, on les bouffe
ps2: vendredi avant l'heure, hein ?
ps3: très bonne initiative que "Desktop project" pour NetBSD, et pour la mise à jour avec un apt-like, je fais de la pub à Imil: http://www.gcu.info/tag/pkg_dry/
[^] # Re: NetBSD Desktop Project
Posté par totof2000 . Évalué à 2.
C'est sur que ça nécessite un peu plus de réflexion et de bien réfléchir à ce que l'on fait, mais travaillant dans la production, ce côté "prudent" est une habitude pour moi ....
Pour ma part je fais mes mises à jour en recompilant la totalité des programmes en environement chrooté, et lorsque j'upgrade j'ai toujours la possibilité de faire un retour arrière car je garde mes anciens packages.
A ce jour je n'ai jamais eu de problème, mais c'est peut etre aussi parce que je n'utilise pas les monstres GNOME/KDE sur mes machines en NetBSD.
[^] # Re: NetBSD Desktop Project
Posté par ptit_o . Évalué à 1.
On parle plutôt de /usr/pkgsrc/, donc pour pouvoir comparer avec tel ou tel gestionnaire de paquets, il faudrait être plus rigoureux.
[^] # Re: NetBSD Desktop Project
Posté par B16F4RV4RD1N . Évalué à 1.
On parlait d'ergonomie dans un autre journal (là par exemple => http://linuxfr.org/comments/1028789.html#1028789 ), et bien les gestionnaires de paquets (si on peut vraiment appeler cela "gestionnaire") ne sont pas du tout ergonomiques. Je vois 2 raisons principales à cela :
- historiquement, pour ne pas changer les bonnes vieilles habitudes
- techniquement, peut-être qu'ils préfèrent consacrer leurs forces à travailler sur d'autres choses que sur cela.
Pourtant, cela ne change rien au fait que tous les gestionnaires de paquets ou logiciels que j'ai pu utiliser sur *BSD ne donnaient pas trop envie d'avoir à gérer cela au quotidien. À la rigueur comme dit plus haut sur un serveur de prod, on installe les logiciels un fois pour toute (presque), et on les fais évoluer très lentement. Sur un bureau, si je dois installer une dépendance pour un logiciel de dessin dont j'ai besoin tout de suite, je n'ai pas envie de passer 15 ou 25 minutes à la compiler.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 6.
C'est vraiment de la merde pkgsrc par rapport à apt/yum !
Je prétend que le but n'est pas le même.
NetBSD compile sur tout un tas d'architecture et ce depuis tout un tas d'architecture. Et ce en deux ou trois commande simple.
Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.
Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.
Ensuite, tu a installé sur ton petit pc à base d'arm ton netbsd. Et tu veux koffice. Tu va avoir besoin, grosso-modo, de Xorg, qt, kdelibs, koffice*. Je pense que pour compiler ça, tu en as pour une semaine, au moins.
Mais comme tu utilise pkgsrc, tu rallume ton gros PC sous linux et grace à pkgsrc, tu compile tes paquets pour ton NetBSD/arm en deux heures le tout.
Et tu le pousse sur ton arm et ça marche.
Biensur, je pense qu'apt et yum permettent ça.
Ah non... Ba comment on fait ? On jete les super nouveau portables arm à la poubelle en attendant que debian et redhat fournissent des dépôts pour arm.
Ou alors, avec les paquets créée plus tot avec ce naze de pkgsrc pour ton pc/arm tu créer un dépôt afin que tes 20 collègues qui ont le même pc/arm que toi puisse installer à l'aide de ce naze de pkg_add les binaires produits à partir de ton gros pc.
Maintenant, supposons que tu t'en fiche, tu n'utilise que du 686.
Quelle est l'avantage de pkgsrc et pkg_add ?
Ba supposons que tu veuille compiler un application avec une option de compilation, ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui est automatisé grâce au nombreuses pkg_option. Une fois que tu à fais ton paquet, tu le mets dans ton dépôt ou dans ton PKG_PATH (ou les deux) et tout tes collègues profiteront de ton paquet fait avec amour.
Mais supposons que tu t'en fiche des options de compilation, apres tout, tu utile apt ou yum, non ? :)
Mais quelle est l'avantage alors me dira tu ?
Pendant ton temps libre, tu as écris un magnifique bout de code (en licence BSD bien sur !). Tu l'as écris proprement, en évitant les trucs lié à la plateforme cpu ,les GNUseries et les Linuxeries. Et bien en le mettant dans pkgsrc/wip (pour work in progress), les milliards de personnes qui utilisent NetBSD sous les differentes architectures proposé pourront l'utiliser, arm, vax, ppc, alpha, dreamcast, playstation2 et même zaurus ! Et si tu es un être profondément bon, tu pourras créer un paquet pour que toute cette foule de processeur criant le nom de ton appli en cœur puisse installer ton logiciel avec ce naze de pkg_add, sans même avoir besoin de le compiler. Et tu pourras en théorie le faire depuis ton gros pc, avec ton gros xeon qui a plus de cache L1 que certaine architectures de RAM.
Le bon vieux pkg_add couplé aux puissant pkgsrc sont capable de bien plus que yum et apt.
Et je ne suis pas un vieux geek aigri ( bon, un peu aigri, je suis juste en train d'attendre un tech FT en salle informatique... :) ), mais les besoins des utilisateurs de NetBSD ne sont pas les mêmes que ceux de Fedora (par exemple). Les besoins de Fedora sont... devenir windows ! Je schématise, mais le but, au delà de la 'vitrine' redhat, c'est bien de gagner des parts de marché. Les besoins de NetBSD sont rester simple et modulaire. On s'en fou des parts de marché. On en veux pas. Et si le
J'utilise Fedora sur le portable du boulot et je suis désolé, mais des fois, j'ai envi de le jeter par la fenêtre quand X plante (souvent) et que je ne peux pas récupérer la main m'obligeant à redémarrer. J'ai envi de le jeter par la fenêtre quand il me demande de confirmer mes actions. J'ai envi de le jeter par la fenêtre quand SELinux m'interdit de lancer netbeans en me sortant des logs incompréhensible qui veulent dire 'tu aurais déjà du me mettre en mode disable, cretin'.
Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
Et le http://wiki.netbsd.se/Desktop_Project, c'est à coté de la plaque. C'est n'est pas comment améliorer NetBSD, c'est juste créer un CD avec certaines choses préinstallé dessus. Ce n'est pas un projet officiel de NetBSD d'ailleurs. C'est peu Mais ça ne modifie pas NetBSD. Par defaut, un iso NetBSD, c'est un noyau, un userland basique et en option X avec twm. Et ça restera ça, à peu de chose près. A chacun de choisir précisément ce qu'il veut.
[^] # Re: NetBSD Desktop Project
Posté par patrick_g (site web personnel) . Évalué à 6.
C'était quoi la suite ?
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 3.
[^] # Re: NetBSD Desktop Project
Posté par zecrazytux (site web personnel) . Évalué à 2.
ça m'intéresse, et je croyais que c'était pas ça encore...
pour le kernel et le basesys, sinon, c'est clairement poutrant !
<3 build.sh
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 3.
Si des bonnes âmes veulent s'investir dans un projet à taille humaine avec plein de gens gentil autour pour rendre tout pkgsrc crosscompilable ( il doit bien y avoir une bonne demi-heure de boulot ! :) ), il n'y a qu'a s'inscrire à la mailling netbsd !
http://www.netbsd.org/cgi-bin/subscribe_list.pl?list=tech-pk(...)
sinon http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-cr(...) est l'exemple pour quelqu'un qui crosscompil du code pkgsrc de sparc vers alpha si je ne me trompe pas.
Je me souviens avoir utilisé des options dans le mk.conf à base de pkg_target je crois. Mais ça remonte à au moins 2 ans...
[^] # Re: NetBSD Desktop Project
Posté par imalip . Évalué à 2.
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 3.
Je t'en rachèterais un tout beau pour que tu puisses lire la news OpenBSD !
[^] # Re: NetBSD Desktop Project
Posté par imalip . Évalué à 5.
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 2.
Mea Culpa.
Mais tu peux remplacer ARM par un cpu non supporté par Debian.
[^] # Re: NetBSD Desktop Project
Posté par herodiade . Évalué à 5.
Franchement, quitte à vouloir faire partager son goût pour les *BSD, autant parler de leurs vrais atouts (de la même façon, j'ai beaucoup de peine pour ceux qui cherchent à promouvoir Fedora en parlant de yum au lieu d'évoquer son superbe support SELinux, le travail avec l'upstream, le LVM par défaut, le grand nombre de paquet fournissant les symboles de débogguage, les outils de gestion de masse comme Cobbler, Spacewalk, Func, FreeIPA, libvirt & co).
Si je voulais faire partager les plaisirs d'un linux à un bsdiste, par exemple, je chercherais pas à mettre en avant la documentation et les pages de man (surtout pas la doc des drivers), je ne parlerais pas de l'intégration, l'unification et la relecture systématique au niveau du code source / de la ligne de code du système de base, je ne m'aventurerais pas sur la possibilité de recompiler simplement l'intégralité du système de base après un changement d'API, j'éviterais de parler de la très unixienne beauté par la simplicité, etc...
> Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.
> Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.
Il existe bien entendu une méga foultitude de façon de faire ça avec Debian, par ex. et entre autres :
http://www.linux.codehelp.co.uk/apt-cross/re01.html
http://psas.pdx.edu/DebianCrossCompilerHowto/
L'élégance de NetBSD est ailleurs.
> Ba supposons que tu veuille compiler un application avec une option de compilation,
> ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui
> est automatisé grâce au nombreuses pkg_option.
Là aussi, les autres systèmes offrent évidement diverses options. Comme simplement renseigner la variable d'environnement DEB_BUILD_OPTIONS, ou pour une modif plus radicale, éditer le fichier de rêgles de compil et reconstruire le .deb ainsi :
apt-get build-dep foo
apt-get source foo
cd ./foo-0.1/
vim debian/rules # ajouter ses options de compil'
dch -i
dpkg-buildpackage -rfakeroot -uc -b
Et puis pour être honnête, il faudrait penser à indiquer pourquoi NetBSD propose si peu de paquet pré-compilés pour les architectures minoritaires... (et aussi, rappeler ce que Debian et OpenBSD pensent de la cross-compilation systématique par opposition à la compilation native).
Enfin, dans tout les cas le fait que pkgsrc permette la compilation croisée ou la personnalisation est une bonne chose, mais il n'est pas le seul, et surtout cette fonctionnalité ne devrait pas masquer les lacunes pour les cas d'utilisation plus courants (0 subtilité pour la gestion des conflits, gestion des dépendances rudimentaire, par ex.).
> Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install
> openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
Oui, je crois que son commentaire était relatif à l'absence de "yum search" dans pkg_add. Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche (ou pour chercher à partir de la description, etc.).
[^] # Re: NetBSD Desktop Project
Posté par B16F4RV4RD1N . Évalué à 3.
on parle d'une façon conviviale de le faire. Je ne vois pas l'intérêt de taper des commandes à rallonge juste pour obtenir une fonctionnalité qui me semble être la base d'un gestionnaire de paquet.
Pour le reste, ok le fait que netbsd supporte beaucoup d'architectures c'est indéniable, par contre cela ne remplace pas le fait qu'il manque quand même une gestion plus KISS des paquets, et des paquets binaires récents pour les architectures les plus courantes. (je reviens encore sur la simplicité de pacman sur archlinux à ce niveau, de plus il est possible de recompiler les paquets existants en rajoutant des options de compilation avec ABS: http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_Sys(...) ).
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 5.
Keep It Simple, ça ne veut peut être pas dire Laisse un script python faire je ne sais quoi avec des fichiers XML dans /etc/yum/yum.d/ et /etc/yum/yum.[nom du repo] et lire des fichiers XML, etc. KISS, ça veut peut être dire que je comprend TOUT ce que fait pkg_add facilement, c'est à dire, suivre le PKG_PATH, lister le répertoire pour matcher la chaine passer en argument, telecharger le paquet puis le detarer, lire les dépendances et recommencer si il y en a.
Sinon, si faire grep koffice pkgList est trop dur pour toi, je peux t'ecrire, en exclusivité pour toi, et oui, je suis comme ça, un pkg_search
#! /bin/shgrep $1 /path/to/pkgList
Prend, c'est cadeau :)
Il y a des paquets binaires pour toute les archis courante !
Et la notion de pacquage récent est relative. NetBSD utilise les paquets récent quand c'est possible.
[^] # Re: NetBSD Desktop Project
Posté par kowalsky . Évalué à 2.
Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche
D'ailleurs, chaque fois que pkgsrc gèle (4 fois par ans) je récupère le listing du répertoire en local en premier.
[^] # Re: NetBSD Desktop Project
Posté par Adrien . Évalué à 4.
Il me semble que Debian fournit un dépôt pour arm…
Si je tape yum -y install openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
yum -y install openoffice doit je pense compléter le nom du paque sur un shell digne de ce nom ?
# On en oublierait le plus important...
Posté par DitOuQueMon . Évalué à 1.
(et surtout, du contrôle de celui-ci en ssh ! )
Bon, c'était trop tentant... Il n'empêche que le fait de fonctionner sur ce genre de plateforme illustre bien la portabilité de netBSD.
Y a-t-il d'autres OS fonctionnant sur des architectures aussi extravagantes ?
[^] # Re: On en oublierait le plus important...
Posté par DitOuQueMon . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.