> every frame of an animation should look good if captured and analyzed statically, in isolation
This is just true though. It isn't the only thing that matters but if you are creating a game or a video sometimes you do capture things frame by frame to understand why something looks off when animated.
Your film thing isn't an analogy, you are trying to say film is an example where some frames have motion blur so they don't look good, but since that's okay in film, it should be okay in software and apps. The word "good" is being overloaded to mean different things in each example. Screen shake in a video game or chromatic abberation in a film can be good in those contexts because they are the intent of the artistic direction. Maybe if you are hung up on the word "good" replace it with "appropriate" or "intentional".
What do you think the premise of the article is? The article is pretty narrowly speaking of "app" UI and your comment is a "well actually" that some videos intentionally introduce noise or temporary discomfort for an emotional or artistic effect. On the same basis, comments like yours would defend screen shake if it was added to desktop and mobile apps on every user input.
This isn't true generally. I am personally far more comfortable with disabling smooth scroll. It has more to do with your mind's expectations. Which can vary between people. Some people expect smooth and others don't. Motion itself isn't necessary.
The only time I have to "rescan" is if I input a scroll and anticipate a scroll and it doesn't scroll. It has nothing to do with motion. In fact, in that case, I "rescan" even though the page hasn't changed, but because it doesn't match my expectation that it would change.
No they are not used everywhere. Some games with good UI use animations everywhere that an animation is appropriate. But plenty of good UI exist without animations. The point above is that no animation is better than an inappropriate animation.
No. Pollution is a byproduct. Spam and slop is quite literally the product in many cases. GenAI generated blogs or websites or youtube videos are the point for those creating them, they are not incidental outputs along the way.
And GenAI to mass produce misinformation and propoganda is a whole other thing. You see this right now with the Alberta sepratists in Canada. Comparing this to pollution like a means to an end is dismissive.
True! I love it when I buy a computer pre-installed with windows and it has a bunch of extra software bundled in like norton antivirus, dropbox, and opera. Plus the OEM makes money and I get a bunch of free apps. It's a win win. I hope the author of omarchy gets sponsor money for including nordvpn, spotify, and 1password. I love seeing linux become more conventionally attractive and steer in the direction of windows and macos because they're popular so linux will be more popular. Everything should be for everyone.
Also if you don't need certbot anymore is your service managing its own ssl certs with letsencrypt? Isn't it generally easier to configure with a reverse proxy like nginx or caddy and terminate SSL at the edge? That's literally caddy's whole thing that it does SSL for you so that it doesn't concern your application.
A lot of features that git had by default had to be enabled as plugins in mercurial.
The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.
I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
Your examples of engines are less about "it works" as more that it does a thing we couldn't do before and it works better than the previous thing. But neither of those are especially true of react.
React was an instant hit because it had the facebook brand behind it and everyone was tired of angular. But ultimately, react has worse outcomes for developers, users, and businesses. On the web, react websites are bloating. They run slower, their javascript payloads are larger, and they take longer to load.
Your suggestion -- that it works and then it gets more efficient later -- would make sense if we lived in a world where react moved off the virtual dom model. A virtual dom is a fine first attempt or prototype but we can do better. We know how. Projects like SolidJS do do better. React has not caught up, but it is still very popular. This whole "It worked badly, but it worked. Later came efficiency" thing is complete nonsense.
And there are loads of businesses that started off with an angular app, started to migrate to react, then started to migrate to react hooks, now switching to whatever the latest methodology is. Time and again you find these products, always endlessly migrating to the new thing, most of them never finishing a migration before beginning a new one. So these products end up being a chimera of four different frameworks held together with pain.
This isn't a good outcome for businesses, or for users, and it's not a good developer experience. react is stagnant and surviving off of being the default or the status quo and supported by tech companies that have long since stopped innovating and subsist on rent seeking. Developers choose react because nobody was ever fired for buying IBM and because they can look busy at their job, and because they buy a new phone and laptop every year with the latest hardware that can compensate for the deteriorating software they ship.
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.
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.
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
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.
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 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.
This is just true though. It isn't the only thing that matters but if you are creating a game or a video sometimes you do capture things frame by frame to understand why something looks off when animated.
Your film thing isn't an analogy, you are trying to say film is an example where some frames have motion blur so they don't look good, but since that's okay in film, it should be okay in software and apps. The word "good" is being overloaded to mean different things in each example. Screen shake in a video game or chromatic abberation in a film can be good in those contexts because they are the intent of the artistic direction. Maybe if you are hung up on the word "good" replace it with "appropriate" or "intentional".