simonster

Some people in this post are assuming that this is something iTunes does to everyone intentionally. Other people are saying this is not something iTunes has ever done to them. I'm not sure it's worth debating whether this practice is ethical or not unless we know whether iTunes will actually delete your MP3s under normal circumstances. The one thing that everyone seems to agree on is that iTunes is too hard to use.

I doubt the problem is that academic CS researchers don't know how to publish their code, but rather that the disincentives are usually stronger than the incentives.

HN is not the right forum for this, but that's definitely not why he was banned.

WebAssembly is a neat idea, and could be useful for creating cool ways of interacting with scientific data. But a lot of code scientists write only needs to run once on one machine. And in that case, there's no reason to take the inevitable performance hit associated with WebAssembly.

If I can switch between programming languages that use 0-based and 1-based indexing without getting confused, surely you could too. If you don't think that learning to use 1-based indexing is worth it, that's fair enough, but it's pretty low on my list of things that give me trouble when I translate code between languages.

The answer to "Does X contain lead?" is nearly always going to be "yes." It's hard to get rid of all the lead atoms out of the ~10^25 going into a computer, no matter how hard you try. Even bottled water is going to contain some lead, although probably far less than a computer.

OTOH, since Apple gets to pick the question, they could have gone with "How much lead do Apple products contain?" or "Do Apple products contain harmful amounts of lead?" for which the existing answer might be more satisfactory.

If you want interactive stuff, there are plenty of Python plotting libraries that can produce interactive visualizations, e.g. Bokeh, MPLD3, or Plotly.

Yes, from the WP article (https://en.wikipedia.org/wiki/Ipratropium_bromide), the anticholinergic in Berodual does not diffuse into the blood and also does not cross the blood-brain barrier, so it seems like you're safe.

Here's the "Colin 27" brain atlas, derived from 27 scans of Colin J. Holmes's brain: http://www.bic.mni.mcgill.ca/ServicesAtlases/Colin27

Here's a lot of data from Russ Poldrack, who scanned his brain and collected behavioral and metabolic data from himself very regularly over the course of a year: http://myconnectome.org/wp/data-sharing/

If you can do a good job predicting monkey visual cortex responses with a linear combination of units from a convolutional neural network, that implies that the network and the monkey compute similar nonlinear functions of visual inputs. If that's not evidence for similar representations, I'm curious what you think would be.

http://www.jneurosci.org/content/35/35/12127/F3.expansion.ht... also shows that confusion patterns are similar for convolutional neural networks, humans, and monkeys, but not low-level visual models.

To me, the most remarkable thing about recent neural network research is that a very substantial proportion of the human brain is dedicated to vision, and neural networks can now achieve human level performance at object recognition, and with similar, robust representations (see e.g. http://journals.plos.org/ploscompbiol/article?id=10.1371/jou...).

I see two possible conclusions that can be drawn here. The first possible possibility is that neural networks really are close enough to the way the brain works, that they learn the way the brain does, and that with some algorithmic tweaks and the right training data they can learn to everything the brain does. This is the view that Luke is rallying against, and I tend to agree that it's too soon to make this claim. On one hand, the frontal lobe is not all that different from the temporal lobe. If we can achieve the same things with a machine as with one giant chunk of 6-layer neocortex, it's not too hard to imagine that we'll be able to do the same with other pieces. The problems may be different, but the biological implementation is strikingly similar. On the other hand, as sdenton4 notes elsewhere in this thread, the big difference between sensation and cognition is that recurrent processing is that the former can (apparently!) be accomplished in an entirely feedforward manner while the latter requires (or is at least thought to require for efficient implementation) recurrent processing. And just because we have efficient ways to train one kind of neural network doesn't necessarily mean they'll generalize easily to others.

But there is a second possibility, which is that neural networks don't learn or function quite like brains, but somehow both can find similar, nearly optimal strategies for encoding information in sensory domains. In this case, we're probably more than a few years away from machines that can think, but to us neuroscientists this is even more exciting. Vision scientists have been looking for decades to understand how the visual system works, and in this scenario, there's some underlying theory to vision and we have an easily observable system that implements it. Even if it turns out that vision is too different from cognition for these insights to generalize, the success of deep learning for object recognition still has vast implications for future understanding of the brain, and thus probably for future artificial intelligence. If we know the representations the brain uses, that makes figuring out the mechanism by which it computes those representations far easier than if we had to figure out both the mechanism and the representation from scratch.

So my perspective here is that we don't know exactly how far recent neural network research is going to take us, but it's hard to deny its importance. Before I started graduate school, I didn't think that machines would achieve human-level performance at object recognition before we figured out how the brain does it, but here we are. But I suppose that historically, huge advances in AI research have been followed by stagnation and disappointment, so who knows how far we'll get this time.

It's also possible that it results in an IQ increase only for a specific subpopulation that you may or may not be a part of, e.g. the linked metanalysis says that "international studies tend to find more transfer than U.S. studies" and it does not seem as though the effect for the U.S. studies was significantly different from zero.

In the metanalysis, Hedges' g is 0.24. Hedges' g is a less biased measure of Cohen's d, and Cohen d between 0.2 and 0.3 as a "small" effect (https://en.wikipedia.org/wiki/Effect_size#.22Small.22.2C_.22...). Of course there are plenty of caveats to assigning importance to effects of different magnitudes without regard to what is being measured, but this isn't a very large effect.

There's http://www.azulsystems.com/products/vega/processor, which is a CPU with special GC instructions, created by the same company as one of the most sophisticated garbage collectors. Apparently they thought they could speed things up with specialized hardware. Not sure what the performance looks like in practice, but it is interesting that it exists...

If journals ever demand code that reviewers can read (as they should IMO; who knows whether hard to read garbage is actually doing what they claim it is in the methods section, and the call for reproducibility in science is getting stronger), then academics might be forced to learn to code. And then they might want to use a programming language that's more conducive to readable code.

I don't think MATLAB toolboxes are a huge obstacle. Maybe something like the Aerospace Toolbox is useful for people in aerospace. But for people in my field (neuroscience), people end up writing their own code for their various applications anyway, because the MATLAB toolboxes are too slow or too inflexible for their use cases. The source of inertia is that everyone uses MATLAB, so they end up writing the code in MATLAB. While it takes time to overcome an established userbase, I think it will happen eventually if the alternatives have substantial technical advantages, as I believe Julia does. It only takes a handful of technically skilled people to reproduce the majority of the code in common use, and if there are good reasons for those people to write that code in Julia and for others to use that Julia code, then Julia will eventually take over.

Not two-based? https://github.com/simonster/TwoBasedIndexing.jl

The OSC Science paper separates cognitive and social psychology papers and journals, and cognitive psychology papers replicate at about twice the rate of social psychology papers. But still only a bit more than half of the cognitive papers replicate, so I think there are still deeper issues.

This is possible and I'd be surprised if no one has done it. The methodology is to inject subjects with a mildly radioactive drug that has a lower binding affinity for a given receptor than the endogenous ligand (e.g. [11C]raclopride for dopamine receptor occupancy) and then measure how much of this drug is bound to the receptor using PET. If more of the drug is bound, then the level of the endogenous ligand is lower. I don't know much of the literature here, but the technique is well-established and should be substantially more accurate than anything that measures urine or saliva.

Alternatively other people in the same building could have had roaches and somehow made FB aware of it (e.g. status updates), and FB could have targeted him based on his address.

It depends a lot on who you're working for. You might think that every professor with interesting publications at a high-ranking institution is smart, interested in their work, and invested in the success of their students. Or at least, this is what I thought when I was an undergraduate, when I did some research with some really great people. Since then, I've realized that some people of these professors are not particularly interested in science, but have big egos and are particularly skilled at promoting themselves. They're at top institutions and they are thus able to attract lots of money and smart, hard-working students, but their intellectual contribution to their lab's work is relatively small and the environment they produce within their labs (and institutions) is pretty toxic.

It's not entirely clear to me from the post whether the reason for changing the add-on API is to get rid of XUL/XPCOM (which was inevitable) or to limit what extensions can do for security reasons and/or to make AMO reviews easier.

If it's really just about XUL/XPCOM, there are promises you (by which I mean Mozilla) could do to make developers happier:

1) That you'll figure out what will replace XUL/XPCOM in Firefox before you force add-on developers to make similar changes. Perhaps there's been some discussion of this at Mozilla since https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003... that I'm not aware of.

2) That functionality provided by non-XPCOM-based APIs currently available to extensions will remain available, e.g. OS.File and js-ctypes.

3) That there will be some mechanism for overlays for future browser UIs, beyond simple browser buttons.

If it's about limiting what extensions can do, and not about the needs of new technology, I think a serious discussion needs to happen. There's always going to be some compromise between security and liberty, and developers would probably have understood if told that they have to write things in certain ways so that the browser itself can be more secure. But telling developers that they can't build what they want to build because Mozilla doesn't trust them to write secure code is more questionable. A bad programmer can write insecure code with any extension API. (Chrome's extension API didn't protect against http://blog.kotowicz.net/2013/07/jealous-of-prism-use-amazon...) I'm hoping for an add-on API that makes it easy to do common things in a secure way, but also provides an escape hatch for people who know what they're doing.

Finally, I think developers would be happier if you finished the APIs and then gave them two years. Now we know we have 12-18 months and that Firefox will run Chrome extensions, but we have no idea what else, if anything, we'll be able to do when Mozilla flips the switch and breaks our old add-ons. We have no idea whether we should start building on top of WebExtensions, switch to an extension + companion app, or just abandon Firefox entirely.

I would much rather this conversation in 2 years when the WebExtensions API is complete, or at least complete enough that we know what to expect from it, than play a game of duck hunt while you figure out the APIs and we figure out how to tailor our extensions to them, or if we will be able to at all.

Mozilla and later Firefox were browsers that were easily extensible in every way. Given experience with the XUL/XPCOM/JS stack, you can still pretty much do anything you want without too much difficulty. However, three things have happened since then:

1) No one outside of Mozilla adopted XUL/XPCOM/JS as an application platform. There are probably many reasons for this, but the main one, based on my recollection of early Mozilla, was that XUL was too slow and didn't look native, and JS was likewise too slow and not considered to be a real programming language. That has changed significantly since Mozilla's introduction, as both the layout and JS engines have improved substantially, but that was the picture at its introduction. In time, JS was revitalized, but so was HTML. HTML has now achieved some success as an application platform (e.g. Atom and Spotify), but XUL remains basically unused outside of Mozilla.

2) Because no one adopted XUL/XPCOM/JS, Mozilla stopped looking at it as an application platform and started looking at it as a legacy technology that they at one time used to build a browser. As a result, it began to stagnate, and interest in documenting things so that other people outside of Mozilla could use them waned. And because XUL/XPCOM/JS are now niche technologies, no one knows them and there's no value in learning them outside of being able to write Firefox extensions, so Firefox does not seem so easily extensible to outsiders.

3) Chrome happened, and Mozilla saw what Chrome gained by not building a fully extensible platform and wants that for itself. On the flip side, I'm not sure that Mozilla fully recognizes what it currently gains from having an extensible platform.

Sandboxing extensions' access to the file system would be acceptable. We could work with that, just as OS X app developers have. But Chrome and the current WebExtensions API don't allow extensions any file system access beyond what webpages get.

Firefox implemented file system access for extensions long before Chrome existed. They're just taking it away now.

If Mozilla wanted to go the standardized API route, they could have done that initially instead of introducing the Add-on SDK (Jetpack). IMO, that would have made more sense.

And if they wanted to, Mozilla could still allow XUL/XPCOM add-ons to coexist with WebExtensions add-ons until Firefox itself stops using XUL/XPCOM (which will most likely happen when Servo is ready for prime time). And by that time, maybe they could standardize js-ctypes as part of WebExtensions, which would address the middle 3 issues on my list.

It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status.

Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does:

- Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets.

- Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps.

- Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway.

- Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB.

- Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!)

I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions.

I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.

Matrix-vector operations are part of BLAS, and most performant BLAS packages (e.g. MKL and OpenBLAS) are written in assembly or machine-generated using a special-purpose codegen. You can't write the gemv/gemm kernel in any general-purpose language and expect to beat modern BLAS. But you can call BLAS/LAPACK from whatever language you want. This is how MATLAB succeeds even though it has a dog-slow interpreter.

GP was suggesting Word's superiority comes from its ability to read its own file format, which certainly makes it superior in practice, but has little bearing on OSS vs. closed source.

But, FWIW, most of the new "features" Microsoft adds to Word seem to be UI improvements (e.g. https://support.office.com/en-us/article/What-s-new-in-Word-...). And if you want to claim that Office is more usable than LibreOffice, and that this is generally true of closed source vs. open source projects, you won't get any arguments from me.

Microsoft doesn't have the greatest support for OpenOffice/LibreOffice odt either, although they try (https://support.office.com/en-us/article/Differences-between...).

The fact that 90% of the world is using Microsoft's format is certainly relevant for everyday use, but it's orthogonal to the question of whether an open source project can achieve feature parity with a closed source product.

File format compatibility is always hard and I'm not convinced MS does a better job reading odt than LibreOffice does with OOXML. But LibreOffice does have a reasonably comparable feature set, even if the UI is not as attractive.

The fractal nature of many of the "hallucinated" images is kind of fascinating. The parallels to psychedelic drug-induced hallucinations are striking.

I don't think mentally ill people are especially likely to rip your face off, and by insinuating otherwise you are contributing to the stigma surrounding mental illness. See http://www.treatmentadvocacycenter.org/about-us/reports-stud... for some scientific background on the relationship between mental illness and violence. I would vastly prefer to be in a room with a mentally ill person than a chimpanzee.