arghwhat

Just a nit: Post-CRTs, there is no longer a "standard gamma curve", but many different transfer functions and many errors stem from misunderstanding this.

Even within "SDR"/"sRGB", many mistakes crop up from people erroneously mixing content encoded with the piecewise sRGB transfer function with content encoded according to a plain gamma 2.2 transfer function. And this is before we are getting into e.g., incorrect blending spaces or mismatched primaries.

But yes, it is purely a matter of compression, with many options for exactly what dynamic range you need and how you want your content defined (e.g., sRGB, gamma2.2, scRGB, HLG, PQ, ...), with linear light primarily reserved as an intermediate space for color conversions and blending - something your display server and any software working with arbitrary color spaces will be using.

> > The Go toolchain does not currently generate any AVX512 instructions. > > Thus leaving performance on the table.

This just misunderstands the documentation. Compilers do not generally emit much of any AVX512, and the docs are just stating that the Go toolchain itself never emits it at the current time.

Use of AVX512 instead usually comes from explicit intrinsics or handwritten assembly in the compilers you're thinking of, and it is the same in Go. There isn't much AVX512 code in the standard library, but it is there and the GOAMD64=v4 flag means that it does not have to use runtime CPUID feature detection.

External Go libraries like simdjson-go also actively use AVX512. AVX512 does nothing for code not written with SIMD in mind anyway.

> Apple does have some good counter arguments. Where there is data, there will be bad actors who want that data - and I trust Apple far more to behave than I trust some random shell company being run by some secret service.

As a EU citizen, sharing your data between Apple and Google which puts said data under free-for-all US intelligence access - which is known to have "questionable" habits and give basically no rights or insight as a to-them foreign citizen - is effectively trusting "some secret service".

To be clear, I am not one to fear use Apple for intelligence reasons, but not through a pretense that my data is safe from it, and certainly not because I believe it would be safer than using, say, a service based in Germany or France.

I'm more concerned with data brokers trading personal data out in the open, collected with minimal control from all the other apps and webpages we use throughout our day.

I get sad reading the "What EU users are saying..." messages. A lot of them seem to be Apple fans that just bought their evasive narrative.

I fully understand that some Apple users are perfectly happy with Apple's closed garden, but they must understand that its primary and almost sole purpose is profit maximization and the counter-arguments to opening up are purely about avoiding any risk to said profit.

While there could very well have been technical considerations to be had, all their answers to DMA have been lies, non-compliance and malicious compliance, as they have no intention of discovering whether their margins relied on the walled garden or not.

I personally suspect that the impact would be quite small exactly because Apple users tend to enjoy and stay within the Apple experience (myself included when I used Apple products - there is no harm to prefering that user experience), but they don't intend to risk parting with as much as a cent regardless of what benefits users, and will happily burn money lobbying against that.

They do not have your interests in mind here, and their way of maliciously presenting this such that you as a user will be bothered and blame regulation for their "inability to deliver" is very much lobbying 101.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

I have seen such detailed and tidy whiteboard diagrams, but the catch is that they never occur in active discussion. It doesn't make room for scribbling, and stopping a discussion for 5-10 minutes to draw slowly and nicely doesn't make sense...

You could turn clothing descriptions into embeddings and have a fashion vector database, but doing that would mostly just net you the ability to find adjacent clothings, rather than the ability to navigate available clothing or clothing fitting certain requirements.

What was done is more like using the LLM as a personal assistant that doing long manual labor to find what you might be looking for.

This way of shopping is already a thing. "Hype and investment" goes into how the companies can monetize AI harder (ads! integrated LLM shopping! business development! premium pro max enterprise data policies!), it doesn't really focus much on how the individual can save time and money through non-flashy tasks.

Being able to push prints and use the printer with direct local connection, while simultaneously having remote monitoring and remote printing when cloud/internet works and is available.

This is not the case of "wanting to have their cake and eat it too", as there is nothing mutually exclusive about these things. It requires no "emulation" or hacks - having a local API open to query state and push print jobs to the queue, while the printer connects to the cloud to publish state and pull the next job, presents no conflict.

Ultimaker has a similar feature set and had full local/cloud simultaneous integration. The only thing you "lost" by pushing a job locally was that when viewed in the cloud portal, the mini 3D model preview in the queue was missing, and only because they never bothered making the cloud solution pull it from the printer for local jobs.

But then they also did like Bambu and killed local printing entirely because they are all enterprise-only now want to sell you their higher Digital Factory subscriptions.

What "ai" got to do with that would be that he didn't write a scraper and a clothing style ("vibe") categorizer to build a database to process entries in to pick a shop. They just prompted the "ai" (I really don't know why you're putting that in quotes), and it in turn did that for them.

Was it a technically impressive effort from the prompter? No. Are the tools created in the session somehow a massive technical achievement? No. But was it a very useful result? Yes. It took the kind of task that would likely never get done otherwise, and turned it into the kind of thing that got done on a whim.

Doesn't mean that your laptop needs "AI buttons" though.

I disagree, because when someone can just get those simple works made on a subscription you already paid for, then the $5 commission goes from something someone might end up doing if the idea is stuck in their head long enough (or they find the idea amusing enough), to be something that can never become a commission.

Not pointing fingers or saying that you must pay kids to draw things for you, but it most definitely does take work away by replacing an entire class of commissions. Not sure what to do with that fact.

(I'd put things that would never, ever be worth a $5 commission into the throwaway noise category, even if you do use the outcome.)

Yes, but this is a bit of an oversimplification. The "99%" tends to be either: 1. Pointless throwaway content which we can just ignore as a new source of noise, 2. Something that could have ended up being a $5 commission[^1] to a kid somewhere out there but now never will be.

Those numbers are also a bit too aggressive - it's easy to miss what kind of gig work exist out there. PowerPoint as a service is a thing on Fiverr for example. A horrible, horrible thing, but a thing none the less.

^1: not at all what art costs, but someone trying to get started might do quick sketches at those prices

That's an entirely different problem to artists getting "shafted". Not saying it's not a worthwhile discussion, but it is a separate concern.

Having everyone pay phone/internet, office, streaming, music, etc., subscriptions to large tech companies that are effectively monopolies all do that. It's a bigger, pre-existing issue.

I have never seen an IR-based on in any store myself. Bluetooth, and possibly some proprietary RF setup, seems popular.

This is, in my opinion, attempting to say the right thing with entirely the wrong perspective:

The people you say are getting "shafted" always got shafted. Their works are the inspiration for all artists and people who lay their eyes on it - maybe they got paid when they made the work, maybe they managed to sell it, but probably not. And still, other artists (and machines) will use remember and be inspired by it, sometimes to the point of verbatim copy (which is extremely common for human artists as well, with verbatim copy and replication being an actual sought after skill).

(Those about to shout "LICENSING", that's a very new invention and we're terrible at it. What are you going to do, cut out the part of your brain that formed new connections while touching GPL code?)

The person (singular) that is actually getting "shafted" at each use is the artist you didn't hire to do the job of making your new work, because it is their skill that got replaced. A skill build from a lifetime of studying other art and practicing themselves, replaced with a skill build from a machine studying other art and by virtue of some closed loops likely also "practicing" itself.

Still, shafting at large, but the obsession with training data is misplaced in that it entirely ignores how society and art worked beforehand.

At the same time, for most of the things you're likely using the tool for, there would probably would never have been an artist in the first place. For example, if you're just making your powerpoint prettier, or if your commission is ridiculous as it often is and yet only willing to offer a single-digit dollar sum per work which no artist should take (RIP the poor souls that take such work anyway).

Your wrapper does do a bunch of extra things that aren't necessary, but pulling in a library here is a far greater maintenance and security liability than writing those 100 lines of trivial code for the umpteenth time.

So yes you should just write and keep those lines. The fact that you haven't touched that file in 3 years is a great anecdotal indicator of how little maintenance such a wrapper requires, and so the primary reason for using a library is non-existent. Not like the fetch API changes in any notable way, nor does the needs of the app making API calls, and as long as the wrapper is slim it won't get in the way of an app changing its demands of fetch.

Now, if we were dealing with constantly changing lines, several hundred or even thousand lines, etc., then it would be a different story.

It could also be trivially written for XMLHttpRequest or any node client if needed. Would be nice if they had always been the same, but oh well - having a server and client version isn't that bad.

Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually than import a library and write interceptors for that...

(Not only because the integration with the library would likely be more lines of code, but also because a library is a significantly liability on several levels that must be justified by significant, not minor, recurring savings.)

Interceptors are just wrappers in disguise.

    const myfetch = async (req, options) => {
        let options = options || {};
        options.headers = options.headers || {};
        options.headers['Authorization'] = token;
    
        let res = await fetch(new Request(req, options));
        if (res.status == 401) {
            // do your thing
            throw new Error("oh no");
        }
        return res;
    }

Convenience is a thing, but it doesn't require a massive library.

Could also be looping videos - some browsers had bugs whereby looping videos would continously redownload.

I recall some years back having corporate IT ask me why I was downloading terabytes off this weird website called "imgur" that they didn't know about. Realized I had a tab open with a stupid jackie chan mp4 a few seconds long on some background workspace, and that had just kept downloading over and over and over and over...

First thing would be that a small geofence (i.e., a narrow church on available data) is entirely orthogonal to having high precision, high quality location data available.

I won't claim with certainty that this is the case, but it seems likely that Factual was overselling their capabilities. That, or they relied specifically on having users grant high precision location data access and had nothing otherwise.

Apps that already need location data are probably the most likely sources of collecting such data - food apps, dating apps, chat apps you have sent your location in, ...

And yet, who would you trust more - a CEO that raised 100M on their "vision" or someone who got slapped in the face?

Mycelium is neat, but last time I heard of it the problem was far, far too low manufacturing throughput.

I don't think anyone would even consider marketing that as "vegan leather", as doing so would mean putting you in the same bucket as cheap-as-dirt polyurethane (which is what regular "vegan leather" is), at an astronomically higher price. You'd pick a new term to differentiate.

I vote for "shroomskin".

A good example for the discussion: leather being animal skin which obviously cannot come from a mushroom.

Assuming you were countering my vegan leather claim: Products marketed "vegan leather" is polyurethane or similar, and for marketing reasons you would use a different term if you did something fancier to differentiate. My gut feeling is that a mycelium-based product would be far more expenisive than simple polyurethane, and quite an upsell.

We also shouldn't call it "vegan leather" when it is in fact just plastic.

Naming departs from technical accuracy when adopted by the masses, as they retrofit their common understanding. Wouldn't be too surprised if "vaccine" ends up covering other strong defense-boosters.

Their subscriptions aren't cheap, and it has nothing really to do with them controlling the system.

It's just price differentiation - they know consumers are price sensitive, and that companies wanting to use their APIs to build products so they can slap AI on their portfolio and get access to AI-related investor money can be milked. On the consumer-facing front, they live off branding and if you're not using claude code, you might not associate the tool with Anthropic, which means losing publicity that drives API sales.

Well, not really. It means you have a renderer that is closer to being portable to web, not an editor that will run in web "with some additional work". The renderer was already modular before this PR.

With the disclaimer that I am comparing to the memory of some entry-level cameras, I would still say that it's way too noisy.

Even on old, entry-level APS-C cameras, ISO1600 is normally very usable. What is rendered here at ISO1600 feels more like the "get the picture at any cost" levels of ISO, which on those limited cameras would be something like ISO6400+.

Heck, the original pictures (there is one for each aperture setting) are taken at ISO640 (Canon EOS 5D MarkII at 67mm)!

(Granted, many are too allergic to noise and end up missing a picture instead of just taking the noisy one which is a shame, but that's another story entirely.)

Rather than a moat of details, it's first-mover advantage. Anyone can run a credit card network, but merchants and banks need to support them. Many others exist, but the issue is that they don't have widespread adoption. Solutions that work exist, which means the lesser supported alternative is not widely used, which again reduces reason for wider adoption...

Regulation changes "why bother" to "oh crap".

> I start getting the feeling that you're involved in keeping the package repositories stuck in the past.

I start getting the feeling that you have no actual experience in threat modelling.

You don't call it "cherry-picking" when a person lists fundamental flaws in your argument.

Constantly ignoring all the flaws outlined and just reiterating your initial opinion with no basis whatsoever is at best ignorance, at worst trolling.

HTTP with signed packages is by definition a protocol with authenticated payloads, and encryption exclusively provides privacy. And no, we're not singeling out the least likely attack vector for the convenience of your argument - we're looking at the whole stack.

The real outcome is mostly a change in workflow and a reasonable increase in throughput. There might be a 10x or even 100x increase in creation of tiny tools or apps (yay to another 1000 budget assistant/egg timer/etc. apps on the app/play store), but hardly something one would notice.

To be honest, I think the surrounding paragraph lumps together all anti-AI sentiments.

For example, there is a big difference between "all AI output is slop" (which is objectively false) and "AI enables sloppy people to do sloppy work" (which is objectively true), and there's a whole spectrum.

What bugs me personally is not at all my own usage of these tools, but the increase in workload caused by other people using these tools to drown me in nonsensical garbage. In recent months, the extra workload has far exceeded my own productivity gains.

For the non-technical, imagine a hypochondriac using chatgpt to generate hundreds of pages of "health analysis" that they then hand to their doctor and expect a thorough read and opinion of, vs. the doctor using chatgpt for sparring on a particular issue.