kevincox

RSS is no simpler. And in fact when you have to take account the ambiguity of different clients interpreting the sloppy specification differently it just gets more complex.

Even the trivial case of trying to include "&" in a title is ambiguous and different clients will handle it differently.

At least in the past it was GLM-4.6. IDK if it is ever changed.

https://github.com/anomalyco/opencode/issues/4276

Scrolling on desktop is also broken.

This seems like a great option for local usage. With 16 GiB of VRAM on the official (https://huggingface.co/poolside/Laguna-S-2.1-GGUF) Q4_K_M quant (which seems to be recommended) I can get about 50 t/s in and 10 t/s out. Definitely not winning any speed benchmarks but totally usable for background tasks.

The intelligent and decision making looks good overall. It seems to roughly compare to unsloth/Qwen3.6-27B-GGUF:UD-Q8_K_XL while being way faster on my hardware. It does often get stuck considering the same decision over and over again but maybe this is how it makes the better decisions.

However it does seem to have a bad habit of corrupting things (most often my name). It will rewrite kevincox to kevinc or kevcox or kevancox. Then fail to read directories or rewrite code with the wrong string and mess it up. Then it can't identify it's mistake.

Maybe I'll have try try out the Q8 model, but the description seems to push away from this one.

Wow an LLM hallucinated? What a novel discovery.

See also why houses are often painted when being staged for selling just so that the new purchaser can paint immediately after with their preferred colour. Wasteful but it works.

In minesweeper you start with nothing visible and explore while avoiding the bombs. In this you start with all of the hints visible and place the bombs.

However in practice it is very similar since identifying where the bombs are to not click them is exactly the same logic as identifying where the bombs need to go. The only functional difference ends up being that all of the hints are visible upfront rather than needing to discover them.

Traversing a linked list is terrible for performance. But in cases like the cache you are only poping from the front, appending to the back or removing which are all quite fast and require little pointer chashing.

Cache cost of individual allocations can be an issue but that can also be mitigated with a good allocator and even without special care can be quite performant in many applications.

I agree the linked lists shouldn't be the first structure you reach to. But there are situations where they can perform very well.

.eu is an exception as it is for the European Union but they don't consider themselves a country.

I am not a huge fan of most of these, but a few do seem useful.

    : "${1:?missing argument, aborting!}"

I wouldn't use this because I would want to give $1 a name for the rest of the script, so I would assign. But it can be a nice way to give a clear error for missing required environment variables.

Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in useful if you are going to extreme lengths to avoid dependencies outside of the shell.

I think a very knowledgeable reviewer can make a decent guess. But to really know you would need to tear it apart and analyze all of the materials used (maybe the metal or plastic has been swapped to a slightly different material which is very hard to identify by just looking or touching). You need a team of engineers. Probably the best you can hope for is noticing a part is changed and make an educated guess why it was changed.

Not to mention that tying your insurance to your job is a *huge* pain. If you switch jobs or get fired you need to deal with coverage gaps, considering individual coverage for the duration, and you may need to switch care providers depending on what your new coverage is.

It is just a really awful system overall.

> and advertisements (and even review sites!) almost never address it properly

The thing that annoys me the most is when the reviewer opens the box, shakes it gently and says "feels well built" or "plastic build". It is actually harmful. Weight doesn't equal quality (there is some correlation, building well often results in more weight, but it is unreliable and easy to game) and plastic is a huge range of materials and some are absolutely the most robust option for many use cases (think a sturdy plastic water bottle that outlasts and glass or metal equivalent).

The problem is quality is very hard to measure. The only really good test is to use the product for many years. But by that time the existing model hasn't been sold for years, in theory you could correlate the new model's quality with the old one but brands are apparently disposable these days so it is very likely that all costs were cut on the new one once their previous model gained a reputation for quality.

I think the only real measure for quality is a warranty. That is the manufacturer promising a lifespan. However they are usually short, can be unreliable to get (often at manufacturer discretion) and more often than not cover only "manufacturing defects" not reasonable wear and tear.

While that is true the bigger issue is that LineageOS doesn't qualify for "They do not break the AOSP security model" as it allows users to get root access without modifying the OS. So even if there was verified boot Roblox would still block it.

For me this means that Roblox's requirements are fundamentally incompatible with any device I would want to use as they want to restrict my access and I want full access.

If anything this distillation is more ethical than the original as it is on machine-generated content rather than copyrighted human-labour products.

I'm strongly in favour of this. I think income tax should approach 100%. So your second billion you still make more. But not twice as much. The exact decay function is up to date. But I really don't think your post-tax take home should scale linearly with your income once you hit the max bracket.

We can also remove all of the loopholes that result in the biggest companies paying basically no taxes. I also think it may make sense to have a dramatically different tax structure for businesses than effectively income tax.

The problem isn't that we are gaining more knowledge and better technology. The problem is that we are allowing the rich to use the technology to subjugate the majority.

If AI improves human productivity so much that millions of people no longer need to work that should be an incredible thing. But the flawed structure of our society punishes those people rather than freeing them to persue endeavors that interest then.

Dead-man's switch means triggering when something doesn't happen. (The name comes from a switch that an alive operator would need to hold in such a way that if they died they would stop holding.) So in this case she means that her monitoring will fire if there wasn't a successful backup within some configured period of time.

I assume this is opposed to alerting when the backup job fails, which is an issue if the job never runs, or hangs forever, or crashes in a way that doesn't trigger your monitoring.

However I don't see how any of this solves the issue of not testing your backup. Because you can definitely have a backup task succeed regularly but the thing it is backing up is still unusable.

A USB drive with FLAC files works pretty well. It doesn't have the same feel as a CD with art though.

For movies there isn't a legal way to acquire proper files unfortunately.

But even that isn't the whole story because the models can produce wildly amount of thinking output as well as regular output for a similar query. Sometimes you can take a cheap model and have it think a ton or an expensive model that thinks little and get similar results. But the number of tokens generated will be wildly different.

I think 10 t/s output is usable for many coding workflows if the input speed is much much higher (~100 t/s is a rough minimum line). The low output speed can really hurt for heavy reasoning output but it can still be used to get some jobs done as long as you don't expect highly interactive use.

Because the web browser can't make arbitrary network connections. Even if it was implemented intercepting at the HTTP layer (which would probably be much more difficult than just intercepting the low level socket operations) you wouldn't be able to properly manage CORS headers, cookies and various other things.

Yes, I especially see this in code comments. You will get a PR where the comments reference an approach that wasn't the previous state and isn't the state of the PR. You can basically hear the dev telling Claude to take a new approach and now it is so fixated on the old approach being wrong that it litters the whole patch with traces of it despite now being irrelevant.

It reminds me of https://silverspaceship.com/static/

In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.

Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.

I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:

1. Slap a reference count on it.

2. Use `unsafe` to promise the compiler that your code is right.

I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.

Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.

It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.

For me it is a mix. I mostly get my content from feeds. But I also aggressively prune my subscriptions so that I catch up, I don't have so much that I fall behind.

When I do catch up in happy to burn a bit of time on Hacker News, Lobsters or Lemmy. But if I like an article I usually subscribe to the feed. So this discovery is an important part of my system.

The algorithmic options can turn into doom scrolling if I'm really bored or similar but since I am not checking too often to start and I am decent at identifying it it isn't a problem for me.

The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case.

I have seen multiple major production outages in Golang code because people accidentally read a non-existent map key and used the default value. As a funny bonus in one of those cases we were stumped when debugging because this code had tests, but the tests were also reading the default values out of the map and asserting that "" was in fact a valid textproto (it always is!) so silently testing nothing.

So even if defaults are useful 9/10 times that 1/10 is so painful and expensive that it isn't worth it in my experience. The time spent responding to, debugging and fixing those outages far, far outweighed the time saved by the convenient default values in the 9/10 times.

Or even better, just let the website return a set of flags (like age_rating=18) in a header and let the user agent decide if it wants to show it, block it, ask for approval, ...

Then the policy lives on the user agent.