For those who don't know the name, Tim Peters is the author of "The Zen of Python". He is the one who uniquely captured was Python is all about with this inspirational little poem:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
It can become a compulsion to record and collect media. Seems like a male thing, normally it's blokes who create these archives.
I met a bloke once in the 90's who made recordings on to C-90 tapes of anything interesting that was on BBC Radio 4 and 3, and he found most things interesting. He was surrounded by piles, thousands of tapes everywhere and he was desperately trying to catalog everything. As I spoke to him he was listening to the radio via an ear bud, whilst also recording the radio. He was supposed to be moving out of his house that day, having just exchanged contacts, but he was drowning in his precious tapes. His wife seemed pretty p**d off with him.
I was a bit compulsive myself. I used to buy records, then CDs, and I also made tapes of albums, and recordings of the John Peel show. It was a problem to shift 100s of records and CDs and boxes of tapes whenever I moved house. I lightened my load by giving everything away apart from the Peel tapes which were the most entertaining items in the whole collection, it actually felt good. I kept hold of the Peel tapes for some years, even though my tape deck had died. There were some great shows from the 90s! But then I had to downsize again so I took them to the rubbish tip, even that didn't make me sad.
Ultimately, having and keeping stuff just weighs you down.
It served to remind me to be grateful my dad is still alive and to engage in a similar reflection.
I’ve heard people say that while you have the chance, you should sit down and interview your father. The other day I happened to stumble on a list of questions one might ask:
1. What is your best memory of your own father?
2. What did you have as a child that kids today are missing?
3. What has life taught you about love?
4. What are the three most important values in life?
5. What was the moment you were most proud of me?
6. What do you wish most for your children?
7. What is the most importantly family tradition you’d like us to keep?
Fun trivia: so is /lib/ld-*.so*. I busted that out in an interview at a FAANG when the question was "how could you recover from accidentally running 'chmod a-x /bin/*'"? My answer: '/lib/ld.so /bin/chmod a+x /bin/*'. The interviewer paused to get out his laptop and confirm it because he had never heard of it. After a fun detour of geeking out over something new an interesting, the followup question was modified to "How else would you do it?"
It's spelled "/lib/ld-linux-aarch64.so.1" on my nearest Linux box but is still executable today.
Super cool to see this here. If you're at all interested in big systems, you should read this.
> Compounding this latency, hard drive performance is also variable depending on the other transactions in the queue. Smaller requests that are scattered randomly on the media take longer to find and access than several large requests that are all next to each other. This random performance led to wildly inconsistent behavior.
The effect of this can be huge! Given a reasonably sequential workload, modern magnetic drives can do >100MB/s of reads or writes. Given an entirely random 4kB workload, they can be limited to as little as 400kB/s of reads or writes. Queuing and scheduling can help avoid the truly bad end of this, but real-world performance still varies by over 100x depending on workload. That's really hard for a multi-tenant system to deal with (especially with reads, where you can't do the "just write it somewhere else" trick).
> To know what to fix, we had to know what was broken, and then prioritize those fixes based on effort and rewards.
This was the biggest thing I learned from Marc in my career (so far). He'd spend time working on visualizations of latency (like the histogram time series in this post) which were much richer than any of the telemetry we had, then tell a story using those visualizations, and completely change the team's perspective on the work that needed to be done. Each peak in the histogram came with it's own story, and own work to optimize. Really diving into performance data - and looking at that data in multiple ways - unlocks efficiencies and opportunities that are invisible without that work and investment.
> Armed with this knowledge, and a lot of human effort, over the course of a few months in 2013, EBS was able to put a single SSD into each and every one of those thousands of servers.
This retrofit project is one of my favorite AWS stories.
> The thing that made this possible is that we designed our system from the start with non-disruptive maintenance events in mind. We could retarget EBS volumes to new storage servers, and update software or rebuild the empty servers as needed.
This is a great reminder that building distributed systems isn't just for scale. Here, we see how building the system in a way that can seamlessly tolerate the failure of a server, and move data around without loss, makes large scale operations (everything from day-to-day software upgrades to a massive hardware retrofit project) possible that just wouldn't be possible in a "simpler" architecture. A "simpler" architecture would make these operations much harder, to the point of being impossible, making the end-to-end problem we're trying to solve for the customer harder.
I once broke a shear pin after a length of old sump pump discharge hose buried under a snow pile became entangled in the auger blades. The spare shear pins were missing, so I figured I'd take a cheap steel 1/4-20 bolt and grind it down until its just about a 1/16 of an inch diameter at the point where the auger tube and drive shaft meet. It did not work as the following snow fall I hit a rock and the damn thing jumped violently and I let go of the drive clutch which prevented it from completely self destructing. The auger tube hole was gouged from the screw on both sides, the screw bent into a Z shape and the housing was slightly bent askew. After some reforming in my shop it was working fine again and still runs to this day. That Craftsman 5HP blower has taken a hell of a beating, is in rough shape but still runs. I keep wanting to up the HP a bit but its seen enough abuse.
Pro tip: always winterize the engine to keep it running for years. Drain the fuel completely, and drain the carburetor bowl. Pull the spark plug and put a cap full of motor oil in the cylinder and gently turn the engine over by hand using the pull cord to coat the walls. Also helps to tape over the exhaust and stuff the intake port with steel wool to keep critters out of the passages. I once had a generator suddenly stop working and upon pulling the plug found a dead spider across the electrodes which shorted it.
> Lesson learned: Go see if your weaknesses are hindering you at your job. Ie. I wasn’t great at planning or product management at this time. Fix them or move to another position. Also, constantly ask yourself how can I make the company more valuable. You do that and you will never get fired*.
* Unless you do something really stupid or the company goes out of business.
Reading your comment I was putting my money on a customized glances - but after checking the slide... Nope, that's just the default view for btop++ (first screenshot in the link)
E-ink, the company, holds the patents of the pigment core tech that makes "paper-like" displays possible and strongarms the display manufacturers and the users of their displays to absolute silence. Any research project or startup that comes up with a better alternative technology gets bought out or buried by their lawyers ASAP.
E-ink don't make the display themselves, they make the e-ink film, filled with their patented pigment particles and sell it to display manufacturers who package the film in glass and a TFT layer and add a driver interface chip, all of which are proprietary AF and unless you're the size of Amazon, forget about getting any detailed datasheets about how to correctly drive their displays to get sharp images.
In my previous company we had to reverse engineer their waveforms in order to build usable products even though we were buying quite a lot of displays.
With so much control over the IP and the entire supply chain and due to the broken nature of the patent system, they're an absolute monopoly and have no incentive to lower prices or to bring any innovations to the market and are a textbook example of what happens to technology when there is zero competition.
So, when you see the high prices of e-paper gadgets, don't blame the manufacturers, as they're not price gouging, blame E-ink, as their displays make up the bulk of the BOM.
Tough, some of their tech is pretty dope. One day E-ink sent over a 32" 1440p prototype panel with 32 shades of B&W to show off. My God, was the picture gorgeous and sharp. I would have loved to have it as a PC monitor so I tried building an HDMI interface controller for it with an FPGA but failed due to a lack of time and documentation. Shame, although not a big loss as an estimated cost for that was near the five figure ballpark and the current consumption was astronomical, sometimes triggering the protection of the power supply on certain images.
Lesson I learned from this comment: you can dish out as much of heavy-handed advice as your heart desires, as long as you preface it with the phrase "things i've learned"
FYI, Kagi lets you do this and personalize it as you desire. They even share aggregated stats※ about which domains users choose to block/lower. (Mine generally match these stats.)
Personal choice, is what I'd say. You can get a lot of mileage out of implementing a dynamic language with NaN boxing[1].
It really depends on the kind of language you're trying to build an interpreter for, and what purpose it could serve. For dynamic languages, I'd say looking at the core types of Erlang is a great place to start (Integers, Symbols, Functions, etc.). For a statically typed language things get more complex, but even with just numeric types, characters, and some kind of aggregating type like a Struct you can build up more complex data structures in your language itself.
> My biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it’s a crappy design. It does what he wants, but what he wants is not what the world should want.
Why is this crappy? What would be better?
Edit: @luckydude Thank you for generously responding to the nudge, especially nearly instantly, wow :)
Of note, I was able to find that item (which I recalled existed but not by what name) with hn.algolia, but I was not able to find it with the OP search engine, or with the DeepHN search itself. So in my book, Algolia is winning.
But projects like this are super fun and educational to build so props to OP.
https://youtube.com/@thepowerofprolog
https://www.metalevel.at/prolog