i-use-nixos-btw

If a company offers some benefit at the cost of some restriction, then users should decide if that benefit is worth the cost. For most Android users, it will be - my grandma isn't interested in the freedom of indie devs to develop for her phone, she's interested in not accidentally installing malware.

I don't like that as much as you don't - for my own devices. But like anyone else who cares about that, I can root it and get past the digital nanny state.

As soon as that is added, people will start to try to optimise their profiles to place them high in the list on certain things, rendering the tool pretty much useless.

The talent people want to find in the talent that doesn’t do everything in its power to say “hey, look at me, I’m talent”, but just… well… does things.

I haven’t used UV, but it says that it manages python as well as packages - I’m guessing like conda, python-venv, and of course nix does.

If the C api is an issue, it sounds like you have control over it if you need it. You manage the python distribution, so could it be patched?

This way it feels like you’d be able to establish not just what is being imported, but what is importing it - then redirect through a package router and grab the one you want.

This may be particularly useful if you’re loading in shared libraries, because that is already a dumpster fire in python, and I imagine loading in different versions of the same thing would be quite awkward as-is.

There's a 50/50 false positive rate, but I can deal with that. It means looking at 10 papers to find 5 useful ones instead of looking at 1000 papers to also find 5 useful ones.

I'm impressed.

Until then, things are not looking great. When one mod deletes threads because they've had a bad day and cant deal with drama, when other mods start teaming up against the only moderate voice for reaching out to ThE EnEmY, when a huge community member get permabanned for merely voicing disagreement with their own temporary ban (which in turn was only because they - wait for it - "encouraged debate"), it is clear that it won't be long before the community turns on them.

Its just a shame that the big forks are ones run by like-minded activists.

- a tmux session can be used by multiple people

- with tmux a single command “tmux attach -t someusefulname” restores the layout and all of the commands used, saving a bunch of time and opportunity for error

- tmux has an API, so you can spawn a fully loaded session from scratch with code, rather than by manually doing things or by having a pre-made session (this is soooo underrated, especially if you make it configurable)

Honestly there comes a point where you just redesign the software and have it run in a more automated fashion anyway, but for the odd job that you have to run from time to time it’s very handy to have tmux as a persistent, shareable, configurable scratch space.

Yes, absolutely doable in Nix.

Derivations are just a set of instructions combined with a set of inputs, and a unique hash is made from that.

If you make a derivation whose result is the invocation of another, and you try and grab the outcome from that derivation, here’s what will happen: - it will generate the hash - it will look that hash up in your local /nix/store - if not found it will look that hash up in any remote caches you have configured - if not found it will create it using the inputs and instructions

This is transitive so any missing inputs will also be searched for and built if missing, etc.

So if the outcome from your process is something you want to keep and make accessible to other machines, you can do that.

If the machines differ in architecture, the “inputs” might differ between machines (e.g. clang on Mac silicon is not the same as clang on x86-64) and that would result in a different final hash, thus one computation per unique architecture.

This is ultimately the correct behaviour as guaranteeing identical output on different architectures is somewhat unrealistic.

These applications specifically because anything that looks at anything on the micro scale includes these as “possible applications”. They sound cool and exciting, and the urge for making them has been around since before Feynman’s Room At The Bottom lecture.

But my comment is mainly surrounding the farce of making a cool discovery that progresses an area of understanding, and then being asked a question that is best posed to engineers: “but what can we do with it?” Wrong field, wrong people, wrong question.

Imagine if astrophysicists were asked these questions. “So you’ve discovered a new kind of star that is made entirely of sponge? What applications do you think will come out of this research?” “Well we hope it will help with Dyson Spheres, Astrology and sea navigation”

Memorizing isn’t a term I’m familiar with in this context.

Nix can be used as a build system in the same way that bazel can. It already has all of the tooling - a fundamental representation of a hermetic DAG, caching, access to any tool you need, and a vast selection of libraries.

The only catch is that no one has used it to write a build system for it in public yet. I’ve seen it done in a couple of companies, though, as using Nix to only partially manage builds can be awkward due to caching loss (if your unit of source is the entire source tree, a tiny change is an entirely new source).

But you speak from sufficient experience that I presume Nix is a “been there, done that” thing for you. What gives?

Everyone who has ever written a grant application will recognise this wording.

I would like to see much, much more in a demo. Probably around 20-30 minutes.

What was shown in the demo video was seemingly the functionality of Dropbox, shown working with one file manager and one OS.

I know it is more than that. I’ve checked your docs. You have branching models. You have cross OS support. You have a lot going on.

But that demo video really put me off. It doesn’t demonstrate anything that seems particularly useful to me, especially on the main selling point: version control. It spends most of the time showing automatic file sync, which (although not easy to do) is a basic feature of so many cloud storage platforms that it doesn’t have the wow factor these days. (It’s also a feature I find annoying and would want to disable, but it seems to be core to your approach so meh)

I know not everyone will jump immediately to the demo video to see it, but it’s what I did, and honestly… I’d scratch it and do a full intro video and put resources into doing it right.

“DAD, YOUR SPRINKLERS ARE HACKING THE RECYCLING COLLECTION TIMETABLES AGAIN”

(spend enough time around places like this, though, and one could easily imagine this being a thing in 2032)

There seems to be this notion that scary titles and overly-simplistic frameworks like this make it more digestible and give it more attention, but I think that’s a big PR mistake.

However, I don't agree that this is the "real" lesson.

Given the costs at play and the risk presented, the lesson is that if you have components that are tested with a big surge of power, give them custom test connectors that are incompatible with components that are liable to go up in smoke. That's the lesson. This isn't a little breadboard project they're dealing with, it's a vast project built by countless people in a government agency that has a reputation for formal procedures that are the source of great time, expense, and in some cases ridicule.

The "trust the 28 year old with the $500m robot that can go boom if they slip up" logic seems very peculiar.

Many years ago I made a bet that Windows as we knew it wouldn’t make it to 50. That they would decide to go the UNIX route and compete directly with Apple and Linux, but allowing the windows ecosystem to be a backstop for software that hadn’t been ported yet.

Instead, the opposite. I absolutely didn’t foresee things like WSL.

For instance, a few months ago I was working on an environment for playing around with some libraries that you’d think would commonly go together. But within the community there are very popular libraries that cannot be used together (at recent enough commits to contain features I want) due to version conflicts.

But as I’m a nix person I obviously try to solve that by going rogue. This was my process before I decided to pack it in and wait for the community to sort their shit out:

1. Pull projects at their latest commit instead. This is the “hope the communities already have their shit sorted out” method. nope, no luck.

2. Write a patch that changes the older requirement. Maybe it is API compatible? LOL no such luck.

3. Write a patch that changes the outdated dependency name to some random name, then add an expression to map the outdated dependency to that name instead. Ugh no, there are version incompatibility with its own dependencies too.

4. Write a patch to update the lib with the outdated dependency to use the new API instead - success! On its own. Now use it together with the other libraries… uh oh.

It has a C++ backend that requires a GLIBC version that is incompatible with that used by the other libraries. It needs this because it needs to be built with a specific CUDA-enabled compiler that is quite outdated now, and if you compile it on a newer version it fails to build because the author hardcoded the compatibility matrix into the codebase with c macros.

So yeah there comes a point where you think “hey I want to try out using some fun tools I’ve heard about” and, before you know it, you’re writing a patch for a dependency that allows you to use a patched version of another dependency that allows you to use a patched version of a dependency that you want to add to your project alongside something else, and at some point you’ve just got to quit and hope that in a few weeks there will be version parity.

It seems like the creator is in a rough patch and faced rising social and financial problems from Omegle, and it has seen a BIT of a decline, but it’s a name we all know, and the image/use/etc can be turned around and the creator could even still be involved in whatever capacity he wishes.

Just seems kind of a waste to replace it with a goodbye page.

It's Speech Recognition -> Llama -> Text to Speech, running on your own PC rather than that of a third party.

The limitations on the context of the LLM are that of the model being used, e.g. Llama 2, Wizard Vicuna, whatever is chosen, in whatever compatible configuration is set by the user regarding context window etc, and given a preliminary transcript (as the LLM doesn't "reply" to the user in a sense, it just predicts the best continuation of a transcript between the user and a useful assistant, resulting in it successfully pretending to be a useful assistant, thus being a useful assistant - it's confusing).

I can imagine that it's viable to get that kind of behaviour by modifying the pipeline.

If the architecture was instead Speech Recognition -> Wrapper[Llama] -> Text 2 Speech, where "Wrapper" is some process that lets Llama do its thing but hooks onto the input text to add some additional processing, then things could get interesting.

The wrapper could analyse the conversation and pick out key aspects ("The person's name is Bob, male, 35, he likes dogs, he likes things to be organised, he wants a reminder at 5pm to call his daughter, he is an undercover agent for the Antarctic mafia, and he prefers to be spoken to in a strong Polish accent") and perform actions based on that:

- Set a reminder at 5pm to call his daughter (through e.g. HomeAssistant)

- Configure the text-2-speech engine to use a Polish accent

- Modify the starting transcript for future runs:

  - Put his name as the human's name within the underlying chat dialogue

  - Provide a condensed representation of his interests and personality within the preliminary introduction to the next chat dialogue

They firmly asked me not to do so and kindly asked me to stop using my plugin.

I complied with the first request. For the second, not so much.

Anyway, the moral of the story is that the DMCA was written to GitHub. Your own local clone is no one’s business.

That’s the opening line, right? Uncertainty is a fact of life. With time series forecasts, the best you can ever hope to do is give probability bounds, and even then you can only really do so by either:

- limiting by the rules of the game (e.g. the laws of physics, or the rules of a stock exchange)

- using past data

The former is only useful if you’re the most risk averse person on the planet, and the latter is only useful if you are willing to assume the past is relevant.

There may be scanners etc but I think your best bet is to ask the security provider for recommendations. They identified the issue and notified you - it sounds like they’re a third party worth keeping around.

In the mean time, assume that creds can be stolen and there’s nothing you can do about it: what do you do about that? You have many options: rate limiting, IP checks, detecting unusual activity. I’d start there.

However the notion that it makes phone numbers and ISPs obsolete is naive in my opinion, as is the notion that it would improve privacy. Quite the opposite. Aside from death and taxes, certainties include that businesses adapt to changing markets, and that privacy is always at threat.