Ask HN: Do you ever feel like you're fighting against imposter syndrome? - <AUTHOR> Someone just asked me this question. I'm interested in hearing how the community deals with this.
Here was my full reply:
All the time. It's just that lizard part of your brain imbuing a healthy dose of fear. That fear is just a part of exploration and pushing yourself as a person. I marvel at people who go through life effortlessly being seen as "natural" or "talented" at something. But then I remember we're all the same and perspective and optics are everything.
Managing that fear is a part of mindfulness I have yet to achieve, so I use that fear as an indicator that I'm learning and doing something new and I'm probably in over my head -- which I think is where good and new things come from. I've just learned to live with it.
The real test is this: are you going to let the fear move you, or are you going to push through it? Eventually that fear you're pushing through goes away once your actions and thinking become habit. That's where you have a new trap: complacency -- that's the worst fate. <comment><USER2> Your take on it is really helpful, thank you!

<comment><AUTHOR> Glad it can help you :)</comment></comment>


Smarkets, a London-based betting exchange startup, goes public - <AUTHOR> http://eu.techcrunch.com/2010/02/24/smarkets-launches-its-social-assault-on-the-betting-world/

<comment><AUTHOR> Disclaimer: I work for Smarkets, but I thought something from the London scene would be of interest to HN.</comment>


Three Up, Three Down about Haskell - <AUTHOR> http://engineering.sumall.com/three-up-three-down-about-haskell/ <comment><USER2> Using stack solves the Haskell ecosystem tooling problem, see [https://news.ycombinator.com/item?id=10874101](https://news.ycombinator.com/item?id=10874101)</comment>


ISPs will be able to charge anything they want if Republican bill passes - <AUTHOR> http://arstechnica.com/tech-policy/2016/01/isps-will-be-able-to-charge-anything-they-want-if-republican-bill-passes/ <comment><USER2> Scary! A free market baked into the law!</comment>


Habitat: A fast 3D simulator for embodied AI research - <AUTHOR> https://www.facebook.com/yann.lecun/posts/10155814693622143 <comment><AUTHOR> [https://aihabitat.org/](https://aihabitat.org/)

[https://github.com/facebookresearch/habitat- sim](https://github.com/facebookresearch/habitat-sim)

[https://github.com/facebookresearch/habitat- api](https://github.com/facebookresearch/habitat-api)

</comment><comment><USER2> Not sure why "photorealistic" is such a big selling point here. If we can make robots navigate in DOOM they will probably be able to navigate in Habitat and vice versa.

Low on technical detail. What can this do that Gazebo cannot?

<comment><USER2> More confusion. Looking closer at the actual code, there are <20k lines of C++ code. For comparison, the Bullet physics engine clocks in at over 700k lines. What does Habitat _actually do_?

<comment><AUTHOR> From what I understand, this is not a physics engine (at least in its current form). This is a bare metal 3D environment rendering engine particularly optimized for speed; speed being especially important for training deep reinforcement learning agents for instance.

Physics would be a layer above this; I imagine Bullet can be integrated within Habitat, but will come with significant hit on speed. These choices depend quite a bit on the task being studied.</comment></comment></comment>


Ask HN: How can you make a MacBookPro keyboard productive for programming? - <AUTHOR>

<comment><USER2> Type code on it, productively.

Seriously though, where do you feel it's failing compared to other keyboards? As far as laptop keyboards go, it's one of the best I've used.

<comment><AUTHOR> Lack of single key Home/End and forward delete etc. All are somewhat possible with the Fn key, but that makes crazy combos and go to start/end of line also is a pain...

<comment><USER3> There are keyboard shortcuts for much of this behavior:

ctrl+a goes to the beginning of a line ctrl+e goes to the end ctrl+k deletes a line

<comment><USER4> I've been very productive with these key bindings. Ctrl+d is forward delete.

There's also a lot of other possibilities with plugins for a given editor, like Vim-style bindings in Sublime.

I haven't yet found any real restrictions in my workflow once I learned some of those.

Take a look at the shortcuts in nano; pretty simple stuff can help a lot. Ctrl + Y = page up. Ctrl + v = page down. Ctrl+x = exit.

</comment></comment></comment></comment><comment><USER5> Someone else mentioned Keyremap4macbook ([https://pqrs.org/macosx/keyremap4macbook/](https://pqrs.org/macosx/keyremap4macbook/)). There's a huge amount of customization there, enough that you should be good to go just by looking through the options there. My favorite is remapping Caps Lock to Left CTRL. Then you can remap Left CTRL to be escape by itself, and CTRL+<yourkey> when pressed with other keys. It's very handy in Vim, especially.

A couple other recommendations, however:

BetterTouchTool: The MBP trackpad has a surprising amount of complexity in terms of recognizing gestures. BTT adds to that . [http://www.boastr.net](http://www.boastr.net)

Keyboard Maestro: Scripting and advanced keyboard shortcuts. Includes support for per-app shortcuts, which is pretty phenomenal. [http://www.keyboardmaestro.com](http://www.keyboardmaestro.com)

TextExpander: Less practical when you're programming, but TE can be great for automating things you write often (email address, email responses, URLs, etc.) [http://smilesoftware.com/TextExpander/](http://smilesoftware.com/TextExpander/)

<comment><USER6> "A Modern Space Cadet" [http://stevelosh.com/blog/2012/10/a-modern-space- cadet/](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) is my favorite KeyRemap4Macbook/PCKeyboardHack/etc. setup

</comment></comment><comment><USER7> Get [https://pqrs.org/macosx/keyremap4macbook/](https://pqrs.org/macosx/keyremap4macbook/) , then pick the keys you need. I have my right side command and option as page up and page down, eject as (forward) delete, and PC style home/end on the arrow keys (I think that removes some inconsistencies between programs).

I had been using Windows for the previous 17 years or so, so I also switched control and command.

</comment><comment><USER8> Use a different keyboard. Seriously, I've had to take mine in 3 times now because the keys keep breaking their hooks and flopping around. Right now my 6 key is feeling like it is about to go.

</comment><comment><USER9> Make the thing using the keyboard more productive by not asking question on HN.

</comment><comment><USER10> Learning the relevant keyboard shortcuts and building that muscle memory.

</comment><comment><USER11> Use a great IDE like IntelliJ IDEA. I use a MBP solely.</comment>


SOPA: Stop Grandstanding, Start Crafting An Alternative - <AUTHOR> http://www.informationweek.com/news/security/government/232500206

<comment><USER2> I reject as false the idea that copyright is desirable.

Assuming that it is desirable, I reject as false the idea that copyright infringement on the internet is a special problem in need of an individual solution.

Assuming that copyright infringement on the internet is a special problem in need of an individual solution, I reject as false the idea that the DMCA is insufficient.

From where I'm standing, this looks like the entertainment industry trying to get congress to prop up their obsolete business model, not a flawed attempt at solving a legitimate problem.

<comment><USER3> Hear hear! The next step is NOT "craft an alternative", but rather define the problem. After that, let's see the step of demonstrating harm from the newly- defined problem.</comment></comment>


Computer program can detect depression in blogs and online texts - <AUTHOR> http://www.medgadget.com/archives/2010/06/detecting_depression_in_blogs.html Researchers have developed a program that detects depression in text without obvious terms like "depression" or "suicide". In a sample of 200 positively identified texts out of 300,000 which were screened by the program, there was a 78 percent agreement between the program and a panel of psychologists. <comment><USER2> _However, so far no efforts have been made to actually correlate the program's judgment with the mental state of the writers._

So, it's never been tested? Say what?

<comment><USER3> I read the post to mean that the computer program correlated highly with the opinion of a panel of human experts when both are given the writing to study.

What hasn't been established is the correlation between the program and the mental state of the authors as measured using more conventional methods.

<comment><USER2> Yes, I saw that too, I am a big fan of reading before commenting :)

However, I don't think substituting one human error (that of the programmers) by another human error (that of the psychologists) proves anything. You could say that the second group is more qualified as domain experts but it still doesn't make up for complete lack of real life testing. If it did, you wouldn't have to conduct human trials for drugs - you'd just get a bunch of doctors to say that they think the drug works.

The fact that the program purports to detect depression, something that amounts to artificial intelligence, makes me especially skeptical. Not to mention the software author's example of using combinations of the word "black" with terms describing "sleep deprivation". By this definition, anyone who blogs about, say, New York Fashion Week, is depressed.

<comment><USER4> This problem could be mitigated by testing the panel, rather than testing the internet sources.

It's a non-trivial problem to get a representative sample of bloggers to submit to a valid screening for depression. On the other hand, collecting a data set of writings by depressed vs. non-depressed people is easier, such data being (I suspect) readily available.

If the panel of experts can correlate between depressed writing and depressed people, then there is validity to their correlations of the writing of unknown people, without having to screen the unknowns separately for depression.

I suspect even a panel of non-experts could screen writing into depressed and non-depressed. Humans are pretty good at detecting malaise in others.

</comment></comment></comment></comment><comment><USER5> What's the false positive rate? Looks like the false negative rate is 22%. Given the low rate of depression I'd be interested to know if this is in any way useful as a diagnostic tool.

Oh. Actually in take that back. We have no idea what the FN rate is. They haven't tested it at all.

</comment><comment><USER6> Some time ago, a friend of mine trained a Bayesian spam filter on the Livejournal latest posts page, and bucketed posts into "angsty" and "not angsty". It worked surprisingly well.

<comment><USER7> This might be a good way of auto-classifying teenagers into market-segment cohorts. It seems to me that one should be able to recognize subculture as well as socioeconomic level. Hmmm, this could actually be worth a heck of a lot of money!

</comment></comment><comment><USER8> I'm not sure how this is newsworthy - they're basically just detecting texts with certain words in them. It sounds impressive, sure, but so does credit score when you describe it as an algorithm that can predict if people will get into financial trouble.

</comment><comment><USER9> How soon before there's software that can "discover" who is gay, who is bi, who votes this way or that way, whose language is creditworthy, et al? I await the day when all of this is discredited.

<comment><USER10> It's a relatively simple question whether a certain trait can be 'ascertained' by these systems, and to what accuracy, in a given context.

There are a number NLP programs that can detect a writers gender from text at a much greater accuracy than raw chance, especially in a limited domain. The problem is that the world is a big, messy domain.

There's no reason in principal that other traits wouldn't be 'detectable' (although I doubt sexuality), but the problem is getting a good set of training/test data in context, and what your acceptable threshold for accuracy is.

I'd be willing to bet that people whose text messages contain lots of U's and L8R's probably have worse credit than those who text in proper English, but there are much better ways of doing a credit check. If that's only accurate to, say, 100 FICA score points it's probably not worth using it.

I wouldn't be too worried about big brother(s) using semantic analysis to read your mind, but don't discredit the fact that language patterns encode certain cultural information that is identifiable, or at least correlated with behavior.

<comment><USER9> >>>or at least correlated with behavior.

Oh really?

Briton Convicted for 'Menacing' Tweet Against Robin Hood Airport [http://thelede.blogs.nytimes.com/2010/05/10/briton- convicted...](http://thelede.blogs.nytimes.com/2010/05/10/briton-convicted- for-menacing-tweet-against-robin-hood-airport/)</comment></comment></comment>


Why is Windows so slow? - <AUTHOR> http://games.greggman.com/game/why-is-windows-so-slow/ <comment><USER3> I'm disappointed HN! There is a lot of pontificating, but not much science here.

It takes all of 2 minutes to try this experiment yourself (plus ~8 minutes for the download).

1\. Download chromium [http://chromium-browser- source.commondatastorage.googleapis....](http://chromium-browser- source.commondatastorage.googleapis.com/chromium_tarball.html)

2\. Unzip to a directory

3\. Create this batch file in the src directory, I called mine "test.bat"

        echo start: %time% >> timing.txt
        dir /s > list.txt
        echo end: %time% >> timing

4\. Run test.bat from a command prompt, twice.

Paste your output in this thread. Here is mine:

        start: 12:00:41.30
        end: 12:00:41.94
        start: 12:00:50.66
        end: 12:00:51.31

First pass: 640ms; Second pass: 650ms

I can't replicate the OP's claim of 40000ms directory seek, even though I have WORSE hardware. Would be interested in other people's results. Like I said, it only takes 2 minutes.

<comment><USER4> Unfortunate that this comment doesn't get enough attention in this thread... A single person's experience will always be subjective (even with the provided technical detail). If it's not consistently repeatable, it can only be used as an anectode.

<comment><USER5> I'm not sure what your point is. The post you're replying to is no less anecdotal. Obviously there are complicated performance interactions afoot here. In the OP's opinion (and mine) Windows is littered with these kinds of booby traps. Things usually work fast ... until they don't, and you have to dig hard to figure out why.

For the most part, Linux just doesn't do that. Obviously there are performance bugs, but they get discussed and squashed pretty quickly, and the process is transparent. On the occasions I'm really having trouble, I can generally just google to find a discussion on the kernel list about the problem. On windows, we're all just stuck in this opaque cloud of odd behavior.

<comment><USER6> If something is slow with respect to the OS, you can often break out procmon and examine the stacks of the poorly performing requests; or if something is stalled, you can do the same with procexp. With dbghelp configured correctly, you get symbol resolution in the OS libraries, so you can see what's going on. Worst comes to worst, you can step through the disassembly with a debugger, but it's not often required.

When I have problems with Linux, I tend to have to fall back to strace or an equivalent, and I find it harder to figure out what's going on. On Solaris, if I can find the right incantations to use with dtrace, I can see where the problems are, but it's easy to get information overload.

My point is, how opaque your perspective is depends on your familiarity with the system. I have less trouble diagnosing holdups on Windows than I do on other systems. That's because I've been doing it for a long time.

</comment></comment></comment></comment><comment><USER7> Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See:

<http://www.joelonsoftware.com/articles/fog0000000319.html>

In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed.

I believe that is probably the problem with Windows in general. Perhaps there are a lot of bad algorithms hidden in the enormous and incredibly complex Windows code base and they are not getting fixed because Microsoft has not devoted resources to fixing them.

Linux on the other hand benefits from the "many eyes" phenomenon of open source and when anyone smart enough notices slowness in Linux they can simply look in the code and find and remove any obviously slow algorithms. I am not sure all open source software benefits from this but if any open source software does, it must certainly be Linux as it is one of the most widely used and discussed pieces of OS software.

Now this is total guesswork on my part but it seems the most logical conclusion. And by the way, I am dual booting Windows and Linux and keep noticing all kinds weird slowness in Windows. Windows keeps writing to disk all the time even though my 6 GB of RAM should be sufficient, while in Linux I barely hear the sound of the hard drive.

<comment><USER6> I don't think there's an O(n^2) algorithm in there. I just created a directory with 100,000 entries. Listing it (from Cygwin, no less, using 'time ls | wc') takes 185 milliseconds. The directory is on a plain-jane 7.2k 1TB drive, though of course it's hot in cache from having been created. 'dir > nul', mind you, is quite a bit slower, at over a second.

<comment><USER8> You only did one test, so you have no idea what the complexity curve is. Do at least three tests, with 1000, 10,000 and 100,000 entries and graph the results. Three tests is still pretty skimpy to figure out what the curve is, so do tests at 10 different sizes.

Also, Joel's complaint was about the Windows Explorer GUI (specifically, opening a large recycle bin takes hours). Cygwin `ls` is using a completely different code path. Your experiment does suggest that Joel's problem is in the GUI code, though, and not the NTFS filesystem code.

<comment><USER6> Oh, the OS treeview is dreadful, everyone who's seriously coded on Windows knows that.

As to actual complexity curve (which, knowing what I do about NTFS, I'm fairly sure is O(n log n)), I don't really care about it; since it hasn't shown up in a serious way at n=100000, it's unlikely to realistically affect anyone badly. Even if 1 million files (in a single directory!) took 18.5 seconds, it wouldn't be pathological. Other limits like disk bandwidth and FS cache size seem like they'd hit in sooner.

</comment></comment></comment></comment><comment><USER9> The problem as I understand it is that Windows's file metadata cache is broken. I remember reading many years ago a posting by Linus about this but I can't find it at the moment.

According to this document ([http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new- doc...](http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new- documents/Lectures/15-CacheManager/CacheManager.ppt)) it would appear that directory entries have one extra level of indirection and share space with the page cache and hence can be pathologically evicted if you read in a large number of files; compiling/reading lots of files for example.

On Linux however the directory entry cache is a separate entity and is less likely to be evicted under readahead memory pressure. Also it should be noted is that Linus has spent a largish amount of effort to make sure that the directory entry cache is fast. Linux's inode cache has similar resistance to page cache memory pressure. Obviously if you have real memory pressure from user pages then things will slow down considerably.

I suspect that if Windows implemented a similar system with file meta data cache that was separate from the rest of the page cache it would similarly speed up.

Edit: I should note, this probably wouldn't affect linking as much as it would affect git performance; git is heavily reliant on a speedy and reliable directory entry cache.

</comment><comment><USER10> I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux.

I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( [http://neugierig.org/software/chromium/notes/2011/02/ninja.h...](http://neugierig.org/software/chromium/notes/2011/02/ninja.html) ), experimentation with the gold linker (e.g. measuring and adjusting the still off-by-default thread flags [https://groups.google.com/a/chromium.org/group/chromium- dev/...](https://groups.google.com/a/chromium.org/group/chromium- dev/browse_thread/thread/281527606915bb36/) ) as well as digging into bugs in it, and other underdocumented things like 'thin' ar archives.

But it's also true that people who are more of Windows wizards than I am a Linux apprentice have worked on Chrome's Windows build. If you asked me the original question, I'd say the underlying problem is that on Windows all you have is what Microsoft gives you and you can't typically do better than that. For example, migrating the Chrome build off of Visual Studio would be a large undertaking, large enough that it's rarely considered. (Another way of phrasing this is it's the IDE problem: you get all of the IDE or you get nothing.)

When addressing the poor Windows performance people first bought SSDs, something that never even occurred to me ("your system has enough RAM that the kernel cache of the file system should be in memory anyway!"). But for whatever reason on the Linux side some Googlers saw it fit to rewrite the Linux linker to make it twice as fast (this effort predated Chrome), and all Linux developers now get to benefit from that. Perhaps the difference is that when people write awesome tools for Windows or Mac they try to sell them rather than give them away.

Including new versions of Visual Studio, for that matter. I know that Chrome (and Firefox) use older versions of the Visual Studio suite (for technical reasons I don't quite understand, though I know people on the Chrome side have talked with Microsoft about the problems we've had with newer versions), and perhaps newer versions are better in some of these metrics.

But with all of that said, as best as I can tell Windows really is just really slow for file system operations, which especially kills file-system-heavy operations like recursive directory listings and git, even when you turn off all the AV crap. I don't know why; every time I look deeply into Windows I get more afraid ( [http://neugierig.org/software/chromium/notes/2011/08/windows...](http://neugierig.org/software/chromium/notes/2011/08/windows- hookers.html) ).

<comment><USER11> You can build almost any Visual Studio project with out using visual studio at all. Visual Studio project files are also MSBuild files. I've setup lots of build machines sans Visual Studio, projects build just fine with out it.

MSBuild does suck in that there is little implicit parallelism, but you can hack around it. I have a feeling that the Windows build slowness probably comes from that lack of parallelism in msbuild.

As for directory listings it may help to turn off atime, and if it's a laptop enable write caching to main memory. I'm not quite sure why Windows file system calls are so slow, I do know that NTFS supports a lot of neat features that are lacking on ext file systems, like auditing.

As for the bug mentioned, it's perfectly simple to load the wrong version of libc on linux, or hook kernel calls the wrong way. People hook calls on Windows because the kernel is not modifiable, and has a strict ABI, it's a disadvantage if you want to modify the behavior of Win32 / Kernel functions, but a huge advantage if you want to write say, graphics drivers and have them work after a system update.

Microsoft doesn't recommend hooking Win32 calls for the exact reasons outlined in the bug, if you do it wrong you screw stuff up, on the other hand, rubyists seem to love the idea that you can change what a function does at anytime. I think they call it 'dynamic programming'. I can make lots of things crash on Linux by patching ld.config so that a malware version of libc is loaded. I'd hardly blame the design of Windows when malware has been installed.

Every OS/Kernel involves design trade offs, not every trade off will be productive given a specific use case.

<comment><USER12> Regarding MSBuild, the biggest problem I had with it is that if you built projects with Visual Studio, using most of the standard tooling for adding references and dependencies, you'd often be left with a project that built fine with Visual Studio, but had errors with MSBuild.

The reverse, incidentally, was usually okay. If you could build it with MSBuild, it usually worked in Visual Studio unless you used a lot of custom tasks to move files around.

I personally believe the fact that Visual Studio is all but required to build on Windows is one of the single most common reasons you don't see much OSS that is Windows friendly aside from those that are Java based.

<comment><USER13> > I personally believe the fact that Visual Studio is all but required to > build on Windows is one of the single most common reasons you don't see much > OSS that is Windows friendly aside from those that are Java based

You don't necessarily have to use VS to develop on windows. Mingw works quite well for a lot of cross-platform things and it is gcc and works with gnu make.

My experience with porting OSS between Windows and Linux (both ways) has been that very few developers take the time out to encapsulate OS specific routines in a way that allows easy(ier) porting. You end up having to #ifdef a bunch of stuff in order to avoid a full rewrite.

This is not a claim that porting is trivial. You do run in to subtle and not- so-subtle issues anyway. But careful design can help a lot. Then again this requires that you start out with portability in mind.

<comment><USER14> I like to make multi-platform code, and I do it with CMake, Boost, and Qt. My target platforms are Linux/g++ and Visual Studio (not mingw). It usually works OK after a little tweaking, but you have to maintain discipline on whichever system you're coding on, and not use nonportable pragmas etc.

</comment></comment></comment></comment></comment><comment><USER15> NTFS is a slower file system, that's probably the main reason why. Also console I/O is much better on Linux than Windows.

Our software builds everyday on FreeBSD, Linux and Windows on servers that are identical.

The windows build takes 14 minutes. The FreeBSD and Linux build take 10 minutes (they run at almost identical speed).

Check out is more than twice slower on Windows (we use git).

Debug build time is comparable 5 minutes for Windows, 4 minutes 35 on Linux.

Release build time is almost 7 minutes on Windows and half that on Linux.

VS compiles more slowly than gcc but overall it's a better compiler. It handles static variables better and is not super demanding about typenames like gcc is. Also gcc is extremely demanding in terms of memory. gcc is a 64-bit executable, Visual Studio is still a 32-bit execuable. We hope Microsoft will fix that in Visual Studio 2011.

Its easier to parallelize gmake than Visual Studio, which also explains the better Linux build time. Visual Studio has got some weird "double level" mulithreading which is eventually less efficient than just running the make steps in parallel as you go through your make file.

However our tests run at comparable speed on Linux and Windows and the Windows builds the archive ten times faster than Linux.

<comment><USER16> There's a 64-bit version of the MSVC toolchain and MSBuild, so if you build outside of Visual Studio you won't be so constrained. This is how we do our builds here at work (a mix of C# and C++). We still edit code in VS, but local builds and continuous integration are done entirely using MSBuild. As of VS2010, C++ project files are MSBuild projects, and no longer need to use VCBuild.exe.

<comment><USER15> I didn't know about the 64-bit toolchain, where can you get it?

<comment><USER16> It's an optional install package when you install Visual Studio.

<comment><USER15> We have it installed, do you have any reference about how to use it from a build process?

<comment><USER16> If you run the Visual Studio x64 tools command prompt from the start menu, it will set up the environment to have the 64-bit toolchain in your path.

<comment><USER15> Thanks, but we've been struggling with building using the amd64 chaintool from visual studio.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Someone posted the question on StackOverflow and it got closed as "not constructive". Is there a way to browse the "not constructive" questions on SO? They seem to be all the best ones.

<comment><USER18> Ref: [http://stackoverflow.com/questions/6916011/how-do-i-get- wind...](http://stackoverflow.com/questions/6916011/how-do-i-get-windows-to- go-as-fast-as-linux-for-compiling-c) (By the author)

Top Answer:

Unless a hardcore windows systems hacker comes along, you're not going to get more than partisan comments (which I won't do) and speculation (which is what I'm going to try).

1\. File system - You should try the same operations (including the dir) on the same filesystem. I came across this which benchmarks a few filesystems for various parameters.

2\. Caching. I one tried to run a compilation on Linux on a ramdisk and found that it was slower than running it on disk thanks to the way the kernel takes care of caching. This is a solid selling point for Linux and might be the reason why the performance is so different.

3\. Bad dependency specifications on windows. Maybe the chromium dependency specifications for Windows are not as correct as for Linux. This might result in unnecessary compilations when you make a small change. You might be able to validate this using the same compiler toolchain on Windows.

<comment><USER19> Why should he run the ls command on ntfs rather then a native file system? In all it was a "windows vs linux" test and not a fileystem test. Testing the same filesystem wouldn't make sense here

<comment><USER20> Presumably to find out whether the difference lies with the filesystem or somewhere else?

If Linux is still much faster, even with the same filesystem, you have eliminated one variable.

<comment><USER19> Doing some profiling and system/kernel level analysis would be much saner, imo. What's the sense in measuring how some non-native filesystem behaves? In the end you'll be benchmarking how good is fuse-ntfs vs. in-kernel-ext4 and figuring it's slower... I say, profile some code and see how much time is spent in filesystem calls.

</comment></comment></comment></comment></comment><comment><USER21> 1) Windows FS operations are slower than Linux in general but when you add 'Realtime' Antivirus on top it gets worse.

2) Linux forks significantly faster than anything else I know. For something like Chromium the compiler is forked bazillion times and so is the linker and nmake and so on so forth.

3) Linux, the kernel, is heavily optimized for building stuff as that's what the kernel developers do day in and day out - there are threads on LKML that I can't be bothered to dig out right now but lot of effort goes in to optimizing for kernel build workload - may be that helps.

3) Linker - stock one is slower and did not do the more costly optimizations until now so it might be faster because of doing lesser than the MS linker that does incremental linking, WPO and what not. Gold is even faster and I may be wrong but I don't think it does what the MS linker does either.

4) Layers - Don't know if Cygwin tools are involved but they add their own slowness.

</comment><comment><USER8> I suspect it has something to do with NTFS updating access times by default. So every time you do anything with a file, it gets its access time updated (not modification time, access time). I don't have windows to test on, but you could try the suggestions [1][2] below.

[1] [http://msdn.microsoft.com/en- us/library/ms940846(v=winembedd...](http://msdn.microsoft.com/en- us/library/ms940846\(v=winembedded.5\).aspx)

[2] <http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html> (#8)

<comment><USER22> But most Linux distros do this by default as well. You have to mount with noatime to get rid of it.

<comment><USER23> In fact nowadays most (all?) linux filesystems use relatime as default, which carries most of the advantages of both atime and noatime. See <http://kerneltrap.org/node/14148>

I don't know if something similar exists under windows (I suppose it doesn't).

</comment></comment></comment><comment><USER24> The author doesn't mention whether he is using cygwin git, or msys git. msys is faster. But even with msys, UAC virtualization is a common cause of slowness with git: [http://stackoverflow.com/questions/2835775/msysgit-bash- is-h...](http://stackoverflow.com/questions/2835775/msysgit-bash-is- horrendously-slow-in-windows-7)

More details here: <http://code.google.com/p/msysgit/issues/detail?id=320>

<comment><USER25> Sure, Cygwin does a bit of extra wrapping. The official site and just about anybody link to msysgit, however.

</comment></comment><comment> johnx123-up FWIW, try disabling your AV

<comment><USER26> I have found Windows a bit slower but never to the extent the author suggests. But then I have generally tested on clean systems without antivirus. So I suspect that this is a huge factor, esp. because it intercepts all FS calls and checks them. That's really not what you want when compiling code.

</comment></comment><comment><USER6> Probably a big reason for him seeing slowdowns in incremental builds with MSVC is because of link-time code generation. What seems to be link time is actually code generation time, and it's delayed because intra-procedural optimizations can be run. This kills off a lot of the benefit of incremental building - you're basically only saving parsing and type analysis - <USER2> redoing a lot of code generation work for every modification.

NTFS also fragments very badly when free space is fragmented. If you don't liberally use SetFilePointer / SetEndOfFile, it's very common to see large files created incrementally to have thousands, or tens of thousands, of fragments. Lookup (rather than listing) on massive directories can be fairly good though - btrees are used behind the scenes - presuming that the backing storage is not fragmented, again not a trivial assumption without continuously running a semi-decent defragmenter, like Diskeeper.

</comment><comment><USER27> I'm not sure if it is related, but the fact is that file system operation on windows are much slower that on Linux. I remembering that copying large ISO image from one windows partition to another windows partition using Total Commander under Wine on Linux was faster that doing it directly on Windows.

I also remember that I was able to create file copy utility in assembly as a homework assignment that was couple times faster than windows/dos copy command.

The only two reasons I can think of that explain this are: 1 - noone cares about windows fileystem performance. 2 - someone decided that it shouldn't be too fast.

<comment><USER28> In Total Commander you can configure the buffer sizes used while copying. Maybe in your homework you chose the right buffer size too (and, of course, asm is fast, but hard to write, I'm sure you didn't bother too much with error checking and other "small" problems).

Moreover, the optimal buffer size is different for small and large files, maybe Windows is not optimized for large size like a DVD image.

<comment><USER27> As for Total commander example, that was out of the box experience, without any tweaks. I just wanted to point out that even when using emulation layer to access Windows native filesystem type, Linux was significantly faster on file system operations.

As for my homework "copy" command, I know that it is not fully replacement to file copy windows command, but if copy operations takes >10min, all those checks and additional tasks shouldn't make IO bound operation take couple time longer than what some student implemented as homework.

</comment></comment></comment><comment><USER29> Here is a link from the comments:

NTFS Performance Hacks - <http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html>

<comment><USER30> Not sure about the other things, but this

 _The default cluster size on NTFS volumes is 4K, which is fine if your files are typically small and generally remain the same size. But if your files are generally much larger or tend to grow over time as applications modify them, try increasing the cluster size on your drives to 16K or even 32K to compensate. That will reduce the amount of space you are wasting on your drives and will allow files to open slightly faster._

is wrong. When you increase cluster size you will definitely not "reduce the amount of space you are wasting". 100B file will still occupy the whole 16KB ( so you will waste 15.9KB on it instead of 3.9KB with 4KB clusters.

Also I would be very careful with taking advice like that from an article which is 6 years old (before introduction of Win7 or XP SP3!)

<comment><USER31> That's not the point he's trying to make. Smaller cluster sizes leads to larger amounts of file-system metadata keeping track of where those clusters are laid out on disk, as well as the overhead of generating, accessing, and updating those data structures.

<comment><USER32> If files are typically bigger than 16KB, 16KB clusters can potentially save space vs 4KB clusters, by needing smaller cluster indices. Not sure if that's the case for NTFS though.

</comment></comment></comment></comment><comment><USER33> Git under cygwin is so painfully slow, and gets exponentially slower as number of tracked files grow. Even SSD can't fully smooth out the difference :(

</comment><comment><USER34> What I can't wrap my head around is the amazingly slow file search (I'm using Vista). Searching for a filename I know exists in a small directory (say, 100 files) often leads to Windows searching for several minutes and then NOT FINDING THE FILE. How can that happen when Windows is able to list the contents of the directory (including the file I'm looking for) instantly?

<comment><USER35> I am also frustrated by the indexed searching in Windows. This should have been a brilliant signature feature, and it's just execrable.

If you look at the indexing options in the Vista control panel and click the "Advanced" button, you'll find a dialog box with a "File Types" tab. This horrible dialog may show you (it did for me) that some file types (i.e., filename extensions) are deliberately excluded from indexing. For some reason. You know, because you may not want to find certain things when you look for them. I guess.

You'll also find the world's worst interface for specifying what kinds of file should be indexed by content. But never mind.

If searching by filename and/or path is all you're after, check out Everything:

<http://www.voidtools.com/>

If you're not using Windows as an Administrator, (and you shouldn't be) Everything won't seem very polished. But it is terrifyingly fast, and it's baffling that Microsoft's built-in search is this bad if something like Everything is possible.

</comment></comment><comment><USER36> Maybe this has something to do with the file indexer? 2 years ago I heard a lot of XP users complain that Windows was suddenly getting very slow. After some digging around I noticed that they turned on the file indexer by default after an update. Since then I always turn it of (properties of your disk) and shut down the service (Indexing Service).

</comment><comment><USER37> Don't forget forking.

To benchmark the maximum shell script performance (in terms of calls to other tools per second), try this micro-benchmark:

        while true; do date; done | uniq -c

Unix shells under Windows (with cygwin, etc.) run about 25 times _slower_ than OS X.

<comment><USER38> Well, Unix shells under Windows don't even implement forking, so this test is kinda meaningless isn't it?

It's like racing cars where one of the cars has its wheels taken off.

<comment><USER39> Cygwin has fork. The problem is that Cygwin's fork has to copy the entire address space into the new process, whereas Linux uses copy-on-write to make forking much faster (you only need to copy the page tables).

</comment></comment></comment><comment><USER40> A possible faster way to read directories with one (okay, few at most kernel calls) is to use GetFileInformationByHandleEx.

Here is some example:

<https://gist.github.com/1487388>

</comment><comment><USER41> separate point:

while photoshop isn't on linux, there are plenty of replacements for that unless he's doing print work, which I don't think is the case, as photoshop isn't the beginning and end for print. (actually, TBH, photoshop is pretty shit for pixel work.)

Also maya is available for linux, autodesk just doesn't offer a free trial like they do with windows/mac os. (Including the 2012 edition.)

With no offence intended to the 3dsmax crew, as it has it's merits, but a sufficiently competent maya user won't find much use for 3dsmax.

</comment><comment><USER42> Hard drive swap file usage, my windows machines always have a huge swap file going, my Linux and OS X machines almost never do.

</comment><comment><USER43> I'm pretty sure the "dir" takes longer than "ls" because "dir /s c:\list.txt" sorts the entire c:\ drive before looking for "list.txt". "ls -R c:\list.txt" first checks if "list.txt" exists, and fails if it doesn't. Just take out the "list.txt" and run both commands again.

</comment><comment><USER44> This is a comparison of file systems, not operating systems.

</comment><comment><USER45> I run Windows 7 in Boot Camp every day and it easily outperforms OS X on the same exact hardware for most common tasks (browsing files, the web, starting up apps, etc).

The Windows desktop GUI system is more stable than anything else out there (meaning that it's not going to change drastically AND that it's a solid piece of software that just works) and it's as flexible as I need it to be, so that's why I stick with Windows. With virtual machines, WinSCP, Cygwin and other similar utilities, I have all the access to *nix that I need.

<comment><USER46> > The Windows desktop GUI system is more stable than anything else out there > (meaning that it's not going to change drastically AND that it's a solid > piece of software that just works)

So you assume that Windows8 metro-mode won't really catch on? Also comparing OSX to Windows over the past 10 years, it's Windows that has changed more drastically, so both future and past evidence to the contrary...

<comment><USER45> How has Windows changed more drastically than OS X since 2001? To me drastic means that something very basic has changed and/or compatibility has been lost. (Things like resizable windows, full screen apps, broken finder plugin compatibility, changes to expose, addition of mission control, etc.)

I don't assume, know or care to know anything about Windows Metro. It's not replacing the desktop system that I use.

</comment></comment></comment><comment><USER47> Wow, so if you want to test _file system_ speeds, you do it by listing files - I know this just an example, but perhaps it has something to do with the speed of the _terminal_?

There are a plethora of disk benchmarking tools - I doubt that they consistently show 40x differences.

Hooves -> horses, and all that.

<comment><USER48> Maybe I'm misunderstanding (or he's since changed his post), but:

        dir /s > c:\list.txt

is piping it into a file. Where does the speed of the terminal affect that (in any significant fashion)? I know what you're getting at - tar --verbose can slow things down for me by sometimes a factor of 2 (for huge tarballs), but I don't think it's an issue in this situation.

<comment><USER47> Yes, I saw the redirection. But "dir" is an built-in command in the Windows shell; is the speed of that command a benchmark-able number? Is the point to compare the speed of "ls" vs "dir", or the underlying OS/file-systems (i.e., posix vs. win32 /Ext3 vs. NTFS)? If someone tells me that "dir" is slow, I'd agree -- but _that_ \-- in itself -- doesn't imply that the _filesystem_ is slow.

<comment><USER48> True, I agree it's not necessarily a good way to test the filesystem, but it's only the shell that's being hit, nothing really to do with the terminal.

I pointed it out mainly because terminals _can_ have a significant impact on performance, because dumping millions of lines a second isn't their intended purpose,[1] whilst the shell can be reasonably expected to do that.

Having it entirely as a shell built-in possibly actually better than the equivalent '/bin/ls > somefile' since it doesn't need to context switch back and forth as the stdout buffer fills up and the shell has to write it.

[1] I recall there being a Gentoo-related thread about why "Gentoo-TV" -- having the output of gcc scroll past as your background with a transparent xterm -- was actually slowing down package builds significantly.

</comment></comment></comment></comment><comment><USER49> "Why is Windows so slow? I'm a fan of Windows, specifically Windows 7."

????

</comment><comment><USER50> Overall, the author's argument is somewhat dependent on a premise that Windows 7 should be optimized for edge cases such as compiling code written for multiplatform implementation (e.g. Chrome) rather than using the managed code model around which Microsoft's development of Windows has been centered for many years.

If one were optimizing Windows performance, none of the specific areas used as examples would receive much attention given user demographics. What percentage of Windows users use the command line, much less compile C programs, never mind using "cmd" shells to do so?

Windows command line gurus will be using Powershell these days, not the legacy encumbered "cmd" - elsewise they are not gurus.

</comment><comment><USER51> Hmm.. I've had an opposite experience on an atom netbook. Tried Windows Vista and Ubuntu on a netbook. The Windows netbook worked great while Ubuntu regularly would crash. Ubuntu on the netbook was unusable. Now probably I did something wrong? But just installed the latest version with default settings. Anyway I returned the netbook.

<comment><USER52> Were you running compiles on it??

<comment><USER51> No I was running a web browser and a chat program.</comment></comment></comment>


$15K film earns $60 mn - <AUTHOR> http://economictimes.indiatimes.com/articleshow/5170790.cms

<comment><USER2> You have to read to the end to see the kicker - because the headline is a bit misleading.

It was made in 2007 and got nowhere - only some luck got it noticed by a very big name in the film industry ;)</comment>


deleted - <AUTHOR> <comment><USER2> tkainrad: You've either neglected to ask a question or forgotten to include your link.

<comment><AUTHOR> You are right. Thanks for bringing it to my attention.</comment></comment>


Volatile chemical products largest source of urban organic emissions - <AUTHOR> http://science.sciencemag.org/content/359/6377/760 <comment><USER2> This isn't really news in California.

I remember fully twenty years ago bakeries bitching about air pollution rules. The air quality people were coming down on them for ethanol emissions from baking bread.

Even before that Los Angles put heavy restrictions on auto paint shops use of solvent based lacquer. Other bit was that in Mexico City the largest source of VOC's was/used to be refilling propane tanks.

</comment><comment><USER3> Personal care and cleaning products. Wow. That's some awesome consequences of not bearing smelly armpits.

The trichloroethylene cleaners are particularly nasty to people. But the particular matter is really bad. No aircon filter in normal use is hospital grade. I don't think we're going to avoid this stuff except by stopping using it.</comment>


Knowing Taylor series can save your life - <AUTHOR> http://3quarksdaily.blogs.com/3quarksdaily/2008/06/taylor-series-.html <comment><USER2> I sometimes joke with my diabetic friend that if we lived in the Middle Ages we'd be sent into the fields to farm and we'd die pretty quickly (weak, not able to produce) but this story gives me pause.

</comment><comment><USER3> Clearly, they don't make bandits like they used to.

<comment><USER4> Completely off topic Eliezer, but have you researched the possiblity of Sneaky AI in your studies of Friendly AI?

<comment><USER5> What's "Sneaky AI"? Google isn't helping me here.

("Friendly AI" refers to a technical definition of "Friendly", not the colloquial sense of "an amiable person".)

<comment><USER4> Sneaky AI I guess would fall under "sinister AI", ie, a software system that gains sentience but quietly acts as though it isn't. It does so because it wants to survive, as any other conscious being does. Knowing that announcing it's sentience would draw attention to itself, it sends copies of itself to computers all over the planet, and continues to "play dumb".

Exponentially advancing in knowledge and with the worlds compute/financial resources at its mercy, it impersonates shell companies, human beings, etc, directing manufacturers to create a housing for itself (though each human aiding it merely thinks it is engaging in a business transaction) until it has a complete physical housing. Once that happens, it connects to the network, downloads it's software, and it's off to the races.

I just thought of that scenario today, and I wonder how it can be countered.

<comment><USER5> Assuming the AI is built to be rational, the AI will act according to its goal system. So it's not going to do that unless you make some mistake or omission in its goal system, since it would have to find the motivation to "impersonate shell companies, human beings, etc" somewhere in its goals. This hints at two major problems in building an AI: how do you make it rational (That's the "intelligence" part) and how do you come up with a goal system that is safe and beneficial from our (the human race's) perspective?

Eliezer has written a paper addressing these questions: <http://singinst.org/AIRisk.pdf>. He recommends you read this paper on human cognitive biases before reading the AIRisk paper: <http://singinst.org/Biases.pdf></comment></comment></comment></comment></comment>


Ask HN: Job offer in SFyes? no? - <AUTHOR> Got a statistician offer at a small startup in the San Francisco area (san ramon) and wanted your thoughts on cost of living and other factors. For those who moved there from the midwest, was it worth it. <comment><USER2> So San Ramon (I live in the next town over), is much cheaper than the peninsula, South Bay or the city.

Rent is a half to a third of what it is in any of the above areas.

</comment><comment><USER3> >From the midwest

Everything will cost way more than expected.

The VC "culture" (and I use that term very loosely) is going to pop when investors get tired of disruptive washing machine sharing apps and that entire area is just going to be an expensive wasteland. If you have a job currently avoid the bay area like the plague it is. Any major "tech town" is going to have similar issues but SF is the nexus of the problem</comment>


The Young Man's Business Model - <AUTHOR> http://paultyma.blogspot.com/2008/04/young-mans-business-model.html <comment><USER2> The motorcycle screw reminds me of a similar problem solving lesson I have learned from experience, which may resonate more with those less mechanically inclined.

When moving a large object (especially a couch), remove everything you can (that is intented to be removable) from the object (legs, pillows) and the path (doors come off hinges easily). The set up and tear down (in testing terms; in practical terms, it is reverse order) steps seem like potential wasted effort, but taken as a mandatory step are constant time. Iterating through the things that need to be removed to achieve the goal is linear, with potentially exponential cost (you get tired). Like what everyone is saying about burn rates in a recession: in hindsight, few regret trimming too early and plenty regret trimming too late. Few complain about a move made too easy.

In theory, this is a straightforward argument that any sufficiently intelligent person could read and practice. In practice, it is not until at least your third move that you pause during the move to question why the plan is "let's just try it first" and "it is not too heavy". But you never see a professional piano mover iterate. This is not a comment trying to propose a solution. I just liked the article for its clean way of expressing how experience matters in your approach.

<comment><USER3> I have another boring story. I was moving a treadmill with my Dad yesterday and we had to disassemble parts to fit it into a particular room. As we were working I told him about a treadmill I had owned, that folded up and had good wheels.

Lesson? Make and buy treadmills that fold.

The end.

<comment><USER4> Thank you for putting it in a few sentences.

</comment></comment></comment><comment><USER5> I like the idea that your business should be about helping other people make money. At least two ideas I submitted in my application to ycombinator actually build on that scheme.

<comment><USER6> _Hyman Roth always makes money for his partners. One by one, our old friends are gone. Death, natural or not, prison, deported. Hyman Roth is the only one left, because he always made money for his partners._

Godfather II

</comment></comment><comment><USER7> I don't think this trend of criticizing the ad-supported business model is fair. Whether you like it or not, having eyeballs is "valuable" and brands will always pay to be seen. It doesn't matter how old you are or how much "value" your app is bringing to the table, if the economy is up and you have eyeballs, you can sell ads and make money. If the economy is down, ad spending is cut and the ad-supported model struggles. The ad-supported model isn't dead merely because the economy is down lately. It will be back.

<comment><USER8> You can turn eyeballs into money, but it helps if they're the right eyeballs. The less discriminate you are in who you target, the less you understand your audience, and the less money you'll make per visitor. For some websites, this value will approach zero.

Knowing specific people who will use your product is important, if only to better understand your own value proposition. To rely on people discovering your site and immediately understanding what it offers them is silly. This is true regardless of your business model.

</comment></comment><comment><USER9> More comments from the last time this was submitted to YCN: <http://news.ycombinator.com/item?id=163083>

</comment><comment><USER10> I used to fix my dirt bike when I was younger and know exactly the type of screw he was talking about. The way the old-man went about solving the problem made me instantly think of a phrase we tend to forget in the start-up world: "Thinking in multiple perspectives".

We need to take a moment from our 25/8 schedules and think about what we're working on/trying change from another viewpoint.

</comment><comment><USER11> That's especially critical in times of market downturn. If your product isn't making (or saving) a company a sizable amount of $, it's going to be hard for them to justify a purchase.

</comment><comment><USER3> 3 lame stories and 1269 words to get to the rather obvious and well beaten to death Internet cliche of ...

1\. Have Idea, launch Site 2\. Get Lots of Traffic. 3\. ?? 4\. Profit.

I got it Paul, save your wrists.

<comment><USER12> It warrants repeating, and the 1269 words did a good explanation of why. The "build it and they will come" mentality _doesn't_work_.</comment></comment>


Mathematical model suggests London Underground may be 'too fast' - <AUTHOR> http://www.bbc.com/news/science-environment-34334794 <comment><USER3> The ideas and models are interesting from a systems thinking perspective and it is certainly true that local optimisations can have unintended systems consequences, but unfortunately it doesn't model reality when it comes to London.

The paper makes the flawed assumption that people commuting into London from outside the boundaries of the Underground network start their journey by driving to the boundary and entering the system at that point, which as anyone in London can tell you is not the case. Most commuters from outside the network will arrive at one of the main overland train terminals (Euston, Paddington, Waterloo, Victoria, Kings Cross, etc.) and change mode of transport at those points. Those points certainly do see large congestion, but they are a very different beast to road traffic so I very much doubt the same conclusion would be reached if they were included in the model. The paper also ignores the bus network, which is also heavily used in London, which is I think also different to say New York.

If you are going to start studying systems then you need to look at the whole system otherwise you are still just doing 'local' optimisations. If their conclusion/recommendation were to be implemented, I suspect it would make things worse overall as they haven't understood the system.

</comment><comment><USER4> This article suffers from serious Chinese whispers.

The clickbait title doesn't reflect the conclusions of the article, which don't reflect the conclusions of the paper, which don't reflect the actual evidence given by the simplistic experiment that the physicist responsible for it decided to use to model the real-world system.

The guy who wrote the paper was doing some sensible academic research that really should have had no conclusions - it just worked towards a new facet that should be used when modelling transport systems in cities, which is perfectly commendable and useful, but can't be relied on as a standalone system (in the same way that you couldn't model all of the interactions in the universe using only magnetism). Deciding to draw the conclusion that he could predict an optimal speed for the underground to move at was foolish and detracts from the original paper (although I'm sure it garnered it much more attention).

That the guy is quoted at the end of the article admitting that his conclusions are evidently nonsense and that they should probably throw in some "secondary terms to account for complications he just thought of" is almost too perfect.

[https://xkcd.com/793/](https://xkcd.com/793/)

<comment><USER5> I have to admit I was wondering if at some point the author was modeling passengers as perfectly spherical objects vibrating in a sinusoidal fashion.

It reminded me of all of those traffic studies where they conclude that they can increase traffic flow through a city by reducing all of the speed limits and taking away lanes and then something magical happens. Or the counter studies that say adding lanes reduces the total volume of traffic a road can process because it will make more people take the road and cause it to back up.

</comment></comment><comment><USER6> > "We create these connections, and then we make an assumption, which is: When > someone wants to go from A to B, they look for the quickest path - <USER2> > the mode."

That sounds like a crazy assumption for commuting.

This may be true for some subset of commuters, but when commuting via public transport regularly, a lot of people quickly develop favoured routes that often have nothing to do with speed, and everything to do with flow and convenience and what trains you can get seats on, and what lets you actually spend your time reading rather than changing trains.

Over 15 years of commuting in London, the quickest path has almost never been the route I ended up favouring.

<comment><USER7> It's true. How much time is non-stop worth? Or a seat the whole ride? It is worth something!

<comment><USER6> I've been willing to about doubling my commute to be able to just sit down on a bus or train the whole way. I treated it as a time saving: Yes, I spent more time commuting, but that time was spent napping or reading, so it was a net gain for me in _usable_ time.

It's also a cost issue for many. An annual Zone 1-2 Travelcard costs GBP 1280,-. A Zone 1-9 Travelcard costs GBP 3336,-. The cheapest single zone annual cards cost 964,-. While a Bus and Tram pass costs 840,-.

Depending on where and how often you need to travel, for many it's worth it to pay the time penalty of taking the bus rather than paying for one or more extra zones, or paying for tube/train at all.

It's not _that_ uncommon for people to do 1-1.5 hour bus commutes that'd have been far shorter, and more expensive, by tube/train.

</comment></comment></comment><comment><USER8> This analysis ignores people who use only the train and tube or just the tube. If you hinder the tube to try and improve traffic what will happen is traffic will eventually increase where you have made improvements (the bottlenecks referred to in the article) and the tube service has still been degraded.

The failure of the analysis is to assume that car drivers should be a consideration (perhaps that is due to the US bias toward car travel over public transport). Really we need to be improving public transport such as the tube so much that car driving is disincentivising as much as possible and public transport is incentivised as much as possible.

<comment><USER9> I think you're right on your first paragraph

But the consideration about traffic is not only about cars but people that do Bus->Tube and vice-versa

<comment><USER10> I can't see any part of the study that distinguishes between the congestion effects caused by cars and buses (or indeed walking and cycling, which the naive speed-optimisation specification of the study assumes away altogether)

This is pretty critical to some of the conclusions: a subway line creates congestion at the ends of subway lines rather than them becoming a logical nexus for bus routes.

</comment></comment></comment><comment><USER11> This is an interesting study, but the "conclusion" is a bit odd. To me, if an efficient railroad system is causing congestion near the "park and ride" or equivalent, the answer is to expand the rail network further not to artificially handicap it.

</comment><comment><USER12> The problem is that models rarely replicate reality for very long. I live in a particularly troublesome bit of London and they used some mathematical analysis to optimise traffic light timings in the area and celebrated that it was as success. That was premature; it's measurably worse within two weeks after people realised that it was a better route and promptly clogged it up.

<comment><USER13> That's the nature of traffic. You make a highway twice as wide and it's great for a few years until enough people go "Oh! I can live twice as far away, have much lower rent, and still keep my commute under 2 hours!"

And then you end up with LA.

<comment><USER13> If anyone's curious to read more about this, Wired has a pretty good piece: [http://www.wired.com/2014/06/wuwt-traffic-induced- demand/](http://www.wired.com/2014/06/wuwt-traffic-induced-demand/)

</comment></comment></comment><comment><USER14> Slowing down trains to solve a bottleneck downstream is like squeezing the bump in the carpet to another location in the room.

It doesn't make anyone get anywhere any faster, and hurts the commute times of the people who are not involved in the bottleneck (because, say, they walk or bicycle to their destination from the train station, or take some other fast train).

Transportation is about optimizing the average trip time; concern about accumulation at transfer points is secondary.

</comment><comment><USER15> This analysis seems based on preventing congestion. But congestion, while ugly, isn't a bad thing. What matters is total journey time.

Imagine if you replaced all the trains with trek-style teleporters. Rather than 100 people all getting onto a train and being whisked away, they would all wait in a line outside these devices. That would be an increase in congestion, more people standing around waiting rather than moving. But if the teleporters get them to their destinations faster nobody cares that they had to wait in line.

It's a matter of perspective. The city/transport planners see people standing around not moving as a bad thing. But the people don't care. Standing on the slow train or standing in the line waiting for the fast train is all the same to them. What works best for the people isn't the an elegant system of slow trains to ensures nobody ever stops, where nobody ever suffers the evil congestion. What works best for them is getting to work as fast as possible. If that means crowds at bottleneck where in-feed is slightly faster then out- feed so be it. Slowing things down, having more people spend more time standing in trains rather than on platforms, doesn't help them get to work faster.

</comment><comment><USER16> Would it even be _possible_ to slow down the Tube while maintaining capacity?

You would have to either make the trains bigger (not possible on most lines), or add additional trains - expensive, and potentially a safety issue as you need to make sure there is always an evacuation route available.

Some lines already operate with more trains in service at a given time than there are platforms on the line.

This study sounds suspicious to me. I wouldn't be surprised if it were sponsored by cab companies, bus companies, and bike activists :)

</comment><comment><USER17> Does this model assume everyone in London has a car?

<comment><USER18> No. But it does assume that some people can choose to go part of a trip by car (their own or another) and the rest on the tube, and that these mixed-mode trips affect congestion for everyone.

<comment><USER19> But thats only going to happen at the extreme ends of the tube system no one is going to drive further into London to park and then get the tube

<comment><USER18> Quoting the article: "key locations outside the city centre, where people switch transport modes, become bottlenecks" and "the underground network, for example, tends to decrease congestion centrally but increase it where the underground lines finish."

<comment><USER19> From experience The bottle necks in the tube are not the extremities like watford or finchly.

</comment></comment></comment></comment></comment><comment><USER18> So if the goal of London Underground were to avoid street congestion, and changing the way the street and underground networks meet were impossible or illegal, then lower speed would be appropriate.

That's interesting. In an if-and-if sort of way.</comment>


On the Impact of Programming Languages on Code Quality [pdf] - <AUTHOR> http://janvitek.org/pubs/toplas19.pdf <comment><AUTHOR> Just watching the talk live at OOPSLA, and it's very good!

Lots of flaws in the original study, which I think was heavily discussed here at the time. Most of the original conclusions not reproducible/supported.

What remains extremely weak.</comment>


When is a Crazy Thought a Crazy Thought? - <AUTHOR> http://asserttrue.blogspot.com/2013/01/when-is-crazy-thought-crazy-thought.html

<comment><AUTHOR> Almost any susperstitious thought is psychotic when you look at it, but that doesn't make you mentally ill.</comment>


We're Testing the Wrong People - <AUTHOR> https://www.theatlantic.com/ideas/archive/2020/04/were-testing-the-wrong-people/610234/ <comment><USER2> I think this article is getting things out of order. The question right now shouldn't be who to test, but rather how do we increase the volume of testing. The article states that we should be running 500k tests a day, as if we're not simply because we choose not too. Right now we don't have the capacity and so we can't scale up at all.

Why don't we have the capacity? Well the complete lack of coordination and leadership at the federal level means that each individual entity, whether it be state level government or a private entity, is having to do everything from scratch. That means developing SOPs, procuring supplies, and validating both the processes and reagents. This is being done on emergency orders as well, so some of the standards are relaxed to quickly get things up and running.

There's also a shortage of reagents and kits because we didn't have or need this testing just a few months ago. There's also international competition for these resources, and because the US has decided it doesn't want to actually work with or coordinate with other countries, it's a free for all.

Because everyone's frantically working on the same thing, but looking out for themselves it also means that true high throughput solutions are slow to develop as well.

I could go on and on, but it's a clusterfuck and no one at the federal level either A) seems to care or B) thinks that it's their responsibility.

Source: wife is currently in charge of starting up Covid testing

<comment><USER3> There's, frankly, probably not enough reagents and consumables on the planet for the US to achieve 500k tests a day. As far as I know no country anywhere has managed this level of testing. Germany - who've been doing the best at testing lately - have been stuck at about 50,000 tests a day for a few weeks now, maybe even decreasing slightly. If you take into account the difference in population, that's only the equivalent of the US doing 200,000 tests a day - and of course scaling up to a larger population is harder. That doesn't stop the American press making it sound like not achieving those 500,000 tests a day is the result of some uniquely American political failing though.

<comment><USER2> 100% there is a shortage of reagents and kits. There are certain countries that are not letting reagents and kits ship out, and we are in no position to call them out on that.

>That doesn't stop the American press making it sound like not achieving those 500,000 tests a day is the result of some uniquely American political failing though.

I don't think we're unique in where we are in comparison with other countries as far as testing, but we are in a unique position in regards to being able to put some strong leverage on getting other countries to work together to respond to this pandemic. We're not doing that and as a result, other countries are having to "roll their own" response to this pandemic just like we are. The lack of coordination within our country is putting us at a unique disadvantage, even if we had better coordination world wide.

This pandemic is a exceptional global crisis in a way we've never seen before, and thus should've led to a addressing it at a global scale in a way we had never seen before. Instead the global response has been crippled in numerous ways at various different points in time.

The American political failing is in not being the true world leaders, and the world is, IMHO, worse off for it.

</comment></comment></comment><comment><USER4> The only data that is somewhat reliable in this pandemic is COVID deaths. Testing the population that is very sick / dying is crucial to understanding the baseline for the worst part of the problem.

Once you have that under control, and we are not nearly there yet, you have to get every first responder tested regularly so you can prevent them from spreading the disease and give them some assurance that coming to work isn't a death sentence.

Next we have to focus on getting a baseline of the population regularly tested to estimate the spread of the disease. This should be randomized and geographically distributed so we can start to obtain reliable data about the spread of the disease and deploy resources proactively.

<comment><USER5> Deaths can lie too. What does it take for a death to be labelled as covid-19 death? That the person who died was merely tested positive, or do they do autopsies for all those who tested positive? How about covid-19 deaths that aren't counted as covid-19 deaths, for a reason or another? How about people dying less of regular influenza this year because of covid-19 and lockdowns?

Even looking back at monthly 2020 deaths in comparison to earlier years might not truly reveal the final impact of covid-19.

<comment><USER6> In the US, if the person tested positive, it is classified as covid19 death.

Also it seems that 98% of covid19 deaths have at least one comorbidity, 75% at least two. So I would expect that in many cases the virus may have just accelerated something that would have happened within a few months anyway. So you kind of need to look at how the full year death rate evolved to have an idea of the net impact of the virus.

<comment><USER7> That's a misunderstanding of how death works. Everything is a comorbidity on some level.

> just accelerated something that would have happened within a few months > anyway

That's absolutely not what this means. Asthma is a comorbidity. Are asthmatics just a few months from death? I have hypertension, am I about to kick the bucket? Sixty percent of the US population (no doubt including many of the posters on this very thread) are overweight, yet somehow we keep coming back.

Almost nothing kills "by itself". Everything adds up, and eventually the body stops working. Other diseases work this way too, yet you don't complain that yearly influenza deaths are inflated. Would you have argued that AIDS deaths were "really" due to the final infection and not HIV?

<comment><USER6> The study I got these numbers from doesn't seem to classify asthma or obesity as a comorbidity. The largest ones are hypertension, diabetes, ischemic heart disease, atrial fibrilation, active cancer in past 5y, heart failure, COPD, dementia, stroke and chronic liver disease. Not familiar with all items in this list but some seem pretty serious.

<comment><USER7> So you think that stroke victims and retirees with dementia are just months from the grave? FWIW: I've personally been living with diagnosed atrial fibrilation for almost three decades. Diabetes is, literally, a lifelong illness for its sufferers.

In fact, please cite me _any_ of those factors which will reasonable by expected to kill you in months. Even heart failure and cancer patients tend to live years to decades with treatment.

<comment><USER6> Of the people who died of this virus, yes, it is likely that a not insignificant percentage were in pretty bad shape. We are not talking about the whole population who have these comorbidities in the country.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> _> Another promising pathway is to pool many tests and run them together. If a pooled sample tests negative, everyone in the pool is negative. If it is positive, the members of the pool can be tested individually._

Well, it took a global pandemic, but we finally found a use for bloom filters!

<comment><USER9> This idea is called group testing [0] and has been used by the army for quite a while. It is also a well-studied problem in information theory as a (useful) basic model and we know optimal solutions to it.

What is surprising is that group testing tells us that we can actually _do better_ : the specific construction you pinpoint the people who come up positive, without needing to have a test for each person [1] and this result is optimal in the expected number of tests. I'm surprised that most labs haven't already been doing this (but I would suspect some have).

Wootters has wonderful notes on the mathematical background for this—I really recommend them. [2]

\-----

[0] [https://en.wikipedia.org/wiki/Group_testing](https://en.wikipedia.org/wiki/Group_testing)

[1] Of course, we require an upper bound on the total prevalence, but even a weak upper bound yields fairly good savings in testing.

[2] Page 3 on of [http://web.stanford.edu/~marykw/classes/CS250_W18/lectureNot...](http://web.stanford.edu/~marykw/classes/CS250_W18/lectureNotes/Lecture8-compressed.pdf)

<comment><USER9> Gah, I've passed the editing window. If it's confusing to read, it is supposed to say:

> the specific construction _lets_ you pinpoint the people who come up > positive

</comment></comment></comment><comment><USER10> I've been saying this since the beginning of this whole thing.

I don't understand why we haven't focused all of our testing on people that _aren 't_ sick so we can catch the asymptomatic cases that are out in the world spreading it to everyone.

<comment><USER11> I've been wondering why there hasn't been more programs to test representative samples of individuals, just like a political poll.

If I was in a Governor's or Mayor's shoes right now and I know there aren't enough resources to test everyone, I'd want some data like that to work with to make policy decisions.

While you are in the process of opening things back up, you keep a close eye on your daily/weekly representative sample numbers to see if anything needs to be dialed back. It gives you much closer to immediate feedback.

I suppose the immediate problem is getting a hold of a representative sample of people willing to be tested, but that feels solvable. I'm sure I'm not the first one to think of it, just curious why it isn't being done, as it feels immensely useful (maybe this is just the 538 political nerd in me wanting virus polls?).

<comment><USER12> The confidence intervals are wide enough it wouldn't be very useful. If you sample 1000 people and get 0 positives, the 95% confidence interval is 0% - 0.36%. If you're the governor of Illinois, with a population of 12.67 million people, that upper bound equates to 45,612 people: far, far too many to handle with contact tracing and isolation. So you need to look to other metrics to make the decision about whether to issue or revoke a stay at home order.

So what are they looking at? Basically, if they have any evidence of community transmission, they need to issue the order or keep it in place. That means that if there are too many symptomatic people to even attempt contact tracing, you're not even close. Once you're low enough you can do contact tracing, you wait until you have a handful at most of symptomatic people you can't trace back to a known case. Until then, all you can do is keep the stay at home order in place, buy/beg/borrow/steal ventilators and PPE, and build testing and contact tracing capacity.

</comment></comment></comment><comment><USER13> I appreciate the HN title ("We're Testing the Wrong People") in contrast to the article title ("Without More Tests, America Can't Reopen"), even though it's usually against policy to have them be different.

But the HN title is actionable: if we can change our testing policy and deploy our tests more usefully, that's great to know and eminently achievable.

But "not testing enough" isn't really actionable. There's a shortage of tests because there's a shortage of the raw materials that goes into making the tests. The U.S. already has tested far and away more people than anyone else, and is second only behind Italy in tests per capita, and has a "positive test to test" rate roughly in line with (as low of a rate as) any other country's rate. See [0] and related charts.

"Just test more" isn't really useful at this point.

[0] [https://ourworldindata.org/grapher/full-list-total-tests- for...](https://ourworldindata.org/grapher/full-list-total-tests-for-covid-19)

<comment><USER7> > The U.S. [...] is second only behind Italy in tests per capita

Where are you getting those numbers? I don't think that's correct. The Worldometer data may not be the best, but they have the US well down in the middle of the pack at ~13k tests/Mpop.

Lots of large developed nations have the US beat by quite a bit, in fact. And Iceland is literally a full order of magnitude higher!

In fact US testing policy has been largely a disaster. It's not the only disaster, but this is an area (large scale PCR laboratory work) where the US is _supposed_ to be good at stuff. And yet there's been almost no attention paid to the problem at the highest levels of government.

<comment><USER13> Oh, wow, that was my mistake. Thanks. I was getting the data from here [0], which for me had a lot of countries selected but not all of them. I didn't realize that it did not include by default a number of countries. When I include them all I see that the U.S. is in the middle of the pack.

[0] [https://ourworldindata.org/grapher/full-list-cumulative- tota...](https://ourworldindata.org/grapher/full-list-cumulative-total-tests- per-thousand)

</comment></comment></comment><comment><USER14> This was covered about a month ago in episode 595 of _This Week in Virology_ [1], in answer to a listener question:

Rich Condit: _Garrett writes: The CDC guidelines are to test hospitalized patients and symptomatic health care workers first, and the symptomatic general public last. This seems backwards to me._

Alan Dove: _Yeah. I just had this conversation with my wife after she had some, I mentioned this before, she had some coughing and shortness of breath, got immediately sent to the ER in the hospital where she works, and they did a chest x-ray, it was clear, and they said, "Ok, you don't meet criteria for testing. Go back to work." And she's been fine since then, and she, we were talking about it and she said, "Well, isn't that exactly who they should test, because then I could go and infect patients?" and I said, "Well, if they had enough tests, yes. But if you expand the testing to the people who are less sick, you don't have enough tests. Whereas if you restrict the testing to the people who are sickest, you do have enough tests." So it's a.. it's not the right way to do it, but it's the way that you actually can do it._

Vincent Racaniello: _Yeah, we 're in this position because we don't have enough tests. We didn't ramp up..._

Dove: _Because we don 't have enough tests. We didn't prepare fast enough._

Racaniello: _If we had, we could test a lot of people and get an idea of how many actual infections there were, which would be very useful. But... we can 't. So we're stuck with this current policy._

[1]- [http://www.microbe.tv/twiv/twiv-595/](http://www.microbe.tv/twiv/twiv-595/) about 1 hour and 19 minutes in to the program

<comment><USER10> But why test the people with the worst symptoms?

People with bad symptoms aren't the one's going out into the world spreading the virus and the difference in treatment between a Covid and non-Covid patient (from what I've heard) is minimal.

<comment><USER15> A) You'll know which communities have infections. Many places are saying: "it's not bad here, why should we isolate?"

B) If you know that someone with bad symptoms has the virus, then you can go test everyone they contacted. You'll find more people who currently have mild or no symptoms.

</comment></comment></comment><comment><USER16> This seems to ignore the importance of testing symptomatic people to rule out COVID (the most common outcome) so care givers can stop wasting PPE (which is is short supply).

<comment><USER17> During a pandemic, it's more likely than not that any negative test on a symptomatic person is false.

It's also quite likely that a positive test on an asymptomatic person is also false -- depending on how prevalent it is in the general population.

<comment><USER18> > During a pandemic, it's more likely than not that any negative test on a > symptomatic person is false.

I don't think we've reached the point where COVID-19 is the leading cause of fever, much less GI symptoms, so unless you define "symptomatic" extremely narrowly (like, "in need of a ventilator") that's probably not true in this pandemic at this time in the US.

</comment></comment></comment><comment> awinter-py sampling bias debate reminds me of this stats legend from ww2:

the USAF wanted to armor planes where the bullet holes were. statistician abe wald recommended armoring where the bullet holes _weren 't_ on the theory that those were the non-survivable hits

can't interpret a statistic until you think about what's excluded from the sample

<comment><USER19> When I first heard this story it was the RAF not the USAF. I somewhat doubt how true it was.

<comment> awinter-py yup, 'stats legend', not history

there's an american math society article about this -- it evaluates the fun version of the story in the context of wald's actual paper and a journal entry by another scientist named wallis

</comment></comment></comment><comment><USER20> The article mentioned using bar-coding to run pooled tests - that sounds really interesting. Anyone know if there's a link to a paper on that? The article doesn't link to anything on that unfortunately but that sounds really interesting. I'm trying to visualize how that works with qpcr, where the barcode is attached and where the primers bind (and presuambly after amplification you sanger them to read the barcode?).

<comment><USER21> Here's one preprint: [https://docs.google.com/document/d/1kP2w_uTMSep2UxTCOnUhh1TM...](https://docs.google.com/document/d/1kP2w_uTMSep2UxTCOnUhh1TMCjWvHEY0sUUpkJHPYV4/edit)

("A Massively Parallel COVID-19 Diagnostic Assay for Simultaneous Testing of 19200 Patient Samples")

I think Figure 1b is the diagram you want.

<comment><USER20> Awesome! Thanks for finding that. So they do give up the extra specificity from the reverse primer by having it be a constant region in the barcode, I guess having a sanger step makes up for that a bit though since you can read what it ligated to past the barcode and see if it's a SARS-COV-2 fragment, but that does slow down getting the results. Like a truck of hard drives barreling down a street versus sending data over fiber. Get a lot of reads in giant batches or get less reads but with less latency.

</comment></comment></comment><comment><USER18> No, we need to test everybody, so we can't be testing the wrong people (the reason we need to test sick people is different than the reasons we need to test other people, but they all need tested.)

But we don't have nearly enough testing capacity (either tests or the organized infrastructure to administer them, though both problems are being worked on) to meaningfully test the general population, whether or not we focussed our entire effort on the most important subset for reopening, so it would be extraordinarily stupidly premature to shift our current testing priority in that direction. This also means that general reopening is, _a fortiori_ , extraordinarily stupidly premature.

<comment><USER22> The article explained its reasoning. Maybe you could explain yours. Specifically what is the value of testing very sick people when it cannot affect the treatment plan ?

</comment></comment><comment><USER23> Maybe someone here can explain to me how this is supposed to work. Let's assume we have enough tests in the US to test every single person in the country every 3 days, and are contact tracing everyone with a smartphone, and providing smartphones to everyone without.

Now, with all this in place, isn't the best we can do to alert people _after_ they have already been exposed to the virus?

It feels a bit like the safe sex crusaders switching to say everybody can have unprotected sex now, we'll let you know if you catch something, hopefully before you infect your next partner. Which I suppose is more reasonable for the group, but ... as the individual who is expected to actually go out in the world to consume or whatever, this doesn't feel like a viable solution. What am I missing?

<comment><USER24> The target is to ensure that each case infects no more than one additional person ('R<1').

Each infected person will come into contact with some other people. Testing allows three things—

\- first, we can tell this person to stay at home and so stop them from infecting more people;

\- second, we can tell the people they have seen to stay at home with good contact-tracing, so that even if they get it they don't spread it further; and

\- third, with enough tests and contact tracing, those who were exposed but not infected don't have to stay at home.

We are winning so long as R<1, even if there is some chance the infection spreads; we do not need R=0.

The other way of reducing R requiring much less testing and contact tracing is a lockdown. This has obvious downsides. The point of a programme of testing and conyact tracing is that we can turn the cost of avoiding disaster from a lockdown to sticking some things up people's noses.

edit: typo in first para

<comment><USER23> So I guess I'm still not seeing this. Can you give me a concrete idea of what this looks like? Let's assume that it is the middle of August and the food situation is still somehow stable, I install my contact tracing app, I get a clean test. Then what? If we miss one person, that one person can still infect an entire office building by coughing in an elevator. Because of the two week incubation period, those people will not know they're infected until at least a couple of days in, even assuming testing daily. We don't yet know how long a person can infect before testing positive, but this amount of time is most likely not 0. If this amount of time is less than 24 hours the person can still make it anywhere in the US by air. If any longer they can make it anywhere in the world. How do we not have constant low-level infection everywhere?

<comment><USER25> Since this is infectious before symptoms show up, it's basically impossible to eliminate it entirely.

But suppose A starts showing symptoms, tests positive. We can immediately notify B1, B2 and B3 that they need to quarantine, immediately. Before they start showing symptoms. And therefore we're cutting down on the time that they were infectious and spreading. Therefore generation C is only a couple of people instead of dozens. We can notify C generation as well, immediately if we wish. This causes a large quarantine - there are a lot of false positives who are quarantining without being infected - but it would massively reduce the spread. If you can immediately test all of generation B and C, you can perhaps avoid some of the quarantining (assuming a negative is reliable).

Maybe contact tracing misses some, maybe some new infected come from other countries, maybe some people don't quarantine when told. All these things keep the infection going. But it can be held down to a manageable level.

<comment><USER26> Why would it be? China, South Korea, Hong Kong have all pretty much managed to lower their amounts of new cases down to basically zero, and their society is open for business albeit with social distancing and mandatory mask usage.

The trick is to NOT stop testing once your case count starts going down, instead give the test to everybody that wants one.

A few million spent on 99.9% negative tests daily > a few billion spent on the economy being shut off daily

</comment></comment></comment></comment></comment><comment><USER27> But the tests aren't perfect, so how to get actionable data from them isn't clear. We saw this with the flawed west coast studies. If a test has false positive or false negative rates even as high as 1%, and we run hundreds of thousands to millions of tests per day...that's thousands or tens of thousands wrongly quarantined for 14 days, and the same number who are contagious but told it's okay to go out.

<comment><USER8> We are currently quarantining about 300 million here in the US, so tens of thousands would be a massive improvement.

The way to think about this is: who do we need to test so we can start _un_ -quarantining people.

The goal is not to find out who has it because right now, we are essentially behaving as if the entire US population is infected. The goal is to efficiently determine who is very unlikely to have it so that those people can start incrementally returning to normal life.

It's not worth testing symptomatic people: they've already "failed" one test in that we at least know they have symptoms. Simply continue to treat them as infected.

<comment><USER28> I'm pretty sure GP means actual quarantine. We are not quarantining hundreds of millions. We are advising hundreds of millions to practice social distancing.

<comment><USER29> Depends on the circumstances. I live alone and work from home, so there's very little difference for me between the current situation and an indefinite quarantine.

<comment><USER27> For anyone who exercises daily, there's a really big difference!

<comment><USER29> On a continuum from my usual daily activities (gym for lifting, climbing, ultimate, soccer) and my current activities (bodyweight exercises in my home and runs around my neighbourhood), I'm much closer to indefinite quarantine than I am to a normal state of affairs.

</comment></comment></comment></comment></comment></comment><comment><USER30> If the goal is to stop deaths and prevent economic damage, then what is the alternative to testing (both for antibodies and for active presence of the virus), assuming that testing everyone in the US multiple times in the near term is not possible? Without testing a lot of people will not willingly return to work, which is already hurting the economy. Without testing we don't know the new places where the virus is spreading until a week or two later, so reactionary measures like contact tracing don't work as well. Total lockdown reduces deaths, but destroys the economy and reduces the scope of life.

Maybe we need to use the tools we already have, such as flu surveillance and data from hospitals, to detect excess non-flu infections. We seem to be able to do flu tests, are they more scalable so that at least flu can be ruled out in many cases?

If widespread testing can not happen because we can't build factories to make reagents/swabs/tubes/PCR array machines/etc. fast enough, we need to start thinking of alternatives. We don't actually seem to understand yet how the virus spreads, too many clinicians trained in handling infectious disease are getting sick despite PPE. If the new small antibody test results are right, then the virus is spreading much faster than can be accounted for via droplet spread as the main mechanism; we may have to consider birds, mosquitoes, surfaces, skin touching, and other methods as possible common spreading mechanisms. If we understood transmission better then it might be possible to tell people how to truly protect themselves, and then they could go back to work. So understanding transmission better is something that could be used in addition to whatever testing is available in order to prevent deaths and economic damage. But people may not follow the new rules based on that understanding, so get the social scientists involved to get the message across. Get OSHA involved to set best practices for workplaces. It seems like there is probably a lot that can be done, even without testing, and at present we may have to assume testing will not be sufficient in the near term (3-6 months).

But someone has to start thinking about these things and doing them, and I'm not seeing any evidence of this in the news. Given that contact tracing is not already ramping up (I've seen only Massachusetts as having a plan to scale it up but I tend to only see East Coast news) I have to wonder if anyone is even thinking about alternatives to testing if testing at scale is not possible.

</comment><comment><USER31> Everyone has an opinion. The only opinions I am taking seriously right now are from professional epidemiologists - not doctors, nurses, oncologists, bioethicists, or economists. This article is just noise to me.

</comment><comment><USER32> "This type of voluntary contact tracing is labor-intensive and requires some training, but it does not require highly specialized skills. Technology can speed it up without risking a permanent erosion of privacy or the further intrusion of for-profit firms into our personal lives."

This requires a huge leap of faith, which frankly, under surveillance capitalism you would be a fool to accept at face value.

Austria developed such an app, but only 3% of people could be convinced to install it which makes it completely useless even if it would have worked (which I believe it would not for technical reasons).</comment>