sqrt17

GPLv3/AGPLv3 would still force Amazon and the like to share all the updates they make to the software itself, which is good for the software - forcing companies to be part of the software ecosystem - but not necessarily helping the (main or otherwise) developer.

The elephant in the room here is that the usual OSS-as-an-offering model works from the fact that intimate knowledge of the software and visibility creates a strong market position for selling services (SaaS or consulting) that others cannot match. Whereas if "others" includes Amazon, GCP etc., their economies of scale and market visibility tilt the playing field in the other direction, making it harder for the OSS-as-offering model.

The Linux OS, even in 1993, was a combination of Linux kernel plus GNU userland tools and compiler plus X11 plus assorted goodies from the BSD world.

Developed, at least the first bit of time, on Minix, a Unix-like operating system that a university professor wrote as a teaching tool and gave away under a shared source license.

Linux' use of GPL was better than the shared-source license of Minix because you could distribute patched Linux kernels but had to distribute Minix improvements as patches to the original distribution. Linux' use of GPL was also what led everyone to contribute back to Linux while BSD derivatives were silently used to bootstrap software (including MacOSX) that never contributed back.

Linux also shows two properties that make up successful open source: there's an "inside" (kernel-land) and an "outside", and everyone profits if the inside-OSS part is made better and better while having minor kernel improvements is not a huge differentiator for most companies.

Contrast with the Redis addons by Redislabs: they want the ecosystem aspect of open source - people contributing back patches. But they also want to be the only ones to gain a livelihood from their code (which is their right as creators of the software but not conducive to the growth of an ecosystem). And they want their license to be treated as Apache-License-related, which is the part that smells of make-believe and dishonesty. But observe the part of having an ecosystem of different software parts (here: Redis and RedisLabs' extensions) that have an inside and an outside, as well as an ecosystem of developers/users who can make and share improvements to the software.

> where developers cannot use AGPL in large enterprises

developers who cannot use AGPL in large enterprises are probably forbidden to use non-open-source software distributed under a shared-source license that allows no commercial use.

A non-charitable reading would be "we want mindshare and adoption from developers in large enterprises who will then buy or software rather than admit that they were unable to understand our terms and assumed our software was liberal open source".

To make things more concrete - while GPL allows unrestricted internal use, the horror scenario would be the contractor who is brought in to work on software including GPLd code and who may have right to receiving the source of everything (as a "derived work"). How is CommonsClause-licensed shared source dealing with large enterprises employing contractors for working with their software? Is the contractor in breach of CommonsClause but the large enterprise isn't?

> Oh, and the confusing name. Why is it called "Commons Clause"?

Exactly. What is in effect crossing the boundary between open source and shared source (as Microsoft called the first source release of the .Netruntime) is made to sound like an afterthought. So, instead of AGPL (widely recognized as off-limits for corporate users), you could claim it's "Apache plus Commons Clause" which sounds nice as long as you squint really hard.

It's ok to put software under a BSD-inspired or Apache-inspired noncommercial-only license - in fact plenty of people are doing this already - but it's disingenuous to use the name of the open source license you took inspiration from in the hope to profit from the open source halo for non-open-source software.

I cringed a little at "many of our formalisms". The maths of thermodynamics is so useful yet it took and takes substantial effort to pry the useful maths away from the thermodynamics gobbledigook that surrounds it.

But it's certainly true that Deep Learning with its combination of mathy underpinnings and poorly understood behaviour is something that fits very well with a physicist's skillset.

Let's define here "being a scholar" as having a good sense of where your field is (and for anything people are interested in, there is a field).

The standard way is that PhD students (often non-scholars) team up with more senior, well-read researchers (i.e. experienced scholars), with the latter at a minimum explaining and framing the work and in many cases guiding and shaping it.

You get marginalized by the community for bad scholarship just as proposing crappy conference talks will lead to "marginalization" by the conference organizers: there's already so much content to consume, and scholarship and other requirements serve to shape and organize people's contributions in a way that means the community as a whole can make progress.

As for advice on how to write better: Read a lot. Get rejected a lot and learn to read between the lines. If you want a friendlier environment, aim for workshops rather than major conferences. Don't be afraid of putting in the work that's necessary for a good paper.

It's important to keep in mind the exact quantity of "more practice". Current mechanisms of reinforcement learning are not very data-efficient, which means that often humans will learn faster than bots. It will still allow bots to discover any unrealistic advantage they have over humans (e.g. faster micromanagement), but if the game is fair and experience to learn from is limited, humans may still prevail.

To "beat" Atari games, AIs trained using reinforcement learning had to put in significantly more than the 10k hours one would expect a human to put in in order to become expert. So, AIs won't beat humans in tasks where training data is costly; however these cases are not interesting to researchers and hence you won't hear from the respective results.

You sound like you didn't read the article. There's nothing about political correctness or try-hard inclusivity in that article but many (or indeed all) the things that common sense would dictate as a base of working code reviews.

The answer, maybe the one you're looking for is that the schema you describe is suitable for blowing up into longform stories that could be equally well-suited to be treated in 400 words or less.

The question would be, do we care for longform as a format (as opposed to having bite-sized stories with links between them if they're part of something bigger)? Or do we care about stories that have substantial background that needs to be explained (rather than be a tangential addition to a main story)?

Go's type system with limited polymorphism looks to me like someone took the (horrible) collections from Java 1.2 and applied a fix that solves 85% of the problem. Compared to the 95% solution we get with Java, it's not as refined but also plenty good enough in most cases where concrete code deals with concrete problems (i.e. not framework-level code where you'd curse Java for lacking Scala's types-and-implicit-driven compile time contorsions).

broadcast video is delayed by 10 seconds. Apparently, that's enough to make the non-delayed stream extra valuable.

If the dollar amounts refer to the training cost for the cheapest DL model, do you have references for them? A group of people at fast.ai trained an ImageNet model for 26$, presumably after spending a couple hundered on getting everything just right: http://www.fast.ai/2018/04/30/dawnbench-fastai/

Pushover is great for events that are delayed or infrequent - say you have a job running on an AWS server and want to be notified when there is a result, or you want some alert when your traffic reaches (say) 80% of the possible load.

It's a cheap and easy service that you'd use anywhere where "then send an SMS" would be your reaction - it's like an SMS but without the cost and/or length restrictions

Quite a bit after the point where it pays to convert sed and awk one-liners into Perl one-liners and build a program around it.

Perl may be as dead as sed and awk are now, but that was the initial use case for Perl before CGI (as in Common Gateway Interface - the first primitive interface for web apps) came along.

get a free 30-day trial of Bluemix. The Watson tools are accessible through Bluemix and there's a free tier that allows you to try out things for yourself.

Anyone discussion of the (non-programmable, electronic) Atanasoff-Berry Computer will eventually segue into mentions of Zuse's (programmable, electromechanic) Z3, Babbage's (programmable, fully mechanic, only realized later on) Analytical Engine as well as Eckart and Mauchly's (programmable, electronic) ENIAC, which all were the first computer for some definition of computer.

The (electronic, programmable) chips that are in almost any device from the washing machine to the watch today are a product of a long series of inventions reaching from logic and arithmetic over the first automatons and calculation machines of the 1600s to more complex machines of the 1800s over to the development of electronics through tubes, transistors and integrated circuits of the 1900s.

And today they are a universal part of everyday life that nonetheless depends on large material flows across dozens of countries that would be in danger in any large-scale event like a World War (like the two world wars that have happened in the 20th century, and where anyone who has seen and survived that kind of large-scale war is rather old now).

Numerical version numbers in Mercurial are a good thing until they start to differ in different repository copies, after which you have to educate everyone to refer to versions by their hash instead of the numeric version

Before everyone got onto GitHub, there was SourceForge and GoogleCode. Both worked well for a lot of people for quite some while. Also, if you really want to, you can use the SVN interface of GitHub and never go through git. You could, in its time, also use Google code with git repositories but without the pileup if nice little things that make GitHub more than just a git hosting service

Why not a one-time fee? It's probably nicer for people to have a software without a built-in kill switch that will magically activate if they stop paying money

Apparently, Volkswagen's emissions regulating code was built to Volkswagen's orders by Bosch, who then delivered the code with an explicit note that that code does not fulfill the requirements to be installed in production cars.

See here for a more complete story: https://media.ccc.de/v/32c3-7331-the_exhaust_emissions_scand...

> Yes, let's have money decide who gets or doesn't get into the country, who can and cannot get hired from abroad. Isn't legal bribery great...

I'm pretty sure that people with enough money already have ways and means to get around visa restrictions by doing contortions similar to what companies do to avoid paying taxes.

As an example, the US process for H1b visas is a highly technical affair that allows companies with large legal departments (e.g. IBM) to hire people significantly below market rate while other companies would have trouble employing people from abroad on an H1b visa. This leads to a double market distortion: one is positively discriminating for companies with a large legal department, narrowing the number of positions that people from outside the US can access, and the other is that the H1b holders themselves are (if you look at the facts) underpaid in comparison to the normal US job market.

Having an auction would ensure that the corresponding money flows to the state (and can help alleviate any qualification shortage that makes it necessary to rely on talent from abroad), while making sure employers have fair and non-discriminatory access to international employees, prioritized by the value these companies put on the talent. Also, an auction would mean that the price is set by the market, i.e. if one particular field of employment has a shortage, then paying extra money to sponsor a visa beyond what other fields can pay makes economic sense and companies from that particular field would spend more money but also get a larger share of the available visa pool.

One thing that really grates me with the Idea Channel is that they (or he) usually start from conclusions and then work their way back to a one-sided myopic argument instead of truly exploring an issue.

So instead of enjoying the fact that they ask a potentially interesting question and pull out at least some relevant facts, I get worked up at all the trollish handwaving and have given up on it entirely.

For those of us who enjoy both having talking heads in our video window and interesting thoughts: Is there some YouTube or other channel that is similarly well-informed as John Green's "crash course" videos, but with a bit more of the "deconstructing pop culture" theme that underlies Idea Channel's questions (but less handwavy and contrived)?

A clearer way to write this would be, pay-per-impression stopped being the default (or only) way of doing business sometime between 1999-2001. After a brief period where ads were predominantly text-based, ad inflation brought graphical ads and CPM back and nowadays can do CPC as well as CPM or CPA (cost per acquisition) links: https://support.google.com/adwords/answer/2472725?hl=en&ref_...

But don't let your clear picture of ad spending make you ignore the fundamental fact: there's no basic relation between ad views and advertising spending. More buzzfeeds mean that there will be more ads, but not more advertising dollars, and quality/expensive sites suffer just as heavily from the ad inflation driven by cheap content sites as they suffer from the 20-30% of people using ad blockers.

Google ads used to be valuable because they were based on the content of the site you were currently watching. Doubleclick (later bought by Google) and others already did the tracking thing and didn't get mileage out of it. Retargeting (i.e. following you around with ads for something that you may buy with a more than 3% chance because you actually searched for it) is the opposite of that, purely tracking-based and mostly annoying.

ads stopped being pay-per-impression around 2001 or so. For actual money to flow, people need to click on ads. For the advertisers to want to spend money, people need to not just click on the ads but also convert (aka, go to the site and order something).

Why does this matter? If the total ad space expands, and therefore the number of ad views increases, people will still buy about the same amount of products they bought before, which means the total advertising revenue of all the sites will also still be the same.

What we'd need would be an ad blocker that allows us, at regular times, to go to a special page, get a list of all the ads, and click on some of them in a quiet moment where they don't interfere with site content. And of course all of these clicks would have to count as "organic" non-fraudulent clicks.

Usenet news and maildir are cases where current operating systems already have to cope with that kind of load, so it's definitely possible.

The question is, can this be useful without becoming a partial and bug-ridden reimplementation of a NoSQL database (just because we have NoSQL databases that fit the bill and carry less maintenance costs wrt a spit-and-glue solution).

Interesting, hadn't heard of it. Thanks!

There are several use cases where this is a sure-fire way of shooting yourself in the foot:

* if you have many records (i.e. more than a couple hundred), the file system will have a lot of work to do and the whole thing becomes sluggish

* if you want to query the data by content, there's nothing that gives you sublinear search capability here

* it's not easily possible to modify data under this scheme. If you add that functionality, you'll have the familiar choice between race conditions and added complexity. Having said that, if you don't modify the data you can also remove the store and just use the data itself (maybe encrypted if you need that) instead of the key.

As an alternative to this, consider each process appending to a file and keeping filename+offset as the identifier for a particular record. This solves at least the "too many files" problem.

Or, if you care for reading a static collection, put your Json (or some moral equivalent, e.g. msgpack) into a CDB database: http://cr.yp.to/cdb.html

Next step up: use LevelDB, or KyotoCabinet/KyotoTycoon to organize the storage.

Is the use of fret marks (the player has a piece of cardboard with lines for certain notes) a common thing among Theremin players or is it generally not done for some reason? (Intuitively it makes sense, yet it's the first time I have noticed them)

What are the assumptions behind "log plots of parametrized experimental progress"? What do these mean in the real world?

To give an example of why "pouring money into it and getting slower and slower progress" could translate into linear progress on a log plot, imagine you have to pour in x² amount of (money, people, time) to get to level x of progress.

In that case "we go slow" means, "we'll gobble up larger and larger amounts of money, but everytime people get impatient we'll have some bone to throw at them".