Shared dependencies or death
Docker
🤔
Shared dependencies or death
Docker
🤔
Not sure what you’re expecting that fuse to do when the battery is on fire from crash damage?
Kinda. IANAL, but here’s my understanding: If you’re explicitly dual-licensing and publish the proprietary license then contributions can be assumed to also follow the same dual licensing. You’d need to be extremely careful with writing the proprietary license though, since your business is now using non-employee proprietary code.
If you write “the copyright holder may choose to allow an entity to use this work”, then you do actually need permission from every contributor. If you write “this work may be copied, modified and redistributed freely by Blah enterprises” now the business cannot be sold without losing access (or possibly have it’s name changed). If you write “Neshura may freely copy, modify and redistribute this” then you can’t be fired or move jobs without the company losing access.
You can also never ever change this license, since every contributor needs to agree. So if a mistake is made when writing it you’re just fucked.
On the other hand with a CLA that transfers copyright ownership you don’t need to dual-license at all since everything already belongs to the business. Much less risky.
Only until you have any other contributor, as you’re then no longer the sole copyright holder. If you still want to work like that you’ll need a CLA.
TLDs are valid in emails, as are IP V6 addresses, so checking for a .
is technically not correct. For example a@b
and a@[IPv6:2001:db8::1]
are both valid email addresses.
Mesa isn’t a kernel driver. AMDGPU is the name of the kernel module and it’s primarily developed by AMD. Mesa provides OpenGL, Vulkan, etc. implementations and is funded by AMD, Intel and Valve (among others). There’s also AMDGPU-PRO which is a proprietary alternative to Mesa from AMD.
Deer had "produced documentary evidence that Wakefield applied for a patent on a single-jab measles vaccine before his campaign against the MMR vaccine, raising questions about his motives".
He both wanted to sell test kits and have his own vaccine.
In recent memory I’ve had both a microphone driver bug in Linux and one in macOS with specific hardware. Only one of them was fixed with an update.
Oh I’m sure they can justify spending the time porting the game. I just can’t blame them for not doing so when Apple’s policy is to not give a shit.
Yes, but it’s highly unlikely they can reuse that effort. TF2 uses an older version of source, so you either end up having to update everything to a newer version or redo all the effort you’ve already put in to porting source, but for an older version. Now multiply that by the number of source games.
I can see how you might come to that conclusion, but porting to 64bit is way more involved than it may seem. x86-64 is different enough to x86 that you’re basically porting to a new architecture: all your assembly will break just like it would porting to arm. On top of that all your sizes have changed and caused all sorts of bugs, for instance: long
is 4 bytes under 32 bit on all platforms, but it’s 8 bytes on macOS & Linux and 4 bytes on Windows under 64 bit.
It’s mind boggling that Apple would drop 32bit support. Adding 64 bit support can be a lot of effort, especially on older code bases, and there’s a whole bunch of games that’ll never receive updates again. You could’ve had arm32 support, with the ability to run any x86 games.
If you factor calorie intake of the bike rider you need to do the same for other forms of transportation. And if you account for the amount of exercise people are supposed to get to stay healthy there’s no additional calorie intake whatsoever.
This is plainly false. Hash collisions aren’t more likely for longer passwords and there’s no guarantee there aren’t collisions for inputs smaller than the hash size. The way secure hashing algorithms avoid collisions is by making them astronomically unlikely and that doesn’t change for longer inputs.
That’s no less true than games written in C, or otherwise with few dependencies. Doom is way more portable than RCT precisely because it’s written in C instead of assembly.