TeXitoi a écrit 358 commentaires

J'ai un Shuttle fanless avec un 1037U et un SSD sous OpenBSD qui me sert de :
- mail (OpenSMTPd, spamd, dovecot, rainloop) que j'utilise pour ma boite mail perso
- web (OpenHTTPd, php-fpm) pour des petits trucs, faudrait que je regarde les cloudtrucs un jour
- mpd pour la musique sur ma chaîne hi-fi
- ssh pour pleins de trucs à la demande (rsync, IRC, notes…)
- et les trucs standard (OpenNTPd, watchdogd, sensorsd, apmd, sndiod)

Avant, j'avais un via epia qui a cramé lors d'un déménagement après 9 ans de loyaux services.

Ou si t'es trop un geek, tu prends un token là et tu requêtes direct l'API ici voir tu fais joujou comme ça. Tout en libre/opendata.

Disclamer: je bosse sur ces bidules.

create_vector_of_string en plus simple (et aussi efficace):

fn create_vector_of_string() -> Vec<String> {
    range(0u, 10).map(|i| i.to_string()).collect()
}

ici rust est intelligent et devine que myvector a pour unit but d'etre passer en valeur de retour, et donc ne sera pas "copier" (en C++ si je me trompe pour avoir la meme chose on aurait du passer myvector en tant que parametre par reference ?)

En fait, en C++, ça donne dans ce cas la même chose, c'est la RVO.

pareil pour i_as_string ce qui en c++ aurait du forcer l'utilisation de fonction special de std::vector introduite uniquement recemment

Rust gère les types affines, appelé en C++11 "move". Mais en rust, c'est réellement intérgé : lorsqu'on a mové un objet, si on essaye de l'utiliser ensuite, le compilo te le dit (erreur).

Box offrant la garantie qu'on ai le seul a posseder ce pointeur

Pour les gens connaissant le C++11, Box<T> en rust, c'est en gros la même chose que std::unique_ptr<T> qui peut pas être à nullptr (l'équivalent strict de std::unique_ptr<T> est Option<Box<T>>, qui est d'ailleurs directement compatible avec T* en C).

Pour mon use je dis "je peux utiliser l'objet temporairement, mais je dois le rendre intacte a celui qui me l'a passe"

&T et à peut près équivalent à T const& en C++ (si on pinaille, c'est plus proche de T const* qu'on peut pas mettre à nullptr).

et pour mon free je dis "on me passe l'objet et j'en deviens l'unique detenteur, vu que je n'en fais rien, alors je peux le detruire et liberer sa memoire sans creer d'effet de bord

En fait, l'objet est mové dans la fonction, puis détruit à la sortie de la fonction car personne ne peut y référencer. On peut même simplifier le code à

fn free_complex_object (instance: Box<ComplexObject) { }

Oui, juste une fonction vide, d'ailleurs, c'est exactement l'implémentation de drop, les génériques en moins : http://doc.rust-lang.org/0.12.0/src/core/home/rustbuild/src/rust-buildbot/slave/dist2-linux/build/src/libcore/mem.rs.html#348

mais attention je suis neophyte en C++ et rust donc si des personnes plus experimentees peuvent confirmer, je suis preneur

J'ai un peu formalisé certains trucs et fait les parallèles avec C++, mais sinon, je confirme, c'est très bien ce que tu dis là ;)

Ha oui, c'est vrai que c'est à OpenBox de configurer les applications Gnome…

Cargo : http://crates.io/

Bon, OK, c'est pour Rust et encore un peu limité ;)

texitoi@vaio:~/dev/tests$ cat test.cpp
#include <iostream>
#include <vector>

int main() {
  std::vector<int> v {0,1,2,3};
  for (int i: v) std::cout << i << " ";
  std::cout << std::endl;
  return 0;
}
texitoi@vaio:~/dev/tests$ clang++ -g -std=c++11 -Weverything -Wno-c++98-compat test.cpp -o test
texitoi@vaio:~/dev/tests$ gdb -q ./test 
Reading symbols from ./test...done.
(gdb) b test.cpp:6
Breakpoint 1 at 0x400d25: file test.cpp, line 6.
(gdb) r
Starting program: /home/texitoi/dev/tests/test 

Breakpoint 1, main () at test.cpp:6
6     for (int i: v) std::cout << i << " ";
(gdb) p v
$1 = std::vector of length 4, capacity 4 = {0, 1, 2, 3}
(gdb) 

Mais c'est vrai que ça fait pas longtemps que Debian configure correctement gdb par défaut.

Sur mon serveur sous OpenBSD, j'ai rien à faire, et tout est chrooté :)

Les std::vector le font pas avec l'opérateur []. OK la méthode at le fait mais personne ne l'utilise.

Bah, non, heartbleed touche pas OpenSSH, et comme il n'y a pas de service qui utilisent ssl qui est lancé et ouvert sur le monde par défaut, il n'y a pas de "remote hole" en plus.

Personnellement, je ne m’attends pas à ce que le conducteur me dise ce qui ne va pas dans mon moteur.

Le problème, c'est qu'en C++, le réglage de l'injection est plus accessible que l'accélérateur.

Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. […] Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !

#include <memory>
#include <iostream>

int const &get_one()
{
    std::unique_ptr<int> i(new int(1));
    return *i;
}

int main()
{
    std::cout << get_one() << std::endl;
    return 0;
}

Ça a l'air par mal, compilons voir avec tous pleins de warning

$ clang++ --std=c++11 -Weverything -Wno-c++98-compat -Wno-missing-prototypes test.cpp -o test
$ 

cool ça a l'air memory safe ! On teste ?

$ valgrind ./test
==8446== Memcheck, a memory error detector
==8446== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8446== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==8446== Command: ./test
==8446== 
==8446== Invalid read of size 4
==8446==    at 0x400BAC: main (in /.../test)
==8446==  Address 0x59f8040 is 0 bytes inside a block of size 4 free'd
==8446==    at 0x4C28BDC: operator delete(void*) (vg_replace_malloc.c:502)
==8446==    by 0x400DC0: std::default_delete<int>::operator()(int*) const (in /.../test)
==8446==    by 0x400D25: std::unique_ptr<int, std::default_delete<int> >::~unique_ptr() (in /.../test)
==8446==    by 0x400C44: std::unique_ptr<int, std::default_delete<int> >::~unique_ptr() (in /.../test)
==8446==    by 0x400B69: get_one() (in /.../test)
==8446==    by 0x400BA3: main (in /.../test)
==8446== 
1
==8446== 
==8446== HEAP SUMMARY:
==8446==     in use at exit: 0 bytes in 0 blocks
==8446==   total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==8446== 
==8446== All heap blocks were freed -- no leaks are possible
==8446== 
==8446== For counts of detected and suppressed errors, rerun with: -v
==8446== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
$ 

Oups !

La même chose en rust

fn get_one() -> &int {
    return &*~1;
}

fn main() {
    println!("{}", *get_one());
}

On compile :

$ rustc test.rs -o test
test.rs:2:12: 2:16 error: borrowed value does not live long enough
test.rs:2     return &*~1;
                     ^~~~
test.rs:1:22: 3:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 1:21...
test.rs:1 fn get_one() -> &int {
test.rs:2     return &*~1;
test.rs:3 }
test.rs:2:5: 2:16 note: ...but borrowed value is only valid for the statement at 2:4
test.rs:2     return &*~1;
              ^~~~~~~~~~~
error: aborting due to previous error
$

Ha, ça compile pas, en effet.

Et boost locale avait quoi comme problème ?

J'ai fait (presque) le contraire : je suis passé de ion (qui a l'air très proche de i3) a XMonad.

Tag ou pas tag change généralement le mode d'utilisation :
- avec tag, on choisi d'afficher certains tags d'une part et on choisi l'algorithme de pavage d'autre part
- sans tag a chaque bureau on a un ensemble de fenêtre et un algorithme de pavage.
L'organisation de l'utilisateur est alors différente.

Est-ce que quelqu'un est capable de comparer jack et pulseaudio au système de son d'OpenBSD (sndio) ? Par curiosité, car sndio a l'air pas mal dans le genre, sûrement beaucoup plus simple, possiblement plus gourmand en ressources.

http://www.sndio.org/

J'ai un réveil électronique qui marche à l'énergie solaire. En plus il se règle par onde radio. Pas de problème de pile ni de changement d'horaire !

Un minitel comme console série.

Il y a a mon avis une raison de plus à ce que le projet OpenBSD n'aime pas la GPLv3.

OpenBSD a forké apache lors de la sortie d'apache 2 sous licence apache 2. Le projet n'aimait pas du tout la licence apache 2 qu'il trouve discriminatoire (la clause antibrevet dit en gros et surement avec des grosses approximations fausses : si tu attaques des gens pour violation de brevets logiciels, tu as plus le droit d'utiliser ce code). Comme la GPLv3 est compatible apache 2...

Non, uniquement l'arbre des ports via CVS.

Ha, zut, j'ai oublié de parler du système de paquets.

Le système des ports est, comme sous FreeBSD, une arborescence de makefiles qui permettent de télécharger et compiler des programmes. Par contre, l'approche d'OpenBSD est très différente de celle de FreeBSD (sujet à de nombreux trolls sur fr.comp.os.bsd) : il génère forcément des paquets binaires avec une gestion très fine des dépendances (un paquet dépend d'autres paquets et des versions des bibliothèques dynamiques (.so), dont les versions sont gérées à la main par le projet (et non en suivant le mainstream qui a tendance à ne changer que le numéro de version mineur alors qu'en fait il faut changer le numéro de version majeur)). La gestion des paquets (génération, (dé)installation, mise-à-jours... bref, l'équivalent de dpkg/apt/aptitude) est développé en perl.

Le système de ports peut générer plusieurs paquets pour un même source, via les multipackages (on découpe un paquet en morceau, c'est pas aussi fin que sous debian) ou en flavors (compilé avec différentes options, genre support samba, version compilé statiquement...)

Il est conseillé d'utiliser les paquets précompilés pour son architecture, et n'utiliser le système de ports que si on travaille dessus ou qu'on a des besoins spécifiques (flavors spécifiques non compilées par le projet par exemple).

À mon avis, il est très efficace et robuste (j'utilise OpenBSD et Debian). Le choix de paquets est tout à fait correcte, le plus grand absent étant KDE 4 (par manque de moyen humain (comprendre personne n'a encore été assez motivé pour faire un port complet)).

http://openbsd.org/faq/faq5.html#Flavors

En résumé, il y a
- release : la version figée disponible sur les CD et en téléchargement binaire
- stable : release + les correctifs de sécurité, maintenue un an après la sortie de release correspondante
- current : la version de développement qui évolue tous les jours, dispo via le CVS ou sous forme de snapshots réguliers (les snapshots pouvant contenir du code à tester non encore commité dans le CVS).

Cette iso téléchargeable contient le système de base (noyaux, libc and friends, X, OpenSSH, "OpenApache", OpenNTPD, perl, tmux..., bref, tout ce qui est hébergé dans le CVS d'OpenBSD) pour une architecture donnée supportant le boot sur CDROM.

Les CD officiels contiennent sur 3 CD le système de base des principales architectures (i386, amd64, macppc, sparc64), les sources et une sélection de packages. Les CD en eux même sont copyright Théo et on a pas le droit de les copier. La vente de ces CD est la source de revenu unique de Théo. T-shirt et autres goodies sont les revenus du projet (majoritairement pour l'organisation des hackathons).

Voilà, j'espère ne pas avoir dit de conneries.

> Et comme il n'y a pas de NAT avec IPv6

Si si, il y a du NAT, c'est juste que c'est triste de l'utiliser.

OpenBSD ne gère pas encore la mise en veille prolongée. La mise en veille classique (en RAM) est en cours de développement. Par exemple, sur mon EEEPC, il se met en veille, mais merde au réveil du disque dur.

Sur la page principale, on trouve le logo CC-NC-SA. Pourquoi un tel choix ? La CC-BY, la FreeBSD Documentation License ou la ISC ne seraient-elles pas plus adaptées ?