> Although most people profess to want to change at least one aspect of their personality, those who will put the effort in are surely far fewer
Many people in Alcoholics Anonymous don't actually do the 12 steps as designed by Bill Wilson. They don't understand that it's a piece of spiritual technology designed to produce a spiritual awakening and a reorganization of personality. I've met many people who have become better people through the 12 steps.
I've rewritten them here to give a basic outline and remove any mention of a theistic god. I am not a professional so please forgive me if I've over-simplified or got something wrong. This is how it worked for me at a basic level.
1 - Take a look and see if you have a problem. Admit you have a problem if you have one. You can't fix a problem you refuse to recognize.
2 - Recognize you've tried to solve it by yourself and have failed. You need help from others.
3 - Humble yourself enough to ask for help and be ready to follow direction
4 - List all the complaints people have about you and analyze what you might be doing wrong
5 - Share your failings, no matter how embarrassing, with a trusted other on the principle that confession is good for the soul and sunlight is the best disinfectant
6 - Ask yourself if you're really willing to change. That's not a given. Maybe you aren't.
7 - If you are then do what it takes to change. This is going to be different for everyone.
8 - Look at step 4 and see who you need to apologize to
9 - When you feel you are ready and sufficiently reformed, apologize and make restitution to those on the list you made in step 8. To those that aren't willing to talk, let it go and don't bother them.
10 - Make it a practice to do steps 4 through 9 as needed. We believe in progress not perfection.
11 - We need to remind ourselves daily that we have a problem that we can't solve alone and that we may need the help of others on any given day. I've heard it called a disease of forgetfulness. We may need to wake up in the morning to read and pray if so inclined. As one person told me, "carve out a little piece of each day for the 12 steps"
12 - Carry this message to others who are still suffering
As a designer first turned developers in the early 2000, I beg of you to learn the gestalt.
Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years. Sure there are new patterns now... "hamburger buttons" and swiping, but the logic remains the same. Human's don't change quickly. They discover things the same way.
Learn about visual hierarchy, visual rhythm, visual grouping, visual contrast, visual symmetry; the golden rule; the theory of colours etc. Think "subject" first, like in photography. Design for first glance & last glance.
Go beyond "do these align".
Think in the eyes of your user as if it's their first visit, there is no content yet, etc; as well as if it's their 1000th visit; cater for both cases; first and power users.
Understand the gestalt, understand the psychology behind design... Why does bright-red jumps at you, at a visceral level?
Feeling that something feels right is great, but understanding deeply why it feels right is a superpower.
Understand the human brain, its discovery process (how do babies discover the world), "why do westerners look top left first"? And you might innovate in design, instead of designing to not offend anyone; or worst, copying dribbble and other sources because "they spent the money".
Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"! That knowledge won't expire on you, you'll start seeing it everywhere and you'll carry it for the rest of your life.
Shonan Beach FM, based in Japan. 'Lofi Japanese jazz', I guess? When I lived in a house with a HomePod I had a shortcut hey Siri, Shonan Beach! that was activated most mornings. This was on all day as a low-volume background track. Love it.
- Label each text character with a globally unique ID (e.g., a UUID), so that we can refer to it in a consistent way across time - instead of using an array index that changes constantly.
- Clients send the server “insert after” operations that reference an existing ID. The server looks up the target ID and inserts the new characters immediately after it.
- Deletion hides a character for display purposes, but it is still kept for "insert after" position purposes.
This might have potential outside text editing. Game world synchronization, maybe.
Age (and its rust implementation Rage) combined with agenix[0] and age.el[1] has made my self-hosted deployment and management so, so easy without compromising security. That, when combined with general NixOS conveniences is why I'm able to self-host at all. If not for these, just the anxiety of having to setup new server in case of whatever loss and the associated time/opportunity loss kept me from dong the same for years.
Anyway, just want to say that Age is great!
P.S. The author also did an analysis of Restic the backup tool [2] which also prompted me to setup nice backup solution for my machines. Pretty cool.
This was specifically designed for one producer (the QEMU processor), and many consumers (processing the trace of instructions and memory accesses). I can't remember what specific tunings I did to help with this specific model. Data structures like this can always be tuned slightly based on your workload, by changing structure shapes, shared cache lines, etc.
With about 3-4 consumers QEMU was not really blocking on the reporting of every single instruction executed, which is really cool. This requires a low noise system, just having a browser open can almost half these numbers since there's just more cache coherency bus traffic occuring. If having a browser open doesn't affect your benchmark, it's probably not bottlenecking on the uarch yet ;)
Ultimately, mempipe is not really a big thing I've talked about, but it's actually what makes cannoli so good and enables the design in the first place.
I've been working hard to up skill on the consistency and distributed systems sides of things. General recommendations:
- Designing Data Intensive Applicatons. Great overview of... basically everything, and every chapter has dozens of references. Can't recommend it enough.
- Read papers. I've had lots of a-ha moments going to wikipedia and looking up the oldest paper on a topic (wtf was in the water in Massachusetts in the 70s..). Yes they're challenging, no they're not impossible if you have a compsci undergrad equivalent level of knowledge.
- Try and build toy systems. Built out some small and trivial implementations of CRDTs here https://lewiscampbell.tech/sync.html, mainly be reading the papers. They're subtle but they're not rocket science - mere mortals can do this if they apply themselves!
- Follow cool people in the field. Tigerbeetle stands out to me despite sitting at the opposite end of the consistency/availability corner where I've made my nest. They really are poring over applied dist sys papers and implementing it. I joke that Joran is a dangerous man to listen to because his talks can send you down rabbit-holes and you begin to think maybe he isn't insane for writing his own storage layer..
- Did I mention read papers? Seriously, the research of the smartest people on planet earth are on the internet, available for your consumption, for free. Take a moment to reflect in how incredible that is. Anyone anywhere on planet earth can git gud if they apply themselves.
1. Write TILs. The only justification needed to publish one is "did I just learn something that was new to me?" - having such a low bar makes it much easier to publish frequently.
2. Write about projects you have shipped, no matter how small. I like to think of this as the price I pay for distracting myself with yet another little side-project.
3. Learn to hit "publish" when you still aren't completely happy with what you have written. The alternative is never publishing anything at all!
Here's a snippet of my nixos config that enables immutability . It mounts root on a tmpfs which is erased on reboot. tmpfs is kind of a ramfs but will page to swap in most cases. Add additional bind mounts as necessary.
The sneaky thing to do is have your attorney send a letter to the insurance carrier's liability insurance provider, detailing everything you uncover and that they will be on the hook for the malpractice claim. That will get you an highly aggressive advocate with teeth.
If you want pseudo-random counters for something that are guaranteed to not have collisions, consider using a "linear feedback shift register". LFSRs allow you to choose the number of bits in your id, and "complete" LFSRs use a starting seed [+] value that guarantee they will exhaust the entire bit space before repeating. They are very cool.
In distributed environments, you can assign different seeds to individual nodes, include the seed in the id, and guarantee no collisions across your entire network.
[+]: edit: sorry, I meant "taps". It's been a minute since I got to do something new with an LFSR. LFSR output is determined by "taps" & "seed" & algorithm. Galois LFSR is an easy algorithm to implement. There are publicly available references and datasets for full-cycle LFSR taps for different bit sizes.
I have a php implementation at https://github.com/robsheldon/asinius-lfsr, but the code is absurdly simple and trivial to translate into any other language. Some references and further notes are included.
I've worked in "climate intelligence" for many years. The list overlooks one of the largest and most immediate opportunities around that market: the data infrastructure and analysis tools we have today are profoundly unfit for purpose. Just about everyone is essentially using cartography tools to do large-scale spatiotemporal analysis of sensor and telemetry data. The gaps for both features and practical scalability are massive.
It has made most of the climate intelligence analysis we'd like to do, and for which data is available, intractable. And what we can do is so computationally inefficient that we figuratively burn down a small forest every time we run an analysis on a non-trivial model, which isn't very green either.
(This is definitely something I'd work on if I had the bandwidth, it is a pretty pure deep tech software problem.)
I asked DJ (not on HN, but hangs out in our community Slack [3] where you can ask further if curious), who knows the disk side of things best, and he responds:
The OS is free to reorder writes (this is true for both io_uring and conventional IO).
In practice it does this for spinning disks, but not SSDs.
The OS is aware of the "geometry" of a spinning disk, i.e. what sectors are physically close to each other.
But for NVME SSDs it is typically handled in the firmware. SSDs internally remap "logical" addresses (i.e. the address from the OS point of view) to "physical" addresses (actual locations on the SSD).
e.g. if the application (or OS) writes to block address "1" then "2", the SSD does not necessarily store these in adjacent physical locations. (OSTEP explains this well [0].)
"Performance Analysis of NVMe SSDs and their Implication on Real World Databases" explains in more detail:
> In the conventional SATA I/O path, an I/O request arriving at the block layer will first be inserted into a request queue (Elevator). The Elevator would then reorder and combine multiple requests into sequential requests. While reordering was needed in HDDs because of their slow random access characteristics, it became redundant in SSDs where random access latencies are almost the same as sequential. Indeed, the most commonly used Elevator scheduler for SSDs is the noop scheduler (Rice 2013), which implements a simple First-In-First-Out (FIFO) policy without any reordering.
Applications can help performance by grouping writes according to time-of-death (per "The Unwritten Contract of Solid State Drives" [2]), but the SSD is free to do whatever. We are shortly going to be reworking the LSM's compaction scheduling to take advantage of this: https://github.com/tigerbeetledb/tigerbeetle/issues/269.
> millionaire is a common outcome for software developers who work hard through their 20s and 30s now.
No, it's not. It's common for some FAANG engineers. It's not common at all for the industry as a whole.
Look at all these comments doubling-down on the "7%/$10k-per-year" arithmetic, as if the only thing that affects savings rates is knowledge of this basic math. For a data driven community there sure are a lot of people ignoring the data.
Many people in Alcoholics Anonymous don't actually do the 12 steps as designed by Bill Wilson. They don't understand that it's a piece of spiritual technology designed to produce a spiritual awakening and a reorganization of personality. I've met many people who have become better people through the 12 steps.
I've rewritten them here to give a basic outline and remove any mention of a theistic god. I am not a professional so please forgive me if I've over-simplified or got something wrong. This is how it worked for me at a basic level.
1 - Take a look and see if you have a problem. Admit you have a problem if you have one. You can't fix a problem you refuse to recognize.
2 - Recognize you've tried to solve it by yourself and have failed. You need help from others.
3 - Humble yourself enough to ask for help and be ready to follow direction
4 - List all the complaints people have about you and analyze what you might be doing wrong
5 - Share your failings, no matter how embarrassing, with a trusted other on the principle that confession is good for the soul and sunlight is the best disinfectant
6 - Ask yourself if you're really willing to change. That's not a given. Maybe you aren't.
7 - If you are then do what it takes to change. This is going to be different for everyone.
8 - Look at step 4 and see who you need to apologize to
9 - When you feel you are ready and sufficiently reformed, apologize and make restitution to those on the list you made in step 8. To those that aren't willing to talk, let it go and don't bother them.
10 - Make it a practice to do steps 4 through 9 as needed. We believe in progress not perfection.
11 - We need to remind ourselves daily that we have a problem that we can't solve alone and that we may need the help of others on any given day. I've heard it called a disease of forgetfulness. We may need to wake up in the morning to read and pray if so inclined. As one person told me, "carve out a little piece of each day for the 12 steps"
12 - Carry this message to others who are still suffering