The worst part about smart phones is their browser/social media. Technically, even dumb phones like the nokia 3310 had contact lists so you didn't have to memorize phone numbers. And land lines had speed dial. And my family used a phonebook with a rotary dial telephone. It's not like people had memorized as many numbers as they now have stored in their telephones.
> Rob studied the man's face and vaguely remembered him as Ronnie Lockwood, someone he would occasionally see at Sunday School as a boy and who he was told to be kind to as he was a "bit different".
> Ronnie was then almost 30 and had been without a home from the age of 15, living in and around Cardiff and moving from job to job - Rob would sometimes see him at a youth club he ran.
> The pair planned to let him stay until the day after Christmas, but when the day came, they couldn't bring themselves to cast Ronnie out and sought advice from the authorities.
You aren't entirely wrong, but this wasn't a random person and they did contact a homeless centre for advice.
Given that Ronnie had apparently already gone through some sort of system to end up at a "school for subnormal boys", it seems pretty clear that Ronnie lived a much better life through this family's actions and generosity.
I made a service using something like a 64 bit wide ULID but there was never a presumption that data is be inserted or updated earlier than the most recent record.
If the domain is modeling something like external events (in my case), and that external timestamp is packed into your primary key, and you support receiving events out of chronological order, then it just follows that you might insert stuff ealrier than you latest record.
You're gonna have problems "backdating" if you mix up time of insertion with when the event you model actually ocurred. Like id you treat those as the same thing when they aren't.
> There were no code assist tools in 2022, but jobs disappeared.
In 2020 there was a global pandemic called COVID-19 that had a pronounced affect on the world economy. Stimulus cheques were given to companies to keep them afloat through this time. Tech companies spent that new capital on hiring and them layed off a lot of workers when they weren't able to sustain them.
A big reason you saw layoffs is because we had massive hiring sprees from short term capital through stimulus cheques.
These days, when a company tells you they are laying off good workers and replacing them, with software that cannot fact check its output, because their audience cannot tell the difference, you should believe them and consider if that is really what you want the world to become.
It's telling that you compare specialized creative work, like making art, to "jobs" like standing in an elevator.
Nobody would miss washroom attendants disappearing either. That is different from automating away the stuff that makes life interesting. Like AI startups telling you that their robot will spend time with your friends and family, so you don't have to. Being disgusted by that is not being a luddite, it's being a well adjusted human with aspirations beyond doomscrolling AI slop on tiktok/youtube.
It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model.
I run npm under bubblewrap because npm has a culture of high risk; of using too many dependencies from untrusted authors. But being scrupulous and responsible is a cost I pay with my time and attention. But it is important because if I run some untrusted code and am compromised it can affect others.
But that is challenging when every time some exploit rolls around people, like you, brush it off as "unlucky". As if to say it's inavoidable. That nobody can be expected to be responsible for the libraries they use because that is too hard or whatever. You simply lack the appetite for good hygene and it makes it harder for the minority of us who care about how our actions affect others.
> you have no appetite for a better security model
For what it's worth, there are some advancements. PNPM - the packager used in this case - doesn't automatically run postinstall scripts. In this case, either the engineer allowed it explicitly, or a transitive dependency was previously considered safe, and allowed by default, but stopped being safe.
PNPM also lets you specify a minimum package age, so you cannot install packages younger than X.
The combination of these would stop most attacks, but becomes less effective if everyone specifies a minimum package age, so no one would fall victim.
It's a bit grotesque because the system relies on either the package author noticing on time, or someone falling victim and reporting it.
NPM now supports publishing signed packages, and PNPM has a trustPolicy flag. This is a step in a good direction, but is still not enough, because it relies on publishers to know and care about signing packages, and it relies on consumers to require it.
There _is_ appetite for a better security model, but a lot of old, ubiquitous packages, are unmaintained and won't adopt it. The ecosystem is evolving, but very slowly, and breaking changes seem needed.
I had the chance to finish reading and it looks like Trigger were using an older version of PNPM which didn't do any of the above, and have since implemented everything I've mentioned in my post, plus some additional Git security.
So a slight amendment there on the human error side of things.
At some point you must be open to being compelled to read code you run or ship. Otherwise, if that's to hard, then I don't know what to tell you. We'll just never agree.
If you find a better solution than being responsible for what you do and who you trust, I'm all for it. Until then, that's part of the job.
When I was a junior, our company payed a commercial license for some of the larger libraries we used and it included support. Or manage risk by using fewer and more trustworthy projects like Django instead of reaching for a new dependency from some random person every time you need to solve a simple problem.
> What no appetite? I just don't like your solution.
When I say "appetite" I am being very deliberate. You are hungry but you won't eat your vegetables. When you say "I just don't like your vegetables", then you aren't that hungry. You don't have the appetite. You'd rather accept the risk. Which is fine but then don't complain when stuff like this happens and everyone is compromised.
I hope you've read every diff to every Linux kernel you've ever deployed... There's LOADS of code you've deployed I can bet a large amount of money you never read. So clearly there's solutions that solve the problem of having to read every line of every dependency you deploy. It's just that certain ecosystems are more easy to exploit so new solutions are needed. Read everything is not a solution, it's a bandaid that shows there's a problem of trust to be solved (or improved enough to discourage this wave of attacks) with a technical solution.
No, you are the problem because you have a higher expectation than reality. People shouldn't have to run npm in containers. You're over simplifying with one case where you have found one solution while ignoring the identical problems elsewhere. You are preventing us from looking at other solutions because you think the one you have is enough and works for everyone.
I agree with you that I shouldn't have to treat my libraries like untrusted code. I don't know what the rest of your comment means. I don't see how I'm preventing anybody from looking at other solutions to npm, they just don't want to do it because it's hard. And I have similar criticisms for cargo as it just copies npm and inherits all of its problems. I hate that.
npm has had a bad ecosystem since its inception. The left-pad thing being some of my earliest memories of it [1]. So none of this is new.
But all of this is still an issue because it's too convenient and that's the most important thing. Even cargo copies npm because they want to be seen as convenient and the risk is acknowledged. Nobody has the appetite to be held accountable for who they put their trust in.
> snickerbockers > No, your security failure is that you use a package manager
> you > It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model.
I'd wager a large portion of people with `npm` don't actually realize they have `npm`. I'd also wager that most people that know they have `npm` aren't aware of the security issues.
Under those conditions, people are not in fact making choices. These are not people "that have no appetite for a better security model". These are people who don't even know they are unsafe!
Yes, this is victim blaming. Just in the same way people blame a rape victim for what they wear. Does what you wear modify the situation? Yes. Does it cause the situation? No. We only really blame a victim if they are putting themselves directly, and knowingly, in harms way. This is not that case! This is a case where people are uninformed, both in the dangers present as well as the existence of danger.
FFS, on more than one occasion I've installed a package only to see that it bundles `npm` along with it. And I'm more diligent than most people, so I know tons of people don't know it's happening. Especially because you can't always run `which npm` to find if it is installed. But the fact is that you can do something like `brew install foo` and foo has a dependency that has a dependency that has node as a dependency.
Dependency hell is integral to the problem here! So you can go ahead and choose a package manager that doesn't allow 3rd parties to push arbitrary code and end up with a package manager that allows 3rd parties to push arbitrary code! That's even what made left-pad a thing (and don't get me started on the absurdity of using a module for this functionality!).
> Nobody has the appetite to be held accountable for who they put their trust in
That is jut not the reality of things. In the real world nobody can read all the lines of code. It just simply isn't possible. You aren't reading everything that you're running, let alone all the dependencies and all the way down to the fucking kernel. There just isn't enough time in the day to do this within your lifetime, even if you are running a very cut down system. There's just too many lines of code!
So stop this bullshit rhetoric of "know what you're running" because it is ignoring the reality of the situation. Yes, people should do due diligence and inspect, but the reality is that this is not possible to do. Nor is it bulletproof, as it requires the reader to be omniscient themselves, or at least a security expert with years of training to even be able to spot security mistakes. Hell, if everyone (or just programmers) already had that kind of training then I'd wager 90+% of issues wouldn't even exist in the code in the first place.
So stop oversimplifying the situation because we can't even begin to talk about what needs to be done to solve things if we can't even discuss the reality of the problem.
It's cute that you truncated the most important part of the other commenter's message; "your security failure is that you use a package manager [that allows third-parties push arbitrary code into your product with no oversight]."
> I'd wager a large portion of people with `npm` don't actually realize they have `npm`.
Recklessness is not a defense.
> But the fact is that you can do something like `brew install foo` and foo has a dependency that has a dependency that has node as a dependency.
That's good to know. I've never looked at brew and wasn't planing on using it, but I will stay away from it in the future. It sounds like you learned your lesson though, right?
Because if you haven't, that sounds like negligence. You can't be unaccountable for your actions by admitting that you did not expect those outcomes when you did not do your due diligence. And if you don't hold yourself accountable, then you sure aren't about to hold others accountable either. So your whole ecosystem is screwed.
> Yes, this is victim blaming. Just in the same way people blame a rape victim for what they wear.
Not even remotely. I can say and it's bad for people to abuse exploits and they don't deserve that. At the same time, if I put my private key without a passphrase into the public, or commit secrets to git and share them with the public, I am being negligent.
You are leaving your car unlocked with the windows rolled down in a dodgy part of town overnight. And when it's gone/pilfered in the morning, it's completely fair to say that you did a stupid thing.
We can say that is negligent without saying that you deserved it or that it ought to have happened. And it's absolutely okay for me, or anybody else, to say that you should have known better, without you comparing me to a rape apologist.
> In the real world nobody can read all the lines of code. There's just too many lines of code!
I don't know why you went on that rant when you quoted me talking about "trust". I wouldn't need trust if I could fully understand everything about every machine I use and only rely on myself.
> So stop this bullshit rhetoric of "know what you're running" because it is ignoring the reality of the situation.
Naw, it isn't. I trust packages from my operating system's package manager. The issues we see with left-pad and shai-hulud, have never and will never happen to me using those packages because they simply do not accept the kinds of garbage people put up on npm, or brew apparently as you pointed out.
I avoid running stuff like on-my-zsh because I don't have the patience to audit that and I certainly don't want to run untrusted stuff in my shell as root. But it's a very popular package because people, like you, have a greater risk tolerance. And that's fine, as long as you accept the consequences of that risk tolerance. You aren't paying for support or liability, you aren't reading the code, you are putting trust in random sources and hoping that things work out.
If you want the luxury running untrusted code as root, or the luxury of leaving your car open in a dodgy part of town overnight, then maybe maybe what you want is a surveillance state, idk. There is a cost to that. A tradeoff. If that's what you want and that's your goal, then I can't stop you. But it's you could also just ... not do such risky things.
A core SRE principle is that "machines/servers are cattle, not pets". They shouldn't be special or bespoke in a way that makes replacement painful or difficult.
I've heard the term used for servers before but not version control repositories. I just don't understand what it would mean for a git repo to be a cattle vs a pet. Like what is an example of a cattle repo vs a pet repo. The metaphore just sounds like gibberish to me idk.
Unless all it means is that that you can have more than a few like the other commenter said but I didn't think that was what the metaphore meant with respect to servers so again I have no idea lol
To me it would mean that a git repo should not have scripts, runners, etc. configured that we don't have the means to easily and readily replace. It should all be documented and understood well enough that we could kill the repo and init another at will.
These export controls increasingly look like "tax".
The White House said the US government would take a 25 percent cut of the chip’s sales, similar to a deal with AMD and Nvidia earlier this year that allowed them to sell lower-powered AI chips to China while paying the US government 15 percent of the proceeds.
> Using them in China is legal in China.
Technically, yes. The CCP, though, wants to incentivize Chinese firms to use domestically-manufactured chips.
> Technically, yes. The CCP, though, wants to incentivize Chinese firms to use domestically-manufactured chips.
This couldn’t be playing out better for Xi. Trump is China’s best president.
I used to think Trump was clueless and being outplayed, but now I realize he’s just looting and couldn’t care less about protectionism or the American worker.
Every single action from this administration can be explained by greed and ego.
> Every single action from this administration can be explained by greed and ego.
I highly agree with you - and that’s coming from someone who can’t stand the Democrats[1]. Things like announcing all of a sudden that he opposes a merger when everybody knows Kushner is involved with a rival bid… it’s too obvious how much corruption is his very operating system.
[1] (I didn’t vote for either candidate for President, but I’m not in a swing state so I’m not sorry)
The lesson from Mamdani is that the only way forwards for actual policy based and anticorruption politics is within the Democrat primaries. These are even run by the state in many states, I believe.
Eradicate the Republican party as an organization, split the Democrats into "normal right" and "maybe a bit left" factions, and see if you can get preference voting in there as well while asking for a pony.
That's Corporatism. It's from the fascist playbook where the state takes partial or complete ownership of private companies. Where does that money go, to some slush fund for the president? The reason for the export controls is to keep our potential adversaries from being on the bleeding edge of frontier AI. It goes against the US's interests to give China a leg up with advanced chips. It's almost laughable, of course, as the Nvidia chips are already manufactured in a country that China claims as their own. If they ever pressed the issue, we could find ourselves without the most advanced chips.
This is not at all what is meant by fascist corporatism, nor corporatism more generally. Corporatism is more about collective bargaining by professional trades, and is not the sense of corporation as used for private companies.
They aren't "bitching and moaning" they are moving communities and platforms. GitHub is user hostile run by a company with a pattern for that. Alternatives to GitHub exist and supporting them is not "bitching and moaning", it's building and creating. The fact you can't or won't recognize that is telling.
The homepage for this project has this video [1] under the heading "See it in action". It starts off with background music that progressively gets lounder and at about 30s the vocals start to drown out the narrator. Why do people do this? Did nobody watch this video before uploading it? What was going through the mind of whoever made this video? Wild.
I hear the effect you're referring to, but I'm not sure I would have noticed if you hadn't pointed it out. It seems about as muddled as most modern sound mixing when there's talking combined with other sounds, which is why so many of us use captions all the time, now.
The dev here. Thaks for the feedback. I'll try to do better next time. I'm a single dev with cero knowledge of video editing (as you clearly noticed :P).
