It died because of improper usage: The user caused the CPU to execute instructions. You’re are not supposed to do that! Macbooks are a piece of art, to show to other people that you have money to just throw away. You’re not supposed to do computing with them. Only nerds do that, with their ugly black Thinkpads.
I got frustrated at Gigabyte’s RGB control stuff (I just REALLY want to turn my GPU LEDs off!) so I caved in and started reverse engineering RGB Fusion and OH GOD WHY DID I DO THAT IT IS SO HORRIBLY CURSED
So, basically, the RGB Fusion software flashes a new firmware when you set a new LED pattern. What an unbelievable mess! What do these software developers do for their living? Ah, yes, the develop software. I see.
Why has the user land software have to take care of this? Instead the firmware should just receive a call from the software and do the necessary steps. No need to flash a firmware for that if you do it correctly.
Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels. The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent Linux kernels. There are patches that address most of these vulnerabilities. If patches can not be applied, certain mitigations will be effective. We recommend that affected parties enact one of those described below, based on their environment.
RAMBleed is a side-channel attack that enables an attacker to read out physical memory belonging to other processes. The implications of violating arbitrary privilege boundaries are numerous, and vary in severity based on the other software running on the target machine. As an example, in our paper we demonstrate an attack against OpenSSH in which we use RAMBleed to leak a 2048 bit RSA key. However, RAMBleed can be used for reading other data as well. RAMBleed is based on a previous side channel called Rowhammer, which enables an attacker to flip bits in the memory space of other processes. We show in our paper that an attacker, by observing Rowhammer-induced bit flips in her own memory, can deduce the values in nearby DRAM rows. Thus, RAMBleed shifts Rowhammer from being a threat not only to integrity, but confidentiality as well. Furthermore, unlike Rowhammer, RAMBleed does not require persistent bit flips, and is thus effective against ECC memory commonly used by server computers.
These automatisms in browsers are giving me a bad time. Who the hell came unmedicated to the conclusion to let browsers transform emoticons into emojis? Text has to remain text and images have to remain images.
Of course I could add the text presentation selector (︎) as suffix to every emoticon I write, but that’s not the point. Also the suffix gets removed upon editing, so I need to add it over and over again. Programmatically scanning all texts and adding the suffix automatically is overkill and results in a huge performance loss.
I found an add-on for Firefox which claims to do disable emojis. But it doesn’t work, and also I don’t want a separate add-on for that. Seems like no one thought of a simple CSS setting to disable this crap. I don’t want smileys, emojis, whatever. This is all so painful.
In case you use a Chromium based browser you’ll likely have noticed blurry fonts on this website. First I thought it’s related to font-smoothing, but I don’t use such CSS rules, because they are not part of the standard, yet. Also I checked if forcing the browser to disable font-smoothing changes the way the text is rendered. To my surprise it had no effect at all. So, it must be something else that breaks the font-rendering. In Firefox, Edge and IE the issue does not appear. To make a long story short, in Chrome 72 the text gets blurry if it’s positioned using
That is quite annoying, because you use this rule to center content where the absolute width and height is unknown. If it’s known you could use negative margins instead.
In Opera the positioning using transform does not affect the font-rendering. However, and now things are getting really weird, the cause of the blurry text is the border-radius of the surrounding div element. Wtf!? Yes, the border-radius causes strange font-rendering. And it’s independent of the actual font. A simple
is just enough to make it ugly. Additionally the size of the browser window affects the rendering, too. So, if the browser window is resized by 1-2 pixels, the blurring disappears. Here are some screen shots to illustrate the issue:
Sometimes the top 96 pixels of a maximized window disappear and are no longer click-able. Instead the click is received and handled by the desktop. This happens randomly on my Windows 10 Pro (10.0.16299) machine, which is a dual-monitor system as you can see. The issue is independent of the applications used; it happens in any application, but it cannot be triggered by a special action or similar. I first noticed it in Excel. Later in Firefox’s development tools and now quite often in Opera. All software is the latest. When it happens in a browser toggling full-screen on/off by pressing F11 helps sometimes. Otherwise a reboot is required to make it work again, because restarting the application does not help. Very annoying. Here’s a screenshot how it looks like:
I believe this is an error related to the display driver (Intel HD 4600, version 220.127.116.1135), but prove me wrong. In case anyone has a suggestion what might be the cause, mail me.
Looks like the website of the beloved Gnome Connection Manager seems to be dead. I created a clone of the original code and will implement the fix mentioned here as soon as I find the code. It’s somewhere burried in a bunch of data on a pile of harddisks. What a mess!
I just experienced and issue where the height of the container of an HTML5 video (1080px, mp4) was calculated wrong. The respective stylesheet had set video width to 100% and no height (defaults to height:auto). The browser rendered the video container to a height of >6000px while maintaining the width of the surrounding div and the actual aspect-ratio of the video. Really strange behaviour. The issue seems to occur in Chrome 64 and Opera 51. Firefox and Edge are not affected by the issue.