Have a suggestion?
Click here to suggest a blog item.
Catch up with DonationCoder by browsing our past newsletters, which collect the most interesting discussions on our site: here.
DonationCoder does not accept paid promotions. We have a strict policy of not accepting gifts of any kind in exchange for placing content in our blogs or newsletters, or on our forum. The content and recommendations you see on our site reflect our genuine personal interests and nothing more.
July 30, 2018
June 24, 2018
Apr 2, 2018
Apr 2, 2018
Feb 24, 2018
Jan 14, 2018
Major Site News
Jan 10, 2018
Our daily Blog
This page spotlights the most interesting posts collected from our forum every day.
This guy is very very funny animating stories from his life. He has dozens of them.
Here's an interesting article that argues that using C to write low-level fast code that operates close to the bare metal is no longer a straightforward task, and is becoming increasingly virtualized..
One of the key attributes of a low-level language is that programmers can easily understand how the language's abstract machine maps to the underlying physical machine. This was certainly true on the PDP-11, where each C expression mapped trivially to one or two instructions. Since then, implementations of C have had to become increasingly complex to maintain the illusion that C maps easily to the underlying hardware and gives fast code... In light of such issues, it is difficult to argue that a programmer can be expected to understand exactly how a C program will map to an underlying architecture.
This is actually both a review and a tutorial. Please don't hurt me for partially ignoring the headline.
After the UNIX 7th Edition which almost anything that claims to be "UNIX-like" is either based upon or inspired by had been released, the developers continued to work on it. However, the last three UNIX releases did not see much adoption: Between UNIX Version 7, released in 1979, and UNIX Version 8, released in 1985, the UCB's UNIX distribution BSD had been developed so far that it had more than twice of UNIX's system calls. In fact, the eighth UNIX was basically a reimported version of 4.1cBSD, modified to run on VAX computers.
Neither the 9th nor the 10th (and final) UNIX were ever released as a complete operating system, efforts to work on it were soon stopped in favor of what should have been UNIX's successor for operating systems research, named Plan 9 from Bell Labs, inspired by what was called "the worst movie of all times". (I will not link that.) The developers of Plan 9, mostly being recruited from the UNIX and C teams (among them, Rob Pike and Ken Thompson), continued from what they had: the graphical terminal Blit came in the 8th edition, Mk and the rc shell were there in the last UNIX version as well. Plan 9 tried to complete UNIX's approach of "everything is a file" by introducing the 9P protocol which acted as a replacement for regular APIs (including sockets and other device calls). Using the wikifs layer, even the Wikipedia could be edited as if it was a collection of files on the local machine. (Sadly, this layer does not seem to have been ported to other operating systems yet.)
Of course, since the 70s were over, the usual computer had a real screen instead of a printer and Apple, Amiga and Atari had successfully taken Xerox's revolutionary input device, the "mouse", out of obscurity by the mid-80s, this was what was considered the best way to interact with a computer: The Plan 9 operating system, including its text editors sam and acme, was developed to be used with a three-button mouse. The designers decided that light blue and light yellow were the best colors to stare at all day, so there was not much to configure. Theming was not a thing.
I’ve been trying to make my computers quieter for nearly three decades. Custom liquid cooling loops, magnetically-stabilised fluid-dynamic bearings, acoustic dampeners, silicone shock absorbers, you name it. Well, last week I finally managed to build a completely silent computer. Without further ado…
Security warning: eff.org says that you need to immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email.
This looks pretty serious. Although they are not saying what the flaw is yet, the key seems to be if you have a mail program that AUTOMATICALLY decrypts pgp encrypted emails, somehow that can be hijacked.
A group of European security researchers have released a warning about a set of vulnerabilities affecting users of PGP and S/MIME. EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.