polyfractal

Fair warning, my hardware skills are shoddy at best, but I may be able to help with the Rust side :)

TIL :)

I cringed when I saw this at the top of HN because I knew the shame that is my soldering skill would be seen by a few hundred people :)

The specs say it has 0.9 mA light sleep, and a 10 uA deep sleep. Assuming the specs are correct (I haven't test it yet... not sure anyone else has either) you could definitely run it off a battery if you aren't waking it up too often.

The real problem with the RTL8710 (and ESP8266, and any other chip that uses WiFi) is that WiFi is very energy intensive. It takes a lot of juice to blast out a 2.4Ghz signal.

I don't know what the numbers are for the RTL8710, but the ESP8266 uses 50-170mA when receiving/transmitting data, which will drain a battery very quickly. (Source: http://bbs.espressif.com/viewtopic.php?t=133)

But it only took an afternoon to bolt Rust into the C build because Rust's FFI story is really nice (imo). So I get the best of both worlds: existing C HAL and SDK with the pleasantness and safety of Rust.*

* With the assumption/hope that the HAL isn't buggy, since Rust will rely on that to not explode :)

I'm not even a power emacs user or something (IntelliJ is my preferred IDE). YMMV of course, but I find the hotkeys super useful.

Speaking of... I need to finish that up soon before winter season starts in earnest!

A major pain point of dew-heaters is if they are too strong, they induce "tube currents". E.g. the heat from the dew-heater causes the air around the heater to start convecting, which causes ripples in the final image. It's not really visible as ripples, but a general blurring of the image. It's essentially recreating astronomical seeing conditions inside the telescope itself, which is obviously not ideal :)

I think some fancier setups will be "active" and regulate themselves based on ambient temperature, but it's a lot more common for people to over-build their heaters and then use a dimmer switch. So you make your dew-heater for the worst winter night you expect, then dim it down for the rest of the year manually.

Image stacking can reduce noise afterwards, but there's no substitute for collecting more photons to increase the signal in an image... and the only way to do that is to try and clean up the noise floor (via cooling, better sensors, etc) :)

1) If your setup is sophisticated enough that fan vibration may cause an issue, you're likely already using a german-equatorial mount and some kind of guiding correction (secondary guide scope, or off-axis guider). These adjust the scope's positioning in real-time to keep on-target. So that removes any large-scale deviation that may be caused.

2a) Small-scale deviation is generally not a problem, since most setups are likely to be limited by the resolution of your entire optical train. For example, my 800mm newtonian combined with a CCD with 7.2mm pixels means I have a resolution of ~2.01 arc-seconds. Assuming perfect guiding, my scope can tolerate any vibration as long as my target stays within ~2 arc-seconds. *

2b) In reality, most locations are limited by seeing conditions (e.g. how turbulent the air is), which averages 1-3 arc-seconds in non-mountain regions. Also the calibration of your mount (periodic errors, guiding errors, etc) are almost certainly a greater concern than the vibration added from the peltier.

That's from an amateur's perspective. Obviously high-end setups will start to worry about things like the fan's vibration, but for someone with a backyard setup (doubly so for someone using a consumer DSLR instead of dedicated CCD), there are bigger causes of inaccuracy :)

* This is a bit of a simplification, since things get a bit more complicated due to FWHM, wavelength, etc.

My QHY8 (a dedicated astro CCD) for example has a poor/old design, where the CCD compartment is not air-tight. This allows humid air to get inside, which can then fog up the optical glass due to the peltier cooling the sensor down.

The fix is a small ring that screws into the port, and raises the temperature just enough to combat dew. You could also wrap a dew heater strap around the part of the optical train at that point for a similar effect.

Dew (and frost) are the astrophotographer's great, persistent enemy and not just on the CCD. You'll also have dew problems on the telescope itself. For example, my newtonian sometimes has dew problems on the secondary mirror, occasionally on the main mirror, and always on my guide scope.

Most people just create some DIY dew heater straps with nichrome wire... it's super simple and effective.

Also, 1000 of those jobs are presumably lost because the new workers are willing to work at a lower rate. That leads to two situations:

- The product/service they are creating will be cheaper (e.g. cheaper commodities out of China, cheaper fruit harvesting by migrant workers, etc). The average person spends less of their paycheck on these purchases, which means they obtain more value for less money. Or purchase more things using the same amount of money as before.

- The owner of the business pockets more profit by employing cheaper labor but keeping prices the same. This segues into the idea of "trickle down" or "supply side" economy, where the owner employs more people, expands business, invests more capital etc because they are now spending less on salaries. Not saying I agree with this analysis, but it's at least one viewpoint :)

Eh, this argument gets trotted out a lot, but it isn't exactly clear-cut. The economy isn't a zero-sum game.

Sure, illegal immigrants do show up and undercut some jobs. Some percentage of people will find themselves working at a lower wage, or lose their job and need to find a new one.

But plenty of other people will find their business increased, higher wages, more profit, etc. All these immigrants require services and commodities too, and have to buy them from somewhere. They need to buy groceries, get hair-cuts, purchase mattresses, buy cars. Illegal or not, they contribute to the economy too.

Planet Money did a good piece on the cuban migrations to Miami in the 80's. It was the perfect microcosm to study the phenomenon: many immigrants, contained geographical region, etc.

http://www.npr.org/2015/10/01/444912593/when-cuban-migrants-...

Money quote at the top of the episode:

    SMITH: So 80,000 refugees came to Miami, and there was no effect on the economy?

    CARD: You couldn't detect any strong evidence of an effect one way or the other.

    SMITH: No effect, not on wages, not on unemployment rates. Card says this is 
    because there is not a fixed number of jobs in an economy. When a bunch of new 
    people come, yes, they get jobs. But they also start buying stuff, getting haircuts, 
    going to the grocery store, which means you need more barbers and more grocers. That 
    creates more jobs.

It's really just a "top ten list according to my arbitrary thoughts", which is fine. But it's not really a useful comparison at all.

Of course, that's a totally unfair comparison: CMS has had a decade of bug squashing...I'm sure it had equally scary bugs when it was new. But that's the point. Don't use new, shiny GC's because they are still squishing bugs :)

(Sorry, preaching to the choir, I just get frustrated by everyone claiming G1 will solve all their problems without investigating potential downsides)

That's a pretty scary bug. Who knows how stuff like that will trash your data if you aren't properly checksumming everything.

CMS and other GCs have the advantage of years of bug-squashing and tuning. G1 is exciting, but I wouldn't personally use it on anything important for quite some time.

But if your index is larger than available memory (very common), the OS will naturally start paging the segments on/off disk as required.

That's the root of the "give no more than 50% of your memory to ES" advice, since the other 50% is needed by the OS FS cache for Lucene segments

Source: I'm an Elasticsearch dev :)

The bulk API mainly helps by amortizing various overheads across many documents at once. There isn't anything "special" about the bulk indexing...it doesn't side-step the normal indexing pathway to directly dump the data directly onto disk, for example.

What happens is that the bulk request arrives at a node (which we'll call the coordinating node now, since it is coordinating this request). The coordinator will then create "mini-bulk" requests which are fired off to individual nodes who need to perform the actual indexing operations. If your bulk touches five different shards around the cluster, the coordinating node will construct five mini-bulks.

Bulk requests have an (annoying) newline-delimited format. This allows the coordinator to extract until the first newline, parse the JSON and identify the action (index, delete, update) and destination (index/type/id). Since the actual document is irrelevant to the coordinator, it can slice the buffer until the next newline straight into the "mini-bulk" for the destination node. This allows the coordinator to avoid parsing the document's JSON, which could be quite large (think 15mb PDFs, or docs with 5k fields).

Once the coordinator is done assembling the mini-bulks, it sends them to the various nodes around the cluster and waits for responses to come back. Finally, the coordinator merges the responses and sends a response to the client.

So a bulk reduces overhead by amortizing the two network hops (one to coordinator, one to node) over thousands of documents. There are also side benefits like allowing concurrent bulks to share translog fsyncs, giving lucene larger indexing buffers to work with (helps create larger segments for less churn), less context switching, etc.

Generally, smaller documents gain more benefit from bulk, since more of the time is dominated by overhead. Super large documents, or documents with very complex analysis chains are less likely to see a huge improvement, since the latency there is dominated by IO or CPU. But you'll still see an improvement due to fsyncs, context switching, giving lucene batches, etc.

Hope that helps! Lemme know if you have questions :)

A quick search turned up this protocol, labeled 2006: http://sydney.edu.au/medicine/pharmacology/CRGweb/internal/l...

I don't know when it was first used, it's one of those protocols that every lab has sitting in an ancient three-ring binder. The procedure is essentially the same everywhere, with minor variations depending on the tissue you're working with, the stains, etc:

1. Knock the animal out somehow (usually isoflurane or similar)

2. Perfuse with Phosphate-buffered saline (PBS) followed by 2-5% Paraformaldehyde (PFA). You can also use glutaraldehyde, which is better for EM, while PFA is usually better for histochemistry

3. Rinse in PBS for a while

4. Drop the brains into sucrose solutions, let them sit there until they sink. Usually labs will have a few sucrose baths they like to use (e.g. start in 10%, then switch to 30%). Sucrose is the cryoprotectant here

5. Dunk in liquid nitrogen, coat with OCT, mount on cryostat and start sectioning

6. Go about your business staining, etc

The only novel thing here, really, is that they perfused the cryoprotectant instead of just letting the brains sit in it for a few days. Letting a rabbit brain soak up sucrose likely takes longer than a mouse, so perfusing would definitely speed up that step.

But it's a rather moot point, since fixed brains can chill in refrigerated PBS for a month or two. There's no rush once it's fixed ... that's the point of fixing. I'm with the other folks, this was really just a grab at some money imo. And fancy headlines. There is nothing interesting here.

Credentials: worked in neuroscience wet-lab for 5 years.

- genome (set of dna material in a cell)

- exome (set of exonic dna material)

- transcriptome (set of all messenger RNA)

- proteome (set of proteins in a cell)

- interactome (set of all interactions in a cell -- protein, small molecular, etc)

- metabolome (set of all small molecular compounds / interactions in a sample)

- connectome (set of all connections in the brain -- e.g. a wiring diagram)

etc etc

I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent.

Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick).

But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)

Or you could just implement the linux syscalls directly in the kernel, but that seems a bit self-defeating if you want to explore new ideas.

Edit: There is also http://www.alexeyshmalko.com/2015/bkernel-a-rust-operating-s...

Phil has stated his series is basically for fun and learning. I imagine Steve's and Eric's are similar. You don't necessarily want to "combine effort" with someone when you are exploring ideas on your own.

The main change recently has been an update to the ACC/AHA LDL guidelines about LDL targets. Previously, there were hard targets that the doctor was trying to reach, in particular the 70mg/dl target was considered "optimal" and doctors strived to get their patients down to that.

In reality, it's become clear that there is no clinical evidence that an LDL that low is required. Certainly decreasing it from a high level (150+) has been shown to be a good idea (in most cases...it's complicated). But once you've decreased a patients LDL to a lower level, the clinical benefit of hitting 70 is nebulous.

So the new recommendations have dropped many of the hard targets, and recommend a more case-by-case evaluation. E.g. if your patient has a high LDL and you put them on a statin, they start exercising, eating better, and levels come down to 80mg/dl ... well, that's probably fine. They are in good shape, monitor and back off the statins.

A major reason for the change is because you'd see people on statins and other cholesterol meds for years. These drugs are very safe and low side-effect, and when combined with hard targets, doctors just "leave" patients on statins forever. But despite being safe, you shouldn't be on a chronic medication and there are other risks. So the new guidelines are trying to encourage doctors to use statins more sparingly.

Some more reading on the new guidelines:

- http://emorymedicinemagazine.emory.edu/issues/2014/spring/fe... - http://www.medscape.com/viewarticle/814152

Basically, the risk of confounding your results with smoking-related mortality is a bigger problem than biasing your population with fewer people who consume addictive substances.

Source: I'm an ex-molecular biologist, my significant other is a PA.

But, the KV store + unikernel is mostly for fun, so may not be the most practical of real-world ideas anyway :)

Edit:

> Well I was not talking about iterating through a list, but rather maintaining arbitrary indexes to a mutable list. Eg, a Sprite which contains a index to a Texture array. In that scenario it's just as easy to miscalculate and crash your program via a bounds-checking error as it is to crash by nil-deref.

The solution here is to just use a reference instead of an arbitrary index. If you hand out references you can lean on the compiler to enforce memory safety -- the compiler won't let you access data that is no longer alive, won't let you accidentally share across thread boundaries if you don't explicitly want that, etc. And if that was a shared mutable list, it's doubly important to let the compiler help you reason about it, since shared, mutable state is the main source of data races.

This is one of those cases where leveraging the compiler allows you to write better, safer code.