Normal_gaussian

As soon as it is sufficiently complex, it becomes a "trust me bro" switch.

I'm in the UK. I use a pixel, but also have iPhones and iPads for work reasons. My wife has a Samsung, my mother a Motorola etc.

I set up phones several times a year. What the author describes is not a problem if you go "all in" on your manufacturer. iOS or Android.

If you tick the cloud sync functions you can restore apps and copy data with a two or three step wizard. If you pay for the cloud storage level, you will have enough space for your photos etc. it's really a non event.

But if you don't go all in with your manufacturer. E.g you consider Google an untrustworthy custodian of your photos, or decide you'll stick with the free iCloud account etc. You're in for a world of tiny pains.

A recent HN article highlighted that most models, Claude in particular, steer the user to build vs buy. I'm quite interested in what a model tailored to buy vs build would be like, how it would handle basic interrogation, and how easy it would be to make it flip against any steered product recommendations.

In some ways I found this a little surprising; however the final paragraph about real working data not being accessed as randomly as you think is my experience.

I'm curious about ways to live automatically tune this. You can use SET LOCAL to transaction scope a value, yet this would mean managing it completely in your application.

I love myself a little bit of C++. A good proprietary C++ codebase will remind you that people just want to be wizards, solving their key problem with a little bit of magic.

I've only ever been tricked into working on C++...

I know the underlying call, but I always see the redirect symbols as indicating that "everything" on the big side of the operator fits into a small bit of what is on the small side of the operator. Like a funnel for data. I don't know the origin, but I'm believing my fiction is right regardless. It makes <(...) make intuitive sense.

The comment about "why not &2>&1" is probably the best one on the page, with the answer essentially being that it would complicate the parser too much / add an unnecessary byte to scripts.

Is it more sane, or is it just what you are used to?

Python doesn't really have much that makes it a sensible choice for scripting.

Its got some basic data structures and a std-lib, but it comes at a non-trivial performance cost, a massive barrier to getting out of the single thread, and non-trivial overhead when managing downstream processes. It doesn't protect you from any runtime errors (no types, no compile checks). And I wouldn't call python in practice particularly portable...

Laughably, NodeJS is genuinely a better choice - while you don't get multithreading easily, at least you aren't trivially blocked on IO. NodeJS also has pretty great compatibility for portability; and can be easily compiled/transformed to get your types and compile checks if you want. I'd still rather avoid managing downstream processes with it - but at least you know your JSON parsing and manipulation is trivial.

Go is my goto when I'm reaching for more; but (ba)sh is king. You're scripting on the shell because you're mainly gluing other processes together, and this is what (ba)sh is designed to do. There is a learning curve, and there are footguns.

There is nothing here that really tells us the turnstile was security theatre? Or the various key card swipes.

There are many ways to skin a cat; and there are many ways to ensure authenticated / trusted access. If you have site wide security gates, it means you know everyone on site / on a given floor conforms to a given minimal security or trust level, so now you can conduct operations in that area with more freedom. This makes the risk assessments for other actions so much simpler. e.g. Now when the apprentice IT tech leaves the SLT's laptop trolley in the corridor it doesn't trigger a reflash of all of the machines. Or when a key individual misplaces their keyfob (e.g. in the kitchen) it doesn't trigger a lockdown of core systems, because they had it on the way in and its reasonable to trust that nobody stole it.

Obviously the implementation was botched in this case - but "feel secure" and "security theatre" are right as often as they are wrong.

The broker lifecycle is presumably

1. Start

2. Load the queue.json from the object store

3. Receive request(s)

3. Edit in memory JSON with batch data

4. Save data with CAS

5. On failure not due to CAS, recover (or fail)

6. On success, succeed requests and go to 3

7. On failure due to CAS, fail active requests and terminate

The client should have a retry mechanism against the broker (which may include looking up the address again).

From the brokers PoV, it will never fail a CAS until another broker wins a CAS, at which point that other broker is the leader. If it does fail a CAS the client will retry with another broker, which will probably be the leader. The key insight is that the broker reads the file once, it doesn't compete to become leader by re-reading the data and this is OK because of the nature of the data. You could also say that brokers are set up to consider themselves "maybe the leader" until they find out they are not, and losing leadership doesn't lose data.

The mechanism to start brokers is only vaguely discussed, but if a host-unreachable also triggers a new broker there is a neat from-zero scaling property.

When you are doing workshops, particularly teaching something that people are "sitting through" rather than engaging with, you see very similar ratios on end of segment assessment multiple choice questions. I mentioned elsewhere that this is the same kind of ratio you see on cookie dialogs (in either direction).

Think basic security (password management, email phishing), H&S etc. I've ran a few of these and as soon as people hear they don't have to get it right a good portion of people just click through (to get to what matters). Nearly 10 years ago I had to make one of my security for engineers tests fail-able with penalty because the front-end team were treating it like it didn't matter - immediately their results effectively matched the backend team, who viewed it as more important.

I talked to an actor a few days ago, who told me he files his self-assessment on the principle "If I don't immediately know the answer, just say no and move on". I talked to a small company director about a year ago whose risk assessments were "copy+paste a previous job and change the last one".

Anyone who has analysed a help desk will know that its common for a good 30+% of tickets to be benign 'didn't reason' tickets.

I think the take-away is that many people bother to reason about their own lives, not some third parties' bullshit questions.

In which case the %age is notable as it aligns very closely to the effect size on cookie accept/reject ratios. Cookie dialogs tend to fall 70/30 either way.

The original graph appears to simply show the blocking issue of their previous synchronisation mechanism; 10 min to process an item down to 6 min. Any central system would seem to resolve this for them.

In any organisation its good to make choices for simplicity rather than small optimisations - you're optimising maintenance, incident resolution, and development.

Typically I have a small pg server for these things. It'll work out slightly more expensive than this setup for one action, yet it will cope with so much more - extending to all kinds of other queues and config management - with simple management, off the shelf diagnostics etc.

While the object store is neat, there is a confluence of factors which make it great and simple for this workload, that may not extend to others. 200ms latency is a lot for other workloads, 5GB/s doesn't leave a lot of headroom, etc. And I don't want to be asked to diagnose transient issues with this.

So I'm torn. It's simple to deploy and configure from a fresh deployment PoV. Yet it wouldn't be accepted into any deployment I have worked on.

It might be better to view a commit as a natural unit of working code. There are a lot of units of working code which would be tedious to be introduced as a only a few lines.

As such, a new codebase is likely to grow by large unwieldy commits and a mature one by targetted small commits.

I doubt many of us will be able to order one for a long while. There is a significant number of existing datacentre and enterprise use-cases that will pay a premium for this.

Additionally LLMs have been tested, found valuable in benchmarks, but not used for a large number of domains due to speed and cost limitations. These spaces will eat up these chips very quickly.

Have you tried using a more traditional, non-LLM, loop to do the analysis? I'd assume it wouldn't catch more of the more complex deceptive behaviours, but I'm assuming most detections can be done with various sentiment analysis / embedding tools which would drastically reduce cost and latency. If you have tried, do you have any benchmarks?

Anecdotally, I often end up babysitting agents running against codebases with non-standard choices (e.g. yarn over npm, podman over docker) and generally feel that I need a better framework to manage these. This looks promising as a less complex solution - can you see any path to making it work with coding agents/subscription agents?

I've saved this to look at in more detail later on a current project - when exposing an embedded agent to internal teams I'm very wary of handling the client conversations around alignment, so I find the presentation of the cards and the violations very interesting - I think they'll understand the risks a lot better, and it may also give them a method of 'tuning'.

Some of you can draw some pretty amazing abstract horses.

Some of you cannot.

Some of you choose not to.

It turns out he posted a better example in his blog post about it - https://thismightnotmatter.com/a-little-website-i-made-for-a... - which is technically linked to in the bottom of the site. I guess if you spend your life learning UX from Apple this is what you get...

As diabolical as it is, this is kind of fine; this site creates an aggregate stat from the existing status page, it doesn't provide an independent status page.

So it inherits GitHub's world class one-9 uptime.

Operation SNAP is a huge success; but it has issues - one being that it is implemented per police force which means the quality of input and response is hugely varied.

I've reported a few which have gone nowhere, because my local force is useless.

I'm sure they would use a European provider if it was only a minor inconvenience to them; but there is no EU-github nearly done and it doesn't make sense to hamstring this project waiting on it. If this project is successful it will help to justify funding more EU sovereign projects, which will likely include GitHub replacements.

To be clear, your linked map shows that it is not a blanket "in europe". Around 20 European countries don't need an ID to get a SIM card and 30 do.

For those learning about political nuance against the backdrop of current propaganda, it is worth noting that the UK and Ireland do not require registration and that the populous are significantly politically opposed to it; and then Russia requires registration and has one of the most linked up registrations.

If you have the docs, but not the means to (legally) read and edit them, do you really own them?

When MS pulls services you are largely screwed.

When GitHub pulls services its a few hours downtime and a new provider.

The project benefits from the visibilityband community of GitHub and GitHub is completely replaceable with European hosted or self-hostable options should something untoward happen.

Its not.

If you call 119 it gets assessed and potentially forwarded to the right department, which then assesses it again and might (quite likely will) trigger an inspection. The people who turn up have broad powers to seize children from the home in order to protect them from abuse.

In general this works fine. Unfortunately in some circumstances this does give a very low skilled/paid person (the inspector) a lot of power, and a lot of sway with judges. If this person is bad at their job for whatever reason (incompetence/malice) it can cause a lot of problems. It is very hard to prove a person like this wrong when they are covering their arse after making a mistake.

afaik similar systems are present in most western countries, and many of them - like France - are suffering with funding and are likely cutting in the wrong place (audit/rigour) to meet external KPIs. One of the worst ways this manifests is creating 'quick scoring' methods which can end up with misunderstandings (e.g. said a thing they didn't mean) ranking very highly, but subtle evidence of abuse moderate to low.

So while this is a concern, this is not unique to France, this is relatively normal, and the poster is massively exaggerating the simplicity.

This is exactly the issue I bumped into eight or so years ago. I had a ratchet style job that would maintain a file of all of the type issues in the system. Add one, remove one was very common - particularly when it amounted "transform one" so the error change is all on the same line. Note that this is compounded by the errors often showing up quite far away from the code change.

I ended up using something similar to `// @ts-ignore` which would encode a truncated hash of the error message on the line, as well as a truncated hash of the lines AST; the original error message and the justification.

These were long lines so were a PITA, but they immediately had this 'ratchet' effect.

I tried several times to move to a central file referencing the issues, but the complexity in maintaining the references with common refactors was a blocker.

In modern times a hand axe is opposed to full axes, hatchets, felling axes, wood splitting axes etc. Depending on where you are in the world you will have different axe categories, but a 'hand axe' is typically present as an axe wielded in a single hand.

However, some significant distinction should be made for what is actually meant here. For such historic finds "hand axe" often means a stone tool with two faces and shaped like a tear drop / round-bottomed triangle. With the 'bottom' face shaped to a crude blade, and the 'top' 'sides' made into a grip. Note there is no shaft, and the way it is used is speculative and likely very varied, as few other tools existed.

The proto-axe if you will.

To this point; if you look at google maps satellite view and zoom in/out repeatedly over the UK the yellow line 'road' that doesn't disappear and reload is the construction site of HS2.

If you want confirmation, the easiest bits to "check" are Aylesbury and Coventry. London and Birmingham are too big for the features to stand out.

Here is the official HS2 map: https://www.hs2.org.uk/map/?mapView=9_52.0744_-1.8347

This is one of the key elements that will shift the SWE discipline. We will move to more explicitly editing systems by their footprint and guarantees, and verifying that what exists matches those.

This is very similar to https://news.ycombinator.com/item?id=46702099 posted 4 days ago.

And there is also this https://dewmal.medium.com/hacker-news-is-a-living-time-capsu...

a weighted sampling method is probably the best. Segment by time period and vote count or vote rate, then human evaluate. This could be done in a couple of hours and it gives a higher degree of confidence than any automated analysis.