> 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.
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.
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.
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.
For one, I think this would be cumbersome from a debugging perspective. All of the address-to-source-mappings in your DWARF section would point to things like "lib.c:237652" instead of "lib-module.c:347".
It also means that you're effectively linking all you dependencies statically. In some cases this can be a plus, in some cases a minus. I think having the choice is important though.
I imagine there are lots of other parts of the toolchain that would have to be updated to support this workflow. Seems like a lot of hassle for something that, though at times complicated, mostly works.
I never argued that it was. Though, "embedded" covers a wide spectrum of systems. For microcontroller-based projects, then no. For bigger SoCs paired with hundreds of MBs of FLASH/RAM it can be very useful.
My original point was that claiming that Linux is partially modular while RIOT is fully modular feels like a stretch to show N lines of red crosses and orange circles, followed by one line of only green check marks.
Linux's FLASH/RAM requirements are enough to disqualify it from projects targeted by RIOT, IMHO. No need to make dubious claims of limited modularity.
I disagree. Sure, it is a monolith as apposed to a micro-kernel, i.e. everything in the kernel shares the same address space. But it is highly modular in that most drivers and filesystems can be dynamically loaded/unloaded.
The OS comparison table leaves me somewhat puzzled.
Contiki's "C Support" is listed as "partial" without any explanation. What does this even mean? It seems to me that this should be between you and your compiler.
Linux is supposedly "partially modular", whereas RIOT is fully modular. That's a bold statement.
I get that they are trying to differentiate their product. But without motivations, statements like these sound a bit hollow to me.
IHMO, threads are mostly useful for scaling a workload beyond the capacity of a single core. For all other types of concurrency problems, a single thread of execution using some kind of event loop is usually a better fit.