Bapt a écrit 772 commentaires

Les *BSD ont d'énormes qualités (robustesse, cohérence, etc ...) mais ils sont à la traine, est-ce que la solution est de figer TOUTE innovations ? je comprends le point de vue de Lennart, et ça n'est pas la première fois que les *BSD sont laissés pour compte

AHAHAHAH pardon, mais laisse moi rire, je vais donc aller coder upstream des interfaces FreeBSD only pour telle ou telle fonctionnalité sans réfléchir à la portabilité et aller baver partout que linux est a la traîne parce qu'il n'implémente pas lesdites fonctionnalité et ne peut pas bénéficier de la dernière version de l'appli.

Parce que libudev, par exemple. L'API est complètement délirante et linux centrique, pourquoi ne pas avoir réfléchi (sick) à une API propre ET générique genre je veux un truc qui me donne telle ou telle information. Et seulement ensuite chercher à l'implémenter au dessus des APIs linux ça aurait été plus simple et PORTABLE.
Alors biensûr implémenter le tas de merde qu'est l'API actuelle de libudev au dessus des autres OS c'est possible mais au prix de noeuds au cerveau sur les autres OS et donc c'est long et sale. Ce n'est pas un boulot intéressant du tout donc c'est repoussé jusqu'à ce que l'on n'ai plus le choix.

Ce n'est pas une question de retard mais une question de design pourri, il est passé où le temps ou les gens réfléchissait avant de pondre un code, le temps où l'on essayait coûte que coûte de pondre du code simple et portable ? etc.

Faudrait surtout voir qu'il ne s'agit pas d'un retrait parce que là FreeNAS en fait c'est une refonte from scratch de freenas pas une mise à niveau.

ie: la base c'est maintenant du nanobsd contrairement a avant.

Donc on repart de 0, bah le set de packages aussi repart de 0. rsync n'a pas été retiré il n'a pas été ajouté ce qui est différent.

Une belle avancée technologique

Un truc qui pète FHS, qui éloigne encore un peu plus linux de la beauté des unix. qui n'est pas portable, qui va la migraine aux administrateurs systèmes, qui réinvente la roue dans tous les sens...

Hum on ne doit pas avoir la même définition de "belle avancée technologique".

Parce que awesome consomme beaucoup (pour ce type d'environnement) parce que la conf de awesome pète(ait?) tout le temps, chaque release fallait tout revoir.

Parce que c'est fun?

As tu essayé cdr (dispo en zsh 4.3.11)? (man zshcontrib pour plus d'infos).
Si oui un retour d'expérience de autojump vs cdr?

C'est comme beaucoup de choses sous FreeBSD (et dans le libre), tant que personne n'y trouvera un intérêt suffisant ce ne sera pas fait (pour les packages, je crois que bapt http://blog.etoilebsd.net/ est plus ou moins sur le coup)

Balance !!! c'est secret comme projet et pas encore fini du tout et rien d'officiel du tout pour le moment :)

Ce qui est supporté par pkgin c'est pkgsrc. Sur FreeBSD il n'y a pas pkgsrc, mais pkgin build très bien et fonctionne très bien quand même sur FreeBSD si tu utilises pkgsrc en lieu et place des ports.

J'ai fait le support de pkgin pour qu'il supporte les packages FreeBSD générés depuis les ports, ça marchait mais ça n'ira pas plus loin car c'est trop bancale (selon moi), les ports et pkgsrc sont assez proches en terme de packages générés, mais les petites différences rendent le résultat "trop fragile" pour que ça soit viable imho, il est donc plus intéressant de laisser pkgin se concentrer sur son vrai boulot, les packages binaire issus de pkgsrc, ce qu'il fait très bien.

Dire "il suffit de supporter les 3 api majeures"
Une SEULE bordel; alsa, et ce depuis pas mal d'années; si tu veux faire du temps réel, tu prends jack, et tu oublies alsa.

Et au revoir portabilité :)

Alsa n'est pas portable c'est quand même clair (en plus d'être super complexe par rapport a OSS qui est quand même le standard historique sur tous les unix)

bref.

Reprend le bon vieux staroffice ou les première version d'openoffice (avant la première release officielle) tu verras si aucune tentative de faire quelque chose d'ergonomique n'a été fait :)

Il y a une différence énorme déjà.

La réponse est assez simple, prend le cas de hal, regarde quand est ce que ce truc a été annoncé comme le messie que tout le monde devait l'utiliser, regarde ensuite à quel moment a commencé le travail pour le rendre portable - travail effectuer par des devs BSD et non les devs hal - (réponse dès que l'on a su que l'on allait nous imposer ça c'est à dire assez rapidement).

Regarde enfin, combien de temps il a fallu pour obtenir un truc propre qui fonctionne et soit un minimum portable. Et c'est à ce moment là que tout le monde le vire "ah bah non les gars en fait on a fait de la merde... désolé, mais on recommence avec le nouveau truc qui déchire et vous pouvez encore vous faire voir pour avoir du portable".

La dedans il y a deux problèmes :
- les devs linux-centriques qui ne cherchent pas a isoler les code OS spécifique mais qui malgré tout cherche a imposer leur soluce comme la base d'applis auparavant portable (ie hal par exemple devenu souche pour beaucoup de gros projets)
- les "putains les gars j'ai mon nouveau truc qui déchire" et hop avant de comprendre il est partout, mais comme il n'est pas suffisamment réfléchi en amont bah il gicle peu de temps après (cf toujours HAL par exemple). Le plus drôle c'est quand la même connerie est recommencée plus tard : cf esound vs pulseaudio (que c'est pas la même chose on te dit mais que ça y ressemble drôlement avec un résultat aussi moisi)

/me qui en a ras le cul de faire grep \/proc pour trouver les linuxeries cachées

sauf que l'on parle de briques importantes, pas de la 250 000 version de pong. Ils serait bon de les penser multiplateforme dès le début que celui qui va faire le boulot de portage n'est que ça a faire au lieu de deviner que a tel ou tel endroit du code il y a des linuxeries.

Le problème c'est que ce n'est jamais ou presque fait comme ça.

ou alors utiliser un OS avec une base vraiment stable et un ensemble de packages/ports end-user en rolling release ainsi tu as le bonheur complet.

tu gardes une machine stable et bénéficie rapidement des évolutions. Oui il existe des OS qui fonctionnent comme ça et qui sont libre.

Non tu n'es pas un vieux truc un mail se doit d'être en texte simple et pas dans une infâmie de melasse htmlesque :
http://www.asciiribbon.org/index-fr.html

quelle question ...

parce que perl est amour alors que python ... :)

Sauf que sqlite est fait pour être "bundler" lui :) les autres projets de l'auteur (http://www.fossil-scm.org par exemple) utilise sqlite en mode bundle.

1 fichiers c et 1 fichier h suffisent pour ça etc ainsi chacun projet embarque son sqlite et le compile avec les options adaptées à son utilisation (oui beaucoup d'options de sqlite sont des options compile-time).

Sinon dans la majeure partie des cas c'est pas bien de faire ça :)

ftp://ftp.fr.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.(...)
ftp://ftp.fr.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.(...)

Non pas besoin de compiler

Je propose une nouvelle catégorie "people" (le logo de la libcaca lui irait très bien) pour y mettre les journaux comme celui ci qui viennent étaler les ragots et autres fait divers "torche balle".

Une petite remarque, les sed sont inutiles tu peux tout faire directement par des expansions normalement.

Il faudrait déjà que les outils que tu cites soient capable d'être aussi efficaces que vim tout en restant aussi léger.

J'ai un éditeur unique pour tout faire ou presque, il a l'avantage d'être léger, de pouvoir être accessible de partout de tourner aussi bien sur un arm que sur un quad-core, je peux y accéder à distance sans sortir l'artillerie lourde (X11Formading ou autres)

un seul apprentissage pour tous les usages, non vraiment je ne changerai pas mon vim contre un autre éditeur.

Tu dois pouvoir pondre ton rpm sachant que tinymail fournit un fichier spec pour builder un RPM. L'as tu essayé?
http://gitorious.org/tinymail/tinymail/blobs/master/libtinym(...)

j'ai pas souvenir qu'une autre distro que Ubuntu est réussi a entrer dans un constructeur tel que Dell.

C'est *SALE* ce que tu racontes

Si Cisco distribuait ses modifications ( en font-ils ? ) sous licence « BSD », ça serait chouette, mais en aucun cas équivalent à un don d'argent.

Oui ils le font, ils sponsorisent même des développements (port de dtrace sous freebsd),..

Ah la belle phrase pourrie !!!!
Tu n'as rien compris au pb. Personne ne se plaint du fait que Cisco utilise OpenSSH mais du fait qu'il ne fasse pas de dons.

Donc si OpenSSH était en GPL ça ne changerait rien du tout au problème, mais alors rien du tout.

Bref avant d'étaler ta bave, réfléchit un peu...

Mac OS X, Linux, Solaris et l'autre OS

Il n'y a donc que 4 OS existant, j'en déduit que l'autre OS c'est FreeBSD...

Pour info déjà nouveau il tourne que sous Linux, donc exit les bsd & co avec un affichage 2D potable.

Juste pour info nouveau tourne aussi sous freebsd (merci rnoland@ )