bonjour,
en fin de matinée, on me livre un petit SSD de 128GB,
je devrais installer quoi,
pour Debian:
-une version stable et je ne vous ennuerais peu,
-un version non stable avec les conséquences que vous savez
-une 3° solution un autre Linux
A+
JB1
Une stable.
bonjour,
OK
merci
JB1
Je ne sais pas pourquoi ricardo répond “une stable” sans plus de questions.
Le choix d’une stable/testing/unstable n’est pas simple. Tu parles de SSD : en effet, pour certains SSD récents, il faut mieux être en unstable car des drivers/noyaux récents sont nécessaires pour profiter pleinement des caractéristiques de ces disques. Il faut donc regarder le modèle de SSD.
Si tu n’as pas de contraintes techniques (le SSD marche sur la stable), c’est alors une question de choix personnel : veux-tu avoir (1.) des logiciels plus à jour et mettre les mains dans le cambouis de temps en temps (ce qui sous-entend d’avoir un minimum de connaissances de Debian) ou (2) préfères-tu la stabilité ?
P-S : à noter que, si tu fais le choix 1, il faut mieux prendre unstable (sid) que testing qui n’est pas une distribution complète en elle-même.
Moi j’aurai dit un Ubuntu voir une Fedora histoire de … 
[quote=“sidell”]Je ne sais pas pourquoi ricardo répond “une stable” sans plus de questions.
Le choix d’une stable/testing/unstable n’est pas simple. Tu parles de SSD : en effet, pour certains SSD récents, il faut mieux être en unstable car des drivers/noyaux récents sont nécessaires pour profiter pleinement des caractéristiques de ces disques. Il faut donc regarder le modèle de SSD.[/quote]
Tu parle de la gestion du ‘trim’ ou simplement des pilotes et de la reconnaissance en générale
Afin de tester si le trim est supporté :
hdparm -I /dev/sda | grep « TRIM supported »[quote=“sidell”]Si tu n’as pas de contraintes techniques (le SSD marche sur la stable), c’est alors une question de choix personnel : veux-tu avoir (1.) des logiciels plus à jour et mettre les mains dans le cambouis de temps en temps (ce qui sous-entend d’avoir un minimum de connaissances de Debian) ou (2) préfères-tu la stabilité ?
P-S : à noter que, si tu fais le choix 1, il faut mieux prendre unstable (sid) que testing qui n’est pas une distribution complète en elle-même.[/quote]
A noter que ni unstable ni testing n’est complète et l’une comme l’autre réclame par moment d’être plus ou moins complétée par l’une ou l’autre voir même dans certains cas exceptionnel par une stable .
Testing est incomplète et nécessite d’avoir stable ou sid en dépôt sous peine de gros problème. Sid est complète (je n’utilise que sid sans mention de stable et testing dans mon sources.list). Dans testing, les dev peuvent ôter des paquets parce qu’ils sont trop buggés ou créent des problèmes de dépendances (d’où la nécessité de piocher en stable ou en sid). Dans sid, les dev ne retirent rien. C’est pour ça qu’on peut fonctionne avec une sid seule et pas avec une testing seule.
Pour avoir tourné un moment en sid, ton meilleur ami est apt-listbugs 
bonsoir,
j’ai omis d’indiquer 32/64bits sur Intel
demain, je le monte et je fais la commande hdparm,
pour info, c’est pas bien,
OCZ SSD128GB vector garantie 5 ans
j’ai un vertex de même taille, il roule toujours!!!
Bonne nuit
A+
JB1
Testing est incomplète et nécessite d’avoir stable ou sid en dépôt sous peine de gros problème. Sid est complète (je n’utilise que sid sans mention de stable et testing dans mon sources.list). Dans testing, les dev peuvent ôter des paquets parce qu’ils sont trop buggés ou créent des problèmes de dépendances (d’où la nécessité de piocher en stable ou en sid). Dans sid, les dev ne retirent rien. C’est pour ça qu’on peut fonctionne avec une sid seule et pas avec une testing seule.[/quote]
Tu peux aussi vérifier ça avec un apt-show-versions
J’ai bien une SID actuellement installé depuis déjà une petit bout de temps et j’ai encore des paquets jessie et même wheezy car leur version n’ont pas été modifié depuis fort longtemps, si je les ai encore c’est bien pour une bonne raison
Sans compter les paquets en ‘hold’
Avant d’affirmer que l’on peux utiliser pleinement une Debian en version unstable sans avoir recours à des paquets provenant de la branche testing ou même stable dans certains cas exceptionnels 
Et le fait que les devs ne retire rien n’est pas une garantie de pouvoir utiliser les paquets possédant un bug véritablement bloquant.
[quote=“sidell”]Je ne sais pas pourquoi ricardo répond “une stable” sans plus de questions.
Le choix d’une stable/testing/unstable n’est pas simple. Tu parles de SSD : en effet, pour certains SSD récents, il faut mieux être en unstable car des drivers/noyaux récents sont nécessaires pour profiter pleinement des caractéristiques de ces disques. Il faut donc regarder le modèle de SSD.[/quote]
On peut largement faire tourner une stable avec un noyau récent. J’ai un SSD qui tourne sous wheezy sans souci…
[quote=“fran.b”]
On peut largement faire tourner une stable avec un noyau récent. J’ai un SSD qui tourne sous wheezy sans souci…[/quote]
C’est sûr que la situation s’est améliorée depuis la publication de wheezy. Avant, les possesseurs de certains SSD en voyaient de toutes les couleurs…
bonjour,
j’ai déjà un ssd sur une machine 64 bits qui tourne avec une 7.2 ou 3.2
A+
JB1
Testing est incomplète et nécessite d’avoir stable ou sid en dépôt sous peine de gros problème. Sid est complète (je n’utilise que sid sans mention de stable et testing dans mon sources.list). Dans testing, les dev peuvent ôter des paquets parce qu’ils sont trop buggés ou créent des problèmes de dépendances (d’où la nécessité de piocher en stable ou en sid). Dans sid, les dev ne retirent rien. C’est pour ça qu’on peut fonctionne avec une sid seule et pas avec une testing seule.[/quote]
Et pourtant, je tourne avec une Testing seule depuis quelques temps maintenant, il ne m’est pas arrivé de pépin. Quand j’ai essayé de retrouver des références officielles à ce sujet, on ne lit pas que Testing seule est à éviter.
Voir précisément ce topic pour les détails: gestion-des-dependances-sous-testing-t46767.html?hilit=Testing#p468734
bonjour,
avex retard:
root@alpha30:~# hdparm -I /dev/sdb
/dev/sdb:
ATA device, with non-removable media
Model Number: OCZ-VECTOR
Serial Number: OCZ-H27R61OSGJ789D37
Firmware Revision: 2.0
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 250069680
LBA48 user addressable sectors: 250069680
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 122104 MBytes
device size with M = 1000*1000: 128035 MBytes (128 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* DMA Setup Auto-Activate optimization
* Software settings preservation
* Data Set Management TRIM supported (limit unknown)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
Logical Unit WWN Device Identifier: 5e83a97a97ed3b5e
NAA : 5
IEEE OUI : e83a97
Unique ID : a97ed3b5e
Checksum: correct
root@alpha30:~# A+
JB1
les 2 ssd montés,
/dev/sdc est le plus récent
à première vue avec une lecture en diagonale,
les firmwares sont différent
A+
JB1
root@alpha30:~# hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: OCZ-VECTOR
Serial Number: OCZ-H27R61OSGJ789D37
Firmware Revision: 2.0
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 250069680
LBA48 user addressable sectors: 250069680
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 122104 MBytes
device size with M = 1000*1000: 128035 MBytes (128 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* DMA Setup Auto-Activate optimization
* Software settings preservation
* Data Set Management TRIM supported (limit unknown)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
Logical Unit WWN Device Identifier: 5e83a97a97ed3b5e
NAA : 5
IEEE OUI : e83a97
Unique ID : a97ed3b5e
Checksum: correct
root@alpha30:~# hdparm -I /dev/sdb
/dev/sdb:
ATA device, with non-removable media
Model Number: OCZ-VECTOR
Serial Number: OCZ-Y8614OUA3549WUJ5
Firmware Revision: 1.03.1
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 250069680
LBA48 user addressable sectors: 250069680
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 122104 MBytes
device size with M = 1000*1000: 128035 MBytes (128 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* DMA Setup Auto-Activate optimization
* Software settings preservation
* Data Set Management TRIM supported (limit unknown)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
Logical Unit WWN Device Identifier: 5e83a9746161200c
NAA : 5
IEEE OUI : e83a97
Unique ID : 46161200c
Checksum: correct
root@alpha30:~# Testing est incomplète et nécessite d’avoir stable ou sid en dépôt sous peine de gros problème. Sid est complète (je n’utilise que sid sans mention de stable et testing dans mon sources.list). Dans testing, les dev peuvent ôter des paquets parce qu’ils sont trop buggés ou créent des problèmes de dépendances (d’où la nécessité de piocher en stable ou en sid). Dans sid, les dev ne retirent rien. C’est pour ça qu’on peut fonctionne avec une sid seule et pas avec une testing seule.[/quote]
Et pourtant, je tourne avec une Testing seule depuis quelques temps maintenant, il ne m’est pas arrivé de pépin. Quand j’ai essayé de retrouver des références officielles à ce sujet, on ne lit pas que Testing seule est à éviter.
Voir précisément ce topic pour les détails: debian-fr.org/gestion-des-d … ng#p468734[/quote]
En fait, le problème de l’utilisation seule de testing vient d’une règle automatique de Debian qui veut qu’un paquet buggé depuis plus de deux semaines soit automatiquement supprimé de testing. La distribution testing se trouve alors incomplète.
Ce problème n’en sera sans doute plus un si le projet de transformer testing en une rolling release voit le jour (le projet est défendu par l’actuel DLP qui est candidat à sa succession).
bonjour,
sur un ssd j’ai installé une Debian 7…2,
et sur l’autre ssd une OpenSUSE que j’ai aussi transformé en passerelle (et cela fonctionne)
sur cette dernière je manipule pour kdump qui roule parfaitement sous Debian,
je pense avoir trouvé un exemple de wiki
A+
JB1
Ok sidell, si tu avais qq liens/références ce serait intéressant pour continuer mon petit tour de la question, je chercherai sinon.
@jb1,
… et donc, tout va bien ?
[quote=“Zbf”]Ok sidell, si tu avais qq liens/références ce serait intéressant pour continuer mon petit tour de la question, je chercherai sinon.
[/quote] J’ai discuté de ce sujet il y a quelques jours avec le DPL (Lucas Nussbaum) qui faisait une conférence dans ma ville. Comme son programme pour se faire réélire repose en particulier sur l’idée de transformer testing en une rolling release utilisable au quotidien, il exposait des pistes sur la manières de régler ce problème de paquets qui pouvaient disparaître de testing. Désolé, pas le temps de chercher des liens mais ça doit être dans les indications pour les développeurs debian.
Il y aussi un autre problème avec le fait d’utiliser testing tout seul : les dev “versent” parfois des paquets de sid vers testing alors que ces paquets cassent certaines dépendances. En effet, les développeurs ne vont pas attendre que tous les bugs de cohérence entre paquets soient réglés pour les envoyé dans testing vu que testing sert précisément de zone de test. Souvent, les devs ne sont pas bêtes et attendent que le paquets soit utilisables avant de l’envoyer en testing. Mais certains ne veulent pas attendre plusieurs semaines et versent leurs paquets pour pousser les autres à envoyer les leurs (et ainsi régler les problèmes de compatibilité). Bien sûr, dans ce cas, apt (ou aptitude) est ton ami est t’évite (souvent) de casser ton système ; mais il faut faire attention. Encore un exemple du fait, qu’actuellement, testing n’est pas faite pour être utilisée seule.
De plus, utiliser testing seule, c’est aussi s’exposer à un long freeze (plusieurs mois même si le projet de rolling prévoit de le ramener à 1 mois voire 2 semaines (je doute fortement qu’ils arrivent à deux semaines de freeze…)). Donc pas de mis à jour pendant un bout de temps avec les problèmes de sécurité qui peuvent en découler (et l’inconvénient d’avoir des logiciels un peu obsolètes.
Personnellement, j’utilise unstable qui est à mon avis la seule release de Debian qui est véritablement une rolling release (les paquets arrivés des développeurs de logiciels directement).
Merci pour ces infos,
Voilà en gros.