xcomcmdr a écrit 3537 commentaires

La mise à jour de sécurité contre WannaCrypt a été intégré aux mises à jours automatiquement installées par Windows Update (si on le laisse tranquille) sur les systèmes pris en charge (= Windows 7 et ultérieur) des mois avant que l'attaque n'arrive.

Mauvais admin, changer admin.

(Et que dire de ceux qui utilisaient encore Windows XP, qui plus est au sein d'un réseau voire ayant accès à Internet… -_- )

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est bien la mise à niveau qui était gratuite, donc ce n'est pas gratuit du tout.

Toi t'as loupé la parenthèse de ce que tu cites. ;-)

Cette mise à niveau est toujours gratuite : https://www.microsoft.com/fr-fr/accessibility/windows10upgrade
Pour que ce soit légal, il suffit d'utiliser une technologie d'assistance. Par exemple tu lances la loupe une fois et c'est bon (on ne demande pas que tu sois handicapé, on demande que tu utilises au moins une technologie d'assistance au moins une fois).

Sale pirate ! Pas étonnant que tu utilises des technologies d'accessibilité, avec ton crochet et ton scorbut.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Avec de grands privilèges viennent de grandes responsabilités, comme on dit. Je lis régulièrement des gens qui vantent la conduite distraite

O_O WUT !

C'est une parodie, c'est pas possible.

Et dire que je vais bientôt avoir le permis… J'ai froid dans l'dos !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Un Mac, c'est jamais qu'un PC obsolète pour trop cher, avec un OS et écosystème fermé.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Alors d'abord le prix de Windows en OEM (= fourni avec l'ordi) c'est dans les 100 € (en tout ça l'était quand j'ai comparé ma config "Duck Nukem" avec et sans l'OS sur materiel.net).

Windows 10 a bien été gratuit (en cas de mise à niveau depuis Windows 7/8/8.1) pendant un an.

Et même fortement poussé, avec des méthodes parfois empruntées aux auteurs de crapware (t'as clique sur la croix pour fermer la fenêtre te proposant une mise à niveau maintenant ou dans quelques heures à l'aide de deux boutons ? OK, on fait ça MAINTENANT alors !).

Enfin, le prix de Windows 10 (Home Premium) est de 130 € sur le Windows Store. Et ça date pas de Windows 10.

Exemple : Windows 7 Home Premium coutaît fin 2009 (peu après sa sortie) dans les $120 (soit environ 110 €).

Pour retrouver un prix à (plus de) $200 (ce qui fait 180 € environ) il faut remonter au prix de Windows Vista Home Premium en 2007 :
https://arstechnica.com/information-technology/2009/06/windows-7-pricing-announced-cheaper-than-vista/

Note que 99% ont eu Windows avec l'ordi.

M'enfin ça c'est le prix de Windows seul. Sans même un éditeur de texte ou d'images digne de ce nom.
MS Office (version Home), c'est encore environ 130 €.

Heureusement qu'il y a Libre Office et Google Docs (on me dit dans l'oreillette qu'il y a aussi Office 365, mais c'est pas gratuit) !

Et pléthore d'autres logiciels libres, tels que GIMP et Paint .NET (non parce que Paint, quelle horreur…).

Concernant le piratage, MS sait très bien quelles Windows sont piratés ou non, semble-t-il.

Alors certes MS, qui a déjà un plan suffisamment complexe de licence avec différents modèles (exemple dans le cas de l'OEM : la copie de Windows est liée à la machine, ce qui n'est pas le cas si on a acheté Windows sur le Store), un serveur d'activation, et des protections contre le "crackage" au sein de Windows, pourrait être plus dur chiant dans son implémentation. Mais à quel moment cela donne des retours sur investissement qui valent le coup ?

Je crois que MS a vite compris qu'il y a une ligne très ténue entre "une DRM qui protège notre produit" et "une DRM qui dégoûte nos clients tellement elle leur pourrie la vie".

Le message sur le bureau quand on utilise un Windows pirate ou en version bêta (car la bêta de Windows 7/8/10 était public) est typique de cette philosophie : OK, je te laisse utiliser Windows sans payer (ou une version bêta pour tester), mais tu auras un message sur le bureau pour te rappeler (entre autres) qu'en cas de problème, tu n'auras aucune aide de la part de MS.

Et la télémétrie permet à MS de savoir quels copies de Windows sont "piratées" ou non.
Cela n'empêche pas MS de fournir des mises à jour de sécurité aux copies pirates. Parce que piratés ou non, quand un SI se fait pwned par des Russes/Chinois/autre, c'est pas le moment de dire "hé oh, t'avais qu'à payer !".

Quand une maison brûle, on appelle les pompiers, on dit pas "t'avais qu'à pas acheter des allumettes !".

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Sauf que… ben je ne sais pas et n'ai pas trouvé comment faire comprendre à systemd que le choix par défaut de ma distrib est pourri, alors je suis reparti sous sysV, qui malgré sa complexité permet au moins de remplacer facilement un foutu getty.

T'as pas cherché loin, ça se fait en 30 secondes avec un oveeride :
https://raymii.org/s/tutorials/Run_software_on_tty1_console_instead_of_login_getty.html

Ou encore :
https://unix.stackexchange.com/questions/247293/how-can-i-get-systemd-to-use-qingy-as-my-default-tty-program-instead-of-agetty

+1. Le bouzin est au final plus lent, parce que pendant qu'il glande à attendre que l'utilisateur se log, il pourrait charger des données utiles. Dans le cas de windows, il y a tellement de bordel à initialiser que c'est réellement long. Mais, c'est un bon argument commercial: système qui boote plus vite, ne veux pas dire système utilisable plus vite.

C'est bizarre, je le reproduis pas. Que ce soit sous Windows 10, Windows 7, ou Windows XP.

Et pour cause : ce n'est pas comme ça que Windows fonctionne.

Quand tu te logues, Windows a déjà démarré. Si ton ouverture de session est longue, il faut voir du côté des logiciels qui démarrent avec la session, et désactiver ce qui est inutile. Ça dépend de l'utilisateur et de ce qu'il a installé.

Et ça se fait facilement avec le Gestionnaire de tâches.

Et perso, vu que j'ai besoin de pas mal de trucs, j'utilise l'hibernation. Depuis 20 ans.
Et le problème est réglé.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Wow, on dirait exactement Win32.

Genre le message pour quitter, c'est WM_QUIT :
https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms632641(v=vs.85).aspx

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je sais pas, mais je sais qu'un script InnoSetup est BEAUCOUP plus facile à faire q'un script NSIS.

Avec NSIS, tu te tapes un truc entre PHP et le C, à gérer la stack et le retour des processus.
Un chose simple devient compliquée (du genre : Mettre une jolie image dans son installeur, un timeout, …), et une chose pas si simple devient super compliquée (exemple : pouvoir réparer une installation).

InnoSetup propose bien plus :
- un éditeur intégré, avec lequel on peut quasiment tout faire à la souris
- des dizaines de propriétés simplement modifiables (du genre, IsWin64 pour savoir si on est sous Windows 64 bits. Sous NSIS, il faut un plugin, ou regarder si "Program Files (x86)" existe, et avant ça savoir comment déterminer le System Drive, alors que Inno Setup te donne sd pour ça)
- Un système de script proche de Pascal. Tu mets ça dans une section code, et tu mets tes fonctions là dedans. Simple efficace, haut-niveau.
- Un support natif de l'unicode. NSIS a été développé du temps de Windows 98SE, et il ADORE cette merde d'ANSI et envoie bouler tout ce qui est Unicode. Sympa pour les gens qui ne vivent pas aux USA, hein ?
- L'import facile de fichiers pour le registre Windows. Tu veux que ça soit dans la bonne section selon qu'on est sous Win32 ou Win64 ? OK, tu spécifie par exemple que tout va dans HKLM32 dans la propriété qui va bien, et le setup s'occupera du reste. Faire ça avec NSIS sans pleurer sa mère et supplier son père de t'aider tient du miracle.

NSIS devrait brûler en enfer. Voilà.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le contexte était un simple utilisateur versus un libriste pur et dur qui considérait que tous ceux qui utilisaient des logiciels non-libres n'étaient pas des libristes.

Y compris des pilotes propriétaires. À l'époque où nouveau ne fonctionnait pas sur le dit matos.

Quand j'ai dit que j'ai la vue qui baisse et des lunettes et que je me fais déjà assez mal aux yeux comme ça sans en plus me taper des graphismes qui foirent et/ou illisibles, je "faisais rire" môssieur.

Depuis je l'ai dans l'gosier.

(euh oui)

L'attitude de LeGab me l'a rappelé. Le même dédain face à ce qu'il appelle des "libristes".
Le logiciel libre en question n'est pas utilisable ? Rien à foutre.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben oui, comme arrêter d'utiliser un pilote graphique non-libre parce qu'il affiche des graphismes corrompus sur sa machine et qu'on a déjà des lunettes et la vue qui baisse et que donc le confort visuel c'est important.

Plus important que la liberté logicielle.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est exactement pareil avec Win32, Windows Forms, WPF…

Exemple avec WPF :

    internal class Startup
    {

        [STAThread]
        public static void Main(string[] args)
        {
            var application = new App();

            application.InitializeComponent();
            application.Run();
        }
    }

Et là on a déjà :
- Un thread de rendu WPF (interne)
- Un thread principale pour l'application, dans lequel s'exécute la boucle des messages.

Win32 et Windows Forms, c'est exactement pareil, au moins sur le fond.
(et idem, application.Run() ne rend pas la main avant la fin du programme)

Un traitement long, si l'application est bien faite, se fera dans un thread dédié avec à la fin un appel (asynchrone ou non) au dispatcher WPF pour mettre à jour les éléments graphiques (qui exécute le code qu'on lui donne sur le thread principale).

Si l'application met du temps à s'afficher, on peut lui mettre un SplashScreen en deux clics (ça arrive si la machine est vielle ou sur un cold-boot de l'application, surtout).

Mais c'est pas l'OS qui va forcer une application à être bien écrite.

Depuis Windows Vista et DWM, une application qui ne répond pas reçoit :
- Forcément un contour de la fenêtre principale qui permet de la fermer (en fait, ça existait déjà sous XP - au moins)
- Pouvoir choisir à partir de la fenêtre si on veut la fermer tout de suite ou attendre
- Un titre de fenêtre auquel on rajoute "(Ne répond pas)" (depuis XP, en fait)
- Un effet graphique qui blanchi à 50% la zone cliente de la fenêtre.

Mais c'est tout.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tu compares des choux et des carottes, quand même.

Moi aussi je peux le faire :
- Si on compare sur un ordinateur disposant d'un Pentium III Slot 1 à 800 MHz, une GeForce 4 Ti4800 sur un port AGP2X, un chipset Intel 440BX sur une carte mère ASUS P2B-F, 512 Mo de RAM PC100, et un disque dur IDE en UDMA/33 avec une vitesse de rotation par minutes de 7200 (sans fragmentation quel que soit le FS), on remarque que Xubuntu 12.04 prend 10 fois plus de temps à démarrer que Windows 98SE (merci Xorg).

Voilà, voilà.

Je sais pas si c'est très utile.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Alors un code python performant, c'est le rêve!

Non non, c'est du C.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Source ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Mais je suis sûr que tu vas encore prendre un malin plaisir à me faire dire ce que je n'ai pas dit.

Soupir, linuxfr… C'était mieux avant

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

On parle d'archivage.

Tu confonds les cas d'usage. Ça n'avance en rien le schmilblick.

Mais si ça t'amuse…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Lol, j'ai une vie sociale sans fesse-bouc.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

En même temps, ton Papa il a laissé "Installer Chrome" coché et il a pas vu la différence avec IE.

Comme 99% des "parts de marché" de Chrome.

C'est facile de prendre des parts de marché, il suffit de faire un adware.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Euh non justement, c'est viser une qualité qui est meilleure que de viser un bitrate constant.

La qualité vidéo sera meilleure si l'encodeur peut s'adapter.

Par ailleurs, le bitrate constant est en désuétude depuis deux décennies parmi les encodeurs vidéos. A part de vieux encodeurs, plus personne ne le propose (et à raison).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ce n'est pas un bitrate constant (mauvais pour la qualité, mauvais pour la taille du fichier), mais un facteur de compression constant.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Idem avec plasma : que des crashs, des bugs graphiques, des bouts pas traduits, etc… J'étais pourtant sous arch.

Et ça dur depuis kde 4. Rendez nous kde v3…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

Source (parmi beaucoup d'autres) : https://blog.oo-software.com/en/defragmentation-and-ssds-opportunities-and-risks

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

LinuxFR défragmente des SSD.

Putain la honte.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et le Luxembourg ! On en parle jamais du Luxembourg, et pourtant …

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Cette fragmentation n'est pas visible par le système de fichiers

Oui c'est ce que j'ai vu. Donc une défragmentation au niveau du FS est encore plus inutile.

Mais surtout beaucoup de SSD (ou même tous ?) sont bien plus lents en lecture aléatoire.

Mauvais SSD, changer SSD (ce que j'ai fait).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)