Q: What would a language need to have to be able to replace English?
A: English. It would have to have English.
Q: What would a language need to have to be able to replace English?
A: English. It would have to have English.
Get yourself a PCMCIA Compact flash adapter. You can copy your data to the compact flash drive. (requires drivers, so this may fail for you)
You can also get a PCMCIA network card. Probably only 10mbit, but still more than enough. You have Windows 3.11, which was Windows For Workgroups. If TCP/IP wasn't installed on that version, you can download and install WinSock, an early TCP/IP socket stack for Windows. (requires drivers, so this may fail for you)
You can do link between two computers and transfer over serial... but this requires the right software and the right drivers, so this may be out of the question for you.
Emergency Boot Floppy:
Use an emergency boot floppy and boot linux off of the network with a pcmcia network card. You can then mount the filesystem Read-only and copy over the network. (requires linux server, linux skills or someone who can do this for you)
Extract the hard drive directly: (best option)
Yank the hard drive. See what kind it is. Get the appropriate laptop drive adapter cable and relevant USB adapter. Plug that into a newer computer and transfer off the files.
Of the options, the hard disk pull and copy option is really the best way to go, bar none. The only thing you would need to buy would be the right USB-to-laptop hard drive adapter. You can find them on amazon/ebay/etc. If you live near Sunnyvale, California, you can even stop by Weird Stuff and they might have it for a song.
Military or civilian, the individual would still be evaluated based on skill and culture fit. Period.
If the candidate shows good problem solving skills, aptitude, and knowledge/experience as well as a personality which shows positive signs of communication, teamwork, accepting criticism as well as being able think independently, then they make good candidates.
Many of the traits listed above (1-5) are good traits to have. No argument there. But fitness for one organization does not imply fitness for another organization. Sometimes, it's just not a "good fit", to borrow some recruitment parlance.
I've had the pleasure of working with veterans both motivated and unmotivated. At the end of the day, the individual decides how they want to proceed in their life.
Having said that, would be good to see more veterans with the skills to apply for Ops positions(Site Reliability Engineers/Development Ops/Systems Ops/etc). There is a mission. And that mission is Up Time. 24x7x365
Seriously, if your recommendation was to go with a product with paid support and your CIO is opting to go the other way, then get it in writing detailing the exchange. Nothing wrong with Centos. Nothing at all. Great platform and great support. However, there are products out there, or drivers for said products, which will ONLY work on a RHEL box because of RPM package dependencies or library linking to libraries of different names/etc. When that time comes up and it results in downtime, you don't want your manager or worse yet, the same CIO riding you for an answer as to why it is taking you so long to get a "standard" RPM installed to get things working again.
I've used RHEL, CENTOS, Oracle's EL, and Ubuntu... and there is ALWAYS something that needs a driver or a package installation that breaks because it didn't support the distro/flavor/version you have installed. Alien and other tools can only do so much... you don't want to be pulling your hair out at 2am in the morning... or worse yet, at 2pm in the afternoon, during a deployment/conference/expo/etc.
the problem is that it isn't facts that the company is limiting its storing to, but postings by people on web and other social media sites.
There is also the problem of:
- dataset poisoning
- information taken out of context
- guilt through association
- account hacking
There also appears to be no way for someone to clarify or otherwise refute incorrect data.
They are opening themselves up to defamation lawsuits.
+1 Thank you. A positive use for military grade technology.
Also noted on FB wall is the potential to replace the RAMDISKS with:
- external HD or flash drive to allow for powerdown, data retained, so long as the KEY drive, which also contains slices of the RAID 0 data, is intact. Lose/destroy it and the whole of the data is inacessible.
- internal PCI/PCIe battery backed RAMDISK. (you have X minutes or X hours between power cycles before keys and data slices are lost and access to the whole is lost)
In all cases, the goal is to protect against unwanted access of the data in question, or to render the data effectively inaccessible for a long enough time.
This can already be done with currently available open source technology and a little scripting.
One can even make the system switch between modes of operation by migrating volumes to/from an external drive unit and the ramdisks.
I commented a bit about it on my FB wall: http://www.facebook.com/wingedpower
But here's a quick synopsis:
Given a hard drive...
- Create X number of zero'd files to be mounted on loopback (losetup) and then to be encrypted individually(cryptsetup) using 256bit encryption(different key per loopback) [this is done on the data hard drive)
- Create Y number of zero'd ramdisk devices to be cryptsetup'd using 256bit encrption(cryptsetup).
- Create a striped array(LVM tools) using both the encrypted loopbacks and the encrypted ramdisks.
- Use cryptsetup to encrypt this resulting LVM volume and mount it as your "quick wipe drive"
- Store all luks keys, if need be, in a ramdisk.
When you power off, what happens is:
- luks keys go away with loss of power(barring UPS, memory freeze, etc)
- ramdisk slices of the RAID-0 striped array vanish... and take their encrypted bits with them.
- what survives on the physical drive are encrypted volumes containing parts and slices of a larger encrypted volume with slices missing.
Cost to implement: normal cost of equipment.
Special equipment or specialty hard drives required: none.
Security: 256bit encryption via cryptsetup at two levels AND some of the data goes missing.
- xerox/copy machine storage... they can actually implement this with standard drives... just update software and repartition their drive!
- protection against identity theft when home computer stolen... pulled power cable... oops. all data now not accessible.
- protection from illegal seizure of computers (no key to give... it is inaccessible)
- protection against foreign government raids(and local government raids, I suppose) (power loss=data not accessible)
The cool factor is... the slices you divide up the drive into... the more unique keys that will need to be found/brute-forced/decrypted before any amount of useful data is regained. And once they do have all the individual files decrypted, only then will they discover that there are pieces of the RAID0 missing... and the RAID0 itself is encrypted.
Most definitely not serious, hen e the tongue-in-cheek comment. But it's fairly strAight forward to build a diy version of the acoustics based LRAD.
Hypothetically, the key component is generating the right signal waveform to produce the intended effect.
Sound can be constrained to with. The premises with proper acoustic design. The db range would range from 90db to 120db...
If the walls are properly deafened and the windows or drop bars or locks effect a seal, then you would be able to contain the sound, thus targeting the intruders and not annoying the neighbors.
This is even more true if your valuables are kept I an inner room of the house, which can be better sealed off. One could rig sensors so that when intruders are I. Different rooms, those rooms can self-seal, thus restraining and keeping intruders apart from one another.
All hypothetical, of course...
Here's the question: Do you want to just record a nice video of your stuff being stolen or do you want to stop the theft from happening?
Security isn't just cameras and sensors. It's also physically locking stuff down, securing things so that people can't just pick them up and walk off with them.
I like the idea of an active defense system that will help prevent theft, but let's face it... that won't fly in any court of law. Still.. you can use non-lethal means.
First off, get a real security company to come do an audit and have them set something up. Get plenty of those security stickers and flags. Yes, put them up.
Second, consider nailing or "earthquake proofing" things with tie downs and bolts. You can't move a big screen quickly if it's been bolted to the wall/table/etc.
Third, get a good strong safe, make sure it's bolted down or otherwise secured in place. This is where your valuables should ideally go.
Fourth, get sound based pain field generators and tie that to your DIY sensors and such. Ie, if windows open or glass broken, pain field blast. If a sensor or trip occurs in key areas... like a drawer, or the safe is jostled... pain field generator. For the sadistic, I suppose you can install drop gates on all windows and doors to prevent the thieves from leaving... but that might be construed as torture.
Tongue-in-cheek aside, most security kits are for ID'ing the perps... so get high resolution and plenty of storage. What's the point of a camera that doesn't record footage good enough? Also, place cameras in multiple angles. From high up, from down low, anywhere/place where it will increase the chance of getting a shot of their faces. Also, have cameras outside as well. Make sure the cameras can adjust to different light levels as well as have IR illumination to ensure proper viewing. Install dummy ones and hidden real ones...
Oh. If you've got stuff you want to keep safe... home insurance policy. Keep a copy in the bank's safety deposit box, along with copies of receipts and such for stuff you have on the plan...
Reading the original post, the first question that came to mind was: why is the hardware configuration not being controlled!?
In another life managing labs, configuration control of the hardware was step #1 towards sane management of any group of computer systems. In the current life of managing thousands of servers, this remains the case, regardless of the OS.
The ONLY reason why folks have a hodge podge of hardware is because someone is trying to be cheap and "save money", nevermind the countless hours spent addressing issues that arose due to bad decisions and/or lack of planning at the start.
Suggestion #1: Review your current hardware/driver issues. Remove or replace components that are having hardware issues. Your lab shouldn't be changing hardware left and right on you. If it is, that's another problem. Once you've moved all of the systems to a nice overlap of compatibility, restrict all further future purchases to hardware that is well supported by all OS(s) in your employ.
The second issue that I'm seeing, which needs more information: what is your intended support list of applications?
Most workstation labs have a list of supported apps. Anything not on that list is "you're on your own". You can't please everyone. That was the case when we didn't have literally hundreds of thousands of potential component matchups. It most certainly isn't the case now. Obviously, if you can reduce your list of operating systems down to just one, you will be in a happier place.
Now, regarding the issue of destkop virtualization, as you've described: you are SOL. ALL desktop virtualization effectively requires the host OS to be running a GUI and the guest OS to be routing their "display" through the virtualization technology through to the host OS's GUI.
If you have to go with virtualization: VirtualBox. You can use either Windows or Linux as the Host OS. Supports both as the Guest OS. It is free. Runs fairly well. Allows reasonably good USB passthrough.
If you don't mind rebooting to change OS(s), another option you can have is to image all the workstations as dual-boot workstations. People can just reboot into the OS of their choice. You get max performance. Regarding drivers, I'm not sure I see the problem. Keep a master image updated on your central server, with all drivers. Each night, auto-reimage your boxes, so they start the day out fresh. I mean... this is a computer lab. Re-imaging each box EVERY night is just good common sense.
Final solution I would offer: Net boot your workstations from a central server. This has the advantage of having each user's intiial experience be on a clean/safe system of their OS choice. Since the image being run is from a centralized server, you only need to keep drivers up to date on one host(master).
Anyways, there are many ways to solve the problems you've listed. The best is to attack the root of your problems; standardize the hardware configuration and prevent future configuration drift.
You don't need to be a psychopath to do something that is immoral if you are convinced it is moral or right.
Ie, if the helmet demonstrated an ability to reduce PTSD and anxiety/conflict on the battle field, it would be morally responsible to do so, as it would represent an improvement in military morale as well as better post-military life transition.
The fact that it also impacts one's moral judgement might be good/bad depending on how one sees the situation. Ie, are soldiers' conflicted emotions causing a delay in reaction time? Is this resulting in more lives lost? If the helmet were to reduce reaction times and also reduce loss of life, then the use of said helmet would be moral.
It all depends on the perspective....
An additional thought: if you don't already have a computer forensics/penetration testing rotation in your policies, now would be a good time to get the funding for one done.
or in your case, some additional work. Sounds like you guys already have put in alot of effort.
So, look at the two boxes that are compromised and determine what technical and social aspects failed in your overall policies and runbooks.
Was it a new exploit that you couldn't have blocked? Was someone infected at home, and brought the infection to work? Was it a case of mobile device infecting desktop systems? Etc.
The only 100% system that cannot be infected is one that is completely powered off and cutoff from human and non-human contact. So, there will always be some risk with networked devices being actively used.
Realizing that switching OS(s) might not be feasible, other folks' suggestions for state locking desktop computers is a good idea.
Another possibility is to virtualize your desktops with something like VMware's VDI(Virtual desktop infrastructure) or Citrix's virtual desktop offerings. You can restrict the activity of the port on the physical machine the user is using. This also has the added benefit of virtual machine snapshots automatically occuring at regular intervals and/or mass upgrade/backup of company data that normally resides on the physical desktop machine.
However, even those solutions can fail. So, it's a calculated risk.
In the end, the fact that you only had 2 machines compromised and it did not spread like wlidfire, is a good sign that you have good controls in place. Just reassess your controls and make the necessary adjustments to close the loophole or lapse in judgement that occured.
It's alot like an ongoing war. No matter how well equip'd your army and no matter how numerous your defenses, you will suffer casualties, eventually.
Several years ago, went down this road. Did the research, setup a test box, went through the upgrade-now-its-broken-my-wife-wondering-why-her-shows-(not recorded/not playing/plays badly/hard to program/etc).
In the end, I decided that the tv's end point was an "appliance". Ie, like the toaster, microwave, etc... It should just work.
To that end, I went with Tivo. Then TivoS2, and now, TivoHD.
It records shows, can schedule, between the two, I an record 4 shows concurrently in sd/hd. I can xfer the content to my pc fileserver wherebit can be restreamed to the tivo ala the various streaming client/server apps. I can strea netflix to both boxes.
Could I have built and maintained a mythtv/freevo/etc box? Sure. But in my case, it made more sense to go the appliance route and focus on what mattered: content.
Hold on to the root.