Hacker News Reader

Comment by Spearchucker | Hacker News Reader

Not to detract from your points (you make good ones); web is probably not a good medium for such displays. Not always, at least. You'd want them to be reasonably functional without comms. Last I checked (I may be wrong), HTML 5 constrains local storage to 5Mb, which is precious little, if the display uses images/media.

View on HN

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

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.

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.

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.

localStorage isn't for resources, it's for data.

That's a very valid point.

About 7 years ago, I worked on an embedded system that had to be localized to a few different languages.. I actually used mono for the main display portion on Linux. It really didn't have much to do with mono, it was essentially an embedded browser run full screen. The content was local html files as menus, and the input logic was separate from the display (it used a keypad, not touch screen, as the end product was deployed in relatively hostile environments).

The biggest reason for html as the menu format was it would be the best format (in terms of flexibility) to use for the display content and localization. The local db was embedded FirebirdSQL, and connected to a remote Firebird instance running on a central server (transactional data was replicated as connectivity was available, and it wasn't more than half the time)

If I were going for a digital signage solution even two years ago, I would probably lean towards windows. There still aren't tools for developing visual animations that match what Flash (though deprecated) offered. Flash is really easy to embed in a full-screnn app, and offers a lot of flexibility for the purpose. The tooling is broadly available, and setting up a canvas of the right proportions is all you need to start.

Flash costs a lot more than Windows even. IMHO The cost of software licensing is really minimal for most companies for these kinds of things.

Today it would be a tossup of a windows solution with Flash and/or an embedded or otherwise chromeless/fullscreen browser and a linux solution. If I were to guess, the windows solution would probably be done faster. Dealing with multiple displays and orientations in Linux is much more of a PITA, let alone that VS is actually pretty decent.

Use local files for that.

> HTML 5 constrains local storage to 5Mb, which is precious little, if the display uses images/media.

You wouldn't use localStorage for images.

Reply on news.ycombinator.com