Lazarus 1.8 Release Candidate 1 est sorti

Citation:

---

Envoyé par Jipété

Citation:

---

Envoyé par Pierre GIRARD

Pourquoi pas 64 bits ? t'as encore un PC avec un processeur 32 bits ? ça existe encore ???

---

Salut Pierre,

J'ai trop vu d'embrouilles et de sacs de nœuds obligeant à virer des logiciels 64 pour "redescendre" en 32 et enfin pouvoir faire ce qu'on voulait faire, ça décourage un peu.
Quelque part j'ai un peu l'impression (fausse, sans doute, mais c'est ainsi) qu'un OS 64 n'est pas 64 du début à la fin, et qu'on nous rejoue le plan 32 qui démarre la machine en 16 pour basculer ensuite.
Bref, j'ai le sentiment que s'il y a des problèmes en 32, les problèmes seront multipliés par 2 en multipliant par 2 la largeur des bus...

---

Pour illustrer mon propos, un lien vers une discussion toute fraîche, et nous sommes mi-2017. Ça date de quand, déjà les procs 64 bits ?...

Pour scanner, j'utilise sane (avec xsane) qui est en 64 bits et les drivers sont ceux fournis par YaST (OpenSUSE donc). Et ça marche à merveille sur mes scanners Canon Lide 700F et Epson Perfection 1640SU. J'ai regardé la fonction scanner de Libre Office : Elle est complètement nulle et affligeante de pauvreté. Sane sait tout faire et le fait bien. Xsane propose de très nombreux réglages et de nombreux formats d'enregistrement. Ensuite, j'importe les images scannées dans LO 64 bits et je n'ai aucun problème.

Comme mes 2 scanners donnent des signes de faiblesse, j'ai décidé de les remplacer. Mon choix est : "Canoscan 9000F Mark II". Pourquoi ? parce qu'il existe déjà un driver YaST pour cette imprimante. Je suis donc quasiment certain que ça va marcher. Pareil pour les imprimantes, je choisis des imprimantes pour lesquelles il existe déjà un driver. Du coup, je n'ai jamais de mauvaises surprises.

Quant au prix, "Multifonction Canon Pixma MG6850" = 99,95€ et "Scanner Canoscan 9000F Mark II" = 199,90€. Je n'achète plus de multifonctions depuis que j'en ai mis une à la décharge au cause d'une panne de l'imprimante (alors que le scanner marchait au poil, mais comme d'habitude, la réparation coûte plus cher que l'achat en neuf). Maintenant, si le scanner tombe en panne, je n'ai plus besoin de changer l'imprimante (et réciproquement).

Bref, le problème évoqué n'est pas d'être en 64 bits, mais que sa Pixma MG6850 n'a (apparemment) pas de pilote 64 bit. Maintenant, chacun fait comme il veut, mais pour moi, c'est 100% 64 bit depuis des années, et tout baigne. ;)

Citation:

---

Bref, le problème évoqué n'est pas d'être en 64 bits, mais que sa Pixma MG6850 n'a (apparemment) pas de pilote 64 bit.

---

Soit canon est un menteur soit il a mal cherché ?
https://www.fullinstaller.com/canon-...download-free/
Et pour linux il faut juste penser à installer libpango.

Je ne vois aucun driver Linux dans ton lien, que ce soit en 64 ou en 32 bit.

Citation:

---

Je ne vois aucun driver Linux dans ton lien, que ce soit en 64 ou en 32 bit.

---

Dans la discussion présentée en référence par Jipété:
https://www.developpez.net/forums/d1...s/#post9529529
il est question de W7 64 bits, pas de Linux.
Pour Linux il y-a ça:
https://www.canon.fr/support/consume...nux%20(64-bit)
En général pour les imprimantes multifonctions il n'y a pas de pilote générique pour le scanner et pour certains modèles il faut aussi installer scangear, certains pilotes sont incompatibles avec sane et xsane.
Sinon pour aller jusqu'au bout on peut aussi utiliser vuescan:
https://www.hamrick.com/
Attention: La version demo free est inutilisable, elle colle un watermark sur les images, la version pro c'est l'arme absolue.

Je ne connais pas de version de Scangear pour Linux et Scangear est livré automatiquement avec tous les scanners Canon. De plus, jusqu'à présent, sane me donne gratuitement satisfaction à 100%. J'en suis à mon 5ème scanner/multifonction : HP, Brother, Epson et 2xCanon et j'ai toujours trouvé les drivers qui vont bien avec OpenSUSE (et aucun n'a eu de problème avec xsane). Je ne vois donc pas pourquoi j'irais acheter "vuescan". D'autant que, après test, il me semble beaucoup moins intuitif que xsane.

Citation:

---

Je ne connais pas de version de Scangear pour Linux

---

http://tipsonubuntu.com/2016/08/14/c...-ubuntu-16-04/
https://forum.ubuntu-fr.org/viewtopic.php?id=894611
Et il figure bien par défaut dans les dépôts de ma LM 18.

Citation:

---

Je ne vois donc pas pourquoi j'irais acheter "vuescan".

---

Évoquer une chose n'a jamais été une injonction d'achat.

Faut-il répéter pour la millième fois que je ne suis pas sous UBUNTU, ni sous DEBIAN, que je n'ai pas besoin de quoi que ce soit de plus que sane/xsane sous OpenSUSE car tous les drivers dont j'ai besoin sont présents et que xsane (qui n'est même pas à sa version 1) me permet de faire tout ce que je souhaite faire ?

Ça ne date d'ailleurs pas d'hier, à l'époque ou je suis passé d'un Modem 9600 bauds à Numeris, seul SuSE a reconnu mon matériel (et configuré tout quasi-automatiquement). Ce qui m'a permis de me connecter à Internet sans effort. Impossible avec Mandrake, RedHat, Debian et quelques autres car aucun ne reconnaissait mon contrôleur Numeris/RNIS. Donc, déjà avant 2000, j'étais avec SuSE (payant à l'époque pour la version complète) parce ce que c'était la seule distribution qui reconnaissait tout mon matériel.

En 2007, avec l'achat d'un portable Fujitsu Siemens (et LINUX 64 bit), le même problème s'est posé. Il était d'usine en XP 64 bit, et SuSE a été le seul à reconnaître tous les composants de ce portable. Impossible d'installer RedHat ni Debian, ni je ne sais plus quoi, car aucun ne détectait correctement le lecteur/graveur de DVD interne. J'y ai donc installé SuSE/OpenSUSE car c'était la seule distribution ayant dès le départ les drivers qui vont bien. Même avec les versions "live" de Ubuntu je ne suis arrivé à rien, vu qu'il commençait le boot (le DVD étant reconnu par le Firmware il était possible de booter) puis plantait car il ne trouvait pas le DVD pour continuer le démarrage.

Donc, non, avec OpenSUSE 64 bit, je n'ai besoin de rien. A propos, je fais confiance à OpenSUSE pour la mise à jour de ce qui est installé. Dans mon cas particulier, LibreOffice est en "5.2.5.1". Tant qu'il n'y a pas de mise à jour officielle OpenSUSE, ça restera comme ça, considérant que si l'équipe de développement de la distribution a décidé que c'était la meilleure version pour l'OS qui est installé, elle le serait aussi pour moi. Par contre, sur ma MV VMware Windows XP, je suis à la toute dernière version 5.4 de LibreOffice car ce n'est pas stratégique sur XP.

Salut

Une fois de plus, je ne vais pas faire dans la dentelle, désolé pour le troll-ing. Ce ne sont que des commentaires personnels, visant les arguments, et non pas des attaques envers leurs auteurs.A chacun son point de vue !

Citation:

---

Envoyé par M.Dlb

Sur les Mainframes IBM, effectivement l'héritage du passé fait que les choses restent simples et efficaces, mais il y a aussi des choses très modernes !
En particulier, le nouveau z14 apporte plein de choses intéressantes.

---

Pour simple, je dirai plutôt simpliste, on ne peut pas dire que Cobol soit une chose très moderne, je subis cette infamie depuis 6 ans mais ouf ! je vais bientôt arrêter. Dans Z/OS, on se contente de ce que veut bien donner IBM, i.e. peu de choses. C'est un environnement bien frustrant quand on vient de la micro. Pour rappel de la modernité de Cobol, un programme peut se décomposer en paragraphes, on pourrait imaginer s'en servir comme de procédures, mais non car on ne peut pas définir de variable locale. Un programme ne comporte donc que des variables globales, ce n'est pas hyper moderne... Cela laisse aussi la possibilité de faire plein de beaux bugs sans se forcer. Pas moyen de faire des structures de données (vraiment) évoluées, la seule disponible étant le tableau et encore avec la lourdeur syntaxique bien typique de ce foutu langage. J'aime bien aussi les types "numériques" de cobol, que les cobolistes eux-mêmes parfois ne maîtrisent pas (je le dis pour l'avoir vu).

Les technologies des mainframes ne sont pas toujours simples et une documentation claire n'est pas toujours facile à trouver.

Pour l'efficacité, les mainframes sont des machines de course, soit, mais avec des outils parfois antédiluviens, je ne les connais pas tous loin s'en faut et leur laisse le bénéfice du doute...

Méchanceté de ma part : Il est souvent dit dans ce milieu professionnel que l'on a pas fait mieux que cobol, les ingénieurs IBM me semblent alors d'une incapacité assez indécente et les clients assez peu exigeants surtout en rapport avec le coût de ce type d'environnement, leur propre passé de coboliste les conforte sans doute dans leur point de vue.

Dijkstra, qui n'était pas un manche, avait tout à fait raison à son sujet :

Citation:

---

Envoyé par Dijkstra

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

---

Je vous laisse traduire...

Pour la modernité, c'est assez variable du fait même des "us et traditions" dans ce domaine, par exemple l'UTF-8 a un peu de mal à passer, ce qui se comprend quand on sait qu'on travaille beaucoup avec des fichiers séquentiels en taille fixe.
Pour avoir repris pas mal de code en maintenance, je trouve que la qualité du code est en général assez faible.

Citation:

---

Envoyé par M.Dlb

La grosse nouveauté du z14 sera la capacité de crypter toutes les données à la volée, avec des fonctions hardware, donc avec un coût CPU très faible.
Aujourd'hui le z est connecté avec le reste du monde, à travers les APIs entre autres, et permet de faire du big data... Toutes les technos sont disponibles !!

---

Pour le big data, pas de quoi pavoiser quand on voit les performances de ces machines mais aussi leur coût... Heureusement que le coût CPU sera faible vu que l'utilisation de la CPU est facturée.

Citation:

---

Envoyé par der§en

Mon parcours professionnel qui a suivi sur les Mainframes IBM m'a conforté dans mon optique du "moins c'est mieux"…

---

Pas besoin de passer par ces bestiaux pour revendiquer la parcimonie, le "moins c'est mieux" ne transparaît vraiment pas en cobol où la verbosité est assez incroyable.
Enfin, mon parcours sur les mainframes ne m'a convaincu que d'une chose : en partir le plus vite possible ...

Pour revenir à notre langage préféré:

Citation:

---

Envoyé par Jipété

une 1.8rc4 serait sortie, une rc5 est annoncée : on n'est pas près de voir la 1.8 définitive, on dirait...

---

D'accord avec Jipété, mais l'équipe de développement fait sans doute ce qu'elle peut, gratuitement de surcroît (encore un grand merci à eux).

Ah si on avait des budgets similaires à ceux dépensés dans les mainframes ... quel monde injuste !

Cdlt

Heu, je veux pas dire mais en 1990 sur les mainframe IBM, Je codait déjà en "C" hein, et cobol servait uniquement pour les chaînes de prod à la bourse de Paris…

Quand au Cobol dont tu gardes un mauvais souvenir (moi aussi si l'on se positionne commen un dev) il est le meilleur langage que j'ai utiliser pour produire des impressions papier, sa puissance se dévoile là, c'est bien pour cela que ce dinosaure est toujours bien présent dans la banque et la finance…

Mais pour ma satisfaction personnel, je l'ai fui pour m'amuser avec le "C" et les scripts en Rexx.

Pour l'unicode, je pense pas que cela soit pire que de passer de l'EBCDIC à l'ASCII :mrgreen:

@e-ric : si tu abordes le Mainframe uniquement par le côté développement Cobol, tu passes à côté de beaucoup de choses, et tu ne peux décemment pas porter un avis objectif sur le sujet, qui est beaucoup plus vaste que cela. Il existe d'autres langages disponibles sur l'architecture, le C et le Java en tête, qui permettent de s'affranchir des limitations potentielles du Cobol. Je dis bien "potentielles", car n'ayant jamais écrit une ligne de Cobol (en 10 ans de z/OS... Et oui, il y a plein d'autres facettes dans cette technologie), je ne peux juger de son efficacité.

Concernant le coût et l'exigence des clients, je peux t'assurer que la barre est placée très haut, car c'est un facteur considéré dans chaque décision. Comme le coût est important, si on ne considère que les coûts purs sans prendre en compte la valeur apportée, les clients font preuve d'une exigence très élevée, pour s'assurer que la machine répond bien à leurs besoins.

Concernant le big data, c'était juste pour illustrer que le z sait tout faire, du transactionnel aux big data, en passant par les APIs...

Si ton expérience sur le développement z/OS n'a pas été concluante, peut-être étais-tu mal outillé (environnement de développement, gestionnaire de sources, ...) ou dans des phases de maintenance de code non optimisé ?

C'est quelle version de Lazarus sur z/OS ? :pingoin2:

Citation:

---

Envoyé par der§en

Heu, je veux pas dire mais en 1990 sur les mainframe IBM, Je codait déjà en "C" hein, et cobol servait uniquement pour les chaînes de prod à la bourse de Paris…

---

Oui mais dans les grosses boîtes, les chaînes de prod constitue l'essentiel du travail.

Citation:

---

Envoyé par der§en

Quand au Cobol dont tu gardes un mauvais souvenir (moi aussi si l'on se positionne commen un dev) il est le meilleur langage que j'ai utiliser pour produire des impressions papier, sa puissance se dévoile là, c'est bien pour cela que ce dinosaure est toujours bien présent dans la banque et la finance…

---

Je ne vois pas trop en quoi ... Quand je produis des éditions papier (enfin leur équivalent) là où je travaille, je n'utilise rien d'autre que des instructions basiques que l'on pourrait transcrire aisément en n'importe quel langage, même du Pascal. Je ne vois pas trop la plus-value.

Citation:

---

Envoyé par der§en

Mais pour ma satisfaction personnel, je l'ai fui pour m'amuser avec le "C" et les scripts en Rexx.

---

Je comprends aisément.

Citation:

---

Envoyé par der§en

Pour l'unicode, je pense pas que cela soit pire que de passer de l'EBCDIC à l'ASCII :mrgreen:

---

Petite différence quand même : Ascii et Ebcdic sont des jeux de caractères à 1 octets contrairement à Unicode (je pense surtout à UTF-8, norme de fait sur Internet) ce qui cadre assez mal avec les fichiers séquentiels en taille fixe.

Citation:

---

Envoyé par M.Dlb

@e-ric : si tu abordes le Mainframe uniquement par le côté développement Cobol, tu passes à côté de beaucoup de choses, et tu ne peux décemment pas porter un avis objectif sur le sujet, qui est beaucoup plus vaste que cela. Il existe d'autres langages disponibles sur l'architecture, le C et le Java en tête, qui permettent de s'affranchir des limitations potentielles du Cobol. Je dis bien "potentielles", car n'ayant jamais écrit une ligne de Cobol (en 10 ans de z/OS... Et oui, il y a plein d'autres facettes dans cette technologie), je ne peux juger de son efficacité.

---

Tu as bien de la chance, là où je travaille l'essentiel du boulot de dév. sur ces machines, c'est Cobol et JCL (interface utilisateur en C# mais bon je n'y touche pas). Je fais avec ce que le client me donne.

Citation:

---

Envoyé par M.Dlb

Concernant le coût et l'exigence des clients, je peux t'assurer que la barre est placée très haut, car c'est un facteur considéré dans chaque décision. Comme le coût est important, si on ne considère que les coûts purs sans prendre en compte la valeur apportée, les clients font preuve d'une exigence très élevée, pour s'assurer que la machine répond bien à leurs besoins.

---

Je doute que les entreprises qui n'utilisent pas de mainframes prennent leurs décisions à la légère, ce n'est pas un argument. Il y a surtout un conformisme impressionnant dans ce milieu (un vrai troupeau de moutons). Ce qui m'amuse, c'est qu'ils s'imaginent tous qu'IBM est incontournable. A ma connaissance, Google et quelques autres vivent très bien sans IBM et cela leur réussit plutôt bien. Dire qu'en France, on est pieds et poings liés à IBM, un vrai non sens économique, comme il doit être facile pour la NSA se siphonner des données, et qui pourra vérifier ? vu que tout y est verrouillé ...

Citation:

---

Envoyé par M.Dlb

Concernant le big data, c'était juste pour illustrer que le z sait tout faire, du transactionnel aux big data, en passant par les APIs...

---

A condition de mettre des clients interactifs graphiques en face (genre Windows, Internet...). TSO c'est sympa mais ça commence à dater...

Citation:

---

Envoyé par M.Dlb

Si ton expérience sur le développement z/OS n'a pas été concluante, peut-être étais-tu mal outillé (environnement de développement, gestionnaire de sources, ...) ou dans des phases de maintenance de code non optimisé ?

---

Sans doute, mais mes expériences directes ou indirectes m'ont conforté dans l'idée que je ne dois pas être fait pour ce genre de choses, la philosophie propriétaire (mot encore bien atténué) est étouffante. Actuellement RDZ se met en place mais bon cela reste du cobol avec de l'habillage graphique, ça améliore un peu le confort mais cela ne change pas le fond.

Bon maintenant essayons de revenir à Lazarus...

Cdlt

La force du mainframe, c'est aussi son système de canaux et ces périphériques ultra-performant.

Petit exemple concret, lors de la migration des chaînes de prod IBM vers des DEC derniers cris pour que les sociétés de bourses puissent se dissocier physiquement de la SBF, les même traitement qui prenait 2 heures pour l'ensemble des sociétés de bourses sur un 3090, il fallait 48 heures sur DEC gavé de ram, de disque ultra-wide-scsi II (et III) et à base des processeurs Alpha par société de bourse, la différence se faisait principalement au niveau des temps d'accès et de lecture-écriture sur disques.

Ces tests on eu lieu peu de temps avant que Compaq absorbe DEC (pour situer la période).

Oui, c'est l'époque où DEC a commis l'erreur de vendre son âme au diable. Au lieu continuer à se concentrer sur le scientifique, la recherche qui était son fond de commerce, ils ont décidés de s'attaquer de front à IBM dans le secteur des banques et des assurances. C'est exactement ce qui a causé leur perte : Vente à perte avec des contrat de maintenance inapplicables dans des secteurs dans lesquels les techniciens se sentaient mal à l'aise, voir pas à leur place.

Pendant ce temps là, Sun et HP ont poussés DEC dehors dans les secteurs qui ont fait toute la réputation de la boite. Pire, ils ont virés Ken Olsen (un des fondateurs) et mis dans les sphères dirigeantes des anciens d'IBM. :roll::roll::roll:

Bon, j'étais bien placé pour voir ce qui se passait, vu que c'est à cette époque que j'ai quitté la boite (il y avait de 400 à 500 licenciements tous les 6 mois rien que pour la France). Bon, on ne refait pas le passé, mais j'ai tout de suite compris qu'on allait dans le mur et qu'on avait rien de sérieux à offrir aux banques ou aux assurances.

Pour en revenir à Lazarus et à Pascal, le DEC Pascal était excellent et certainement un des meilleurs Pascal du moment. C'est d'ailleurs sur le Pascal de Digital que j'ai eu mes premières notions de programmation.

Pour en avoir tâté un peu VMS était vraiment bien et les DEC de cette période, des machines passionnantes.

Dans le contexte les disques SCSI etait sans commune mesure avec les disques d'IBM, ils ne jouaient carrément pas dans la même cour…

Pièce jointe 305835

Pièce jointe 305840

Oui, mais pour être juste, avant d'arriver aux disques 3,5", Digital est passé par des monstres comparables à ceux montrés en dessous. J'ai même travaillé dessus pas mal de temps avant de passer au groupe support. ;)

Sinon, on a une petite idée de la date de sortie définitive de la V 1.8 ?