7410

Ce n'est que partiellement une bonne nouvelle... je trouve la syntaxe de qmake, que j'utilise depuis des années au boulot, nettement plus agréable que celle de CMake, pour lequel j'ai très récemment eu à modifier des CMakeLists.
Maintenant, j'ai à peu près fini par retenir les vilains "CMAKE_C_COMPILER" et "CMAKE_CXX_COMPILER", certes plus descriptifs, mais tellement moins intuitifs que CC et CXX (QMAKE_CC et QMAKE_CXX, dans le cas de qmake) utilisés par les autres.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7411

J'ai utilisé Qmake à la marche, un peu plus CMake. Si il y a une couche de moins over Make, c'est toujours ça. Je trouve que les surcouches simplificatrices deviennent vite aussi bordéliques que ce qu'elles sont sensées simplifier.

(puis bon, dans Qt Creator, t'as l'auto-completion pour Cmake, donc les commandes chelous ça passe embarrassed)

7412

Ils ont aussi posté une entrée de blog, avec déjà pas mal de commentaires:
Deprecation of Qbs - Qt BlogQt BlogThe Qt Company has been supporting three different build systems for Qt programs. For Qt users, qmake is currently the most widely used build system. CMake is a clear second and growing in popularity. The third place is Qbs, with significantly smaller adoption. When asked about their preferences, most of our customers said they plan …
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7413

https://bodhi.fedoraproject.org/updates/FEDORA-2018-7ea6e0dfb5
enhancement update in Fedora 29 for freetype
This update enables ClearType algorithm in freetype as a result of Microsoft joining OIN.

Les brevets de Microsoft ne sont plus un problème pour Fedora depuis:
https://www.generation-nt.com/microsoft-oin-brevet-linux-open-source-actualite-1958245.html
top

Du coup, ça donne un rendu meilleur des polices, avec le subpixel antialiasing. (Le paquetage freetype-freeworld de RPM Fusion n'est plus nécessaire et ne sera plus mis à jour, la mise à jour de freetype le supprimera automatiquement (tag RPM Obsoletes).)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7414

On dit merci Satya ?
avatar
Attention, nouvelle signature #eeek#
https://mastodon.ti-fr.com/@redangel

7415

Ca veut dire qu'il y aura enfin un beau Consolas pour Linux ? Bien ! smile

7416

C'est vrai que ClearType est quelque chose de vraiment bon, pas vraiment comparable à de que freetype offrait, même si en hinting "léger" et les fontes kivonbien c'était déjà très bon smile
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

7417

Attention, le "ClearType" qui est activé là est le mode d'antialiasing subpixel déjà proposé par FreeType, mais auparavant désactivé à cause du brevet ClearType de Microsoft. Ça ne veut pas dire que c'est l'implémentation de Microsoft qui est utilisée.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7418

Vu dans https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.6_release_notes/#chap-Red_Hat_Enterprise_Linux-7.6_Release_Notes-Deprecated_Functionality grâce à https://www.distrowatch.com/dwres.php?resource=showheadline&story=7068 : sur RHEL 7.6, entre autres, sendmail, btrfs, tcp_wrappers, la commands `cpuid`, KDE sont deprecated.
Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
A future major release of Red Hat Enterprise Linux will no longer support using KDE instead of the default GNOME desktop environment.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7419

Fais gaffe à ce que tu postes : après le coup de la semaine dernière, Kevin va nous faire une crise cardiaque là...
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7420

btrfs il est deprecated avant d'ếtre stable? grin

7421

Je suis déjà au courant. (Ça a été discuté sur #fedora-kde.) Je n'utilise pas RHEL, et j'utilise CentOS seulement sur le VPS de CalcForge, donc franchement, je m'en fiche pas mal qu'ils suppriment Plasma. (Et puis, l'infatigable Rex Dieter est tout content qu'il pourra s'occuper aussi de Plasma dans EPEL. smile)

Je signale aussi que ces fonctionnalités ne seront pas supprimées dans RHEL 7.x, mais seulement dans la prochaine release majeure (c'est-à-dire RHEL 8, à moins d'un gros coup marketing qui change le système de numéros de version).

squalyl (./7420) :
btrfs il est deprecated avant d'être stable? grin
Ils ont perdu l'espoir qu'il sera stable un jour. grin Et contrairement à KDE Plasma, Btrfs est déjà déprécié depuis RHEL 7.4.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7422

"perdu l'espoir qu'il sera stable un jour" est la partie charitable, bien que vraie, de l'explication smile
Il y a aussi qu'ils veulent monétiser le rachat de Stratis... non seulement à court terme - rentrer dans les frais de l'acquisition et la poursuite du développement pendant quelques temps - mais à long terme: vendor lock-in sur une solution qui n'est actuellement officiellement supportée, à ma connaissance, nulle part ailleurs (quelles que puissent être ses qualités, dont le langage d'implémentation plus sécurisé). Surtout maintenant que Big Blue les a rachetés... Big Blue, le vendor lock-in, ils connaissent bien ça, même si ça fonctionne de moins en moins.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7423

Oh redhat n’en n’est pas à ses débuts:

Gcc 2.96
Des histoires de diffusion des sources du kernel sans historique de smodifications
Pulse audio
PolicyKit
consoleKit
SystemD

Et plein d’autre merdes du meme genre.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7424

Autant dire qu'ils vont bien s'entendre avec IBM ^^
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7425

Qu'un certain nombre de technos soient issues de Redhat est normal: étant une des entreprises qui vendent du support associé à Linux, et la principale d'entre elles, ils ont des sous pour employer des gens à travailler sur des technos, donc c'est plus facile d'avancer que pour des gens qui travaillent exclusivement sur leur temps libre, comme c'est trop fréquent dans le monde du logiciel ouvert.

* EGCS était une évolution technique indispensable sur la base de code GCC très ancienne. Sans elle, GCC aurait été plus mal en point face à l'arrivée de Clang, infrastructure bien plus moderne et qui a précipité l'ajout de la capacité de gérer des plugins (avec une API au moins aussi instable que celle de LLVM/Clang) dans GCC, ce que RMS a bloqué pendant un peu trop longtemps de peur des plugins propriétaires. J'admets ne pas connaître l'histoire d'EGCS dans tous ses détails, mais j'ai du mal à me convaincre qu'il y ait eu une volonté ouverte de vendor lock-in sur ce sujet... et puis le résultat à long terme est positif pour tous. Le fork EGCS est devenu le nouveau GCC, l'ancien a disparu.
* la diffusion des sources du kernel sans historique, là, en revanche, difficile de ne pas voir du vendor lock-in. Même si c'était pour (tenter d') emmerder en particulier Oracle, autre spécialiste de vendor lock-in, bien pire que Redhat, et même si utiliser le kernel de Redhat, à défaut d'être une garantie de sécurité ( ), est surtout une garantie d'obsolescence. PaX/grsecurity fournissait à tous, et fournit toujours à ses clients, l'historique des modifs.
* PA a des avantages clairs par rapport à ALSA dans certains use cases... quand il veut bien fonctionner, j'en ai encore fait les frais récemment. Il s'est répandu des années trop tôt dans les distros, mais d'un autre côté, s'il ne l'avait pas été, les bugs n'auraient pas été trouvés et - parfois - corrigés. Mais du vendor lock-in sur PA ?
* PolicyKit et PackageKit avaient une partie standardisation d'opérations entre distros, ce qui est clairement une bonne chose. J'ai utilisé PackageKit programmatiquement au boulot. Ils se sont répandus à pas mal de distros.
* CK visait à améliorer certains use cases lui aussi, avec également un effet de standardisation d'infrastructure. Là aussi, il s'est répandu à pas mal de distros.
* systemd, en partie le successeur de PolicyKit et CK, standardise beaucoup de choses entre distros, et a des avantages fonctionnels clairs par rapport à ce qu'il vise en particulier à remplacer: le vieux sysvinit, ses spécificités et sa duplication de travail dans chaque distro. Certaines capacités built-in de systemd nécessitent des contournements bizarres avec sysvinit. Ce n'est pas du tout pour rien que systemd s'est ainsi répandu sur la grande majorité des distros Linux, y compris Debian et dérivées (sauf les idiots de Devuan, qui ont gaspillé une énergie considérable à forker, et sont maintenant obligés d'aider Debian pour à la fois se faciliter la vie et aider les utilisateurs, cf. un article récent de LWN...). Malgré ses failles dangereuses répétées, techniquement, systemd est une chose positive pour l'écosystème Linux, en le rapprochant du modèle Windows et MacOS X: une façon standard (de fait) de réaliser la gestion des services.

Bref... à part la diffusion des sources du kernel sans historique, je ne vois pas trop de vendor lock-in dans ta liste, Godzil smile
Et même à supposer qu'il y ait réellement eu volonté de le faire sur tous ces points... le moins qu'on puisse dire, c'est que ça a totalement raté, puisque les autres distros ont suivi, et pas seulement parce que "oh ben Redhat le fait, alors ça va se répandre et il faut qu'on fasse pareil". Il y avait aussi des raisons techniques positives.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7426

Lionel Debroux (./7425) :
PaX/grsecurity fournissait à tous, et fournit toujours à ses clients, l'historique des modifs.
Là, ce n'est vraiment pas un bon exemple, l'équipe qui contraint ses clients à abandonner, à travers un contrat, leurs droits sous la GPL. vtff
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7427

A ma connaissance, les clients d'Open Source Security, Inc. peuvent redistribuer ce qui leur est fourni... c'est juste qu'ils ne recevront plus de mises à jour futures smile
Et comme la valeur de PaX/grsecurity est immense, venant de sa capacité à éliminer des classes d'attaques qui sont toujours toutes présentes dans mainline, et le resteront à cause de Linus et des autres, les clients qui ont accès aux patches PaX & grsecurity ne s'amusent pas à diffuser la seule, et puissante, solution permettant de rendre moins pas sûr le kernel Linux monolithique.
Fuchsia et d'autres utilisent autre chose que le kernel Linux, ce n'est pas pour rien. Bien sûr, la licence moins contaminante est une des raisons de cet état de fait, mais un autre point très important est la sécurité.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7428

Cette restriction est clairement incompatible avec la GPL, je ne comprends absolument pas pourquoi tu la défends.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7429

Je défends davantage la solution technique sans équivalent que la façon de faire. J'utilisais grsecurity tant qu'il était dispo publiquement, et même jusqu'à la fin de la durée de vie du portage non officiel de minipli, c'est à dire l'apparition de KPTI, trop difficile à remixer avec KERNEXEC et MEMORY_UDEREF. Je contribuais quelques sous à l'aventure, et ça m'embête de ne plus avoir accès à grsecurity.

Mais je comprends bien pourquoi ils ont changé de façon de faire, dans le but de pouvoir faire des choses plus utiles, et mieux servir ceux des clients qui font l'effort de s'informer sur la solution technique plutôt que de croire les bêtises de Linus et les autres. Continuer à fournir gratuitement leur travail, et devoir en sus corriger les bêtises de KSPP/mainline qui interféraient avec leur travail, leur était devenu une charge intolérable pour un projet pour lequel ils n'étaient qu'à peine payés: comme la plupart des développeurs de logiciel ouvert, pendant 16 ans qu'ils fournissaient gratuitement leur travail, ils ne récoltaient pas du tout assez d'argent pour y passer le temps qu'ils auraient voulu. Leur nouvelle façon de faire leur a apparemment apporté assez d'argent pour pouvoir travailler davantage sur PaX/grsecurity, et augmenter encore l'écart de sécurité entre mainline et PaX/grsecurity, cf. le récent ajout de Respectre.
Moi aussi, si j'avais été à leur place, j'aurais voulu changer quelque chose. Etait-il envisageable d'utiliser une autre approche très différente de la leur (hormis le fait d'arrêter le travail, évidemment) ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7430

Leur approche est un foutage de gueule envers les développeurs du noyau qui ont choisi de placer leur travail sous une licence copyleft. Le droit des utilisateurs de redistribuer les versions, modifiées ou non, est un droit fondamental apporté par la GPL et les connards de PaX/grsecurity sont en train de chier là dessus. vtff
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7431

Tu ne réponds pas à la question…
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7432

Lionel, que tu critiques la manière peu utilisable de laquelle Red Hat diffuse les sources du noyau de RHEL, c'est absolument justifié, mais que tu le fasses en louant dans la phrase d'après une entreprise qui fait pire, c'est le comble de la mauvaise foi!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7433

(-de laquelle +avec laquelle)

7434

"PaX/grsecurity fournissait à tous, et fournit toujours à ses clients, l'historique des modifs." est pourtant loin d'être une louange, mais passons... oui, je signalais le fait qu'en ne fournissant pas l'historique détaillé, Redhat ne fait pas quelque chose que même grsecurity, dont tu détestes le comportement, fait.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7435

Je ne suis pas d'accord avec ton point de vu sur les *Kit, SD et PA. Surtout avec SD qui est gourmand et cherche a manger le plus de truc qui n'ont au premier abords aucun rapport avec celui-ci. Le fait que SD ai fait un takeover sur udev est une forme de vendor lock.

Tu veux udev officiel? utilise SD, sinon VTFF
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7436

Vu. Apparemment, je prends "vendor lock-in" à un sens plus littéral que toi, et je voulais signifier que l'utilisation de CK, PolicyKit, PackageKit, systemd+udev, PA ou son successeur désigné PipeWire ne verrouille pas les utilisateurs sur les distros Redhat, puisque la plupart des distros ont adopté les mêmes technos.
Tu as raison, l'intégration trop poussée d'udev et systemd pose des problèmes à ceux qui souhaitent pas utiliser ce qui est devenu un standard (de fait) de base commune pour les distros Linux.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7437

Non mais tu as raison j'abuse un peu du terme ici, même si je pense qu'on en est pas loin. Redhat contrôlant les dit projets, et ayant réussi le tour de force d'en imposer la majorité sur 80-90% des distribs, ils on un contrôle proche d'un vendor lock-in plus "classique":

Tu ne peux pas (facilement) te passer des produits Red-Hat.


De toute maniere il ne faut pas se leurer, RH ne veux qu'une seule chose: être seul sur le marché, leur but étant les $$ avant tout.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7438

Les malwares pour Linux n'ont rien à envier à leurs équivalents Windows :
https://www.zdnet.com/article/new-linux-crypto-miner-steals-your-root-password-and-disables-your-antivirus/
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7439

Pas mal, en effet smile
Le must serait d'utiliser ce virus grâce à une des nombreuses ACE / RCE sur un pro-virus (dommage que l'article n'utilise pas ce terme) ^^

Les deux failles sont anciennes, mais c'est un excellent choix parce que les machines non patchées sont hélas nombreuses. Et puis rien n'empêche d'en utiliser d'autres qui s'appliquent à un spectre moins large de versions, les listes hebdomadaires de vulnérabilités montrent que ce ne sont pas les 0-day LPE qui manquent dans les fonctions de namespaces ou eBPF, par exemple.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7440

8d2.gif