I don’t think that is true. Not much at Google really bought into the UUID hype. At least not for internal interfaces. But really there is no difference between a UUID v4 and a large random number. UUID just specifies a standard formatting.

It is true, don’t do it.

Even at huge companies like Google, lots of stuff was keyed on your email address. This was a huge problem so Google employees were not allowed to change their email for the longest time. Eventually they opened it up by request but they made it very clear that you would run into problems. So many systems and services would break. Over time I think most external services are pretty robust now, but lots of internal systems still use emails (or the username part of it) and have issues.

IIUC Google accounts now use a random number as the key. But there are still places where the email is in use, slowly being fixed at massive cost.

I’m using Kagi. I find that it does a better job at finding “legitimate” sites rather than blogspam and content marketing. However I’m not sure I will stick with it a long time. I seems like it has mostly stalled and the team is getting distracted by making a browser, non-relevant AI (I have no problem with the few AI experiments tied to searching) and other side projects. We’ll see. I really hope that they pull themselves together and focus or it might not last. But for now they seem like one of the better options available.

Bing’s new “Deep Search” where it has some sort of LLM refinement iteration process has also been helpful sometimes. Probably the best AI search product I have seen, but definitely doesn’t replace most searches for me.

23.11 is the nixpkgs/NixOS version. This is the version of the Nix package manager. If you don’t need the newer version then there is nothing to worry about. It doesn’t effect the NixOS and nixpkgs software that you are installing.

This is like an Aptitude package manager update vs Debian version or a Pacman update vs Arch Linux version (not Arch has versions).

I would probably just ignore the Makefile provided by upstream. It just copies files and installs dependencies.

I would take a look at existing python derivations in nixpkgs (ex a random one I picked) and try to modify it to work with your package. Once you have it working well you could even submit it to nixpkgs!

Yes, I agree with your clarification of commonly in use terms.

In my experience taking a term that is widely used and attempting to give it a more specific meaning doesn’t end well. If people are using “method” interchangeably with “associated function” right now it will be an endless battle of trying to make people stop using the term “sloppily” when it isn’t sloppy it was just the original meaning.

There is no concrete difference between the two options. But in general they will be similar. I think you are talking about these options:

struct Person;
struct Skill;

struct PersonSkills {
    person: PersonId,
    skill: SkillId,
}

vs

struct Person {
    skills: SkillId[],
}

struct Skill;

The main difference that I see is that there is a natural place to put data about this relationship with the “join table”.

struct PersonSkills {
    person: PersonId,
    skill: SkillId,
    acquired: Timestamp,
    experience: Duration,
}

You can still do this at in the second one, but you notice that you are basically heading towards an interleaved join table.

struct PersonSkills {
    skill: SkillId,
    acquired: Timestamp,
    experience: Duration,
}

struct Person {
    skills: PersonSkills[],
}

There are other less abstract concerns. Such as performance (are you always loading the list of skills, what if it is long) or correctness (if you delete a Person do you want to delete these relationships, it comes “for free” if they are stored on the Person) But which is better will depend on your use case.

It happened: https://discourse.nixos.org/t/nixos-foundation-board-giving-power-to-the-community/44552 Lemmy post

We’ll see exactly what this means. But I would love if it means that the project manages to continue without the huge amount of confusion and disruption that would come from forks fighting for becoming the canonical source.

Or use a browser extension to implement your preferences rather than push them onto others in a way that makes it harder for them to implement theirs.

If an article links to medium.com my redirects kick in, my link flagging kicks in and everything else. If everyone uses some different service to “fix” medium I am stuck with what they like. There is valuable to keeping the canonical URL.

I would also love to see domain blocks as a user preference in Lemmy. Just hide these sites that I don’t like.

This is “Testing on the Toilet” which are short flyers that are posted in bathrooms at Google. They aren’t typically meant to be particularly profound, just to remind people of common code patterns that can be written more clearly or other reminders that are good to keep in mind.

They are a powerful tool. They are controversial because they can be used for good and evil. For example even some FSF projects require copyright requirement: https://www.gnu.org/licenses/why-assign.en.html. (It used to be all projects, but many have them have switched to DCO, example glibc)

But of course it also means that an organization can take code in a GPL project and start disturbing closed-source versions.

See https://en.wikipedia.org/wiki/Contributor_License_Agreement#Relicensing_controversy for a basic overview.

Lots of projects will have a CLA that basically says “You assign copyright of your work to us” or some sort of unlimited rights grant to the project. So depending on the exact CLA the author may completely transfer ownership of the patch to the project, maintain ownership but grant the project a licence to do basically anything with it (including re-licencing) or for less strong CLAs just confirm that you license the code under the project license.

This is a nice small feature. I’m curious about the commit description:

foo(const { 1 + 1 })

which is roughly desugared into

struct Foo;
impl Foo {
    const FOO: i32 = 1 + 1;
}
foo(Foo::FOO)

I would have expected it to desugar to something like:

foo({
  const TMP: i32 = 1 + 1;
  TMP
})

But I can’t seem an explanation why the struct with impl is used. I wonder if it has something to do with propagating generics.

I don’t think OpenTofu is accusing them of taking any code from an incompatible license. Just saying that both parties did the same thing.

IIUC all past Terraform code was copyright assigned via a CLA. This is what allowed them to re-license in the first place. So even if the previous code was offered under an incompatible license they own the copyright so it doesn’t matter.

I wish they had a feed for posts like these. Their mail feed is mostly release notes but sometimes they post great articles like these and I would love to subscribe.

No, you won’t lose anything. However do be aware that unless you specifically configure different data directories using the same DBMS in multiple projects will use the same underlying data files.

Typically this won’t be a problem, and you can just create different logical databases if necessary.

Everything basically.

• Ricochet Robots solver.
• A CLI tool to add timestamps and time since last log annotations when watching logs in a terminal.
• A few random games.
• RSS to Email service.
• Making a CRDT library that embeds well in programs.
• A tool for uploading journald log files to log aggregation services.
• Some machine learning experiments.
• A tiny library to implement rate limits.

In general Nix doesn’t manage persistent data. It will be stored in whatever location the tool writes it to.

nix-shell is a very simple program. Basically it downloads/builds the package you have configured, then sets up environment variables like PATH to include that package. It would be similar to downloading a pre-built tarball run running ./foo inside of that.

For most built-in modules this will be /var/lib/foo for a service foo. If you run nix-shell the service will write data wherever it would normally write data on any other distribution.

pthreads is fine and widely supported. I would probably recommend that interface for now. Maybe after 5 years or so when all of the LTS systems support the new standard that will be the better option, but all major OSes are POSIX compatible so no need for a new standard anyways.

Also if you want to take advantage of any OS-specific extensions they are probably supported by pthreads, but the new C threads API will probably lag.