Do you know if this was in a fit of some sort of weird exuberance about the imaginary all-IP economy of the future, where boring things like actually doing stuff will be abandoned; or has the notion that "Kodak" has some kind of hope really just been propped up as long as it has in order to make time to get the real assets shoved into legally separate boxes and centralize the liabilities for the sacrificial bankruptcy of a nearly asset-less shell?
Given that Kodak did substantial amounts of actually pioneering work in imaging(I'm sort of saddened that some bullshit about 'preview' was the best they could dredge up for some trolling) and then managed to do for digital cameras approximately what Xerox did for PCs, I suspect that shaking down the people who didn't reach deep into the mouth of victory and grasp hold of defeat will be what their patent portfolio ends up being used for...
The thing that surprises me, a bit, about Kodak's fall from grace is that being a film titan, at their prime, involved substantial chemical manufacturing capacity and expertise. Was that non-transferrable to some other area of chemical production, or did they somehow get rid of their boring-but-solvent departments in some strange reorganization scheme? Same question would go for any departments involved in optics, industrial imaging, etc.
Software engineering is definitely a vocation(or at least a job). Paint-by-numbers in the corporate fad language of today, assured to be obsolete by the time you graduate, is also pure vocational training. So too are the specifics and details that are involved in large-scale projects(knowledge of revision control, project management and project-being-managed, etc, etc.)
However, computer science is a branch of mathematics and arguably has the same claim as calculus or geometry to some portion of instructional time purely as a matter of general education. In addition to simple 'breadth-of-knowledge' stuff, the same thing that rationalizes all curriculum that isn't purely vocational, there is a very good argument to be made that a degree of programming knowledge(on the level of basic shell, or python, or even Office vbscript macros) is a very, very valuable tool for enormously increasing the power of the learner over all sorts of computer-related or computer-assisted tasks(which a great many of them will almost certainly be doing at some point in their lives, even if with a different high-level scripting/glue language).
Unless the kiddie wants to actually go down the CS path, flunking him for failure to grok MIPS assembly or keep his pointers straight is mere cruelty without purpose. Giving a basic grounding in programmatic operations provides enormous power over the "I could just do it manually if there were 10 of them; but there are 10,000" style problems is both practical and (potentially) might spark further interest.
Honestly, guys, it isn't that hard. Pretty much any question about facebook can be answered by asking yourself "If the NSA and the National Enquirer merged, what would they do?"
Once the subscriber base for WoW starts falling off, they'll manage to pull the employees away from the giant cocaine fountain in the lobby and the omnihedonic stimulus cocoon in the break room.
Unless the protective case is shaped like some sort of hyper-aerodynamic reentry vehicle, wouldn't the relatively low terminal velocity make the vast majority of the fall completely irrelevant?
Isn't merely discussing this topic running the grave risk of having the ghost of Donald Knuth come from the future, heavy with unutterable wrath, and smite us all?
I'm a bit surprised that it wasn't caught purely as a side effect of other procedures... If I were planning on running fuel through something important that might theoretically be contaminated with lubricants/condensation/whatever, I'd strongly consider blowing $5 worth of compressed nitrogen through it until the outflow is clean...
Catching every little thing that might gum up the fuel lines during assembly, testing, and cleaning seems like it could be a genuinely hard problem. Doing a combination pressure test/gas flush seems like it would be a cheap, simple, brute-force solution to that entire class of potential problems...
I suspect that(while they will probably be of assistance to geeks brewing their own) this will suffer the same fate as all the prior 'automated house' widgetry(a market at which they've been hammering for bloody ages now, with comparatively little success).
Suitably motivated geeks, with some major time and pains, and more money than they initially expected to shell out, will indeed hammer out home automation systems. Fundamentally, home automation is a series of really-not-all-that-ghastly problems in AC wiring, switching, sensors, and logic. It will be utterly non-inter-operable with anything else(save perhaps the geek's cellphone of choice, for which he will build a website/app, and possibly an appliance or two into which he will hack directly. Nothing else.)
Joe User, on the other hand, will discover that specific home automation products(eg. cheap programmable thermostats) can be purchased at any hardware store; but more sophisticated systems either pretty much suck, enough that they are really just starting parts for dedicated geeks(eg. X10), or can be purchased, from an installer, in one big, shiny, expensive, bespoke, proprietary package. It'll start at $10,000, be really slick, and interoperate with absolutely nothing that isn't itself.
The various utility companies attempting to deploy "smart meters" for some combination of PR, easier meter reading, and customer behavior metrics will utterly ignore this, since it doesn't comply with their alphabet soup of semi-open-for-interoperability's-sake-but-not-at-all-talked-about-outside-the-industry-or-intended-for-you-to-know-anything-about wireline and wireless protocols(their status seems rather analogous to the state of various 'standards' in the wireless telco wars. Some of them are just totally proprietary, dreamed up by some company large enough that its service area qualifies as a large scale deployment. Others, GSM-like, are standardized cross-industry things; but are really not intended to be fiddled with by end users.
All in all, no difference:
There will still be nothing resembling manufacturer support for appliances that can report and control intelligently(as opposed to just having an external relay cut them on and off, with the exception of a few horrible manufacturer gimmicks that will probably be badly broken and tied to some manufacturer 'portal'. Geeks will continue to homebrew functional, if slightly rough, systems; and it will still be possible to buy very shiny, tightly integrated, totally proprietary widgets for large buildings and custom installs of various sorts.
What dogs 'the automated house' seems not to be a lack of cheap computing power(wireless and fast CPUs certainly helps; but ASM coded PICs communicating over some primitive serial bus through your house's telephone wiring back in the late 80's could have handled it, with some sort of frontend/master-control widget similar to the x86/DOS based CNC machine control systems that persist to this day. Expensive? Yeah. Doable? Yeah.) It seems to be a combination of limited incremental benefit(power just doesn't cost that much, in many locations, doing it manually works OK, for most tasks, setup is currently complex, many locations charge residential customers the same for on and off peak power, so who cares?), complete lack of anything resembling standardization(minimal standardization of even simple things like remote control switches, never mind any sort of direct intelligence built into appliances that can be exposed. PCs have it, in a somewhat clusterfucked way, with ACPI; and some individual devices, like higher end furnaces, might have a manufacturer specific control panel on an HTTP server somewhere; but everything else is largely silent), and some degree of sinister intent by certain entities(the intentions of the power-rationing, 'consumer-metric'-gathering, and similar 'smart-meter' entities are largely not in your interest...)
It's a pity: If it were a primarily technological problem, technology would have curb-stomped it by now. It isn't.
Depends on the application. Arduinos make twiddling a few logic-level pins and some other useful interface-to-the-world logic quite simple, which is fantastic for certain applications(Linux devices aren't totally impossible in this regard, there are usually some GPIO pins hiding somewhere, and a 'sound card' is a quite capable ADC/DAC if you can manage to get reasonably non-mangled values out of whatever drivers where almost certainly designed for making noises, not sensory applications...).
On the other hand, while larger systems have (arguably) been getting increasingly hostile to simple sense-and-control, it sure is nice to be able to spin up some huge, luxuriously wasteful interpreter and bang away in the high level language of your choice, complete with all sorts of fun network and persistent storage stuff...
It is pretty much assured that it will scale better and cost less than all those effects for which the fundamental physics don't actually work, so we are off to an atypically promising start...
I don't have anything in particular against today's IIS, my point was just that commodification, outsourcing, and scale are arguably a danger to Microsoft(and anybody else who is trying to sell licenses for software that isn't leagues better than the OSS competition). If you are running a server, or a handful of servers, even fairly exorbitant license fees are small change compared to the value of being able to use whatever it is your available people have expertise in. However, as the number of nodes you are running increases, the cost per unit of having expensive experts keeps on falling, while the cost of licenses doesn't.
Microsoft's real threat is not so much that the customers currently using IIS will directly abandon them for apache or nginx; but that they will abandon running IIS internally for buying web services from somebody else, who is much less likely to be running IIS.
Quite true; but I suspect that anything running a VMware View client(if the VM is hosted remotely, this is what a system developed with VMware is going to be using) or something running a full x86 VM on top of vmkernel(if the VM is hosted locally, this would be the VMware tech most likely in use) is not going to qualify as "simple" for any terribly useful definition of the term, certainly no simpler than the more-or-less-normal-but-in-an-armored-case x86s that Diebold usually uses.
The one major advantage of this VM approach(that could also theoretically be implemented at the BIOS level, or with a suitable LOM card) will likely be that it will make nuking the OS running the ATM software much easier, which will make it cheaper to clean known-rootkitted systems, as well as economically feasible to preemptively nuke-and-pave with a known-good image, just in case the system has been compromised with a bug you can't detect at present.
I don't know of any premade options; but if you have one of the Model M's with removable keycaps, there are probably enough Model M enthusiasts around that you could CAD up and have printed in laser-sintered, bronze impregnated, stainless steel(not real stainless steel; but similar, and the copper in the bronze probably helps the antibacterial value. If you could get the quantity up, fully stainless steel parts punched out of sheetstock would probably be doable; but that wouldn't be a 'quantity 1' thing...)
Unless they fuck it up pretty horribly, IIS has an assured future as the embedded webserver for default installs of the various Microsoft products that have a web-facing component(ie. Foocorp installs exchange, exchange.foocorp.com/owa is going to be providing 'Outlook Web Access' via IIS... Ditto with Sharepoint and similar).
If Microsoft has plans for people to actively shell out a nontrivial amount of money just to run a commodity HTTP server, though, they'd better have something good in mind, especially now that so much commodity HTTP serving is done on an outsourced basis by 'cloud' types or CDNs, both of which generally care a great deal about per-node costs that scale linearly with volume(like software licenses, or low end admin flunkies); but care substantially less about fixed costs(like having a serious guru on staff to deal with the esoteric intricacies of whatever they are using).
The real trick(and the likely determinant of whether there is actually a problem or not) will be whether or not UV tolerant bugs that are otherwise competitive with their non-tolerant peers and the human immune system crop up.
There are some downright alarming extremophiles, that can shrug their teeny bacterial shoulders at gamma radiation, hard vacuums, heat, dessication, and sometimes several of the above at the same time; but those tend to be virtually irrelevant to human health because so much of their biology is geared toward surviving extreme conditions. Under normal conditions, it's the swarms of relative weaklings that carry the day and probably kill you.(the same thing crops up with antibiotic resistance: most of the time, antibiotic resistant bugs are uncompetitive against their nonresistant except in antibiotic laced environments, which has led to interest in various dosing strategies designed to exploit nonresistant bugs to outcompete resistant bugs and then chemically kill the now-vulnerable remaining population.)
If the keyboard merely becomes host to a swarm of bacterial curiosities with neat DNA repair mechanisms, it'll probably be a fun project for some bio researcher to investigate; but it won't be a major threat to human health. If we get unlucky, and some exciting pathogen hits upon a cheap way to resist UV, we could have a problem... We could also have a problem, regardless of bacterial evolution, if people start treating the keyboards as some sort of magic bullet: Normal keyboard + paranoid hand washing may well be better than special antibacterial keyboard + 'eh, the keyboard is antibacterially magical, no problem' hand washi8ng...
Ah, but it's hitting a thumbtack with a sledgehammer that you can charge monthly hosting fees for, and disable immediately if the customer doesn't pay up.
The "Provide product, receive money, repeat." business model is, like, totally retro, man. Why do that played-out stuff when you can make the customer pay for the box and build in technological measures to yank the firmware if they ever stop paying, then call it a security feature?
All the cool kids are building in network-dependent 'security' features into their products so that they can get all the benefits of having the customer on the end of a rent-to-never-actually-own agreement; but structure the initial transaction with all the legal flourishes of a genuine sale...
Luckily, some fancy VM setup definitely prevents customer data from passing through the local PIN pad and/or touchscreen controller hardware. Thankfully, hardware keyloggers suddenly give up in defeat if they are asked to log keystrokes going to a super-secure remote VM...
Do not worry. All violations of the law deemed convenient to the national economic interest, or carried out by suitably favored people, will simply be ignored for the sake of practical efficiency.
Next time unlucky activist visits foreign NGO website? Visit from secret police...
I imagine that the sophisticated espionage types who want to abscond with your rocket-building expertise(for competitive purposes, or because you aren't selling toys to their nation state of choice) probably aren't stopped by fences and dogs. If they are really serious, you've already hired them and they just walk in the front door every morning. If that is your concern, the prison-camp props probably aren't a huge deal.
I am somewhat surprised, though, that they haven't had a greater incentive to repair the fence and put together something resembling a night watch for reasons of simple theft. Rocket surgery presumably involves some expensive tools, and big piles of parts and stock in various rather pricey metals and alloys. If your security is so fantastic that bored bloggers are wandering in, I'm amazed that the whole operation hasn't been melted down at the nearest scrapyard of loose morals...
Slashdot Mirror
Do you know if this was in a fit of some sort of weird exuberance about the imaginary all-IP economy of the future, where boring things like actually doing stuff will be abandoned; or has the notion that "Kodak" has some kind of hope really just been propped up as long as it has in order to make time to get the real assets shoved into legally separate boxes and centralize the liabilities for the sacrificial bankruptcy of a nearly asset-less shell?
Kodak is the Xerox of digital imaging.
Given that Kodak did substantial amounts of actually pioneering work in imaging(I'm sort of saddened that some bullshit about 'preview' was the best they could dredge up for some trolling) and then managed to do for digital cameras approximately what Xerox did for PCs, I suspect that shaking down the people who didn't reach deep into the mouth of victory and grasp hold of defeat will be what their patent portfolio ends up being used for...
The thing that surprises me, a bit, about Kodak's fall from grace is that being a film titan, at their prime, involved substantial chemical manufacturing capacity and expertise. Was that non-transferrable to some other area of chemical production, or did they somehow get rid of their boring-but-solvent departments in some strange reorganization scheme? Same question would go for any departments involved in optics, industrial imaging, etc.
I (somewhat) beg to differ:
Software engineering is definitely a vocation(or at least a job). Paint-by-numbers in the corporate fad language of today, assured to be obsolete by the time you graduate, is also pure vocational training. So too are the specifics and details that are involved in large-scale projects(knowledge of revision control, project management and project-being-managed, etc, etc.)
However, computer science is a branch of mathematics and arguably has the same claim as calculus or geometry to some portion of instructional time purely as a matter of general education. In addition to simple 'breadth-of-knowledge' stuff, the same thing that rationalizes all curriculum that isn't purely vocational, there is a very good argument to be made that a degree of programming knowledge(on the level of basic shell, or python, or even Office vbscript macros) is a very, very valuable tool for enormously increasing the power of the learner over all sorts of computer-related or computer-assisted tasks(which a great many of them will almost certainly be doing at some point in their lives, even if with a different high-level scripting/glue language).
Unless the kiddie wants to actually go down the CS path, flunking him for failure to grok MIPS assembly or keep his pointers straight is mere cruelty without purpose. Giving a basic grounding in programmatic operations provides enormous power over the "I could just do it manually if there were 10 of them; but there are 10,000" style problems is both practical and (potentially) might spark further interest.
Honestly, guys, it isn't that hard. Pretty much any question about facebook can be answered by asking yourself "If the NSA and the National Enquirer merged, what would they do?"
Once the subscriber base for WoW starts falling off, they'll manage to pull the employees away from the giant cocaine fountain in the lobby and the omnihedonic stimulus cocoon in the break room.
At that point, it should be the usual 3-5 years.
Unless the protective case is shaped like some sort of hyper-aerodynamic reentry vehicle, wouldn't the relatively low terminal velocity make the vast majority of the fall completely irrelevant?
Never underestimate the bandwidth of a V2 loaded with reel-to-reel tapes and sent in the general direction of London...
Isn't merely discussing this topic running the grave risk of having the ghost of Donald Knuth come from the future, heavy with unutterable wrath, and smite us all?
I'm a bit surprised that it wasn't caught purely as a side effect of other procedures... If I were planning on running fuel through something important that might theoretically be contaminated with lubricants/condensation/whatever, I'd strongly consider blowing $5 worth of compressed nitrogen through it until the outflow is clean...
Catching every little thing that might gum up the fuel lines during assembly, testing, and cleaning seems like it could be a genuinely hard problem. Doing a combination pressure test/gas flush seems like it would be a cheap, simple, brute-force solution to that entire class of potential problems...
I suspect that(while they will probably be of assistance to geeks brewing their own) this will suffer the same fate as all the prior 'automated house' widgetry(a market at which they've been hammering for bloody ages now, with comparatively little success).
Suitably motivated geeks, with some major time and pains, and more money than they initially expected to shell out, will indeed hammer out home automation systems. Fundamentally, home automation is a series of really-not-all-that-ghastly problems in AC wiring, switching, sensors, and logic. It will be utterly non-inter-operable with anything else(save perhaps the geek's cellphone of choice, for which he will build a website/app, and possibly an appliance or two into which he will hack directly. Nothing else.)
Joe User, on the other hand, will discover that specific home automation products(eg. cheap programmable thermostats) can be purchased at any hardware store; but more sophisticated systems either pretty much suck, enough that they are really just starting parts for dedicated geeks(eg. X10), or can be purchased, from an installer, in one big, shiny, expensive, bespoke, proprietary package. It'll start at $10,000, be really slick, and interoperate with absolutely nothing that isn't itself.
The various utility companies attempting to deploy "smart meters" for some combination of PR, easier meter reading, and customer behavior metrics will utterly ignore this, since it doesn't comply with their alphabet soup of semi-open-for-interoperability's-sake-but-not-at-all-talked-about-outside-the-industry-or-intended-for-you-to-know-anything-about wireline and wireless protocols(their status seems rather analogous to the state of various 'standards' in the wireless telco wars. Some of them are just totally proprietary, dreamed up by some company large enough that its service area qualifies as a large scale deployment. Others, GSM-like, are standardized cross-industry things; but are really not intended to be fiddled with by end users.
All in all, no difference:
There will still be nothing resembling manufacturer support for appliances that can report and control intelligently(as opposed to just having an external relay cut them on and off, with the exception of a few horrible manufacturer gimmicks that will probably be badly broken and tied to some manufacturer 'portal'. Geeks will continue to homebrew functional, if slightly rough, systems; and it will still be possible to buy very shiny, tightly integrated, totally proprietary widgets for large buildings and custom installs of various sorts.
What dogs 'the automated house' seems not to be a lack of cheap computing power(wireless and fast CPUs certainly helps; but ASM coded PICs communicating over some primitive serial bus through your house's telephone wiring back in the late 80's could have handled it, with some sort of frontend/master-control widget similar to the x86/DOS based CNC machine control systems that persist to this day. Expensive? Yeah. Doable? Yeah.) It seems to be a combination of limited incremental benefit(power just doesn't cost that much, in many locations, doing it manually works OK, for most tasks, setup is currently complex, many locations charge residential customers the same for on and off peak power, so who cares?), complete lack of anything resembling standardization(minimal standardization of even simple things like remote control switches, never mind any sort of direct intelligence built into appliances that can be exposed. PCs have it, in a somewhat clusterfucked way, with ACPI; and some individual devices, like higher end furnaces, might have a manufacturer specific control panel on an HTTP server somewhere; but everything else is largely silent), and some degree of sinister intent by certain entities(the intentions of the power-rationing, 'consumer-metric'-gathering, and similar 'smart-meter' entities are largely not in your interest...)
It's a pity: If it were a primarily technological problem, technology would have curb-stomped it by now. It isn't.
Depends on the application. Arduinos make twiddling a few logic-level pins and some other useful interface-to-the-world logic quite simple, which is fantastic for certain applications(Linux devices aren't totally impossible in this regard, there are usually some GPIO pins hiding somewhere, and a 'sound card' is a quite capable ADC/DAC if you can manage to get reasonably non-mangled values out of whatever drivers where almost certainly designed for making noises, not sensory applications...).
On the other hand, while larger systems have (arguably) been getting increasingly hostile to simple sense-and-control, it sure is nice to be able to spin up some huge, luxuriously wasteful interpreter and bang away in the high level language of your choice, complete with all sorts of fun network and persistent storage stuff...
What do you mean "if we find out"? This is an insurance company...
It is pretty much assured that it will scale better and cost less than all those effects for which the fundamental physics don't actually work, so we are off to an atypically promising start...
I don't have anything in particular against today's IIS, my point was just that commodification, outsourcing, and scale are arguably a danger to Microsoft(and anybody else who is trying to sell licenses for software that isn't leagues better than the OSS competition). If you are running a server, or a handful of servers, even fairly exorbitant license fees are small change compared to the value of being able to use whatever it is your available people have expertise in. However, as the number of nodes you are running increases, the cost per unit of having expensive experts keeps on falling, while the cost of licenses doesn't.
Microsoft's real threat is not so much that the customers currently using IIS will directly abandon them for apache or nginx; but that they will abandon running IIS internally for buying web services from somebody else, who is much less likely to be running IIS.
Quite true; but I suspect that anything running a VMware View client(if the VM is hosted remotely, this is what a system developed with VMware is going to be using) or something running a full x86 VM on top of vmkernel(if the VM is hosted locally, this would be the VMware tech most likely in use) is not going to qualify as "simple" for any terribly useful definition of the term, certainly no simpler than the more-or-less-normal-but-in-an-armored-case x86s that Diebold usually uses.
The one major advantage of this VM approach(that could also theoretically be implemented at the BIOS level, or with a suitable LOM card) will likely be that it will make nuking the OS running the ATM software much easier, which will make it cheaper to clean known-rootkitted systems, as well as economically feasible to preemptively nuke-and-pave with a known-good image, just in case the system has been compromised with a bug you can't detect at present.
I don't know of any premade options; but if you have one of the Model M's with removable keycaps, there are probably enough Model M enthusiasts around that you could CAD up and have printed in laser-sintered, bronze impregnated, stainless steel(not real stainless steel; but similar, and the copper in the bronze probably helps the antibacterial value. If you could get the quantity up, fully stainless steel parts punched out of sheetstock would probably be doable; but that wouldn't be a 'quantity 1' thing...)
Unless they fuck it up pretty horribly, IIS has an assured future as the embedded webserver for default installs of the various Microsoft products that have a web-facing component(ie. Foocorp installs exchange, exchange.foocorp.com/owa is going to be providing 'Outlook Web Access' via IIS... Ditto with Sharepoint and similar).
If Microsoft has plans for people to actively shell out a nontrivial amount of money just to run a commodity HTTP server, though, they'd better have something good in mind, especially now that so much commodity HTTP serving is done on an outsourced basis by 'cloud' types or CDNs, both of which generally care a great deal about per-node costs that scale linearly with volume(like software licenses, or low end admin flunkies); but care substantially less about fixed costs(like having a serious guru on staff to deal with the esoteric intricacies of whatever they are using).
The real trick(and the likely determinant of whether there is actually a problem or not) will be whether or not UV tolerant bugs that are otherwise competitive with their non-tolerant peers and the human immune system crop up.
There are some downright alarming extremophiles, that can shrug their teeny bacterial shoulders at gamma radiation, hard vacuums, heat, dessication, and sometimes several of the above at the same time; but those tend to be virtually irrelevant to human health because so much of their biology is geared toward surviving extreme conditions. Under normal conditions, it's the swarms of relative weaklings that carry the day and probably kill you.(the same thing crops up with antibiotic resistance: most of the time, antibiotic resistant bugs are uncompetitive against their nonresistant except in antibiotic laced environments, which has led to interest in various dosing strategies designed to exploit nonresistant bugs to outcompete resistant bugs and then chemically kill the now-vulnerable remaining population.)
If the keyboard merely becomes host to a swarm of bacterial curiosities with neat DNA repair mechanisms, it'll probably be a fun project for some bio researcher to investigate; but it won't be a major threat to human health. If we get unlucky, and some exciting pathogen hits upon a cheap way to resist UV, we could have a problem... We could also have a problem, regardless of bacterial evolution, if people start treating the keyboards as some sort of magic bullet: Normal keyboard + paranoid hand washing may well be better than special antibacterial keyboard + 'eh, the keyboard is antibacterially magical, no problem' hand washi8ng...
This is the division of Diebold that handles stuff we care about, not the division(now "Premier election systems") that handles ceremonial functions.
If our priorities can be inferred from how much effort we put into them, they are as follows:
xbox360/PS3 savegames, then money, then votes.
Ah, but it's hitting a thumbtack with a sledgehammer that you can charge monthly hosting fees for, and disable immediately if the customer doesn't pay up.
The "Provide product, receive money, repeat." business model is, like, totally retro, man. Why do that played-out stuff when you can make the customer pay for the box and build in technological measures to yank the firmware if they ever stop paying, then call it a security feature?
All the cool kids are building in network-dependent 'security' features into their products so that they can get all the benefits of having the customer on the end of a rent-to-never-actually-own agreement; but structure the initial transaction with all the legal flourishes of a genuine sale...
Luckily, some fancy VM setup definitely prevents customer data from passing through the local PIN pad and/or touchscreen controller hardware. Thankfully, hardware keyloggers suddenly give up in defeat if they are asked to log keystrokes going to a super-secure remote VM...
Do not worry. All violations of the law deemed convenient to the national economic interest, or carried out by suitably favored people, will simply be ignored for the sake of practical efficiency.
Next time unlucky activist visits foreign NGO website? Visit from secret police...
I imagine that the sophisticated espionage types who want to abscond with your rocket-building expertise(for competitive purposes, or because you aren't selling toys to their nation state of choice) probably aren't stopped by fences and dogs. If they are really serious, you've already hired them and they just walk in the front door every morning. If that is your concern, the prison-camp props probably aren't a huge deal.
I am somewhat surprised, though, that they haven't had a greater incentive to repair the fence and put together something resembling a night watch for reasons of simple theft. Rocket surgery presumably involves some expensive tools, and big piles of parts and stock in various rather pricey metals and alloys. If your security is so fantastic that bored bloggers are wandering in, I'm amazed that the whole operation hasn't been melted down at the nearest scrapyard of loose morals...