> Every time this comes up there are comments assuming that ads are being injected into the normal plans
No. The distinction between the unpaid vs. cheap vs. expensive plans is irrelevant here.
The main controversial point about this topic is to include ads in the output of an LLM-backed AI tool responses. It does not matter at all in which tier it occurs.
The discussion is about the fact that it occurs in the first place.
Ok. But that is in my opinion a distinction without a difference.
It does not matter whether the ads are built by the AI itself and seamlessly embedded into the regular responses. Or just made separately and placed into the same window as the AI's output.
The bulk of the controversies in relation to doing this are still roughly the same, whatever the origin of the ads may be.
Your implication that "you will be fed" other ads if you block the main ones is unsubstantiated. But even if it was true, it does not matter. Because the so-called "opaque" ads can and in my opinion should be blocked as well.
I think that in general blocking all ads is always a good idea.
The reason is that there is no negative consequence in doing so. A person has absolutely no obligation, not even an implied one, to watch or otherwise consume any ad. I think that as long as there are ways to remove or block ads, people should use them.
That being said, if the companies wish to intertwine their products with ads that are indistinguishable from the actual content and therefore unblockable, it is okay. They have the right to do that if they want.
But, in the same fashion, the customers have every right to turn away from all such products. And never consider using them ever again.
Such a conclusion cannot reasonably be made from the data you have presented. It merely means that your web app was not preferred over your native app.
> Such a conclusion cannot reasonably be made from the data you have presented.
I’m responding to somebody who presented the following with absolutely nothing to back it up:
> Make it a PWA. This will make it accessible to many more people. Nobody wants to install an app. Nobody wants to install a PWA either but they will at least use a "web site" (a surprising number will install it if it's good).
The stats I’ve seen point in the opposite direction and I see no reason not to share that. Why are you giving them a free pass to share their opinion with zero stats but pull me up when I actually base my opinion on real stats? Looking past somebody saying “a surprising number” to complain about somebody sharing actual numbers is bizarre.
> It merely means that your web app was not preferred over your native app.
No, I’m talking about hundreds of apps hosting a wide range of independent communities. It wasn’t a single app for a single demographic.
This should not be a controversial stance. Saying that people prefer native to PWA on the desktop is not a controversial stance and the advantages for native on mobile are even more pronounced. The very existence of the App Store came about because when Steve Jobs told everybody if they wanted to build apps for the iPhone they should be web apps, the market demanded native apps.
PWA uptake is dismal. People strongly prefer native apps.
> Man, paying Google/Apple $5/mo is surely a much better solution for her.
According to which criteria?
There are values beyond "basic convenience" that are important as well. Being independent from a subscription service is one of them. Having full control over your own media being another.
Moreover, subscriptions in general have disadvantages. For example:
1. If a subscription service decides to increase their prices tenfold, there is nothing a customer can do to stop them.
2. If they decide to stop operating completely, a customer also has no say into the matter.
3. If the subscription service decides to just unilaterally stop offering the service to a particular user, they can do so at their own discretion, at any time.
This all means that whatever value is being "obtained" by using a subscription service, it is only going to last for as long as the provider wants it to last.
There are very efficient ways to block all ads, including YouTube ads. uBlock Origin browser extension is one of them. SponsorBlock browser extension would also skip over in-video ads.
This is a dishonest analogy. In your example, there is only a limited amount of cookies available. While there is no practical limit on the amount of time a certain digital media can be viewed.
You are allowed to take one cookie. But you are allowed to view a public website multiple times if you so want.
You're trying to use a quite unfunny "sarcasm" to move the goalpost to the strawman (they never claimed they handcrafted these pages) and quickly gloss ove the fact it's 20 years of work so why not?
You're ascribing an adversarial attitude to me which is actually held by nobody except yourself. The question was genuine and out of curiosity, and they can answer for themselves, however they choose. From the posting guidelines:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I am a friend, not a foe, and so are your other fellow HN posters.
> So why did you want to know if my 6M pages were handwritten
I didn't ask if they were, I just assumed so. My assumptions are sometimes wrong, though, so feel free to correct me there, if you want to.
> why was the method of production relevant here exactly?
This being Hacker News, you should expect to see questions along the lines of "how did you do that?" when mentioning something impressive you did. People here are (to grossly generalize) interested in learning how to do things, and how things work.
On the other hand, AI bots scraping stuff, isn't impressive, and having already read many posts on that issue, I'm not as interested in rehashing what we both seem to already know.
But enough about me. As long as we're going meta: Why do you want to know why I want to know what I want to know? I want to know :)
There sure is a limit in the load that the server you're DDoSing can take or the will for people to post new worthy content in public. The supply is limited just not at the first degree. Let's make a small edit: Are you allowed to take all the cookies and then sell them with a small ribbon with your name on it ?
Of course we do not. Because there is no need. The process of compiling higher order language to assembly is deterministic and well-tested. There is no need to continue reviewing something that always yields the same result.
> We care that it works, and is correct for what it is supposed to do.
Exactly. Which is something we do not have with an output of an LLM. Because it can misunderstand or hallucinate.
Therefore, we always have to review it.
That is the difference between the output of compilers and the output of LLMs.
This. The comparison between compilers and LLMs is so utterly incorrect, and yet I've heard it multiple times already in the span of a few weeks. The people suggesting this are probably unaware of the fact that Turing complete languages follow mathematical properties not just vibes. You can trust the output of your compiler because it was thoroughly tested to ensure it acts as a Turing machine that converts one Turing complete language (C, C++, whatever) into another Turing complete language (ASM) and there's a theorem that guarantees you that such a conversion is always possible. LLMs are probabilistic machines and it's grossly inappropriate to put them in the same category as compilers - it would be like saying that car tires and pizzas are similar because they're both round and have edges.
If the "bug" shows up every time in the output given the same input, then it definitely is deterministic.
Just because there are bugs does not mean a compiler is non-deterministic. I looked through a bunch of the bug reports and there is nothing there that can't be fixed to make it deterministic.
You can't fix an LLM to be absolutely deterministic, but you can fix a compiler.
In the 12+ years I've been a professional developer, I can only remember two bugs that were caused by the compiler / interpreter, everything else were logic bugs, oversights, 3rd-party libraries, misunderstanding of the requirements, internal contradictions in the requirements etc.
So that's maybe 0.1% of all the bugs I've touched.
In that sense, code generation isn't really an interesting source of bugs for the discussion at hand.
There were more ~26+ years ago. gcc and egcs had some subtle register allocator bugs that would get tripped up under heavy register pressure on i386 that were the bane of my existence as a kernel developer at the time.
It's close enough. If we had a build pipeline that kept prompts in source control, and ran it through an LLM and then a compiler to produce the build output, this would fall over constantly. You'd get radically different results every time. Build pipelines that store actual source code in source control, then run them through a compiler to produce the build output, are used all over the place and they generally work great.
This is related to Firefox unwilling to add support for WebUSB because, I suppose, they believe that a browser is not a general purpose application launcher and the scope of what it can do should be limited. As such, it should not be allowed to e.g. control peripherals like the USB devices.
Which is in my opinion a fairly reasonable take.
But given the current situation, I would assume that the companies providing WebUSB tools like installers would also spend a few moments to create e.g. a Python script that would do the same thing but locally. So that anyone unwilling to use WebUSB within their browser can have a vetted and transparent way to get the same thing done.
I am opposed to it for similar reasons as in GP, but it does let you do cool things like installing Android ROMs without touching adb by having a (presumably) WASM-based impl of adb.
No. The distinction between the unpaid vs. cheap vs. expensive plans is irrelevant here.
The main controversial point about this topic is to include ads in the output of an LLM-backed AI tool responses. It does not matter at all in which tier it occurs.
The discussion is about the fact that it occurs in the first place.
reply