Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

**newbie06** · 31/07/2012, 12h09

Envoyé par snipx

Ah bon ? Mais on peut s'ettriper avec tout, c'est ca qui est genial en informatique (ironie).

Je suis bien d'accord, mais la je trouve que c'est alle plus loin que d'habitude : en lisant j'ai vraiment ressenti que certains etaient tres sensibles au sujet au point de sur-interpreter et de s'emporter contre des personnes qui ne les avaient nullement agresses (enfin AMHA).

**haik** · 31/07/2012, 12h11

En tout cas, le nouveau fil est du coup beaucoup plus drôle que l'ancien

**Tramb** · 31/07/2012, 12h26

Envoyé par newbie06

Je ne savais pas qu'on pouvait s'etriper pour un file system. Je rajoute ca a ma liste de trollage, tiens. De toute facon, rien ne vaut le FAT32 c'est compatible avec tout.

Bouffon. C'est évident que c'est le file system du GEMDOS le meilleur.
Je recommande des disquettes double face/double densité formatées avec 81 pistes et 10 secteurs par piste pour en tirer le meilleur parti.

**rOut** · 31/07/2012, 12h30

FTW

**newbie06** · 31/07/2012, 12h31

Envoyé par Tramb

Bouffon. C'est évident que c'est le file system du GEMDOS le meilleur.
Je recommande des disquettes double face/double densité formatées avec 81 pistes et 10 secteurs par piste pour en tirer le meilleur parti.

Ouai s'pas faux, mais ca reste du FAT

Ha ca me rappelle le bon vieux temps : j'avais ecrit un programme qui utilisait l'interrupt DMA pour faire du chargement de secteurs en tache de fond, pendant que je decompressais. Ca doublait la vitesse apparente de chargement.

**Tramb** · 31/07/2012, 13h03

C'est vrai que ça reste du FAT

C'est marrant parce que (hors sujet total) j'ai l'impression qu'il y a eu une régression sur l'asynchronisme entre l'état de l'art des 16/32 et les interruptions bien maîtrisées et "faciles à écrire" et la transition vers le code multithread "facile à écrire" de nos jours. Entre les deux, c'était pas bien clair comment faire sous Windows 3.1 puis 95 (pour moi en tout cas

)

**Møgluglu** · 31/07/2012, 13h47

Peut-être parce que les locks globaux au niveau du système dans les gestionnaires d'interruptions, aujourd'hui c'est un peu mal vu ?

**Tramb** · 31/07/2012, 14h04

Sans doute, mais justement, du fait de tous ces "nouveautés" (pour le "grand public" programmeur, pas pour les mecs qui codaient du pthread sous Digital Unix) j'ai l'impression que ça a stagné un petit moment dans le monde x86.

**haik** · 31/07/2012, 14h45

Tendencieux la manchette d'Ars Technica sur la réaction de rms à l'arivée de Steam/Gnu/Linux (...)

http://arstechnica.com/information-t...mes-unethical/

Pour une fois qu'il fait pas direct dans le bête "bouh caca propriétaire, Gnu/Linux c'est que pour les barbus qui se servent de leur PC pour, heu, editer un fichier texte dans emac"

**newbie06** · 31/07/2012, 16h58

Envoyé par Tramb

Sans doute, mais justement, du fait de tous ces "nouveautés" (pour le "grand public" programmeur, pas pour les mecs qui codaient du pthread sous Digital Unix) j'ai l'impression que ça a stagné un petit moment dans le monde x86.

Hum, je ne suis pas convaincu par ton argument. Les interruptions c'etait bien clair, lock global ou pas, reentrance ou pas, on est d'accord. Mais je ne vois pas en quoi ca aurait empeche les gens de comprendre le multi-threading au sens large.

**Tramb** · 31/07/2012, 17h33

L'absence de stabilité des APIs, le manque de doc...
Bref osef, maintenant toutes nos applications sont SMT-friendly.
/relance msvc qui freeze pour la 345ème fois de la journée

Edit: le multitache coopératif d'une certaine époque, c'était épique.

**newbie06** · 31/07/2012, 17h35

Envoyé par Tramb

L'absence de stabilité des APIs, le manque de doc...

pthread c'est stable depuis longtemps non ?

**Tramb** · 31/07/2012, 17h54

Je te parle du monde x86 des années 90 et donc... et donc...

**Møgluglu** · 31/07/2012, 18h46

...et donc personne n'en avait rien à foutre du multi-threading à cette époque, vu la rareté des plate-formes multiprocesseur d'une part et l'évolution continue des perfs qui rendait les trucs asynchrones immédiatement obsolètes d'autre part ?

**braoru** · 31/07/2012, 19h09

Et le pire dans tout ça, c'est que la clé est souvent dans un mix entre l’asynchrone et le multithread/multiprocess (comme node.js :-))

**Tramb** · 31/07/2012, 19h58

Bah ce qui a morflé, justement, c'est la latence dans les GUIs et dans les loadings!
Heureusement on optimisait un peu plus à l'époque, hum.

**newbie06** · 31/07/2012, 20h32

Envoyé par Tramb

Je te parle du monde x86 des années 90 et donc... et donc...

Ha ça m'exclut de la conversation. A cette période je n'avais pas de x86.

**rOut** · 31/07/2012, 22h04

En même temps une GUI texte c'est toujours rapide à charger.

---------- Post added at 22h04 ---------- Previous post was at 20h40 ----------

Et Blizzard en rajoute une couche.
http://www.begeek.fr/blizzard-approu...indows-8-66414

Allez Steevy, encore un petit effort et c'est EA qui annonce qu'ils portent toute leur collection de jeux sous Linux.

**war-p** · 01/08/2012, 08h48

Envoyé par rOut

En même temps une GUI texte c'est toujours rapide à charger.

---------- Post added at 22h04 ---------- Previous post was at 20h40 ----------

Et Blizzard en rajoute une couche.
http://www.begeek.fr/blizzard-approu...indows-8-66414

Allez Steevy, encore un petit effort et c'est EA qui annonce qu'ils portent toute leur collection de jeux sous Linux.

C'est pas lui qui ne voulait pas que Diablo 3 tourne sur wine en bannissant les mecs qui l'utilisait?

**newbie06** · 01/08/2012, 09h19

Envoyé par war-p

C'est pas lui qui ne voulait pas que Diablo 3 tourne sur wine en bannissant les mecs qui l'utilisait?

Non, le ban etait parce qu'il est plus facile de faire du boting sous Wine. Donc les mecs qui botaient sous Wine se sont faits choper et bien entendu ont pretendu que c'etait pas vrai.

**war-p** · 01/08/2012, 09h57

Ok, j'avais pas eu vent de cette partie de l'histoire...

**newbie06** · 01/08/2012, 12h22

On n'a pas de preuve au final, mais je doute fortement que Blizzard fasse un ban base uniquement sur l'utilisation de Wine (ref). J'ai joue pendant des annees a WoW sous Linux et n'ai jamais ete ennuye.

---------- Post added at 12h22 ---------- Previous post was at 12h19 ----------

Envoyé par rOut

En même temps une GUI texte c'est toujours rapide à charger.

Rah ouai : a l'epoque avec mon Atari ST j'etais jaloux des GUI texte PC, ca scrollait tellement vite ! Alors j'avais hacke l'editeur de DevPac pour coller des routines optimisees pour afficher les caracteres et c'etait enfin vraiment rapide

On s'eloigne de Linux... Alors je vais raccrocher au sujet : mon premier contact avec UNIX a ete avec MINIX sur ST ; a l'epoque j'avais ete outre : la console affichait mes caracteres alors qu'ils n'etaient pas encore pris en compte. J'avais pas vraiment l'habitude du multi process a ce niveau

**Tramb** · 01/08/2012, 12h51

C'était très très très mystérieux pour moi à l'époque MINIX (évidemment je l'avais acheté, c'était pas du tout des floppies douteuses).
"Kezako? A quoi ça sert?"

Ça a fait du chemin, Unix (et cie) chez le particulier!

**newbie06** · 01/08/2012, 13h04

Envoyé par Tramb

C'était très très très mystérieux pour moi à l'époque MINIX (évidemment je l'avais acheté, c'était pas du tout des floppies douteuses).
"Kezako? A quoi ça sert?"

Ouai, surtout qu'on ne pouvait plus discuter directement avec le hardware pour tout tuner, un veritable scandale !

Ça a fait du chemin, Unix (et cie) chez le particulier!

Merci Apple

**snipx** · 01/08/2012, 16h22

Merci nVidia, l'est beau celui la : nvidia linux binary driver priv escalation exploit

**Tramb** · 01/08/2012, 16h59

Envoyé par newbie06

Ouai, surtout qu'on ne pouvait plus discuter directement avec le hardware pour tout tuner, un veritable scandale !

Et bien ça tombe fort à propos, nVidia nous prouve qu'on peut encore taper dans les registres hardware en userspace

**rOut** · 01/08/2012, 18h31

Envoyé par snipx

Merci nVidia, l'est beau celui la : nvidia linux binary driver priv escalation exploit

Ca marche pas chez moi en tout cas.

**Tramb** · 01/08/2012, 18h33

Ca fonctionne chez mon voisin de taf.

**braoru** · 01/08/2012, 18h54

J'utilise nouveau :-) mais, il est vraiment gros quand même

**ducon** · 01/08/2012, 20h45

Code:

> ./pub_c.bin 
./pub_c.bin: ligne1: /bin: est un dossier
./pub_c.bin: ligne2: $'*\r' : commande introuvable
./pub_c.bin: ligne3: aida-rapport.txt : commande introuvable
./pub_c.bin: ligne4: $'*\r' : commande introuvable
./pub_c.bin: ligne5: aida-rapport.txt : commande introuvable
./pub_c.bin: ligne6: $'*\r' : commande introuvable
./pub_c.bin: ligne7: aida-rapport.txt : commande introuvable
./pub_c.bin: ligne8: aida-rapport.txt : commande introuvable
./pub_c.bin: ligne9: $'\r' : commande introuvable
./pub_c.bin: ligne11: $'\r' : commande introuvable
: Aucun fichier ou dossier de ce type
./pub_c.bin: ligne13: $'\r' : commande introuvable
./pub_c.bin: ligne32: $'\r' : commande introuvable
./pub_c.bin: ligne38: $'\r' : commande introuvable
./pub_c.bin: ligne40: $'\r' : commande introuvable
./pub_c.bin: ligne48: $'\r' : commande introuvable
./pub_c.bin: ligne49: static : commande introuvable
./pub_c.bin: ligne49: $'\r' : commande introuvable
./pub_c.bin: ligne50: static : commande introuvable
./pub_c.bin: ligne50: $'\r' : commande introuvable
./pub_c.bin: ligne51: $'\r' : commande introuvable
./pub_c.bin: ligne52: Erreur de syntaxe près du symbole inattendu « ( »
'/pub_c.bin: ligne52: `static void poke_byte(volatile uint32_t *m, uint32_t ofs, uint8_t val)

Discussion: Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

Outils de la discussion

Règles de messages