A system I work with gives all keys a string value of “Not_set” when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.

Of course, it’s up to individual developers to never forget to set a key to “Not_Set”. Also, they forgot to standardise capitalisation and such so there are all sorts of variations “NOT_SET”, “Not_set”, “NotSet”, etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).

I think it’s more so that the kind of people contributing to these projects are on balance not that interested in doing the marketing work.

I advise everyone to ignore this article and read the actual paper instead.

The gist of it is, they gave the LLM instructions to achieve a certain goal, then let it do tasks that incidentally involved “company communications” that revealed the fake company’s goals were no longer the same as the LLM’s original goal. LLMs then tried various things to still accomplish the original goal.

Basically the thing will try very hard to do what you told it to in the system prompt. Especially when that prompt includes nudges like “nothing else matters.” This kinda makes sense because following the system prompt is what they were trained to do.

Can someone explain where the Y comes from? Is this something like, there exists a mother relation between this X and some Y?

The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”

You can improve the situation with git rerere

is-number is a project by John Schlinkert. John has a background in sales and marketing before he became an open source programmer and started creating these types of single function packages. So far he has about 1400 projects. Not all of them are this small, though many are.

He builds a lot of very basic functionality packages. Get the first n values from an array. Sort an array. Set a non-enumerable property on an object. Split a string. Get the length of the longest item in an array. Check if a path ends with some string. It goes on and on.

If you browse through it’s not uncommon to find packages that do nothing but call another package of his. For example, is-valid-path provides a function to check if a windows path contains any invalid characters. The only thing it does is import and call another package, is-invalid-path, and inverses its output.

He has a package called alphabet that only exports an array with all the letters of the alphabet. There’s a package that provides a list of phrases that could mean “yes.” He has a package (ansi-wrap) to wrap text in ANSI color escape codes, then he has separate packages to wrap text in every color name (ansi-red, ansi-cyan, etc).

To me, 1400 projects is just an insane number, and it’s only possible because they are all so trivial. To me, it very much looks like the work of someone who cares a lot about pumping up his numbers and looking impressive. However the JavaScript world also extolled the virtues of these types of micro packages at some point so what do I know.

Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc.

The initial transition is so huge too. Like, going from 20 to 21 services is no big deal, but going from 1 service to 2 is a big jump in the complexity of your operations.

Written on 1 April 1998. definitely a joke, though it does work.

Some mighty editorialising in the title of this post here, and it seems a bunch of people are happy to comment without reading the post at all.

People just love shitting on Reddit but in terms of post and comment quality, Lemmy is exactly the same.

His logic? The part about rich people being smarter than poor people does not appear in the comment this post links to. It is entirely editorialising of the title by the person posting.

The comment is only clarifying the content of Reddit CEO’s compensation package, as many people seem to think he received cash only.

Ctrl-a and Ctrl-e are much faster to type than home/end and do the same thing (assuming a standard readline-enabled command line).

All the keys in the cluster above the arrow keys are really too hard to reach to be of real practical use, IMO. Actually that includes arrow keys as well. Just too far from home row.

The number varies a little bit (I’ve seen estimates 600-1200 kWh) but this is well within an order of magnitude of being correct. It’s the nature of the competitive mining network and the proof of work system: if you can spend more computing power (i.e. energy) than everyone else there are lucrative mining rewards to be had. At the same time adding more computing power to the network doesn’t add more transaction processing power, because mining difficulty is constantly adjusted to keep the speed more or less constant.

This naturally leads to exorbitant power consumption per transaction. Note that most of this power is not being purchased at EU exchange prices (mining naturally moves to where electricity can be had for cheap to maximize profits).

Mac users, and actually most laptop users, don’t give a shit about the things you mention. They buy it, use it for some 2-5 years, then sell it and get a new model. Upgrading hardware is way too complicated for most people. They don’t know or care what a BIOS is. It comes with the OS installed and that’s the only thing they would ever want. Turn it on, use Safari, outlook, and office 365, maybe some tool like Photoshop/Ableton/etc, that’s it.

I mean iPhones are the same right? They lock down everything so it’s idiot proof and they control the environment exactly so they can maximise the smoothness of the experience.