ripley12

This is very cool, thanks for sharing it. I'll try to add some entries about Vancouver when I have time.

Perhaps you've missed that Trump and several administration officials keep referring to Canada as the 51st state, stating in no uncertain terms that their goal is to annex Canada. Canadians have definitely not missed that. https://www.westernstandard.news/news/trump-dhs-sec-straddle...

This looks very good, thanks for sharing! I maintain a similar project and working with the systemd/dbus APIs has been pretty painful; eager to try this and see what I can learn from it.

https://github.com/rgwood/systemctl-tui

(disclaimer: Datadog employee)

I haven't kept super close tabs on it but last year we were hiring for a role to do tech lead stuff and OSS community building for Vector, and yes several of the original Vector employees still work here.

They worked for me last night.

This looks quite nice overall and the demo is slick.

It looks like backend APIs need to be written in JS and and then deployed as separate files. Not quite what I want, but I can appreciate why they went that route.

It'd be neat to have a project like this as a Rust crate, where you can write your own APIs in Rust and compile the whole thing to a single file.

I also found it kind of hard to understand what it's for from the docs. Logging into the demo UI (linked on the GitHub README) helped a lot.

1. Tailwind is just 1 part of a build system, and it all adds up

2. Watch Inventing on Principle if you haven't already. Pushing build times into milliseconds or sub-milliseconds enables new capabilities

I absolutely care about things that take hundreds of milliseconds for my builds. The faster I can build, the faster I can iteratively try new things things out. The goal should be to be able to see changes instantly after you make them, and Tailwind is usually just 1 part of a build pipeline.

Bret Victor's Inventing on Principle is probably the best demonstration of why this matters; in the first 10 minutes he shows a very concrete example of an insight that would not have occurred without instant feedback https://www.youtube.com/watch?v=EGqwXt90ZqA

> Well, I did see for myself.

What, specifically, did you try? Like what LLM and what tools around that LLM?

> what I've seen doesn't really impress me

I suspect that most people who express this view haven't tried cutting-edge LLMs and tools recently. I've met a lot of people who tried early versions of ChatGPT and Copilot a year or 2 ago, concluded that the tools aren't impressive or useful, and haven't revisited things since.

It's wild what Sonnet 3.5 can do with a tool like Aider; if you have a commit-sized piece of work in mind there's a very good chance it will get it right on the first try.

I've written a bit about how I use Aider: https://www.reillywood.com/blog/how-i-use-llms-sep-2024/

It's not magic, but it is very useful. I find that it works best if you have a commit-sized piece of work in mind; something that might take you half an hour but can be described in a few sentences.

Which LLM were you using? I’ve had a great experience with Aider and Claude Sonnet 3.5 (which is not coincidentally at the top of the Aider leaderboard).

I think it depends on what you want to do. Nushell's never going to surpass PowerShell for Windows infrastructure automation.

But if you want a shell that makes it easy+quick to work with data in all kinds of formats, Nushell wins IMO.

- Why BES vs the Job Objects APIs which explicitly support this kind of resource limiting

Opening another terminal is one thing this new sudo can do. It's also possible to configure it to run the sudo'd command inline in the current window (mentioned in the linked blog post); there are security tradeoffs to consider.

IIRC there are no builds because forcing people to compile it themselves ensures that users (and people who file issues) have a certain amount of technical competency. Keeps life easier for maintainers, but will probably change if/when the project matures.

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

https://news.ycombinator.com/newsguidelines.html

Also, Omar and some other people have been working on the very cool Folk Computer which is inspired by Dynamicland: https://folk.computer/notes/tableshots

The "Do you need a Dedicated Vector Database?" slide is quite interesting, but doesn't really answer its own question! This is something I've been wondering myself, if anyone has any guidelines or rules of thumb I would appreciate it.

I've recently been using Simon Willison's (hi simonw) excellent `llm` tool that can help with embeddings, and it takes the simplest approach possible: just store embeddings in SQLite with a few UDFs for calculating distance etc.

The simplicity of that approach is very appealing, but presumably at some level of traffic+data an application will outgrow it and need a more specialized database. Does anyone have a good intuition for where that cutoff might be?

FWIW, Simon Willison's `llm` tool just uses SQLite plus a few UDFs. The simplicity of that approach is appealing to me but I don't have a good sense of when+why it becomes insufficient.

The Zero 2 W has a 64-bit Cortex-A53 (ARM8).

I upvoted without checking because I'd seen the new Cutler interviews elsewhere and assumed the link would be correct. Whoops.

I've been playing with one of those for the last month, made a little household dashboard thing: https://twitter.com/reillywood/status/1705373370215449033

The refresh time blows (something like 30 seconds), but otherwise I've been pretty happy with it.

Correct. Lets you skip the "connect a keyboard/mouse/monitor" thing though.

Have you tried recent versions of the Raspberry Pi Imager utility? It lets you build pre-configured Raspbian images, similar to what you're describing.

> Will homebrew work on Ubuntu?

Yes, brew works well on any x86 Linux distro (doesn't support ARM yet, sadly).

> Why is there no Debian or Ubuntu package or ppa listed?

Packaging for every distro is a lot of work, and the Nu core team has had other priorities. I think we'd like to have Debian-specific packages eventually but that will probably require some work by a motivated contributor. In the meantime we publish binaries, and it's fairly easy to build from scratch or use Homebrew.

Thanks for sharing; Enron's downfall is fascinating to me (honestly not sure why) and I appreciated this perspective on it.

I don't think MSIX is a good choice for most apps. With a decent-sized user base, you will have a lot of people who run into undiagnosable errors with MSIX or can't use it because they're in locked-down enterprise environments.

I think Affinity Photo's experience with MSIX is instructive; hundreds of negative results on their forum, eventually they had to back down and provide a non-MSIX installer (and at that point do ya really want to maintain 2 separate Windows installers?)

https://forum.affinity.serif.com/index.php?/topic/170529-ext... https://forum.affinity.serif.com/index.php?/search/&q=msix&t...

> It was deprecated by the newer AppX/MSIx/AppV format which uses sandboxes, binary chunks/streaming and no executable code to install stuff.

I can offer a little perspective on MSIX, having devoted months of my life to it in a past job.

MSIX is nearly unusable outside the Store. It will work in a tightly controlled environment, but when you try to deploy it to a wide variety of users you will run into 1) unhelpful errors that basically can't be diagnosed, 2) enterprise environments that cannot/will not allow MSIX installs. I get the impression that the MSIX team is uninterested in solving either of those issues.

It's not a coincidence that virtually no first-party teams use MSIX to install their product outside the Store. Office tried for a while and eventually gave up.

Despite all that, there are still a few people at MS who will tell you that MSIX is the future. I don't really understand it and I assume there's a weird political reason for this.