Snarky reaction aside, and actually reading the article, it says that the problem is something along the lines of "we incentivized and rewarded business accounts to post large volumes, so now if you switch to chronological order you will see more of these posts which reduces user satisfaction".
Well, that just means that the company will have to adapt before their users start unfollowing spammy accounts and the whole "influencer" business takes a hit. Though tbh, not sure how much of a hit it could take but hey, when instagram says engagement falls, I allow myself to feel optimistic for a brief moment.
While this may be a bit of a tongue-in-cheek comment, I've started to think that this is exactly how it should be:
People that are elected by the public and hold the power to define every aspect of our lives, should be held to the absolute highest level of scrutiny possible. Every aspect and every single moment of their lives should be transparent and recorded while they hold office, no exceptions whatsoever.
I will concede that having it broadcasted may be a tad hard to do, but there should be a record of what happened during their time - in fact there should be a way to answer the question "what was minister X doing at 2026-08-29 20:13:14 UTC?"
And for the argument that says "oh then nobody would want to do it", I think that's in favour of this approach. Look around at what we're dealing with, and which people want to win elections and the fervour with which they go about it.
We should be trying to make this kind of "job" as unappealing as possible. It should be a chore, not something to go after.
Is it me or was there a similar vulnerability reported a few years ago? Something about the attacker getting access to all platform's users' databases, though not sure if it was cosmos or something similar.
In this case, the companies that make and provide AI models that are increasingly used to interact with me on critical things (banks, public sector services) then yes.
Abso-fucking-lutely they should be regulated like crazy.
In fact I'm really surprised by the amount of people that are not worried by how many parts of their lives are being handed over to be managed by a probabilistic system that is controlled by a private company with next to zero oversight.
There must be a greater liability than "oops, you're right to push back"
Not the original person you replied to, but as far as I'm concerned there are a few questions that could very easily indicate which side of the line is something.
E.g.
- Is it addictive?
- Does it have the potential to destroy lives?
- Does it have the potential to destroy lives in seconds?
- Does it have a strong lobbying mechanism behind it? (n.b. things that are good and nice rarely need someone to bribe people to accept them)
or simply:
- Would you be worried if your child did it?
I think the number of "yes" that you get draws a very clear line.
He's obviously talking about alcohol (it takes seconds to consume an amount of alcohol that can result in death, yours or someone else's from a fight or car crash) and firearms (should be obvious).
Sounds like you're implying some sort of mischaracterization of sugar here which minimizes the former in a weird way.
I wanted to draw the distinction between something that destroys lives over a longer period of time (smoking) VS something like gambling where you could lose your life's savings in seconds.
The alcohol mentioned in a sibling comment also ticks the box.
For the sugar, I'd say yes, no, no, yes and "not too much, but I'm keeping an eye out".
Maybe I haven't seen enough of his videos. They seem generally informative? Perhaps a bit depressing but I wouldn't say that watching a Tim Snyder video can ruin your life like gambling can.
Ok, so add "is it easy / quick / cheap to acquire?". Performance cars (I take measured risks at the race track) and track days / race tires aren't cheap. Not in any sense of the word.
Unsafe driving in ANY car? Yes - but that's already illegal.
Performance cars are very cheap to acquire temporarily.
I can literally book right now, for 4 long laps, for £99 any of the following (and that's a a very small subset of 30 similar cars): Lotus Evora / GTR 1200bhp / Lamborghini Gallardo / Dodge Viper SRT VX / Huracan... Unless you'd say these are not performance cars?
Not sure if the history lessons are a joke, but sugar is rightfully taxed or otherwise disincentivized in many countries, because it is highly harmful to society as a whole. Sports cars definitely get some yes answers, and are also rightfully taxed in several countries.
Military technology may be an exception as "necessary evil", but also is a bad example because it id not consumer-oriented.
This feels like a good idea in principle, but I can't shake the feeling that it just moves the goalposts one step away:
Now your app doesn't have direct access to your stripe/github/aws/whatever keys (which is good!) but you still need to have _some_ authentication against your proxy.
If you have a per-app authentication, then if your app's key leaks, then whoever uses it will be able to reach all the external services your app can, i.e. with one key you lose everything. On the other hand, if you have per-endpoint authentication, then you didn't really solve anything, you still have to manage X secrets.
Even worse, from the perspective of the team who owns and runs the proxy, chances are you are going to use per-app AND per-endpoint authentication, because this will allow you to revoke bad keys without breaking everyone else, etc.
What this really solves is subscription management for (big?) organisations. Now that you have a proxy, you only need a single key to talk to <external-service>, no need to have to manage subscriptions, user onboarding and offboarding, etc. You just need to negotiate ratelimits.
The auth between your app and the proxy can be scoped more easily.
For example if the proxy runs in localhost you can trust the localhost workload.
Or you can use some other kind of workload identity proof (like cloud based metadata servers). If you leak such a key no other VM can use it, because it's scoped to your VM
That's not true. Both AWS' as well as GCP's workload identity tokens are not bound to the VM. If you leak the credentials they're valid until they expire. on AWS the expiry is 6 hours (non-configurable). Even if your IAM role has a shorter expiration, the credentials assumed by the VM will always be valid for 6 hours.
That entirely depends on the location of the proxy and the extra conditions you can express. E.g. you could bind it to a source IP and have the proxy check that, or use some overlay network (like tailscale does)
My point was that you don't literally have to run the proxy on localhost in order to scope the request.
The problem is that, even if Fastmail are Australian, they host exclusively in the US. They state that sure, there is the possibility of interference at the data center level, but they rely on their anti-hacking measures to prevent unlawful access
For me it's quite simple: It works and it stays out of my way.
I've owned a macbook since 2010, with a short break during the touchbar era when I got myself an XPS with windows which I dual-booted with ubuntu and later a system76 that comes with their own flavour of Ubuntu, called Pop! Os.
The situation in windows (windows 10 at the time) was abysmal. Completely incoherent UI, settings spread across different menus, ads in start menu, slow and broken search, constant nagging to update windows, to update the drivers, to tell me that the drivers have been updated, to install or update my antivirus, etc. These were not things that I installed myself, these were included with Dell's setup of the machine.
On the system76 laptop things were different. Things were calm, I could configure everything as I wanted and things worked. Until at some point I installed a new version of something, which had nothing to do with sound, but it broke sound, just as I was preparing to join a meeting, and just as we were going into the second phase of lockdowns in late 2020 so online meetings were here to stay.
My macbooks are reliable. I've got the M1 as soon as it came out and I never got a single issue with it. I've upgraded twice (I think) across major versions and everything worked. I don't have to worry about it leaving me hanging when I need it.
(And that's not taking into account things like build quality, touchpad quality, battery life, silence, etc)
In the end of the day, I do a lot of debugging as part of my work. When I don't work, I want to choose what I will be debugging, not have it forced on me.
And don't get me wrong: I see where Apple is going, I know that they're a greedy company that want to maintain their iron grip and have the final say on what we can and cannot do on our machines.
However, for me for the time being it's the least bad option.
I do like the build of Macbooks and especially the solid casing. Unfortunately I could never get used to MacOS even within 2.5 years and it was not quite as reliable for me as it is for many others.
XCode installations failing, Docker installation failing after an OS update never to work again without completely reinstalling OS, plugging in headphones would crash the Macbook (until OS update 6 months after I got it), video calls slowing to a halt, if sharing screen etc.
Also there were some things I just never got used to in Mac like window tabbing & minimize working in a Mac way. Maybe if I hadn't had a personal laptop that used Linux at the same time, I would have gotten used to it a little better, but I just plain hated the way it worked.
To be fair, I think it was still more reliable than varieties of Windows, especially the later ones! If tabbing worked more like under Windows and it allowed a bit more configuration, I might be using Mac these days.
That leaves Linux. Although it's not flawless neither after configuring Debian + i3, it works exactly like I want and the same installation has been reliably working for 5+ years. However, getting to the setup that just works certainly took several tries and depends on laptop compatibility, so... No ideal choices exist right now I think. Just luck and what someone is most used to in the end.
I’ve used Macs nearly exclusively for 13 years and have not gotten used to the window tabbing. I just fundamentally don’t think windows of the same application should be grouped together.
I have very few problems with linux, despite running a fairly unstable rolling release distro. MacOS does have problems. I have no idea whether its more of less reliable, but going on personal experience is not a good sample.
As someone who's only did a couple of small toy-projects in rust I was never annoyed by the borrow checker. I find it nothing but a small mental shift and I kinda like it.
What I _do_ find annoying though and I cannot wrap my head around are lifetimes. Every time I think I understand it, I end up getting it wrong.
Lifetimes are the input to the borrow checker, so it doesn't make much sense to say you have never been bothered by the borrow checker but you are bothered by lifetimes.
How does lifetime elision affect performance? I thought the compiler just inferred lifetimes that you would have had to manually annotate. Naively, it seems to me that the performance should be identical.
Cloning values, collecting iterators into Vecs and then continue the transformation rather than keeping it lazy all the way through. Skipping structs/enums with references.
I thought they meant the case where you go "ugh, I don't want to write a lifetime here" and then change your code, because you have to. If you don't have to, then yes, there's literally no difference.
Somehow at some point lifetimes started clicking for me. I think the key was when I understood that in a function, not everything needs the same lifetime. e.g.
the function this way is incorrect. When I was a beginner, I would have thought that every & in the signature needed a lifetime. In a slightly complicated code, the borrow checker then demanded lifetimes everywhere, they'd infect everything, but the code would still never compile.
Then I understood that not everything needs to be tied to the same lifetime. In this example, MyRef should be tied to the MyStruct, but not to the `key`:
Snarky reaction aside, and actually reading the article, it says that the problem is something along the lines of "we incentivized and rewarded business accounts to post large volumes, so now if you switch to chronological order you will see more of these posts which reduces user satisfaction".
Well, that just means that the company will have to adapt before their users start unfollowing spammy accounts and the whole "influencer" business takes a hit. Though tbh, not sure how much of a hit it could take but hey, when instagram says engagement falls, I allow myself to feel optimistic for a brief moment.
reply