2,192 karma · joined August 8, 2012
There's at least 2 performance dimensions for provisioning an instance: vCPUs and memory. Often also GPUs, local SSDs, local HDDs. And then you have multiple generations of hardware, which aren't 100% comparable to each other.
So coming up with a "fully systematic" naming scheme is not really possible without listing all the parameters, and then you lose the benefit of having a name.
So an explicit patent grant, even if terminated if you sue Facebook for patent infringement, is much better than omitting the PATENTS file.
The very popular OSS Apache 2.0 license includes the same language to grant a patent license that is terminated if you start a patent lawsuit. Avoid suing Google about Android patents or Microsoft about .NET patents if you are using that software.
Overall I think it's a good thing, and if enough open-source projects adopt the same rule, then it could perhaps become a poison pill that stops everyone from enforcing software patents.
For example to build a C++ project, run tests, and publish resulting artefacts (binaries, tarballs) in some release repository?
At best they will google "<profession> interview questions" and ask the first one, and do word-by-word matching on the answer.
For Electrical Engineering, the first one that comes up for me is "Why star delta starter is preferred with induction motor?".
Given that leap seconds have been added at a rate of approximately 1 every 1.6 years, we are still good for another 376 years.
It would mean that github is responsible for analyzing each license and what features they can provide for code under each license, and take the risk of potentially defending their understanding of each license in court if other people disagree. It would also mean that if someone illegally changes the license file on someone else's project and then uploads it to github, then github is at risk instead of the uploader.
A better solution would be to describe the features they provide for public repos in detail, and require uploaders to pledge that the license is sufficient to grant these rights, or that they grant the rights themselves.
Yes it does. If there's a license that says "you must not make backups of the code on Thursdays", then hosting it on github would be incompatible with the license. So is hosting other people's non-open-source code in a public repo. Github's ToS put the responsibility of checking that the compatibility of the license and github features on whoever uploads the code.
> The point was that their cover-your-ass move is preventing a large number of open source projects from being hosted on the service in compliance with the ToS.
Well, there are features that Github wants to have on public repos, for example public code search with short snippets, and the "fork" button. Their ToS has to "cover their ass" for these features, their lawyers would throw a fit if they kept the features without asking for permission in the ToS.
If there are OSS licenses that are not compatible with these features, then either the uploader or github was breaking copyright laws already.
But I'm not convinced that its anywhere as big deal as the author of the article makes it seem.
So github has public code search, which shows 5 line snippets of code with a link back to the repo. Does this satisfy LPPL's "code must be distributed unmodified" rule? Is this enough attribution to satisfy CC-BY? A reasonable person would say yes, because you can just click on the link to get to the whole repo with the full codebase and authors.txt file.
But github isn't going to take the legal responsibility of checking each license for these questions, people uploading the code will have to do it themselves. (Also, github has no way of checking that the person uploading the code actually has the right to put the license.txt file on the code).
As they say, when you upload some code to Github (or any other service or website), they are making a copy, and then more copies for backups. If the code is visible to other users, then they are distributing it to other users. If the code is searchable, then they are taking out and distributing little bits of it.
Github needs a legal basis to do all these "obvious" things - and so would every hosting service.
If LPPL requires the integrity of the author's source code, then it's not just incompatible with Github's ToS, its incompatible with all search engines that show snippets of results.
Is there anything that they are asking for in the new ToS that they have not been already doing by running the website, and everyone being okay with when they upload code?
But if you are in a position to insert "garbage data" into a commit in preparation for an attack, it will be much easier to insert malicious but safe-looking code in the first place. Omit an array bounds check, disable SSL certificate validation, or anything else that looks like a mistake but will allow you to compromise the running code later.
You would just build a hidden backdoor into the first binary blob, like a deliberately omitted array bounds check if specific parameters are used. Reviewers and tests won't find that in complied binary code either, it's much easier to hide than large amounts of garbage data, and you even get to keep plausible deniability of it being a honest mistake if discovered.
CRC-X is complicated to use and terrible choice.
First of all, it is not a single algorithm, it is a family of algorithms. For a CRC of size N, you have to also choose a N-bit polynomial, N-bit starting value, and N-bit output XOR value. There is no single standard, there are tens or hundreds of popular options [1]. The optimal polynomial depends on both the CRC size, and the length of the data you are feeding into it [2]. If you choose poor parameters, you will get terrible error detection characteristics (like allowing extra 0 bits at the start of data with no change to the checksum). If you choose good parameters, certain classes of common errors like zeroing out a block of more than N bits will still have much worse characteristics than 1 / 2^N random chance of collision.
Second, implementation in standard libraries is patchy. Most programming languages have some CRC32 implementation - but do not document what parameters they use, or use different notation for the same parameters (forward and reverse), or do not let you change the parameters, or do not let you change the CRC size, or all of these. There is no easy way to get a "standard CRC64 or CRC128" compatible across platforms without putting it together from github snippets and example code yourself.
Third, CRC is fast when implemented in hardware, but not that much faster than SHA-1 or SHA-512 in software. It's only 1.5-2.5x faster [3], and when you're doing one checksum per uploaded file or something, it really does not matter. It's going to be even slower when you don't have a suitable-length CRC available in optimised native code, and have to write it yourself in simple C or pure Python.
The obvious and simple solution is to pick a known popular cryptographic hash like (SHA-X) that is available in the standard library of every programming language under the exact same API and no parameters to configure, truncate its output to the digest size you want, and call it a day. No need to worry about error detection performance on specific error cases like long bursts of zeros, and you get some defense against malicious tampering as a free bonus.
[1] https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Standa...
[2] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1672&c...
People on salary earn a fixed amount per month - they don't get paid extra if they work an hour longer in the evening instead of shopping.
People on most hourly jobs have their schedule set by their manager. They can't pick up an extra hour of work unless their manager has some to offer, and not at the time of their own choosing.
People working on their own businesses have an even less direct correlation between extra hour worked and extra income.
Only the very few people who do remote freelance work on an hourly basis have the flexibility to decide between going shopping for an hour or doing billable work for an hour.
For everyone else, the opportunity cost of leisure time is close to 0, but they might be willing to pay for services for other reasons.
It's reasonable that volunteer developers working on an open-source project sunset old versions, and old versions of language runtimes or dependencies. Nobody wants to keep maintaining 5-year-old versions with 12-year-old dependencies when they could use their time to improve the latest version instead.
Django is one of the most "responsible" projects in this regard - having LTS releases that are maintained for three years for free. Some projects even say "you should stick with github master" for fixes :)
But it's cool that Rails has a company providing paid enterprise support after the community support ends. Their pricing is surprisingly cheap - I would expect that if an enterprise has a legacy application that must be kept "stable" and never upgraded, then they would be willing to pay $10k and upwards per month for that privilege.
But it's a huge hassle keeping application settings, development environments, large datasets or VM images, etc in sync on two computers.
With a single laptop I can just unplug the monitors and keyboard, and go to a client meeting or a hackathon without checking that everything is set up on the laptop.
One option would be to look for strategies that "look intelligent", instead of being perfectly optimal paths at every simulation frame.
Run slow pathfinding for an enemy and store the path. Have them follow the path until they hit a player-created obstacle, and only then re-run pathfinding. Besides being faster, this could let the players use the enemy behaviour to their advantage by creating traps or such.
Writing passwords down on a piece of paper, and keeping that in your wallet or locked desk drawer is actually one of the more secure ways of storing passwords these days.
No risk of electronic compromise, and its highly unlikely that people who would steal your wallet or break into your home are also interested in your online accounts.
https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...
> The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system.
> However, no system provides 100% availability, so the pragmatic question is whether or not Spanner delivers availability that is so high that most users don't worry about its outages.
The current laptop lineup is great, and perfect for a wide range of professions, myself included. But there is nothing for the person who wants more power, even if with more weight and cost. The desktop lineup is okay, but 3-year-old models keep being sold at launch prices, and are not practically upgradeable.
Nobody cares if HP comes out with boring laptops one year - because there's always Lenovo, Dell, etc to choose from, and for desktops you can always build your own. But if you want to stay with your software and workflows on MacOS, Apple is the only maker of Macs.
My "suggestion" for Apple would be to give up on the Mac Pro desktop line, take one high-end Dell workstation every year, and test and qualify it to run MacOS. People already build Hackintoshes, so it cannot be too complex compared to designing and building their own hardware.
This would mean that people who want to pay $10-50k, can have a MacOS computer with 44 cores, a terabyte of memory, 4 graphics cards, 8 SSDs in RAID, and so on. Add a generous "Apple tax" to make it worthwhile for Apple, and people who want the power always have one "really maxed out" option. And everyone who complains about laptops not being powerful enough can be told to get a desktop instead.
At first (especially some years ago when the catalogue was much smaller) this used to annoy me. But Spotify has made a lot of progress in side-stepping the issue.
The Discover Weekly playlist of recommended music in particular was a great invention. It doesn't matter that much if artist X's latest album is not on Spotify, as long as they can find some other music that satisfies what people are looking for. Some techno with no vocals to code to, something chill in the evenings, like a personally curated radio, not a perfect on-demand player.
Focusing more on recommending music instead of having people search for music means that they get away with missing some artists - and they can take the cost of licensing deals into account when picking the recommended songs.
I agree that strict limits on vacuum energy use are overreaching a bit, but it has had good results. People wrongly believe that energy use = suction power.
Before the limits, vacuums were advertised on how much power they use. All manufacturers had to do was to put in an inefficient motor, and stamp "wastes even more watts" on the box.
After the limit, I now see vacuums advertised with some standardised "cleaning performance score" on carpet and hardwood, and airflow per minute. Hopefully this means that manufacturers will focus on (advertising) metrics that more closely match the actual purpose of vacuums.
Now the same result could probably have been achieved with just the advertising rules. And energy efficiency & environmental goals could be achieved with pollution tax on electricity and everyone making their own decisions on energy-efficient devices. But that's a much more complicated political move, with a lot of people opposed to it.
The FizzBuzz test exists to quickly filter out candidates who really cannot code at all, despite what they say in their CV, what jobs they have done in the past, or what courses they have passed.
If you can show that yes, you understand what for loops and if statements are, and can write 10 lines of code roughly correctly, the test is passed and the interview can continue with more interesting questions.
If no, then it saves everyone time to just cancel the interview.
The more independent small bets you make, the lower the chance that you will come out ahead.
Nobody wants to share things, it's all done for economic reasons. People buy on AirBNB and Uber because it's cheaper than an equivalent hotel or taxi. People sell on AirBNB and Uber because they need the extra income.
For a short while, VC investments paid out as bonuses to the participants, and just the novelty of the thing might keep both sides happy. But eventually there has to be a balance found between "I want to pay less" and "I want to earn as much as before" and "government wants as much taxes as before".
* They have a captive audience and no competition inside the security area in the airport - people who want to sleep between flights, but can't/don't want to go through passport control, customs and security to a hotel,
* They have to be cleaned between each visitor, many times per day.
Companies have to be very conservative but thorough in the "Risk Factors" section, or get sued by investors claiming to have been misled later.
For example some of Google's Risk Factors from 2004:
> New technologies could block our ads, which would harm our business.
> We generate our revenue almost entirely from advertising, and the reduction in spending by or loss of advertisers could seriously harm our business.
> We are susceptible to index spammers who could harm the integrity of our web search results.
Parse was a:
* cloud hosted nosql database,
* with client libraries for mobile platforms,
* direct write access from mobile apps, without hosting your own API backend in the middle, and
* some methods of securing this direct write access from untrusted clients.
> These are obvious flaws in design, in my opinion, that warrant re-looking at, but to which no real improvements are being made for some reason. (Incompetence? Politics? Both? Who knows.)
You list a number of things which Python ecosystem should do better or differently, and suggest that the reason why these changes aren't getting built as fast as you'd like is people playing politics or incompetence.
Whereas in reality, the two main reasons are that the changes will take lots of effort and time, which the volunteers don't have next to their day jobs (PyPy), or that the developers have different opinions on the ideal language design, and just don't agree with you (heavy functional programming).
"It is my personal subjective opinion that you are incompetent" isn't less harsh than "You are incompetent".
There are no solutions that satisfy everyone that I am aware of yet. Guido has said in the past that he'd be happy to get rid of the GIL, and would merge a patch that solves it, as long as:
* It does not reduce the performance of single-threaded Python code.
* It stays compatible with all existing pure Python code and C extensions.
But in practice, GIL is not that much of an issue for many types of applications where Python is popular.
* It's not an issue for web apps, because these are typically served from multiple physical servers each running multiple python processes. These do not share a GIL anyway, and "thread safety" is pushed to database transactions.
* It is not an issue for apps which spend most of the time doing I/O. Most IO libraries release the GIL, and other threads can run while you're waiting for results from the database.
* It is not an issue for data science doing heavy number crunching with numpy and everything built on top of numpy. Numpy releases the GIL while doing large computations in C.
* It is not an issue for small scripts, as a "better than Bash".
The GIL is only an issue for apps that do heavy computation in pure Python code, and need parallelism within a single process (socket servers? text data processing?). As a result, many Python users just don't find it a big enough problem to be worth solving, if the solution comes with downsides for their use cases.