i-use-nixos-btw

I don’t even think it’s a forecasting issue at this point. It’s a lack of a plan B.

In this time they could have launched new products that make the most of available supply. They didn’t.

They could have recognised the hit that their b2b-first distribution model has had on their reputation and tried to make amends. They didn’t.

They could have coordinated with the alt-board suppliers to make “RPi approved” models for the Rock Pi, Orange Pi etc as a stop gap. They didn’t.

Hell, they could have bumped costs up a bit to spend on mitigating supply issues, reduce demand and burn scalpers. They didn’t.

So instead they just keep promising, just keep delaying, and we keep waiting. Even if their supply issues are through no fault of their own, it feels like they aren’t even trying.

Completely unaware of this social network. What problem, exactly, is a blockchain based social network trying to solve? Proof of origin? A conversational paper trail?

The latter would be interesting for areas where conversations should be on the record, however in cases that people want their conversations off the record they’d just use a side channel. The UK govt communicates using WhatsApp for Christ’s sake.

So it’d need to be something where both parties fundamentally benefit from the ability to verify that a post, or a conversation, took place. Where would that even apply?

Not a direct answer. Just some advice from someone who has tried and failed at blogging, and can’t help but wonder if this question is being asked for the wrong reasons.

I’ve had several blogs in the past that all died out because I didn’t have the time (or couldn’t be bothered) to keep adding to them. If you don’t have a plan for a continued theme, regular posts, plans for when ideas dry out, then it’s a non-starter. Sure, you can maintain it for a long time if it’s just for personal writing, but you’ll only do so if you aren’t chasing popularity.

My mistake in the beginning was being a perfectionist - trying to write the killer post that made me an international blogging superhero or something. And one or two did see a lot of traffic (at cost to me) for a short while, but didn’t create engagement. The time and effort that went into it was just not worth it, and the low frequency of posts (because of the overhead I’d added) was what made people fail to stick around.

What I found was that it didn’t matter about making one awesome post. What mattered was regularity - twice a week without fail.

If I couldn’t think of anything to write about I just looked at recent commits to projects that I followed and painted an obviously-contrived arching theme to the direction of the community. “so you can see that there is a growing frequency of PRs that focus on the build system and testing, rather than core functionality. Is the community entering the get-your-shit together phase?” - post it under the title “Developers are getting their shit together. What does this mean for you?”. Done. Half an hour, easy peasy.

By keeping up the regularity, people were more likely to click. Perhaps it was that they’ve seen the name of the blog a few times and their intrigue has grown. They were also more likely to click onto other articles when I sorted out a decent tagging system, and once they had seen three posts on a single visit their chances of sharing posts, commenting or visiting the RSS feed skyrocketed.

The thing is, this was a long time ago in the 2000s. Things have changed big time, and not in a good way, when it comes to blogs. People don’t subscribe to blogs any more (well, it’s rarer), they subscribe to PEOPLE who sometimes SHARE blog posts they find interesting. If I were to try again (which I won’t - I’d sooner start doing YouTube videos or something), my aim would be to be noticed by the influencers (10k+ followers) in the right community.

That’s my 2c anyway.

Yeah, this is where I’m completely lost. You don’t need to do much use a webcam in two applications at the same time. If you want some additional features VLC can handle it easily. If you want the bells and whistles then OBS. All FOSS.

So I don’t understand the value add - is it used for more than is being described, or if there’s legitimately a piece of software that does something so trivial yet people are actually paying for it.

This sounds like a lot of fun! It’s also great that you’re encouraging this - having a passion is great, and following it through to this level is fantastic for development.

I have a question. When you ask an LLM to summarise the rules of the language in a concise manner, and it does so, is it… disheartening?

I mean, if you put a lot of work into creating something, and it gets described in terms that basically make it feel like a configuration - given a glossary and a set of toggles and fill in the blank settings (e.g. word boundaries), out pops a language.

Does seeing that make it feel somewhat less exciting?

I am not satisfied with the other answer, because while it is correct I don’t think it makes the distinction clear enough. So I’m gonna ELI5 it, dumb it down far more than you need it to be, because it gives me the chance to make silly metaphors.

The atom that they found - let’s call it Bob - was, for all intents and purposes, created.

The discovery isn’t of Bob. He’s cool and all, but he doesn’t stay around for a long time so there isn’t much that he can pers… atomly do for us.

So what’s cool about Bob that we can record and know for later? Well, there are two things to point out. First is that Bob stuck around for a while. The second is that Bob is governed by the laws of physics.

Therefore an atom with the same properties as Bob can, according to the laws of physics, stay around for a while. That’s the actual discovery.

Well, this discovery can be summarised more succinctly than “we found that things with the same properties as Bob can exist for a while”, because the name for the class of all things that have the same properties as Bob is the isotope Uranium-241.

Now, we can say that Bob is Uranium-241 just like we can say that I am a member of the human race, but just like we can’t say the human race IS me, we can’t say Uranium-241 IS Bob. Uranium-241 is the mere category of things that we know Bob was one of.

If aliens created a wormhole that accidentally sucked you away to their planet and they saw you, did they discover nonethewiser? Or is it more profound that they discovered the human race?

Same goes for this. We can say that we discovered Uranium-241 (which is shorthand for “we discovered that Uranium-241 is stable enough to survive long enough to be measured”). We did so by creating Bob, which merely acted as proof.

It’s a shame, then, that this has scammy written all over it. Never heard of the bloke but if this is legit then he needs to fire whoever produced this writeup.

Completely agree.

The lesson I learned was to not buy generic brand stuff from Amazon. The one I have is dreadful. The temperature dial is meaningless, the grip gets hot with the iron, and the tips that come with it* are absolutely awful. Even at low soldering temperatures they can’t take the heat, and at this point all of them have their cracked, chipped, or have otherwise become completely blunt.

But hey I got a nice generic tool bag full of wires that don’t conduct, insulation tape that doesn’t insulate, tiny screwdrivers, blunt snips, and “lead-free” solder that absolutely has lead in it.

* and it seems to be a fitting that nothing else will fit apart from the rubbish tips that come with a thousand other almost-identical generic soldering irons you can get from Amazon.

Meh. I feel like there needs to be an active movement to assess programs that have huge scale (>10m users) to identify unnecessary power usage - whether it be because of a bug, because of unused functionality that nonetheless takes resources, or intermediate steps that take unnecessary power.

Perhaps I’m getting into a bit of a niche here, but the rise of stringy formats for data transfer concerns me. There are many-stage pipelines on machines that agree on what a 64 bit integer is, yet each stage performs encoding and decoding of JSON twice (decoding upon receipt, encoding to pass it on to the right place, decoding the response, encoding it in another manner to reply to the original sender). Sounds like a minor concern, but the scale of this instinctively feels like it’d dwarf 250MW globally.

On the other hand, without the click bait titles and other YouTube algorithm hacking, how many of us would have watched it?

I’m happy having watched it. The argument about particles travelling at light speed and then suddenly having mass and travelling below light speed is one that I haven’t heard before. The note about 0/0 being finite rubbed me the wrong way, but I see the point.

It’s quite rare for a theory to be dismantled so thoroughly that we look back on it and say “oops, all of that was just coincidence”. Rather, the existing theory is a special case of the one that replaces it.

For instance, Newtonian physics wasn’t demolished by Einstein et al. It was refined, such that Newtonian physics applies very well in scenarios and scales that we would consider ordinary.

But you are completely right. When the theories are unified then people could very well be saying “you can’t just add these states together”, just like I’d often say that when talking about adding speeds together (it doesn’t convince the traffic officer). What I do think, though, is that a perfectly good response to that will be “ah, yes, that isn’t a problem though because this isn’t in the presence of a magnetic, rotating, supermassive black hole with a funny hat on, so the flopookle correction we learned about in physics 201 is negligible”

I’m wondering how sustainable this is.

Tech firms are throwing billions at this at the moment, and will continue to do so for a long time. As soon as faster tech emerges, they’ll upgrade - they don’t need to justify it to the public, and justification to shareholders is pretty easy. “We’re trying to secure our position at the forefront of a competitive market”.

Would a publicly funded project be able to keep up with that? Or would there be a big upfront cost, only to find that their technology is in the Stone Age five years from now?

With CERN it makes a lot of sense. There isn’t a vast market out there for it to compete with - just a few organisations that they collaborate and “compete” with. But trying to join the big spenders seems risky.

What am I missing?

When I look at the image with the dots, I feel that my eyes are using the ratio of black to white as a low resolution “feature” that my brain is acting upon. So is it that my eyes are mainly providing already scaled information, or is it that my brain is choosing that information as the most important thing to act on? When it comes to fast decision making (which herd to target for hunting, which side of the hill do I run down to escape this predator) I’d kind of expect that the brain is hardwired to act on low resolution information quickly and process more detailed information at leisure.

I think the same goes for neural nets. Numerical features are often provided in some scaled manner anyway (e.g. not “how many cents has this stock price fallen in the last second” but “what is the ratio between the price now and the price a second ago?”, or even “what is the ratio of the stock’s price change in the last second, represented as a number of standard deviations from the mean in this background data?”.

And then there’s the fact that a (useful) neural network isn’t linear to begin with (if it was, it’d just be a simple matrix transformation). Each layer has an activation function. None of those I’m familiar of are even remotely logarithmic, but e.g. tanh and sigmoid functions are more sensitive to small changes at values near 0 than values far from zero. Perhaps over many layers it kind of resembles something kind of logarithmic? IDK

In favour of Nix.

In Nix, the sequence of events that lead to your build are figured out on the language level. A build is this sequence of events.

In Starlark, you have to do things in a specific order - and that can get messy. It has a bunch of built-in phases that mean WORKSPACE, .bzl and BUILD files all have different levels of ability. A workspace can define a dependency (e.g. a http_archive), load a file into bazel, then call a bazel function from it. If you want to do that outside of a huge unmaintainable file, you have to break the steps down into multiple bzl files - one that does the download, then another that loads the dependency and calls it. And then you can call the latter from your workspace. BUILD files can do neither of the above and can only really define builds. So you end up with awkward file arrangements to load the right dependencies.

In Nix, anything you evaluate is a Nix variable. A function is a variable, a derivation (target) is a variable. You can refer to it natively and do what you want with it.

In Bazel, everything is referred to in a global register via labels, which are just strings. If you want two versions of the same thing that are the result of a function call, you have to give them different labels, so you can end up screwing around with string manipulation to generate unique identifiers.

This also feeds into a deeper issue. Bazel loves its global registry. Names from your dependencies are also your dependencies - so if the author of a project decides it hates the users and wants to enforce a “com_github_owner_repository” as its workspace name (because who doesn’t love Java-style conventions), you’re stuck using “@com_github_owner_repository//:library” throughout your codebase, anywhere you rely on that dependency. And to load in that dependency’s own dependency, you have to either load a special file and run special functions that the author provides, or you have to copy a bunch of code into your WORKSPACE file, making sure you give things the naming conventions used within the dependency.

In Nix, you name things whatever you want. If something you depend on has dependencies, it manages them itself - you can override them if you want.

Bazel doesn’t have much of a registry of third party repos. The onus is on you to scour the web, find an archive you want, grab the hash, and sometimes write your own build file to explain how it gets put together.

Nix has a truly vast repository of dependencies, which can be library dependencies or programs (in the latter, it’s the largest repository of applications out there - bigger than even debian and arch provide).

Bazel is maintained by Google, and maintainers make it very clear that they are spread thinly and don’t enjoy doing it. Some projects are completely stalled due to lack of maintenance. When bugs are found in the internals, they don’t get fixed for a long time. It’s based on Blaze, just like VSCode is based on Visual Studio, and there’s a feeling that it is being held back when things that could benefit users would be incompatible with their own system. There’s always the looming apprehension that Google are going to abandon it as soon as the next shiny thing comes along, or as soon as the people who work on it get promoted. Want to submit a PR? Sign this agreement first, then we might look at your PR, then we might merge it, might say no, but (note: speculation) an eerily familiar yet unattributed push might arrive a few months later from a googler.

Nix is full FOSS, with the standard open process you’d expect.

In favour of Bazel.

In Bazel, because you’re expected to follow a certain flow, errors are friendlier and easier to figure out. Bazel knows what you’re supposed to be doing and can help. When it builds things and fails, the intermediate files are saved in an easy-to-find place within your local directory (as a symlink) so it’s easy to explore and figure out the issue.

In nix, a derivation (target) truly resolves down to the tiny operations that put it together. It doesn’t know what you’re trying to do with it, so a typo at the topmost definition of a derivation can end up giving you horrific errors about low level list operations. If an error occurs in the code you’re building, intermediates can be found by copying a huge nix store path from the terminal and navigating to it, but it is a laborious process.

Starlark is based on Python, and it’s familiar to a lot of people. The overhead of learning the language is just a case of “oh it’s Python but without X, Y, Z, and… without fstrings!?”.

Nix is an entire language, with its own conventions, its own library, and its own syntax. It’s easy enough to learn if you’re used to picking up new languages (and honestly is one of my favourite languages now), but that’s an overhead. Most people think imperatively and eagerly, and nix is functional and lazy, so it can be hard to figure out how to accomplish something.

Bazel has an actual build system. It has native support for a bunch of languages. Nix is very much DIY - if you’re using make or CMake then the mkDerivation can do a lot of things for you, but for a developer using the two technologies together is unpleasant. We went as far as making our own build system in Nix that invoked e.g. gcc directly rather than try to work with cmake.

I get incredibly frustrated with popular science articles that use only artist’s impressions and avoid the real images.

To me, the real images are much more exciting. You don’t need fake clarity and fake colour when you’re seeing a (candidate) high speed black hole sucking the life out of some fricking ginormous balls of flaming nuclear fusion.

> One is a component specified by international standards

That just means that vendors should provide something that matches the specification. Usually it also means backwards compatibility guarantees, which is moot with external repos when you can stick to a revision if something breaks.

But hey, don’t worry, we’ve got std::format and soon we will have std::print. So you can keep to the standard library if you wish.

The implementation is inferior to the fmt library itself, though. An addition to fmt is a commit away - an addition to std::format is four bikesheds, three defect reports and six revisions away before it may find itself into the standard in 3 years). It has much more exposure to a much bigger and more diverse community before it hits a major version than the standard gets.

> You gave zero reasons

Just to provide the full paragraph:

> And thus far, that best tool is fmt. The syntax is cleaner, it’s more configurable without horrible side effects, the resulting operations are more efficient, and as a project it is still being actively improved over time.

Configurability: check

No horrible side effects: check

Resulting operations are more efficient: check

Under regular improvement: check

Those are my reasons. If any “pro” work negates using good tools, then I pity it. I use a range of third party libraries in my work (no, not just hobby projects - and no, not a small project) and it is a major plus.

You are entirely correct: I do not understand the argument - or, rather, the relevance of it in any applied situation.

In effect, my argument is that in order for you to require it to understand something, you require it to understand that thing for a reason. If it acts like it understands that thing under all probing, then your requirement is satisfied - the question about whether it truly understands the thing is moot, because it fulfils the requirement.

The emphasis on “for all intents and purposes” is important. If you specify requirements you specify them for your intent and for your purpose.

Requiring that something fly and that something be a plane are two different things with only minor overlap. If all you require is something that flies, then a dragonfly matches your requirements exactly as much as an apache helicopter does.

To some, the bigger picture of what could be possible includes using multiple languages, multiple build steps, etc.

Refining individual ecosystems to be effortless to use is one thing, and it’s a goal worth pursuing for the benefit of those who are happy in that ecosystem. For those who rely on bringing different technologies together, though, there can be a lot of complexity and nuance.

The point of these projects is to take that complexity and nuance and provide an effective “super ecosystem” to piece them together in. That’s why some of the biggest proponents of these technologies are Google and Meta - they have many interacting parts in many different languages that need to come together and work effectively.

If you only use one language, and that language has a reliable, reproducible build system that gives you the guarantees and functionality that you require, then not much.

Here’s how I used Bazel (and how I now use Nix).

I am provided a configuration file that specifies what a given instance of my program must do. I use language A that can natively understand this configuration to code-generate a file in language B (which is significantly more suited to the performance requirements of the program)

This file is then built along with generic program code. It is used to process a lot of data.

As an interface to this program, I have a HTTP interface that can communicate with it. It needs to understand the kinds of outputs the program will produce, so some of this HTTP interface is also code generated in language A. The interface is interactive so typescript is generated and then compiled too.

In order to process the output from the program, I need to produce extensions for languages that users of the output use: Python and R. These need to understand the kinds of data being used, so are also code generated - then built. They’re then tested against requirements defined by the config (so the tests are also code generated).

Each of these stages have dependencies required when building and dependencies required when running, and there are several languages involved.

I also need to be able to express the entire process as a function, because it’s something that needs to be run very frequently on different configs - sometimes in collections of configs that need everything built at once. It needs to be build on several different machines, sometimes desktops and sometimes remote servers, sometimes on clients’ hardware (depending on the needs). I need confidence that something that works on my development machine will work, in entirety, on a completely different machine with minimal prior setup. And I need it to be easy to do, easy to maintain, and I don’t want to mess around with many different build systems that have entirely different use cases, entirely different ideas of how build/runtime environments should be handled, entirely different languages to configure them - and many of them are rigid and don’t have a concept of functions, they’re just “state your dependencies, kthxbye”.

All of the above is absolutely trivial with bazel if you know where to tread lightly (e.g. surrounding Python environments). It’s also very easy with Nix once you get used to it, and you don’t need to tread lightly there - it has stronger guarantees.

I used Bazel for a long time, in a small team (5). No spring/react for me, but we have ~100 external dependencies across 5 languages. It was generally positive, certainly better than any system we used beforehand, and multi-language stuff was great, but the learning curve was steep and it had annoying defaults (which we soon wrapped with our own).

Regarding 3rd party packages, if you update them regularly and they are depended on by intensive builds, that’s going to be the reality in any build system worth using. A build is a DAG and if one node changes then it’s children must too, if you want any guarantee that the update isn’t going to break fresh builds. As with any build, if you want fewer rebuilds you need to be diligent with assigning dependencies to things that need them (so unrelated things don’t rebuild), and when things can be divided and conquered then they should be.

Bazel it isn’t perfect at reproducibility and thats what made me abandon ship. It isn’t perfectly sandboxed, for instance - it still uses your system compilers, still has access to your system libraries. This means that you can accidentally depend on something without specifying it, which violates my requirement for true reproducibility.

These days we use Nix, which is ultimately a better environment for developing reproducible builds if you’re happy to shun Windows. It is also a superior language to Starlark IMO - declarative makes much more sense than imperative in something that has to later resolve to a DAG. In terms of using it as a build system, it’s lacking unless you put in the legwork. The default is to use other build systems within Nix, but that leads to a lot of unnecessary rebuilding during development, so we just span up our own Bazel-like library for Nix to do the heavy lifting.

Yes, in this instance I understand failings of today (though copilot has a much better hit rate, and at the moment it’s a great augmentation to coding if you treat it like an enthusiastic intern).

My question is about the future. The argument goes that a machine can never understand Chinese, even if it is capable of interpreting Chinese and responding to or acting on the input perfectly every time. My reply is that, if it acts as if it understands Chinese in every situation, then there’s no measurable way of distinguishing it from understanding.

It’s kind of like the whole string theory vs SUSY vs… argument in physics. If the only outcomes are things that agree with the Standard Model in all measurable aspects, and don’t provide any measurable distinction, then for all intents and purposes they don’t matter. That’s why their active areas of research are looking for the measurable distinctions.

FWIW, supersymmetry models predict measurable things (that so far have only ruled out those models when tested) but have applications elsewhere. String theory research has had implications in mathematics, condensed matter, and a bunch of other places. They’re useful.

But that’s beside the point, because the premise of the Chinese room problem is that there exists a machine that passes all scenarios, where no measurable difference can be found, and that this machine does not understand Chinese.

I’d be interested in hearing from anyone who takes the Chinese Room scenario seriously, or at least can see how it applies to any of this.

I cannot see that it matters if a computer understands something. If it quacks like a duck and walks like a duck, and your only need is for it to quack and walk like a duck, then it doesn’t matter if it’s actually a duck or not for all intents and purposes.

It only matters if you probe beyond the realm at which you previously decided it matters (e.g roasting and eating it), at which point you are also insisting that it walk, quack and TASTE like a duck. So then you quantify that, change the goalposts, and assess every prospective duck against that.

And if one comes along that matches all of those but doesn’t have wings, then if you deny it to be a duck FOR ALL INTENTS AND PURPOSES it simply means you didn’t specify your requirements.

I’m no philosopher, but if your argument hinges on moving goalposts until purity is reached, and your basic assumption is that the requirements for purity are infinite, then it’s not a very useful argument.

It seems to me to posit that to understand requires that the understandee is human. If that’s the case we just pick another word for it and move on with our lives.

You do not need a very good reason not to. This ain’t the 90s, so whether something is in the standard or whether it is from a third party is broadly irrelevant. It’s just a question of picking the best tool for the job.

And thus far, that best tool is fmt. The syntax is cleaner, it’s more configurable without horrible side effects, the resulting operations are more efficient, and as a project it is still being actively improved over time.

As far as I’m concerned, iostreams are deprecated.

(This is a little tongue in cheek, but seriously, fmtlib and libscn surpass iostreams in every conceivable way)

Wait, people still include <iostream>? In 2023?

This is written with quite a lot of hyperbole.

The predominant focus is realloc(pre,0) becoming UB instead of what the author misleadingly describes as useful, consistent behaviour. It is far from that, and that’s the entire reason that it was declared UB in the first place: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf. Note that this wasn’t a proposal to change something, it’s a defect report: the original wording was never suitable.

The second part is the misconception about the impact of UB. Making something UB does not dictate that its usage will initiate the rise of zombie velociraptors. It grants the implementation the power to decide the best course of action. That is, after all, what they’ve been doing all this time anyway.

Note that this deviates from implementation-defined behaviour, because an implementation-defined behaviour has to be consistent. Where implementations choose to let realloc(ptr,0) summon the zombie raptors, they are free to do so. Don’t like it? Don’t target their implementation. Again, this isn’t a change from the POV of implementers - it’s a defect in the existing wording.

In this case, the course of action that any implementation will choose is to stick with the status quo. It is clearly not a deciding factor in whether or not you embrace the new standard, and to suggest otherwise is dishonest, sensationalist nonsense. The feature was broken, and it’s just being named as such.

A well-informed electorate isn’t a prerequisite to democracy. This is precisely why fake news proliferates - it’s relatively easy to elicit an emotional response, and that tends to win over critical thinking.

While fake news and undue outside influence absolutely must be protected against, the line is hard to draw. For instance, would Snowden have been considered undue influence, would Wikileaks have been considered fake news, at least sufficiently enough to cross the ban threshold?

There are pros and cons to both approaches, and it really doesn’t come down to whether or not people agree with a statement that contains such vague terms. It comes down to interpretation of those terms.

Hikikomori vibes do make sense, but there’s a caveat: Work and social life are not the same thing.

Companies showed their ignorance of this when the political response to Covid switched to downplay mode and companies tried to lure people back with pizza and games. The cringe factor there is extreme.

I understand my colleagues. I empathise with them. I work with them effectively and in general I bear them. But like them? God no. They’re not my friends.

I am no hermit. I have a wife and kid, and would trade spending time with them them every morning and evening over any job on the planet. When I commuted I’d leave before they wake up and get home after my kid goes to sleep - that, to me, is the definition of an isolated existence.

There’s another aspect of this, one which has been an issue for centuries and an extreme issue for decades: location.

Many cities formed as a result of useful geography. In the UK, at least, that reason is often water-based transport. These locations meant that large scale transport of goods was practical, as well as the ability to have all of the resources necessary to sustain large populations in those areas.

In the modern day, at least in the UK, cities are much less practical. Getting anywhere in them is a pain - road links are too busy, rail is extortionate and over-subscribed. And why are they so busy and expensive? Because everyone has to do it. Why? Because that’s where the high paying companies are. Why? Because the way it has always been done. Why? Because… the place has links to good waterways?

And what do you do when you get there? The same damn thing you’d do at home, but in a noisier and less comfortable environment. You can speak to the same people you could huddle with in Slack, except there’s no mute button. You’re bombarded with a brightly lit, white, open plan room, which could only ever have been popularised by people who don’t understand what a productive environment actually is.

Like many on here, because we have a certain affinity for the tech sector, I have ADHD. I am extremely productive when I’m in an environment that allows me to shut out everything else and focus on what I need to do. Working from home unleashed a level of productivity I wasn’t aware that I was capable of, and once you’ve got that buzz - you aren’t going to let go of it without resistance.