You make it sound like there is an obvious solution to this. So what is it? No changes ever? Make 20 year experiments before rolling out any change at scale? Hold decision makers personally accountable for billions of GDP loss? Compensate the cohort monetarily for the generational inconvenience?
> Make 20 year experiments before rolling out any change at scale?
Basically. It wouldn't require a 20 year experiment probably. Looking at whole words vs phonics as an example, you'd get a handful of schools to participate and they'd try phonics in one class and whole word in the other. By the time the kids were in 2nd grade the fact that whole word learning wasn't working and that a higher rate of kids needed remedial lessons to catch up would have been obvious. And if it had worked really well you'd expect to see that performance improvement in reading by 2nd grade too!
So the experiment would take 3 years. Though then you'd probably want a larger scale experiment. I'd think if things were going well once kindergarten finished you could probably start involving more schools in the experimwnt the next year. So like 3-6 years altogether.
We have been successfully educating kids for a long time; if we want to mix things up with some fancy new pedagogy we should absolutely be studying if it actually works before rolling it out at scale!
Err, no, it's actually really easy. Just give them a choice in the matter first. You do realize you're arguing for toying with people's futures based merely on effectively unproven methods because you just feel like doing it? Futures that have inherent value because the people being toyed with are inherently valuable too. But no, it's totally fine to not be held accountable for your actions. I mean, what's the real damage done here? Think about how expensive it'd be, or, or, how long it'd take if not! That surely justifies just going to town on people, right? :/
That's essentially what you're arguing. Perhaps not what you intended, but it is what it becomes given the context, and more importantly, the people involved that you disregard so callously.
If it's so darned expensive to do, have you considered that you have the free will and intellectual sophistication required to just . . . not do it? If it'd be so expensive to recuperate a group of people, either your methods have too high a probability of requiring it or your method is just perhaps not ready yet if the potential end result are that disastrously bad. Either way, it points towards going back to the drawing board instead of to town.
But if it's oh so difficult to get these studies done, you know what you can do? You can do it over longer periods of time, just like you bemoan, because that larger time scale will stop you from ruining other people for your own curiosity of will x work in y. You could give people the choice to join the study, you could have smaller cohorts every time and refine the process as you go, you could keep each cohort limited to a year or two to avoid long-term damage, and you could test in different age ranges to get more data.
The list goes on and on and on. Almost like studies on people require larger caution than just testing to see what works without any precautions and going from there. When learning about the scientific method, the idea that people are, you know, people and not test subjects is pushed constantly. Because certain people sadly need that reinforced to avoid being callous researchers. It's oh so easy to forget the numbers you toy with are real lives with real value regardless of what is done with those lives.
We trade immediate results and dubiously better efficiency for larger time spans exactly so that we can ensure the people in them remain protected. Giving people choice in the matter, and letting guardians weigh the value proposition (like other studies have done successfully) by giving them the prerequisite information required to make those decisions, allows for a higher likelyhood of avoiding disasterous effects on those very same people. It's not "generational inconvenience" when lives are affected for multitudes of years; it's callous impatience. It's not "no change ever," is respect for the people involved in attempting those changes and respect for the potential ramifications of those changes. It's borderline evil to disregard people because you, and I do mean you here, don't have the patience to ensure people's safety because, oh no, it'll take a while, or cost a lot if you're held accountable.
Rather, it's okay that things take time, it's wanted that we don't make haste. Because haste makes waste. Because we don't need immediate results. Because we're not working with machines, we're working with the single most valuable thing we have on this earth; a human life. Have some compassion for those people, and you'll find that change doesn't take so long after all.
That's a lot of words reiterating how intensely important the matter is. I agree, it is. But your suggestions are either doing nothing out of caution, vast fragmentation, or too small numbers to really see the effects at scale.
Mostly it's a question of middle ground for an acceptable scale of decision, but "only change something if we know for a fact it's purely beneficial" is not a realistic plan no matter how intensely important the matter is. At some point decisions have to be made.
This is one of the things that becomes harder and more entrenched the worse those decisions are democratically legitimated. I think it's not unlikely that the difference in expectations between us boils down to a general different level of trust in authority.
The mv3 problem was never about "does it work now". It was about "can it keep up". Ad blocking is a cat and mouse game, and the mouse is kneecapped now. You're being slow boiled.
There is a faq entry about that on tfa. The main differences are use of rsbuild (not a big diff down the line I expect, since vite uses rolldown now), and design to accommodate llm agentic development.
Yes, the overall framework design is different. This isn't just a superficial Vibe coding project (although AI was used in its development), but rather the result of my long-term experience developing browser plugins. Incidentally, I'm also the author of the browser extension Video Roll (https://videoroll.app). The main differences are as follows: 1. First, it's based on Rsbuild. If you install it via `pnpm create addfox-app`, you can quickly integrate unit tests (Rstest) and analytics reports (Rsdoctor), and use it simply with `addfox test` and `addfox dev --report`. 2. The extension supports three paradigms for entry point identification: first, automatic file-based identification (which needs to follow AddFox rules); second, it supports directly writing the source file address in various fields of the manifest (e.g., `background.service_worker: 'myBackground.ts'`); and third, it supports custom entries.
3. For automatic browser startup, a default address is set for most Chromium-based browsers (if no custom address was selected during browser installation), so you don't need to configure it to start automatically (supports Vivaldi, Opera, Arc, Yandex, etc.).
4. Using the Rsbuild plugin, if --debug is enabled, error monitoring code will be injected in dev mode, which will output errors such as content_script and background to the terminal, making it easy to directly copy and tell the AI without having to open the browser's devtools.
5. llms.txt/meta.md/error.md were generated, containing basic source information for the project, including the entry file, version used, framework, etc. These files will be useful if you are using Agent in conjunction with Skills for development.
I agree that Vite and Rsbuild are just choices of build tools, and the difference in development experience may not be significant.
AddFox is not a perfect framework and is still in a very early stage. WXT and Plasmo are both excellent; you just need to find the one that suits your needs. Thank you very much for trying it and providing feedback.
I'm a happy subscriber, and it's certainly a big improvement over Google search. But the internet just isn't the same place it was five years ago. And as search results (for non-navigational queries) are becoming less useful by the day, I find myself asking AI to do it for me more.
There's a lot to like about Kagi, but they'll probably have to reinvent themselves if they want to grow beyond the niche that high level internet search will probably become.
Why though. Why does it need to grow beyond a niche premium option? As long as they’re paying the bills and everyone is happy why not just let a good thing keep chugging along.
Agreed. I LOVE Kagi as a search engine - so long as it answers queries in under 2s with no ads, I'm a very happy customer. I don't mind if they flirt with LLMs, but if the LLM work detracts from the search work they will lose me as a paying customer. If the LLM work slows down search results I also lose the only thing I pay for - search result response time and correctness.
I've been a paying customer since 04/2022, and have the early adopter badge. I was easily doing 600-800 searches/month, and now I do 400-300 searches. I think that's the reality. More and more people are asking ChatGPT or whatever for search.
I didn't renew my Kagi subscription, as I am now mostly using AI based search (google, chat.bing.com, perplexity). Search engine wise, Kagi was superior but it is just that traditional search engines are less and less needed with the rise of AI.
BUT Kagi is in a good spot, as they have their user data (and the feedback/upvote/downvote/blacklist feature) to train their own models on. Maybe their AI will one day be a superior search. Especially when the big ones like Google will start to enshittify the free AI tier with ads, or SEO-like AI manipulation on Google will take off.
I've learnt jujutsu. It took me a couple weeks to get it but 100℅ worth it. I've always intuitively understood git but jj does make a lot of annoying things easy. My commit history is now much cleaner than ever before. It's not for everyone though. Takes a lot of upfront investment to learn when git is often already good enough.
reply