skysight-inc/HackerNews huggingface dataset:
The designer gave a lot of thought to the problems with current touchscreen UI in cars, and kudos to him for doing so.

However, it's not the solution yet, in my opinion.

First, all the methods of interaction are invisible. There are no cues to tell the user what two fingers vs. four fingers will do, or what the difference is between a close-fingered gesture and a wide gesture. At best, you'd have to standardize the meanings across all cars (something that rarely happens in autos, even today there's no standard for where the wiper controls go, for instance), and even then, people would have to memorize those invisible gestures before they could use their car.

Secondly, accidental inputs would happen with some frequency. People have a wide range of hand sizes, motor control skills, even number of fingers. Suppose I've got two of my fingers in a cast? I can use an existing car's dashboard just fine with that temporary impairment, but not this.

Finally, it's addressing a problem that already has a solution—physical, dedicated input devices. Humans have spatial memory, we learn where things are, and learn to reach for them without looking or even thinking. Your muscle memory tells you how to reach the wiper stalk or the gear shift, which is why it's sometimes disconcerting to get into a car with the gears on the steering column if you normally shift in the center console. We need in-car systems that let the physical feedback, affordances, and reliable location of buttons, knobs, and switches interact with display systems that are designed for the attention a driver requires. You should be able to keep your eyes on the road and still adjust the air conditioning—something the designer in this video recognizes—but that shouldn't require learning invisible gestures that are prone to user error.
My thoughts exactly. I doubt I go more than two hours without using something from moreutils.
That's stupid.

We are seeing web development moving to other platforms - true. Part of this is down to a change in the typical requirements for a web app. Some of it is probably down to performance, although in most cases Rails performs well enough with an engineer who knows what they're doing. Almost none of that shift is down to security issues, of which there are few.
The Last of Us has been out since June, and is still over $40 (down from $60) no matter where you look. I don't think it's the new standard to discount games that heavily.
Hmm... moving off "framework" to "language", "language", "language". No doubt you're a far better programmer than I am, but I sure as hell like using a framework with a bunch of very clever, very dedicated people maintaining and securing the framework I rely on... because I'm damn sure if I had to come up with the same functionality there'd be a heck of a lot of holes.
As a non-us engineer, I've had 2 visa applications denied. I guess Europe wins :D
Some people have already mentioned that you may want more than 8 controls. Perhaps a solution for this would be to have a max of 8 controls but the user could define which ones are mapped. Perhaps this interface can be a layer on top of a more traditional interface. That way the driver could customize the controls to fit his needs.
I prefer to talk to my car computer, it's based on Windows CE [1]. It works like Siri and predates it by several years.

http://en.wikipedia.org/wiki/Windows_Embedded_Automotive
The startup I co-founded is exclusively remote, with almost everyone in a different USA state. I've found a lot of the talent in the area we're looking for (Minnesota) find remote to be either a new idea (I've done just a little remote before), and perhaps a somewhat strange concept (many are not sure if they could do it all day long).

Is there any good strategy to finding remote workers in a specific geographic location? Yes, that's kind of antithetical to remote working, but the state offers tax advantages to employing people from the state... and looking through the entire state of Minnesota should find someone who's fine working from a home office... right? Or do those types of people really primarily live in the SV area?
The view-dependent stuff is in fact separated from the business conversion logic and can be used in a non-web context if you want.

Here's the version for use in a view context: https://github.com/rails/rails/blob/master/actionview/lib/ac...

You can see that this method has some XSS prevention logic.

Here's the converter itself: https://github.com/rails/rails/blob/master/activesupport/lib...
Definitely in the right direction. I've never thought long about solving for car interfaces, but I'd probably keep a more visual interface around and build it with these shortcuts in mind -- a basic point and touch interface for new users, and more gesture-based control for people that learn the system.

I'd also probably not do more than three-finger combinations. One, two, and three finger controls are pretty easy. Four and five require some hand contortions on car-sized screens.
I think that model oversimplifies it a bit, though for some implementations you're correct.

Often however IRC servers are either a hub or leaf. A hub accepts no user traffic directly and its IP address does not need to be publicly known. That makes it difficult to split the network since only the leaf addresses are known to an attacker.

As for the leaf servers, you can prioritize traffic between the leaf and hub over the traffic between the leaf and its users. You can also have them travel over different peers (most of the servers in the network I have experience with are multi-homed). Usually DoS attacks then manifest themselves as a large number of users timing out from their leaf server. Many IRC clients will attempt to connect to other known leaf servers when they cannot reconnect to the one that dropped them, meaning they get back onto a healthy leaf.

An attacker would then need to be able to saturate all (or at least most) of the leaf servers to take down the network. In my experience IRC servers run on networks that far exceed IRC's requirements and taking down all leafs at once would be a tall order for all but the largest botnets.

There have also been anycast IRC implementations which I don't have experience with, but I imagine they would mitigate most simple DoS attacks.
This is the problem with "modern" society / "invention". Touchscreen is not an improvement. It is in fact a downgrade. It adds nothing to the driving experience, and makes the device harder to use.

To quote Antoine de Saint Exupéry, "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away"

Modern "convenience" is more like modern pain in the ass.

My car is a 1991 and has manual locks, manual windows, manual everything.

Beyond the radio the only buttons in the entire vehicle are the headlights.
There is a button for the lights, and one for the brights. Pressing the one for the brights is rigged in a way that physically enables the bright button if it is not already depressed. High tech.

The heat controls consist of two vacuum powered left to right sliders.

I find myself want for nothing. Nothing. So simple. Nothing to break, nothing to worry about. It gets me from home to work, and back, reliably. It does what a car should.
I'm not sure how you infer this from what I said?

Even Ubuntu have plans to ditch upstart long-term, following Debian's lead to adopt systemd. Nobody is running "full-blown copies of Ubuntu" under docker, because full-blown would imply "with upstart" and using your distributions' built-in /sbin/init is precluded by the fact that docker overrides it, and also that Upstart doesn't work well in a container.

So people are running parts of Ubuntu without understanding that sometimes those parts had expectations of being child processes of upstart, and that upstart would always be running, when in docker-land that's not a reasonable expectation (and OP addresses this by adding in a more reasonable init, which probably handles most of these concerns.)

I just built the baseimage-docker, trying to get into it with ssh now, I can't imagine giving anyone a container and not letting them ssh into it, and I've added ssh to containers before in a way that I knew was non-supported or broken, so it's good to have this example. It looks like they are indeed doing it right.
One person can only play that particular lottery maybe half a dozen times (more likely 2-3). That isn't nearly enough for the law of averages to even things out, so if you don't have a lot of room for risk, the rational thing is to value the equity at 0 (in terms of long-term planning) and be pleasantly surprised if things turn out better than that.
Maybe just having physical buttons is vasty superior?
Agreed with you and smacktoward. Tevis' analysis gave me a lot to think about after playing the game, but during my play, I was nonplussed regarding the character arcs between Booker and Elizabeth, and the constant, brutal violence.
At some point you would probably be better off having physical button. A huge touch screen on which you need to draw weird gestures you had to memorize does not strike me as very user friendly.

That said that is neat implementation and it very elegant but I would like to have that in the living room rather than the car.

A possible evolution I guess would be to have different screen you would flick through that would group 2 or 3 command together with a big visual cue on the background.
Yes, especially in the US. There is also a huge bureaucracy problem.

Even at the current cost of PV and the current electricity prices, residential PV generation amortises in areas where a lot of air conditioning is required. This basically applies to the entire south west of the US.

The problems rather seem to be ignorance and an unwilligness to see a house as a long term investment.
The biggest oversight seems to be the utter lack of discoverability. Can you imagine trying to figure out of this works on a rental car ? or explaining to your grand-father how this works ?
Historical weather would fit your description. The NOAA has a large collection going back a century or more from different weather stations.

ftp://ftp.ncdc.noaa.gov/pub/data/
So it says "President Obama agrees net neutrality is important, but the FCC is an independent agency so the White House won't tell them what to do."

Honestly, that's not much, but it is still slightly better than I had hoped. Even if it doesn't involve any immediate action, it clearly acknowledges the problem and even takes a position.
Voice control or GTFO. It's already dangerous enough changing the radio channel with the physical button I know by feel. Touchscreen with no tactile feedback sounds like disaster.
Car manufacturers need to give up on the idea that one screen should control everything in the car. A touch screen just isn't suited for every task. Knobs are the best volume control and this is unlikely to change. They are also a great way to control air flow volume and temperature. While a touch screen could be great for selecting music to play, the other functions of the dashboard shouldn't be shoehorned into a touchscreen.

I'm not sure that the New Car UI is better than what car manufacturers have already done. None of the functions of this interface can be easily discovered. You would need to watch a training video to learn how to use one of these. It would be too easy to forget which gestures correlate to each function.
I would like to share how inhuman a lot of the interview processes are. Some examples:
* recruiter says a startup is interested, introduces me to the HR person via email. I get a 2 sentence email from HR, telling me that I have to schedule a phone technical interview in the next day or two, they need to onboard FAST.

Okay, I don't know what the job is, who the client is, and the last thing I want to do is be grilled over the phone. I'm certainly uninterested in your time crunch and am not going to rearrange my life to meet your schedule requirements (there were narrow stipulations on acceptable times).

* Talk with a company, and explain that I don't do whiteboard interviewing. Oh, a session is no problem, but the interview has to be as much letting me interview and question you. 'No problem, we just want to talk and see where you'll fit in'.

Come the day, and I barely get a 'hi', just nonstop whiteboard coding in an intense environment. Took the whole day off for that time waste. Two of the sessions had me solve essentially the identical problem - I waste my day, they don't take 5 minutes to plan out what I'll be asked. Then they call me back, and tell me I have to come in for another series a day later, which was entirely unexpected, and not communicated to me prior to agreeing to interview. And if my requests for how the interview is conducted can't be honored, fine, tell me, and either I'll change my mind or decide not to waste a day taken from work. The cap to all of that was the 'shoot the messenger' emails when I said I was not accepting due to how this all went down (and oh, I didn't respond quickly enough to that email, meaning it took me a few hours, so more grief for that).

* Just general, insistent demands as if I have nothing to do but interview with your company. If you have your resume out there, all you do is field phone calls and emails. I'm not going to pursue anything without knowing quite a bit about the job because I don't have to. There is always going to be better, low hanging fruit - cold emails with very accurate, detailed descriptions of a wickedly cool start up, recruiters that actually get to know your skill sets and desires, and so on.

* No exposure to what the work will be like. It's so secret they can't tell you, or there is a 'variety of work', or whatever. No work environment tour. No discussion of compensation, work hours, and so on until you've wasted a day or more in interviews.

* 'Go and study this book for a month, and then apply'. Um, I'm 47 and have a very successful career of inventions and products. Surely you don't have to quiz me on red-black tree implementation to access my abilities. If I need to know that, I'll open the book and learn it.

It was, by and large, very unpleasant. Perhaps it is not the best proxy, but I go in assuming the interview process is the time you are trying to impress and woo me the most, and judge you on that.
The designer evidently hasn't looked into any of the multitouch research. This interface would actually be far harder to use, learn, and get accustomed to than existing interfaces. It's unintuitive. There's no reason why 2 fingers should correspond to volume. With loose coupling like that, and no standards committee, hopping from one car to another will be extremely annoying.

Interfaces need to have strong couplings between action and zero overloading. Two finger ubiquitously means "scroll now" on trackpad. But even on an iphone, multitouch is seldom used for this reason. A trackpad has no images to display, so it is forced to overload gestures with multitouch. Phone don't have this limitation, and thus, intelligently avoid the use of multitouch.

As another anecdote, mobile games that rely on multitouch tend to not do so well.
>The nature of this (radio, etc) doesn't really matter. There will be a receiver on the car that can and will be identified and removed by criminals, rendering the stated purpose moot. Of course removing the receiver will be made illegal, as if this will accomplish anything.

It has been effectively impossible to hotwire a new car for over a decade, because modern cars simply will not start without the say-so of the ECU, which is a highly secure black box. Stealing a modern car means stealing the keys, because highly sophisticated organised criminals have failed totally in developing practical attacks to circumvent immobilisers. Build the remote shutdown facility into the ECU and it will be essentially impossible to disable. Send the remote shutdown instruction over a suitably designed radio link and jamming becomes utterly impractical. I have very little doubt that the motor industry is capable of designing a very effective remote shutdown systems; Relatively crude aftermarket solutions are already being used very effectively by fleet operators.

There are perfectly legitimate civil liberties objections to such a scheme, but the usual hacker trope of "technologies that I don't like can always be circumvented" is just plain wrong. Crime can be prevented or substantially curtailed through the effective use of technology, as we have seen in Europe with IMEI-based blocking of stolen mobile phones. Cash-in-transit robberies are now quite rare, due to design improvements in CiT boxes. Security technology isn't perfect, but that doesn't make it useless.
This seems like a really clever implementation of an system that's probably a passing fad.

Touch screens are great for portable computers both because they need to be small and because they need to enable a potentially limitless number of operations.

In a car the number of things that need adjustment while driving is relatively small and doesn't really change. We've had climate and audio controls since the 1950s. We've since added speakerphones and navigation, but the former only requires a couple of buttons, and the latter shouldn't really require any adjustment while driving.

There's also no shortage of space to put the controls.

My guess is that touch screens will start to dominate in cost-sensitive segments of the industry, while physical controls will migrate to luxury status in a few years.
You might also consider checking for the environment variable $EDITOR. It's defined by POSIX and there are existing tools that use it.
Don't stop, thanks to the two public programs you've run so far I've:

* Got into Ruby and Go (trying to get a feel for what language felt most comfortable for bit manip.)

* Got into assembly (for fun so far)

* Got a good appreciation for bit-level operations

* A bazillion more little facts and insights that help in daily work life

I bet if you polled how it's helped other people there'd be all kinds of great examples. For work, I'd say the best impact has been a personal drive to pentest our own product, resulting in a lot of bugs found and fixed. That included managing to root our servers via a product flaw, which was scary and amazingly fun.

So yeah, thumbs up, don't stop now (please).

As for the above catering to newcomers, sure but it ramps up incredibly and pushes some boundaries if you've never touched that stuff before.
The startup industry saw the same kind of interviewing voodoo in the 90s, copycatting how Microsoft conducted them.
You had the same gut reaction as me but if you look at the beginning before he started using it there was a legend of how many fingers map to each icon (no room for text as well?).

Beyond spatial memory what's good about this is that you don't have to look anywhere while still adjusting (some speech feedback about what mode you've selected would be good). The lack of sight is the most compelling aspect -- but I can guarantee you my parents would likely never remember the mappings and always have to look at the legend. Even then they'll probably be confused.
It's really not. It's a huge step back from even the interfaces he presented.

You exhibit the symptoms of somebody just introduced to multitouch and gesture recognition and trying to "explore the possibilities." The reality of gesture control is that they make for horrible user experiences. You are encouraged to try it on your own if you aren't convinced. Adobe, Apple, and a number of other companies did a lot of user study into this.

Double tap, twists, etc. All those gestures suck and fail for different reasons sadly.
You still down know if the display registered the correct amount of fingers. And you have to look to check.
I love this.

How are (non-public) Docker images handled (as in where are they stored)?

Do they need to be built on each machine before use?
My favourite touch screen UI on current cars is the one on the VW Golf 7. It has this proximity sensor that highlights and increases the size of buttons when your hand approaches the screen.

Overall, the interface is very clean and avoids a lot of visual distractions present in many of these UIs.

It lacks the responsiveness/speed we see on modern tablets, tough, this seems to be the rule on the market, even Tesla's screen is quite slow.

Video: http://www.youtube.com/watch?v=GyBUcCno_i8
I've never understood paying 3 recent to sell a house, especially in these times(Internet), and some markets
sell themselfs(Bay Area). Plus, the full commissions usually go to the best salesperson, or Cheerleader.
It's eight courses! Two years for a broker--who most likely
got their brokers license with any four year college degree.
(Yea--most of these guys partied through a bachler's degree
before this year and got their broker's license. They
lobbied Gov. Moonbeam to make it harder for anyone else
to do what they did--The Terminator saw right through the
ploy, and vetoed the bill--ironic?)
Success is moving Realestate. The average homeowner
only realizes they could have got more after they do
their homework, but that never really happens--they go into
denial after the sale. It's done.

I've never seen a industry that needs a fresh, iron clad
Application, but it has to be top notch. A hungry, smart developer could revolutionize the Realeste market
with the right code, and eliminate Realtors to a history
wiki. Plus--I would never need to look at their stupid
smiling faces everywhere. And yes, I know a house is the
biggest thing you will ever own--you need hand holding?
That's all your full commission will get. Smart Realtors
always cover their asses legally if you buy a Lemmon. This
is just my rant on Realtor's--especially full commission
brokers. The above post reminded me of how arcane buying
a house is.
> All of this is really to make the programmers more efficient, because programmer time is expensive (and getting stuff out the door quicker is important), but the amount of lost time (and money) on the user's end, waiting for these monstrosities of abstraction to compute something must far far exceed those costs.

I believe that the amount of time spent optimising software should be proportional to how long it will be used for, and how many users it has/will have. It makes little sense to spend an hour to take 10 minutes off the execution time of a quick-and-dirty script that will only be run once or twice. It makes a lot of sense to spend an hour, or even a day or week, to take 1 second off the execution time of software with hundreds of thousands or millions of users that constantly use it. At some point the overhead of optimisation is less than the time (or memory?) saved by everyone, so the "programmer time is expensive" line of thinking is really a form of selfishness; interesting that free/open-source software hasn't evolved differently, since it operates under a different set of assumptions.
This is exactly how I'm planning to architect my front-end code. Is Angular ideal for such environments or are there better suited frameworks.