1.0.5.48_1.1.79 is vulnerable. As I had one laying around, plugged it in and it would execute code when I shot it the url.

Updated to V1.0.7.2_1.1.93 also vulnerable.

http://router-address/cgi-bin/...'

Kills the httpd demon and doesn't allow remote execution (or web management) until rebooted, where router-adress is the netgear. That is work around enough.

" ...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.' But the plans were on display...' o n display? I eventually had to go down to the cellar to find them.' `That's the display department.' `With a torch.' `Ah, well the lights had probably gone.' `So had the stairs.' `But look you found the notice didn't you?' `Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".' -- Douglas Adams.

It's about the same to turn off the ads. Or will be soon. You get what you pay for.

I've enjoyed Steve Jackson Games for years. I have Zombie Dice, Illuminati and Munchkin and have enjoyed Ogre and Car Wars in table top and computer form. I've played GURPS as well. That is a diverse bunch of games from one company.

What is your game design process like?

What elements do computer game design and tabletop design have in common?

Do people still write applets? I thought they were actually dead. Any motion is the decomposition taking place.

Java is a server language of choice for a lot of developers, and if not Java the language, then at least a JVM language (Scala, Groovy, Jython, etc).

Windows 2012 Server boots first, then after a bootstrap the Windows 2012 O/S migrates out of Ring-0; so it eventually ends up as a Type-1 but it doesn't boot as a Type-1. (The same is true of Xen, for example; it boots as pure Linux and then Xen takes over Ring-0)

ESXi is literally a bare metal and boots directly into the hypervisor.

Workstation and Fusion, once spawned, are hosted applications, but still have direct hardware access to hardware if you're on a box with hardware-assisted virtualization instructions (ie, intel vt-x).

So the idea of Type-1/Type-2 is sort of dated anyhow as a division.

... "my MacBook Pro has 9 VMs on it right now, 3 of which are powered on, and I build clouds for a living" choice? ;)

or even ... "Are you kidding? My VMs have VMs in them."

Pricing can be based on utility, rather than cost; see http://en.wikipedia.org/wiki/Utility. I completely agree with you in principle, but I've found I am now just buying ebooks, even when I could get a paper copy for less, because:

- I get it instantly
- I tote my entire library around on a device that weighs 11 ounces
- I can read on multiple devices and it syncs my position automatically

And I recently gave >1000 books to the library when moving, so I know that despite my fears that Kindle as a platform might die, I'm not necessarily keeping all my books forever. (Although since my daughter is 11 and I'm now giving her books I bought when I was a kid... there is definitely some merit to it. If anything, this is the one thing that keeps me occasionally buying paper books; the loaning and hand-me-down factor.)

I'll be honest - I hate myself a little for capitulating, because on principle I completely agree with you. But I also drop $6 on triple lattes frequently and I just feel too busy to feel any rage over a few bucks here or there. I applaud everyone who goes for the cheaper option even if they'd prefer the e-book at that price.

The equivalent crap happens in movies as you point out. HD movies on iTunes being $15 instead of $10, or $20 instead of $15, say, seems fairly absurd, since the difference is perhaps $.02 of bandwidth. TV shows even more crazy, being $3 instead of $2.

The reality is, publishing is a completely shitty business. Macmillan's parent company (a publishing conglomerate) made a whopping 6.7% on 2.1B Euros in 2005 (BEFORE taxes). (2010 they were up to 2.25B euros)

That's not exactly rolling in the dough.

I've seen actual agile, and I've seen stuff called "agile", which means, "we don't plan, but we do standups". "We're using agile" is a codeword sometimes for "we don't like or even understand SDLC, so we'll use no process and call that lack of process agile."

There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.

Not even remotely describing agile. Her "has 17 years of web development experience" jibes with my experience in a 5-man web shop where the term agile was literally a euphemism for "no process", and there was a COO asking for 6-month gantt charts despite the "agile" label; vs a stint at a top-3 software company where we had agile tools (ie, Rally), everyone got trained on it on our team, we had a very defined process (including using gitflow for branching and a review process pre-merge), and a full-time scrummaster.

I don't even think this is really giving agile a bad name, because I think anyone who has experienced both (or, say, just real agile) could tell the difference easily.

So, I co-wrote this book on virtual security and am a former VMware Cloud Solutions Architect. And I'll preface this advice by saying that, if you want to talk more in depth, feel free to ping me. First initial, last name at gmail will work. (The email I have attached to slashdot I glance at occasionally, but it gets almost purely spam and so I'd likely miss anything.)

From my perspective, the first question is which hypervisor to use:
- VMware is mature, you can get a free license for the base hypervisor (which is quite feature rich; this is no trial product) for up to 32GB per physical box, is widely used. If VMware remains as relevant in the future as it is now, it's actually a very solid skillset to have.
- If you have physical hosts over 32GB, VMware ceases to be free
- Some features require more advanced VMware stuff, including vCenter server, which isn't free - for example, VMware's live vm migration feature (vMotion)
- VMware is almost entirely closed on the internals; hypervisor is closed source (other than a not-useful-for-your-purposes "open source" bundle that contains their modified GPL code only); they have a bunch of APIs for internal functions (ie, tracking changed blocks on the virtual iscsi devices, for example), but those are generally restricted to partners; so if your students want to actually hack the virtualization layer, they can't. Then again, letting them do so wouldn't really be safe.
- On the other hand, VMware layers do have nice APIs that are reasonably accessible for doing non-internals stuff; things like powering VMs on and off, changing their allocated RAM and cpus, etc
- VMware has a nice set of tools, including CLI tools, which work well even with the free versions, that can allow you to move virtual machines in and out of specific hypervisors (not while the VMs are powered on), and into and out of VMware's desktop products (Workstation for Windows and Linux, Fusion for Mac). (google ovftool for the cross-platform CLI tool, for example; it can import/export to/from ESX, vCenter Server, Workstation, Fusion, and vCloud instances)
- VMware has a nice set of tools for snapshots and backups, even on the base hypervisor; for example, I have a personal ESX box at a provider and I use this tool to back up the VMs back and forth, which can be done from outside the OS without powering the VM down, and it's free.
- I found using some things I'd think of as mandatory for a lab environment (ie, thin provisioning) were just built-in on the VMware side and required a fair bit of extra work and added extra wrinkles

The virtual networking on VMware is dramatically more mature from my experience; my experience with Xen & KVM is now dated (it's been 2 years since I was in the thick of writing that book, which was the last time I was really in the thick of exploring the open-source hypervisor networking bits). I found that depending on the version of the hypervisor OS, which hypervisor, which kernel, which guest, etc, you could fall into all sorts of traps. I had some examples in the book where I showed, for example, generating and applying ebtables configurations to the host OS (the Xen Linux hypervisor OS) to block forged frames from coming across the bridge from one of the guest Linuxes, for example.

Compare that to the VMware side, you could in theory wire up everything to dumb hubs, even, and enforce network separation at the hypervisor layer with VLAN tags applied to the portgroups where you attach VMs. (Warning: not suggesting you blindly do that; but VLAN enforcement on the VMware side is fairly rigid if configured in a good way.)

My own book is a fun read for some of these concerns, although Haletky's book is probably the canonical work on the subject. (Although it is -slightly- dated from being a bit old, it is still a wealth of great information, and it was a huge help to me as a primer when I first joined VMware.)

Depending on how far you want to deep dive, my second choice might be Xen+Eucalyptus; if you could front-end your hypervisors with Eucalyptus and build an internal cloud, you'd also get your students one foot on the road to playing devops with AWS. (There are plenty of VMware clouds out there, but I don't know of any offhand that have the equivalent of the AWS micro tier, which would let students even occasionally deploy their boxes to the net.)

One final consideration is that VMware actually gracefully does nested virtualization; you can run ESX inside ESX, and you can run Xen inside of ESX, and they generally function well. The Xen FAQ implies Xen supports it, but I'm unsure if Xen can nest VMware or KVM for variety; I can say from experience that I had VMware, with Xen inside it, with a guest OS inside that, all on my laptop just fine.

Good luck! This is super-fun. I will say: don't overlook the value of the actual virtualization layer experience! It is currently far harder to find solid virtualization & cloud engineers than it is to find a Linux admin. The rise of virtual appliances and infrastructure as an extension of code makes me feel like the devops & virtualization skillsets will remain in strong demand, and operating systems may be simply seen as containers for applications.

VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.

As you pointed out below, VLANs in general are trustworthy when properly configured with a proper switch. I did nothing but netsec work in the late 90s, and everything was airgapped; we'd never have frames from two networks on the same wire. If you wanted to cross security zones, it was at L3 on a firewall and to different wires and switches.

On the other hand, it seemed like back then a new practical way to defeat VLANs was coming out every other week, so this was a wise precaution.

That said, keep in mind that VMware also affords some additional security in terms of VLANs. Physical switches have to connect to virtual switches to interact with the VMware layers (either the hypervisor for control traffic, or with the VMs for VM traffic), and the hypervisor itself will enforce a lot of things. On a VMware vSwitch properly configured:

- VMs can't enter promiscuous mode, change their MAC address, or forge transmits with the wrong L2 address
- QinQ frames are discarded
- The hypervisor itself will determine which virtual nics on a vswitch should receive copies of a frame, depending on which VLAN tag is on a portgroup
- Guests can't send tagged frames if their portgroup is set with a VLAN; you have to specifically configure a trunk on a portgroup to pass VLAN tags in and out of the guest environment

If the network was homogeneously ESX nodes and administratively controlled network equipment, you could likely enforce security between VMs with VLANs even with a dumb hub.

Obviously, airgapping and single-role wires will create better security than VLANs, because there always remains a chance that an undiscovered bug will allow breaching that L2 barrier, but that's true for everything.

Realistically, I view an ability to bring in highly skilled workers as a huge boon for us. Tax revenues, technological innovation, business agility - etc. People who are really driving technology and innovation create way more value than they capture and they become the rising tide that lift all boats.

But how can you identify them? We all know companies that want to import workers for less skilled jobs carefully tailor the job descriptions to avoid any domestic competition, don't publicize the jobs widely, etc.

Salary is the answer. We should prioritize H1-B visa imports by salary. The more you are paying the worker you import, the higher on the list they get to be. Any increase in the cap requires a certain number of workers at the top of the salary curve; if your salary would put you in the top 1% of workers in any science or technology field, then come on in; I don't care how high the "cap" goes. As you move toward the middle of the bell curve, the total number of workers we'll import declines. We shouldn't import even one worker below the median salary. I don't think we should move an inch over the current cap unless everyone over the cap is at least in the top 20%.