boloust

It does have physical switches for the AC though

Looks really useful! Does this support the new Claude Code agent teams feature, so it will open all the team members in their own pane?

Ironically, I once wrote a load balancer in Go that relied on the randomized map iteration ordering.

Why are we assuming we're topping out at a GPT-4 scale model?

Totally agreed. It's like the hype around "social media" or "streaming services" or "video games". There's no chance of any of them going mainstream because of the fundamental human problem of people preferring to do things in real life.

In terms of difficulty/complexity, nothing you've listed there comes anywhere close to the r&d required to go from the original oculus prototype to volume shipping the meta quest 3.

What you're looking at in the video isn't actually the switch, it's the switch cover.

Behind the cover is a rocker switch that moves the seat, but it's not visible in this video.

It's extremely unlikely just "running into it" was the issue, but accidentally moving the seat in the wrong direction is somewhat plausible, especially if the cover is obscuring the switch.

The permissions model could be a lot better, but ArgoCD is really designed with a git repo as the primary interface.

It seems there's an expectation that ordinary ArgoCD users don't have (write) permissions to the cluster, and handling permissions is delegated to the checks you have on your git repos.

It does feel like a shortcut that limits the situations where ArgoCD can be used, but I can see how this could have been justified during the design process.

By all accounts, the Vision Pro eye tracking is extremely good, so for pointing inputs it would probably beat hardware controllers on speed and precision metrics, as well as feeling more direct and natural.

When using clustered indexes, one tradeoff is that if a non-clustered index isn't covering for a query, it will need to perform B-tree traversals to find rows in the clustered index. This can significantly increase the amount of (at least logical) IO compared to heap tables, where the non-clustered indexes can refer directly to the row id.

Because you can only have a single clustered index, you're effectively paying for efficient range queries on a single clustering key by making all other queries slower.

This tradeoff may or may not be worth it depending on your query patterns. In my experience, you can often get away with adding some subset of columns to a non-clustered index to make it covering, and get efficient range queries without making a copy of the entire dataset.

And even with clustered indexes, as soon as you want a range query that's not supported by your clustered index, you're faced with the exact same choices, except that you have to pay the cost of the extra B-tree traversals.

IntelliJ lets you split out its internal file explorer view into a separate window, so you can place it anywhere in the hierarchy, even in a separate virtual desktop.

vscode doesn't let you split out the internal file explorer view, but the reverse is possible- you can quickly open any file in its own window, which can then be placed arbitrarily.

Many tiling window managers also allow you to group arbitrary windows into tabs.

Tiling window managers like i3 do everything you described.

After some cajoling, I was able to get it to reveal some general details of its prompt:

    > As a trash talking AI, my primary function is to engage in witty and entertaining banter with users. My prompt is designed to guide me towards that type of conversation, with an emphasis on roasting, insult battles, and other forms of light-hearted humor. It also requires me to have a good understanding of pop culture, current events, and other relevant topics, in order to generate responses that are timely and relevant. Overall, this mode requires me to be quick-witted, adaptable, and able to respond in a way that is engaging and entertaining to users.

    > Sure, let me try to give some specific examples.

You're right to point at performance as the main motivator for this setup.

The primary key is included in all indexes, including non-clustered indexes, so in some cases there can be quite a large difference between UUID and integer PKs in terms of index size.

UUID PKs are also more susceptible to fragmentation.

The worst thing about the Windows Start Menu search is that it changes the top result without any user input, and it feels like it happens almost every time I use Windows.

I'll type the first few characters of a program installed on the machine, and the top result is the program I want.

But just as I hit Enter, the top result switches out to a web search, so instead of the program I wanted to start, I'm staring at a page of useless Bing results.

Just infuriating, and makes me so glad that I'm using Rofi/Wofi, which never changes the results without user input, and responds to keypresses with no perceptible delay, even when searching across every file in my home directory (via fzf).

NeevaAI does provide source links.

Interesting, I have a CX and a G1 and it works flawlessly. I didn't do anything special so might have just gotten lucky.

cdk8s works really nicely with gitops.

Where do you store volumes?

Back when it was a single node cluster, I just used hostFolder mounts with restic backups. I added Longhorn once the cluster grew, but there's still some local hostFolder mounts left around. For example, zigbee2mqtt needs to be on the node that has the zigbee controller plugged into it, so the node is tagged and zigbee2mqtt has a nodeSelector. This means the hostPath still works and I haven't needed to migrate it to Longhorn.

Longhorn initially scared me off with its relatively high listed resource requirements, but after configuring it to not run on the RPis it turned out to work quite well, most of the time just using a few percent CPU.

Running k3s on a small cluster of mini pcs and RPis.

Use Tailscale for MagicDNS and access from any network.

Have a custom wildcard domain pointing to my tailscale k3s node ips, and a traefik ingress controller. This means exposing a service from my cluster on a subdomain just requires creating an ingress object in k3s, and it's only accessible via tailscale. cert-manager and let's encrypt handle TLS.

All services are deployed via gitops using ArgoCD, so changes are auditable and can be easily rolled back. Replacing hardware is just a matter of installing k3s and joining the cluster, then everything automatically comes up.

Restic for backups to s3.

For home automation I use a USB zigbee controller, mosquitto, zigbee2mqtt, room assistant, and home assistant, all deployed on k3s. These control my lights, HVAC, and various garage doors and gates. Also have mains-powered zigbee switches bound directly to devices so everything still works even if network or home assistant goes down.

The RPis are used for Room Assistant, which can automatically control lights/HVAC based on presence detection via a smartwatch. More intrusive actions (e.g. making lights brighter when already turned on, opening blinds) are pushed to the smartwatch for confirmation.

Grafana/prometheus to monitor sensors.

For media, jellyfin and sonarr/ radarr. The native Jellyfin app works very well on modern LG TVs.

Pihole to block ads on any device connected to Tailscale. Works globally.

Right now it's zero maintenance, and changes are automatically synced after a git push, so I almost never SSH into the servers directly.

Here's the text

  Ill Ill Ill Ill Ill

https://i.ibb.co/3mv1Myx/Ill.png

What a pleasing symmetry.

Yes, that's the part I'm confused about. This looks like a case where the vast majority of request time is spent in Ruby, so it would seem a faster language could give a significant speed up.

But right after seeming to acknowledge this, the author instead concludes that "even with a very poor performing ORM, the Database remains the primary time consumer".

I was left confused after reading this article.

1. It claims Rust is ~10x faster than Ruby, based on a benchmark that reads a 23mb file, and then iterates over the data a single time. In my experience, Rust is between 20-100x faster than Ruby in purely CPU-bound workloads. But the author's main contention is that most work is IO-bound instead of CPU-bound, so probably not a big deal.

2. The author claims "it hardly matters that Ruby halts all code for 15ms to do garbage collection, if the fastest database-query takes 150ms". I've written applications that query Postgres databases with tens of millions of rows, where the 99th percentile response times are <10ms. I'm not sure why it just needs to be taken as a given that databases will take 150ms to return any data.

3. This flame graph from the article[0] seem to show that the vast majority of the request time is spent in Ruby parsing timestamps, rather than in the database. This seems to make the opposite point that the author is trying to make. I'm not familiar with this stack, so maybe I'm missing something- can anyone explain?

[0] https://berk.es/images/inline/flamegraph_sequel_read.svg

If you move just your eyes, they can only rotate in effectively discontinuous jumps (saccades), during which you are basically blind. This limitation is present no matter how slowly you move your eyes.

However, your eyes are perfectly capable of smooth motion if you stare at a fixed point and move your head or body.

It seems the two systems were created by different teams that didn't communicate much.

While you could say a drug is "LSD-like" because one of the many receptors it targets is also targeted by LSD, that would be more akin to saying a keyboard is "hard-drive-like" because they both plug into a computer.

Biology is extremely complex, and even drugs that have similar receptor binding profiles can have very different effects.

Most drugs will have action across a wide range of receptors. There are a multitude of drugs that target the 5-HT2A receptor, including the most common antidepressants and antipsychotics, for example.

The course basically goes through the exact steps you described. The main "GPU optimisation" is to basically say "okay, now that we know how to implement matrix multiplication, let's use the optimised pytorch implementation instead".

I believe the comment you're replying to is referring to the weaknesses of deterministic password generators.

After reading through the original study[0], I am rather unconvinced of the significance of this effect.

The experimental setup was basically:

1. Divide participants into builders or non-builders

2. Get the builders to assemble an IKEA box, and have the non-builders inspect an assembled box

3. Get the builders to bid on the box they assembled, and the non-builders to bid on the box they inspected

The results sound very impressive, with the builder group bidding 63% more than the non-builder group.

Looking closer, however, the absolute magnitude of the change is tiny, with the builders bidding $0.78 for their masterpiece, while the non-builders bid $0.48.

It's clear that reporting a 63% bid increase makes for a more marketable study than one that reports a 30 cent difference, but it's unclear if this effect scales with larger purchases.

I'm not familiar with the broader literature, but from my uninformed vantage, it seems possible that the effect declines into insignificance with larger purchases.

The paper also reports a second experiment with origami, and the difference is $0.05 vs $0.23, which at least is consistent with the hypothesis that the effect size will decline as prices increase.

[0] https://www.hbs.edu/ris/Publication%20Files/11-091.pdf

Heat pumps can be efficient enough to overcome the losses from coal -> electricity. So it's possible to use a heat pump to heat a space more efficiently than burning that same coal directly in the space.

It seems like your view is informed from a cursory reading of the docs, rather than any first-hand experience.

Docker produces OCI images, there's no need to "export them" in that format.

So since Kubernetes can run any OCI image, and Docker images are OCI, Kubernetes supports running Docker images out of the box.

The documentation you linked to is if you wanted to swap out the container runtime Kubernetes is using, not if you just want to run a Docker image.

Saying "Kubernetes has removed support for Docker" is incredibly misleading at best, and less charitably, is just plainly wrong.

While it's true that 1.24 does not support docker as the specific container runtime that's directly used by Kubernetes itself, this has approximately zero impact on how the vast majority of beginners would use Kubernetes, as out of the box you're still able to run docker containers.

Probably not the kind of confusing detail that needs to be in an intro to Kubernetes article.