informatique et high-tech (les meilleures news) %) - Page 463

Brunni (./13854) :
on enseigne dans les écoles que c'est tellement mieux UNIX, encore plus de 30 ans après, et on voit ce que ça donne.

Brunni (./13858) :
C'est une simple remarque sur cette architecture stoo

Alors explique-moi quel est le rapport avec la choucroute, en fait je vois pas le rapport entre la qualité d'Unix et un bug dans un programme en dev ?

Folco (./13857) :

Brunni (./13854) :
on enseigne dans les écoles que c'est tellement mieux UNIX

Non mais attends tu comprends rien là Le mec a écrit un bug dans une version de dev d'un programme, quel rapport avec unix ou le libre ? Tu veux essayer de te convaincre que quand on écrit du proprio pour Win ou OS X il n'y a pas de bug dans les versions de dev ?

(cross ^^)

Mais où vois-tu un rapport avec le libre UNIX existait bien avant la GPL, hein

C'est simple:
Linux est libre.
Linux est un UNIX.
Donc tous les UNIX sont libres. Logique, non ?

Yoshi Noir > Justement, on n'est plus dans les années 90, mais 20 ans plus tard…

Folco > Parce que le fonctionnement de Linux et autres dérivés UNIX est totalement basé sur le fonctionnement UNIX… Et qu'en décidant de ne jamais s'éloigner de la philosophie de base (La seule semi-exception à ma connaissance étant Mac OS X… Il me semble que les .pkg contiennent malgré tout des scripts shell…), ça a justement conduit à l'erreur mentionnée au dessus.

Les .pkg peuvent contenir des scripts shell, en effet.
OS X est vraiment bicéphale : la couche Cocoa est presque complètement déconnectée d'UNIX et de sa philosophie des années 70.

D'un autre côté, il s'agissait ici d'un script perso de développement. pas d'un package de prod dans la version stable d'une distro, où les choses ne sont pas faites pareil.

Bin ça ne change rien au problème : sous Windows, t'es bien mieux protégé contre ce genre de conneries

Peut-être. Question de stratégie. Je préfère que mon système s'efface si je lui demande, plutôt que d'avoir qu'un bout de droits sur un bout du système. ^^

flanker (./13855) :
J'ai du mal à y croire Ce n'est pas parce que tu es admin que tu peux effacer les fichiers système. Sans compter qu'il y a également toute une liste de dossiers et de fichiers protégés qui seront restaurés de façon transparente s'ils sont modifiés.

(Si tu es admin, tu peux passer System ou exécuter un service, donc tu peux effacer les fichiers systèmes, même protégés ; cela dit, autant que je me souvienne du screen posté - flemme de revenir à la page précédente pour un troll aussi gros, ça fait un rm -Rf sur /usr/ donc pas sur les fichiers systèmes, plutôt dans l'équivalent de \Program Files\).
Personnellement, je n'ai pas de préférence Win/Linux. Il y a des choses que je trouve vraiment intéressantes et bien pensées dans les deux mondes, et des choses franchement pourries dans les deux aussi (putain, mais pourquoi on ne peut pas monter un lecteur réseau dans une arborescence NTFS ?! et bordel, mais pourquoi est-ce ci chiant d'utiliser les ACL pour une gestion fine des droits d'accès sous Linux/Unix ?!). Ce n'est pas une question de monde proprio/libre (pour le coup, le bug de l'application aurait aussi foutu la merde sur un Solaris ou un HP-UX, et c'est franchement loin d'être libre ), mais une question à la fois de logique du produit, et d'histoire des systèmes.

GoldenCrystal (./13859) :
Mais sous Windows on n'utilise (= ne devrait jamais utiliser !) pas des script shell merdiques pour faire des installeur.

Huh ? T'as déjà vu un windows dans la vraie vie ?
Le jour où tu me montreras une production avec des windows sans scripts merdiques pour faire du déploiement, je fais un post à la gloire de Bill Gates et Steve Jobs réunis.

Et sinon, en parlant de fonctionnement de windows, si tu travailles avec le compte admin (le vrai, celui appelé System), windows ne fait aucune difficulté à effacer des fichiers systèmes. Encore heureux d'ailleurs. Mais de toutes façons comme l'a fait remarquer Nil, il n'y a aucun rapport avec la choucroute ^^

spectras (./13869) :

GoldenCrystal (./13859) :
Mais sous Windows on n'utilise (= ne devrait jamais utiliser !) pas des script shell merdiques pour faire des installeur.

Huh ? T'as déjà vu un windows dans la vraie vie ? Le jour où tu me montreras une production avec des windows sans scripts merdiques pour faire du déploiement, je fais un post à la gloire de Bill Gates et Steve Jobs réunis.

(Et, en passant, déployer une application dans une infrastructure mixte clients légers/postes de travail virtualisés/terminal server/clients lourds dans un domaine, c'est vraiment, mais alors vraiment super chiant... ce qui ne veut pas dire que ça soit plus simple sous Unix/Linux, mais dans les deux cas on passe par des scripts pourris en priant pour qu'il n'y en ait pas un qui ait la mauvaise idée de redémarrer son poste pendant le démarrage de sa session... - cela dit, MS a quand même graaaandement facilité les choses avec la généralisation des paquets MSI).

Allez, un peu de lecture, pour ceux qui ne le connaissent pas déjà : http://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook (le bouquin est téléchargeable en PDF)

Unix aficionados accept occasional file deletion as normal. For example, consider following excerpt from the comp.unix.questions FAQ:

6) How do I "undelete" a file?
Someday, you are going to accidentally type something like:
% rm * .foo
and find you just deleted "*" instead of "*.foo". Consider it a rite of passage. Of course, any decent systems administrator should be doing regular backups. Check with your sysadmin to see if a recent backup copy of your file is available.
"A rite of passage"? In no other industry could a manufacturer take such a cavalier attitude toward a faulty product. "But your honor, the exploding gas tank was just a rite of passage."

Le bouquin date de 1994, et c'est effarant à quel point il est encore d'actualité pour pas mal de trucs
J'en recommande la lecture si vous avez un peu de temps et que vous voulez rigoler, que vous soyez pro ou anti-UNIX

Nil (./13870) :

spectras (./13869) :

GoldenCrystal (./13859) :
Mais sous Windows on n'utilise (= ne devrait jamais utiliser !) pas des script shell merdiques pour faire des installeur.

Huh ? T'as déjà vu un windows dans la vraie vie ? Le jour où tu me montreras une production avec des windows sans scripts merdiques pour faire du déploiement, je fais un post à la gloire de Bill Gates et Steve Jobs réunis.

(Et, en passant, déployer une application dans une infrastructure mixte clients légers/postes de travail virtualisés/terminal server/clients lourds dans un domaine, c'est vraiment, mais alors vraiment super chiant... ce qui ne veut pas dire que ça soit plus simple sous Unix/Linux, mais dans les deux cas on passe par des scripts pourris en priant pour qu'il n'y en ait pas un qui ait la mauvaise idée de redémarrer son poste pendant le démarrage de sa session... - cela dit, MS a quand même graaaandement facilité les choses avec la généralisation des paquets MSI).

Mais vous confondez tout là T_T (Nil & spectras)
Je parle d'un installeur oui, vous savez le logiciel (ou le paquet MSI) qui installe un logiciel sur Windows. Vous vous parlez de script de déploiement qui lancent des installations (donc des installeurs). Y'a aucun rapport… (Enfin si, le rapport c'est que l'un est un installeur et que l'autre les utilise (ou pas))

Bref, merci d'arrêter de me faire dire ce que je n'ai pas dit.

Je sais bien que les scripts sont utiles (sauf quand on peut s'en passer ! Car il y a quand même assez souvent utilisation de script là où une solution alternative propre existe hein…) pour déployer des logiciels ou certaines mises à jour, oui. Mais ça n'a rien à voir avec par exemple l'installeur de Blender ou de Paint.NET. (Je ne parle volontairement pas de Office ou de Visual Studio car ce sont des installeurs beaucoup plus (trop ?) complexes, découpés en plusieurs paquets, mais le concept reste le même )
Si ton installeur (MSI/NSI/etc…) a besoin d'exécuter un script shell, alors c'est que la solution que tu utilises pour développer ton paquet d'installation est mauvaise, ou bien que tu t'y prends comme un manche. (MSI a des lacunes par exemple, mais il est extensible, donc sauf grosse contre-indication, il devrait toujours être utilisé… Car justement, ça simplifierait le boulot de déploiement)

GoldenCrystal (./13872) :
Si ton installeur (MSI/NSI/etc…) a besoin d'exécuter un script shell, alors c'est que la solution que tu utilises pour développer ton paquet d'installation est mauvaise, ou bien que tu t'y prends comme un manche. (MSI a des lacunes par exemple, mais il est extensible, donc sauf grosse contre-indication, il devrait toujours être utilisé… Car justement, ça simplifierait le boulot de déploiement)

Là, je suis d'accord avec toi ^^

Cela dit, les installeurs devraient prendre en charge par défaut le déploiement. C'est une installation comme une autre aujourd'hui... et MS a réussi, avec les paquets MSI, à bien dégrossir un système qui devenait vraiment critique... cela dit, ce qui est amusant, c'est que Windows, sur beaucoup de niveaux, était très en retard par rapport à Linux/Unix. Mais le retard est en train d'être comblé à une vitesse faramineuse - disons que ça a du mal à aller aussi vite de l'autre côté
Typiquement, on peut à présent faire l'équivalent du X over SSH pour des applications Windows depuis W2008 ; on peut déployer des paquets (moyennant quelques bricolages cependant) pour des installations réseau *propres*. De l'autre côté, X over SSH n'a pas évolué depuis des années. Et les distributions Linux, en se focalisant sur le retard qu'elles avaient dans leurs relations avec le grand public, ont oublié le monde des entreprises (en dehors des solutions serveur ; mais les solutions avec clients Unix/Linux sont particulièrement mauvaises et ne proposent rien de plus qu'il y a 10 ans - ah, si, on est passé de yp+NIS à LDAP \o/).
Bon, après, le problème de Microsoft (mais c'est leur stratégie d'entreprise) est qu'ils récupèrent les idées d'ailleurs, les transposent à leur sauce et cassent les compatibilités avec l'existant (rectification : ils permettent la compatibilité avec l'existant à l'aide de solutions coûteuses et complexes à mettre en place / devoir investir dans ILM-MIIS pour assurer une compatibilité unicodePassword/userPassword, c'est quand même le comble du concombre dans l'anus).

Nil (./13873) :
le comble du concombre dans l'anus

Il dit qu'il voit pas le problème

Petit coquinou

./13873> plus que les systèmes, ce sont les besoins qui évoluent en fait.
Par exemple, il n'y a plus vraiment de cas d'usage à un affichage déporté au sens classique sur de l'Unix, et de moins en moins sur du windows, ce qui a fait cesser toute innovation dans ce sens. Les cas d'usage de type prise de main distante n'ont jamais vraiment existé sur Unix et tendent à disparaître sur Windows, tandis que les usages de type virtualisation du poste de travail ont été industrialisées à grande échelle par des éditeurs tiers, rendant caduques les outils proposés par X comme par windows.

Mais il n'y a plus vraiment de débats en fait, chaque OS a pris une part des cas d'usages, et tout changement serait extrêmement long, à cause de l'inertie des compétences des opérateurs. En gros...
=> les serveurs d'infra, c'est du Linux
=> l'outillage de messagerie et bureautique, c'est du windows pour le frontend et du linux pour le backend (quand il y en a un)
=> tout ce qui est web c'est du Linux
=> les gros progiciels, c'est du Unix
=> les autres progiciels, c'est du Linux ou du Windows selon l'éditeur (50/50 à peu près)
=> les bases de données, généralement c'est le même OS que l'appli qui l'utilise. Sauf s'il y a besoin de performances, auquel cas il n'y a pas vraiment le choix, c'est forcément du Unix.
=> les systèmes transactionnels lourds, c'est du Z. Un bon vieux sysplex des familles, on n'a toujours rien fait de mieux pour ça.

Du coup chaque système a l'essentiel des efforts dirigés vers ses cas d'usages, et il y a plus un phénomène de spécialisation qu'une vraie concurrence. Sauf peut-être pour Unix, qui se fait bouffer progressivement par le couple Linux/Windows, mais pour des raisons hardware, pas à cause de l'OS.

Kochise (./13854) :
Pas forcément mieux protégé, mais d'inclure les espaces dans les chemins oblige à les encapsuler dans des doubles quotes si c'est le cas, sinon la fonction ne s'execute tout simplement pas.

tu veux tester un del /Y C:\WINDOWS\SYSTEM32 \trucalacon ?

spectras (./13876) :
mais pour des raisons hardware, pas à cause de l'OS.

Ouais, enfin, pas que... Solaris et HP-UX sont quand même bien chants à utiliser ; pour avoir une console qui soit vraiment efficace, il faut passer plusieurs heures à se refaire des alias qui sont là par défaut depuis des décennies sur les systèmes Linux). Bon, faut aussi ajouter que quand il n'y a pas de sortie vidéo mais une unique sortie console, tu as parfois envie de te tirer une balle dans la tête (surtout avec un clavier HP-UX... combien de fois ai-je verrouillé des comptes système en tapant un mauvais mot de passe parce que la touche majuscule n'est pas à la place habituelle, et qu'il y a 3 touches "majuscule" différentes, avec un usage différent ).
Puis ce qui les tue aussi, c'est qu'un Solaris à mettre à jour, c'est l'enfer et ça coûte. Une RH, pour prendre une distrib payante, ça coûte déjà moins, et en plus tu as moins d'ennuis au moment de la migration qu'avec une solution propriétaire... c'est un comble, quand même...

Nil (./13878) :

spectras (./13876) :
mais pour des raisons hardware, pas à cause de l'OS.

Ouais, enfin, pas que... Solaris et HP-UX sont quand même bien chants à utiliser ; pour avoir une console qui soit vraiment efficace, il faut passer plusieurs heures à se refaire des alias qui sont là par défaut depuis des décennies sur les systèmes Linux). Bon, faut aussi ajouter que quand il n'y a pas de sortie vidéo mais une unique sortie console, tu as parfois envie de te tirer une balle dans la tête (surtout avec un clavier HP-UX... combien de fois ai-je verrouillé des comptes système en tapant un mauvais mot de passe parce que la touche majuscule n'est pas à la place habituelle, et qu'il y a 3 touches "majuscule" différentes, avec un usage différent ).
Puis ce qui les tue aussi, c'est qu'un Solaris à mettre à jour, c'est l'enfer et ça coûte. Une RH, pour prendre une distrib payante, ça coûte déjà moins, et en plus tu as moins d'ennuis au moment de la migration qu'avec une solution propriétaire... c'est un comble, quand même...

Je confirme, dans mon ancien job, les serveurs SUN et HP, on y accédait par un PC + Putty (ou équivalent)...

./13878> tout ce que tu dis est vrai, mais ce n'est pas ça la raison qui fait perdre du terrain aux Unix.
Les Unix sont encore là simplement parce qu'ils n'ont pas de remplaçant. C'est une simple question de puissance permise par le matériel. Sauf que l'architecture x86 augmente en performances plus rapidement, ce qui rend progressivement de plus en plus d'applications éligibles pour une migration vers Linux.

Le critère principal est juste celui là : les applications qui sont aujourd'hui sous Unix n'y sont que pour deux raisons :
=> soit ils étaient là historiquement et migrer serait trop cher
=> soit on ne peut pas les mettre ailleurs, parce que le x86 c'est pas ça en perfs.

Les autres ont *déjà* été migrées vers du linux ou de windows depuis 5 à 10 ans. Précisément à cause des raisons que tu cites

(pour info, les architectures matérielles unix comme sparc ou parisc par exemple, sont abandonnées progressivement pour les serveurs/machines unix correspondantes, le choix de remplacement, c'est soit de l'IA64 -Itanium 1 ou 2-, soit du Xeon, made by intel, sachant que l'Itanium qui était initialement prévu pour être la suite logique des cpu RISC s'appuie désormais sur un tronc commun avec les Xeons, plutôt orientés CISC ...)

http://blog.slate.fr/globule-et-telescope/2011/06/14/le-jour-ou-des-hackers-pirateront-le-reseau-electrique/

Je suis surpris qu'ils aient poussé le test jusqu'à détruire délibérément du matériel, montrer qu'il pouvait être commandé était suffisant... ou alors y'avait quelqu'un de haut placé qui n'était pas convaincu de la gravité du problème, et "on" a voulu lui faire une démonstration convaincante

EDIT : bizarre, l'article laisse penser que c'est une vidéo de 2007 qui n'a été rendue publique que maintenant, mais sur YouTube on trouve des commentaires datant d'il y a plusieurs années...

./13881> Itanium est une technologie morte. Sur le marché, il ne reste guère plus que IBM de toutes façons dans le monde Unix.

- HP a misé sur le mauvais cheval et ils s'en mordent les doigts, et continueront de s'en mordre les doigts jusqu'à ce qu'il ne reste que le moignon du poignet sanguinolent. Mais plus personne d'à peu près sain d'esprit n'achète d'Integrity à moins d'y être obligé - ça arrive, les commerciaux de HP font des réduc jusqu'à -90% et là les achats peuvent t'imposer du HP du coup... surtout si ça arrive au moment d'une négo de contrat cadre et que t'as une ou deux XP24k qui traînent.

- Pour le sparc, c'est une question intéressante, c'était presque mort, mais le rachat par Oracle semble avoir changé la donne : contre toute attente ils n'ont pas juste tué le truc. Il est quand même peu probable qu'il regagne du terrain aujourd'hui, en revanche il est tout à fait possible d'en voir dans des appliances, comme de l'exadata. Cela dit, c'est plus du sursis qu'une vraie survie.


Sinon niveau techno, l'Itanium c'est pas du risc, c'est de l'epic, et c'est une architecture qui est tellement tordue et complexe dans sa tête que même Intel n'a jamais réussi à faire un compilateur capable de produire des binaires vaguement optimisés. Mais la raison pour laquelle Itanium a capoté c'est même pas ça, c'est juste que ça devait remplacer l'architecture IA32, mais que l'AMD64 a coiffé l'itanium au poteau du 64 bits en permettant une migration progressive grâce à sa compatibilité avec l'IA32.

Le plus drôle dans le petit cinéma entre Intel et HP, c'est que quand HP a choisi Intel, Intel savait déjà que l'Itanium c'était raté. Ca remonte grosso modo à 2005 l'époque où Intel a renoncé à l'Itanium pour remettre l'accent sur les puces Xeon, le tournant c'est quand Intel a sorti le premier Xeon dual core et a backporté la techno sur Itanium après. Depuis il y a de moins en moins d'efforts, et on attend l'annonce de l'arrêt définitif de l'itanium... très bientôt d'ailleurs, puisque l'info devrait être officialisée lors du procès de HP à Oracle sur ce sujet précis.


Enfin bref, de toutes façons Itanium ça rentre dans la catégorie Unix, et plus précisément Unix sur le déclin. Pour le reste, c'est ce que je disais au dessus, tu mets une appli sur Unix quand 1) elle y est déjà et tu veux pas la migrer, ou 2) t'as besoin de hardware avec une grosse paire bien velue, chose que les archis x86/open ne sauront jamais faire.
Dans tous les autres cas, tu colles une rhel6 ou un win2k8dc dans une VM, et roule.

nota : dans ce contexte, quand je parle d'archi open, je parle du matos, donc ça englobe aussi bien linux que windows

</pavé>
J'ai l'impression de bosser le dimanche, c'est malin...

spectras (./13880) :
Les Unix sont encore là simplement parce qu'ils n'ont pas de remplaçant. C'est une simple question de puissance permise par le matériel. Sauf que l'architecture x86 augmente en performances plus rapidement, ce qui rend progressivement de plus en plus d'applications éligibles pour une migration vers Linux.

Oui, enfin, à présent on trouve des Linux pour quasi toutes les archis sur lesquelles on fait tourner un Unix (en tout cas pour les deux que j'ai cité avant, les Solaris et les HP-UX sur lesquels j'ai bossé... le Solaris, je ne sais plus ce que c'était, pour l'HP-UX, c'était un PA-RISC). D'ailleurs, toutes ces machines ont été reconverties en serveur de test ou en serveur non critique (DNS de secours...) sous une Debian, une fois les périodes de garantie passées.

C'est dingue les gens qui aiment faire dire ce qu'on n'a pas dit, je parle de "suite logique des CPU RISC", je n'ai pas parlé "de nouveau CPU RISC" et ce que dit Nil est tout à fait vérifiable : les serveurs UNIX ont des remplaçants vu qu'ils sont progressivement évincés pour être relégués à des tâches secondaires...

./13885> Oui, celles ci sont dans la catégorie de celles qui sont éligibles pour la migration, la raison pour laquelle les Unix perdent du terrain. Mais là encore c'est pas une question d'OS. D'ailleurs même si théoriquement Linux est supporté sur pSeries, j'en ai jamais vu sauf ptet une fois pour un poc, et c'est pas plus mal parce que ça serait quand même particulièrement con (sauf temporairement pour faciliter une migration).

En fait ton exemple illustre très bien mon propos :

spectras (./13883) :
tu mets une appli sur Unix quand 1) elle y est déjà et tu veux pas la migrer, ou 2) t'as besoin de hardware avec une grosse paire bien velue, chose que les archis x86/open ne sauront jamais faire.Dans tous les autres cas, tu colles une rhel6 ou un win2k8dc dans une VM, et roule.

Le point clé étant que grace à l'évolution de l'archi open, le "tous les autres cas" fait une proportion de plus en plus importante, ce qui permet les migrations.

Maintenant, le domaine où les Unix n'ont pas de remplaçant, c'est le cas n°2. Même les gros 2U x86, type R810 avec une conf genre 32 coeurs, 512Go de ram, ça reste de la machine de tapette à côté d'un pseries. Je ne parle pas de 2 serveurs webs et une base LDAP là hein, je parle plutôt de progiciels type Gold, d'une base qui te tire plusieurs centaines de milliers de transactions par minute, d'un esb central interconnectant plusieurs centaines d'applis, ou encore de l'appli décisionnelle qui génère un cube olap.


./13886> si je devais nommer un prédécesseur à l'EPIC, ça serait plus le VLIW. Il n'y a pas vraiment de points communs entre EPIC et RISC. Sauf si tu parlais de prédecesseur historique et non technique, auquel cas je suis d'accord...mais uniquement chez HP. Parce que Itanium mourra bien avant le Power, et le Power c'est du... RISC, gagné !
Mais bon quoiqu'il en soit, l'échec d'Itanium ne vient pas de son architecture, juste du fait qu'il n'était pas compatible avec l'existant.

J’ai pu constater ce matin, lors d’un reboot, que les nouveaux panneaux publicitaires vidéo dans le métro parisien tournent sous UNIX ou Linux (celui avec des « [ OK ] » en face de chaque truc bien démarré, je crois).

http://www.gizmodo.fr/2011/06/15/les-hackers-ont-facilement-pirate-la-banque-citigroup.html Ils sont ensuite passés d’un compte à l’autre tout simplement en modifiant une partie du texte de la barre d’adresse du navigateur.

WTF???

bin en changeant le numéro de client qui était lu dans un $_GET[], classique

(ouais les panneaux sont sous linux, y'avait déja eu une belle image )