andreer

There is a forum dedicated to devices like this at https://forum.ei2030.org/ - also a zulip chat linked there which is more active.

Reminds me of the recent Lisperati1000: https://www.hackster.io/news/the-lisperati1000-is-a-cyberdec...

I think these personal terminals are really cool, and might foster some interesting innovation in the near future.

There's much in this thread about the helmet absorbing the energy of the impact, but that's far from the whole benefit of wearing one.

The helmet, by conforming to the shape of your head, distributes the energy from the point of impact to a much larger area. So instead of having your head cracked open at the point it hits the tarmac, or pierced by a pointy rock, the force will be evenly distributed across your head.

The helmet also has a low-friction shell that will slide across a surface, which helps avoid head rotation, snapping your neck or getting whiplash, and will protect you from cuts and abrasions.

I've been saved by my helmet many times.

Just an FYI to your last paragraph: The core indexing/ranking/storage components of Vespa are C++, and run in a separate process (no jni).

In my own attempt to compare the two, I found the memory consumption of Vespa was easier to predict and understand (there are formulas for it in the documentation).

Here’s a sensor that’s already used by the local police to monitor the breathing of those locked up over night - to be able to respond asap if someone stops breathing after excessive drinking or drugs. Seems benevolent to me. https://www.xethru.com/x4m200-respiration-sensor.html

I find this to be an interesting question. Given a modern, high-performance compiling lisp implementation on a modern CPU, say SBCL on x86_64.

What modification or addition to the CPU (or wider computer architecture) would be most effective in making typical lisp programs run faster?

Technological innovation can also arise as a consequence of the minimum wage being high. By increasing the cost of human labor, automation becomes relatively cheaper / more cost effective.

Here in Norway this has led to the near complete elimination of classes of jobs. As a very visible example, we have no toll booth operators or garage attendants, these have been universally replaced by automatic license plate recognition.

Thankfully we have a (relatively) good social safety net to take care of those who lose their jobs to such things.

Are these in unicode already, or are they really Apple specific?

It could be a replacement for the 'E', but the APIs are different enough that there's no drop-in replacement for the 'L' and 'K' and creating or making those compatible would be a significant effort. Would be great if someone did though :-)

In our tests, vespamalloc has simply been faster. I don't know how in-depth the analysis has been as to why, but obviously vespamalloc is written and tuned for Vespa so that is a likely factor.

The reason is simply, for performance. To avoid having to go to the kernel every time we need to allocate memory for a query, and avoid having to clear memory on free/reuse. It is made for Vespa, but also used for other programs.

Similar in purpose to Google's TCMalloc: http://goog-perftools.sourceforge.net/doc/tcmalloc.html

It's based on "VErtical Search PlAtform". A bit of a contrived acronym perhaps ... it's been known as Vespa internally in Oath/Yahoo for a long time.

That would be Apache Pig, a scripting language for Hadoop. Some scripts are included to feed data to and query Vespa from Hadoop.

https://github.com/vespa-engine/vespa/tree/master/vespa-hado...

Solving all of these in 5 hours is truly awe inspiring. It would probably take me months, if not years :-)

Skip to Chapter XIV, if you must.

"Of all men they alone are at leisure who take time for philosophy, they alone really live; for they are not content to be good guardians of their own lifetime only".

The whole town is actually considered for a place on the UNESCO world heritage list: http://whc.unesco.org/en/tentativelists/5472/

It certainly has an interesting history, having started as a company town, important war history (sabotage of production of materials for the production of nuclear weapons), and certainly interesting geography.

Very neat. I'm ordering a print of my home town. Then we can add pins to show where our house, where grandparents live, etc. I'm sure the kids will enjoy it.

I'll miss this feature, but I realize that for the "average user" which only uses ctrl-x/c/v it is probably a good thing.

Personally, I've long been planning to switch back to a tiling wm anyway.

Bar graph of current data: http://www.pvv.ntnu.no/~andreer/salary_bar_graph.png

My son (nearly three), usually around 6am. If I don't bounce out of need the instant he opens our bedroom door, he'll wake the baby and her mother, and both will be grumpy for the rest of the day! I love it because then we get to build something with Lego's for an hour before we have to get ready for kindergarten.

Well, in a way. Yahoo products with Summly integration are in the app store right now.

An excellent writeup on different techniques to do this: http://www.keithschwarz.com/darts-dice-coins/

n here is the number of different elements you can choose from. If there was a third alternative, you'd have to add another if statement.

Both my kids have slept outside, also in temperatures down to -10C. I don't know whether they slept better, but they certainly slept for longer - giving me more time to get other things done. I suspect thats probably the real reason for it!

I'm all for this, but I'm a bit miffed about the terminology: autonomous/robot/self-driving cars. "Autopilot" is shorter, simpler and well-established - and IMHO more accurate, as long asa human driver ready to take over at any time is still required.

I think the issue is with discrete (line-at-a-time) vs. smooth (pixel-at-a-time) scrolling. Two-finger scrolling typically sends the latter type of event, which is not yet widely supported in Windows and Linux software (although I have it working on my thinkpad X121e with the latest gtk3).