I actually think this is 100% the correct move practically, as someone who thinks advertising is unethical. Keeping it out of this popular option while remaining open source allows the original to be clear from "wrongdoing" here and does not put so much pressure on creating an arms race. Then, the fork just adds sponsorblock, and things are ok.
As I see it, it's similar to the situation with FOSS passkey options. Currently the big projects are complying with all of the (increasingly silly, imo) demands of the standards org. If they did not, there would be significantly more pressure for attestation, in which ultimately only Google/Apple/Microsoft-controlled options would be permitted. Complying allows a fork to patch out the user-hostile behavior.
There is no wrongdoing though, except for the people that decide to build machines to waste other's time. Imagine spending your life on that. There's no need to carry water for the people who dedicate their lives to making everyone else's lives a little worse. Like if the wealthy paid people to go around littering (which, in a sense, is basically what mailers/inserts are).
Passkey likewise is a retarded idea with no user empathy, and by going along with their demands, you still push people into monopolistic ecosystems because the only way to use it in practice is with a cloud sync service. There's likewise no need to carry water for it. Anyone advocating for it outside of scenarios where you have an IT department to maintain it is either a fool or a shill.
Also NewPipe is still niche and appeasement isn't going to do anything. They'll end you when they feel like it. c.f. the tightening of the Android software monopoly in general. At some point they're just going to block NewPipe entirely. It's not like Google is thinking "well it's okay if they block our ads as long as they allow in-video sponsors." Nor are they ever going to think "wow maybe we should have some morals; maybe our global surveillance system we've built was a bad idea. I can't believe we didn't realize that!"
Well, that's why I scarequoted it. Morally I agree with you, and for the same reason I will not support LLMs and the companies pushing them. But as it is, the techbros and the adbros will continue to move fast and break things, and nobody will check them, so if some people can divert them into breaking slightly less, it is a small consolation.
But NewPipe clearly circumvents YouTube ads so not sure how they wouldn't have faced pressure otherwise, and it's actually more so that YouTube doesn't care about sponsorship segments as they make no money from it so NewPipe would be even more in the clear if they didn't block YouTube ads but blocked sponsorship segments.
I haven't been able to watch youtube in the browser for ages. I get like one 10-20s chunk then nothing further. Do you use just the standard block lists?
Are you using a VPN? Youtube will be a jerk to those IPs. I need to set my exit node to either Poland or Albania to watch YT. (The latter incidentally is supposed to act as an ad-blocker due to local legislation banning some types of ads, but I have my own ad-blockers so I cannot confirm.)
Your experience is strange, I use the official Chrome (not Chromium) with uBlock Lite and everything works perfectly (except the 5s delay at the start).
If your answer is you tell it, then the obvious solution to improve the app is to provide a way of specifying a road exclusion list, and that is extremely feasible.
It's incorrect to assume that the information you heard is 100% an accurate representation of the scientific understanding and not information filtered through "public health" which balances that with other interests. I'm not aware specifically what was known at the time about the initial vaccine formulation, but there are several examples where there was a disconnect:
- ~Feb 2020: COVID is known to spread through and linger in the air, not just spread via droplets or fomites; public health messaging fixated on simultaneous 6ft distancing and surface cleaning rather than air filtration and masking
- Spring 2020: it's known that masks reduce the risk of acquiring and spreading infection; in the US, public health messaging stated the opposite, in order to keep as many masks in supply to healthcare workers despite a major shortage of masks
- Jan 2022: it's know that an infected person can remain contagious for over two weeks; in the US, public health isolation guidelines are reduced to 5 days due to noncompliance and in response to pressure from the airline industry, which was experiencing a significant shortage of flight staff due to COVID infection
> in the US, public health messaging stated the opposite, in order to keep as many masks in supply to healthcare workers despite a major shortage of masks
I'm saying that "experts" here is not one group. The politicians and public figures choosing what information to publicize and disseminate are not the same people as those who worked on developing the vaccines.
The issue with LLM guarding isn't that it's "excessive" in outputting edge case handling, it's that the result often ends up just suppressing an error that actually indicates there is a bug or that should be handled elsewhere in a different way.
While I've definitely experienced it I don't think this is as much of a problem anymore. It's very easy to add an instruction to projects where you want every error to lead to a top-level throw rather than be handled. I also find that when it does try to mitigate it does so gracefully with a path you would actually make if you had infinite time, but your instinct tells you it's overkill.
I think there will be a divide. The SaaS of the future can probably absorb much more LLM use with less knowledgeable devs, because the product not being trash was never critical; it just has to be good enough that Sales can keep convincing people who won't use it to buy it for their orgs. But for things that actually need to be right, there will always be a need for devs who can understand and write code. There has already been some pullback among a few of my colleagues who were riding high earlier this year because what we're working on is more of the second type.
That's why I like to tell myself that systems programmers like me will be eaten last, but there's already so many things the agents can do better than me that I think that's just whistling past the graveyard...
No, it's actually much, much harder unless you are ignoring any of the details, which are the things that actually matter ultimately. When you were first learning did they not do the "tell me how to make a PB+J sandwich" or whatever to show you the imprecision of plain human words? You may comprehend the LLM I/O easily, but you don't know that that matches what's actually happening.
People other than you, I guess. I think your first chunk is a bit of an unfavorable perspective, but still I would take that over the second every time.
As I see it, it's similar to the situation with FOSS passkey options. Currently the big projects are complying with all of the (increasingly silly, imo) demands of the standards org. If they did not, there would be significantly more pressure for attestation, in which ultimately only Google/Apple/Microsoft-controlled options would be permitted. Complying allows a fork to patch out the user-hostile behavior.
reply