Xorg lying is actually a good point. I am reading up on the XDG mailing list for quite awhile, although I know next to nothing about (modern) programming - my knowledge of Turbo Pascal and Delphi must be considered ancient. But my reason for subscribing is different, and maybe someone on this mailing list has the answer to my problem:
As I see it, there's a lot more to freedesktop.org than it meets the eye. I am - despite my outdated knowledge about programming - a fairly nerdy guy with about a dozen computers in use at home. Since October 2016, ALL of then are down owing to a polymorphic, multi-platform malware. NOT a virus or Trojan, although in reality it amounts to that. The backbone seem to be faked root certificates. How I got those in the first line, no idea. But together with DBUS, Fileroller, Avahi, ConsoleKit, CACertificates and about a dozen other legit and fairly common pieces, of software, these turn ANY PC into the perfect surveillance tool no matter of OS used. This crap marched through my well maintained Win7Pro installations in the same way it affected Mint Linux 64, TrueOS and Kali Linux installations. It even shows on my BlackBerry OS 10 devices (which are actually QNX or Posix). On a Windows machine, a lot of malware dll's are crossloaded, with the fake root certs making sure no major Antivirus solution is acting up, and as soon as the bugging has been detected by the user the only aim is to destroy primarily data and then the OS, rendering the installation unusable. On Linux based machines, anything one says, does, watches, stores or retrieves is submitted through encrypted channels to I dunno where. Why have I not just wiped, reinstalled and moved on? Because this crap is... advanced. Probably at least a part of this belong to the NSA deployment tools stolen from that bugged server. The malware is BIOS and firmware resident. Even if one starts a system from a live medium -CD, DVD, USB stick, network server or even floppy disc, the very first thing executed is BusyBox and an encrypted SQASHfs partition, crossloading functions which are...detrimental to the legit's users interest, to put it politely. Uninstalling is impossible, since the repositories of any Linux installation have been altered in a way that by uninstalling parts of the malware backbone you also uninstall core functionalities of your system. Eventually, the system is rendered unusable, crashes and gets reinfected upon reboot from the BIOS. Of course i've tried to flash the BIOS and the firmware controllers. Suffice it to say that didn't work, long story why. The malware is capable of gaining Internet access by using WiFi and Bluetooth connections which were not made available; e.g. which were turned off in the BIOS or for which even the user does not know the password (because they don't belong to him). A whole bunch of hacking tools -most of these astoundingly small - are contained in the core load. While I can't read most of the directories created by that malware - most of them symlinked 50x and in multiple ways - some I can, and almost all links point to, you may have guessed it, freedesktop.org. So far, three service providers have smiled at me in their most reassuring manner and said "no problem, we'll take care of it". A maximum of two weeks later they neither smiled nor were they reassuring. The answer in all cases amounted to "never seen or heard about something like this" and "sorry but no can do". So I guess my question simply is threefold: 1) How do I get rid of it? 2) why do I have it? 3) What's the purpose of it? One more thing: I am not a programmer. That doesn't mean I don't know my way around a server or workstation system under any standard OS. Since this crap started I bought four new computers. All of them got infected, in no time, no matter if Windows, Linux, MacOSX (actually also a Linux, I know that) or QNX. For the two last systems, I had taken out the WLAN and Bluetooth components and used NO USB stick at all, a network cable wasn't attached and the discs used were original branded Microsoft or other directly from strip-sealed, verifiable sources. So...any ideas, anyone? Regards, Laze Original Message From: [email protected] Sent: Sunday, March 26, 2017 14:00 To: [email protected] Reply To: [email protected] Subject: xdg Digest, Vol 156, Issue 5 Send xdg mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.freedesktop.org/mailman/listinfo/xdg or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of xdg digest..." Today's Topics: 1. Fix URL of jmimeinfo (Sebastian Kürten) 2. Re: Pixels Per Inch needs to be standardized 🔍 (Thomas U. Grüttmüller) 3. Re: Pixels Per Inch needs to be standardized 🔍 (Kai Uwe Broulik) ---------------------------------------------------------------------- Message: 1 Date: Sat, 25 Mar 2017 14:33:39 +0100 From: Sebastian Kürten <[email protected]> To: [email protected] Subject: Fix URL of jmimeinfo Message-ID: <20170325143339.19fda659@pluto> Content-Type: text/plain; charset="utf-8" Hi, I noticed the URL of jimimeinfo is out of date (404) on this page[1] under section 'Current implementors'. It should be changed from [2] to [3] probably. I also attached a git patch if you find this more convenient than fixing it manually yourself. The original homepage is not available anymore and the original author (Andy Hedges) moved the source code to GitHub a few years ago. Thanks, Sebastian [1] https://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/ [2] http://hedges.net/archives/2006/11/08/java-shared-mime-info/ [3] https://github.com/andyhedges/jmimeinfo -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-URL-of-jmimeinfo-on-Specifications-shared-mime-i.patch Type: text/x-patch Size: 1625 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170325/f624858a/attachment-0001.bin> ------------------------------ Message: 2 Date: Sun, 26 Mar 2017 01:41:06 +0100 From: Thomas U. Grüttmüller <[email protected]> To: [email protected] Subject: Re: Pixels Per Inch needs to be standardized 🔍 Message-ID: <[email protected]> Content-Type: text/plain; charset=utf-8; format=flowed On 04.05.2016 17:44, Alberto Salvia Novella wrote: > I would like to propose having a standard way of advertising Pixels Per > Inch, so applications can know its value independently of the desktop > environment in use. The X server already advertises the DPI of the monitor. I found this in /var/log/Xorg.0.log: [ 6882.546] (==) intel(0): DPI set to (96, 96) Here, the resolution is set to 96 DPI although in reality, my screen has 120 DPI. And you know what: I want it to stay this way. Please don’t set it to the true value. Or at least provide some means to change it back to 96 DPI manually. The point in having a higher definition screen is to fit a lot of stuff on it. Thank you. Thomas ------------------------------ Message: 3 Date: Sun, 26 Mar 2017 09:00:46 +0200 From: Kai Uwe Broulik <[email protected]> To: [email protected] Subject: Re: Pixels Per Inch needs to be standardized 🔍 Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" > The point in having a higher definition screen is to fit a lot of stuff on > it. The point in having a higher definition screen is to have crisper fonts and graphics. See how opinions differ? X.org lying to us by forcing 96 dpi is a terrible thing and one of the major complaints we in Plasma get (e.g. Login screen unreadably small) Cheers, Kai Uwe ------------------------------ Subject: Digest Footer _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg ------------------------------ End of xdg Digest, Vol 156, Issue 5 *********************************** _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
