In CPython, types implemented in C actually are part of the type tree
In Python, in theory all types descend from object (they aredirect or indirect subclasses of it). For years, I've believed (andwritten) that this was not the case at the implementation level fortypes written in native C code in CPython (the standard implementationof Python and the one you're probably using). Types written in Cmight behave as if they descended from object , but I thought theirbehavior was actually entirely stand-alone, implemented by eachtype separately in C.
Using constant Python hash functions for fun and no real profit
In one of the examples of wtfpython ,the author uses a constant __hash__ function in order to make aversion of plain dicts and ordered dicts that can be put in a set.When I saw this, I had some reactions.
My first reaction was to wonder if this was safe. With a lot ofqualifications, the answer is yes. Two important qualities of a __hash__ function are that it always return the same result fora given object and that it returns the same
The legibility of different versions of ZFS
I'll put the summary right up at the front: one of the refreshingthings that I enjoy about OpenZFS on Linux is how comparatively legible and accessible some aspects ofits operation are to me. Well, specifically how comparativelylegible starting up ZFS on boot is. Now, there are two sides tothat. On one side, the Linux setup to start ZFS is complicated . On the otherside, this complexity has always existed in ZFS, it's just that onSolaris (and Illumos/OmniOS)
Who I think CentOS Stream is and isn't for
As time goes by and Red Hat people write more official posts ( via ), I'vegrown some opinions on who it feels that CentOS Stream is for andis not for. Since I also feel that Red Hat people are not being completely straightforward , I am going towrite out my views, as an outsider to the CentOS project but someone whouses CentOS (and Ubuntu LTS) and has in the past used RHEL.
If you want to see if your software will work with upcoming packageupdates for the
Go modules are soon going to be the only future
One of the things that the Go project talked about in Eleven Yearsof Go , posted in November, is theplans for Go 1.16 and Go 1.17, and along with them the plans for Go modules . A short summary of all ofthat information is that Go modules are soon going to be our onlyoption . This is said straight up in the article:
We will also finally wind down support for GOPATH-based development:any programs using dependencies other than the standard library willneed
On Go, release timing, and new machines
One of the early articles I read about the Apple ARM Macs was Onthe Apple Silicon M1 MacBook Pro ( via ).In it, the author (a developer) observed that Go wouldn't officiallysupport these new machines until February 2021, when Go 1.16 isreleased ( cf ). I read this (incontext) as being unhappy with the time it will take for Go to addthis support and have it out in the world, and I had some feelingsabout
Limiting the Nouveau kernel driver's messages via removal
Over on the Fediverse, I said :
Current status: solving software problems triggered by hardwareproblems with 'rmmod
'. It even worked. (Modules cannot incessantly log kernel messages when they areunloaded. I was just glad the module did unload, given likely brokenhardware that it was complaining about.)
Naturally there is a story here.
We have a collection of hand-built AMD Threadripper based computeservers (we bought all theparts, including 4U cases, and assembled them). In
Mailing lists and bounce handling (or not handling bounces) today
Traditionally, if you ran a proper mailing list you were supposedto remove addresses if they started bouncing (or being rejected).The need to automate this was the major reason behind email trickslike Variable envelope return path (VERP) , whereemail to every separate address is sent with a unique envelopesender (and so has to be sent in a separate transaction, insteadof letting you batch together multiple 'RCPT TO' addresses at asingle destination). There's always been a little bit of an open
How to make Grafana properly display a Unix timestamp
There are many things in Prometheus that generate a 'time' valuethat is in seconds since the Unix epoch of January 1st 1970 00:00UTC. One such example, relevant to yesterday's entry on the timewhen Prometheus metrics happened , is theresult of the Prometheus
timestamp()function. When you're working with such times, it's common to wantto display them in a Grafana table (perhaps a multi-value table ), and one natural way
In Prometheus, it's hard to work with when metric points happened
I generally like Prometheus and PromQL ,its query language (which you have to do basically everythingthrough). But there is one frustrating exception that I routinelyrun into, and that is pretty much anything to do with when ametric point happened .
PromQL is great about letting you deal with the value of metrics.But the value is only half of a metric, because each sample (whatI usually call a metric point ) are a value plus a timestamp ( cf ). Prometheusstores the timestamp as well as
Menu