simon84

The project would benefit from explaining the test setup. From what I can tell (from code), the machine is probably well under capacity, so I am unsure about how to interpret the results.

If you consider that a pixel is a container for RGB value, then the length and area collapse into simple storage requirement.

When an image is some px wide and some px high, it provides a shape (ratio between them), because a camera of 12mega px isn't 1px x 12M px in shape, but it does occupy 12M storage units nevertheless.

I agree though that like many IT related terms, their usage is twisted and simplified to amplify the buzz. Because it is more marketing friendly to put a bigger number than exact dimensions and proper terminology.

This is very interesting. I have not tested it (yet) but I believe this is what will come next when talking about "AI will be everywhere".

The self-contained disconnected mode is very convenient, though it could be useful to have an "online access" mode to allow it to access the Internet and perform lookup.

You can also guide the AI to organize the codebase according to some principles and attempt to untangle the mess.

But I totally agree on the fact that it will probably look like just any other frontend.

My own guess would be that what matters most for the frontend is UX (and accessibility).

So if you are able to properly evaluate the outcome, it is probably fine.

It will also depend on the type of frontend and its target complexity. From what I understand from your question, you would handle the backend and infrastructure so these do need higher rigour.

If you apply the principle of separation of concerns, the frontend shall be decoupled from the rest and may evolve on its own end. That means that you have some degree of freedom to test and fail the frontend without harming the rest of your project.

Your end users may not like it much, but from a dev perspective, there is no "flaw".

Also consider that LLM training dataset and available data is huge about frontends, so it is way better at doing these.

Did you consider that star growth stalling could mean product maturity? We always want more stars, but if your innovators user base (those that try at the early days and give stars) is now turning to average users that will use the product without rating.

Did you witness a download rate drop too?

While I agree on the fact, this is the typical case where you need a business analyst in between to 'translate' that requirement and confront the leadership if it is unclear.

If you mean that leadership IS the business analyst, then you are in trouble :D

From what I understand of the not-very-detailed text watermark, it comes up to masking the generated output with specific bias in the weights of the token generation (or something like this). Anthropic was explaining that it would survive edits (not full rewrite). So asking another AI to paraphrase will surely add its own, but since the bias is not disclosed, it will depend on how the 2nd AI is considering the existing tokens to steer its own.

Fictive example: imagine the bias is to inject notion of colorfullness in the text regardless or its content:

"I eat an apple" becomes "I eat a red apple"

The 2nd AI is about injecting size component, so the text becomes " I eat a big red apple"

There you get both watermarks. It is not that obvious obviously

I think you are very correct here! Now imagine how much worse it can get with AI in the way.

It is as always (think cybersecurity) the cat and mouse game, what is a weapon is also a defense. You, the simple fact that you are on this very site, means that you are probably more educated to AI than most, so it is not necessarily you that will really benefit from any constraining framework.

There are many people believing in many weird theories and those are more prone to be convinced by a nice narrative. AI did not introduce that, it just made it easier and available to anyone with any intent.

The goal of the AI act is not to determine if an "oh yeah!" comment was AI generated. The target is long papers that falsely claim human review and can have real significant consequences.

E.g. research paper, law makers, lawyers, state policies, notaries,...

These are much longer content and thus statistically they will disclose a better guess at AI generated content.

Asking another AI to paraphrase will not erase the mark (which they are unaware about) but rather cumulatively add their own mark and make it easier to detect.

The problem is not to use AI, but to endorse the responsibility of the content you (as a human) deliver and somehow make sure that fake-news, biased content or unverified output is detected as early as possible.

Real +1 for being transparent about the imported libraries and respective owner/license.

I think that part of the problem is that you try to apply this to low level variables.

If you consider a framework on top of any existing language that provides serialization mechanics that include metadata about the item, then you can approach your 2 goals.

I think that one important aspect (whether that is feasible or not is another question) is to have valid coercion. JS has some, but as your example shows, it is not complete.

Is the binary equal value a requirement or is it the semantic value which can take another form but can be interpreted in the same way?

Very interesting topic overall and I've been touching these questions a bit (until I had nightmares).

> What are its advantages? > There is only one rendering engine, cutting down complexity.

Actually there are 2 rendering, the server sending HTML and the browser drawing it on your screen.

So why not push the logic and send a jpg image of the rendered content itself. Lol

The whole concept of decoupling the frontend and the backend is that they can be agnostic of each other, they need to align but it is not the same skills/concerns.

Serve rendered html like in 2000 and you have recreated a smart way to do what industry spent decades running away from.

I was not aware of this website, nice discovery

I wonder if they did vet their own process through the same channel: "The 'IsThisBS' process can be trusted to reflect accurate BS evaluation"

BS or not BS ?

It would be great to understand better your motivation and expectations from it. I got in touch once with the committee I after requalifying them as a proper sales team I ran away...

Clever trick, but not great for accessibility and screen readers.

D) is notably the one mixing best vertical and horizontal view.

I guess we are used to a horizontal layout, some try to be bold with completely vertical but it won't be easy to identify in my wallet.

So I would grant D) that fine balance argument.

I am wondering what type of workload this is for.

They give a tiny example and insist on micro, fast start, but the say it lasts up to 8 hours and is up to 16 vCPU.

What sort of app require faster boot (than lambda or ec2), but only for a limited interval, and with possibly plenty of processing power...

Maybe I am not the right target, but if you have examples so that I can better appreciate, I'd love that

I see the article focuses on tasks and things to do or not do.

These are primarily driven by skills of the junior. Though you should expect they have none.

What sort of comes out between the lines is the attitude of the person, and I think this matters most and should be framed directly.

You want someone curious that will peek beyond what you asked. Someone proactive that will not sit and wait for an assignment. Someone meticulous that will not self-satisfy of quick-and-dirty.

When said like this, the article content resonates as the consequences rather than objectives.

You are correct, better concede than argue.

What I meant was a tangent: the HTTP was designed with a strong assumption that the application implementing it (the web server) would be the one providing the logic. Hence all the RFC terminology "should", "must", targeted at the implementor.

But very quickly, the logic was deferred to a layer on top (PHP,...) which would focus on the business aspect. The wiring was strong but the contract intent is loose (the requirements on the transport do not apply to the function).

Different layers, different people involved. What survived are the more or less conventions about it, which for the ease and limitations imposed by the protocol layer, led to infinite discussions about GET having a body or not.

The whole question arises because there is this clash between transport and logic that is wired on top, not built-in.

So while indeed, introducing QUERY solves a protocol gap, the people designing the business method never cared (or even knew) about that gap in the first place. This was another people's job to try to reconcile the two.

That's why I'm saying that digging into the initial assumption that the implementor of the HTTP is bound to business-level contraints is not reflecting the reality that has been going on since the early days of the dynamic web.

This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol.

HTTP is transfer protocol. It should not ever imply anything at the business level.

Yes REST made it's worst mistake out if it by giving a meaning to the verb.

Yes proxies rule how the body is re-interpreted in spite of the will of the sender (wtf).

But the original RFC states clearly that any verb can be used. This is how WebDav normalised its own.

But playing fancy by introducing a change that all HTTP implementation will have to honor is a very bad and irrational choice.

Any idea how it got there in the first place?

We have long passed the point where there is more AI generated content than authentic human content. That will soonish spiral into uniformity and degradation (see the experiments where image generation is recursively trained on generated images).

The idea is good, but the proposal falls in the same trap.

The best case would be to issue whatever method is specified in the "method" attribute.

At the moment, it suggests to add support for PUT, PATCH, DELETE because that is the current bias in using REST. However html should be agnostic of the implementation behind the scenes and allow for any http method akin the http standard itself.

Is it a full blown browser with support for all capabilities (basically a web-view with no title bar?) or does also it attempt to block all fatigue-related bloat, ads, moving parts, auto-play videos,...?

It is all about the power of statistics and the un-humanly conceivable processing power we grant it.

I like the dream analogy framing as it avoids to personify an algorithm.

Though, the article may somewhat underrate the quality of the dream (aka code) we can get from AI. Trivial tasks have been trained so much that high fidelity output is frequent.

It is when your idea is genuine and novel that the divergence is most noticeable because there is less resemblance to mimick.

Indeed, this is ridiculous for a country that says no beer before 21. Arguing that children will learn to bypass the age restriction is equally founded as for alcohol.

Is there a way to bypass the tamer? i.e. if the implementation is actually needed for some subtle task

This is the reason SBOM is an attempt to force documenting dependencies.

It will not solve everything but it helps.

Other than that, it is a reponse to one's laziness to import a full library to use only one method... it is part of my code review to always question the need for imports and (try to) weight the maintenance cost.

EU companies are judged guilty of negligence because backups were not totally disconnected (even though distant site) and ransomware did destroy them.

So that is starting to dig deeper than a plain mistake. I guess we will soon-ish witness the first AI slop trial going on, this will be interesting to follow