Reprise du message précédent :

Je dis peut être une connerie, mais ça vient pas de la définition de tes partitions ?
 
De memoire quand j'installe linux et que je gdisk, par défaut il change les valeurs de début et de fin de blocs si nécessaire pour que ça s'aligne sur des multiples de 1024

je sais pas trop, en fait la notion de "block" est pas vraiment un concept du monde des disques, donc peut-être que c'est ajouté au moment du partitionnement, mais ça serait bien que tout le monde soir multiple de tout le monde.
 
là j'essaye avec parted.

ça fait plusieurs années que la plupart des outils linux, gdisk inclus, alignent les partitions (début et fin) sur 1MB par défaut (soit 2048 secteurs de 512 bytes ou 1024KB  ou 1024*1024B)
 
edit: depuis gdisk 0.7.2 (6/26/2011)...

historiquement la taille d'un secteur c'est 512B

justement, je soupçonne que l'emploi du mot "bloc" n'était pas innocent.

Dites, c'est quoi en 2018 la bonne méthode pour ripper des dvds? (oui, je sais, 2018 et dvd dans la même phrase c'est étrange. )

le cylindre c'est juste par rétrocompatibilité, sinon les softs modernes n'en ont plus rien à foutre
 
8225280B = 255 têtes multiplié par 63 secteurs de 512 octets https://en.wikipedia.org/wiki/Logic [...] ranslation
 
255 têtes et 63 secteurs c'est juste le maximum qu'on pouvait utilisé dans les anciens bios
 
du coup tu devrais te poser la question de pourquoi tu fait des calculs avec des tailles de cylindres, un "cylindre" n'a plus de réalité physique depuis le passage en adressage LBA

parce que j'ai eu un warning à ce propos ?

par quoi ?

Michael Avenatti (l'avocat de Stormy Daniels) qui va se payer Rudolph Giuliani.
 
https://forum.hardware.fr/hfr/Discu [...] #t53540759
 

 

C'est 4k maintenant, si c'est pas aligné dessus ça pète les perfs
https://en.wikipedia.org/wiki/Advanced_Format

moi j'en ai marre de ce métier, je crois que j'ai juste envie d'être chroniqueur dans un média.

net-entreprise, ça reste moisi, mais au moins ils sont en https maintenant. Ce n'était pas le cas l'an dernier. Rien de bien grave, ça n'est que le portail vers toutes les prestations sociales pour des dizaines de milliers d'entreprises...

Y'a un autre moyen ?

déclarations papier par la poste.

j'me fais tellement chier la journée avec cette merde de Java et tout son brol que chuis de noyer mon chagrin en codant un moteur de ray-tracing

HandBrake propose plein de profils pré-configurés.
 
Si t'as pas de contrainte côté lecteur, je dirais H264 2000 kbps (c'est large) pour la vidéo, audio pass-thru, dans un MKV et hop.

Si t'as pas de contrainte tu fais du h.265 AV1 comme un homme

En asm68k j'espère

Mon post manquait de source
http://reho.st/http://download.aba [...] %20037.jpg

Griller dix fois plus de cycles CPU pour un pauvre DVD bof.

https://www.amazon.com/50pcs-steppe [...] A6KHF97HA2  
'tain ça prenait combien de millénaires pour sourcer des trucs pareils il y a 10ans ?

En tout cas les commentaires donnent envie

Sinon les Javateux, pourquoi vous aimez pas Gradle?

Je note, merci!

surement du recyclage de vieux appareils fait par des enfants dans des pays du tiers monde, ça fait clairement pas envie

parce que c'est complexe, ça n'apporte rien de plus que Maven à part une couche de complexité complémentaire, que c'est du Groovy et que ce que je veux au départ c'est compiler du Java et pas apprendre un nouveau langage (Groovy), c'est lourd et lent, etc...

C'est complexe mais ça apporte pas mal de choses sympatiques aussi: leur résolveur maison est rapide et robuste, le serveur de compilation, l'extensibilité est triviale comparée à écrire de plugins maven
Et tu peux utiliser le DSL en Kotlin.
 
Je trouve que les build.gradle de gros projets open source sur lesquels je tombe parfois sont assez intuitifs, alors que j'ai pas des bons souvenirs de Maven quand je bossais avec des gros projets multi-modules et un tetra-million de lignes XML dans chaque POM.

M'en fous, Kotlin, Groovy ou whatever, j'ai pas envie d'apprendre un nouveau langage juste pour compiler du Java quoi... La config XML de Maven est pourrie, c'est un fait. Du coup, Gradle aurait pu s'appuyer sur des fichiers de config yaml ou json par exemple, plutôt que sur un langage.

De toute façon, Gradle, Ant ou Maven, tout ça c'est de la merde. Java c'est de la merde, Eclipse c'est de la merde, Spring c'est de la merde (j'ai du réécrire totalement un DelimitedLineTokenizer pour Spring Boot tellement celui fourni d'origine était lent sur des fichiers de plusieurs Go à force de passer son temps à construire des objets dont on se demande à quoi ils servent... j'ai divisé le temps de parsing de mon fichier par 5).
Faire 11 ans de C# et Visual Studio pour ensuite faire du Java sous Eclipse, c'est comme si tu baisais Mimie Mathy après avoir baisé Emma Watson

Tiens c'est marrant, t'utilises un truc optimisé pour le cas général et ça marche pas pour ton cas super particulier, donc c'est de la merde ? Bien joué roger.
Accessoirement DelimitedLineTokenizer n'est pas une classe de Spring Boot (mais de Spring Batch) et elle fait une allocation de String par token dans sa boucle principale, ce qui ne me semble pas délirant. T'as profilé pour voir d'où venait le problème ?

Le purement déclaratif a ses limites et remplacer du XML par du YAML c'est comme préférer le cancer à la peste bubonique.

Nan mais attends, Gontran ! Je demande à un framework (Spring Batch) de me parser un fichier texte de 7.5 Go, un bête fichier plat. Je peux penser qu'étant donné que c'est sa raison d'exister, il me livrera out of the box un parser qui parsera ça dans un temps acceptable
Mais merde, 42 mn sur un serveur de préprod, faut pas exagérer. J'ose espérer qu'une taille de 7.5 Go rentre dans le cas général, sinon autant faire un bête script python pour parser ce bordel et on n'en parle plus.
 

Oui, mon doigt à fourché
(parlons en de Spring Boot d'ailleurs... un framework dédié uniquement à l'initialisation et la config d'un autre framework (Spring)... t'embarques 3 kgs de dépendances rien que pour la config, on marche vraiment sur la tête dans cet écosystème de merde...)
 

J'étais parti pour, mais le plugin TPTP m'a pété au nez
(bon, je sais que ce plugin c'est de la merde -aussi-, mais c'est le seul que je peux installer)
Du coup j'en avais tellement ras le cul que j'ai refait un tokenizer from scratch en sous-marin !

 
Tous les batchs ont pas vocation à intégrer des fichiers de 7.5 Go, de plus l'implémentation de la classe en question est générique : elle est adaptable à un grand nombre de format de fichiers.
Et dans la plupart des cas ses performances ne posent absolument aucun problème. T'as juste suivi le workflow normal où une fois que t'as encontré un problème de perf, tu spécialises le code en tenant compte des spécificités des données que tu dois charger. C'est le b.a.ba de ce boulot en fait.
 

 
Là encore, Spring Boot c'est une forme de compilation de ce que l'équipe Spring pense être des good defaults. C'est pas là pour faire du café ou guérir le cancer, mais ça fait largement le boulot pour des petites applications, des prototypes, simuler des serveurs distants, etc. Pareil, de base t'as pas 3 kilos de dépendances, les configurations auto sont certes packagées chacune dans une dépendance à part (justement pour pouvoir mieux les retirer et foutre les tiennes à la place).
 
C'est pas parfait, notamment pour les gros projets, mais ta critique est un peu légère.
 

 
En vrai, si t'avais pas un stack d'outils merdique t'aurais pas de problème.

Dites, pour tester du hard avec un PC + carte I/Os, vous avez déjà vu faire ça avec autre chose que du labview ou labwindows ?

une toolbox matlab ?  
scilab ?

y'a pas un appel système pour obtenir le contenu de /proc en mémoire ?
 
je trouve ce truc génial:
https://github.com/OpenXT/blktap3/b [...] /cpumond.c
219 lignes pour parser /proc/stat et le mettre dans un segment de mémoire partagée toutes les seconde (avec un sleep() de bon aloi)

pas con, pas con du tout

Tu n'aimes pas LabVIEW ?

pour moi labview c'est fait pour visualiser/monitorer/régler un process
 
pas pour faire du test