unilynx

I think he actually wants pipes. Instead of having to write:

  f3(f2(f1(some data)))

it would be nice to write

  some data |> f1 |> f2 |> f3

javascript has proposals for pipe operators because as soon as the simple .map /.filter/.reduce APIs don't suffice (ie. as soon as Promise.all is needed) the f3(f2(f1(data))) mess starts.

I haven't had an Apple TV in years.. it has no home app?

The EU/banner situation keeps confusing people because there are two different laws in play:

1) ePrivacy. the OG banner law. requires you to inform the user (but not consent, as I understand it) if you store data on a user's device. includes cookies, localStorage, indexedDB, etc. does not affect fingerprinting 2) gdpr. requires you to ask consent for any kind of user data processing, unless you can find another legal basis

eprivacy was about cookies, but forgot fingerprinting. gdpr was not specifically about cookies. but gdpr (or at least its past interpretation by the dutch privacy authority) didn't require consent for limited first party analytics.

which led to situations where you'd get the impression that you wouldn't need a banner for first party tracking using cookies .. well the gdpr didn't require it, but the older ePrivacy rules still did.

we still have the digital omnibus law package coming up which is supposed to simplify and resolve the overlap between the two above, and reduce banner requirements at least for SMB just analyzing their website visitors

Can whatever the next new image format for the web will be please have a JSON block at the start giving

  - dimensions
  - filetype 
  - minimum required decoder version
  - lossless: true/false
  - a list of alternative URLs and mimetypes to older image formats

And it doesn't have to be JSON, as long as it's in a fixed location (looking at you, AVIF and JPEG), extensible and can be decoded by just reading the first 8KB or 16KB.

Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)

Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.

So opensearch also allows you to POST search requests, but those are uncacheable

QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.

The noise probably makes the lava lamp wall just as effective as pointing the camera at the Mona Lisa - the lamps themselves are not that unpredictable frame-to-frame.

They were working on it since at least halfway March, because that's when MS got annoyed at AWS & OpenAI negotiating - https://www.datacenterdynamics.com/en/news/microsoft-conside...

> But I like this review of techniques, even the simplest ones are very effective, that surprised me.

because harvesters don't care until one technique gets massive use. if you come up with a unique but simple enough scheme for your sites and keep a few dozen email addresses out of their reach.. they've still gathered a million addresses. it's not really worth their effort to get the last 0.0001% of extra email addresses

so it's best to just not advertise your solution and make sure it doesn't get n any outside traction - if it gets popular the harvesters will defeat it

At least the error goes away immediately, for everyone, once you fix the cert.

.net seems to serve DS records with at least 18 hours TTL. so worst case it takes your monitoring up 18 hours to notice your record was broken, and then another 18 hours before your fixed record is server everywhere.

> but it is not the operational hazard it’s made out to be

Until you flip that DNSSEC toggle

Poll takes a timeout parameter. ‘Not polling’ is just a really long timeout

Don't forget about Bootcamp for the (soon) obsolete Intels .

With a debloated Windows 10 (which we're not going to connect to the internet anyway) they can live on for older games.

I think the 'K-thing' was a big and helpful part of getting early volunteers onboard to build apps for KDE. They really seemed to enjoy rebuilding existing applications into a K-version.

So I guess you just have to live with it, but consider it a way to honor the original contributors who build all the K(DE)-versions of the common apps

Except for infinite loops in JS. Firefox still handles those better.

How so? I don't remember ever having seen issues with this. If anything CSP steers you towards this (instead of inline scripts directly assigning to JS variables)

Exactly this. Don't look at the renewal proces, look at its output. It'll work for all certificate sources and catch other potential errors too (eg the webserver reporting success but not presenting the new certificate)

Can't remove a certificate from the revocation lists until it's expired, leading to boundless growth of those lists.

Risk of private keys/certificates from old backup media being leaked (remembering the adobe password leak...) and then suddenly coming back online and working until someone figures out how to revoke them

They're not an April fool's joke. A 90's linux might have these services enabled by default. I assume they were built to make network debugging slightly less boring

> Also, the prices may become more sustainable if LLM providers find ways to inject ad revenue into their products.

I'm sure they've already found ways to do that, injecting relevant ads is just a form of RAG.

But they won't risk it yet as long as they're still grabbing market share just like Google didn't run them at the start - and kept them unobtrusive until their search won.

and not having sponsored links back then

Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?

People actually do this??

Suddenly having to prefix `this.` in JavaScript to every member bothers me a lot less

> Iframes don’t expand to fit content

Actually, that was part of the original plan - https://caniuse.com/iframe-seamless

ugh. these kind of changes should not be made in a minor release..

We did this for a long time for our CMS - although we did simulate a filesystem structure. We also set up a git-like system to store versioning information and set up WebDav to mount it all and allow direct source code editing. It worked pretty well for years.

We eventually stopped because we were relying much more on external tools (eg npm, webpack) which had all sort of issues over webdav mounts. Maintaining all this code management infrastructure in parallel wasn't worth it in the end, and we moved the code back to disk, switched to git, etc.

And photoshop silently ignoring webdav I/O errors when saving designs didn't help either.

You already have tagging by type on the filesystem - the file extension. That allows you to limit file searches. Add extra metadata to extensions if the same extensions have different roles (.backend.ts, .frontend.ts, .html.template, .text.template)

These days I prefer to structure for easy removal of code - everything for eg. a widget (frontend, backend, css) goes into a folder and I only need to remove that folder when the widget is retired, and linting/validation will show me the few remaining path references I need to cleanup.

Because (accidentally) mailing an unsubscribed user hurts your deliverability. And because there are users out there that will attempt to add spam traps to your mailing lists, sou you keep them off the list

(double opt-in doesn't really help with the latter as you're still mailing it)

Even if they freeze typescript development after the native implementation, given that the current performance was apparently acceptable to the current users, type complexity will just grow to use up the headroom

Plus, using TS directly to do runtime validation of types will become a lot more viable without having to precompile anything. Not only serverside, we'll compile the whole thing to WASM and ship it to the client to do our runtime validation there.

ARM already has them. https://developer.arm.com/documentation/ddi0602/2022-03/SIMD...

All taxes are ultimately paid by the consumer, companies just collect them. So German consumers who buy American cars pay their tax to Germany.

When a company buys from another company, no net VAT is collected - it’s only collected when a consumer enters the picture.