It's not hosted on "our own website" - our licence fee isn't paying for it, neither is HM Government; hence we cannot read it because the BBC cannot engage in commercial activity - I assume it has ads, or maybe a paywall - in the UK.
> BBC WORLDWIDE IS THE MAIN COMMERCIAL ARM AND A WHOLLY OWNED SUBSIDIARY OF THE BRITISH BROADCASTING CORPORATION (BBC). OUR VISION IS TO BUILD THE BBC'S BRANDS, AUDIENCES, COMMERCIAL RETURNS AND REPUTATION ACROSS THE WORLD.
> BBC Worldwide helps keep the Licence Fee as low as possible, returning £222.2m to the BBC in the last financial year, an increase of 17.6% from 2014/15, adjusted for disposals, and equivalent to 13.0% of BBC Television content funding in the year.
Why, though, they don't duplicate the content with the IP-restriction instead of paywall/ads/whatever it is, I'm not quite sure.
Not an expert, but what you describe is testing different parts of the system. Real world data tests that the sensor system is creating an accurate model of the environment, whereas simulated data ensures that the vehicle makes correct decisions for any given input model.
e.g. real world data tests that the vehicle can detect a stop sign. Simulated data tests that the vehicle stops at a stop sign.
Having a space station is not important. Having the infrastructure to build and maintain a space station is important.
When the US stopped sending people to the moon it stopped to be capable of sending people past LEO. A space station at least ensures that we can still send people to space.
But we (USA) can't still send people to space. We voluntarily gave up that infrastructure years ago and have no clear, funded plan to restore it.
For manned spaceflight, NASA's top priority should be basic research into breakthrough propulsion technologies. It's pretty clear that we'll never be able to safely send a large number of people anywhere worthwhile using chemical rockets.
We do have a funded plan to restore it. SpaceX and Boeing have contracts to ferry people to the ISS, starting in a year or so. Both of them have constructed serious amounts of hardware, both the capsules and the pads/towers required to launch them.
I'm arguing for choosing dependency versions that don't require you to break the highlander rule. "a is updated to 2.0" doesn't mean you should start using that version of a right now.
Right but what I'm saying is that two versions of the same library will live quite happily together, because node.js absolutely abhors global scope. The two versions have their own module-level scope to store functions and data.
So go crazy and install every version of lodash! Nothing will break.
That will work for lodash, because it's just a bag of functions. But anything that creates objects that are passed outside of a single module could have problems.
That seems to be a slightly different situation? As the issue poster described, a single page had invoked two copies of React, both of which assumed ownership of a particular "global" variable. (Not really global, but a particular member of a global.)
I'm not a React expert, but I don't see why that situation would only affect multiple React copies with different versions?
I'm not a large JS developer but with my other experiences managing dependencies, it doesn't always allow this as a possibility. A bug in your system is tracked down to the library b using x@1.0 but the fix is to upgrade to b with x@2.0 however a using x@1.0 doesn't have an upgrade path. Waiting for another company or organization to release with an update is not an option. Our projects have several cases of requiring different versions of the same library -- we try to avoid this using the same logic you suggest but it's not a possibility in all cases so we have to work with it.
It's placing your own release cycle at the whims of your dependencies' release cycles. In the corporate world that would not be a viable solution.
It's almost certain that a's version of x and b's version of x have distinct types whose names collide, and I don't know of any Typescript or Flow notation to prevent passing incompatible instances between them (e.g., a wants to call a method that didn't exist in b's version of x), so if anything works it's only by luck.
Node's module system doesn't import dependencies into a global namespace. So the `x` required by `a` and the `x` required by `b` will have separate namespaces and won't conflict, or even know of each others' existence. There are pros and cons to this approach, but it definitely does work. Flow, at least, (and presumably Typescript) understands the module resolution logic and handles this very common situation without issue.
It's not possible to import two different versions of a module in the same module.
If a depends on x v1 and exports this dependency then your application also imports x v1.
If b depends on x v2 and exports this dependency too that means your application is transitively importing both x v1 and x v2 which is not possible.
If a or b only use instances of x internally and do not accept instances of x as parameter or return an instance of x they don't have to export their dependency on x.
If either a or b do not export their dependency on x then there is no problem. Your application will only depend only on x v1 or x v2 directly.
Marriage and religion are both prehistoric. They are cultural universals, present wherever you look.
The ubiquity of marriage across vastly disparate cultures means either that there's a strong force compelling all societies to develop it, or it's so old that we took it out of Africa with us.
Mobile devices are ideal candidates to be thin clients, because they are battery powered.
If most instances of greater capability can be implemented as a thin client, then it's not CPU performance that is the bottleneck, but mobile ISPs and aged infrastructure.
It's funny that the MIT license has the reputation of being "The license you choose when you don't care about attribution, or it would be unreasonable to require attribution".
As the article points out, copies of MIT licensed code must include not only the copyright line but the whole damn license.
Indeed, for works where I don't care about attribution for binary users I use the zlib license [0] which says "This notice may not be removed or altered from any source distribution."
You'd still have to include the notice in any source distribution, but that's not really as onerous in my opinion, since you're already having to distribute all your source files, so what's just one more notice.
Of course, my projects normally use a language with a compiler that produces binaries. I'm not sure how this would apply to a language that keeps things in source form like javascript. Maybe webasm will become the new binary form? asm.js? minified javascript?
You'd still have to include the notice in any source distribution, but that's not really as onerous in my opinion, since you're already having to distribute all your source files, so what's just one more notice.
But neither MIT nor zlib require you to distribute any source files. With zlib it's pretty clear what's expected, but with MIT, I'm actually not sure what attribution if any is required in a binary-only distribution.
Just to clarify my previous statement. I didn't mean to imply that zlib or MIT require you to distribute your source. I meant that if you are distributing your source code (for reasons other than any requirement from zlib or MIT licenses), then it's not too much of an additional burden to include the zlib license attribution, because you'd already be including the files that I had licensed under zlib, and each of those files has a little header saying it's licensed under zlib. Including the zlib license is then not much more work than including another source file from the project.
The way I've seen MIT interpreted most often is that you have to distribute the license and attribution even for binary only distribution, or distribution in binary form as part of a larger work.
But you're right the language does seem kind of vague on what "The Program" actually means.
Think you're reading too much into it. Most software license agreements have silly rules and restrictions that nobody takes any notice of - at home. Businesses have to be more careful.
Edit: why is this at -3? You guys are assholes.