> I conjectured that it's Kubernetes. Just like XML, Kubernetes solves a problem, but it doesn't solve EVERY problem.
Like XML, Kubernetes does a lot of cool things which were not common before it came around (unlike XML, I think K8s actually manages to improve on the state of the art a bit, too). But just as XML was largely replaced by JSON, I am really excited to see what replaces Kubernetes.
Then the user is stuck with the macOS UI and macOS software.
I have a very custom desktop UI based on a tiling window manager (WM); I tend to run it with one or two windows per screen, so that I can focus. I have a suite of synchronised colour schemes between the WM, my editor, my browser (with custom styles for commonly-used sites), my terminal, my PDF reader and my screen locker, so I see one unified colour theme across everything I do on a computer (with separate themes for work and personal computers, so I instantly know what context I am in). I have as few distractions as possible from the work I am doing. I have a fairly consistent set of keybindings across my environment, with custom keybindings for custom work.
Since it’s written in Common Lisp, I can dynamically reprogram my WM as it runs. What I mean is that I can connect to it from my editor and open a REPL; I can define, replace and debug live code in the running instance. It’s not quite as powerful as a real Lisp machine would be, but it’s better than any other desktop environment I’m aware of.
My Compose key setup is much more powerful than macOS’s Option key. I have a pair of true Hyper keys dedicated specifically to my own cross-application tooling, unused by any specific program.
I believe that switching to macOS, Windows, GNOME, KDE or any other setup would be a step back, or at the very least require a significant investment of time and effort to begin to approach parity.
Then there is the issue of freedom. Just about every line of code I run is free software, which I may inspect, learn from, debug and change. It’s not there to make Apple more money.
Then there is the issue of privacy. Apple claim to care about privacy, but with free software I can actually examine code to see if it does anything I don’t want it to do, and I can hire someone to do that for me, or rely on others I trust who have done that. You can’t do that with proprietary software.
The developers of GNU/Linux and the other software are more aligned with my own interests, wants, needs and desires than the developers of macOS are. It’s not perfect alignment, of course (Mozilla is a good example where improvement really is needed, as are the systemd developers), but on the whole the free software community are reasonably well-aligned with me.
I care about privacy, freedom, customisation and productivity. When I use my system, it does what I want it to do and nothing (or at least very little …) else. It gets out of my way and enables me to be effective in my job and in my computer-based hobbies, and gets out of my way so that I have time for my non-computer-based hobbies and the rest of my life.
GNU/Linux and other free software afford me much more privacy, freedom, customisation and ultimately productivity than does macOS.
Pretty neat! I see that you’re using Hunchentoot — are you concerned that it interns HTTP header names in the KEYWORD package? It means that a malicious client can use up all your RAM by submitting requests with random header names.
I have now updated the Nginx configuration to block arbitrary headers coming from the remote client and explicitly pass only a limited set of headers to Hunchentoot. So now I have something like this in the Nginx reverse proxy configuration:
Here's an update. The Nginx reverse proxy configuration update to work around the memory leakage issue in Hunchentoot has now been pushed to the GitHub repository of MathB.in too.
A simple fix that would be to intern all valid header names into the keyword package on startup, and then when processing a request, use FIND-SYMBOL against the keyword package rather than INTERN. If that fails, just drop that header.
> Good to see that the good old "laptop doesn't go to sleep on linux" problem has never truly gone away.
FWIW, I have a spare Windows laptop, just over a year old, whose WiFi does not recover upon waking from sleep about eleven times out of a dozen.
OTOH, I have had both Windows and Linux laptops which have gotten uncomfortably warm when ‘asleep.’ And right now I have a Linux laptop which very rarely hangs on sleep and turns into space heater, not even turning off the monitor but becoming completely unresponsive.
Sleep is apparently a lot trickier a feature than it looks.
I have 2 computers with AMD, sleep glitches on both.
On desktop, sometimes there's no video signal after wake up.
The laptop doesn't support sleep at all, it's either connected standby = not sleeping, or hybernate. Windows says none of the proper S1-S3 states are supported by the computer.
No, it works reliably on many individual PCs as well. Comparing the entire PC ecosystem to a couple models made by a single company is a category error.
There are problems with Macs too as recently as the last release where the laptop would have a bit set preventing it from sleeping that you could only see from the terminal.
HN's dupe detector only kicks in if a story has already had significant attention (see https://news.ycombinator.com/newsfaq.html). We leave it porous to partly mitigate the randomness of what gets noticed on /newest — we want good stories to get multiple cracks at the bat!
In the future we'll have some sort of karma sharing so earlier submitters get credit also.
I think there’s a “noise gate” on the dupe detector…by which I mean it is more likely to trigger the more traction a story previously received.
Except there also seems to be an “LRU cache” to the dupe detector as well, so after some period of time stories aren’t considered duplicates at all. That is to say, that they are treated as evergreen.
Of course this is entirely speculative, but it is no longer like the hard dupe detection of the old days.
That strikes me as an excellent idea: it’s a pretty small tool, but it is useful and has just enough complexity to test the language and its standard library. Note, however, that I have not done so myself!
This is a great example of why Emacs is so powerful: the activation energy to go from ‘gosh, that sounds neat’ to ‘cool, I implemented that’ is so incredibly low.
> Also knowing that the thing will last forever, take care of it and it will probably outlive you. Can't say that about an Apple Watch.
I don’t know how many mechanical watches really will last a lifetime, but they will easily last longer than a so-called ‘smart’ watch.
Six years ago I seriously considered purchasing a ‘smart’ watch. Eventually I realised that they were just another money sink and attention leash, and put the money into a couple of automatic watches instead. I still have them, and wear them regularly. Had I bought an Apple or Android watch, I would have replaced it multiple times by now.
That’s the plus side. The minus side is that I don’t wear one of those two every single day because … I gotten bitten by the watch bug, and now I have a pile of other watches, and I wear those too! I still think that I am ahead of the game, though.
BTW, I write ‘smart’ watch because I don’t think they are really that smart; if anything, they should be called unwise watches, because they are an unwise expenditure of resources, money and attention. Also they just don’t look good. I predict that in thirty years we’ll look back on them much as we do digital watches: as a fad.
The minus side is that I don’t wear one of those two
every single day because … I gotten bitten by the watch
bug, and now I have a pile of other watches, and I wear
those too!
This was a big part of the fun for me. Different watches for different days. It's ridiculous, even embarrassing to admit this but -- I feel like the richest, luckiest man in the world when I look at a drawer full of watches from which I can choose each day. As a child I would never have dreamed of it.
In reality they are all very modest watches, most under $100. The entire collection is not worth more than a nice laptop. But whatever.
As a bonus mechanical watches, unless I'm mistaken, will last longer if not running 24/7/365.
Like XML, Kubernetes does a lot of cool things which were not common before it came around (unlike XML, I think K8s actually manages to improve on the state of the art a bit, too). But just as XML was largely replaced by JSON, I am really excited to see what replaces Kubernetes.