andrewaylett
""" 54 Prohibition of nuisances by persons in the thoroughfares.
Every person shall be liable to a penalty not more than level 2 on the standard scale, who, within the limits of the metropolitan police district, shall in any thoroughfare or public place, commit any of the following offences; (that is to say,)
...
8. Every person who shall roll or carry any cask, tub, hoop, or wheel, or any ladder, plank, pole, showboard, or placard, upon any footway, except for the purpose of loading or unloading any cart or carriage, or of crossing the footway:
... """ https://www.legislation.gov.uk/ukpga/Vict/2-3/47/section/54
The plank of wood is one element in a much broader statute, rather than an example of hyper-specificity. And it might have been strictly applied at the time, but that doesn't mean you're definitely going to get into trouble nowadays.
In a similar vein, the UK *does* have laws that affect big tech. UK GDPR places requirements on processing of personal data:
""" Personal data shall be:
(a)processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’); """ https://www.legislation.gov.uk/eur/2016/679/article/5
Whether that's properly enforced is (as with the plank) a completely different matter.
In the UK, at least, we don't need new regulations, we need to more effectively apply the regulations we already have in place. But there is also a balance to be made between enforcement through fines and enforcement through changing behaviour: it's much better to work with companies to bring them into compliance than it is to just fine them and without actually changing anything.
I'm not overly keen on the tooling: as far as I can tell the whole industry is prone to flagging false positives as "vulnerabilities" rather than "potential vulnerabilities" and it's a bit too easy to turn those reports into a tick-box "you must update now because the tool says so". But they also do flag true vulnerabilities. And they pay for teams of security researchers to find and fix issues, not least because that's good marketing.
That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.
It's not built in to ESLint, but it's fairly widely used in my experience and helps ensure that you've got a sensible split between production and non-production.
I'd suggest that Google aren't your primary audience for this kind of post: it's folk like me, who are quite keen on the idea of GrapheneOS but don't actually use it yet (I actually bought a second-hand spare phone last week with the ulterior motive of trying GrapheneOS on it, we'll see...). What do you want your average reader to think about you, from reading what you've written?
I should add that this post (that I'm directly replying to) comes across to me as very much more appropriate than the original blog post, even as it's in many ways a lot harsher. It's putting Google's behaviour in context, rather than drawing comparisons between your own abilities and their poor performance.
You don't need to drag Google down in order to look good; there are many reasons why what Google (and especially their management) have done is bad for society (and not just for you) and also many reasons why what you're doing is excellent on its own merits, not merely compared to Google.
That's part of the motivation behind HugOps: the people working on fixing a thing are only rarely the people who are responsible for the system that caused the breakage.
The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.
Should probably start slightly less ambitiously though :P.
We certainly held it in high regard. It was rare that a compiler bug was in their code rather than ours :).
For example: https://andrewaylett.github.io/rgitweb/ is a repository viewer that runs against a static git repo. It doesn't care what you're storing the pack in, just that the data is there to make the right range requests.
All the sources of randomness are under the control of the provider, even if today's deployment structures mean providers introduce extra randomness due to the concurrent nature of the evaluation. Serialise the computation, feed it from a pRNG, and you have a fully deterministic result. But providers don't want to offer a deterministic result, and especially not one as fragile, expensive, and inefficient as a full serialisation would be.
†: For variants of "nothing" that include cost and deployment challenges.
Where LLMs can be really actually quite useful, is situations where you have a lot of context and want to distil it. That's what I think happened here: the author has a lot of information to convey, and the LLM-generated output is relatively information-dense.
Unfortunately there's no objective measure for information density of an arbitrary piece of text.
[1]: https://taginfo.openstreetmap.org/keys/official_name#overvie...
I'm certainly not saying you should use this code, but it's a proof of concept for avoiding the CPU overhead of cgit rendering by loading the data on the client.
It cost me £8.27 of Fable use (from the free credits I've been given) and 56% of my five hour quota on a $20/month Pro plan. There's no server logic, it's 1.3MB of minified JS and CSS and (while I'm absolutely not suggesting anyone try to use it) it basically works: https://github.com/andrewaylett/rgitweb
This is a one-shot, my prompt set the expectation that I'd be able to load resources using CORS but (not entirely unreasonably) the Git hosts I've tried don't set CORS headers.
Shared more because I was pleasantly surprised at how cheap and easy this was -- and with a repo link because talking about it without sharing the link would be a bit crass.
Given one of the major themes of the leave campaign was "restoring parliamentary sovereignty", it's darkly ironic that leave also campaigned against parliament actually using that sovereignty, and indeed came closer than anyone else (including the EU) to restricting parliamentary sovereignty.
Ebikes are pedal assist, power limited, and limited to only assist up to a certain speed. You can go as fast as you're able, but if you're above (commonly) 25km/h the motor won't help you. They're allowed anywhere you're allowed a non-assisted bicycle.
Electric motorbikes may be limited by the manufacturer in order to achieve a certain license class, but once you get past the low power classes, they're only as limited as their petrol cousins. They're only allowed on roads.
Any middle ground, including things that look like bicycles but don't require the rider to peddle, fall either into the "electric motorbike" category or into the "not roadworthy" category. Riding them without a proper license, insurance, and equipment is illegal.
Somewhat unfortunately, much of the press seems to want to class the non-roadworthy motorised vehicles as a special case of "ebike" rather than the general case of "motorbike".
(And to your first point: yes there are speed limits but it's fairly common for cars and motorbikes to be able to go much faster than the limit. In first gear, even, for motorbikes.)
It's not the LLM that spammed, it's the people who set up the LLM.
And the implementation feels very much like it sits in the UI layer, rather than further down the stack.
I'm not trying to claim stacking PRs in this way is the best way (it's not). But it does add an extra affordance for those who want it without burdening those who don't with the need to understand why someone would prefer it.
And there are also plenty of ways that people have been working around GitHub's (and to a lesser extent, git's) lack of tooling for working on changes in this way. I'm sure they have customers clamouring for the feature; whether they'll be happy with what they get remains to be seen.
(Very happy jujutsu user here, my tooling makes it really easy to create stacked commits with a stable identifier that maps really easily to branches and then onwards to running `gh stack`, but what GitHub have delivered is definitely still lacking)
A set of stacked PRs is exactly the same as a line of commits. The only difference is the UI, but the UI is the important bit here because lack of UI is what's stopping folk from doing that today.
Even when I've developed my changes as a stack of commits, I'll feed them to my team one commit (and one PR) at a time so they're easier to review — and I discovered that GitHub had turned on stacked commits UI because for one particular project I'd manually created a set of PRs in advance (with the right bases) and GitHub offered to create a stack out of them.
Edit: which also means you're not wrong, if you've got claims that trigger damage control then HR are even less your friend.
The people within HR may be friendly, they've probably got friends :). It can be a very people-oriented role. But they are incapable of being your friend when you're interacting with them in their role as representative for the company.
I greatly appreciate my employer's HR folk, they're really lovely, very good at their jobs, and want to help. But if I have to have a formal meeting with them, I would definitely bring along my union rep.