619 karma · joined September 17, 2009
https://efsa.onlinelibrary.wiley.com/doi/full/10.2903/j.efsa...
Another factor is money. The covid vaccine trials have done some testing steps in parallel that would normally be done sequentially to avoid wasting money should it fail along the way. So yes, more risks are being taken, but they are financial, not clinical.
https://www.theguardian.com/world/2020/nov/16/moderna-covid-...
Git offers the flexibility to let each person work the way they prefer, even (to a large extent) on large shared projects.
With some wrappers and hooks, you could quite easily cripple git so as to emulate most any simple VCS. The aforementioned enterprise products barely work at all, so replicating their non-functionality might require more effort.
- Those who have never used Clearcase, Perforce, or any other enterprise monstrosity.
- Those who have and suffer from Stockholm syndrome.
It's called "virtue signalling," I'm told.
Low-speed USB devices are not permitted by the spec to have a detachable cable. The fancier keyboards are probably full- or high-speed, though, so that doesn't apply to them. As someone else said, mechanical strength may have something to do with it. Keyboards get shoved around a lot, and a connector would likely break off too easily.
It is also true that Unix linkers give an error if the final set of object files to link contain more than one external definition of the same symbol. The linker can't tell if functions were marked inline in the source code or not. A definition is a definition. The Microsoft object file format might record this information. If it does, it would appear to be a misguided decision that opens the door for the kind of breakage you're complaining about.
With the inline semantics defined by C99 there are two solutions to this problem:
1. Use static inline. Any non-inlined calls will result in an instance of the function with internal linkage. Aside from wasting space with multiple copies of the same function it is harmless. As mentioned, an optimising linker might even merge identical functions across compilation units.
2. Use inline without explicit extern. Non-inlined calls result in an undefined external reference to be resolved by the linker with a definition provided elsewhere. The inline definition is only used when the function is actually inlined and never provides a non-inline definition of the function, internal or external.
Neither of these approaches result in duplicate definitions with external linkage, so the described problem cannot arise.
It's disappointing that Microsoft seem to have chosen the one approach to inline functions that results in this sort of breakage.