kbknapp

Initially I was like, "Oh cool, a new layer on top of Nix to make it more accessible!" And then read on to see it's basically just the NixCpp fork from save-nix-together now with Meson. I guess gradually moving to Rust is a cool idea, but there also exists tvix in that space with a greenfield version in Rust.

This looks to be a fork of NixCpp only. There is also https://aux.computer that appears to be (the beginning of) a fork of nixpkgs.

Navi[1] is perfect for this! It's both a fuzzy finder of a personal collection of commands, but it's template syntax is flexible enough to be able to have "command builders"

I have a blog on doing exactly this for a subset of strace[2].

1: https://github.com/denisidoro/navi

2: https://kbknapp.dev/strace-navi/

GPS satellites don't "send" your coordinates to your receiver. Your receiver is just listening to the broadcast signal from several (usually 4+) satellites and based on the strength of that signal determining how far it is from each of those satellites. Which means the receiver is able to triangulate it's own position.

In fact, I believe that's exactly where this bug lies. You're effectively able to trigger a case in which passing `&'a &'b` without providing any correlation (`where 'a: 'b`) that one would normally be required to provide makes the compiler behave as if those correlations were passed, albeit inferred incorrectly.

hyperfine is such a great tool that it's one of the first I reach for when doing any sort of benchmarking.

I encourage anyone who's tried hyperfine and enjoyed it to also look at sharkdp's other utilities, they're all amazing in their own right with fd[1] being the one that perhaps get the most daily use for me and has totally replaced my use of find(1).

[1]: https://github.com/sharkdp/fd

Rust can re-use an allocation, but if the new item is smaller than the previous it doesn't automatically remove (free) the "wasted" memory left over from the previous allocation. I think this is categorically not a memory leak as the memory was absolutely accounted for and able to be freed (as evidenced by the `shrink_to_fit()`), but I can see how the author was initially confused by this optimization.

The 2x versus 200x confusion IMO is the OP was conflating that Vec will double in size when it needs more space, so they were assuming the memory should have only ever been 2x in the worst case of the new size. Which in the OPs case because the new type size was smaller than the previous, it seemed like a massive over-allocation.

Imagine you had a `Vec<Vec<u16>>` and to keep it simple it there were only 2 elements in both the inner and outer Vec's, which if we assume Rust doubled each Vec's allocation that'd be 4x4 "slots" of 2 bytes per slot (or 32 bytes total allocated...in reality it'd be a little different but to keep it simple let's just assume).

Now imagine you replace that allocation with a `Vec<Vec<u8>>` which even with the same doubling of the allocation size would be a maximum of 4x4 slots of 1 byte per slot (16 bytes total allocation required). Well we already have a 32 byte allocation and we only need 16, so Rust just re-uses it, and now it looks like we have 16 bytes of "waste."

Now the author was expecting at most 16 bytes (remember, 2x the new size) but was seeing 32 bytes because Rust just re-used the allocation and didn't free the "extra" 16 bytes. Further, when they ran `Vec::shrink_to_fit()` it shrunk down to only used space, which in our example would be a total of 4 bytes (2x2 of 1 byte slots actually used).

Meaning the author was comparing an observed 32 byte allocation, to an expectation of at most 16 bytes, and a properly sized allocation of 4 bytes. Factored out to their real world data I can see how they'd see numbers greater than "at most 2x."

TBF, when a 1.0 is released doesn't mean it's viable right way for things like this. It takes a certain level of market adoption and ecosystem buy-in first.

Also, Zig still isn't 1.0 so if we're measuring languages from when they first became public, I believe those others in your list are much older as well.

I'm not a fan of trying to put hard numbers on unknowns like this because it biases against uncertainty, but if they shaved ~74 minutes off their CI time and assuming it runs multiple times a day that very quick equates to a small teams cost savings over a year.

However, I think trying to find the actual numbers is dumb because there's also the intangibles such as marketing and brand recognition bump by doing this both for the company and individuals involved.

That's not to say all greenfield endeavors should be actioned, but ones with substantial gains like this seem fine given the company is big enough to absorb the initial up front cost of development.

I've had significantly fewer issues with `cargo [b]install`ed compiled Rust programs than `npm install`ed ones. Getting nodejs/npm installed (and at an appropriate version) is not always trivial, especially when programs require different versions.

OOTH, Precompiled Rust binaries have the libc version issue only if you're distributing binaries to unknown/all distribtuions, but that's pretty trivially solved by just compiling using an old glibc (or MUSL). Whereas `cargo install' (and targetting specific distributions) does the actual compiling and uses the current glibc so it's not an issue.

Really cool idea but this gives me anxiety just thinking about how it has to be maintained. Taking into account versions, command flags changing output, etc. all seems like a nightmare to maintain to the point where I'm assuming actual usage of this will work great for a few cases but quickly lose it's novelty beyond basic cases. Not to mention using `--<CMD>` for the tool seems like a poor choice as your help/manpage will end up being thousands of lines long because each new parser will require a new flag.

Many (most?) disagree with this line of thinking, but I believe the "Rust will never have a 2.0" style thought is what ultimately leads these multi-year pursuits of perfect (or at least good enough to last "essentially forever"). The Editions provider a certain release valve for some styles of breaking changes, but I don't believe it's quite enough ultimately over the entire lifespan of a language which will undoubtedly grow cruft that even Editions cannot remove.

Seems the author is expecting OAI to continue merrily along its way working towards AGI (albeit at a stated slower pace) while MSFT is able to take Altman et al and circle the wagons on what already exists (GPT4) squeezing it for all its worth. While that's entirely possible, there are other outcomes not nearly as positive that would put MSFT at a disadvantage. It's like saying MSFT's AI hedge is built on what appears like sand; maybe it's stable, maybe it's not.

I've worked in large companies (thousands of employees) and startups (<20) and I actually felt more like a cog in the machine at the startup size companies.

I was literally just a means to an end to churn out code on a product. I could have been (and eventually was) replaced at any moment with another generic cog willing to churn out the same code without much of a thought.

It's the IATA code for Portland International Airport. Many datacenters use IATA codes for the nearest airport to give a rough approximation of the location. So the PDX datacenter is the one closest to the PDX airport in or around Portland.

Git terminology is a clinical example where many (most? definitely not all) terms make perfect sense once you already understand how it works, but make almost no sense in concert with other terminology or when you don't know the implementation details.

Leaky terminology.

The "Security. Cryptography. Whatever." podcast just did an episode about the origin of the nistp curves.

https://securitycryptographywhatever.com/2023/10/12/the-nist...

My wife isn't going to be happy about this...

I have an ErgoDox EZ at home, and a Moonlander for work. I absolutely love these keyboards. They have played a significant role in reducing pain I experience from arthritis.

This makes me wonder about newer terminal emulators on maccOS like Warp[1], and if they're for example taking all input locally, and then sending it over the remote host in a single blob or not? I imagine doing so would possibly break any sort of raw-mode input being done on remote host but I'd also imagine that is a detectable situation in which you could switch into a raw keystroke feed as well.

[1]: https://warp.dev

I wonder how well (or if it's even possible?) to pair this with hosted WASM runners (like CloudFlare Workers, or Fastly Runners, etc.).

It looks like there is also (limited?) support for tracing functions and allocations in WASM binaries you didn't compile. I'm looking forward to trying this out!

It was a combination between Patreon and Github Sponsors for solo the lead developer at the time making several thousand USD per month. Those campaigns are still ongoing AFAIK, but the contribution amounts are now private.

I think the reason the word "scam" became attached is because those outrageous and frequent claims were attached to receiving large sums of money.

> If you ask those angered they pull out a list of petty grievances a mile long composed of misleading or highly interpretive wrongs.

How can you assert that they're misleading or highly interpretive wrongs if you haven't dug into them yourself and actually used V? All the negative press I've seen on V has been highly detailed and reproducible.

The generals tips I have apply equally for self-taught developers and traditionally trained, yet are interestingly enough more often easier to accept for self-taught developers. Perhaps due to a willingness to acknowledge a _potential_ gap.

1. Be curious; allow yourself to say "I don't know" and go deeper

2. It's OK to be wrong; be humble and use step 1 to correct

3. Be aware of and try to discover and shed light on the things in your field that are your unknown-unknowns [1]); and then follow step 1

Links:

1: https://en.wikipedia.org/wiki/There_are_unknown_unknowns

Exams mostly don't assess knowledge and understanding, only snapshot regurgitation of facts and snippets. Additionally, when one takes an exam it's rare to require 100% correct to "pass" (and even when that does happen it's only 100% of the sliver of the total subject matter that was assessed). I know plenty of people (as I'm sure we all do) that can pass a test and still be functionally useless in a particular field. Not that I'm against exams (and I'll lump in certifications), I just don't think they're the silver bullet many make them out to be at least in the tech industry.

At least when downloading from the Play store, Google requires the application be updated every 90 days or so. I've run into this multiple times where the application ceases to function after the 90 day window until I go update.

How many of these are duplicates or just multiple versions though?

At least on Fedora I've always found the RPMs either lagged pretty far behind version wise (at least the COPR repos, I can't remember if I tried the OpenSUSE ones or not? But I generally try not to use OpenSUSE RPMs due to differences that crop up between SUSE and RHEL families packages), and the snap version basically didn't work for all but the most basic cases.

I'd love an actually up to date RPM compatible with the RHEL family.

The fact that my M2 has an effectively double size battery from my Fedora based Thinkpad (M2 has a 100Wh battery, while the Thinkpad has a 57Wh) means it just needs to be not terribly less efficient than x86 Fedora laptop for me to be happy, which from the sounds of it is already the case.

Last I looked Session[0] does not and was created for just that purpose but without sacrificing much in the way if UX.

0: https://getsession.org/