In the morning my brother Marco picked us up to go to the Terraria
Expo
in the city of Houten, near the city of Utrecht. I had been looking
forward to this expo for quite some time and was considering to buy
two tarantulas that were on my wish list for some time:
Monocentropus balfouri (Socotra Island Blue Baboon tarantula)
Tliltocatl albopilosus (Curlyhair tarantula)
Soon after we had entered the expo building a man walked towards us
holding a ferret. Alice loved the ferret and soon was holding the
excited animal. While I took some photos she got softly bitten in her
chin by the ferret.
After we had looked a bit around in the small area with mostly rodents
we entered the large one with many tables. Soon we came upon the table
of Dawid Staroń's Exotic Spiders. In the past I had ordered three
tarantula slings with
Dawid. Sadly, after some time, two died. I still keep the Ephebopus
cyanognathus, which remains mostly well hidden.
The majority of the tables was assigned to selling reptiles and
amphibians. We looked at the beautiful but pricey snakes on
display. At the table of EC Reptiles I took
several photos of Python regius on display.
After some more walking we came upon the table of the Belgian
Tarantula Breeding Team. They had both spiders
I wanted; a large female Monocentropus balfouri and an even larger
female Tliltocatl albopilosum [sic]. But since we where half way the
large expo area I decided to keep looking around a bit more.
A while later I decided to return and make the purchase of the two
tarantulas I had seen. I paid €70 for the Monocentropus balfouri and
€50 for the Tliltocatl albopilosus. Female tarantulas are more
expensive because they live much longer compared to males.
After the expo we decided to have lunch. My brother knew a place
nearby but sadly it was loaded and no space for us. So we went to
another restaurant he knew in the city of Zoetermeer. After a nice
late lunch he dropped us of at our home.
Back home I repurposed two terrariums, large plastic containers, that
belonged to animals that sadly had passed away. The first one for the
Tliltocatl albopilosus female. Moving her from the small plastic
container into the terrarium went easy. The terrarium had already a
starter burrow which she soon after found and used to hide from view.
Next, I moved the Monocentropus balfouri into her terrarium. This
was a bit more challenging: the spider moved way faster than the
previous one even before I had opened the container she came in. After
I carefully had removed the lid I carefully pushed her with a large
tweezer I had also bought at the expo. She threat posed a few times
but nothing serious.
After I had housed the two new tarantulas I fed the following four
tarantulas each a superworm Zophobas morio — I had bought two small
containers at the expo as well:
When Puss in Boots discovers that his passion for adventure has
taken its toll and he has burned through eight of his nine lives, he
launches an epic journey to restore them by finding the mythical
Last Wish.
An alarming 87% of container images running in production have
critical or high-severity vulnerabilities, up from 75% a year ago,
according to the "Sysdig 2023 Cloud-Native Security and Usage
Report."
Yet only 15% of those unpatched critical and high-severity
vulnerabilities are in packages in use at runtime when patches are
available.
I was recently debugging an issue in some integration-style Go tests
which made me realize that I didn't have a very deep understanding
of how parallelism works when using go test. I knew that there
were ways that Go could parallelize tests, and I thought it had
something to do with using t.Parallel() inline in each of my test
functions.
Because I feel the concurrency behavior of go test is non-obvious,
and for posterity so I don't forget in the future, I wanted to write
something up here to document my understanding of how go test
parallelization works as of Go 1.19.
Python has long had a monopoly on data workflows — everything from
data analysis to data science to machine learning. Anything that
can't be done in SQL is done in Python. But Python won't be the
language for LLMs.
Flutter Rust
bridge is super
useful project that allows you to call Rust code from
Flutter. Instead of manually writing FFI methods and type
conversions, bridge will generate all that glue code for you.
Emacs has long had a competent spell checker, and it's capable of
distinguishing code from prose, which is useful to many. But Emacs
28 adds a compelling dictionary lookup feature that warrants a much
closer look.
Looking to set up a virtualization server? Proxmox is a popular
choice for IT professionals and tech enthusiasts alike. With its
user-friendly interface and powerful features, Proxmox makes it easy
to run virtual machines on your own hardware. In this guide, we’ll
walk you through the process of installing Proxmox on your
server. Whether you’re new to virtualization or a seasoned pro,
we’ve got you covered.
A common assumption I see on the ‘net is that NP-complete problems
are impossible to solve. I recently read that dependency management
in Python is hard because package resolution is NP-complete. This is
true in principle, but the reality is more complicated. When we say
“NP-complete is hard” we’re talking about worst-case complexity,
and the average-case complexity is often much more tractable. Many
industry problems are “well-behaved” and modern SAT solvers can
solve them quickly.
An introductory post about complexity theory today! It is relatively
well-known that there exist so-called NP-complete problems —
particularly hard problems, such that, if you solve one of them
efficiently, you can solve all of them efficiently. I think I’ve
learned relatively early that, e.g., SAT is such a hard
problem. I’ve similarly learned a bunch of specific examples of
equally hard problems, where solving one solves the other. However,
why SAT is harder than any NP problem remained a mystery for a
rather long time to me. It is a shame — this fact is rather
intuitive and easy to understand. This post is my attempt at an
explanation. It assumes some familiarity with the space, but it’s
not going to be too technical or thorough.
Most command line programs that offer line editing – like bash,
Python, GDB, psql, sqlite and more – do so using GNU
readline. Readline's a powerful library that grants history,
completion, movement and editing to programs that use it — and a
stable and consistent set of keyboard shortcuts.
Shame, then, that even serious command line hackers never bother
learning about its capabilities, as they can supercharge your
command line productivity.
Jar is a toy Python web
framework, implemented in about 200 lines of code (see
cli.py). I
built it to explore some ideas around framework APIs, and to explore
frameworks from the author-side of things. Please don't actually use
it. It's called Jar because it has almost no features and you need
to fill it up yourself!
C++ is late to the coroutine party, compared to other programming
languages, but they are part of C++20. Prior to coroutines, a C++
programmer had two choices, roughly speaking:
Synchronous (straight line) code is easier to understand but less
efficient.
Asynchronous code (e.g. callbacks) is more efficient (letting you
do other work while waiting for things) but is also more
complicated (manually saving and restoring state).
Coroutines, “functions whose execution you can pause”, aim to get
the best of both worlds: programs that look like sync code but
performs like async code.
After a publisher changes a writer's debut novel about a deadly
assassin from fiction to non-fiction, the author finds himself
thrust into the world of his lead character, and must take on the
role of his character for his own survival.
Dropbear is a relatively small
SSH server and
client. It runs on a variety of unix platforms. Dropbear is open
source software, distributed under a MIT-style
license. Dropbear
is particularly useful for "embedded"-type Linux (or other Unix)
systems, such as wireless routers.
Source: Dropbear
SSH, an article by
Matt Johnston.
According to Node’s official documentation, Node.js is a JavaScript
runtime built on Google’s open-source V8 JavaScript engine. Node.js
can execute JavaScript code on the server side, making it possible
to create fast, scalable, high-performance network applications.
I’ve been writing a pubsub listener for work recently and had this
silly “shower thought”: the ideal queue should be empty. Why? If the
queue is not empty, it means that whatever job is consuming from the
queue is not keeping up with messages coming into it. Ok, then if
queues are supposed to be empty, then what are they good for?
I've read some nice articles recently which I can sum up as “advice
you might as well take.” This is stuff that's good to consider at
the beginning of a project, or when you're about to add a feature to
some existing software.
These articles run counter to YAGNI (You Ain't Gonna Need It), the
software design principle that says you should only ever add things
you'll be using right away. Many even call this out in their titles!
One even addresses this by coining an alternative term, PAGNI
(Probably Are Gonna Need It), so let's start with that one.
Writing good code is hard - it takes a ton of effort and
care. Writing bad code that does things correctly is incredibly
hard. Of course, goaccess is a program that is stuck forever in the
form you see it now, because adding new features is nigh impossible,
but looking at the code, knowing that it was valgrind tested, the
thing is a masterpiece.