adamkf's comments

I see these posts a lot, but this really does not match my experience. I find I run into many more bugs in kde than in gnome or other desktop environments. This bug made kde absolutely unusable for me: https://bugs.kde.org/show_bug.cgi?id=365255

(I think this bug is still present in X11, but I've moved on to Wayland.)

The other bug I run into constantly is that "exposé" sometimes makes all the windows invisible. The only fix is logging out and logging in again. I've seen this across a number of different distros. Gnome is mostly boring and just works for me.

I've been using Wayland KDE on my gaming machine recently, it somehow made my cursor movement stutter. Switching to KDE X11 or Gnome Wayland solved the issue.

I hope they address this kind of thing prior to making it a default.

Here's the quote from the [actual whitepaper](https://envoy.com/wp-content/uploads/2023/08/Workplace_Data_...) from Envoy that this article references:

> 80% of executives say they would have approached their company’s return-to-office strategy differently if they had access to workplace data to inform their decision-making.

Envoy's not exactly an unbiased source here, since they sell software to collect this data.

I am using typescript with typescript-language-server. I'll give the lazy stuff a try, but I am not sure why this would make the editor more responsive outside of the initial load.

I gave it a try the other day using copilot.lua, and it made the whole editor unusably slow. It somehow caused syntax highlighting to "lag" for tens of seconds every time I made any sort of edit.

Maybe I need to be using the official plugin, and maybe I need to disable LSP based syntax highlighting, but that makes me wonder what it's doing.

In my experience living in SF, these cars are much safer than the typical drivers in my neighborhood for pedestrians. Most human drivers around here don't even bother to stop at stop signs, and instead just slow slightly. With the cruise and Waymo cars, I feel like the risk is a bit lower when I'm on my bike or walking.

I have witnessed a Cruise car stopping in the middle of the road when faced with an oncoming emergency vehicle, so I totally buy that they aren't ready for prime time yet.

Honestly, I'd prefer if we prioritized enforcing existing traffic laws for regular vehicles.

My understanding is that it provides asynchronous replication, so you'd still lose some data if you lose a machine. This is documented here https://litestream.io/tips/#data-loss-window

>The only time you need to consider a client-server setup is: Where you have multiple physical machines accessing the same database server over a network. In this setup you have a shared database between multiple clients.

This caveat covers "most cases". If there's only a single machine, then any data stored is not durable.

Additionally, to my knowledge SQLite doesn't have a solution for durability other than asynchronous replication. Arguably, most applications can tolerate this, but I'd rather just use MySQL with semi-sync replication, and not have to think through all of the edge cases about data loss.

I gave Helix a try the other day and really enjoyed the "feel" of things. I'm also generally impressed with their philosophy / approach, after having spent way too much time tuning my Neovim configuration. However, I ran into several blockers for it being my daily driver, I thought I'd share them:

1. It's generally janky whenever the language server is slow, in ways that Neovim is not. The most visible one of these is that completion does not take into account the characters that were typed between when the completion request started and when the completion was selected. For example, if I type "abc", and the LSP suggests "abcdef" after having only observed the "a" keystroke, Helix will end up with "abcdefbc" as the final output. This is annoying.

2. The posted directions (https://github.com/helix-editor/helix/wiki/External-binary-f...) for configuring prettier didn't work, there are no error messages visible in any logs. I haven't had the bandwidth to dig into this yet.

3. Helix doesn't detect the correct root for my language servers in my environment, and it doesn't seem to have any way to override the detected root. This means that have to start the editor in the directory that I intend to use as the root. This gets really problematic when I'm working across several languages.

No, it does local checks first, then only checks the full URL if there's a high probability of a match: https://www.chromium.org/developers/design-documents/safebro...

I've been using a lot of typescript lately. The ide support in vscode/tsserver is very complete, but it is NOT fast. As an example, it frequently takes multiple minutes to use find references. Rg or git grep with fzf are both hundreds of times faster, and are easier for me to navigate. (Obviously language aware find references is much more powerful, but with carefully named variables it's acceptable to just use rg.). Sometimes, even a simple "go to definition" results in a 45 second hang. (This is on a 2019 Macbook pro)

I've also used intelij idea with Java, and while it was much smoother than anything in the typescript ecosystem, it's definitely not faster than using grep.

Small, luxury apartments are going to be more profitable than something more affordable. Landlords will build the most affordable thing they can, to do anything else would be irrational. If only luxury apartments are being built, that means demand for such apartments hasn't been satisfied yet. The solution is to allow MUCH more building, so that something affordable will eventually be built. Even without that, having luxury apartments prevents the renters from competing on more affordable units, so it likely does have a positive impact.

I don't know anything about Berlin, but in San Francisco, there are plenty of affordable housing requirements placed on developers of new apartment buildings. This ends up just making new construction MUCH more expensive, as a single unit has to support itself as well as some fraction of an affordable unit. The result is that it's even less profitable to build new housing.

Since you bring it up, I think studying questions that a company has been known to ask in the past is somewhat in poor taste, especially if the candidate gives the impression that this is the first time they've seen the question. Usually, when I've done interviews, I'll try to throw a wrench into the question and see how the candidate reacts if I suspect they've seen the question before.

Though in both cases, I think it's on the question asker (either teacher or interviewer) to make sure that questions change up frequently enough and aren't easy to study without having genuine understanding.

I've had truly terrible experiences with RabbitMQ. I believe that it should not be used in any application where message loss is not acceptable. Its two big problems are that it cannot tolerate network partitions (reason enough to never use it in production systems, see https://twitter.com/antifuchs/status/735628465924243456), and it provides no backpressure to producers when it starts running out of memory.

In my last job, we used Rabbit to move about 15k messages per sec across about 2000 queues with 200 producers (which produced to all queues) and 2000 consumers (which each read from their own queues). Any time any of the consumers would slow down of fail, rabbit would run out of memory and crash, causing sitewide failure.

Additionally, Rabbit would invent network partitions out of thin air, which would cause it to lose messages, as when partitions are healed, all messages on an arbitrarily chosen side of the partition are discarded. (See https://aphyr.com/posts/315-jepsen-rabbitmq for more details about Rabbit's issues and some recommendations for running Rabbit, which sound worse than just using something else to me.)

We experimented with "high availability" mode, which caused the cluster to crash more frequently and lose more messages, "durability", which caused the cluster to crash more frequently and lose more messages, and trying to colocate all of our Rabbit nodes on the same rack (which did not fix the constant partitions, and caused us to totally fail when this rack lost power, as you'd expect.)

These are not theoretical problems. At one point, I spent an entire night fighting with this stupid thing alongside 4 other competent infrastructure engineers. The only long term solution that we found was to completely deprecate our use of Rabbit and use Kafka instead.

To anyone considering Rabbit, please reconsider! If you're OK with losing messages, then simply making an asynchronous fire-and-forget RPC directly to the relevant consumers may be a better solution for you, since at least there isn't more infrastructure to maintain.