[Discussion] Recompilation de son kernel

[MisterFreez]

Sympa ton script j’ai juste parcouru rapidement, mais j’ai déjà quelques remarques. Visiblement tu ne connais pas la règle des 80 caractères C’est pas systématique, c’est une vieille règle, je le reconnais, mais ça à l’avantage d’éviter des longues lignes de codes illisibles.

Ça viens de vieux compilateur lol
80 de large et un écran de haut.

Edit : J’aurais aussi une ou deux remarques :
[ul][li]Tu prends pas en compte les erreurs possibles, lors de la compilation par exemple.[/li]
[li]Il y a des petits trucs genre :

echo "compile en cours" echo "compile en cours" `date` >> "$Log" Startcompile=`date`
pourrait être remplacé par

Startcompile=`date` echo "compile en cours" $Startcompile | tee "$Log"
Alors oui c’est pas de l’optimisation de folie mais, c’est un tic chez moi.[/li][/ul]

[mattotop]

[quote=“MisterFreez”][quote=“Ashgenesis”]Sympa ton script j’ai juste parcouru rapidement, mais j’ai déjà quelques remarques. Visiblement tu ne connais pas la règle des 80 caractères C’est pas systématique, c’est une vieille règle, je le reconnais, mais ça à l’avantage d’éviter des longues lignes de codes illisibles.[/quote]Ça viens de vieux compilateur lol
80 de large et un écran de haut. [/quote]Non, ça vient des vieux terminaux séries de base non reconfigurable qui font du 80 colonnes 25 lignes.
C’est juste une question de respect pour ceux qui ne disposent que de ce genre de terminaux pour relire le code.

[MisterFreez]

[quote=“mattotop”]Non, ça vient des vieux terminaux séries de base non reconfigurable qui font du 80 colonnes 25 lignes.
C’est juste une question de respect pour ceux qui ne disposent que de ce genre de terminaux pour relire le code.[/quote]
J’applique, j’applique. Puis c’est vachement pratique pour ouvrir deux fichiers avec vi.

[fran.b]

[quote=“mattotop”][quote=“MisterFreez”][quote=“Ashgenesis”]Sympa ton script j’ai juste parcouru rapidement, mais j’ai déjà quelques remarques. Visiblement tu ne connais pas la règle des 80 caractères C’est pas systématique, c’est une vieille règle, je le reconnais, mais ça à l’avantage d’éviter des longues lignes de codes illisibles.[/quote]Ça viens de vieux compilateur lol
80 de large et un écran de haut. [/quote]Non, ça vient des vieux terminaux séries de base non reconfigurable qui font du 80 colonnes 25 lignes.
C’est juste une question de respect pour ceux qui ne disposent que de ce genre de terminaux pour relire le code.[/quote]

Ce format de 80 colonnes des terminaux vient des premières cartes êrforées (les IBMs) qui avaient 80 colonnes (il fallait pouvoir les afficher). Par suite, il y a eu des cartes 132 colonnes et les imprimantes avaient 132 colonnes.

En fait c’est plutôt 72 plutôt que 80:
Un programme fortran se doit d’avoir les 7 premiers caractères de la lignes pour l’étiquette, du 8ième au 72ième pour l’instructions et les colonnes 73 et au delà servent à évenutellement numéroter les cartes dans le cas où elles tombent par terre. (Personnellement, je mettais un grand coup de feutre en diagonale sur la tranche du paquet). Cela explique la fameuse justification à 72 colonnes de beaucoup de client mail par exemple… C’est devenu une tradition. En général, la tradition est plutôt donc de limiter à 72 le nombres de caractères par lignes…

[mattotop]

t’es vraiment vieux alors ?

[panthere]

[quote=“Ashgenesis”]Sympa ton script j’ai juste parcouru rapidement, mais j’ai déjà quelques remarques. Visiblement tu ne connais pas la règle des 80 caractères C’est pas systématique, c’est une vieille règle, je le reconnais, mais ça à l’avantage d’éviter des longues lignes de codes illisibles.
[/quote]

Tien je ne connaissait pas
En fait j’ai un 22 pouce ce qui permet justement de faire des longues lignes, avec une reso 1680-1050 donc évidement sa donne pas du tout la même chose sur un 17, certe on n’y pense pas quand on code, surtout pour moi qui préfère avoir le tout sur la même ligne pour éviter de jouer avec l’ascenseur (avec le mulo) ce qui est dur pour ma concentration. je sai spas pourquoi sa me fait sa mai c’est assez ch***

Pourquoi n’as-tu pas mis la config dans un fichier de conf à part, que tu appel par la suite dans ton script?

J’avai essayer mai sa avais tendance a buguer en gros avec un screen - gedit il ne le lançais pas ou pas tout le temp, je me suis donc fait un autres script avec un menu que je peux lancer a choix par exemple si je tape 23 il me lance gedit avec pour édition le script: Ensuite je tape 22 et il lance le script
De plus un fichier de conf en plus du script demande d’ouvrir un fichier supplémentaire, je trouve pas vraiment utile il est plus facile d’éditer directement le script aux complet évidement c’est commes les gouts et les couleurs.

Ta variable $unamevertion je l’aurais appelé $unameversion. Essaye de refactoriser ton code pour pouvoir prendre des paramètres en comptes ça permet d’éviter de configurer un fichier de conf avec finalement peu de variables à changer comme ça tu les passes directement en paramètre et c’est finis.
J’avais déjà fait un script un peu moins évolué ashgenesis.debian-fr.net

tu veux dire passer par la ligne de commande ?
c’est pas très difficiles a faire mai je trouve risquer car si on ce goure et que la commande est lancer sa peux faire foirer une compile. Même avec un minimum de contrôle par le code, en plus pour retenir le numéro de vertion …

Une fois refactorisé, j’ajouterais ton script à mon tuto avec ton accord bien sur Et si tu as d’autres choses à faire rajouter sur la re-compilation de kernel n’hésite pas à me contacter.[/quote]

La je ne suis pas sure d’avoir compris ce que tu voulais
Adapter la longueur des ligne a 80,( ou celon fran.b 72) puis passer les numéro de version en paramètres sur la ligne de commande ?

Sinon pas de souci tu peux reprendre le code sans problème

j’ai vu sur le tien que tu aprécie de faire apelle a sleep, c’est a eviter car durant ce labse de temp sa laisse l’oportuniter a une erreur en memoire, par exemple un programe en C/#/¢++ qui place mal son pointeur et qui va écrire dedant… si c est a la chaîne c’est mieux

cp /boot/config-`uname -r` /usr/src/linux/.config

A proscrire car le .config peux ce trouver avec un autres nom que celui du kernel, en gros c’est un risque de confusion pour la configuration a la chaîne (plusieurs compilation) c’est particulièrement importemp car tu ne testes pas si le fichier est copier celon la velonter de l’utilisateur.

j’ai remarquer qui si le .config est pas copier il est recupérer automatiquement de l’ancien noyaux. fait un essai pour voir si sa ce produit aussi chez toi. (oldconfig puis xconfig)

Bon je ne teste pas non plus, parce que je n’utilise justement pas ton code citer plus haut. En gros c’est a l’utilisateur de ne pas ce planter

pourrait être remplacé par
Code:
Startcompile=date
echo “compile en cours” $Startcompile | tee “$Log”

Alors oui c’est pas de l’optimisation de folie mais, c’est un tic chez moi.

Petie question qu’elle est le gain par rapport a un >> ? car le man est pas très explicite

[MisterFreez]

[quote=“panthere”][quote=“MisterFreez”]
pourrait être remplacé par

Startcompile=`date` echo "compile en cours" $Startcompile | tee "$Log"

Alors oui c’est pas de l’optimisation de folie mais, c’est un tic chez moi.[/quote]
Petie question qu’elle est le gain par rapport a un >> ? car le man est pas très explicite [/quote]
T’exécute une seule fois la commande date et s’il existe des optimisation possible pour écrire sur le terminale et dans un fichier en même temps (et il en existe, j’en suis quasiment sur) tee les auras faites. En plus c’est plus facilement maintenable et tu t’embarrasse moins avec pleins de lignes pour l’affichage.

Pour ce qui est de oldconfig il est fait pour récupérer une ancienne configuration et y ajouter les nouvelles. Mais je trouve que c’est pas une excellente idée de ne pas séparer la phase de configuration de celle de compilation. xconfig je connais pas.

j’ai vu sur le tien que tu aprécie de faire apelle a sleep, c’est a eviter car durant ce labse de temp sa laisse l’oportuniter a une erreur en memoire, par exemple un programe en C/#/¢++ qui place mal son pointeur et qui va écrire dedant… si c est a la chaîne c’est mieux

Là j’ai pas bien compris. Tu parle d’un autre programme quelconque qui foire ?
Si c’est le cas, les accès mémoire foireux d’un autre programme ne peuvent pas planter ton appli, le noyau donne un espace d’adressage virtuel par processus, elle n’est pas partagée entre les processus sauf quand on fait de la mémoire partagée mais là il faut le vouloir.

[Ashgenesis]

[quote=“panthere”][quote=“Ashgenesis”]Sympa ton script j’ai juste parcouru rapidement, mais j’ai déjà quelques remarques. Visiblement tu ne connais pas la règle des 80 caractères C’est pas systématique, c’est une vieille règle, je le reconnais, mais ça à l’avantage d’éviter des longues lignes de codes illisibles.
[/quote]

Tien je ne connaissait pas
En fait j’ai un 22 pouce ce qui permet justement de faire des longues lignes, avec une reso 1680-1050 donc évidement sa donne pas du tout la même chose sur un 17, certe on n’y pense pas quand on code, surtout pour moi qui préfère avoir le tout sur la même ligne pour éviter de jouer avec l’ascenseur (avec le mulo) ce qui est dur pour ma concentration. je sai spas pourquoi sa me fait sa mai c’est assez ch***
[/quote]Moi aussi sur mon fixe je suis avec cette résolution là mais je préfère voir scinder les actions plutot que d’en faire une qui tiens sur 200 caractères ou plus. Je trouve ça moins lisible quitte à en faire une fonction et à l’appeler. Mais bon les goûts et les couleurs ça ne se discutent pas

[quote=“panthere”]

Pourquoi n’as-tu pas mis la config dans un fichier de conf à part, que tu appel par la suite dans ton script?

J’avai essayer mai sa avais tendance a buguer en gros avec un screen - gedit il ne le lançais pas ou pas tout le temp, je me suis donc fait un autres script avec un menu que je peux lancer a choix par exemple si je tape 23 il me lance gedit avec pour édition le script: Ensuite je tape 22 et il lance le script
De plus un fichier de conf en plus du script demande d’ouvrir un fichier supplémentaire, je trouve pas vraiment utile il est plus facile d’éditer directement le script aux complet évidement c’est commes les gouts et les couleurs.
[/quote]je ne vois pas trop où il y a besoin d’ouvrir un fichier supplementaire que tu ouvre ton script pour la config ou ton fichier de conf pour celle-ci tu n’as qu’un fichier à ouvrir d’une manière ou d’une là ou ça change c’est que tu ouvre un fichier de conf et que tu sais que c’est un fichier de conf, tu rajoute ce dont tu as besoin ou une modification si necessaire et ensuite tu lance ton script. Je ne vois pas trop le problème là[quote=“panthere”]

Ta variable $unamevertion je l’aurais appelé $unameversion. Essaye de refactoriser ton code pour pouvoir prendre des paramètres en comptes ça permet d’éviter de configurer un fichier de conf avec finalement peu de variables à changer comme ça tu les passes directement en paramètre et c’est finis.
J’avais déjà fait un script un peu moins évolué ashgenesis.debian-fr.net

tu veux dire passer par la ligne de commande ?
c’est pas très difficiles a faire mai je trouve risquer car si on ce goure et que la commande est lancer sa peux faire foirer une compile. Même avec un minimum de contrôle par le code, en plus pour retenir le numéro de vertion …
[/quote]idem qu’avec le fichier de conf le risque est le même il est possible de faire une erreur et de ne pas s’en apercevoir lors du remplissage de la conf que ce soit dans le fichier de conf ou directement dans le script c’est au programmeur de faire le nécessaire pour qu’il y ai le moins d’effet de bord possible lors de l’execution de son code[quote=“panthere”]

[quote]
Une fois refactorisé, j’ajouterais ton script à mon tuto avec ton accord bien sur Et si tu as d’autres choses à faire rajouter sur la re-compilation de kernel n’hésite pas à me contacter.[/quote]

La je ne suis pas sure d’avoir compris ce que tu voulais
Adapter la longueur des ligne a 80,( ou celon fran.b 72) puis passer les numéro de version en paramètres sur la ligne de commande ?

Sinon pas de souci tu peux reprendre le code sans problème
[/quote]En gros oui c’est ça, les 80 caractères, et la refactorisation. en fait l’objectif de la refactorisation du code c’est de l’optimiser de manière à ne pas avoir 25 fois la meme chose copier/coller dans ton code source. Tu regroupe ton code par fonctionnalité tu créé les fonctions nécessaires et tu t’arrange pour ne pas avoir à répéter de code.
J’attends donc la version optimisé pour la rajouter dans mon tutos merci pour ton autorisation [quote=“panthere”]
j’ai vu sur le tien que tu apprécie de faire appelle a sleep, c’est a eviter car durant ce labse de temp sa laisse l’opportunité a une erreur en mémoire, par exemple un programe en C/#/¢++ qui place mal son pointeur et qui va écrire dedant… si c est a la chaîne c’est mieux
[/quote]L’objectif n’était pas de faire un code parfait mais comme j’ai critiqué le tiens c’est normal que tu fasse de même
Le sleep était là juste pour faire patienter l’utilisateur lors de sa compilation de manière à bien voir les messages qu’il y avait entre chaque étape rien de plus ils sont superflus je te l’accorde.[quote=“panthere”]

cp /boot/config-`uname -r` /usr/src/linux/.config

A proscrire car le .config peux ce trouver avec un autres nom que celui du kernel, en gros c’est un risque de confusion pour la configuration a la chaîne (plusieurs compilation) c’est particulièrement importemp car tu ne testes pas si le fichier est copier selon la volonté de l’utilisateur.

j’ai remarquer qui si le .config est pas copier il est recupérer automatiquement de l’ancien noyaux. fait un essai pour voir si sa ce produit aussi chez toi. (oldconfig puis xconfig)

Bon je ne teste pas non plus, parce que je n’utilise justement pas ton code citer plus haut. En gros c’est a l’utilisateur de ne pas ce planter
[/quote]Pas en utilisant ma méthode de recompilation, elle est faite pour fonctionner ainsi je ne vois pas de problème si tu respecte des règles préétabli pour faciliter la chose. Le script n’était pas là pour être général sur une recompilation de kernel mais juste pour aider les nouveaux utilisateurs à recompiler leur kernel. C’est un script particulier pour un cas particulier. en connaissant la nouvelle version du kernel que l’on veux installer on peux en une commande le faire comme indiquer dans les règles d’usage du script

kernel.sh linux-source-2.6.15 sealle nom du script suivi de 2 arguments le premier correspondant aux sources du kernel et le second au nom donné au nouveau kernel personnalisé. La conf du kernel faite une fois est réutilisé après.

Si l’utilisateur se plante, il y aura une erreur lors de l’installation du paquet et cela sera indiqué. Il n’y aura donc pas de suite. Si l’utilisateur rentre les bons paramètre alors ça iras jusqu’au bout normalement sauf si il y a un plantage lors de la compilation mais cela serait arrivé tout de même si il l’avait fait manuellement.

[panthere]

[quote]Ashgenesis a mentionner:
Moi aussi sur mon fixe je suis avec cette résolution là mais je préfère voir scinder les actions plutot que d’en faire une qui tiens sur 200 caractères ou plus. Je trouve ça moins lisible quitte à en faire une fonction et à l’appeler. Mais bon les goûts et les couleurs ça ne se discutent pas
[/quote]

Je confirme; de plus c’est facilement modifiable, seulement sa rajoute des ligne de code, mai on peux pas avoir le beure l’argent du beur et le [censurer] de la fermière

je ne vois pas trop où il y a besoin d’ouvrir un fichier supplementaire que tu ouvre ton script pour la config ou ton fichier de conf pour celle-ci tu n’as qu’un fichier à ouvrir d’une manière ou d’une là ou ça change c’est que tu ouvre un fichier de conf et que tu sais que c’est un fichier de conf, tu rajoute ce dont tu as besoin ou une modification si necessaire et ensuite tu lance ton script. Je ne vois pas trop le problème là

Oui sur le principe , si déclare que éditer un fichier de conf doit être éditer plutôt qu’un script.
mai évidement sa fait du code supplémentaire, donc plus lourd c’est vraiment utile, ou devrai-je plutôt dire indispensable ?

idem qu’avec le fichier de conf le risque est le même il est possible de faire une erreur et de ne pas s’en apercevoir lors du remplissage de la conf que ce soit dans le fichier de conf ou directement dans le script c’est au programmeur de faire le nécessaire pour qu’il y ai le moins d’effet de bord possible lors de l’execution de son code

C’est aussi pour ça que moins il y a de code plus l’erreur cera facile a trouver (quoi que) et surtout moins facile a faire. Windo** est une (((référence))) (pas taper svp) en la matière a force d’avoir des sure-couches on fini par plus voire ce qu’il y a dessous.

En gros oui c’est ça, les 80 caractères, et la refactorisation. en fait l’objectif de la refactorisation du code c’est de l’optimiser de manière à ne pas avoir 25 fois la meme chose copier/coller dans ton code source. Tu regroupe ton code par fonctionnalité tu créé les fonctions nécessaires et tu t’arrange pour ne pas avoir à répéter de code.
J’attends donc la version optimisé pour la rajouter dans mon tutos merci pour ton autorisation

Tu parle des fonctions, en fait les fonction du sh permette d’isoler les variables, mai d’inporter celle qui son dans le processus père ce qui est donc plus fiable
mai certes le bute c’est d’éviter de ce répéter.

Pas en utilisant ma méthode de recompilation, elle est faite pour fonctionner ainsi je ne vois pas de problème si tu respecte des règles préétabli pour faciliter la chose. Le script n’était pas là pour être général sur une recompilation de kernel mais juste pour aider les nouveaux utilisateurs à recompiler leur kernel. C’est un script particulier pour un cas particulier. en connaissant la nouvelle version du kernel que l’on veux installer on peux en une commande le faire comme indiquer dans les règles d’usage du script

Certe pour les débutants, j’avais vu sa autrement vu sous est angle la je dit rien

le nom du script suivi de 2 arguments le premier correspondant aux sources du kernel et le second au nom donné au nouveau kernel personnalisé. La conf du kernel faite une fois est réutilisé après.

Si l’utilisateur se plante, il y aura une erreur lors de l’installation du paquet et cela sera indiqué. Il n’y aura donc pas de suite. Si l’utilisateur rentre les bons paramètre alors ça iras jusqu’au bout normalement sauf si il y a un plantage lors de la compilation mais cela serait arrivé tout de même si il l’avait fait manuellement.

Ah nan je déteste compter sure les autres programmes pour contrôler les erreurs, particulièrement celle d’un utilisateurs. a moins que l’erreur ce fasse dans ton programmes ce qui est différent.

En fait il n’y a pas grand chose qui repasse des 80 colonne, osd et make-kpkg et les commantaires.
donc une autres question survien est qu’il faut tenir compte des l’indentation (les espaces ) qui son de 40 ? car on pourrait jouer sur 1 caractère a ce moment, mai sa deviens aussi moin lisible.
et comment tu veux faire si tu indente de plus de 3 tabulation (bon aux dela de 4 je concidère que c’est le code qui est ma penser. ) si tu a 300 ligne que tu doit diviser par 2 sa fait 600 ligne… (bon j’exagère hein)

je peux tricher en placent des fonctions pour revenir a 0 mai c’est vraiment pas indispensable j’ai un peux de peine a comprendre comment sa ce goupille.

sinon le script fait moins de 80 ligne de long
je vai placer une fonction pour osd c’est vrai que sa fait un peux long

MisterFreez à ecrit Là j'ai pas bien compris. Tu parle d'un autre programme quelconque qui foire ? Si c'est le cas, les accès mémoire foireux d'un autre programme ne peuvent pas planter ton appli, le noyau donne un espace d'adressage virtuel par processus, elle n'est pas partagée entre les processus sauf quand on fait de la mémoire partagée mais là il faut le vouloir.

Oui d’un autres programmes, Et non tu te plante. c’est pas parce que c’est isoler que c’est pas possible. Certe c’est conciderer comme une faille. c’est donc aussi un bug qui peux faire planter la machine. mai c’est pas forcement l’instantané.

[Ashgenesis]

[quote]Oui sur le principe , si déclare que éditer un fichier de conf doit être éditer plutôt qu’un script.
mai évidement sa fait du code supplémentaire, donc plus lourd c’est vraiment utile, ou devrai-je plutôt dire indispensable ?
[/quote]Je pars sur le principe que si il y a plus de 5 variables à modifier manuellement il peux être utile alors d’avoir un fichier de conf mais c’est loin d’être indispensable et celà n’engage que moi.

[quote]C’est aussi pour ça que moins il y a de code plus l’erreur cera facile a trouver (quoi que) et surtout moins facile a faire. Windo** est une (((référence))) (pas taper svp) en la matière a force d’avoir des sure-couches on fini par plus voire ce qu’il y a dessous.[/quote]Je suis d’accord mais ça dépend si ca permet de simplifier le code alors les erreurs n’auront plus lieu d’êtres.

[quote]Tu parle des fonctions, en fait les fonction du sh permette d’isoler les variables, mai d’inporter celle qui son dans le processus père ce qui est donc plus fiable
mai certes le bute c’est d’éviter de ce répéter.[/quote]Tout à fait

[quote]Ah nan je déteste compter sure les autres programmes pour contrôler les erreurs, particulièrement celle d’un utilisateurs. a moins que l’erreur ce fasse dans ton programmes ce qui est différent.[/quote]Je suis d’accord, mais là c’était fait de manière à ce qu’il n’y ai pas de restrictions pour l’utilisateurs. Il faut trouver le juste milieu entre un système bien sécurisé mais inaccessible et un système accessible mais mal sécurisé.

[quote]En fait il n’y a pas grand chose qui repasse des 80 colonne, osd et make-kpkg et les commantaires.
donc une autres question survien est qu’il faut tenir compte des l’indentation (les espaces ) qui son de 40 ? car on pourrait jouer sur 1 caractère a ce moment, mai sa deviens aussi moin lisible.[/quote]Normalement, il faut les prendre en compte mais on peux réduire la taille de l’indentation et augmenter quelques peu le nombre de colonne par ligne, pour exemple la norme tolère jusqu’à 120 caractères par ligne en PHP.

[quote]et comment tu veux faire si tu indente de plus de 3 tabulation (bon aux dela de 4 je concidère que c’est le code qui est ma penser. ) si tu a 300 ligne que tu doit diviser par 2 sa fait 600 ligne… (bon j’exagère hein)

je peux tricher en placent des fonctions pour revenir a 0 mai c’est vraiment pas indispensable j’ai un peux de peine a comprendre comment sa ce goupille.[/quote]C’est pas forcément triché mais optimisé. Un code ne devrait pas avoir plus de 5 imbrications en comptant fonction principale classe structure conditionnelle sinon c’est une mauvaise conception de l’algorithme.

[quote]sinon le script fait moins de 80 ligne de long
je vai placer une fonction pour osd c’est vrai que sa fait un peux long [/quote]Impeccable

[quote]
Oui d’un autres programmes, Et non tu te plante. c’est pas parce que c’est isoler que c’est pas possible. Certe c’est conciderer comme une faille. c’est donc aussi un bug qui peux faire planter la machine. mai c’est pas forcement l’instantané.[/quote]Il faut vraiment le vouloir pour écrire dans un espace alloué par un autre programme. Ça peux arriver par hasard mais dans ce cas, c’est vraiment pas de bol

[MisterFreez]

[quote]Oui d’un autres programmes, Et non tu te plante. c’est pas parce que c’est isoler que c’est pas possible. Certe c’est conciderer comme une faille. c’est donc aussi un bug qui peux faire planter la machine. mai c’est pas forcement l’instantané.

Il faut vraiment le vouloir pour écrire dans un espace alloué par un autre programme. Ça peux arriver par hasard mais dans ce cas, c’est vraiment pas de bol [/quote]
Très franchement je ne vois pas comment c’est possible. L’adressage virtuel de l’espace de travail devrait empêcher ça.

[panthere]

rès franchement je ne vois pas comment c'est possible. L'adressage virtuel de l'espace de travail devrait empêcher ça.

c’est ce que l’on appelle un bug, plus le code est long a exécuter plus la probabilité augmente.

bon récrit une partie du script, mai bon pour le fichier conf j’ai la flemme de le faire.
ceci dit sa fait moins joli enfin et on passe de 80 a 120 ligne !
bon je trouve quelque peux ces histoire de 80 colonne un peux absure, surtout qu’on lit de gauche a droit et seulment ensuite de haut en bas. si tiendrai qu’a moi on placerait tout sur 1 ligne :smt111

#!/bin/sh
#Script produit par panthere noire www.panthere-noire.com sous licence GNU

#Principe du script: le configurer,le lancer puis patienter.

#Répertoire : /kernel/source ici cela contient le tar des sources /kernel 
#étant le répertoire principale

#Répertoire: /kernel/source/intel_00X sera crée et contiendra les sources
# décompresser

#Note: il faut pouvoir utiliser xconfig et osd_cat,donc a installer si 
#c'est pas déja fait

#Note pour xconfig et osd il faut utiliser un serveur X !

#Bien sure vous pouvez changer cela. Seulement il vous faudra adapter
# le script

#Astuces: Pour les sources dédier une partition pour la compilation sa 
#a tendance a fragmenter le disque

# Fonction pour eviter de jouer avec screen et ps et grep :)

startcompil()
{
#================= variable a changement fréquant =============================
	#News vertion. 
	unamevertion="-custom-021"
	#News répertoire. 
	newpath="source/intel_021"
	#Ancienne configuration 
	oldconf="/kernel/source/intel_020/linux-source-2.6.22/.config"  

#============================ variable secondaire 
	#Répertoire principale
	source="/kernel/"
	#nom du fichier sources
	filesources="linux-source-2.6.22.tar.bz2"
	#Repertoire cree une foit dé-taré
	taredfiles="linux-source-2.6.22"
	#Note: ne log pas toute la compilation mai seulement certaine étape
	Log="/kernel/$newpath/Log_Installation.txt"
#==============================================================================
	(
		#Décompretion des sources
		cd $source 
		echo "Dé-tar en cours" 
		tar xvf $source$filesources 
		cp $oldconf $source$taredfiles
		echo "fin du détar" 
		mkdir $source$newpath 
		echo "déplacement des fichier" 
		mv $source$taredfiles $sorce$newpath 
		cd  $souce$newpath/$taredfiles 
#================= Configuration par l'administrateur =========================
		make oldconfig 
		make xconfig 
#==============================================================================
		Startcompile=`date`
      	echo "compile en cours" $Startcompile | tee "$Log"
		cd $source$newpath/$taredfiles
		echo $source$newpath/$taredfiles
		nice -n 19 make-kpkg --us --uc \
		--append-to-version $unamevertion --initrd buildpackage  
		echo "compile en terminée"
		echo "la compilation a commencer "\
		"a $Startcompile et c'est terminer a " `date` >> "$Log"
	)

#==============================================================================
# 2 eme processus lancer automatiquement
# après la fin le premier (pas indipensable)
#==============================================================================
	(
	startosd()
	{
		(
		UBX=`pidof /usr/bin/X`
		if [ -n "$UBX" ] && [ -n "$1" ] && [ "$1" = "1" ] ;then
				echo -e "\n ********************************* instalation des"\
				" paquets en cours *******************************"\
				"*" | osd_cat -A center -p \
				top -f -bitstream-*-*-r-*-*-25-*-*-*-*-*-*-* -d 10
		fi
		if [ -n "$UBX" ] && [ -n "$2" ] && [ "$2" = "2" ] ;then
				echo -e "\n ********************************* "\
				"La compilation est terminée" \
				"*********************************" | osd_cat -A center\
			 -p middle -f -bitstream-*-*-r-*-*-25-*-*-*-*-*-*-* -d 30
		fi
		)
	}

		cd $source$newpath
		startosd "1" "0"
		InstallImage=`find $source$newpath -iname linux-image*.deb`
		echo "installation des paquets $InstallImage" `date` >> "$Log"
		dpkg -i $InstallImage
		UBX=`pidof /usr/bin/X`
		startosd "1" "0"
		InstallHeader=`find $source$newpath -iname linux-h*.deb`
		echo "installation des paquets $InstallHeader" `date` >> "$Log"
		dpkg -i $InstallHeader
		UBX=`pidof /usr/bin/X`
		startosd "1" "0"
		InstallSources=`find $source$newpath -iname linux-s*.deb`
		echo "installation des paquets $InstallSources" `date` >> "$Log"
		dpkg -i $InstallSources
		UBX=`pidof /usr/bin/X`
		startosd "0" "2"
		echo "installation terminée" `date` >> "$Log"
	)
}
#demarage avec la fonction
startcompil
exit 0 

[MisterFreez]

[quote=“panthere”]rès franchement je ne vois pas comment c'est possible. L'adressage virtuel de l'espace de travail devrait empêcher ça.
c’est ce que l’on appelle un bug, plus le code est long a exécuter plus la probabilité augmente.[/quote]
Oui mais là ce serait un bug critique du noyau (le genre de truc que je remonte tout de suite aux dev).

À quoi ça sert de faire de si grandes lignes ? À la rigueur si tu veut faire des commentaires kikoolol tu peut encadrer ton titre genre ça

[code]###############

Ici on met un titre

###############[/code]
ou (celui que j’utilise qui est mieux pour les prog C/C++ par exemple car on a des commentaires avec //)

[code]# //////////////////////////////////

// Ici on met un titre //

#//////////////////////////////////[/code]

Ou pour être plus sobre de sauter des lignes.

[Ashgenesis]

Un petit document à lire
lug.fh-swf.de/vim/vim-bash/Style … ell.en.pdf

[thialme]

C’est quoi ça ! Un programme ?

Il faudrait vraiment penser à mettre des commentaires propres, ecrire des fonctions, gérer les erreurs, un fichier de conf ce serait en effet une bonne idée. Si quelqu’un veut le faire évoluer il fait comment ?

Ecrire un programme c’est pas seulement aligner des lignes de codes, cela doit être modulaire, maintenable et compréhensible. Ce n’est pas parce qu’il n’y a qu’une centaine de lignes par exemple qu’on peut se permettre de faire cela à l’arrache. Cela te retombe toujours sur le quoi du nez. Les utilisateurs Debian faut aussi les considérer comme des clients.

Idem pour l’empaquetage en paquets Debian, je voyais l’autre jour des personnes sur ubuntu qui ne se souciaient de rien hormis du fait d’avoir un .deb au final.

On a quand même un peu de temps à consacrer aux programmes que l’on fait à la maison, on n’a pas d’impératif de date.

Donc je t’encourage à revoir ton source et à le remanier en conséquence. Ce sont des habitudes à prendre.

C’est pour t’aider pas pour t’enfoncer.

[panthere]

[quote] thialme a péter une durite
C’est quoi ça ! Un programme ?
[/quote]

Non c’est une mouche qui bas le beurre

Il faudrait vraiment penser à mettre des commentaires propres, ecrire des fonctions, gérer les erreurs, un fichier de conf ce serait en effet une bonne idée. Si quelqu’un veut le faire évoluer il fait comment ?

Ben je voit pas ou est le problème ?

Idem pour l’empaquetage en paquets Debian, je voyais l’autre jour des personnes sur ubuntu qui ne se souciaient de rien hormis du fait d’avoir un .deb au final.

C’est pas beaux de jouer les pervers

Donc je t’encourage à revoir ton source et à le remanier en conséquence. Ce sont des habitudes à prendre.

euh les 80 colonne, tu trouves que c’est une habitude a garder toi ? donc si t’a une 2 Cv tout le monde doit rouler en 2Cv t’a trop mis de sucre dans ton thé il est un peux opaque

Mhmm je ne suis pas chaud pour faire un fichier conf. franchment pour 10 varaible… et pour 80 ligne code. c’est comme écraser une mouche avec un tank…

Tester les erreurs ? je ne vois pas ou il pourrait y en avoire…? tout les teste ton gere en interne par les programmes lancer. a la limite tenter de savoir si le programme a renvoyer une valeur vrai ou fausse. mai sa serai dupliquer ce qui existe déja, je veux dire par là que c’est afficher sure la console. Si tu veux tester tout le systeme (espace disque memoire ect) c’est possible mai je me voit mal faire sa en sh et franchement a ce moment la je me tourne ver un vrai langage. probablement le C/C++

Bon trolle poilu et mauvaise fois mis a part

Certes je pourrai faire mieux pour les commentaires, C’est a dire ne pas en mettre, un bon code n’en a pas besoin,le problème ce pose que si il a besoin de recevoir des informations de l’utilisateur.
donc juste faire une en-tête mai bon c’est vrai qu’aux départ ce petit “programe” était pas destiner a être publier :smt002

C’est pour t’aider pas pour t’enfoncer.

Pas très constructif …

[quote] Ashgenesis a proposer
Un petit document à lire
lug.fh-swf.de/vim/vim-bash/Style … ell.en.pdf
[/quote]

Vendu
Je veux pas abuser mai la même chose en fr c’est possible ?

[thialme]

[quote=“panthere”][quote] thialme a péter une durite
C’est quoi ça ! Un programme ?
[/quote]

Non c’est une mouche qui bas le beurre
[/quote]

C’est bien ce que je me disais.

[…]
Ben je voit pas ou est le problème ?

C’est bien dommâge. Tu as déjà codé autre chose qu’un script sh de moins de 100 lignes pour ton propre usage ? Je ne pense pas. Je présenterais un code comme cela à mes clients où à mon chef de projet, je pourrais remballer (même combat que ce soit en C, perl, python ou tout ce que tu veux).C’est pour cela que je t’invitais à faire quelque chose de plus propre. Maintenant tu fais ce que tu veux, mais il ne faudra pas s’étonner si tu as d’autres remarques à l’avenir. C’est quand même pas dure de prendre un peu de temps pour faire ça, et c’est pas moi qui vais le prendre à ta place.

[Ashgenesis]

Oulah zen les gars

[quote]euh les 80 colonne, tu trouves que c’est une habitude a garder toi ? donc si t’a une 2 Cv tout le monde doit rouler en 2Cv t’a trop mis de sucre dans ton thé il est un peux opaque [/quote]Pour les 80 colonnes je trouve clairement oui qu’il faut les garder mais je reconnais que ça fait un peu juste donc je dirais que 120 serait acceptable mais je ne pense pas plus. Il a été démontré qu’un paragraphe qui n’était pas trop large, était plus facile à lire que ce même paragraphe sur une seule ligne, c’est d’ailleurs l’une des raisons principales qui fait que les journaux sont conçus en multicolonnes.

[quote]Mhmm je ne suis pas chaud pour faire un fichier conf. franchment pour 10 varaible… et pour 80 ligne code. c’est comme écraser une mouche avec un tank…[/quote]10 variables pour 80 lignes de codes, je trouve que ça fait un peu beaucoup tu devrais pouvoir t’arranger pour réduire le nombre de tes variables. Et le nombre de lignes de ton code ne doit pas être un obstacle.

[quote]Tester les erreurs ? je ne vois pas ou il pourrait y en avoire…? tout les teste ton gere en interne par les programmes lancer. a la limite tenter de savoir si le programme a renvoyer une valeur vrai ou fausse. mai sa serai dupliquer ce qui existe déja, je veux dire par là que c’est afficher sure la console. Si tu veux tester tout le systeme (espace disque memoire ect) c’est possible mai je me voit mal faire sa en sh et franchement a ce moment la je me tourne ver un vrai langage. probablement le C/C++[/quote]Tu me disais l’autre fois que tu préférais gérer les erreurs toi-même et là tu précise que tout est géré en interne, je ne te suis plus car c’est la même chose dans mon script tout est géré en interne.

[quote]Certes je pourrai faire mieux pour les commentaires, C’est a dire ne pas en mettre, un bon code n’en a pas besoin,le problème ce pose que si il a besoin de recevoir des informations de l’utilisateur.
donc juste faire une en-tête mai bon c’est vrai qu’aux départ ce petit “programe” était pas destiner a être publier :smt002 [/quote]Faux, un bon code à besoin de commentaire mais pas trop. Il en faut le minimum pour les subtilitées que tu as trouvé au moment où tu l’as conçu, je te met au défis de reprendre n’importe quel code sans commentaire et de réussir à le comprendre en très peu de temps, même l’un des tiens que tu aurais fait il y a 6 mois.

Pour la version française du PDF désolé j’en ai pas mais si tu trouve pourquoi pas

[quote]C’est bien dommâge. Tu as déjà codé autre chose qu’un script sh de moins de 100 lignes pour ton propre usage ? Je ne pense pas. Je présenterais un code comme cela à mes clients où à mon chef de projet, je pourrais remballer (même combat que ce soit en C, perl, python ou tout ce que tu veux).C’est pour cela que je t’invitais à faire quelque chose de plus propre. Maintenant tu fais ce que tu veux, mais il ne faudra pas s’étonner si tu as d’autres remarques à l’avenir. C’est quand même pas dure de prendre un peu de temps pour faire ça, et c’est pas moi qui vais le prendre à ta place.[/quote]Comme panthere le disait le code n’était pas prévu d’être publié, si il s’y retrouve comme ça chez lui pourquoi pas, mais c’est vrai que dans le cadre d’une redistribution de code il faut respecter certaine règle de syntaxe et d’usage pour pouvoir être relus amélioré et complété si besoin est.

[fran.b]

t’es vraiment vieux alors ?

à 19 ans j’ai effectivement fait un projet en fortran sur carte perforées (déformation d’un barage lors de la montée en eau). Il y avait une première partie résolution d’un système linéaire et j’ai fait tombé mon carton… Le plus simple a été de tout retaper. Après je faisais des croix sur les paquets de cartes, l’année suivante je découvrais les claviers…
C’était en 1979-80

Discussion Thialme vs le reste: Des commentaires sont utiles mais effectivement, la clarté d’un code se voit surtout lorsque les noms de variables et des fonctions sont explicites. Je corrige des programmes à longueur de semaines, de mois, d’années (et c’est la plaie). Des commentaires mais longs et explicites ne remplacent jamais le nom: je préfère voir

let NOMBRE_DE_BITS_TOTAL=31;;

let rec itere_sur_n_et_m nombre_de_bits fonction_sur_bit n m =
if (nombre_de_bits = 0) then 0
else 2*(itere_sur_n_et_m 
            (nombre_de_bits - 1) 
            fonction_sur_bit 
            (n/2)
            (m/2)) 
     + (fonction_sur_bit (n mod 2) (m mod 2);;

let xor_sur_bit x y = x + y -2*x*y;;

let xor_sur_entier = (itere_sur_n_et_m NOMBRE_DE_BITS_TOTAL xor_sur_bit);;

let (prefix %$) = xor_sur_entier;;

(* exemple 5 %$ 9 renvoit 12 *)

plutôt que

let NB=31;;

let rec itere nb f n m =
if (nb = 0) then 0
else 2*(itere (nb - 1) f (n/2) (m/2))+(f(n mod 2) (m mod 2);;

let xorb x y = x + y -2*x*y;;

let xore = (itere NB xorb);;

let (prefix %$) = xore;;

(* exemple 5 %$ 9 renvoit 12 *)

Ici l’exemple est trop court pour que ça soit évident mais dans le deuxième cas, on finit par ne plus rien comprendre au code à cause du caractère guère explicite des variables. Un commentaire peut localement aider mais un programme avec 1 ligne de commentaires pour 1 ligne de code est presque aussi illisible (je ne compte pas les commentaires en entête du programme pour détailler les fonctions et variables).

En clair, des noms de fonctions et de variables explicites rendent souvent inutiles les commentaires même si ça alourdit le code (là, les noms sont qd même un peu long). Très souvent, je fais ma tambouille puis à grand coup de query/replace, je met des noms de variables explicites.

[mattotop]

quote="fran.b"
C’était en 1979-80[/quote]En 80-81, effectivement, j’entrais en seconde, et mon Lycée s’équipait de Sharp MZ80K, avec claviers et lecteurs de cassettes, et dans l’année, on avait récupèré aussi des MZ80B (avec de la couleur et 32Ko de RAM). Puis fin 81 début 82, un Oric, un Z80, et un Apple ][, et moi je récupèrais un Vic 20 avec 8Ko de RAM pour mon usage perso. On rentrait dans l’ère de la micro. A un an prés, effectivement, je me fadais aussi des cartes.