Whilst I sympathise, you're being rather melodramatic.
People survive perfectly well on one kidney.
Yeah, what a fucking consolation for someone who's having a loved one one hair away from death from a botched operation, you stupid animal.
And if the US adopted a socialised healthcare service, you wouldn't have had to pay a thing.
How long were you waiting for an opportunity to state that opinion? And you have to do it like that, in response to someone's post stating a real-life-and-death situation? What a fucking classless moron.
The Russians manage to save money, launch a lot of missions, AND they still have a safety record that dwarfs NASA's. Maybe we should ask them how to do it.
They have a safety record that dwarfs NASA? Pray tell what statistics are you using? I think there is a high probability you don't know what you are talking about.
So, basically, bend over and take it for 15 years until you can move to some other employer. Awesome.
Well, if accumulating 15 years of work experiences means "bending over and taking it" for you, then... welcome to human life.
Whether you work 1 year or 15 years, whether as a employee or consultant or business owner, whether coding the ultimate
compiler or flipping burger, you bend over and take it in from someone, one way or another.
It's called earning your bread with the sweat of your brow. Also, there is nothing wrong in accumulating
x years of experience in preparation for a career move into another company if there is the potential of
greater benefits. It's called having foresight, career improvement.
In case you thought you made a snarky, illuminating comment. Newsflash: You didn't.
My advice would depend on whether you are still at school or not
If you are going to break into a megacorp, do it after you get your masters. A masters
doesn't necessarily mean you are a better programmer than one who only has a B.S. or even
a A.S. degree (I've seen M.S. grads who can't code their ways out of a for loop.).
But it does help in establishing a career path into software leads, principal engineers or
software/system architects. Of course, the onus is on you for being able to delivering the
goods as well as being able to roll your sleeves and code and make things happen.
Also, when in universities, get a job at their labs or do research, or do interships. That
is, accumulate work hours.
Now, if you are already out of school and not working on a mega-corp, then go back
to school and finish a MS. Then apply. If you are good, you should be a hot catch (experience
and post-grad education.)
That's my opinion now that I look back at my professional experience (having worked both
in small and big corps.) They way I see it, if you want to work on a mega-corp, do it with
the purpose of establishing a career path as a team lead or principal engineer. If it's just
for the love of coding, I would stay with small companies (or work as a consultant and milk
the OT.)
Take that with a grain of salt. My opinion is extremelly personal and after ruminating about
what I like and I don't like about software work on small and big corps.
It often works the other way, too. I can't remember how many interviews I've given for programming jobs where the interviewee comes in all cocksure and arrogant. Not to single them out, but I've found those trained in India to be the worst.
They tell me about their training at some foreign university or college I've never heard of, about all of the certification they've received from Sun and Oracle and Microsoft, and all of these programming contests that they've participated in. Then I ask them to describe how a linked list works, and they tell me some shit like, "Java doesn't support linked lists, only arrays."
Then I thank them for their time, and tell them to leave.
If there is any comfort, you are not the only one who have witnessed that type of shit. The funny thing about software geeks is that we tend to only look at corporate arrogance (whether real or perceived), but we never look at the arrogance we many times distill. Sometimes, what we see as arrogance in others just happen to be the reflectionof a big fucking chip in our shoulders.
As for arrogance in interviewers (and this is not intended to any poster in particular), it's human nature. I've been on the receiving end of
interviewers more interested in showing me what they know or how little I know compared to
them (little-dick-compensation syndrome) as opposed to actually interview me and gauge whether my skills
can be incorporated as assets to the company.
An interviewer's job is to do just that: match an applicant's skills and personality against
the requirements of a given position. When they go into little-dick-compensation syndrome,
they are not doing their job and they might as well reimburse the company for the hours wasted
in the interview and possible loss of talent acquisition.
But that's part of life and part of the game. We just have to suck it up with some dignity.
Unless you are in a really dire situation and you are just short of taking a job flipping burgers,
just stop the interview if you feel (rightfully of course) if they are feeding you dick stew.
If it's tolerable, just go with it to the end, say thanks and move to the next interview.
If it's blatant dickery - "I'm sorry, but I don't feel the tone and objective of this interview is
to gauge my skills against the job requirements but to show me how little I know or to establish a
food chain order before even discussing if we are both interested in working together. I think
it will be best that *I* (never *we* but *I*) discontinue this interview. Thank you for your time
and I hope you find a suitable candidate."...
... then call their HR department and *your* headhunter and inform him/her of what just transpired
(if he/she happens to be a headhunter that you trust.)
This is all predicated in the fact that your assessment is objective and that you are not just
an ashole that gets easily insulted.
Not everything will be peaches and roses all the time, but if you conduct yourself professionally
and with integrity and with respect, good things will follow.
Better question - when an anti-abortionist blows up a an abortion clinic, what empire needs to be renounced? What empire lead to the Oklahoma bombing? When neo-nazis plan terrorist attacks in Europe, what empire needs to be renounced?
The Lord's Army in Uganda is a terrorist organization, so was the Shinning Path in Peru. What empire does Uganda or Peru need to renounce? When a Sunny terrorist blows up a Shiite mosque in Pakistan, what empire does the Shiite minority needs to renounce?
I could bring a large number of examples where terrorism has more to do with ideology, racism and religious fanaticism than with any notions of empire and its side effects. Just because the most notorious forms of terrorism (Islamic terrorism affecting the Western World) can be explained as a reaction of empire building, that does not mean the phenomenon of terrorism can be explained in those terms, much less solved from those premises.
The easiest way to answer a moral question without actually answering it is by pitching empty slogans. It sure feels great to say them (oh man, do you feel me? I do stand for something, so cliche... I mean avant garde!)...
... but they are a dime a dozen and don't amount to much anyway. A moral point based on a fallacious premise is an empty one, a fallacy and a slogan. Try harder. Try better.
</rant>
On another note, if the story is true, I do hope Montgomery and whoever up the intelligence food chain that was too stupid to paid him for his snake oil go burn in hell.
How are they auditing the code of the closed source apps they're using? If there are steps in place, use those as a minimum. If there aren't, then how's the blind faith of using those programs different than what's needed for open source?
Flipping the question does not answer the original one, which is a valid one and which deserves an answer. The answer is, just like anything, it depends. It depends on the open source artifacts in question; it depends on the specific audit/security requirements; it depends on how critical the app under development is; it depends on SLA agreements (if one exists and requires it.)
As you said, if there are steps in place, use those as a minimum, provided that they are sufficient for the requirements at hand.
If there aren't any, you can't just cross your arms and say "well, if I didn't do them with COTS, why would I with FOSS"? If there aren't, and your project requires them, then shit, you implement them.
The question of whether to sec audit something, be it COTS or FOSS is predicated by the requirements at hand, not on whether a previous usage of COTS (or FOSS) was properly audited in the past.
What we need is basic training in algorithmic thinking for the masses.
Nope. What we need is more analytical thinking and less multiple-choice exams. That is far more fundamental than training on algorithmic thinking. Take any random kid from HS and I'll bet he'll be more inclined to ask "what is the answer to this problem?" as opposed to "how do I work it out?". That is what needs to be fixed.
Steve Lohr writes in the NY Times that the country needs more 'cool' nerds — professionals with hybrid careers that combine computing with other fields like medicine, art, or journalism.
Bad idea (not unless we are talking about people who have a BS/BA degree in a technical field pursuing another BS/BA degree - or even a MS - in another technical field. Now, THAT'S A HYBRID CAREER. We already have a problem with watered down CompSci and MIS programs churning chumps who can't code for shit themselves out of a wet paper bag. CompSci, MIS, Software Development and IT, these are fields that call for people that are domain experts and specialist, not watered down hobbyists with superficial and inadequate training.
It is quite telling of our society that when facing with a shortage of scientific/engineering talent, the solution is to make it more "cool" as opposed to raising the scholastic expectations of kids. As if "cool" makes up for the grey matter required to be a (good) software developer. Either the author thinks software disciplines are shallow enough that they can be weaved in with a medicine, journalist or even an arts curriculum (an art curriculum takes quite a lot of work to get through.) Either that, or he thinks these other disciplines can be watered down so as to allow someone to be graduate in both (notice that I say "graduate", not "be sufficiently competent.")
How come you don't see that type of mentality in India, China or, say Eastern Europe? You want kids to be interested in hard sciences (not just software disciplines)? Then raise the bar and academic rigor starting from 2nd grade all the way to 12th, where the objective is to learn and not simply to pass. You don't solve an educational deficiency by painting "cool" all over it.
On another note, I stopped reading the article when I hit this:
Today, introductory courses in computer science are too often focused merely on teaching students to use software like word processing and spreadsheet programs, said Janice C. Cuny, a program director at the National Science Foundation.
Say fucking what? I know that Computer Science curriculum in most universities have been watered down into Java/C# schools, but give me a fucking break. Either the journalist is misquoting Cuny, or she actually said - and I quote - that introductory courses in computer science are too focused on software like word processing and spreadsheet programs. If it's the later, someone kicks her out of the NSF. There is no "science" in that kind of stupid remark.
I might regret saying this but the "which leads to the following" isn't entirely true. As a manager of staff, I do have responsibility and visibility across the whole project. But my staff don't.
I agree with that, but I also agree that each member of the staff is responsible for his own contribution to the team (and that contribution is directly proportional to the criticality or "cost-of-failure" of his contribution).
They don't have the time to each know every last detail about what everybody else is doing and how they are performing; that's my job -- they are trusting me to manage the project to a successful result. If Fred drops the ball, then sure enough I need to find a way to get it picked up.
We are in agreement.
But your last line isn't a very helpful way of approaching that. If you insist to Joe-down-the-corridor that "he should quit" / "is being dishonest" if he isn't happy about missing his son's birthday to pick up Fred's mess at the last minute "because that's what's needed to get the job done" -- that sounds like passing the buck on your responsibility for the project, and unless you are in a very high-paying environment (money covers many sins), it isn't helpful.
I do not insist on that. I insist in that people be professionals and work for the benefit of the employer who is writing a paycheck to them. Being professional does not mean missing your son b'day or dropping the ball on your family life. It simply means: be professional - don't chose your responsibilities or your opportunities for "stepping up to the plate" solely on who is to blame or who dropped the ball.
This is specially true when we work as salaried employees and not by-the-hour contractors (I've done both.) There is an understanding that at times people might need to stay beyond the regular 40 hours. And your kid's bday does not occur every day, nor every day is a family emergency.
No body is going question your professionalism when you have to take care of your family priorities, assuming you have a track record of doing your best to also meet your work priorities. The former goes hand in hand with the later.
However, what I see a lot is that team A drops the ball (or can't meet a deadline because someone on top screwed up the scheduling.) Team b needs to interface with the deliverables from team A by a certain date. But because of the reasons above, they can't. So team B has to work extra to either do a work around or take some work off team A.
Now the deadline must be met because if not, it will cost tens of thousands of dollars per hour and it puts the whole project in jeopardy. The jobs for team A and B are on the line, like pink-envelope time.
And yet team B decides not stick to their 9-to-5s because they didn't drop the ball. Team A or management or "they" (they=anybody but them) did. I'm going home, everything else be damned, stupid team A, stupid managers. Whether it rains or snows, out by 5 they go. Later they hate "they" when the project is canceled and they end up looking at dice.com every other hour.
Never mind they have much better salaries that other people with equal education in other fields. And never mind the benefits and the vacations. Project is about to fall and us be on the street serving fries? Who cares. We=good. They=evil. They=drop ball. We=go home by 5. Always. Every single day. For any single project. With each and every employer.
In almost every single freaking gig I've been I see this. It is true that it is human nature, but there is something about Software professionals that you see this more often (or perhaps more vitriolically visible), acting as if they are doing a favor to their employers for working with them (or as if the employer has an obligation to keep them hired no matter what just because they are pretty.)
/. needs to add a "+1, Fucking A" mod. You have it exactly right.
Playing the blame game is deadly to an organization. You end up spending more time trying to CYA than just fixing the problem.
Exaaactly brother. A lot of software prima donas like to cry foul about the "bizness" politics, how much they are above that, pretending to be 100% logical and objective and technology-driven, oblivious to their own pitiful CYA politics. Projection at its finest.
If the developers are staying late because the manager messed up, it doesn't hurt to stay late (but stay out of the way and order them food)
If the developers are staying late because they come in late or they messed up, no, the manager doesn't need to stay.
The reasons developers *must* stay late vary widely, depending on context, scheduling, external pressures (.ie. new requirements due to a merge that must be implemented immediately to avoid bleeding tens of $Ks/hour.) That is, they don't fit *at all* in that *he screwed up/they screwed up* dichotomy (which isn't even mutually exclusive to begin with.)
It is obvious that you do not have management/team lead experience. This is because, if I'm a manager and my guys screwed up and must stay late to fix it, I might need to stay with them to make sure they get it done. After all, the sign of a good manager is that he takes responsibility for the performance of the professionals under his watch, in particular if the thing to get done is critical, independently of who screws up.
Which leads to the following: the sign of a professional is that he does what needs to be done to get the job done and to conduct his job for the benefit of the business. BTW, if anyone has a problem with that statement, they should quit their jobs. It is dishonest to accept a check for a job function that is not being completed under that premise.
I might not be responsible for the screw up of someone else, but if called to step in, I would (if it is feasible for me to do so.) Within reason, professionals step up to the plate. Prima Donas and sensitive bitches with vaginal silicosis (who are a dime a dozen in the software world) do not, opting instead for trying to explain every single scheduling or work problem in terms of "who else other than me fucked up."
"Improved user experience" is marketingspeak for feature upgrade or bug fix. The parent got modded down, but if I had points, I'd put it right back up. Crippled software sets, suddenly enabled by market pressure, isn't an upgrade.
When apps are truly upgraded, so much the better, but this doesn't follow the computer industry model. And I wouldn't expect it from others.
What sort of computer industry model do you speak of? Certainly not what I've witnessed. Having a release ever 3 months or so is quite common in almost any industry I've been to. In fact, the better the software practices, the more that you see this in the form of predictable releases.
Even in companies that are still stuck in "waterfallish" models, but who have good software practices, you see that they schedule periodic releases.
In good and bad software shops, from waterfall to agile, real world computer industry models follow a pattern of constant software releases.
You say "Improved user experience" is marketingspeak for feature upgrade or bug fix.. I say NO FUCKING SHIT. You say it as if it were some sort of revelation. It is not. It is an oxymoron of collegiate sophomoric proportions.
If it is a feature upgrate, then it is (more often than not) improved user experience. If it is a bug fix, it is also (more often than not) improved user experience. Welcome to yesterday Cpt. Obvious.
Or what, do you think it is feasible to create non-trivial applications useful for more than a tiny tinie bunch of people in a cockamamie, irrelevant context without introducing bugs? No matter how good you are, you will introduce bugs in your software.
So as a professional, you will have no choice but to provide regular releases, to fix those bugs, to improve on a feature, or to adapt to a new request (which is a fact of software life.)
Or maybe I'm reading your post wrong (in the part about "improved user experience"). I do share your criticism on the android update model, though.
Indeed. You don't get insurgents without an occupying power*.
* For the semantic pedants: While technically insurgents could resist a domestic government, it's been the case in the 20th century and since that insurgent warfare is a response to invading forces.
Uh, really, explain to me which were the invading forces that triggered a response from the following which are perhaps best known and most representatives of 20th insurgency:
- UNITA insurgency during the Angolan Civil war) (Angola)
I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens.
Nope. The very purpose is to simplify code usage. I don't gain anything by saying o.setName("name") when I can semantically get the same by saying o.name = "name". It was one of the greatest things that came out of Delphi, and there is a reason why it is the default way to access bean properties in EL/JSTL (firmly a Java technology) as well as in Groovy.
Unless that verbosity gets me something (clarity, better semantics) it is just syntactic salt with no associated benefit and certainly with an associated cost. When you start working with a whole bunch of goddam POJOs, you'd wish you'd have properties. I used to be in that camp that worshiped verbosity for the sake of it. Fortunately, first hand work experience in its associated cost helped me grew out of it.
I don't gain anything in knowing whether o.name = "name" executes code or not. I want that name to be "set". Whether that "set" operation carries additional semantics beyond assignment (.ie. synchronization, reference count or what not), I don't need to know. I don't want to know. Just as I would not want to know the "hidden" internals of calling a method in an object.
In fact, YOU WANT TO HIDE THE CODE INVOCATION. In programming, you simplify out of a context the things that you don't need to know. If you have two constructs that, by design-by-contract, carry the same semantics, you opt for the less verbose one. Always.
And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
Prove to me that "good" exception handling absolutely requires checked exceptions, and then you might have an argument. In my experience, the worst exception handling mechanisms I've seen have been implemented with checked exceptions. No other language introduces them.
Now think about this. The folks implementing Groovy, Scala, C# as well as those that support and extend the C++ standard, these are all people experienced in programming language theory (not counting their industrial experience). And, by what they know, and by their industrial experience, they opt not to implement checked exceptions. Moreover, there are a lot of systems implemented in Java and otherwise that have excellent exception handling without checked exceptions. What should that tell you? Checked exceptions sounded good on paper, but it turned out not to be the case.
Exception handling (or design by contract for that matter) does not require checked exceptions. Sorry. Checked exceptions introduce code entanglement at various levels, and Java does not provide a way to abstract them out. The only way to really use checked exceptions in a controlled manner would be if Java provided a mechanism to declare exceptions as checked within a scope (say a package or an architectural layer) or by concentrating them within template patterns (which is basically what I have to do in a project I'm working on.)
Checked exceptions turned out to be a costly feature. They work well for designing layers interfacing with external layers - external being either logical or truly physical. IO layers and APIs for accessing external resources are excellent places for using checked exceptions.
But once you move away from that "boundary zone", checked exceptions introduce hidden costs in the form of either complex exception handling semantics or on implementing fault barriers and exception translation behavior. None of these are trivial, and it an art to get them right. Most people who try them fail miserably (introducing yet another leaky abstraction) since they usually don't really understand the nature of the root problem to begin with. A good solution would have been some way to mark exceptions as "checked" only within certain layers or packages.
Giving interface inheritance as the sole alternative to multiple (class) inheritance. This partially leads to immensely deep inheritance trees, and there is no way to modify an interface without altering the implementing classes (not good if your interface is being used by 3rd parties.) The solution has typically been to present an interface and provide a "suggested" abstract class that implements the interface, and from which to inherit from (kinda defeating the whole idea of strict interface inheritance to begin with.)
Using classes as namespaces. You can't define stand alone methods, and the reality is that not everything fits into an object. But you have to in Java. Just because everything has to be an object in a programming language, that does not imply that everything has to be defined within one. Pascal, C++, C# and Ada had it right in defining some sort of module/scope/namespace/package concept. Java didn't, and that by itself turned out to be a bad feature. This leads to the next dangerous feature:
Focusing object orientation to just noun-based inheritance hierarchies. Java more than any other language has monstrosities that look like this:
In any other language that allows you to declare methods on the top scope (or at least in the scope you are in), you don't need to shepherd everything into a dot-spaghetti - you simply say doSomeShitForMe(). People who think you have to have the former constructs to do OO never got OO right to begin with, and Java, unfortunately, leads itself to support that type of coding/thinking anti-pattern. The cost associated to that kind of shit (in terms of coding, debugging and NPEs) is enormous, and there is no clear whether this obsessions with noun-oriented dot-spaghetti can actually lead to better coding practices.
I am not convinced that it is such a bad thing that Java-the-language is 'stagnated'. As language, Java was designed from the start to eliminate features that were, in the parlance of the day, "Considered Harmful". So yes, it was and is a bit restrictive. C# has a richer syntax, including "goto"... The richer syntax can be a plus because it often saves time in coding.
But creating code is what, 20% of the lifetime cost of a software package? And meanwhile C# provides the less disciplined programmer with plenty of opportunities to create write-only code. Never mind lambdas and closures --- I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens. And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
Dude, "goto" was never eliminated in Java. It exists in Java in the extremely restricted form of a labeled break statement. And even without a full goto statement, the language still contains pretty much all the potentially harmful constructs (meaning all programming/control statements.) No amount of feature filtering will eliminate programming suckage as the idea of a "safer" programming language is an academic fallacy in anything but the narrowest, best well defined problem domains.
As a professional Java developer my conclusion is that the language is stagnant. Many of the ideas we originally thought were useful and that would conduct to better programming had turned out not to be such good ideas at all. In fact, they turned out to be bad ideas, syntactic/semantic "leaky abstractions" with an associated negative cost that no one would have expected back then between 1995-2000 when we were going OOOH JAVA:
Replacing multiple (class) interface inheritance - how do you modify an interface down the road (even good software is subject to changes) after it's been inherited by a bazillion entities w/o breaking code compatibility
.
Checked exceptions - they aren't that bad of an idea except that Java never provided a mechanism for preventing them cross-cutting all over the place.
String "+" operator - in the hands of sucky Java programmers (who are a dime a dozen) is the bane of garbage collectors. It is funny in a sad way that immutable strings were thought to help in memory management,but no one gave a shit of a thought about the poor implementation of the String "+" operator.
Not having a non-synchronized string builder until Java 1.5, and refusing to deprecate Vector and HashMap = brainfart.
Still having a debate about having support for lambdas and closures on Java 7 == a bigger brainfart.
Not having an explicit namespace mechanism (which forces you to use classes as namespaces) == another brainfart.
Each and every one of the brainfarts above were thought to be good ideas, but practice has proved them to be, well, brainfarts, very expensive brainfarts. If it weren't because the JVM is rock-solid and multiplatform, we would be dead in the water. The value of JEE stopped being the language a while ago, and the language innovations that were supposed to help implement software of a better quality turned to actually increase the cost of software development.
I have nothing but praise to Gosling and all the bright people that brought Java to us. But you can't stay perpetually in awe as if it were 1995. We gotta recognize what's good and what's broken and learn from past experience. Acknowledging that Java, the language, is stagnant, that's an step forward.
As a professional Java programmer, I've watched as Java-the-language has stagnated. Java-the-platform has only thrived thanks to Open Source, and no thanks to the sclerotic Java Community Process and an ineffectual steward in Sun Microsystems.
Java programmers have watched in horror as C# gained fully reified generics, lambdas and closures, arbitrary monadic comprehensions and Hindley-Milner type inference, whilst we've only grudgingly been allowed a broken generics model whilst Sun spent years rejecting and rewriting closure proposals that are still 1-2 years away from adoption.
C# is thriving because it has a benevolent dictator in the form of Anders Hjelberg. Java the language is a stagnant mess.
Dude, from one Java developer to another, you could not have said it better. It was a sad day for a Java developer like when I started watching the features in C# (and many features in the CLR) with deep envy. If we don't get good support for closures in Java 7, we'll have to conclude that, syntactically, Java (the language) is dead and COBOLified.
Please mention what gain full virtualization has over a system like openvz.
Your question is a non-sequitur. I'm not laughing at the proposition that openvz is better than full virtualization. THAT IS NOT WHAT YOU SAID IN THE POST I REPLIED TO
This is what you said:
Full virtualization is only worth bothering with if you are stuck running windows as well.
And that makes no sense. For starters, OpenVZ is limited now to having the guest and host OSes to be Linux (that might change in the future mind you.) But for problems that exist today, you need shit that run the shit you need to run today
So, please, tell me, how does OpenVZ help me if I have to support NetWare? How about supporting vm images of DOS for embedded devices? Solaris?
Notice that none of these real-scenarios scenarios fit into this "stuck in Windows". And even if all you need is Linux as the OS, there are still shops out there that WILL. NOT. USE. OpenVZ. Period.
Stupid? Yes. Reality? Yes,too. We get paid to get things done within the constrains in which we operate. You don't quit a job and burn bridges because they don't use every single piece of software that is your predilection. You don't stop being a problem solving professional because of that.
You suck it up and you just make it work because, in the end, it's not that bothersome or fatal to our oh-not-so-fragile(really) e-gos.
Get-Paycheck <--> Get-It-Working... even if it means to get it working with things you know are not necessarily the best technical alternatives. That's the difference between the professional and the fanboy. The professional makes a workable choice given constrains as opposed to dramatizing and evangelizing the search for the technical alternative of all times.
So that's why a lot of people "bother with vm even if they are just using Linux." Anyone with a modicum of work experience in a variety of work environments - good and bad - know this.
Valkovich will face a statutory maximum of 50 years in prison: 20 years for the murder-for-hire and 30 years for the bank fraud.
Two things amaze me:
One, that you can get more jail time for moving 440,000 from one DB column to another than for trying to have someone killed.
Two, that actual bankers that committed fraud to the tune of trillions were punished by (at most) being handsomely paid off and sentenced to go golfing for the rest of their lives.
What a strange "justice" system we've created for ourselves.
One. Laws do not get implemented in pairs. That is, legislators do not sit down and say, "umh, what a nice day, let's punish fraud more severely than attempted murder." Also, federal and state laws do not evolve in parallel either. So it is all conceivable that in a union like the US you'll have punishment discrepancies like that. The only fairness you get is the fairness of a fair trail. It is not strange at all. Legislation can (and might or might not) change those punishment discrepancies (for better or worse.) It's not a frozen thing, and it is not strange at all.
Two. Actual bankers did not commit fraud. I know what you are trying to say, BUT, the legal term fraud has a very specific meaning. To assign blame, or to accuse, you need to use the appropriate terms of accusation for it to make sense.
Slashdot Mirror
Whilst I sympathise, you're being rather melodramatic.
People survive perfectly well on one kidney.
Yeah, what a fucking consolation for someone who's having a loved one one hair away from death from a botched operation, you stupid animal.
And if the US adopted a socialised healthcare service, you wouldn't have had to pay a thing.
How long were you waiting for an opportunity to state that opinion? And you have to do it like that, in response to someone's post stating a real-life-and-death situation? What a fucking classless moron.
The Russians manage to save money, launch a lot of missions, AND they still have a safety record that dwarfs NASA's. Maybe we should ask them how to do it.
http://en.wikipedia.org/wiki/Nedelin_catastrophe
They have a safety record that dwarfs NASA? Pray tell what statistics are you using? I think there is a high probability you don't know what you are talking about.
So, basically, bend over and take it for 15 years until you can move to some other employer. Awesome.
Well, if accumulating 15 years of work experiences means "bending over and taking it" for you, then... welcome to human life. Whether you work 1 year or 15 years, whether as a employee or consultant or business owner, whether coding the ultimate compiler or flipping burger, you bend over and take it in from someone, one way or another.
It's called earning your bread with the sweat of your brow. Also, there is nothing wrong in accumulating x years of experience in preparation for a career move into another company if there is the potential of greater benefits. It's called having foresight, career improvement.
In case you thought you made a snarky, illuminating comment. Newsflash: You didn't.
If you are going to break into a megacorp, do it after you get your masters. A masters doesn't necessarily mean you are a better programmer than one who only has a B.S. or even a A.S. degree (I've seen M.S. grads who can't code their ways out of a for loop.).
But it does help in establishing a career path into software leads, principal engineers or software/system architects. Of course, the onus is on you for being able to delivering the goods as well as being able to roll your sleeves and code and make things happen.
Also, when in universities, get a job at their labs or do research, or do interships. That is, accumulate work hours.
Now, if you are already out of school and not working on a mega-corp, then go back to school and finish a MS. Then apply. If you are good, you should be a hot catch (experience and post-grad education.)
That's my opinion now that I look back at my professional experience (having worked both in small and big corps.) They way I see it, if you want to work on a mega-corp, do it with the purpose of establishing a career path as a team lead or principal engineer. If it's just for the love of coding, I would stay with small companies (or work as a consultant and milk the OT.)
Take that with a grain of salt. My opinion is extremelly personal and after ruminating about what I like and I don't like about software work on small and big corps.
It often works the other way, too. I can't remember how many interviews I've given for programming jobs where the interviewee comes in all cocksure and arrogant. Not to single them out, but I've found those trained in India to be the worst.
They tell me about their training at some foreign university or college I've never heard of, about all of the certification they've received from Sun and Oracle and Microsoft, and all of these programming contests that they've participated in. Then I ask them to describe how a linked list works, and they tell me some shit like, "Java doesn't support linked lists, only arrays."
Then I thank them for their time, and tell them to leave.
If there is any comfort, you are not the only one who have witnessed that type of shit. The funny thing about software geeks is that we tend to only look at corporate arrogance (whether real or perceived), but we never look at the arrogance we many times distill. Sometimes, what we see as arrogance in others just happen to be the reflectionof a big fucking chip in our shoulders.
As for arrogance in interviewers (and this is not intended to any poster in particular), it's human nature. I've been on the receiving end of interviewers more interested in showing me what they know or how little I know compared to them (little-dick-compensation syndrome) as opposed to actually interview me and gauge whether my skills can be incorporated as assets to the company.
An interviewer's job is to do just that: match an applicant's skills and personality against the requirements of a given position. When they go into little-dick-compensation syndrome, they are not doing their job and they might as well reimburse the company for the hours wasted in the interview and possible loss of talent acquisition.
But that's part of life and part of the game. We just have to suck it up with some dignity. Unless you are in a really dire situation and you are just short of taking a job flipping burgers, just stop the interview if you feel (rightfully of course) if they are feeding you dick stew. If it's tolerable, just go with it to the end, say thanks and move to the next interview.
If it's blatant dickery - "I'm sorry, but I don't feel the tone and objective of this interview is to gauge my skills against the job requirements but to show me how little I know or to establish a food chain order before even discussing if we are both interested in working together. I think it will be best that *I* (never *we* but *I*) discontinue this interview. Thank you for your time and I hope you find a suitable candidate."...
This is all predicated in the fact that your assessment is objective and that you are not just an ashole that gets easily insulted.
Not everything will be peaches and roses all the time, but if you conduct yourself professionally and with integrity and with respect, good things will follow.
I don't buy your conspiracy theory, but assume I do. That's one answer. How about the other examples?
Better question - when an anti-abortionist blows up a an abortion clinic, what empire needs to be renounced? What empire lead to the Oklahoma bombing? When neo-nazis plan terrorist attacks in Europe, what empire needs to be renounced?
Renounce Empire.
<rant>
The Lord's Army in Uganda is a terrorist organization, so was the Shinning Path in Peru. What empire does Uganda or Peru need to renounce? When a Sunny terrorist blows up a Shiite mosque in Pakistan, what empire does the Shiite minority needs to renounce?
I could bring a large number of examples where terrorism has more to do with ideology, racism and religious fanaticism than with any notions of empire and its side effects. Just because the most notorious forms of terrorism (Islamic terrorism affecting the Western World) can be explained as a reaction of empire building, that does not mean the phenomenon of terrorism can be explained in those terms, much less solved from those premises.
The easiest way to answer a moral question without actually answering it is by pitching empty slogans. It sure feels great to say them (oh man, do you feel me? I do stand for something, so cliche... I mean avant garde!)...
</rant>
On another note, if the story is true, I do hope Montgomery and whoever up the intelligence food chain that was too stupid to paid him for his snake oil go burn in hell.
How are they auditing the code of the closed source apps they're using? If there are steps in place, use those as a minimum. If there aren't, then how's the blind faith of using those programs different than what's needed for open source?
Flipping the question does not answer the original one, which is a valid one and which deserves an answer. The answer is, just like anything, it depends. It depends on the open source artifacts in question; it depends on the specific audit/security requirements; it depends on how critical the app under development is; it depends on SLA agreements (if one exists and requires it.)
As you said, if there are steps in place, use those as a minimum, provided that they are sufficient for the requirements at hand.
If there aren't any, you can't just cross your arms and say "well, if I didn't do them with COTS, why would I with FOSS"? If there aren't, and your project requires them, then shit, you implement them.
The question of whether to sec audit something, be it COTS or FOSS is predicated by the requirements at hand, not on whether a previous usage of COTS (or FOSS) was properly audited in the past.
What we need is basic training in algorithmic thinking for the masses.
Nope. What we need is more analytical thinking and less multiple-choice exams. That is far more fundamental than training on algorithmic thinking. Take any random kid from HS and I'll bet he'll be more inclined to ask "what is the answer to this problem?" as opposed to "how do I work it out?". That is what needs to be fixed.
CompSci and MIS programs churning chumps who can't code for shit themselves out of a wet paper bag. ..never mind their writing abilities...
Because not making a grammatical mistake when posting in haste is a requirement for writing code. L33t hax0r and grammer nazis unite!!(10+1) </finger>
Steve Lohr writes in the NY Times that the country needs more 'cool' nerds — professionals with hybrid careers that combine computing with other fields like medicine, art, or journalism.
Bad idea (not unless we are talking about people who have a BS/BA degree in a technical field pursuing another BS/BA degree - or even a MS - in another technical field. Now, THAT'S A HYBRID CAREER. We already have a problem with watered down CompSci and MIS programs churning chumps who can't code for shit themselves out of a wet paper bag. CompSci, MIS, Software Development and IT, these are fields that call for people that are domain experts and specialist, not watered down hobbyists with superficial and inadequate training.
It is quite telling of our society that when facing with a shortage of scientific/engineering talent, the solution is to make it more "cool" as opposed to raising the scholastic expectations of kids. As if "cool" makes up for the grey matter required to be a (good) software developer. Either the author thinks software disciplines are shallow enough that they can be weaved in with a medicine, journalist or even an arts curriculum (an art curriculum takes quite a lot of work to get through.) Either that, or he thinks these other disciplines can be watered down so as to allow someone to be graduate in both (notice that I say "graduate", not "be sufficiently competent.")
How come you don't see that type of mentality in India, China or, say Eastern Europe? You want kids to be interested in hard sciences (not just software disciplines)? Then raise the bar and academic rigor starting from 2nd grade all the way to 12th, where the objective is to learn and not simply to pass. You don't solve an educational deficiency by painting "cool" all over it.
On another note, I stopped reading the article when I hit this:
Today, introductory courses in computer science are too often focused merely on teaching students to use software like word processing and spreadsheet programs, said Janice C. Cuny, a program director at the National Science Foundation.
Say fucking what? I know that Computer Science curriculum in most universities have been watered down into Java/C# schools, but give me a fucking break. Either the journalist is misquoting Cuny, or she actually said - and I quote - that introductory courses in computer science are too focused on software like word processing and spreadsheet programs. If it's the later, someone kicks her out of the NSF. There is no "science" in that kind of stupid remark.
If anthrax is what i think it is, then it is impossible to find a vaccine for it because it will mutate fairly quickly.
Who the hell told you that what you think is a fact? Anthrax is what it is, a bacteria, not what you think it is.
You == dumbest poster ever.
I might regret saying this but the "which leads to the following" isn't entirely true. As a manager of staff, I do have responsibility and visibility across the whole project. But my staff don't.
I agree with that, but I also agree that each member of the staff is responsible for his own contribution to the team (and that contribution is directly proportional to the criticality or "cost-of-failure" of his contribution).
They don't have the time to each know every last detail about what everybody else is doing and how they are performing; that's my job -- they are trusting me to manage the project to a successful result. If Fred drops the ball, then sure enough I need to find a way to get it picked up.
We are in agreement.
But your last line isn't a very helpful way of approaching that. If you insist to Joe-down-the-corridor that "he should quit" / "is being dishonest" if he isn't happy about missing his son's birthday to pick up Fred's mess at the last minute "because that's what's needed to get the job done" -- that sounds like passing the buck on your responsibility for the project, and unless you are in a very high-paying environment (money covers many sins), it isn't helpful.
I do not insist on that. I insist in that people be professionals and work for the benefit of the employer who is writing a paycheck to them. Being professional does not mean missing your son b'day or dropping the ball on your family life. It simply means: be professional - don't chose your responsibilities or your opportunities for "stepping up to the plate" solely on who is to blame or who dropped the ball.
This is specially true when we work as salaried employees and not by-the-hour contractors (I've done both.) There is an understanding that at times people might need to stay beyond the regular 40 hours. And your kid's bday does not occur every day, nor every day is a family emergency.
No body is going question your professionalism when you have to take care of your family priorities, assuming you have a track record of doing your best to also meet your work priorities. The former goes hand in hand with the later.
However, what I see a lot is that team A drops the ball (or can't meet a deadline because someone on top screwed up the scheduling.) Team b needs to interface with the deliverables from team A by a certain date. But because of the reasons above, they can't. So team B has to work extra to either do a work around or take some work off team A.
Now the deadline must be met because if not, it will cost tens of thousands of dollars per hour and it puts the whole project in jeopardy. The jobs for team A and B are on the line, like pink-envelope time.
And yet team B decides not stick to their 9-to-5s because they didn't drop the ball. Team A or management or "they" (they=anybody but them) did. I'm going home, everything else be damned, stupid team A, stupid managers. Whether it rains or snows, out by 5 they go. Later they hate "they" when the project is canceled and they end up looking at dice.com every other hour.
Never mind they have much better salaries that other people with equal education in other fields. And never mind the benefits and the vacations. Project is about to fall and us be on the street serving fries? Who cares. We=good. They=evil. They=drop ball. We=go home by 5. Always. Every single day. For any single project. With each and every employer.
In almost every single freaking gig I've been I see this. It is true that it is human nature, but there is something about Software professionals that you see this more often (or perhaps more vitriolically visible), acting as if they are doing a favor to their employers for working with them (or as if the employer has an obligation to keep them hired no matter what just because they are pretty.)
Being just is not about being vindictive.
Acting like that is not being pr
/. needs to add a "+1, Fucking A" mod. You have it exactly right.
Playing the blame game is deadly to an organization. You end up spending more time trying to CYA than just fixing the problem.
Exaaactly brother. A lot of software prima donas like to cry foul about the "bizness" politics, how much they are above that, pretending to be 100% logical and objective and technology-driven, oblivious to their own pitiful CYA politics. Projection at its finest.
If the developers are staying late because the manager messed up, it doesn't hurt to stay late (but stay out of the way and order them food)
If the developers are staying late because they come in late or they messed up, no, the manager doesn't need to stay.
The reasons developers *must* stay late vary widely, depending on context, scheduling, external pressures (.ie. new requirements due to a merge that must be implemented immediately to avoid bleeding tens of $Ks/hour.) That is, they don't fit *at all* in that *he screwed up/they screwed up* dichotomy (which isn't even mutually exclusive to begin with.)
It is obvious that you do not have management/team lead experience. This is because, if I'm a manager and my guys screwed up and must stay late to fix it, I might need to stay with them to make sure they get it done. After all, the sign of a good manager is that he takes responsibility for the performance of the professionals under his watch, in particular if the thing to get done is critical, independently of who screws up.
Which leads to the following: the sign of a professional is that he does what needs to be done to get the job done and to conduct his job for the benefit of the business. BTW, if anyone has a problem with that statement, they should quit their jobs. It is dishonest to accept a check for a job function that is not being completed under that premise.
I might not be responsible for the screw up of someone else, but if called to step in, I would (if it is feasible for me to do so.) Within reason, professionals step up to the plate. Prima Donas and sensitive bitches with vaginal silicosis (who are a dime a dozen in the software world) do not, opting instead for trying to explain every single scheduling or work problem in terms of "who else other than me fucked up."
"Improved user experience" is marketingspeak for feature upgrade or bug fix. The parent got modded down, but if I had points, I'd put it right back up. Crippled software sets, suddenly enabled by market pressure, isn't an upgrade.
When apps are truly upgraded, so much the better, but this doesn't follow the computer industry model. And I wouldn't expect it from others.
What sort of computer industry model do you speak of? Certainly not what I've witnessed. Having a release ever 3 months or so is quite common in almost any industry I've been to. In fact, the better the software practices, the more that you see this in the form of predictable releases.
Even in companies that are still stuck in "waterfallish" models, but who have good software practices, you see that they schedule periodic releases.
In good and bad software shops, from waterfall to agile, real world computer industry models follow a pattern of constant software releases.
You say "Improved user experience" is marketingspeak for feature upgrade or bug fix.. I say NO FUCKING SHIT. You say it as if it were some sort of revelation. It is not. It is an oxymoron of collegiate sophomoric proportions.
If it is a feature upgrate, then it is (more often than not) improved user experience. If it is a bug fix, it is also (more often than not) improved user experience. Welcome to yesterday Cpt. Obvious.
Or what, do you think it is feasible to create non-trivial applications useful for more than a tiny tinie bunch of people in a cockamamie, irrelevant context without introducing bugs? No matter how good you are, you will introduce bugs in your software.
So as a professional, you will have no choice but to provide regular releases, to fix those bugs, to improve on a feature, or to adapt to a new request (which is a fact of software life.)
Or maybe I'm reading your post wrong (in the part about "improved user experience"). I do share your criticism on the android update model, though.
Indeed. You don't get insurgents without an occupying power*.
* For the semantic pedants: While technically insurgents could resist a domestic government, it's been the case in the 20th century and since that insurgent warfare is a response to invading forces.
Uh, really, explain to me which were the invading forces that triggered a response from the following which are perhaps best known and most representatives of 20th insurgency: - UNITA insurgency during the Angolan Civil war) (Angola)
- Tamil Tigers (Sri Lanka)
- Lord's Resistance Army (Uganda)
- AFDL (Congo)
- FSLN/MILPAS/Contras (Nicaragua) - FMLF (El Salvador) - Shining Path (Peru) - Tupac Amaru (Peru) - EZLN (Mexico) - CPN-M (Nepal)
- India's Naxalite insurgents
- People's Mujahedin of Iran
I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens.
Nope. The very purpose is to simplify code usage. I don't gain anything by saying o.setName("name") when I can semantically get the same by saying o.name = "name". It was one of the greatest things that came out of Delphi, and there is a reason why it is the default way to access bean properties in EL/JSTL (firmly a Java technology) as well as in Groovy.
Unless that verbosity gets me something (clarity, better semantics) it is just syntactic salt with no associated benefit and certainly with an associated cost. When you start working with a whole bunch of goddam POJOs, you'd wish you'd have properties. I used to be in that camp that worshiped verbosity for the sake of it. Fortunately, first hand work experience in its associated cost helped me grew out of it.
I don't gain anything in knowing whether o.name = "name" executes code or not. I want that name to be "set". Whether that "set" operation carries additional semantics beyond assignment (.ie. synchronization, reference count or what not), I don't need to know. I don't want to know. Just as I would not want to know the "hidden" internals of calling a method in an object.
In fact, YOU WANT TO HIDE THE CODE INVOCATION. In programming, you simplify out of a context the things that you don't need to know. If you have two constructs that, by design-by-contract, carry the same semantics, you opt for the less verbose one. Always.
And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
Prove to me that "good" exception handling absolutely requires checked exceptions, and then you might have an argument. In my experience, the worst exception handling mechanisms I've seen have been implemented with checked exceptions. No other language introduces them.
Now think about this. The folks implementing Groovy, Scala, C# as well as those that support and extend the C++ standard, these are all people experienced in programming language theory (not counting their industrial experience). And, by what they know, and by their industrial experience, they opt not to implement checked exceptions. Moreover, there are a lot of systems implemented in Java and otherwise that have excellent exception handling without checked exceptions. What should that tell you? Checked exceptions sounded good on paper, but it turned out not to be the case.
Exception handling (or design by contract for that matter) does not require checked exceptions. Sorry. Checked exceptions introduce code entanglement at various levels, and Java does not provide a way to abstract them out. The only way to really use checked exceptions in a controlled manner would be if Java provided a mechanism to declare exceptions as checked within a scope (say a package or an architectural layer) or by concentrating them within template patterns (which is basically what I have to do in a project I'm working on.)
Like what, out of curiosity?
Checked exceptions turned out to be a costly feature. They work well for designing layers interfacing with external layers - external being either logical or truly physical. IO layers and APIs for accessing external resources are excellent places for using checked exceptions.
But once you move away from that "boundary zone", checked exceptions introduce hidden costs in the form of either complex exception handling semantics or on implementing fault barriers and exception translation behavior. None of these are trivial, and it an art to get them right. Most people who try them fail miserably (introducing yet another leaky abstraction) since they usually don't really understand the nature of the root problem to begin with. A good solution would have been some way to mark exceptions as "checked" only within certain layers or packages.
Giving interface inheritance as the sole alternative to multiple (class) inheritance. This partially leads to immensely deep inheritance trees, and there is no way to modify an interface without altering the implementing classes (not good if your interface is being used by 3rd parties.) The solution has typically been to present an interface and provide a "suggested" abstract class that implements the interface, and from which to inherit from (kinda defeating the whole idea of strict interface inheritance to begin with.)
Using classes as namespaces. You can't define stand alone methods, and the reality is that not everything fits into an object. But you have to in Java. Just because everything has to be an object in a programming language, that does not imply that everything has to be defined within one. Pascal, C++, C# and Ada had it right in defining some sort of module/scope/namespace/package concept. Java didn't, and that by itself turned out to be a bad feature. This leads to the next dangerous feature: Focusing object orientation to just noun-based inheritance hierarchies. Java more than any other language has monstrosities that look like this:
Shenanigan.getInstance()
In any other language that allows you to declare methods on the top scope (or at least in the scope you are in), you don't need to shepherd everything into a dot-spaghetti - you simply say doSomeShitForMe(). People who think you have to have the former constructs to do OO never got OO right to begin with, and Java, unfortunately, leads itself to support that type of coding/thinking anti-pattern. The cost associated to that kind of shit (in terms of coding, debugging and NPEs) is enormous, and there is no clear whether this obsessions with noun-oriented dot-spaghetti can actually lead to better coding practices.
I am not convinced that it is such a bad thing that Java-the-language is 'stagnated'. As language, Java was designed from the start to eliminate features that were, in the parlance of the day, "Considered Harmful". So yes, it was and is a bit restrictive. C# has a richer syntax, including "goto"... The richer syntax can be a plus because it often saves time in coding.
But creating code is what, 20% of the lifetime cost of a software package? And meanwhile C# provides the less disciplined programmer with plenty of opportunities to create write-only code. Never mind lambdas and closures --- I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens. And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
Dude, "goto" was never eliminated in Java. It exists in Java in the extremely restricted form of a labeled break statement. And even without a full goto statement, the language still contains pretty much all the potentially harmful constructs (meaning all programming/control statements.) No amount of feature filtering will eliminate programming suckage as the idea of a "safer" programming language is an academic fallacy in anything but the narrowest, best well defined problem domains.
As a professional Java developer my conclusion is that the language is stagnant. Many of the ideas we originally thought were useful and that would conduct to better programming had turned out not to be such good ideas at all. In fact, they turned out to be bad ideas, syntactic/semantic "leaky abstractions" with an associated negative cost that no one would have expected back then between 1995-2000 when we were going OOOH JAVA:
.
Each and every one of the brainfarts above were thought to be good ideas, but practice has proved them to be, well, brainfarts, very expensive brainfarts. If it weren't because the JVM is rock-solid and multiplatform, we would be dead in the water. The value of JEE stopped being the language a while ago, and the language innovations that were supposed to help implement software of a better quality turned to actually increase the cost of software development.
I have nothing but praise to Gosling and all the bright people that brought Java to us. But you can't stay perpetually in awe as if it were 1995. We gotta recognize what's good and what's broken and learn from past experience. Acknowledging that Java, the language, is stagnant, that's an step forward.
As a professional Java programmer, I've watched as Java-the-language has stagnated. Java-the-platform has only thrived thanks to Open Source, and no thanks to the sclerotic Java Community Process and an ineffectual steward in Sun Microsystems.
Java programmers have watched in horror as C# gained fully reified generics, lambdas and closures, arbitrary monadic comprehensions and Hindley-Milner type inference, whilst we've only grudgingly been allowed a broken generics model whilst Sun spent years rejecting and rewriting closure proposals that are still 1-2 years away from adoption.
C# is thriving because it has a benevolent dictator in the form of Anders Hjelberg. Java the language is a stagnant mess.
Dude, from one Java developer to another, you could not have said it better. It was a sad day for a Java developer like when I started watching the features in C# (and many features in the CLR) with deep envy. If we don't get good support for closures in Java 7, we'll have to conclude that, syntactically, Java (the language) is dead and COBOLified.
Please mention what gain full virtualization has over a system like openvz.
Your question is a non-sequitur. I'm not laughing at the proposition that openvz is better than full virtualization. THAT IS NOT WHAT YOU SAID IN THE POST I REPLIED TO
This is what you said:
Full virtualization is only worth bothering with if you are stuck running windows as well.
And that makes no sense. For starters, OpenVZ is limited now to having the guest and host OSes to be Linux (that might change in the future mind you.) But for problems that exist today, you need shit that run the shit you need to run today
So, please, tell me, how does OpenVZ help me if I have to support NetWare? How about supporting vm images of DOS for embedded devices? Solaris?
Notice that none of these real-scenarios scenarios fit into this "stuck in Windows". And even if all you need is Linux as the OS, there are still shops out there that WILL. NOT. USE. OpenVZ. Period.
Stupid? Yes. Reality? Yes,too. We get paid to get things done within the constrains in which we operate. You don't quit a job and burn bridges because they don't use every single piece of software that is your predilection. You don't stop being a problem solving professional because of that.
You suck it up and you just make it work because, in the end, it's not that bothersome or fatal to our oh-not-so-fragile(really) e-gos.
Get-Paycheck <--> Get-It-Working ... even if it means to get it working with things you know are not necessarily the best technical alternatives. That's the difference between the professional and the fanboy. The professional makes a workable choice given constrains as opposed to dramatizing and evangelizing the search for the technical alternative of all times.
So that's why a lot of people "bother with vm even if they are just using Linux." Anyone with a modicum of work experience in a variety of work environments - good and bad - know this.
Two things amaze me:
One, that you can get more jail time for moving 440,000 from one DB column to another than for trying to have someone killed.
Two, that actual bankers that committed fraud to the tune of trillions were punished by (at most) being handsomely paid off and sentenced to go golfing for the rest of their lives.
What a strange "justice" system we've created for ourselves.
One. Laws do not get implemented in pairs. That is, legislators do not sit down and say, "umh, what a nice day, let's punish fraud more severely than attempted murder." Also, federal and state laws do not evolve in parallel either. So it is all conceivable that in a union like the US you'll have punishment discrepancies like that. The only fairness you get is the fairness of a fair trail. It is not strange at all. Legislation can (and might or might not) change those punishment discrepancies (for better or worse.) It's not a frozen thing, and it is not strange at all.
Two. Actual bankers did not commit fraud. I know what you are trying to say, BUT, the legal term fraud has a very specific meaning. To assign blame, or to accuse, you need to use the appropriate terms of accusation for it to make sense.
Full virtualization is only worth bothering with if you are stuck running windows as well.
HAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHH!!!! Oh wait, you were being serious. Oh well.... HAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHH!!!!