Batchyx a écrit 1261 commentaires

Personne n'a dit ici que les systèmes de fichier Linux sont faits pour être userfriendly. c'est toi qui nous dit que c'est le cas sous windows …

Sous UNIX, le rôle du système de fichier c'est de simplifier la tâche aux applications. Si tu veut de l'ergonomie/utilisabilité/acceptabilité, c'est dans les applications qu'il faut le faire. Et tu n'est pas obligé de présenter le système de fichier tel quel à l'utilisateur (d'ailleurs, la plupart des utilisateurs de Windows ne savent pas ce qu'est un fichier, je me trompe ?).

Après, si tu vois l'intérêt d'avoir un système de fichier qui s'amuse à avoir une collation sans distinction de casse, faudra me le dire. Parce que moi je vois pas la justification de pourquoi open("/home/zenitram/documents/Classeur", O_RDONLY) accepterai d'ouvrir un fichier qui s'appelle "/home/Zenitram/Documents/classeur". Ça n'apporte strictement rien au programmeur, et l'utilisateur il en à un peu rien à foutre de l'appel système open(2).

Ben si, justement. Quand je fais une recherche sur "Classeur", ça me gonfle au plus haut point que Linux soit incapable par défaut de me sortir le fichier "classeur".

Ça n'a strictement aucun rapport avec le système de fichier, mais plutôt à ton outil de recherche. C'est lui qui fait la comparaison.

Non, désolé, Microsoft gère la casse comme les humains

ah oUaiS, IgNOreR la CassE c'eST "gérEr LA CaSSe COmME LEs huMaiNS". Tu PeUx dOnC mÉLAnGEr AllegRemENt lES mAJUSCuLeS ET LES minuScuLes Et ÇA sERa PArEIL qUe Le mêMe texTE RÉSpEcTAnT Les RÈGLEs tYPoGRAPHIQUes gÉnÉralEmEnt aDMIsES ?

Si tu veut gérer la casse comme un humain, "Classeur" c'est un nom propre, alors que "classeur" est un nom commun. "CO₂" n'est pas la même chose que "Co₂", ainsi que toutes les règles à la con que l'humain a le dont de savoir inventer.

Si tu utilise ton #define, tu à bien d'autres problèmes. Déjà tu est en train de mentir à l'utilisateur de ta macro, parce qu'il peut croire que c'est une fonction avec vérification des paramètres et documentation.

Ensuite si ta macro à un problème, ou si l'utilisateur à une autre variable qui s'appelle "func", t'aura avec la plupart des compilos des messages d'erreurs incompréhensibles du genre "func indéfini" ou "func ne peut pas être indéxé" alors qu'il n'y a pas "func" dans la ligne en question.

Si ça te fait plaisir de mettre tout ton code dans des macros et d'avoir que main() comme fonction, c'est ton problème.

De plus, Le inlining n'est pas du tout une garantie (cfr. le standard). Il peut encore dans de nombreux cas avoir un appel. Un appel coûte dans 99.9% des cas extrêmement plus qu'un accès mémoire.

Le standard ne te garanti pas qu'inliner sera forcement plus rapide que d'appeler une fonction, et ne te garanti pas non plus que ton compilo ne dé-inline pas ton code si tu fait trop de copier/coller.

Mais si tu ne fait tellement pas confiance à ton compilateur, change le. Quand gcc refuse d'inliner, il peut te dire pourquoi, et tu peut bidouiller les heuristiques de gcc si tu te crois plus malin que lui. Mais n'oublie pas que la plupart des problèmes d'optimisations sont NP-complet, et que gcc peut refuser d'optimiser une fonction si elle devient trop compliquée pour éviter que le temps de compilation explose.

Et comme c'est désactivable

Pas sur ARM avec Windows 8, donc non, ce n'est pas désactivable partout.

au pire tu désactive complet

Et est ce que Windows fonctionnera encore si c'est désactivé ? Parce que si il refuse et qu'il faudra aller bidouiller les options à chaque fois que l'on veut booter sur un OS différent si tu veut faire du double-boot, on va encore bien se faire chier. Et si il accepte, alors un utilisateur qui se fait pwner sa machine et qui se retrouvera au prochain démarrage avec un message "Ton OS n'est pas signé va te faire voir", il entendra certainement plus souvent "Tiens désactive Secure Boot et ça marchera mieux !" plutôt que "Fait toi chier à tout réinstaller !".

Ce n'est pas en mentant aux gens qu'on va les faire pleurer sur le sort des Linuxiens.

Ou est le mensonge ? Est ce que je pourrai installer un autre OS à coté d'un Windows 8 sur ARM ? Est ce que je pourrai ajouter des fonctionnalités/corriger des bugs et voir le résultat immédiatement ? Est ce que j'aurai la main sur cette machine au final, ou est ce que Microsoft pourra en faire ce qu'il en veut ?

Il est censé protéger le monopole de Microsoft contre ses utilisateurs, ses concurrents et ses revendeurs.

Parce que tu sait à l'avance que tu n'est même pas sûr qu'avoir le résultat précalculé dans un tableau soit une bonne idée. Et que si un jour tu a envie de changer et de calculer le résultat à la volée, t'aura pas à te faire chier à modifier tout les endroits ou tu à utilisé ton tableau directement.

Si tu était en C++, par contre, ça pourrai se discuter, vu que tu pourrai remplacer ton tableau par un objet avec un operator [] sans avoir à changer le code qui accède au tableau.

les ordinateurs sous ARM, donc en gros des téléphones

Non.

Et même si ce n'était que des téléphones, il y a toujours de quoi s'inquiéter. Un téléphone typique à accès à bien plus d'informations personnelles que mon ordinateur, donc c'est normal que je puisse le contrôler et en faire ce que j'en veux.

Si tu n'utilise pas de flag d'optimisation, je vois pas pourquoi tu reproche à gcc de ne pas optimiser.

Et par défaut si tu n'utilise pas static sur ta fonction, cela veut dire que la fonction doit être exportée, donc qu'elle doit pouvoir être appelée par du code externe. donc elle existera forcément, et du coup le compilateur aura moins envie de l'inliner. Du coup gcc n'inline qu'en -O2, et la fonction est encore présente, même en -O3. Il faut du -fwhole-program pour s'en débarrasser.

Tu a essayé de compiler ton code ? Chez moi, avec GCC 4.7.1 en 64bit:

testinline.c: In function ‘mafonction1’:
testinline.c:13:1: warning: comparison is always false due to limited range of data type [-Wtype-limits]
testinline.c: At top level:
testinline.c:34:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
testinline.c: In function ‘main’:
testinline.c:49:9: warning: assignment makes integer from pointer without a cast [enabled by default]
testinline.c:58:9: warning: assignment makes integer from pointer without a cast [enabled by default]
testinline.c:37:9: warning: variable ‘x’ set but not used [-Wunused-but-set-variable]
[23:5

Et les résultats chez moi après avoir corrigé au moins les calculs de temps :

O0 : Inline-Macro: 20691390, pas d'inline
O1 : Inline-Macro: 25125555, fonction omise, lecture du tableau omise, mais boucle de 0 à TESTSCOUNT conservée
O2 : Inline-Macro: 0 ou 18446744073709551595 (integer underflow), boucle de 0 à TESTCOUNT omise, lecture du tableau omise, on mesure plus rien du tout, mais l'initialisation du tableau est conservée.
O3 : Code assembleur identique à O2.

Enfin bref, c'est pas le tout de pondre du code de test, mais autant que ce code calcule quelque chose qui ne puisse pas être connu à l'avance, et qui soit ensuite réellement utilisé.

Enfin bref, n'optimisez que des programmes finis qui servent à quelque chose.

Chez moi ça marche.

static const uint8_t func[256] = {232, 21, 174 /*.....*/};
static uint8_t macros_are_for_wimps(uint8_t v) {
    return func[v];
}

int main(int argc, char* argv[]) {
    if (argc <= 1)
        return 0;
    return macros_are_for_wimps(atoi(argv[1]));
}

main:
.LFB1:
    .cfi_startproc
    movl    $0, %eax
    cmpl    $1, %edi
    jle .L6
    subq    $8, %rsp
    .cfi_def_cfa_offset 16
    movq    8(%rsi), %rdi
    call    atoi
    movzbl  %al, %eax
    movzbl  func(%rax), %eax  <------
    addq    $8, %rsp
    .cfi_def_cfa_offset 8
.L6:
    rep
    ret
    .cfi_endproc

Et c'est du gcc -O, hein, c'est presque le flag d'optimisation que je met tout le temps même en debug.

Si ton compilateur n'est pas capable d'inliner une fonction qui retourne func[x]; alors change de compilateur.

J'allais faire une réponse plus argumentée qui commence par la même chose, mais finalement, c'est déjà très bien comme ça ;)

La télévision n'a pas tué la société

Sources ?

Oui et ce sont les clients qui le font : Neighbor Unreachability Detection.

Si leurs connections TCP n'avancent pas ou si le routeur ne répond pas au Neighbor Discovery ou autre, et ce pendant (temps indiqué dans les router advertisement), alors ils arrêtent d'utiliser ce routeur.

Finie la conf compliqué et les routeurs qui doivent collaborer !

Et le problème se réglera (presque) automagiquement.

Pas besoin de rajouter de nouvelles routes, je suis sûr que ta table de routage est déjà bonne. Peut-être pas idéale, mais déjà bonne.

Si tu à configuré eth1 en 172.16.0.1/8, eth0 en 192.168.1.250/24, ton noyau t'a déjà rajouté ces routes là :

172.16.0.1 à traiter localement.
192.168.1.250 à traiter localement.
les machines 172.0.0.0/8 sont sur le même lien que eth1
les machines 192.168.1.0/24 sont sur le même lien que eth0
[il y en a d'autres, sur les adresses broadcast 172.255.255.255 et 192.168.1.255 notamment)

Rajouter une "passerelle par défaut" (quel terme moche) X.X.X.X, ce n'est que rajouter une route :

default (autrement dit, tout le reste, dont Internet) passe par X.X.X.X.

Après, il faut qu'on puisse déjà joindre X.X.X.X et qu'il soit directement accessible sur un lien. Une route par défault n'a habituellement pas besoin d'interface,
mais ça peut servir de mettre la bonne. pour voir ta table de routage, utilise ip route show table main (et ip route show table local pour voir les routes locales)

Si tu accède à internet depuis ton boitier, c'est que tes routes vers eth0 marchent, si tu ping ton pc portable, ça veut dire que tes routes vers eth1 sont bonnes et que les routes de ton pc portables sont bonnes aussi.

Après, il faut juste savoir que le noyau, par défaut, ne fait pas suivre les paquets, et ne change pas les adresses pour cacher l'ip 172.16.0.1 à la box, qui ne saurai pas quoi en faire. Et y a suffisamment d'info sur cette page pour savoir comment configurer ça ;)

Après :
- Les classes, ça n'existe plus. Comme le dit la blague : "We are a classless society now !".
- Seul 172.16.0.0/12 est réservé à un usage local. Pas tout 172.0.0.0/8
- N'hésite pas à utiliser wireshark/tshark/tcpdump pour voir ce qui se passe sur ton réseau, surtout quand ça marche pas.

Linux donnait l'image d'une personnalité toute à fait équilibrée, ce qui était très positif.

Ah bon ?

Un tel geste d’adolescent retardé sera du pain béni pour les sceptiques et surtout pour les détracteurs des nos chères technologies libres.

C'est qu'ils étaient très mal informés de base. C'est pas comme si Linus n'avait jamais envoyé des mails avec des "You're a [fucking] moron" dedans. Et ce n'est pas comme s'il n'y avais pas pire en face dans le monde propriétaire, ou on n'a pas accès aux mails envoyés en interne.

En usage normal, le PC ne consommera peut-être que 30-35 W

Les alims de PC portables sont prévues pour pouvoir charger la batterie en même temps que de faire tourner le portable; C'est à ce moment là que ça consomme le plus. Consommer 50-60W à ce moment là n'est pas surprenant.

Le rôle de déterminer ce qui doit être configurable et comment ça doit être configurable reviens quand même à la distribution. Ce n'est pas à GNOME d'imposer son point de vue.

Si Gnome ne propose qu'une interface limitée pour changer que certains paramètres avec des choix limités, il est en train de s'approprier la responsabilité de la distribution; Au final, une distribution qui voudrai intégrer Gnome et son outil de configuration n'a pas le choix : Elle doit garder un mapping 1:1 avec les options de GNOME.

Parce que si elle ne peut pas faire de mapping 1:1 avec les options de GNOME, alors soit GNOME impose à la distribution de supporter plus d'options qu'elle ne le peux, soit GNOME ne supporte pas assez d'option, et donc peut péter la conf du système si les options non-supportées sont modifiées par ailleurs ou ne peuvent pas avoir de paramètres par défaut raisonnables. Ce qui ne pourrai pas arriver si c'était la distribution qui faisait le travail, qui est son travail.

La seule chose raisonnable que peut faire une bonne distribution est soit de retirer le module de configuration, soit fournir un connecteur qui refuse toutes les modifications, soit refaire l'interface de configuration pour que ça colle à la distribution. Tout ça pour un truc "intégré et complet".

Si GNOME veut mieux pouvoir s'intégrer à une distribution, il n'a qu'à permettre aux distributions de construire plus facilement des GUI intégrés dans son outil de configuration.

Est ce que la config marchait avant, ou est ce que tu à rajouté des cartes entre temps ? Parce que si tu à deux cartes qui sont sur le même IO, ça risque de pas bien marcher.
Par exemple, les cartes sons SB ont tendance à utiliser l'IO 0x220, si ta carte réseau utilise les mêmes …

La différence, c'est qu'ici c'est GNOME qui cherche à proposer une interface mieux intégrée.

Alors que c'est à la distribution de faire ce travail. C'est comme si tu me disait que tu voulais intégrer une fonction unique dans la libc pour changer l'icône de n'importe quel application graphique. Rien ne t'empêche de le faire, sauf que ça sera pas propre, pas portable et que donc ça peut merder facilement.

Mais là on parle de configuration système. Ça ne doit juste jamais merder, sauf si t'a envie de te faire plaisir avec des livecd ou des init=/bin/bash parce que ton bidule t'a plombé ton seul utilisateur qui avait les permissions pour modifier la conf.

Et ifupdown supporte quel pourcentage des fonctionnalités du système ?

100%

ifupdown c'est le genre de logiciel UNIX bien conçu dont Gnome devrai s'inspirer un peu. De base c'est juste un logiciel qui garde un état des interfaces entre "configuré" et "pas configuré", qui maintient une correspondance "nom de la configuration interface", et qui propose un framework pour configurer et dé-configurer une interface. De base, il supporte peu d'options. Et pour gérer ce peu d'options, ifupdown utilise, à sa compilation, un méta language de programmation (les fichiers dfn si je me souviens bien) prévu pour être modifié par les mainteneurs de la distributions. Et si les choix qu'à fait ta distribution dans ces fichiers dfn te plaisent pas dans un cas particulier (ou pas), tu à le mode manual qui ignore ce qu'à fait ta distrib, et te laisse le refaire toi-même.

Et vu que les options gérées de base sont ridicules (du même genre que la conf réseau de ce bouzin, quoi que, ifupdown supporte au moins une passerelles par défault en statique), ifupdown va utiliser des hooks qui peuvent être des scripts ou des programmes pour supporter plus d'options. Ces hooks peuvent soit être écrits par des administrateurs géniaux, soit être installés par d'autres paquets de la distributions pour étendre/intégrer un autre logiciel à ifupdown. Ce qui fait que mon ifupdown sur mon système Debian supporte le wakeonlan, les vpn, le wifi et bien d'autres choses encore, sans que j'ai besoin d'écrire de scripts. J'ai quand même des scripts dans tout les sens pour jouer avec des politiques de routages dans tout les sens, et je peux supporter absolument tout ce qui existe si j'en ai envie.

Bon après, c'est pas forcément la panacée non plus, il n'y a pas de moyen de savoir quel options sont disponibles (ifupdown se contente simplement de prendre toutes les "option valeur" et de les mettre dans des variables d'environnement IF_OPTION=valeur, et chaque script utilise les variables qui l'intéressent) ce qui rend par exemple la détection d'erreur de nom d'option plus compliquée ou la création d'une GUI plus difficile. Mais ces problèmes peuvent quand même être résolus par la distribution.

Mais bon, on à quand même un logiciel intégrable, extensible à la sauce UNIX, qui n'est pas bien compliqué à comprendre, qui plaît aux admins et qui ne déplaît pas vraiment aux admins débutants. Après il n'y a pas d'interface graphique, mais ça n'empêche pas la distribution d'en faire.

Après je ne dit pas que ça ne peut marcher qu'avec une poignée de distribs, je dit justement que ça ne marche qu'avec une poignée de distribs ACTUELLEMENT, que c’est un FAIT, et qu'aujourd'hui on a la capacité avec dbus et une norme freedesktop de changer ça pour avoir un vrai gestionnaire de réseau graphique.

C'est un fait, mais je te dit que c'était prévisible. Pour ton abstraction de configuration de distributions différentes, tu ne peux pas à la fois :
* Fonctionner avec toutes les distributions.
* Avoir une API facile à utiliser.
* Ne pas casser le système si des options configurées par ailleurs sont ignorées, écrasées ou modifiées.

Tu ne peux pas en avoir plus de deux. Si tu à une API facile à utiliser et que tu possède assez d'options pour pas beaucoup casser le système avec des options que tu ne gère pas, tu ne pourra pas étendre ça à toutes les distributions, sinon tu va devoir rendre ton API plus compliquée.

Là on est plutôt dans un cas ou tu à une API facile à utiliser, ou tu supporte plein de distribution et ou tu casse le système vu comment ça jongle avec les fichiers de configuration d'ifupdown, au moins.

Des horaires qui ne sont pas dans le fuseau horaire naturel de l'utilisateur ne correspondent de toute façon à rien. Ce n'est pas en forçant l'utilisateur à utiliser le fuseau horaire abscons du système plutôt que le sien, qu'il s'y habituera instantanément et qu'il pourra lire sans effort les logs avec un fuseau horaire différent de l'horloge physique juste à coté de lui.

Tout ce qui contient le mot "uniformisation" à coté de "distribution", c'est forcement une mauvaise idée. Surtout quand tu dit toi même que ça ne peut marcher qu'avec une poignée de distribs.

Si un utilisateur de base veut modifier sa config via gnome, c'est à sa distribution de faire le boulot. Gnome peut aider un peu, mais c'est à la distribution d'avoir le dernier mot sur comment le système doit pouvoir être configuré. C'est son rôle après tout.

y'a un backend de NetWorkManager qui permet d'utiliser les fichiers de conf natifs de Debian, du coup nm-applet devient une superbe interface graphique à /etc/network/interfaces :D

Backend qui comme d'habitude, ne supporte pas la moitié des fonctionnalité de ifupdown. Un peu comme system, quoi.

J'ai pris l'API réseau, parce que c'est ce que je connais de mieux. Mais je suis sûr que n'importe qui connaissant mieux le sujet des autres objets D-Bus peut relever autant de conneries de ce genre sans avoir à rentrer dans les détails (J'ai pas parlé du fait qu'il utilise les wext pour configurer du wi-fi, alors que c'est carrément obsolète).

Pour le reste, oui, il faut utiliser les moyens prévus par sa distribution, et oublier ce machin qui se croit plus intelligent que toutes les distributions et utilisateurs réunis.