Yes. I will watch it for free as intended, nobody posted the content to be YouTube premium only, so I won't pay for it, I will watch the sponsor segments though.
I won't pay YouTube and I won't support in other forms that will let creators keep posting content on YouTube.
I'm voting with my money, I don't want YouTube to succeed as a platform, unless it becomes more open about their algorithms and their suggestions. most of my creator friends saw their views diminish two folds for no apparent reason, their video have been demonetized after years being there, because some user improperly signaled them, maybe a competitor that wanted to harm their reputation or maybe just some troll, but there was no easy way to put them back, because YouTube has no support.
Should I really pay for that?
No, thanks!
Easy as that.
It's like paying the mall because the comic book shop I like is inside the mall, so that the mall can finance and advertise all the things I hate in life, while also killing the exposure of the comic book shop.
You won't guilt trip me with your misguided morals.
> Yes. I will watch it for free as intended, nobody posted the content to be YouTube premium only, so I won't pay for it, I will watch the sponsor segments though.
Fair enough, but the grandparent's point was specifically about circumventing the ads, no? At least that was what I was addressing.
> It's like paying the mall because the comic book shop I like is inside the mall, so that the mall can finance and advertise all the things I hate in life, while also killing the exposure of the comic book shop.
But you're fine with some percentage of whatever you spend in that store going back to the mall in form of rent? Seems like an accounting detail to me.
It's easy to forget the maintainers' side of this.
Yes, most contributors will prefer opening a PR on GitHub as apposed to mailinglists. But imagine instead that you are David Miller, and it's your job to consume the absolute fire hose of patches and messages related to Linux's networking subsystem. Would you rather wade through the hundreds of messages and patches coming in every day using either GitHub PRs and issues or email?
I would choose email for one simple reason: It's easier to script.
Even as a small-time contributor and observer to that space, I couldn't even imagine trying to keep up with everything going on if I couldn't bulk download, filter, tag etc. As a maintainer it would be excruciating.
And once you've used that API to download and tag everything, what tools do you use to interactively view the results, run search queries, apply patches to local trees etc?
If your on-disk format is an Mbox or a Maildir, you can use tools like notmuch and its emacs integration to do it.
Now don't get me wrong; I love GitHub. I host all my projects there, and I prefer PRs+issues to mailinglists in almost all cases. But for massive projects like Linux, a mailinglist (and associated tooling) scales better, in my opinion.
Which eventually will change, and you have to update everything. Or the company disappears and you have to move somewhere else.
Email is just email. You write SMTP/IMAP clients today and they'll continue to work for a long time, probably longer than most platforms with APIs online today.
If they really don't think that they need to comply with any license, then why not include all private repos in the training set? Could it be that they're worried about legal repercussions, whereas OSS is easier to (ab)use for this purpose because there's much less legal muscle behind it?
It is also very telling that they have not included any of their own proprietary code in the training set. If it's merely suggestions that are generated, why not also train on the NT kernel? Office?
While it might not be a special case exactly, you most likely won’t see /bin/[ being executed either. Typically your shell will implement it as a built in command. Because as you say, spawning processes is expensive.
