Marotte ⛧ a écrit 8798 commentaires

À priori seulement à condition d’utiliser conv=fdatasync

http://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync

man 1 dd me dit :

fdatasync : écrire les données du fichier de sortie physiquement avant de terminer

Ce problème de débit est certes pénible, mais la machine reste utilisable malgré tout.

Pour info, cette baisse du débit ne touche pas le réseau.
100% 1768MB 84.2MB/s 00:21

Par ailleurs, depuis que j’ai transféré ce système sur la nouvelle CM, j’ai aussi google chrome qui déconne. L’affichage rame complètement.

À part l’affichage (qui serait à priori un autre problème) tu as concrètement des problèmes de lenteur quand ça écrit ou lit sur le disque ?

Si tu fais un "sync", ça rame ?

1M c’est la taille exacte des blocs ?

Effectivement. Merci.

stef@medusa:/tmp/foo.git$ git branch habon
stef@medusa:/tmp/foo.git$ git checkout habon
Basculement sur la branche 'habon'
stef@medusa:/tmp/foo.git$ git status 
Sur la branche habon
nothing to commit, working tree clean
stef@medusa:/tmp/foo.git$ git push stef@medusa:/tmp/plop.git habon
Enter passphrase for key '/home/stef/.ssh/id_rsa': 
Décompte des objets: 3, fait.
Écriture des objets: 100% (3/3), 206 bytes | 0 bytes/s, fait.
Total 3 (delta 0), reused 0 (delta 0)
To medusa:/tmp/plop.git
 * [new branch]      habon -> habon

Ensuite il n’y a plus qu’à :

stef@medusa:/tmp/plop.git$ git branch 
  habon
stef@medusa:/tmp/plop.git$ git checkout habon
Basculement sur la branche 'habon'
stef@medusa:/tmp/plop.git$ ls
hello

pour ne pas laisser le dépôt distant perdu sans savoir sur quel branche il est.

oui car si j’ai bien compris c’est la branche pointée qui sert si quelqu’un d’autre veut cloner ce dépôt. Ça ne peut être deux états, deux commits (ou dans l’exemple, un commit et un dépôt vide)…

Tu m’auras appris un truc, merci.

En espérant pas dire de connerie… Si on l’autorise (donc il faut déjà configurer cela après l’init du premier dépôt) ça rend le dépôt de travail distant « inconsistant » ça veut sûrement dire qu’on ne peut plus vraiment s’en servir comme dépôt de travail avant de « s’aligner » (avec le reset) et donc perdre potentiellement des choses qui aurait été faites de ce côté… Peut-on stasher dans ce cas ? Le dépôt dans cet état, s’il est cloné, quel est le résultat ?

stef@medusa:/tmp$ mkdir plop.git
stef@medusa:/tmp$ cd plop.git/
stef@medusa:/tmp/plop.git$ git init
Dépôt Git vide initialisé dans /tmp/plop.git/.git/
stef@medusa:/tmp/plop.git$ cd ..
stef@medusa:/tmp$ mkdir foo.git
stef@medusa:/tmp$ cd foo.git/
stef@medusa:/tmp/foo.git$ git init
Dépôt Git vide initialisé dans /tmp/foo.git/.git/
stef@medusa:/tmp/foo.git$ touch hello
stef@medusa:/tmp/foo.git$ git add hello
stef@medusa:/tmp/foo.git$ git commit -m'hop'
[master (commit racine) 6b0a7b9] hop
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 hello
stef@medusa:/tmp/foo.git$ git push stef@medusa:/tmp/plop.git master
Enter passphrase for key '/home/stef/.ssh/id_rsa': 
Décompte des objets: 3, fait.
Écriture des objets: 100% (3/3), 206 bytes | 0 bytes/s, fait.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To medusa:/tmp/plop.git
 ! [remote rejected] master -> master (branch is currently checked out)
error: impossible de pousser des références vers 'stef@medusa:/tmp/plop.git'
stef@medusa:/tmp/foo.git$ 

C’est il me semble le comportement par défaut de ne pas le permettre.

Il est possible très facilement de pousser vers un dépôt de travail. Si le dépôt distant a un accès SSH, il n'y a rien à configurer.

Juste pour voir si j’ai bien compris. Dans ce cas on ne pousse pas vraiment, on se connecte en SSH à distance et on « tire » (en clonant) depuis là-bas :)

Et avant que tu ne m’en fasses la réflexion,

C’est tout aussi décentralisé car il est possible de commiter (ou créer une branche en local) et travailler dessus sans avoir à joindre le dépôt de référence

Oui j’ai bien écrit des conneries ici je pense ;)

Donc pour moi Git c’est forcément centralisé

Euh…

Je vais être plus précis.

Dans le cadre du développement logiciel, Git va de consort avec les différentes sur-couches, tu ventes toi-même un service comme Github, sa facilité d’accès, sa valeur ajoutée… Ces sur-couches, ainsi que tout le reste de la forge logicielle, n’est pas aussi décentralisé que Git lui-même. Tu ne la migres pas d’un clone magique comme tu peux le faire avec les fichiers suivis eux-mêmes. Ces fichiers sont effectivement partout localement, en principe, selon leur popularité plus précisément, exactement comme un torrent…

Si on sort du cadre du développement logiciel (avec bugtracker et CI, au minimum…) et qu’on considère juste Git pour ce qu’il est, c’est absolument décentralisé je te l’accorde.

Je pense à l’utiliser pour mon $HOMEDIR. C’est un moyen qui me semble plutôt efficace pour installer rapidement mon environnement sur une nouvelle machine, ainsi qu’avoir un historique et pouvoir revenir en arrière en cas d’erreur. Je pense que pour cet usage, je ne devrais pas forcément utiliser un dépôt bare sur une seule machine, mais simplement lier les $HOMEDIR les uns aux autres, au grès de mes envies, selon l’environnement où je travaille à un instant T (et surtout celui sur lequel j’étais à T-1…)

Même là, le fait d’avoir un dépôt qui centralise, sur un NAS par exemple c’est intéressant. Pour le répertoire /etc c’est pratique aussi. Je ne serais pas surpris de voir dans l’avenir des distributions intégrer plus git, pourquoi pas pour la gestion des packages et de la configuration.

perso je n'ai pas encore tout compris mais assez pour faire mon taf

J’en arrive à la même conclusion, je pense forcément en apprendre un peu plus mais je ressens aucun obligation de devoir tout assimiler pour collaborer sur du code.

Merci pour ton lien. J’étais passé à côté de ta réponse.

# my first ever commit with GIT! Don't greet me with an error.
> git commit -m "yippeee git!"

Howdy! So that git can give you credit for changes you make
    Please enter your name? Jon Saints
    Please enter your email? email@gmail.com
Thank you! Committing...

This replaces the more confusing error message that git shows users now:

Error 123: Look! Another stupid user is _trying_ to learn git. 

You should have known to type this first:
> git config --global user.name "Jon Saints"
> git config --global user.email "gmail@gmail.com"

You are a git DUFUS!! Just give up now. Seriously.

_o_ . Moi j’ai carrément pris ça comme une réelle volonté d’indiquer à l’utilisateur l’importance que la pertinence de ces informations revêtent pour la collaboration sur un projet :)

L’aide qui s’affiche par défaut je trouve ça assez bien. On dit toujours qu’il faut RTFM au débutant. Donc rappeler la base aux moments cruciaux est loin de me sembler délirant.

Bref, je pense que l’auteur initial de Git se souciait effectivement peu de cet aspect, si c’était logique pour lui.

D’automatiser le stash suivit d’un reset ça n’aide pas à comprendre ce qu’est ce stash.

Quand Linus a créé Git il devait faire pas mal de gestion de patch, plus que du développement à proprement parler. Git est fait pour faire de la gestion de patch (code source mais on pense aussi à la documentation…), et seulement cela, assez dans l’esprit Unix.

Bref, je pense que l’auteur initial de Git se souciait effectivement peu de l’accessibilité de son programme, son ergonomie, tant que c’était logique pour lui et son propre workflow.

Je reconnais que Git est pas non plus le logiciel que j’ai trouvé le plus facile à assimiler. Les pieuvres ça fait un peu peur ^^

Merci pour ce lien avec ces explications très claires et ces exemples. J’ai moi même commencé à rédiger ce genre de document afin de mieux mémoriser ce que j’apprends sur Git.

Mais bon, à part dire que « c’est probablement la commande la plus confusante(?) jamais écrite par des humains » nulle part est pointé ce qui peut porter à confusion…

Une fois qu’on a saisi la différence entre l’étape add et l’étape commit, l’action reset c’est clair comme du cristal de roche ;)

SVN n'étant pas simple à part pour les gens le connaissant

Je n’ai jamais travaillé avec SVN (mon utilisation à l’époque se limitait à faire des svn up pour récupérer le source de certains logiciels)

Je pensais benoîtement que SVN ayant moins de fonctionnalité (mais là encore je dis peut-être une connerie) il était plus rapide à prendre en main.

Pour en revenir à l’aspect centralisé/décentralisé j’avoue ne pas bien comprendre de quoi on parle.

Il me semble que pour travailler avec Git il est nécessaire d’avoir un dépôt de référence (un bare…) car il n’est pas possible de pousser vers un dépôt de travail (même si on peut cloner un dépôt de travail) et il n’est pas possible non plus de travailler dans un dépôt de référence…

Donc pour moi Git c’est forcément centralisé. C’est tout aussi décentralisé car il est possible de commiter (ou créer une branche en local) et travailler dessus sans avoir à joindre le dépôt de référence, ce qui, si j’ai bien compris, n’était pas possible avec SVN.

Bon, comme vous pouvez le voir je débute avec Git, mais j’avoue que pour le peu que j’en connais (push/pull/merge/rebase/stash… le gestion des "remotes") je trouve déjà que c’est un outil vraiment puissant, utile.

Il me reste pas mal de truc à voir : cherry-picking (bon ça ça à l’air simple) bisect/3-way merge… et sûrement d’autres fonctionnalités… J’ai l’impression que les possibilités sont quasi infinies avec le système de hooks…

Plutôt d’accord avec toi sur le fait qu’un outil simple à utiliser a plus de chance d’être adopté (et correctement utilisé). Par contre :

même si l'architecture de git est bien pensée, son interface comme sa doc sont catastrophiques.

Que leur reproches-tu au juste ?

Essaye de mettre un exit 0 à la fin de ton fichier rc.local…

Je te dis ça car j’ai eu ce problème… Par contre je ne sais pas si tu n’as pas un autre problème, vu le "connection refused"

Dernier commit de 2013… (visiblement), tu aimes les logiciels plus maintenus toi :)

Cela dit ce logiciel est peut-être très bien. Ce serait bien que la personne qui a moinssé ton commentaire dise pourquoi elle l’a fait :/

Pourquoi trois fois ?

Parce que j'aime bien avoir le code produit pas ma société sur un serveur que ma société maîtrise.

Gitlab est un service mais c’est aussi un logiciel, libre, que tu peux installer sur un de tes serveurs ;)

https://gitlab.com/gitlab-org/gitlab-ce

Si tu ne veux pas que la note affecte la visibilité du commentaire tu peux « surfer à -42 »… Tu dois avoir un bandeau en bas de la page, en cliquant sur la valeur « Seuil » tu peux choisir -42, tous les commentaires seront visibles.

Mon besoin est de créer un repository central et de travailler à la manière de SVN.
Remarque : GIT est à la base conçu pour travailler de manière décentralisée.

Je ne connais pas SVN, c’est peut-être pour ça que je ne comprends pas ton journal…

Git est bien conçu pour travailler de manière décentralisée, on peut cloner n’importe quel dépôt (même un dépôt de travail) cependant le dépôt de référence (ie: bare repository) représente bien une centralisation du développement ?

Voilà, est-ce que tu pourrais expliquer un peu plus ton idée, la problématique que tu as en utilisant Git « normalement » ?

Je ne sais pas si ton problème vient de là mais pour la directive DocumentRoot d’Apache il faut indiquer un répertoire, pas un fichier.

Sybase

J’utilise des scripts de supervision qui font appel à Sybase pour faire quelques requêtes sur des instance MS SQL. C’est vrai que ça marche très bien.

Cela dit je me demande à quel point les deux ont pu diverger et si, pour la partie serveur, Sybase pouvait être utilisé à la place de MS SQL…

Tu aurais pu utiliser un TL;DR comme il se doit, à savoir au début de ton commentaire et moins long que le message lui-même ;)

Merci pour ta réponse.

je pense aux applications java, en particulier dans le fichier /etc/xxxx/xxxxx.properties

et bien mets les bons droits sur ce fichier ce sera déjà ça :)

Si j’ai une application Java à installer hors dépôt officiels elle va dans /opt et ne met pas de fichiers ailleurs.

Parce que si les utilisateurs doivent s’identifier ils devraient utiliser chacun un fichier qui est dans leur $HOME, avec des droits à 0600

Oui c’est vrai que 8Hz c’est très bas, même pour un subwoofer.

Je viens de faire le test chez moi avec Audacity, j’entends rien en dessous de 18Hz, et de toute façon j’ai une atténuation pas possible en dessous de 30Hz, mes enceintes sont pas faites pour.

Pour les aigus j’entends jusqu’à 20kHz, j’ai testé à 21kHz, là j’entends vraiment plus rien (j’ai pas cherché la limite exacte…), pourtant clairement le son sort vu la réaction de ma chatte :)

8Hz, c'est inaudible tout court (sauf peut-être pour les baleines ?)

Ben voyons… C’est parce que les infrasons sont inaudibles qu’on se casse le cul à fabriquer du matos audio capable de les reproduire… Faut arrêter avec ce poncif. Oui, les infrasons sont perceptibles par les humains (quand la pression acoustique est suffisante bien entendu). On les "entend" avec la cage thoracique.

Il semblerait d’ailleurs que les sempiternelles valeurs limites, 20Hz et 20kHz, soient loin d’être exactes, sur Wikipédia à plusieurs endroits il est fait mention de l’intervalle 16-16000Hz

https://fr.wikipedia.org/wiki/Audition_humaine#Limites_de_la_perception_auditive