Why I don't think browsers will ever standardize how 'Reader Mode' works
I recently read Daniel Aleksandersen's four part series on 'readingmode' in (most) browsers (parts 1 , 2 , 3 , and 4 ,discovered via my referer logs). In the final summary part, "WebReading Mode: A bad reading experience" ,Aleksandersen suggests that there should be standardization of howbrowsers parse pages to determine what is the 'main page' contentsthey will show. I'm not a fan of the current state of affairs (I'vewritten about the
My view of the current state of Go's dependency management (as of Go 1.11)
Over on Mastodon, someone I follow was curious about the state ofGo's dependency management and I had some opinions . Rather than justleave them on Mastodon, I'm going to also put them here with a bunchof additional commentary and clarifications of my toot-forcedterseness.
I started with a rundown of what I see as the current positives (+)and negatives (-):
I would say Go is at about the 50% level, depending on what youwant from dependency management:
I've slowly been improving my web experience by trusting uMatrix more
I have a long history of not running Javascript ,which comes in large part from me very much not trusting sites thatwanted to run Javascript; I started on the web in an era whereJavascript was mostly abused, and that has stuck with me ever since.For most of that history the only way I had to deal with Javascriptwas a total block, first globally and then on a site by site basis(with NoScript). This has left me with a well honed and deep seatedreflex of saying '
Our future IPv6 access control problems due to non-DHCP6 machines
Back almost two years ago, I wrote about how I suspected a lotof IPv6 hosts wouldn't have reverse DNS because they would be using stateless address autoconfiguration(SLAAC) where they essentially assign themselves one or more random IPv6addresses when they show up on your network. For us, this presentsa problem much larger than just DNS, because control over what hostsDHCP will give addresses to (and what addresses it will assign)are how we force machines to be registered on our laptop network and our
Some views on the Go 2 Error Inspection early draft proposal
The big news in Go lately has been the announcement of Go 2 DraftDesigns for improved error handling, error values, and generics. The detailsof the proposed improvements to error values have been split intotwo parts, error printing and error inspection. Today I have someviews on the error inspection draft (and you should also read the error values problem overview ).Broadly, I like the proposal but I feel that it doesn't go farenough and the result of not doing so is going to be inconvenience
ZFS quietly discards all-zero blocks, but only sometimes
On the ZFS on Linux mailing list, a question came up about whetherZFS discards writes of all-zero blocks (as you'd get from ' ddif=/dev/zero of=... '), turning them into holes in your files or,especially, holes in your zvols. This is especially relevant forzvols, because if ZFS behaves this way it provides you with a wayof returning a zvol to a sparse state from inside a virtual machine(or other environment using the zvol
Link: "The History of a Security Hole" (in various *BSD kernels)
To yank my words from Twitter, Michal Necasek's The History of aSecurity Hole is a fascinating exploration of both the arcana of the x86 and whatC can innocently do to you. Watching the code train barrel down thetracks towards its doom was decidedly compelling. There are alsosome useful lessons for long term software development that can beextracted here, since many of the mistakes made were entirely naturalones.
I often find this sort of stuff fascinating, so I really likedreading this entry and found
An extravagant and dense piece of malware-laden email
In the process of looking through our mail system logs for my entry onphish spam with multiple tries , I stumbled over thefollowing extravagant and apparently densely packed email message:
attachment application/zip; MIME file ext: .zip; zip exts: .jar; inner zip exts: .class[4] .mf none[2]; email is in-dnsblrejected from 185.61.138.98/info@cimexcuritibas.com to
If one phish spam doesn't succeed, maybe another will
Here is another entry in the annals of spammers trying extra hard, togo with an earlier one . Recently, our mailsystem logged the following two interesting cases. Let's start with thefirst one:
attachment application/octet-stream; MIME file ext: .pdf attachment application/octet-stream; MIME file ext: .htmrejected from 194.201.253.234/info@deltaexpress.co.
NFS directory reading and directory file type information
NFS has always had an operation to read directories (unsurprisinglycalled
READDIR). In NFS v2, this operation simply returned a listof names (and 'fileids', ie inode numbers). One of the things thatNFS v3 introduced was an extended version of this, calledREADDIRPLUSthat returns some additional information along with the directorylisting. This new operation was motivated by the observation thatNFS clients often immediately followed aREADDIRoperation by abunch of additional NFS calls to get additional information on manyor allMenu
![]()