sqrt17

> selfishly lowball the cost of whatever it is they want.

if you asked a recording industry person in the CD age if 10$/month flatrate for music (as offered by Spotify, Google, Amazon, Apple) was a fair deal, they'd have said the same or worse.

The point is, there's enough people willing to pay something but now paying exactly 0$ and not willing to pay north of 200$/year. And we're still stuck at the "newspaper bundle" stage where publications that used to bundle articles into a mass-produced paper copy and distributing them want to use that same one-size-fits-all bundle for how they charge users, even if those same users would only ever read articles by one author on one topic.

Bug bounties work well for publically accessible systems, e.g. a site's web service. As a result, many of the more visible break-ins occur through phishing or spear-phishing and combine social engineering with malware as well as classical intrusion techniques from within the network perimeter.

You're missing the point here. The point is not to find ways to sell/rent out software (these already exist) but to monetize open source projects in a non-forced, non-compulsory way.

So, instead of selling your songs on a CD for a fixed price, that approach would be more like busking or having your music streamed on music services (Spotify, Apple Music, YouTube Music, etc.). It's unlike begging in that you do provide valuable goods with the expectation that the community is paying, and that providing better value (more catchy songs) will get you more revenue.

Non-required payments already work ok in a number of shapes for music and video creators, and we've seen some success in terms of feature bounties and direct sponsorship in software.

Given that enough people are willing to support the software they use, there are two things missing in the equation

- an entity collecting, pooling, and distributing money in a transparent (enough) fashion - the prime candidate would be GitHub because it already has sponsorships and the necessary bits of information

- an attribution model; and this is a bit harder for software than for music or videos where you can simply use watchtime as an attribution metric. Software has a more complex dependency graph, and arguably open source software is the silver bullet that allows us to stand on the shoulders of a herd of giants instead of implementing our bloom filters, routers etc. ourselves. This is a hard problem, and arguably one in danger of not being solved "correctly" in that an entity collecting money could do something intransparent and unfair and people might still sign up because it's the only game in town and they want the warm fuzzy feels and the convenience of not having to write 0.50$ checks to a gazillion small-project maintainers.

every couple decades, there is a new approach that promises to do solve more of the language understanding problems with less of humans actually thinking about and understanding the inner workings of language. Each time we get a phenomenon which is best described with the hype cycle analogy, namely consistent progress of what it can do, along with even faster progress of what people expect from the technique, until the actual progress cannot keep up with expectations and we settle at a new (much progressed but much disillusioned) level.

BERT, GPT-2 and now GPT-3 have brought us to the tail end of such a hype cycle, with the most enthusiastic DNN enthusiasts still claiming that it's understanding meaning and general AI isn't far off, whereas the folks who give out ACL Best Paper awards (all long-time experts in their field) probably sigh and are thankful for a paper that breaks with the hype and tells the overenthusiasts that there's still stuff left to understand and discover.

Do we need mediocre philosophical papers when we can have mediocre technical papers (or even fairly decent technical papers) instead? Hell no. But do we occasionally need a good and thoughtful philosophical paper to sober ourselves up? Admittedly yes.

Why is it ridiculous to you that people want and need both shelter and access to a way of sustaining themselves? The comparison between a Porsche (essentially a status symbol that you buy so that people around you see that you have money - given traffic regulations it isn't really a way of making your daily commute shorter) and housing (which is a necessity) shows that you don't have a good grip on reality. And you don't want all bus drivers, garbage men, supermarket cashiers etc. to move to Texas and bring your garbage to the landfill by yourself.

according to that logic, lawyers, CEOs, line managers and HR should be paid what they were 100 years ago, as they do not directly produce. They're not, it's effectively through competition with other jobs that their pay is determined.

Intuitively, "pay according to productivity" makes sense, but productivity gains have far outpaced the pay of workers while the money went elsewhere. Let's face the reality that productivity prescribes the total sum that goes around but not how each individual's contribution is credited in a society.

GPT-3 is too large to be useful for practical purposes. Look it up. It's the equivalent of a Formula 1 car or a Saturn V rocket - an impressive feat of technology but of no practical relevance for getting you to work and back.

And certainly fine-tuning and distillation are part of the story why we wanted these large do-all-be-all models in the first place, but the question of what's next for the state of the art - and that currently would be featurization through a large transformer model (i.e. BERT, ERNIE, GPT-2) with some deep-but-not-huge task-specific model on top - isn't simply answered by "more compute".

Here's a thing: incorrect assumptions that are built into a model are more harmful than a model that assumes too little structure. If you model the vocal tract and the actual exciting things are the transient noises that occur when we produce consonants, at best there's lots of work with not much to show and at worst you're limiting your model in a negative way. That's the basis for the "every time we fired a linguist, recognition rates improved" from 90s speech recognition.

On the other end of the spectrum, data and compute ARE limited and for some tasks we're at a point where the model eats up all the humanity's written works and a couple million dollars in compute and further progress has to come from elsewhere because even large companies won't spend billions of dollars in compute and humanity will not suddenly write ten times more blog articles.

A "?" email is a result of exactly that - one of the clowns made an unfunny joke and the customer went to the circus owner.

I wish someone would build that and force you to use it for the next six months.

NTMs and similar are very slow at learning, and would (e.g.) not pick up on the fact that you've created a directory until you've interacted with it a couple thousand times.

Yes, a linear weighting of factors would be perfectly fine.

But we're in 2020. A small two-layer MLP has a negligible impact when compared to the work to (e.g.) output the current git branch at every command prompt.

It's a WM (Window Manager). It only sets the placement of windows, it does not interfere with the programs themselves (that's what systemd and gnome-session do) nor does it do the fancy part of the painting (that's what a compositor does).

So no, do not expect a significant performance penalty.

You may be lucky - people from NTT have published a model based on JParaCrawl - a large JP/EN parallel corpus, which can be used together with fairseq

http://www.kecl.ntt.co.jp/icl/lirg/jparacrawl/

There are many high-performing machine translation toolkits that use PyTorch these days:

- OpenNMT-py (OpenNMT, but Python!)

- fairseq

- JoeyNMT

In addition, you can also try

- tensor2tensor (Tensorflow)

- Sockeye (MXNet / Gluon)

1) vim is easier on your hands if you're on a high-latency connection (i.e. usable in a terminal) and/or get tired of chording (i.e. having to press Ctrl along with random keys).

2) I've found vim's plugin systems (Pathogen, Vundle, vim-plug) vastly more intuitive than Emacs' version with package-install and activating one of several repositories (Milk, ELPA, MELPA, whatever) - you install the same plugin regardless of whether you're using Vundle or vim-plug

3) vim and its packages are vastly easier to configure - this is subjective and may be much improved in Doom Emacs/Spacemacs, but in general vim packages have a bunch of global variables that you can set to a number or a string whereas most emacs packages need you to define elisp functions and/or nontrivial data structures, with no sane defaults to fall back on if you want things just to work

it also has notepad++ at 30.5% - I've seen one or two people who would use notepad++ when nothing else is available, but I don't think many people have it as their primary IDE.

Also, if you sum up all the JetBrains products (which you can get as IntelliJ Ultimate if you shell out the money), you land in the vicinity of 63% (not vim-related but a neat fact)

Fun fact: niche is a French word that doesn't have an accent. So niché is the heavy metal ümlaut version.

maybe "they were successful in a period that comes quite close to where we are now"? People forget that success is not an immutable attribute - it is the sum total of hard work and decisions that are put in every week, every month, every year, over a longer period of time. But as much as it is the product of a longer period of time, success can wax and wane throughout the decades and a company can be wiped out or acquired on less-than-favorable terms if they fail to adapt to the next large-scale change in the industry.

The insurance policy would be tied to following some (infosec) best practices. In the best of all worlds, insurances would then check on their customers to make sure best practices are followed in the same way that we follow best practices for avoiding fires in terms of building construction and not having flammable materials lying around too much.

"Software Entropy" sounds so much more scientific and general than "avoid stringly typed code"

BTW, "stringly typed" has been in use for exactly the behavior to avoid for maybe 10 years now https://wiki.c2.com/?StringlyTyped

Is there a similar tool that you can throw at Electron/NodeJS apps to figure out why Slack and Teams are eating all the CPU and memory again?

I'm not anywhere retiring yet, but when Python came around the corner, I thought, well it's as well-suited as Perl for larger things (i.e. not one-liners for text processing - those are a reason for keeping Perl around) but with a cleaner structure.

And that was at a time where you still (occasionally) had to write your own string replacement function that a weirdo company-specific BASIC dialect didn't have.

There's never been a language that I thought of as "Python, but with a cleaner structure", even though Go may be something like "Java 1.2 but with a cleaner structure and a fast toolchain"

> summarize it succinctly in a blog post

as far as I can tell, that part was a failure. There's no content in the blog post.

There's a whole class of solutions beyond Selenium that automates not just web apps but all apps. It's going under the name of "Robotic Process Automation" and people really like it because they're not dependent on their software vendor to get basic integrations done.

A surprisingly large subset of those tech folks can and does improve the UX of their Mail and Chat life using basic scripting on top of a simple but flexible UI. Both Slack and Hey say F U to that and force you to do everything your way. No standards compliance, no tailoring of the UX to your actual needs.

the cure to that is a field where independent people can also contribute to further development of existing work - through making sure that resources used and code are published along with the paper.

Of course, this is hard to do with cell cultures and such, and in the case of large databases or compute-intensive tasks it's not quite feasible. But a surprising amount of what goes on in CS and neighbouring disciplines can work that way once you work past the reticence of individual established authors and set it as a goal for your (sub-)field.

GOFAI basically consists of inference and reasoning techniques, some of which cease to work well when you scale them up too much (computational complexity) or when there is uncertainty involved. There have been some efforts to scale reasoning towards greater scale (description logics) as well as problems with uncertainty (ILP, Markov Logic), but they've been de-emphasized or forgotten in recent times because you get a lot of mileage out of end-to-end deep learning - where essentially hidden state within the network deals with the uncertainty on its own, and where the additional compute overhead + rule engineering effort doesn't seem warranted.

It certainly worked for them. But results are not typically indicative of risk, so anyone doing X may doom themselves by doing something that doesn't work in their special context.

You can get it from different vendors and the solicitation behaviour is just detracting and horrible. It's understandable from the standpoint of the widget maker if more interactions mean more money, and it's understandable from the standpoint of the web site if they think it gets them more stickiness but what it really does is have an idiot greeter kiddo interrupt their actual sales funnel.

Maybe a better way to put it would be "Graph Neural Networks are a Generalization of Transformers". The formulation of "X are Y" indeed suggests that you could just have stuck with Y instead of using the special case X, whereas in reality they took Y and added something to make it more general.