zx81 a écrit 264 commentaires

Pas facile de trouver les limites dans la doc :-(( :

"When an AUTO_INCREMENT column runs out of values, InnoDB wraps a
BIGINT to -9223372036854775808 and BIGINT UNSIGNED to 1.
However, BIGINT values have 64 bits, so do note that if you were to
insert one million rows per second, it would still take nearly three
hundred thousand years before BIGINT reached its upper bound."

Ca, c'est les limites du ficher "container" de la table sur le fs hôte...
Ca ne dit rien en ce qui concerne le *nombre* de lignes, au pire c'est
sur 4 octets : 4 milliards maxi :-).
Les deux limites n'ont rien à voir, mais chacune est bloquante de
manière indépendante (liées par la taille de la ligne + frais fixes divers
par ligne/par page/etc selon la structure interne).

> AlmSlmA -> Apres la mode SMS, la mode Acronyme ?
Je vais vite breveter un nouvel algo de compression de textes
de forums ;-)
(bon, allez, je te laisse les royalties sur tes ACD...)
(et pour le "tedlt", j'étais pressé, désolé !)

tedlt...

Pas encore de gestion "fr" au niveau du bios:
donc CTRL-Q !!!

> Y a des méta donnée qui font qu'ont pas peut y acceder directement

Oui je sais :-) (c'est pour ça que je ne veux pas faire de raid hard histoire de ne pas avoir à immobiliser des cartes raid dans un placard en attendant que celles de mes clients crament !)

Sinon le format est le même non ? (les métasdonnées du raid sont à la fin du "container" md il me semble et du coup le fs inclus est un chouïa plus petit que la partition md...). Du coup grub peut "comprendre" les octets qu'il voit sur le mdX comme un fs "normal".

En attendant mieux, je crois que je vais tout faire sur un disque et mirrorer le tout par la suite (et mettre le swap en raid aussi).

Je confirme pour 2.6.12.
Y'avait des délais assez bizarres lors de certains accès sur un
montage cifs (surtout sous Kde ce qui était d'autant plus étrange
vu que ça marchait bien en console...).

Mon script n'envoie rien :-) (même que je ne chope pas d'évènement
quand la clé est retirée...)
Je vais regarder à quoi il sert ce gros script...

Sinon, mon teste tourne toujours et là ça vient de passer de sdb
à sdc à "scsi620", assez illogique quoi...

Certes, j'aurais du y penser moi-meme et commencer par là...

En général, en cas de soucis, je commence toujours par le plus
bas "niveau" disponible: si c'est une machine test tensions
alim/mémoire/cpu/ carte mère/fs, si c'est du réseau alors tests des
cables (eh oui des fois un câble bien gentiment posé qu'on ne
touche jamais se coupe !)
Alors je préfère commencer au début en "empilant" des "couches
de confiance" (en moyenne ça ne fait PAS perdre de temps, l'inverse
si...)

ça peut pas faire de mal...
(touch /forcefsk pour forcer sur tous les fs et rebooter)

bizarre, je l'ai en etch cette commande mais elle vient du paquet "tetex-bin", je trouve pas de paquet pour la sarge...
Mais bon ça marche...

tiens chez moi c'est man access tout court...
et sinon, elle gère les ACLs cette commande (si le fs en dessous le
fait bien sur (montage -o acl) ?

Leur choix a aussi été motivé par le fait que cette région du Nord est
proche de plusieurs frontières et, en manière d'enseignement, il est
tout à fait judicieux d'initier les étudiants à plusieurs langues tout en
utilisant "normalement" des outils informatisés.
Seule une distrib de logiciels libres semble avoir permis de switcher
facilement d'une langue à l'autre ! (à moins que je ne me trompe, je
ne crois pas qu'on puisse facilement et à coût faible basculer un
ensemble Windows/Office/PhotoShop/etc de l'italien vers l'allemand
puis le français...).
Bon, sur ce, je retourne à ma traduction de Kde en alsacien :-)

quand tu lance simplement gcc à l'invite, il se lance bien ou il est
toujours non trouvé ?

si je ne m'abuse, les scripts rcS.d/* sont lancés avant les rcN.d/*
donc essaye de déplacer ton init pcmcia vers rcS.d/S39 (ou 40
ou 41... sans garantie mais c'est ce que je tenterais...:-)

-verifie ton runlevel (2 ?) : lance runlevel
-poste ici le resultat d'un ls -l /etc/rc2.d et de ls -l /etc/rsS.d
... y'a p'tet encore une histoire de hotplug ?

ce qui serait bien, ce serait de pouvoir le forcer uniquement à
partir d'un noeud de l'arborescence (et que ça reste valable
pour tous les sous-répertoires, sauf si on le ré-enlève, etc...)

Ouais, bon, j'ai rien dit... C'est juste la parenthèse qui traine à la
fin du lien qui gène (pas très propre quand même :-)

Microsoft VBScript runtime error '800a000d'
Type mismatch: 'cint'
/international/product.asp, line 26

c'est peut-être plus du nunux qu'ils embarquent maintenant...

... la liste des outils facilitant la recherche de logiciel.

Si tu passes un peu de temps à observer les scripts lancés au boot,
tu trouveras la solution (sous /etc/rcS.d) ...
Bon allez, je te la donne: crée un fichier forcefsck à la racine (par
exemple en faisant touch /forcefsck).

Merci pour tous ces détails !

Pour la table des jours fériés, j'ai fait la même chose (avec un petit
bouton sur le formulaire de màj pour insérer les jours standards
d'une année).

Je vais peut-être aussi utiliser plus de triggers, ça peut éviter de
couteuses jointures (pléonasme ... :-) car dans le genre exception
à la con, j'ai par exemple: si le personne a une certaine fonction
(ET à la date voulue, car ça bouge...) et si elle bosse entre 23h00
et 07h00 alors son compte d'heure sera un forfait de 3h00 et non
pas 08h00 ! (c'est un forfait pour des éducateurs de nuit).

Et je ne veux *pas* avoir de code spécifique au calcul dans l'appli,
tout doit venir de la bdd, pour éventuellement faire des extractions
directes via odbc sans se taper de champs "calculés" par le client
(qu'il soit logiciel ou humain :-).

Cette gestion de planning est ma première appli php. Autant j'aurais
pu torcher ça en 2 semaines avec un Delphi sous Windows, j'ai
estimé le tout à environ 2 mois de taf. Comme ça, une migration des
postes clients sous un *nix est envisageable !

Mon gros taf actuellement est d'écrire un browser générique de
table (liste/tri/filtre/ajout/supp/modif/impression). Ne connaissant
pas les limites du php (parce que les fonctionnalités c'est facile, il
suffit de lire les docs !), je perds beaucoup de temps à valider
toutes mes routines de bas-niveau (perfs entre autres...). Mine de
rien, ça fait déja + de 2000 lignes de code (oui, je sais, il y a des
libs php qui existent, mais je crois que je vais plus vite que de
trouver comment elles marchent, et puis ça forme !).

Pour faciliter les pointages, je pense bidouiller qq chose avec des
clefs usb: on fout une clef spécialement formatée et pouf, on a
pointé (avec un petit message vocal). Mais ça ne règle pas le
problème d'un pointage oublié (si on oublie de pointer le départ
de midi, le pointage d'arrivée à 14h00 sera pris comme le départ
oublié)... A moins de générer un départ automatique si la période
est "louche"...

voir aussi: http://linuxfr.org/forums/12/8020.html(...)

Pour ce qui est de la tronche de la table, je vais réflechir au fait
d'enregistrer une période par ligne plutôt que d'en avoir deux
en cas de chevauchement (mais je dois faire des stats par jour férié
alors j'ai pensé à y inclure le jour, enfin bon, à voir...).

C'est simplement qu'après avoir peiné 15 ans sur des bases
conséquentes dénormalisées à outrance, j'ai enfin la chance de
pouvoir créer une base (une 50aine de tables) from scratch, j'en
profite pour la faire bien d'équerre !! :-)

Sinon, oui, je vais regarder pour les types "maison", c'est vrai que
c'est pas mal cette possibilité d'extension...

Enfin, ça peut peut-être servir à d'autres, j'ai fait 2 tests de perfs,
la table contient 100.000 lignes, le serveur est un amd 2GHz avec
512Mo de ram et un disque IDE de 80 Go et os=debian testing:

La première requête suivante prend 0,3 sec (lancée plusieurs
fois pour annuler l'effet de cache) :

select
id_pers,
sum(duree)
from
vu_heur_reel_duree
group by
id_pers

La vue appellée étant:

create or replace view vu_heur_reel_duree(id_pers,jour,duree) as
select
hr.id_pers,
hr.jour,
case
when (duree is not null) then (hr.duree - '00:00:00')
when (hr.heure_fin >= hr.heure_deb) then
(hr.heure_fin - hr.heure_deb)
else ('23:59:59' - hr.heure_deb + '00:00:01')
end
from
tb_heur_reel hr;

Avec la bidouille de rajouter une seconde dans l'expression, ça
marche...

Le 2eme test, je l'ai fait avec une fonction que voila:

create or replace function fc_elapsed_time(
time without time zone,
time without time zone,
time without time zone)
returns time without time zone as '
declare duration alias for $1;
declare start_time alias for $2;
declare end_time alias for $3;
begin
if (duration is null) then
if (end_time >= start_time) then
return end_time - start_time;
else
-- hack to handle substract from midnight
return ''23:59:59'' - start_time + ''00:00:01'';
end if;
else
return duration;
end if;
return;
end;
' language 'plpgsql';

Et la requête (sur la table directement):

select
id_pers,
sum(fc_elapsed_time(duree,heure_deb,heure_fin))
from
tb_heur_reel
group by
id_pers;

Ca renvoie évidemment la même chose, mais ça met 2 secondes
soit 6 fois plus !

La différence est insignifiante sur de petits volumes (qq milliers de
lignes) mais l'écart se creuse quand on atteint les volumes de
"production".

Comme je vois que tu bosses aussi sur un soft de pointage, as-tu
prévu qq chose pour les changements heure été/hiver ?

D'ou l'intérêt de sa question ! C'est peut-être la dernière machine à ne
pas pouvoir changer d'OS dans tout un parc, alors si il "suffit" de
dépenser un peu de sous en plus pour unifier, pourquoi pas ?
Sinon, au niveau stabilité, ça risque d'être "sport" :-)
Pourquoi pas un qemu ?