Bonjour Nal,
En faisant des recherches qui n'ont rien à voir avec ce que je parle (j'ai recherché des solutions sur un problème d'affichage Gnome sur Fedora), je suis tombé sur cet article du site linuxtricks.fr :
https://www.linuxtricks.fr/wiki/reinitialiser-le-mot-de-passe-root-depuis-grub-fedora-et-red-hat
N'étant pas assez connaisseur question sécurité sous Linux (même si cela fait des décennies que j'en fait mon pivot), je trouve ça hallucinant que cela soit aussi simple d'avoir des droits root sur un système.
Je pose ma question aux spécialistes.
Journal Réinitialiser le mot de passe root ??
13
mai
2023
# Du coup...
Posté par Psychofox (Mastodon) . Évalué à 10.
…c'est quoi la question?
Quand t'as acccès physiques à une machine, c'est généralement game over oui. Seul du chiffrement peut empêcher quoique ce soit. C'est pareil pour tout OS en fait. Sous windows tu peux monter la partition et réinitialiser le mot de passe de quelconque compte, y compris l'administrateur donc, via la modification de la base de registre. Un outil populaire pour ça est ntpasswd.
[^] # Re: Du coup...
Posté par AlexTérieur . Évalué à -10.
Sauf que non, tu n'as pas forcément besoin d'un accès physique, il y a des offres de serveurs dédiées qui te permettent de contrôler le démarrage…
Elle est là la question. Le problème du chroot ne se pose pas, puisque c'est le but. Sauf que là ce n'est pas du chroot.
[^] # Re: Du coup...
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 13 mai 2023 à 18:30.
Si tu as accès à la console kvm du serveur dédié, tu es l'administrateur.
Je suis étonné qu'après "des décénnies d'utilisation" tu n'as aucune vague idée de l'initialisation d'un système linux.
[^] # Re: Du coup...
Posté par AlexTérieur . Évalué à -10.
Et bien je trouve que la faille est là. Bien sûr qu'en étant "administrateur" tu fais ce que tu veux. C'est juste que je trouve que c'est une faille "simple" à mes yeux.
Et je trouve l'article de linuxtricks.fr trop précis, c'est-à-dire que ce n'est que pour les système "Red-Hat", pour qu'on ne se pose pas de question.
[^] # Re: Du coup...
Posté par Psychofox (Mastodon) . Évalué à 10.
C'est difficile de considérer ça comme une faille vu que c'est un comportement normal et connu.
[^] # Re: Du coup...
Posté par AlexTérieur . Évalué à -10.
Et pourquoi la précision sur le fait des systèmes "Red-Hat" ? Cela veut dire que sous les systèmes de base Debian/Ubuntu ce n'est pas aussi évident/c'est différent.
[^] # Re: Du coup...
Posté par Psychofox (Mastodon) . Évalué à 10.
Non. Ça veut dire que l'auteur ne s'est pas préoccupé de quel gestionnaire de démarrage est utilisé par les autres distribs.
Par exemple slackware utilise toujours lilo par défaut donc la procédure sur cette distrib serait différente. D'autres te laissent choisir parmi n gestionnaires différents.
[^] # Re: Du coup...
Posté par AlexTérieur . Évalué à -10. Dernière modification le 13 mai 2023 à 18:46.
Sauf que je parlais des systèmes comme Debian/Ubuntu… qui utilisent si je ne me trompe pas également grub2.
Il me semble que tu ne connais pas assez bien les systèmes comme Fedora/Red Hat, qui utilisent un init particulier.
[^] # Re: Du coup...
Posté par nsbs . Évalué à 10.
que ce soit lilo, grub, grub2, … il y a toujours moyen de faire quelque chose de similaire. Tu trouveras un équivalent pour toutes les distributions.
Il est néanmoins possible de chiffrer les disques durs, comme cela a déja été dit… mais aussi de protéger grub2 avec un mot de passe pour empêcher de changer la ligne d'initialisation. Et même Red Hat le documente ! (et grub2 n'est pas un "init particulier")
[^] # Re: Du coup...
Posté par totof2000 . Évalué à 5.
C'est quoi l'init particulier des fedora/redhat ?
[^] # Re: Du coup...
Posté par nsbs . Évalué à 6.
C'est grub2
Vachement exotique, hein ? ;-)
[^] # Re: Du coup...
Posté par totof2000 . Évalué à 2.
Je pensais que c'était systemd depuis un bout de temps (oui je chipote) :-)
[^] # Re: Du coup...
Posté par Faya . Évalué à 7.
Je ne comprends pas ce que tu dis. Fedora/RedHat, Ubuntu/Debian (et bien d'autres) utilisent grub2. Grub2 permet toujours d'accéder à son menu (avec
SHIFTen général) et d'éditer les paramètres de boot. De plus ce n'est pas spécifique à grub2, lilo & syslinux le permettent aussi, avec d'autres méthodes. Même sous Windows tu peux accéder au Command Prompt à l'initialisation en démarrant en Safe Mode. Donc en fait cette «««faille»»» est présente dès que tu as accès à un clavier (physique ou KVM) sur la machine qui boot et c'est toute l'industrie qui est touchée.Sauf… chiffrement.
[^] # Re: Du coup...
Posté par totof2000 . Évalué à 6.
ouais mais bon … c'est pas pareil … parce que Windows c'est un bon os. C'est toute la différence entre un bon os et un mauvais OS.
[^] # Re: Du coup...
Posté par gUI (Mastodon) . Évalué à 10.
Si j'ai accès à ta console, je peux tout détruire sans même avoir accès au root. C'est déjà une sacré faille, une sacré attaque qui marche sur tous les systèmes.
Si ensuite tu parles de l'accès à des données confidentielles, on te l'a dit, c'est chiffrement point à la ligne (quel que soit le système). L'accès root est un détail.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Protéger Grub via un mot de passe
Posté par François . Évalué à 3.
La solution la plus simple est de protéger Grub par un mot de passe qui sera demandé si tu essayes (via la touche 'e') d'éditer la ligne de commande.
Au temps de Grub version 1, c'était très facilement fait via l'ajout d'une simple ligne dans le fichier de conf de grub contenant le mot de passe en clair (pas terrible niveau sécurité).
Dans Grub 2 cela se fait via l'ajout d'un mot de passe préalablement hashé.
Plus d'info, par exemple: https://www.tecmint.com/password-protect-grub-in-linux/
[^] # Re: Protéger Grub via un mot de passe
Posté par mahikeulbody . Évalué à 10.
C'est peut-être plus simple mais ce n'est pas une solution. La seule solution est, comme le dit plus haut Psychofox, de chiffrer le disque dur.
[^] # Re: Protéger Grub via un mot de passe
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
Ça change pas le fond du problème, si tu as un accès physique à la machine tu peux booter sur une clé usb par exemple ou brancher le disque dur sur une autre machine.
Comme dit ci-dessus la solution c’est de chiffrer le disque dur, ce qui a pour effet de protéger tout le contenu du disque, et pas seulement le mot de passe root.
[^] # Re: Protéger Grub via un mot de passe
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 13 mai 2023 à 18:29.
Mettre un mot de passe sur le grub n'empêche pas d'utiliser autre chose que grub pour initialiser l'ordi…comme un autre grub depuis un disque usb.
Ça n'empêche pas non plus de sortir le disque de la machine, de profiter d'une vulnérabilité du TPM pour récupérer une clé de chiffrement, de récupérer une clé de chiffrement sur le carte mère via un analyseur logique hardware…
Dès que ton pc est potentiellement au contact d'une personne tierce non supervisée, il doit être considéré comme potentiellement compromis. Ce n'est pas pour rien qu'on filtre qui a accès à quoi et qu'on ne laisse pas un technicien seul dans un datacenter.
[^] # Re: Protéger Grub via un mot de passe
Posté par AlexTérieur . Évalué à -10.
Sauf que tu n'arrive pas à comprendre ce qu'on te dis… tu joues les connaisseurs. La solution de François est la meilleure dans de nombreux cas, sauf que tu mélanges beaucoup de choses… comme je l'ai dit plus haut, il est normal de pouvoir "casser" les protections root d'une machine qu'on a accès physiquement… ça cela est un comportement normal (comme tu le dis). Mais qu'on puisse devenir root au cours de l'initialisation d'un système aussi facilement… Pour moi cela n'est plus normal.
[^] # Re: Protéger Grub via un mot de passe
Posté par nsbs . Évalué à 10.
"Pour moi cela n'est plus normal"
Si ce n'était pas normal pour la profession, Linux serait un système interdit pour les systèmes critiques, et il ne me semble pas que l'ANSSI en France, ou son équivalent américain le proscrivent. Pourtant, si c'était une faille aussi béante, il n'y a aucun doute qu'il y ait une interdictions, ou des CVEs pour qu'il y ait une correction de sécurité.
Toi aussi tu joues les connaisseurs, mais les experts de la profession ont un autre point de vue que toi…
[^] # Re: Protéger Grub via un mot de passe
Posté par Zenitram (site web personnel) . Évalué à 5.
Euh, celui qui joue les connaisseurs sans rien comprendre du tout au sujet et en mélangeant beaucoup de chose, n'est pas aussi loin de toi en fait.
Vraiment, tu devrais arrêter de fantasmer à savoir mieux que tous les développeurs et admins Linux (et autres, tous les autres), et déjà essayer de comprendre de quoi tu parles, et comprendre le fonctionnement d'un ordinateur, vraiment on en est la, et te faire autant moinser ici sans parler en mal de Mélenchon, gilets jaunes, des antivax ou ce qui s'en approche, c'est quand même un niveau qui devrait t'alerter.
C'est 100% normal, dans la réalité.
Et en réalité, ça pourrait en effet être plus compliqué, mais ça ferait que cacher que c'est faisable, un faux sentiment de sécurité, car dès que tu as accès physique (direct ou lilo, pareil) à la machine, c'est mort de toutes façons (il reste le chiffrement, une autre histoire).
[^] # Re: Protéger Grub via un mot de passe
Posté par zurvan . Évalué à -10.
Sauf que les antivax ont refusé le hackage de leur génome ou je ne sais quoi d'autre par les grosses compagnies pharmaceutiques et les gouvernements corrompus, sous prétexte d'une "pandémie" bidon, et qu'ils ne regrettent absolument pas cette décision, mais on sort un peu du sujet initial (qui n'est certes pas passionnant)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Protéger Grub via un mot de passe
Posté par fearan . Évalué à 7.
euh… tu fais comment pour l'empêcher ? Pour windows tu lance le boot sur un autre système et tu réinitialise le mot de passe admin t'as des paquet de système live pour ça, généralement appelé rescue au autre. Pour tous les système c'est pareil; si tu as accès à l'initialisation, et que t'as pas chiffré c'est mort.
si tu veux pas qu'un petit malin modifie le démarrage de grub t'as qu'as le protéger par mot de passe, mais comme dit juste avant ton pirate, il vient avec un système de rescue et paf t'es foutu.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Hum…
Posté par ml . Évalué à 8. Dernière modification le 13 mai 2023 à 20:12.
Ce que tu cherches, c’est ça :
What is UEFI Secure Boot and how it works?
Ensuite il faut aussi sécuriser toute la chaîne du boot dont Grub, optionnel avec UEFI, mais aussi tout l’init du système. Ce n’est PAS une faille du noyau. Bien comprendre : la sécurité ce n’est pas un truc magique, elle est assurée par des opérations réalisées par le noyau. Un utilisateur qui modifie la ligne de commande du noyau est déjà, en quelque sorte, un utilisateur qui agit avec tous les privilèges (±virtualisation). Tu déclares comme faille de sécurité le fait que root peut modifier le mot de passe de root… -_-
De manière très schématique : un programme en espace utilisateur n’a pas le droit de demander des opérations “sensibles” (accès direct au matos par exemple) au CPU directement : il doit demander ces opérations au noyau. Le noyau, lorsqu’il reçoit une telle demande va effectuer des contrôles, pour s’assurer de la légitimité du programme. Puis ensuite faire réaliser au CPU l’action pour le compte du programme utilisateur. Sans noyau lancé, pas de sécu.
Le noyau est exécuté avec tous les privilèges donc celui qui lance l’exécution du noyau (ici Grub) a nécessairement tous les privilèges (±virtualisation). Si le sujet t’intéresse, le noyau exploite un mécanisme de sécurité assuré en dernière instance par le CPU : un peu de lecture.
À ce propos si vous tenez tant à troller. On peut discuter la tendance de l’informatique moderne à déléguer de plus en plus la sécurité aux couches inférieures, bas niveau (Rust, virtualisation, etc.) avec les conséquences que l’on connaît (failles de sécurité dans les CPUs, pour Rust ce n’est qu’une question de temps?).
Le chiffrement des données garantit la confidentialité, mais ne garantit pas contre la suppression et le rançonnage.
[^] # Re: Hum…
Posté par Zenitram (site web personnel) . Évalué à 6.
Ma compréhension de Secure Boot est que seuls les programmes sont protégés de modifs via signature, il faut tout une chaîne signé par un tiers de confiance. Ce ne semble pas protéger les données (dont fait partie un mot de passe) qui sont locales sans tiers de confiance qui les signe, et qui seraient à la charge d'une partie chiffrement.
Comment est-ce que Secure Boot sans chiffrement protège d'un changement de mot de passe comme tu le sous-entends?
[^] # Re: Hum…
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 13 mai 2023 à 22:07.
Lennart Poetering a bossé sur le sujet pour se protéger de la très mal (et sexistement) nommée attaque de la femme de ménage malfaisante:
https://0pointer.net/blog/
Plus qu'éviter le fantasme de l'auteur de ce journal sur un système non chiffré, c'est pour éviter qu'on modifie ton initrd dans ton dos pour y foutre un malware ou cheval de troie que tu vas charger au prochain démarrage.
L'idée est de ne pas passer par grub et de signer à peu près tout.
Mais bon au final comme dit plus haut on finit par devoir faire confiance au hardware (TPM2) et les récentes failles de sécurité touchant TPM2 montrent que ce n'est pas aussi simple que ça.
# mouais, pourquoi j'ai le root en 15 min ?! o_O
Posté par BAud (site web personnel) . Évalué à 5. Dernière modification le 13 mai 2023 à 21:21.
en tant qu'architecte SI, je suis intègre et respectueux des procédure (mes potes de la sécu sont embêtés des remontées que je leur fais…)
Pour autant, il me faut moins de 15 min pour chopper le mot de passe root sur la plupart des systèmes quand je passe en prod' (eh oh faut bien que je puisse travailler !? la consigne étant plutôt d'ouvrir un terminal root sans donner le mot de passe, bon ça revient au même, mais bon…)
déjà ne me donner que le sudo — ponctuellement — serait un peu plus responsable pour des admins (cela ne m'a jamais été proposé :/)
comment gérez-vous vos secrets dans votre boîte ? (pay attention it's a classical trap :p)
[^] # Re: mouais, pourquoi j'ai le root en 15 min ?! o_O
Posté par nsbs . Évalué à 2.
Dans mon ancienne boite, avant que je parte, ils mettaient en place Wallix Bastion, qui permettait de donner des accès root à des machines à des sous-traitant sans qu'ils aient connaissance du mdp root des machines (ou Admininstrator pour les Windows), et avec un enregistrement de sessions.
Sur le papier, ça avait l'air pas trop mal en terme de sécu, mais assez chiant à utiliser pour les admins (besoin de passer par une console web pour lancer des sessions ssh qui restent dans un onglet d'un navigateur web
[^] # Re: mouais, pourquoi j'ai le root en 15 min ?! o_O
Posté par IceCat (Mastodon) . Évalué à 1.
Je déteste devoir intervenir chez des clients avec un Wallix qui ouvre des sessions via le navigateur ! À tous les coups un (ou plusieurs :'))
^Wvont me faire fermer des onglets de son navigateur.Par contre il semble y avoir pour Wallix une cli, ou alors c'est un programme tiers, mais j'ai déjà eu des accès à travers des bastions Wallix, joignable en SSH depuis un vrai terminal.
[^] # Re: mouais, pourquoi j'ai le root en 15 min ?! o_O
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, tu peux utiliser ton client SSH (depuis un vrai terminal) si on te file la bonne adresse qui dit que tu rebondis sur le bastion Wallix en tant que tel compte pour atteindre tel autre machine en tant que tel autre compte.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mouais, pourquoi j'ai le root en 15 min ?! o_O
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
Les architectes SI ne sont pas censés "passer en prod". Ils y voient tellement d'horreurs que ça leur donne envie de démissionner (hein Serge ?).
# chiffrement des données
Posté par steph1978 . Évalué à 6.
En fait, tant que tu ne chiffres pas le disques, n'importe qui ayant un accès physique à la machine peut passer root. Et ce n'est pas propre à Linux, cela fonctionne avec tout OS.
Une possibilité parmi d'autres. "root" n'est qu'un user id sur un système de fichier. Branche le disque dur de la machine à compromettre sur une machine où tu es root. Monte le système de fichier. Et voilà tu vois tout.
Encore plus simple, boot depuis une clé usb avec un Linux live, monte le système sur le disque dur de la machine. Et voilà tu vois tout.
Bien sûr tu peux en profiter pour altérer un fichier pour avec un accès plus tard, à distance, quand la machine sera retournée dans les mains de son propriétaire.
En bref : chiffrés vos disques dur. Ce n'est même pas compliqué : Debian le propose avec l'installateur de base.
[^] # Re: chiffrement des données
Posté par Vincent Danjean . Évalué à 5. Dernière modification le 13 mai 2023 à 23:31.
Chiffrer les données n'est intéressant que si on est confiant dans l(es) administrateur(s) de la machine (actuel(s) et passé(s)) quand on déchiffre les données. Sinon, s'il y a un keyloguer ou autre truc équivalent, alors c'est tout perdu. Et ça peut être très rapide si les données chiffrées ont déjà été copiées (encore chiffrées) avant (juste le mot de passe intercepté à transmettre en plus).
Si une machine passe dans les mains de quelqu'un de compétent et motivé (une douane par exemple, au hasard), et si la machine contient des données réellement précieuses, il vaut mieux laisser tomber l'ordi. TPM2 (avec secure boot) est censé protéger de cela (si tout est bien et complètement implémenté), mais bon, il faut encore faire confiance au constructeur de matériel (la puce TPM2). Et je ne connais pas l'interaction possible avec Intel® Management Engine (le processeur dans le processeur avec un OS non connu, capable d'intercepter les données des bus…)
Il est par contre facilement possible de bloquer les attaques qui respectent l'intégrité de la machine (pas de démontage, …), ce qui est généralement le cas dans les salles de TP dans l'enseignement par exemple. Il faut alors configurer et protéger le BIOS (accès BIOS avec mot de passe, démarrage forcé sur le média choisi, interdit sur les autres média) et protéger Grub (pas de console sans mot de passe).
[^] # Re: chiffrement des données
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Ah si, on sait ce que c'est cet OS inconnu, et il vient d'un monsieur que Linus connait bien :)
https://en.wikipedia.org/wiki/Intel_Management_Engine#Hardware
[^] # Re: chiffrement des données
Posté par flan (site web personnel) . Évalué à 5.
Le chiffrement est utile, ne serait-ce que dans le cas où le disque a une seconde vie (vol, revente, perte, …).
[^] # Re: chiffrement des données
Posté par steph1978 . Évalué à 8.
Il est difficile d'évaluer les solutions sans définir le modèle de menace.
Ton exemple de salle de TP est intéressant. La "menace" étant l'élève :), il faut s'assurer que le système n'est pas altéré d'un élève à l'autre. Le SecureBoot/TMP est alors tout indiqué. On fait l'hypothèse qu'un élève pourrait faire mumuse avec une clé bootable mais ne va pas aller dessouder l'eprom ou mettre un keylogger (euh…).
Moi je suis plus dans le cas du vol de mon ordinateur portable. Dans ce cas la menace est externe. Et je ne suppose pas que je vais le récupérer le matériel. Je veux juste que mes données soient illisibles quand il sera revendu sur le bon coin.
Si il s'agit de se protéger d'un espionnage étatique alors cela dépasse mes connaissances. Car il faudrait fondre ses puces soit même, utiliser des clés PGP partout, et j'en passe.
Bref, il est important de définir de quoi on veut se protéger.
[^] # Re: chiffrement des données
Posté par gUI (Mastodon) . Évalué à 7.
C'est en effet la base de n'importe quelle conversation.
Exemple : avec un couteau sous la gorge je donne tous mes mots de passes, est-ce pour autant que mettre un mot de passe ne sert à rien ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: chiffrement des données
Posté par ted (site web personnel) . Évalué à 7.
Le XKCD qui va avec
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: chiffrement des données
Posté par Vincent Danjean . Évalué à 4.
Le
SecureBoot/TMP, c'est un SecureBoot temporaire ? ;-)[^] # Re: chiffrement des données
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Touche Mon Poste il a dit le sécure boute
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Mieux qu'il y a 20 ans déjà
Posté par geegeek . Évalué à 1.
Quand j'étais jeune, il suffisait de mettre init 1 comme paramètre, je dirais qu'il y a eu du progrès.
Ça n'existe pas la sécurité out-of-the-box, c'est toujours à toi de le faire.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Vincent Danjean . Évalué à 6.
Tu as essayé de mettre
init=/bin/bashà la ligne de grub [sur un système installé de base] ? Je trouve cela généralement plus pratique que de trouver/utiliser une clé USB bootable.[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Christophe B. (site web personnel) . Évalué à 3.
Et il y a plus longtemps encore …
IL fallait se connecter physiquement sur le port "console", généralement le 1er port serie de la 1ere carte pour effectuer certaines opérations.
Puis le réseau TCP est arrivé :)
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par totof2000 . Évalué à 2. Dernière modification le 15 mai 2023 à 10:14.
Je n'ai pas souvenir de ça sur des machines de type PC/X86 (ou la console par défaut est le couple clavier + écran), mais sur d'autres architectures n'ayant pas forcément de carte graphique installée, c'était effectivement assez courant (serveurs Sun, Hp, Ibm, …). Exemple : un des plus vieux trucs sur lesquels j'ai bossé
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Psychofox (Mastodon) . Évalué à 3.
Il fut un temps où les pc venaient avec des ports séries en standard.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par totof2000 . Évalué à 4.
Le problème n'est pas l'absence ou la présence de port série. Le problème c'est la gestion de ce port série par le firmware/bios pour pouvoir démarrer de bout en bout sur ce port. Sur PC, le port série n'est pas géré au démarrage par le BIOS.Il n'est pas conçu pour que les entrées/sorties au boot soient gérés par une liaison série. Pour pouvoir utiliser le port série sur un PC, il fallait qu'un système soit démarré.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 15 mai 2023 à 17:26.
Oui mais les gestionnaire de boots peuvent rediriger sur le port série. Donc certe tu n'as pas forcément accès aux paramètres du bios/openboot/firmeware uefi, mais tu peux avoir accès au shell grub et au boot du noyau une fois configuré pour.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Christophe B. (site web personnel) . Évalué à 4.
Pour info ce n'était pas des PC/X86 à la même époque : fin des années 80 debut 90, enfin je crois, plein de constructeurs sortaient ce que l'on nommait de la "mini" par opposition à la "micro" informatique type PC et au mainframe IBM, Bull etc …
La plupart se basaient sur des processeurs motorola Z80, M68000 etc …
L'OS était Unix System V et le port console devait ne pas être considéré comme un poste normal, en théorie …
Puis la "micro" est devenu aussi puissante que la "mini" et ces termes ont disparu, IBM a sorti son RS/6000, windows venait de sortir, Amiga et Atari se bagarrait et le basic était le langage populaire de l'époque :)
Enfin d'après mes souvenirs …
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par totof2000 . Évalué à 2.
Je n'ai pas connu toutes ces machines en milieu professionnel.
Le truc le plus vieux que j'ai connu en milieu pro, c'est les 3B2600 AT&T décrits sur cette page wikipedia. C'était du 32 bits, à 8 Mhz environs, avec un vrai unix systemV.
Il me semble que le basic était effectivement, avec l'assembleur, LE langage populaire avant les amiga/atari ST: c'était le langage de prédilection des Amstrad CPC, et toute la série des micro 8 bits qui sont sortis à cette époque et un peu avant. Les Amiga et Atari ST avaient un Basic fourni avec, (Microsoft Basic sur Amiga), cependant, d'autres variantes de Basic plus populaires étaient utilisés (AMOS, GFA Basic, ….) mais il y a eu aussi - au moins pour AMiga - quelques bons compilateurs C ou Pascal, et assembleurs (je connais moins l'offre sur Atari ST), avec la fameuse revue Amiga Dream qui est devenu Dream puis Login qui fourmillait d'exermples de code dans tous ces langages.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Psychofox (Mastodon) . Évalué à 2.
L'amiga, c'est déjà dans le futur par rapport à ce que décrit le commentaire précédent.
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Christophe B. (site web personnel) . Évalué à 3.
L'Amiga et L'Atari ST (oui depuis le temps la paix a été conclue :) )
étaient de super bécane à l'époque pour le prix
Faire la même chose au point de vue Graphisme / son cela coûtait 4 fois le prix d'un amiga pour faire la même chose avec un PC de l'époque qui par défaut se contentait de 16 couleurs et d'un son style "bip"
Et je parle pas de L'AmigaOS, qui apportait une interface graphique ET le multitache des sa sortie en 1984 … on evitera de comparer avec le DOS 3.3 :)
Par contre le basic standard de l'amiga n'était pas top et c'était un temps ou le prix du compilateur C coutait un mois de mon salaire de l'époque …
Alors que maintenant il y a presque trop de langages à apprendre …
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par Vincent Danjean . Évalué à 3.
Mon premier ordi à la maison était un Atari 1040 STE. Raison de mon choix : je voulais faire de la musique (MIDI) et l'Atari avec ce port par défaut (avec Notator puis Notator Logic comme logiciel, concurrent de Cubase). Le vendeur nous avait conseillé cela ou un Mac (ce dernier étant beaucoup plus cher).
Il arrivait avec une interface graphique, une résolution de 640x400 ! (en monochrome). Et le Omicron Basic. Je n'ai jamais acheté de compilateur (les programmes étaient lents) et j'avais été sidéré par la vitesse de l'assembleur quand un magazine en avait fourni un (version précédente d'une version commerciale).
De mon point de vue, Atari a beaucoup tardé avant de passer au 68030 (processeur avec une MMU) avec le Falcon 030 qui a permis un vrai multitâche (et le multitâche coopératif n'a pas été développé/poussé sur les précédents ordis où le système était en ROM). Les PC avaient alors pris leur envol. Mon dernier Atari a été effectivement un Falcon030. C'est aussi là où j'ai appris le sens de "Debian fait sa release quand elle est prête" : j'ai attendu plus d'un an Debian Hamm (2.0) qui devait tourner sur 680x0. J'ai finalement installé une Slack avant que Hamm soit dispo (au moins une vingtaine de disquettes pour la distrib Slack !). Cela avait en outre nécessité une cross-compilation du noyau (il fallait intégrer un patch pour émuler les instructions flottantes non présente dans le Falcon030) faite en semaine sur les ordis de mon lycée de prépa (salle entière en réseau sous Linux !, accès limité à Internet avec le lien RDNIS (pas sûr de l'acronyme) vers le rectorat). C'était le bon temps ;-) (Gropher puis Netscape, slip/plip pour les réseaux locaux, etc.)
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par BAud (site web personnel) . Évalué à 3.
sans doute RNIS plutôt ou Réseau Numérique à Intégration de Services, Numéris de son nom donné par France Telecom
moui, le rêve avec un lien à 2 Mbits/s par campus :p mieux que le modem 33,6 kbits que l'on pouvait avoir chez soi o_O (c'était déjà mieux que le 9600 bauds…)
Gopher ;-) (et Archie pour aller de site FTP en site FTP, WAIS pour le préalable aux sites Web… Heureusement qu'il y avait IRC pour s'échanger des liens !)
Bah, je regrette peu cette époque :D
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par totof2000 . Évalué à 2.
Moi c'était l'autre, un amiga 500, mais plus par opportunité que par réel choix (achat d'occasion).
C'était je pense la différence fondamentale entre les deux machines pour les utilisateurs : l'Amiga était mieux adapté au graphisme assisté par ordinateur, l'Atari ST à la musique. Sinon pour les usages "standards" (jeu, bureautique), je pense que les deux machines se valaient.
Par contre côté musique il me semble que l'Amiga avait 4 canaux (deux gauche, deux droits) mais l'atari ST seulement trois. En terme de rendu sonore, je n'ai jamais pu tenter de distinguer la différence (je n'ai jamais vu/entendu d'Atari tourner, j'avais un amiga à l'époque).
[^] # Re: Mieux qu'il y a 20 ans déjà
Posté par pasBill pasGates . Évalué à 2.
Il ne faut pas utiliser l'imparfait avec l'Amiga, AmigaOS est toujours développé : https://www.hyperion-entertainment.com/index.php/news
;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.