Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Been there, done that. (Score 4, Insightful) 376

I developed a very serious mobile app back way in the mid-90s for public health and disease surveillance. Let me tell you from experience why an app that people rely upon every day for critical work is no way to strike it rich. People *need* a lot of support for that kind of app. Support equals labor, and labor is expensive. Businesses with high expenses don't get rich unless they can command huge prices.

When smartphones came along, my partner used to gnash his teeth at stories of developers scoring windfalls with ringtones or stupid little games, and here we were doing *important* work and only making an OK living. I pointed out that if somebody pays $1.99 for something to amuse himself, he's never going to call tech support. When something represents a total investment of fifty to a hundred thousand dollars in hardware, software and system integration services, he damn well is going to call tech support. But 50K isn't really that much money if you include hardware, third party software licenses, QC'ing the client's existing data and converting it, training the administrators and end uses, and negotiating with IT gatekeepers. That's what you have to face when you do work that everyone agrees is important. Yes, people are willing to spend real money on important problems, but they also subject you to higher standards, intense scrutiny, and exacting ongoing demands, and those things eat into your profits. And the only way to get rich in business is to generate profits -- and salary you pay yourself for your labor IS AN EXPENSE.

That's why the $1.99 app somebody buys on a whim to amuse himself is bound to be more profitable than *important* software that somebody relies on to do something important -- no matter how much you charge for that software. There are exceptions to this rule, of course. Software that is a cheaper, more convenient alternative to something someone already has (e.g. Skype) is practical because what it does may be important, but that software itself is at first dispensable.

Look at the vast amounts of cash going into develop "social media"; it is no accident that most of it goes to support is so trivia. Trivia is profitable. It's easier to try radical new things in the trivial. A lot more people have an early adopter stance towards a service like Facebook than they do to towards things they regard as critical. They take convincing and hand-holding. That's why something like Google Wave couldn't get off the ground, you have to approach something as important as collaboration much more conservatively, usually working around how people already do things (e.g. Sharepoint).

Comment Re:Why the IC in ICBM? (Score 1) 351

umm... because China is fairly big and the larger cities are pretty far away from where these ICBMs will be launched?

umm...hopefully that's "would be launched," not "will be launched." I'm no fan of the chinese political establishment, but in many ways (culturally, work-ethic wise, secular society, desire for stability) we and China should be natural allies, if they could just get past their control-freak authoritarianism and we could get past our emperial belligerence.

Comment Re:MLB has much bigger problems (Score 1) 276

And if chess players were allowed to hit each other with sticks, it'd be a lot more interesting for the average viewer.

I actually think the larger ball idea is interesting, but the real problem is that Americans don't have the attention span they used to. If you've ever tried to explain baseball to someone in a country where it isn't played, you'll know it takes a great deal of information just to follow basic game play. Worse, baseball is a game of evolving situations; it takes a database of dozens, if not hundreds of games watched to really understand what's going on. So tweaks like the larger ball are likely to do little for the casual fan and nothing for the dedicated fan.

The Italian Baseball League has an interesting solution. They reduce the length of the game to seven innings (nine is often too long for non-fanatics) and if there is a tie the winner is decided by a home run derby -- kind of the way soccer tournament advancement is done by a penalty shoot-out in a tie game.

Comment Re:What kind of encryption did the FBI break? (Score 1) 802

Regardless of the circumstances, ordering someone to decrypt a hard drive should be against the 5th amendment. I look at this the same way as any other "evidence is in a very hard place to get" situation.

I don't agree. Ordering someone to decrypt a hard drive is more akin to ordering someone to "We have a warrent! Open up, in the name of the law!", which, if you don't do so, you will find your front door in splinters and yourself on your stomach with cuffs behind your back.

Your example of onerous burden is also misapplied. If you dump a body in a 1000' well, it may not be physically possible for you to retrieve it (though you should be billed for the cost if you're convicted of dumping it there). Regardless, it is not an onerous task to type in a password (the consequences of your conviction may be onerous, but the act of typing in the password is easy and not physically demanding), so the comparison you offer does not apply.

Being required to open your front door and allow your house to be searched, provided a warrant is served, is not a violation of your 5th amendment rights, and neither is being required to decrypt your drive.

Comment Re:BYOD means I/T loses some control over it (Score 1) 377

Honestly the one thing that screams that the management is a bunch of Douschebags is a BYOD policy.

That depends on the BYOD policy. I work for a company that gives you a choice: company iPhone, or BYOD and they give you a stipend that covers the majority of the cost of most cell phone plans. It's a pretty good deal whichever way you roll.

But then, my employer isn't trying to get people to buy their own laptops or workstations. Any employer doing that is a real douchegab.

Comment Re:Recruiter Commision (Score 5, Insightful) 189

Yep certainly had the Agencies cut taken off my agreed salary for three months before (I did complain). No mention of what Language/ALM they work with. Given that I know hundreds of Devs (Some of whom already live in commuting distance) it would be nice to know what skills they are looking for.

huh!?!

I've worked with recruiters for years, in Chicago, New York, and London to name just three places. I've never, ever, had my pay docked because of the recruiter's fee. Never. And every job I've had beyond the first out of college has been through a recruiter (and they've all been excellent jobs, on both sides of the pond).

The employer should always pay the recruiter's fee. You as an employee/candidate should never see the fee, probably won't know what the fee was, and shouldn't necessarily even be aware of the fee (other than in the most hypothetical sense).

Having your salary docked for three months...that's just crazy. The only instance I know of where that's the norm is with talent agents in the media...a journalist I know at a New York radio station pays n% of his salary to his talent agent, but that's an entirely different can of worms. In technical recruiting, that should never happen. If your employer docked you, I'd say your employer is more than a little suspect and I'd get your CV/resume out. If your recruiter is collecting from you, then you've been suckered into the wrong kind of recruiter.

Comment A bit of cloud security author advice (Score 2) 212

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.

Comment Re:Set up VLANs (Score 3, Interesting) 212

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.

Slashdot Top Deals

The value of a program is proportional to the weight of its output.

Working...