Hacker Newsnew | past | comments | ask | show | jobs | submit | genshii's commentslogin


Hi Jarred, thanks for all your work on Bun.

I know that one thing you guys are working on or are at least aware of is the size of single-file executables. From a technical perspective, is there a path forward on this?

I'm not familiar with Bun's internals, but in order to get the size down, it seems like you'd have to somehow split up/modularize Bun itself and potentially JavaScriptCore as well (not sure how big the latter is). That way only the things that are actually being used by the bundled code are included in the executable.

Is this even possible? Is the difficulty on the Bun/Zig side of things, or JSC, or something else? Seems like a very interesting (and very difficult) technical problem.


I used Proxmox for years to run a fairly comprehensive homelab, and a few months ago replaced the entire thing with Incus (on a debian host, haven't tried IncusOS yet). Incus is amazing and it makes so many things so much easier compared to Proxmox.

One thing in particular is permissions in unprivileged containers. In Proxmox, you have to do a bunch of somewhat confusing ID mapping. In Incus, it's as simple as setting "shift=true".

Also the profile system in Incus is really powerful and allowed me to deduplicate a ton of config.


Can Incus do regular vms too, or only LXCs? I think I looked at it before but wrote it off because I still have some workloads that have to be in VMs.


It can do VMs, "system containers" like LXC and Docker/OCI-compatible application containers.

There was a project to implement a dockcer-compose compatible "incus-compose" but unfortunately, it looks dead, right now.

You can even set up a kubernetes cluster entirely composed of containers: https://github.com/lxc/cluster-api-provider-incus


Yes, it can do both. The image server will build for both options if possible, so you have to specify “—vm” on the command line creating the domain.


That's awesome, thanks for the nudge. I reinstalled one of my proxmox servers so that I can try Incus out and see if I like it.

It looks like it may handle networking (via ovn) a bit better than what I have now


Incus is more comparable to LXD than proxmox. IncusOS is different though.

LXD containers also are unprivileged by default.


Incus was an LXD fork in the very beginning but it's evolved a lot since then. Incus is far superior than LXD in number of ways


Incus is specifically an LXD fork.


You might be mixing up LXC and LXD


From Incus main page:

> The Incus project was created by Aleksa Sarai as a community driven alternative to Canonical's LXD. Today, it's led and maintained by many of the same people that once created LXD.

Thé confusion si real


Even I that worked for a long while with this tech would mix them up time and again, I think it's understandable.


No, LXD’s LXCs. I use it and it’s good.

The UID mappings are correctly setup in Ubuntu so the containers run non-privileged by default.

I hear Incus, a fork of LXD, is better. It’s used in truenas.


Interesting. Is there anything else that is better than proxmox? Like performance etc?


Besides VMs and LXC/Proxmox-style containers, it can also run docker containers out of the box.


I like harvester by suse


Profiles are really great. It's like cloud-init on steroids


Maybe it's just too early in the morning for me, but I genuinely can't tell if this is satire or not.


I'm personally looking forward to this change because I currently pay $20/month just to get edit prediction. I use Claude Code in my terminal for everything else. I do wish I could just pay for edit prediction at an even lower price, but I can understand why that's not an option.

I'm curious if they have plans to improve edit prediction though. It's honestly kind of garbage compared to Cursor, and I don't think I'm being hyperbolic by calling it garbage. Most of the time it's suggestions aren't helpful, but the 10-20% of the time it is helpful is worth the cost of the subscription for me.


We have a significant investment underway in edit predictions. We hear you, more soon.


This is the one thing keeping me from switching from Cursor. I much prefer Zed in every other way. Exciting!


Yeah, Cursor tab completion is basically in the realm of magical mind reading and might still be the most insane productivity demonstration of LLM tech in software.

It obsoleted making Vim macros and multiline editing for example. Now you just make one change and the LLM can derive the rest; you just press tab.

It's interesting that the Cursor team's first iteration is still better than anything I've seen in their competitors. It's been an amazing moat for a year(?) now.


I agree. I wish they focused more on it. I'd love to be able to give it a few sentences of instructions to make it even more effective for me. It's so much more of a productivity boon than all the coding agent stuff ever was.


I could say the same about the AI-assisted autocomplete in IDEA. Wonder how they compare...


Windsurf.


That's great to hear, thanks!


This is very very exciting.


The edit prediction model is open source https://huggingface.co/zed-industries/zeta

It's based on qwen 2.5 coder 7B and you should be able to run it locally quite easily since it would only require about 8 GB of VRAM for the 8-bit version. Not sure if Zed supports this though, I'm not a Zed user myself.


I have never used Zed predictions but $20 for 500 prompts is quite a good deal. I use it mostly with Opus for some hard cases.


10 bucks on copilot and you get unlimited + unlimited gpt4.1 etc

Copilot is the best value by far


How well does copilot edit prediction work vs Zed’s?


Still very poor. Not sure why they have so much trouble catching up. I would have expected them to by now. Cursor is still the best by far, followed by Windsurf (free by the way).


sorry, do you mean CoPilot is poor or Zed's own edit prediction is poor?


That's been my workflow also. Claude Code / OpenAI Codex most of the time, when I have to edit files Cursor's auto-complete is totally worth the $20.


There are plenty of larger ones and plenty of ones that used the date as the version, but I was mainly curious about packages that followed semver.

Any package version that didn't follow the x.y.z format was excluded, and any package that had less published versions than their largest version number was excluded (e.g. a package at version 1.123.0 should have at least 123 published versions)


After double-checking some things, the real winner is actually: https://github.com/nice-registry/all-the-package-names

I made a fairly significant (dumb) mistake in the logic for extracting valid semver versions. I was doing a falsy check, so if any of major/minor/patch in the version was a 0, the whole package was ignored.

The post has been updated to reflect this.


Ah this is cool, thanks!


Hmm yeah, I decided that one counts because the new packages have (slightly) different content, although it might be the case that the changes are junk/pointless anyway.


Hmm, maybe I need to think about this more, but since operations are a language feature (and could have any name, see custom operations), I don't think they could be attached to the filterql class like that.

You're right though, the naming of the `filter` method is confusing. I need to split off the filtering and applying of operations into two separate methods. And probably provide an additional `query` method like you said which would do what `filter` is doing now. Appreciate the feedback!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: