But the whole point was that it wasn't a separate role: it was a re-distribution of work so the developers were doing operations. Instead, a lot of people entirely missed the point and just renamed their ops people to devops.
Whether this is actually beneficial (let alone possible) depends heavily on the type of site.
Web apps that are valuable to use offline also tend to be the kind that really do warrant client-side logic and rendering (a spreadsheet web app is a classic example).
If the site's focus is providing information (e.g. Wikipedia), then working offline really just means loading all the backing data into the browser, which quickly becomes impossible.
I'm sure there are cases where offline availability is a huge plus (your site might be a good example), I just don't think it's universally applicable.
The author is reinforcing the false dichotomy between using front end frameworks and hand-rolled JS, as if rendering data from JSON APIs is the only way to display information from the server.
Almost as an aside, he says
> Server Side Rendering is also no better, because while they can do certain things in more straightforward way, they break browser behaviour [...]
but he provides no examples or supporting evidence, so it's difficult to know what browser behaviour he's referencing. "SSR" is just how the web has worked since the beginning and it works very well. Maybe he's specifically talking about SSR as provided by Next? I've never used it, so I'm not sure what browser behaviour it might be breaking.
> The whole point of indication is to signal my intention to move, so that the car in my blind spot creates room for me to merge into their lane.
That is definitely not the point of a turning signal. The car that's already in the lane has right of way and it's your responsibility not to plow into them. If they opt to make room for you, great (that's just courteous driving), but it's not an obligation.
If you can't see the car in your blindspot when changing lanes, you're not doing a proper shoulder check, hence the blindspot warning.
> That is definitely not the point of a turning signal
Incorrect. The turning signal is called an Indicator, because it give other drivers an indication of your intentions. So you first look and check that it's possible and likely safe to merge. Then you indicate your intention. You then merge if/when safe.
Indicating an intention to merge into a narrow gap is fine - as long as you only merge when there is sufficient room to do so.
But if the car beeps at you just because you indicated - then there is a design issue.
> If they opt to make room for you, great (that's just courteous driving), but it's not an obligation.
Absolutely - I was not implying it was an obligation. I am only saying that you use your indication to indicate to other drivers your intention. It is totally valid to turn off your indicator and not merge after indicating.
That said, I still think it's a generally good feature. If a person is distracted and fails to see the vehicle in their blind spot during their inital shoulder check, that beep might prevent an accident.
On my vehicle that warning can be disabled, which I think is the right way to provide features like this. People who find it useful can leave it on and people who find it distracting can turn it off.
The one time I rented a car with this feature, it claimed there was a car in my blind spot when there was none. It seemed to be reacting to a car that I had already determined was clear of my path.
When I write the code I know what my intention is with each line. Sure I can (and do) make mistakes, but identifying those mistakes during debugging is relatively easy during debugging because I can clearly see the discrepancy between what I intended and what I did.
With an LLM I must first understand (usually really just infer and guess) its intention, which is much more difficult.
is the LLM not acting on your stated intent? maybe you can find a middle ground, where you can plan and act in small enough chunks that it doesn't start getting its "own" ideas about what to do, or how to do it
a chainsaw is a coarse tool and I liken it to vibe coding. you maintain at least some level of control, but the edges are rough and you might slice off more (or less) than you meant to. I want to model my usage more like a table saw, a precision instrument that can make the exact cut just as I planned it
This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.
A pretty nice use case I have for socket activation is for isolating containers or applications from the host network.
The great thing about socket activation is that opened sockets carry over even if the application/container unshares into a different network namespace!
It also works great with Podman pods with networking in the pod completely disabled and, as those are host sockets, does fully retain the connection info of peers (so logs are not just uselessly containing the gateway IP, depending on the container network config)
I believe its original motivation was just speeding up boot times by starting fewer services, even if you'd eventually want the service running. This was achieved in the past with xinetd, but systemd made the approach more popular for the masses.
inetd began to fall out of favour in the mid-late 90s as services became more heavyweight and startup times became longer (think of the initial crypto setup needed by sshd vs rsh/telnetd)
CPU speeds have increased & and i/o latency has decreased so much since then that startup times are generally imperceptible, so the pendulum has swung back to favouring socket activation.
The anti-systemd "traditionalists" never seem to acknowledge that history, though!
Protecting forms with reCAPTCHA uses cookies that fall under "marketing" and gathering site stats using Google Analytics uses cookies that fall under "marketing" and "statistics," making a consent banner or dickover pretty much required.
Are these services necessary for a page to work? Not at all, but many businesses consider them crucial. Unprotected public forms almost immediately start getting spammed by bots, burying real, important communications from potential clients. GA offers insight into what visitors to your site are looking for, which has real business value.
I don't like it any more than you do, but I get why businesses would choose to use these. On their end, at least with reCAPTCHA, they're just trying to protect themselves from the complete shitshow that the modern web has become.
It can be, see Global Privacy Control [1]. As an example, the Complianz consent plugin for WordPress can detect and respect the user's GPC setting, but that feature can be toggled. So even though this exists, many sites will still ignore it.
Proton makes safer, more private (than, say, Gmail) email a possibility for people who don't have much technical knowledge but who know enough to want to keep their emails out of Google's hands.
If you have both the knowledge and time to run a server, by all means, that can make sense (and can be fun!). It's just not as widely applicable.
You send emails to @gmail addresses most of the time, so... How you can avoid giving Alphabet (or some other giant) your messages?
The point of ownership is having your mails in your hand, on your iron, anything who can talk IMAPs or even POP is ok for that. For voice/chat etc Matrix or XMPP might be yours, so nobody could decide to ban you or shut the service down. You still depend on a ISP ok, but much less dependencies anyway. That's the point IMVHO.
While thinking that company X is better in privacy terms than company Y is honestly meaningless, you can trust them or not, you don't know what happen on their servers or someone else ones where they actually live on (like using Amazon o Microsoft cloud as a backend).
I can't help but wonder if we've already hit the point where real people now write like that because it's what they're exposed to day in and day out.
I have zero evidence to back this up but I'm convinced that autocorrect is what led to people pluralizing word's with apostrophe's. If we keep outsourcing how we express our ideas, how long until we no longer have any left?
Calling anything ops "DevOps" is right up there with calling JSON APIs "REST."
I know it's silly to let it bother me, but man does it get under my skin.
1. https://imgur.com/gallery/thank-you-lNUh0uV
reply