See the Reedy Creek Improvement District, for a US analog:
http://en.wikipedia.org/wiki/Reedy_Creek_Improvement_Distric...
2,699 karma · joined May 6, 2008
http://en.wikipedia.org/wiki/Reedy_Creek_Improvement_Distric...
"ACM Flight Simulator, revision 4.7
What is ACM? ------------
ACM is a LAN-oriented, multiplayer aerial combat simulation. My main design objective was to provide source code that could be easily compiled and executed on a wide variety of platforms. To that end, acm is written entirely in C, exploiting the programming features of Unix, X11, and the BSD socket interface.
Players engage in air to air combat against one another using heat seeking missiles and cannons.
ACM is implemented as two programs. The first, named "acm", is a small program that, when invoked, starts a flight session on a given workstation.
The second component, named "acms", is a server process that manages the multiplayer environment. It also manages the flight simulation and display management that is required. Most players will prefer to run the acms process on a back-end server system on their local area network. Players at client workstations can then invoke the acm program to begin play."
http://threatpost.com/facebook-underplays-data-exposure-from...
In this case, adding a very brief overview of what Ember.js provides, and links to more info would seem appropriate.
Not everybody landing on that page knows what Ember is or why they might want to learn it, after all.
With the recent IPv4 address burn rate — the allocation rate the last remaining addresses block were issued — reclaiming a half-dozen /8 blocks would be a rearguard action at most, and an effort and a hassle that would detract from IPv6.
For data, select the column with the IANA date sort here:
http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addres...
and then consider how long a few more added /8 blocks would really last. By my count, fourteen /8 blocks since 2009. And the rate that network-connected devices are arriving isn't slowing.
So what can be done?
There are systems with firmware that can automatically detect failed updates or corrupted firmware, or where a failsafe firmware loader can be triggered by a jumper or related request, and that can then perform a reset and (re)load of replacement firmware.
Without requiring a test harness or JTAG access or other equipment.
In various of these cases, there are two copies of the firmware, meaning the old firmware can be immediately accessed, or — pending successful completion — a second copy of working firmware can be generated.
In one case, a system had its firmware mostly in ROM, and had NVRAM that could hot-patch routines via an NVRAM-based vector table, and with space for replacement routines in the NVRAM. This meant that the box would always boot, and bad vectors could be detected by checksum, and firmware bugs could still be patched up to the limit of the available NVRAM.
Put another way, we know how to avoid this mess. It just costs some time and effort and money, and that can get this capability cut.
This stuff is not rocket science.
The high bits of the condition value format can also tell you more about what component returned the error, and there were a few control flags up in the highest bits, including bit 31 (the sign bit) which inhibited message display.
Somewhat unusually, the low three bits of the condition status value are used to indicate varying levels of success or failure; the success (0b001), informational (0b011), warning (0b000), error (0b010) and severe/fatal (0b100) errors.
VAX had the BLBS and BLBS instructions for testing and branching on the low bit, too.
These success- and failure-testing instructions were separate from the BEQL/BEQU, BNEQ/BNEQU, BGTR/BGRTU, BGEQ/BGEQU, BLSS/BLSSU and BLEQ/BLEQU that looked at whether the signed or unsigned value was positive, zero or negative, or zero or greater, or zero or less. A condition value that had been displayed or otherwise inhibited was switched to a negative value.
Yes, VAX had a lot of instructions.
This usage of the low bit also led to the semi-inevitable "Success on VMS being odd" in-joke.
Moving mass — people moving around — within a rotating structure will transmit vibrations throughout the structure, even with mass dampening.
As an example of the considerations around vibrations within ISS, astronaut Sunita Williams indicated that the ISS exercise equipment is intentionally isolated from the ISS structure, as the vibrations of the crew members exercising causes problems for the solar arrays.
Stumbles, fumbles, mumbles and grumbles.
These can be relatively early external signs of altered mentation and potentially of the on-set of hypothermia.
Hypothermia can occur even in fairly warm temperatures, too; you don't need freezing temperatures.
When carrying food, remember you're going to be eating a whole lot more when it's cold and you're exercising.
Avoid cotton clothing, as that gets and stays brutally cold when it gets wet. Wool or synthetics work much better.
Which means there's no need to rush to order today.
[1] This based on the 50% control requirement listed in the existing JetBrains license.
If you're attacking, having flexibility is advantageous.
http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_...
http://www.hp.com/hpinfo/globalcitizenship/environment/techg...
What's this? Why is this here? Why do I want it? Why is this good? Why do I care? Why? What's that mean? What's this knob do? What's that code do? Why is this code here? Why?
Flabby documentation, user documentation written in programmer jargon and scatter-shot code comments are all comparatively easy to write. When somebody bothers to write that.
Writing for the end-user (whoever that might be) is tougher, and I find require iterating on the content of the documentation, UI, release notes, comments, or whatever. Writing less documentation or fewer comments — while conveying the necessary details — is hard work.
http://www.globalsecurity.org/military/world/carriers.htm
scroll down for the image.
In emergency services, specialists tend to be communications officers or dispatchers, or the radio shop, and variously assisted by the computers and the radio consoles that are increasingly supervising the radio networks.
To a reasonable degree, radios need to be useful and functional and understandable by everybody in the organization; to all of the users. It's this ubiquity that was at issue with the original article, and it's the radio's UI that tends to be inscrutable.
If you can drop it, slam it, whack it, rain on it or even dunk it, cover it with blood or vomit (and clean it), balance your weight on it on a stairway, use it as a wheel chock (unintentionally) and (depending on the particular users) operate it with your gloves on, then we'll talk.
For some users, you further need to allow for heavy gloves.
Or provide emergency buttons, or other features.
As great as it is, iPhone isn't close to providing this.
Even in a system that's been architected with specific channel layouts, there's almost always some weirdness somewhere, and some differences, and some number of radios always seems to arrive mis-programmed and needs a trip back to the radio shop, and this if the folks receiving the batch of radios are paying attention and can afford the reprogramming. Not all do, or can, either.
Not all radio shops pay attention to what they're doing here, and even the good shops can be using radio service software most charitably described as atrocious.
And yes, anyone that thinks you can have everybody on one of the mutual aid frequencies is headed for trouble. The pile-ups are always massive. Add in encryption and tone squelch (CTCSS, PL) and you might be stomping on the other agencies without knowing it.
In a typical organization, you'd want your dispatcher(s) or communications officer(s) or (if not delegated) one of the senior officers on the shared channels.
Modern radios can be surprisingly complex tools, and the FCC migration to trunked radios and digital trunked radios, and adding inter-operations features (gazillions of channels, etc) and digital communications and deadspots, and the over-the-air rekeying and reprogramming, emergency button(s), and the seemingly obligatory remote kill can all combine to makes your average high-end radios hairy.
Certainly various radio users don't regularly train with and aren't familiar with the "odd-ball" channels; the "national" and mutual aide frequencies can have different names, or weird local oddities, and many of the end-user folks are often trained to stay off the other channels.
Training is certainly part of this, and of using the radios correctly. Conversely, you're probably not expecting the folks to be picking random channels. In the newer radio systems, you can be told (by dispatch or by your supervisor) which channel to use, or dispatch can reprogram your radio and your talk group(s) on the fly.
And as for training, every emergency services department I'm familiar with has been chafing under the political and technical and documentation requirements arriving from outside entities; blanket mandates requiring time and thought and budget for stuff that's probably never going to happen to a given individual or agency, but the obligatory training and documentation requirements pull the folks away from the stuff that they can and will be dealing with. Like dealing with their radios. And delivering whatever service the folks hired on to provide.
Yes, modern radios can be far more complex than it should be. So is the rest of the mess.
Startup ideas here? Sure. The two-way radio version of a ruggedized iPhone; a radio with a "modern" UI.
If I had my druthers here, I'd like a build tool that wasn't a layer atop GNU/Linux/Unix — and that's not to imply how autotools works here is at all bad or particularly wrong, it's just an approach that's a bear to port the tools — and have that (portable) build tool then generate the platform-specific build script, build procedure, build-whatever equivalent.
Conceptually: to move the existing builds from a procedural, interpreted approach into a higher-level and object-oriented approach.
Among those of us that have attempted or have done that port, most will probably not look particularly favorably on autotools again.
One of the easiest approaches here involves reverse-engineering the autotools product from a test run performed on a GNU/Linux box, and then translating and building a platform-specific script.
From what I can tell of it, autotools makes substantial use of GNU/Linux features. Which is certainly fine for its intended platform and typical usage, but it's an approach that is Not Fun for porting that code.
http://txchnologist.com/post/32463368168/channeling-star-tre...
For starters, acquire the reputation for providing high-touch, enterprise-grade, enterprise-focused, enterprise-costs support, with all that entails, and preferably with a cost somewhat below what Oracle charges.
Provide enterprise-friendly DBA training, certifications, and other related materials.
Have your sales reps schmooze the C-level office, and the IT leadership.
But adoption of databases in enterprises in general? They're loathe to change their databases, and have massive investments in their existing software and hardware processes, and their staff and training. The costs involved here are staggering.
If you're looking for more organic growth (and as some of those smaller companies grow and get bigger), that'll happen. But it'll take years. Maybe some acceptance in smaller projects in enterprises, but this sort of "shadow IT" can be a guerrilla effort in an enterprise; discouraged by management.
With WP8, HP does what it's comfortable doing - hardware - and Microsoft does the software stack.
Whether HP (and Microsoft, for that matter) can gain traction against Android and iOS remains to be determined.
And going against an organization that's "saturated with lawyers"?
Even if I were creating a voter registration web site, I'd likely not use this package, as reusing this PDF fulfillment package for any other use within that web site would potentially put the organization in licensing jeopardy. With this license, it'd be safer to re-implement rather than to re-use.
I'm not touching this license with a barge pole.
This permission does not include: (a) any use of the Software other than for its intended purpose; or (b) any use of the Software in any manner that violates applicable law. Any use of the Software other than as specifically authorized herein is strictly prohibited and will terminate the license granted herein.