> The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
> - 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
What do you think status codes like 404, 405, 406 are for? You say they shouldn't be for "did the application successfully validate the user's input data" but status code 400 is explicitly for bad requests. In your view should a HTTP server ever return 4xx?
It depends how you define validate. If the HTTP headers are malformed, sure. If a JSON or XML API receives malformed JSON or XML, sure. But if it's "register this account" and the username already exists, or "pay with this credit card" but it's not a valid credit card number, or "process this invoice" but the total is missing, then I think it should be a 200 status with an error message. It's validating the request was received and loaded by the application vs. validating the business logic requirements for the request's data payload.
Obviously if you send a TAIL method request, you should get a 405, and if you send Accept: eggs/*, you should get a 406. If a route doesn't exist, you should get a 404. If you fail HTTP basic auth, you should get a 403 (but why are you using HTTP basic auth?). If you want certain paths to never be accessed for some reason, you should return a 401.
To be more precise, ZFS snapshots are mostly just a timestamp reference, similar to how a git commit is just a reference to a git object. Writes don't change the value of the files in the snapshot because they're stored in new places rather than overwriting the existing files on disk.
The fact that it’s a “non functioning future” is exactly why people are concerned. It’s entirely possible to regulate a set of activities out of existence if you make the cost of compliance too high. In this case the per user margins are low (FB ARPU is about $25 before expenses).
No it doesn't. FATCA applies to foreign corporations because otherwise the US financial system will freeze them out, moreover FATCA requires recursive application of this rule, that is part of FATCA compliance involves determining if your counterparties are FATCA compliant and freezing them out. It has nothing to do with bilateral treaties.
Slackware: I donated the cost of the DVDs plus postage. Seemed silly to shift atoms across an ocean when the bits can trickle down the phone line from a mirror server about 60 miles away.
Are there any strange tax or accounting advantages for the organisation I'm supporting if I buy actual stuff rather than donating?
I don't know about Canadian tax law, but in the US there is no benefit to earned revenue over contributed revenue, and often having a high number of individual donors can be advantageous for granting reasons.
I've seen some strange things related to exports (primarily because the law seems to be moving at a glacial speed compared to reality). So, e.g. a product exported to another country may be exempt from local VAT (so you can "zero rate" it, hence the checkbox that sometimes appears on order pages). This gets a bit blurry when it comes to digital software sales - is it a product you are shipping to another country? Or is it a service you are rendering in your own country (and thus, not exempt from VAT)?
Not necessarily better but perhaps easier. For example your employer may not have an issue with an expense charge for software CDs but might have a problem with a paypal payment to "deraadt"
The MVP for that system wouldn't be all patient data, it'd be just one metric or something that you could harden the system's other properties against. If you leak one metric, you probably leak them all (and the inverse is probably true). The training costs are amortized because they are dominated by one-time costs of learning the system for one metric, not all metrics.
