Hacker News Reader

Comment by krallin | Hacker News Reader

I'm not an expert in embedded displays, but I assume you'd simply run a webserver on localhost.

I've done a couple of these, and that's close to what I did.

I started with a small "industrial" computer — Intel D525, 2g RAM, 40g SSD — costing about $300. I installed Ubuntu 12.04 Alternate with X and Fluxbox. I used Chrome for the display. I configured it to log on automatically upon booting, start X, and run a script configured to start Chrome pointed at the proper URL.

Then I used remastersy† to create an installation USB stick. Boot from the stick, and it installs the customized Ubuntu non-interactively. The first time the system boots, it runs a little dialog where you tell it its role in the system (i.e, what view of the overall status should it display).

If you later need to reconfigure it, you can log in over SSH and run scripts to change the configuration. Or, if absolutely necessary, you can visit in person, open the cabinet, and hook up a keyboard.

It spends almost all its life waiting on an XHR, which asks essentially, I'm showing version x, send me the next version when ready. When version x+1 comes along, the server replies to all the XHRs waiting for version x+1 with a chunk of JSON describing version x+1. The displays then all update their DOMs and hang an XHR for the next version.

I later added a separate heartbeat loop. Once a minute, it asks the server if it's alive, and it puts up an out-of-service screen if the server stops responding.

†http://www.remastersys.com/

Tangent, but I've found it a bit odd to see Out of Service messages on billboards. Why not display a default ad (e.g. "Your Ad Here")?

Actually on that note I'm surprised I don't see more community/charitable notices in the mix for digital boards (these could serve as "defaults"). Having non-commercial and regularly changing ads in the mix would actually get me watching, and is potentially even tax-deductible.

You don't even need to go that far, you can reference local files with "file://" instead of "http://". That said, most digital signs are digital because they change so a [web] server somewhere along the line will be used.

Web server means additional complexity both to deploy and maintain. After 20+ years in the corporate world I can guarantee that an alone-standing native client it going to beat anything with a web server.

A lightweight local web server is not going to be any more complicated than a stand-alone program that does the same thing.

The web site you build does the same thing that the standalone app does. The web site is hosted by the web server. That's an added piece of software to maintain and configure, over and above the web site itself.

The web server is going to be fine. It's usually gone through a lot more testing than your display. Displays are trivially and commonly implemented as fullscreen webapps.

It's the browser javascript that I would worry about; responsiveness is always a battle.

"Beat", how exactly? 20+ years in the corporate world doesn't mean much if you can't back your opinion up with proper arguments.

Besides the confusing fact that you bring HTML5 local storage into the equation for some reason, a local web server doesn't necessarily mean more complex deployment/maintenance than maintaining a .NET application.

The problem is governance. The web sever needs to be patched, the web site configuration needs to be maintained, as does the web application. Bear in mind that a display doesn't live in an IT department, and that developers don't maintain apps - operations does. So if you compare the web server/web site scenario to a single, self-configuring native app (presumably a single .exe and a couple .dlls or something, the .exe is cheaper over a 3 or 5 year lifespan, especially if the .exe works with SCCM and ops can push updates out using WSUS or similar.

I guess if you're into Windows, setting up a web server actually _is_ a hassle to you. Rest assured that there are easier ways. If you simply want to use a web server for local sharing, forget about patching and "maintaining" the configuration. Just install it and you're done (or why not use the file:// URI scheme? I can't see any compelling reason not to in a non-interactive setup). As for maintaining the web application, well, only in the same sense you have to maintain your .NET application.

Also, pulling numbers out of nowhere isn't going to help your argument.

If anyone I oversee actively decides to not patch and maintain a system within an enterprise network for any reason, they will find themselves back on helpdesk doing password resets until they learn better. Pentesters / hackers love using setups like you suggest as easy targets to provide them with perstitant backdoors.

3 and 5 years are the common life cycle's enterprise IT use when discussing any existing implementation or any new system design. These are not pulled from nowhere.

First off, when I say "maintaining" I meant the configuration. When I say patching, I mean patching, not just trivially installing software updates. Spearchucker was trying to make this a look like a huge disadvantage over maintaining a Windows system, which it obviously is not.

Oh and as far as I'm concerned "3 to 5 years" is still pulled out of nowhere. You aren't mentioning any sources, just describing a really vague process that you think is "common". If you have a working, flexible system with which you can harness a huge continuous effort in developing the technology behind it for free, you aren't going to kill it off just because your enterprise clock says so.

Reply on news.ycombinator.com