How about we blend it with DU and 'burn' it in a reactor?
Heretic!
How dare you propose a solution which is both workable by examples in France and Japan, and fails to support the idea that wind and solar can provide all the power we need (ignore the Solyndra behind the curtain)?!?!?!
I'm pretty sure we burned Joan of Arc at the stake for less than that!
I can see why parent is marked insightful... the more packets coming through a router, the more friction there is on the wires and other electronic components, the faster things wear out.
AT&T probably has an entire team of people who go around measuring wear and tear on routers and wiring using calipers.
The guy did not actually recommend what you just said. He suggested a software fix where if brake and gas are both pressed, the brake would over-ride the gas pedal. So brake would always stop the car independent of whether the gas pedal was pressed.
According to the comments section, it already works that way. Also, if you look at the pictures of the pedals, the brake pedal area is huge compared to the gas pedal area. While I personally like a long gas pedal hinged at the bottom, compared to a small square one, it's pretty clear his heel was too far right for braking. He probably needs to adjust his seat forward to increase his foot rotation.
We've jumped way past the point of claiming that polarized background cosmic radiation = gravitational waves detected (right now, the polarization is just consistent with a theory that, IF there are gravitational waves, AND a particular inflation theory requiring gravitational waves to be possible is correct, THEN the observed polarization is consistent with fossil pre-inflation gravitational waves.
We are now to the point of "alternate explanations for the gravitational waves 'observed' by BICEP2".
It's like seeing a headline that says "Aliens meet with Jimmy Carter!" in a supermarket tabloid, and then arguing about whether or not they met with Jimmy Carter, instead of arguing about whether or not aliens landed on Earth... or arguing about whether or not they landed on Earth, rather than whether aliens exist in the first place.
They could put antlers on the thing, as long as it continues to pass the POSIX conformance test suite Validation Suite for Commands version 5, it doesn't matter, my medulla will be able to still type the commands to operate it while I'm up in my cerebral cortex thinking about higher level problems than "will typing this command too many times give me carpal tunnel syndrome like RMS has from emacs use?" or "how an I get a graduate student to take dictation into an editor for me, rather than aggravating my carpal tunnel syndrome acquired from emacs use?".
If you have an ethical or philosophical objection to training a replacement on the basis of the company terminating you afterward in order to save money, and they have no other reason (which they could not, given they feel you are qualified to train), then you can refuse, and if terminated for refusal, claim benefits.
Treating companies as a place to get vocational training because your college degree is nothing more than a union card because you didn't put in the effort required to actually *learn* something when you were at college, and you were more concerned with how much you thought you were going to be making when you picked your major than with actually liking or being good at the job?
I had to train my replacement. not long, since they wanted us off the company site in days, not weeks.
I got 2 weeks severance for being there 1 year's time.
Unless they were holding a gun to your head, or an amazing place to put on your resume, or wrote you a stellar letter of reference, or the two weeks pay was desperately needed, how does "had to" fit into the whole "train my replacement" sentence there? If you'd refused, you'd have been fired, and therefore eligible for unemployment for 18 months, right?
We would much rather pay the cost of having younger workers make the mistakes the older workers learned to avoid.
Older workers avoid repeating mistakes -- true... as far as it goes.
I don't think this is an issue when the product your company is building is a social networking web site that you plan on rewriting every couple of weeks anyway in an "iterative process" of getting to the point where Facebook will buy you out. If the old code doesn't work very well, fire the programmers that wrote it, get new bodies in to write the next version, and be done with it. For the parts that actually do work, well, don't fire those guys, unless the parts work well enough that you don't need any more work done on them: "good enough" is the enemy of "better" -- and they can't be thrown over on some other code you need worked on.
If you are working on disposable code, then you're a disposable worker, period. If someone uses the magic work "iterate" in your job interview, take that as a strong clue that you will be working on disposable code.
Instead of whining about the impracticality of retraining "old" tech people, why not help them keep their skills up to date while they are working?
The whole "retraining" attitude is BS.
YES, it's cheaper to get an already trained worker than it is to retrain an existing one! You'd have to be stupid to think that a company is going to run a training program itself, rather than contributing towards continuing education. It's about as stupid as believing that there will be a training program at your company that will make you magically competent in a way that your newly minted college degree was not able to. If they don't even have a training program in the first place, what makes you think they are going to start a *re*training program just so they can keep a high salary worker on the payroll while they come up to speed on something that a new college graduate (or someone who took advantage of the continuing education assistance program) is *already* up to speed on?
Practically speaking, every tech company I have ever worked at, including those with fewer than 50 engineers, is willing to pay for continuing education for all their workers. If you don't take advantage of the opportunity, that's on you.
So if you take advantage of ongoing training, great for you. If you don't, don't expect a voucher for retraining in the envelope containing your pink slip: you've already screwed the pooch by not keeping up to date.
Right in both cases. I narrowly avoided a layoff by learning a new skill and jumping at the right time. But the issue in our case wasn't retraining (the company ended up blowing time and money training the H1-B "guests" anyway) it was simply the desire to pay third world salaries.
I've never seen an H1-B worker in the U.S. that cost the company a third world salary, rather than a first world salary. This is true for H1-B's at Google, IBM, Facebook, and Apple.
The closest I've seen to an H1-B worker *being paid* a third world salary is an H1-B worker (effectively) indentured to a contracting agency by the contracting agency holding the H1-B registration for the worker, and being unwilling to legally transfer it, and taking a huge chunk of the workers paycheck. I saw that happen for several contract workers at IBM. But in every case, the cost that IBM paid the contracting agency was comparable to, or in excess of, the salary an H1-B hired directly by IBM, or a U.S. worker equivalent, would have cost.
I've seen a similar boondoggle at a primarily Chinese H1-B/graduate student employing company (which was started and owned by a Korean gentleman), but that was basically a way to get MS level people at fairly cheap prices by holding their visas over their heads, and it was seriously atypical of the majority of H1-B workers or companies that hire H1-B workers as normal workers.
So yeah, there are H1-B indentured servants, but they're all pretty much at contracting companies or startups, and they are not the norm.
I have retrained myself a number of times - even paid thousands of dollars of my own money for it.
The question: How do you get around the requirement for 'on the job' experience of your new skills?
All of my re-training was worthless because I didn't have any paid experience in those skills. I volunteer and that is not good enough either. It has to be paid experience and at least two years of it - from the feedback I am getting.
Take a bridge job, where some fraction of your time can be dedicated to applying those new skills. Presto: two years experience on your resume.
Sometimes a lateral move is not actually lateral, if it gets you resume-fodder that you believe you're going to need to advance your career.
"The biggest slap in the face to all of us here is we have to train all of our replacements," said the IT worker. Once that training is completed, the IT workers receive severance pay. Some employees were offered jobs with the offshore firms, but at lower salaries and with reduced benefits, he said.
There's no reason they couldn't be training Americans to replace those jobs.
In the places I've seen this, the severance was generally 6 months, and the IT workers were tech leads who were shipped to India and paid for the training time on top of those six months, so the choice is between doing the training, getting a trip to an exotic country that you might have wanted to visit anyway, and then get a half a years pay and insurance coverage on top of any COBRA or other benefits, during which you can immediately go to work for a competitor, or just bum around for 6 months in Thailand or the Mediterranean or wherever.
It's a pretty good deal, if your job's going to be going away anyway, unless you're the wrong person to be doing the training, and if you are, you're not going to be able to compete for jobs with your displaced coworkers because you aren't better at the job than they are (hence "the wrong person to be doing the training").
In general, though, the bottom line is that they *could* be training Americans to replace those jobs, but few Americans would likely be willing to expatriate to India to work where the jobs are located, at the wages offered. It's not like the person in the article was training H1-B workers intended to work in the U.S..
They intermediate DNS all the time,in order to do proxy caching, and to prevent you going to high bandwidth sites without a lot of difficultly, or to land you on a page when you hit a non-existant domain because of a typo, and they try to sell it to you.
One wireless carrier, on their WiFi hotspot-only options, used to move you off their 4G network and onto their 3G by having intentional "DNS outages" that pointing to Google's DNS worked around. 3G had a data cap for which they got paid, 4G was no data cap, so the benefit to them for you using the DHCP assigned DNS was enormous: large amounts of data charges.
Even if they aren't screwing with the results for their own reasons, you hitting Google for all your DNS lookups means that they can't cache DNS responses, which means that they have to support more DNS traffic out and responses in on their network than they otherwise would need to.
None of these are beneficial to their bottom line.
And what, exactly, does using an "interface builder" to build a GUI program teach you? Nothing.
It enforces a "hands off" on the framework internals by virtue of presenting only a high level abstraction.
Commercial IDEs from vendors like Apple and Microsoft are "better"? Better for what?
They are better at information hiding. As a result, you have to learn to code in an environment where there is hidden information. In a non-framework coding environment, if something doesn't work the way you want it to because there is no way for you to add non-standard behaviour, it also means that user training is portable between applications written with the same framework(s). In other words, it reduces the learning curve involved in transferring knowledge from word processor A to work processor B or spreadsheet C, and so on.
A consequence of this is that you learn to live in the constrained environment published by a given framework. It doesn't really qualify you to implement frameworks yourself, since you don't see them from the outside, but it will at least give you a feeling for how you should constrain the programmers implementation environment, should you write your own framework in the future.
If I had to boil it down to a single sentence, I'd say "They more strictly enforce API contracts, and by so doing, allow less talented people to produce useful code".
Tell me, what is the "order of the algorithm" that the gui builder generates?
It doesn't matter, if it's fast enough for the hardware you are running on, and everyone is stuck with the same algorithm, regardless of order. One would hope that the people writing frameworks had a deeper understanding of the fact that they are constraining their consumers, and would attempt to get their implementation as close to O(1) as possible, without needing to throw hardware at the problem.
If you consider places where O(1) algorithms are truly necessary, e.g. performance critical code, such as code which is called repeatedly, or code such as in the Linux scheduler (which, by default, uses an O(1) algorithm), this typically falls into the "you are not expected to understand this" category, and the code is written by more capable people in order to benefit the less capable by virtue of having done the hard work on their behalf.
This is very common with self-taught programmers, or programmers who came up through either vocational training, or programmers who were apprenticed into their jobs. Unfortunately, this makes you much less valuable, because you probably don't know the proper terminology to use when referring to a specific algorithm, or you do not have a working knowledge of rarely used data structures, or you do not know object oriented programming paradigms. Minimally, you are going to be handicapped when you are trying to communicate about these things with your peers - in other words, people who have a formal education in these things can use a shorthand you can't, and as a result your communications bandwidth is considerably less than theirs, when talking about technical aspects of the work.
The first key to understanding frameworks is that there is an inversion of control: the framework dictates the control flow, not you. This may come from after you call into a framework functions, but in the simplest implementation, it comes from you not getting to write your "main" function. If you have used yacc, and did not supply your own main because you have linked to liby.a and used the liby.a supplied main() and yyerror() routines, then you have used this type of programming. If you have used rpcgen and used librpc.a to supply the main() for your program, you've also done a similar thing.
The second key to understanding frameworks is that you are allowed to extend, but not modify, a framework. Extension is done by overriding callback methods, or by providing additional event processing by hooking the default action, which is typically an error action. For this to be understandable, you need to have a minimal understanding of object orients programming. It's perfectly possible to do object oriented programming in C (in fact, libXt and libAw and other widget toolkits in X Windows did exactly this, prior to wide availability of inexpensive C++ compilers. If you've ever had a pointer to a structure that contains function pointers, and substituted one set of function pointers for another by setting the structure pointer through which you call things to one structure instance or another, you've done this. In simplest terms, you can write a function that gets called when you press a button, but you can't change the fact that it's a button, or the fact that when the UI sends an event into the framework, that causes your function to get called when the user clicks the button.
The third and final key to understanding a framework is that things have default behaviours. If you don't supply a function to handle a particular event, then the framework is going to supply one for you. For example, if you have a menu bar with drop down menus, the main menu will probably have a quit option. If you don't supply a function to implement the quit (e.g. popping up a dialog and asking if the user wants to save their work, if they've done any), then the default action will happen instead, and the program will quit - without saving the changes, since it's your responsibility to know that there were document or settings changes, and it's your responsibility to warn the user, if the user needs warning.
You might have some minimal knowledge, through use of Python, of the very basics of frameworks, but since the language doesn't actually force their use, then you probably don't have a very good understanding beyond that.
My suggestion would be to take a class or seminar on object oriented programming; one thing that's pretty popular is the Stanford series on iPhone programming using Objective C, which will also teach you concepts about object instantiation and messaging, which are things you might need to know on top of just object oriented programming.
You'd also do well to learn a compiled object oriented language, like C++, if you opt out of learning Objective C, rather than relying on "getting it" by using a language which doesn't force object orientation on you. At the v
My paret (or is that you?) assumed that all recessive gens are harmfullor a sign of illness or an genetic illness.
They are not.
Brining some more genetic illnesses as argument implies you make the same mistake.
A genetic mutation resulting in illness is not a "genetic illness" unless the gene's host survives to reproduce. It doesn't require that the parents each pass on a recessive trait to activate the disease in the offspring, cosmic rays can cause it.
Perhaps you would be happier were I to use the terminology "previously non-heritable genetic disorder that is now heritable and incorporated into the human gene pool in general as a result of preventing the death of the host".
That seems a bit of semantic hair splitting, but the point is we routinely engage in technological intervention into these cases today, such as the SIRT1 gene that JDRF funded the discovery of, and which, prior to insulin treatment for T1D, would not have survived into a second generation, and was therefore a self-limiting mutation.
The argument isn't whether we are going to extend human life or not, or whether the resulting extensions are "natural" or not in terms of the population, and speaking to Travis Mansbridge's argument, it's too damn late to make that argument: we've already thrown a stick in the spokes of that wheel, and now it's only a matter of how many sticks and how many wheels, not a matter of "if we can".
As for recessive traits, unless they are severe enough to cause you to lose against competitors without the same trait, they will not be bred out.
I think you are confusing "recessive genes", which I never specifically mentioned, with "unfavorably mutated genes".
How about a single gene mutation which would normally result in the child dying, but for which treatment exists, and which is now retained and propagated in the gene pool? For example, the mutations to the gene RNU4ATAC responsible for microcephalic osteodysplastic primoridal dwarfism type 1 (MOPD1).
Or how about the SIRT1 mutation, also a single gene mutation, which results in type 1 diabetes? Without treatment, this mutation, which can occur naturally, would ordinarily result in the death of the individual, rather than being passed on to future generations (given that dead individuals have a hard time breeding).
The fact is, we have already passed the point where technological intervention has disabled the feedback mechanism of death in multiple cases where a gene mutation would not be retained in the overall gene pool.
All we are arguing about now is how far we allow these efforts to go in preventing death, and not whether or not these efforts are effective, since they demonstrably are.
For the most part, yes, but there's something to be said for gui in the fwbuilder/ASDM space and for visibility operations. A minority of tasks are actually easier in a GUI, though it has to be a pretty good GUI or its a wash.
That'd be a great argument, if all devices of a particular class used the same GUI; of course, then they'd be commodities, and the lowest price wins.
GUIs are a means of doing two things:
(1) Differentiating your product from someone else's to add margin to what is actually a commodity
(2) Causing knowledge to be vendor-specific in order to facilitate vendor lock-in through learning curve.
You obviously only administer small LAN systems in low security environments.
Stateless autoconf, uPNP, zeroconf, prolific service discovery stacks, and non-local authentication databases are the very first things we turn off on any system that requires security-in-depth and rock-solid stability. These are all end-user/domain features that have no place in WAN, metro-lan, and border network infrastructure.
Google recently went to the model where all connections to the Google internal network are VPN connections, even if you are in a Google cubicle in a Google building on a Google supplied computer plugged into a Google network port located in a secured area.
The idea that you need to secure network connectivity is bogus, and an artifact of scarcity of bandwidth. Without an artificial scarcity, there's no reason to not allow anyone who wants it connectivity, so long as gethostbyaddr() returns their actual affiliation, and gethostbyname() returns wherever they happen to be located in IPv6 space at the moment.
Perhaps you should reread what "recessive genes" actually are. E.g. the gene for red hair is recessive... has nothing to do with your rant.
Your argument would be sound if all we were talking about were recessive genetic disorders, like color blindness.
Perhaps you should read about adrenoleukodystrophy caused by a mutation on ABCD1 which can happen to anyone, and which was normally removed from the gene pool by way of the effected person dying at a young age before they could reproduce. Or any of thousands of similar genetic diseases which we now treat, and therefore retain in the gene pool.
It may be a good survival trait to have fear of death, but it leads to things like religions, including this new technological one, and prolonging life beyond when it serves an evolutionary incentive.
We should probably take away the insulin from the diabetics and the classes and contacts from people who are near-sighted, and undo any laser surgeries we've done on peoples eyes.
You know, to serve as an evolutionary incentive.
In case you were wondering, evolution is not "survival of the fittest", it's "survival of those who successfully reproduce most", or we would have weeded things like near-sightedness out of the genome a long time ago, along with all other recessive traits.
Furthermore, do you understand how species development works? Have you heard of this "evolution" thing?
That would be the natural tendency of people with normal vision to out-compete people with impaired vision, and for people without diabetes to out-compete those with it, right?
Didn't we kind of lose that pressure when we started intervening technologically by putting up audible crossing indicators, manufacturing glasses, manufacturing injectable insulin, doing allergy testing, developed cochlear implants, started vaccinating people against diseases, and so on?
Most of the historical evolutionary pressures on humans which kept the number of recessive genes in the gene pool small (because the people who had them who expressed the traits... well, they died, rather than reproducing..) are no longer applicable. Thanks for playing, though.
Slashdot Mirror
How about we blend it with DU and 'burn' it in a reactor?
Heretic!
How dare you propose a solution which is both workable by examples in France and Japan, and fails to support the idea that wind and solar can provide all the power we need (ignore the Solyndra behind the curtain)?!?!?!
I'm pretty sure we burned Joan of Arc at the stake for less than that!
I can see why parent is marked insightful... the more packets coming through a router, the more friction there is on the wires and other electronic components, the faster things wear out.
AT&T probably has an entire team of people who go around measuring wear and tear on routers and wiring using calipers.
The guy did not actually recommend what you just said. He suggested a software fix where if brake and gas are both pressed, the brake would over-ride the gas pedal. So brake would always stop the car independent of whether the gas pedal was pressed.
According to the comments section, it already works that way. Also, if you look at the pictures of the pedals, the brake pedal area is huge compared to the gas pedal area. While I personally like a long gas pedal hinged at the bottom, compared to a small square one, it's pretty clear his heel was too far right for braking. He probably needs to adjust his seat forward to increase his foot rotation.
Great assumed premise, guys, really.
We've jumped way past the point of claiming that polarized background cosmic radiation = gravitational waves detected (right now, the polarization is just consistent with a theory that, IF there are gravitational waves, AND a particular inflation theory requiring gravitational waves to be possible is correct, THEN the observed polarization is consistent with fossil pre-inflation gravitational waves.
We are now to the point of "alternate explanations for the gravitational waves 'observed' by BICEP2".
It's like seeing a headline that says "Aliens meet with Jimmy Carter!" in a supermarket tabloid, and then arguing about whether or not they met with Jimmy Carter, instead of arguing about whether or not aliens landed on Earth... or arguing about whether or not they landed on Earth, rather than whether aliens exist in the first place.
As long as it passes VSC5, I don't care.
They could put antlers on the thing, as long as it continues to pass the POSIX conformance test suite Validation Suite for Commands version 5, it doesn't matter, my medulla will be able to still type the commands to operate it while I'm up in my cerebral cortex thinking about higher level problems than "will typing this command too many times give me carpal tunnel syndrome like RMS has from emacs use?" or "how an I get a graduate student to take dictation into an editor for me, rather than aggravating my carpal tunnel syndrome acquired from emacs use?".
No. Refusing to do a task is insubordination and grounds for termination.
See http://www.edd.ca.gov/UIBDG/Ab...
If you have an ethical or philosophical objection to training a replacement on the basis of the company terminating you afterward in order to save money, and they have no other reason (which they could not, given they feel you are qualified to train), then you can refuse, and if terminated for refusal, claim benefits.
You wanna know what's BS?
Treating companies as a place to get vocational training because your college degree is nothing more than a union card because you didn't put in the effort required to actually *learn* something when you were at college, and you were more concerned with how much you thought you were going to be making when you picked your major than with actually liking or being good at the job?
That's pretty BS.
I had to train my replacement. not long, since they wanted us off the company site in days, not weeks.
I got 2 weeks severance for being there 1 year's time.
Unless they were holding a gun to your head, or an amazing place to put on your resume, or wrote you a stellar letter of reference, or the two weeks pay was desperately needed, how does "had to" fit into the whole "train my replacement" sentence there? If you'd refused, you'd have been fired, and therefore eligible for unemployment for 18 months, right?
We would much rather pay the cost of having younger workers make the mistakes the older workers learned to avoid.
Older workers avoid repeating mistakes -- true... as far as it goes.
I don't think this is an issue when the product your company is building is a social networking web site that you plan on rewriting every couple of weeks anyway in an "iterative process" of getting to the point where Facebook will buy you out. If the old code doesn't work very well, fire the programmers that wrote it, get new bodies in to write the next version, and be done with it. For the parts that actually do work, well, don't fire those guys, unless the parts work well enough that you don't need any more work done on them: "good enough" is the enemy of "better" -- and they can't be thrown over on some other code you need worked on.
If you are working on disposable code, then you're a disposable worker, period. If someone uses the magic work "iterate" in your job interview, take that as a strong clue that you will be working on disposable code.
Instead of whining about the impracticality of retraining "old" tech people, why not help them keep their skills up to date while they are working?
The whole "retraining" attitude is BS.
YES, it's cheaper to get an already trained worker than it is to retrain an existing one! You'd have to be stupid to think that a company is going to run a training program itself, rather than contributing towards continuing education. It's about as stupid as believing that there will be a training program at your company that will make you magically competent in a way that your newly minted college degree was not able to. If they don't even have a training program in the first place, what makes you think they are going to start a *re*training program just so they can keep a high salary worker on the payroll while they come up to speed on something that a new college graduate (or someone who took advantage of the continuing education assistance program) is *already* up to speed on?
Practically speaking, every tech company I have ever worked at, including those with fewer than 50 engineers, is willing to pay for continuing education for all their workers. If you don't take advantage of the opportunity, that's on you.
So if you take advantage of ongoing training, great for you. If you don't, don't expect a voucher for retraining in the envelope containing your pink slip: you've already screwed the pooch by not keeping up to date.
Right in both cases. I narrowly avoided a layoff by learning a new skill and jumping at the right time. But the issue in our case wasn't retraining (the company ended up blowing time and money training the H1-B "guests" anyway) it was simply the desire to pay third world salaries.
I've never seen an H1-B worker in the U.S. that cost the company a third world salary, rather than a first world salary. This is true for H1-B's at Google, IBM, Facebook, and Apple.
The closest I've seen to an H1-B worker *being paid* a third world salary is an H1-B worker (effectively) indentured to a contracting agency by the contracting agency holding the H1-B registration for the worker, and being unwilling to legally transfer it, and taking a huge chunk of the workers paycheck. I saw that happen for several contract workers at IBM. But in every case, the cost that IBM paid the contracting agency was comparable to, or in excess of, the salary an H1-B hired directly by IBM, or a U.S. worker equivalent, would have cost.
I've seen a similar boondoggle at a primarily Chinese H1-B/graduate student employing company (which was started and owned by a Korean gentleman), but that was basically a way to get MS level people at fairly cheap prices by holding their visas over their heads, and it was seriously atypical of the majority of H1-B workers or companies that hire H1-B workers as normal workers.
So yeah, there are H1-B indentured servants, but they're all pretty much at contracting companies or startups, and they are not the norm.
I have retrained myself a number of times - even paid thousands of dollars of my own money for it.
The question: How do you get around the requirement for 'on the job' experience of your new skills?
All of my re-training was worthless because I didn't have any paid experience in those skills. I volunteer and that is not good enough either. It has to be paid experience and at least two years of it - from the feedback I am getting.
Take a bridge job, where some fraction of your time can be dedicated to applying those new skills. Presto: two years experience on your resume.
Sometimes a lateral move is not actually lateral, if it gets you resume-fodder that you believe you're going to need to advance your career.
I suspect he means "not cheap"
FTFA:
"The biggest slap in the face to all of us here is we have to train all of our replacements," said the IT worker. Once that training is completed, the IT workers receive severance pay. Some employees were offered jobs with the offshore firms, but at lower salaries and with reduced benefits, he said.
There's no reason they couldn't be training Americans to replace those jobs.
In the places I've seen this, the severance was generally 6 months, and the IT workers were tech leads who were shipped to India and paid for the training time on top of those six months, so the choice is between doing the training, getting a trip to an exotic country that you might have wanted to visit anyway, and then get a half a years pay and insurance coverage on top of any COBRA or other benefits, during which you can immediately go to work for a competitor, or just bum around for 6 months in Thailand or the Mediterranean or wherever.
It's a pretty good deal, if your job's going to be going away anyway, unless you're the wrong person to be doing the training, and if you are, you're not going to be able to compete for jobs with your displaced coworkers because you aren't better at the job than they are (hence "the wrong person to be doing the training").
In general, though, the bottom line is that they *could* be training Americans to replace those jobs, but few Americans would likely be willing to expatriate to India to work where the jobs are located, at the wages offered. It's not like the person in the article was training H1-B workers intended to work in the U.S..
False premise. Assumes a bias without providing evidence.
Why the hell would they want Google DNS to work?
They intermediate DNS all the time,in order to do proxy caching, and to prevent you going to high bandwidth sites without a lot of difficultly, or to land you on a page when you hit a non-existant domain because of a typo, and they try to sell it to you.
One wireless carrier, on their WiFi hotspot-only options, used to move you off their 4G network and onto their 3G by having intentional "DNS outages" that pointing to Google's DNS worked around. 3G had a data cap for which they got paid, 4G was no data cap, so the benefit to them for you using the DHCP assigned DNS was enormous: large amounts of data charges.
Even if they aren't screwing with the results for their own reasons, you hitting Google for all your DNS lookups means that they can't cache DNS responses, which means that they have to support more DNS traffic out and responses in on their network than they otherwise would need to.
None of these are beneficial to their bottom line.
And what, exactly, does using an "interface builder" to build a GUI program teach you? Nothing.
It enforces a "hands off" on the framework internals by virtue of presenting only a high level abstraction.
Commercial IDEs from vendors like Apple and Microsoft are "better"? Better for what?
They are better at information hiding. As a result, you have to learn to code in an environment where there is hidden information. In a non-framework coding environment, if something doesn't work the way you want it to because there is no way for you to add non-standard behaviour, it also means that user training is portable between applications written with the same framework(s). In other words, it reduces the learning curve involved in transferring knowledge from word processor A to work processor B or spreadsheet C, and so on.
A consequence of this is that you learn to live in the constrained environment published by a given framework. It doesn't really qualify you to implement frameworks yourself, since you don't see them from the outside, but it will at least give you a feeling for how you should constrain the programmers implementation environment, should you write your own framework in the future.
If I had to boil it down to a single sentence, I'd say "They more strictly enforce API contracts, and by so doing, allow less talented people to produce useful code".
Tell me, what is the "order of the algorithm" that the gui builder generates?
It doesn't matter, if it's fast enough for the hardware you are running on, and everyone is stuck with the same algorithm, regardless of order. One would hope that the people writing frameworks had a deeper understanding of the fact that they are constraining their consumers, and would attempt to get their implementation as close to O(1) as possible, without needing to throw hardware at the problem.
If you consider places where O(1) algorithms are truly necessary, e.g. performance critical code, such as code which is called repeatedly, or code such as in the Linux scheduler (which, by default, uses an O(1) algorithm), this typically falls into the "you are not expected to understand this" category, and the code is written by more capable people in order to benefit the less capable by virtue of having done the hard work on their behalf.
You appear to not know fundamentals.
This is very common with self-taught programmers, or programmers who came up through either vocational training, or programmers who were apprenticed into their jobs. Unfortunately, this makes you much less valuable, because you probably don't know the proper terminology to use when referring to a specific algorithm, or you do not have a working knowledge of rarely used data structures, or you do not know object oriented programming paradigms. Minimally, you are going to be handicapped when you are trying to communicate about these things with your peers - in other words, people who have a formal education in these things can use a shorthand you can't, and as a result your communications bandwidth is considerably less than theirs, when talking about technical aspects of the work.
The first key to understanding frameworks is that there is an inversion of control: the framework dictates the control flow, not you. This may come from after you call into a framework functions, but in the simplest implementation, it comes from you not getting to write your "main" function. If you have used yacc, and did not supply your own main because you have linked to liby.a and used the liby.a supplied main() and yyerror() routines, then you have used this type of programming. If you have used rpcgen and used librpc.a to supply the main() for your program, you've also done a similar thing.
The second key to understanding frameworks is that you are allowed to extend, but not modify, a framework. Extension is done by overriding callback methods, or by providing additional event processing by hooking the default action, which is typically an error action. For this to be understandable, you need to have a minimal understanding of object orients programming. It's perfectly possible to do object oriented programming in C (in fact, libXt and libAw and other widget toolkits in X Windows did exactly this, prior to wide availability of inexpensive C++ compilers. If you've ever had a pointer to a structure that contains function pointers, and substituted one set of function pointers for another by setting the structure pointer through which you call things to one structure instance or another, you've done this. In simplest terms, you can write a function that gets called when you press a button, but you can't change the fact that it's a button, or the fact that when the UI sends an event into the framework, that causes your function to get called when the user clicks the button.
The third and final key to understanding a framework is that things have default behaviours. If you don't supply a function to handle a particular event, then the framework is going to supply one for you. For example, if you have a menu bar with drop down menus, the main menu will probably have a quit option. If you don't supply a function to implement the quit (e.g. popping up a dialog and asking if the user wants to save their work, if they've done any), then the default action will happen instead, and the program will quit - without saving the changes, since it's your responsibility to know that there were document or settings changes, and it's your responsibility to warn the user, if the user needs warning.
You might have some minimal knowledge, through use of Python, of the very basics of frameworks, but since the language doesn't actually force their use, then you probably don't have a very good understanding beyond that.
My suggestion would be to take a class or seminar on object oriented programming; one thing that's pretty popular is the Stanford series on iPhone programming using Objective C, which will also teach you concepts about object instantiation and messaging, which are things you might need to know on top of just object oriented programming.
You'd also do well to learn a compiled object oriented language, like C++, if you opt out of learning Objective C, rather than relying on "getting it" by using a language which doesn't force object orientation on you. At the v
You don't support our policies?
Don't worry, I'm sure we can change your mind...
My paret (or is that you?) assumed that all recessive gens are harmfullor a sign of illness or an genetic illness.
They are not.
Brining some more genetic illnesses as argument implies you make the same mistake.
A genetic mutation resulting in illness is not a "genetic illness" unless the gene's host survives to reproduce. It doesn't require that the parents each pass on a recessive trait to activate the disease in the offspring, cosmic rays can cause it.
Perhaps you would be happier were I to use the terminology "previously non-heritable genetic disorder that is now heritable and incorporated into the human gene pool in general as a result of preventing the death of the host".
That seems a bit of semantic hair splitting, but the point is we routinely engage in technological intervention into these cases today, such as the SIRT1 gene that JDRF funded the discovery of, and which, prior to insulin treatment for T1D, would not have survived into a second generation, and was therefore a self-limiting mutation.
The argument isn't whether we are going to extend human life or not, or whether the resulting extensions are "natural" or not in terms of the population, and speaking to Travis Mansbridge's argument, it's too damn late to make that argument: we've already thrown a stick in the spokes of that wheel, and now it's only a matter of how many sticks and how many wheels, not a matter of "if we can".
As for recessive traits, unless they are severe enough to cause you to lose against competitors without the same trait, they will not be bred out.
I think you are confusing "recessive genes", which I never specifically mentioned, with "unfavorably mutated genes".
How about a single gene mutation which would normally result in the child dying, but for which treatment exists, and which is now retained and propagated in the gene pool? For example, the mutations to the gene RNU4ATAC responsible for microcephalic osteodysplastic primoridal dwarfism type 1 (MOPD1).
Or how about the SIRT1 mutation, also a single gene mutation, which results in type 1 diabetes? Without treatment, this mutation, which can occur naturally, would ordinarily result in the death of the individual, rather than being passed on to future generations (given that dead individuals have a hard time breeding).
The fact is, we have already passed the point where technological intervention has disabled the feedback mechanism of death in multiple cases where a gene mutation would not be retained in the overall gene pool.
All we are arguing about now is how far we allow these efforts to go in preventing death, and not whether or not these efforts are effective, since they demonstrably are.
For the most part, yes, but there's something to be said for gui in the fwbuilder/ASDM space and for visibility operations. A minority of tasks are actually easier in a GUI, though it has to be a pretty good GUI or its a wash.
That'd be a great argument, if all devices of a particular class used the same GUI; of course, then they'd be commodities, and the lowest price wins.
GUIs are a means of doing two things:
(1) Differentiating your product from someone else's to add margin to what is actually a commodity
(2) Causing knowledge to be vendor-specific in order to facilitate vendor lock-in through learning curve.
You obviously only administer small LAN systems in low security environments.
Stateless autoconf, uPNP, zeroconf, prolific service discovery stacks, and non-local authentication databases are the very first things we turn off on any system that requires security-in-depth and rock-solid stability. These are all end-user/domain features that have no place in WAN, metro-lan, and border network infrastructure.
Google recently went to the model where all connections to the Google internal network are VPN connections, even if you are in a Google cubicle in a Google building on a Google supplied computer plugged into a Google network port located in a secured area.
The idea that you need to secure network connectivity is bogus, and an artifact of scarcity of bandwidth. Without an artificial scarcity, there's no reason to not allow anyone who wants it connectivity, so long as gethostbyaddr() returns their actual affiliation, and gethostbyname() returns wherever they happen to be located in IPv6 space at the moment.
Perhaps you should reread what "recessive genes" actually are. ... has nothing to do with your rant.
E.g. the gene for red hair is recessive
Your argument would be sound if all we were talking about were recessive genetic disorders, like color blindness.
Perhaps you should read about adrenoleukodystrophy caused by a mutation on ABCD1 which can happen to anyone, and which was normally removed from the gene pool by way of the effected person dying at a young age before they could reproduce. Or any of thousands of similar genetic diseases which we now treat, and therefore retain in the gene pool.
It may be a good survival trait to have fear of death, but it leads to things like religions, including this new technological one, and prolonging life beyond when it serves an evolutionary incentive.
We should probably take away the insulin from the diabetics and the classes and contacts from people who are near-sighted, and undo any laser surgeries we've done on peoples eyes.
You know, to serve as an evolutionary incentive.
In case you were wondering, evolution is not "survival of the fittest", it's "survival of those who successfully reproduce most", or we would have weeded things like near-sightedness out of the genome a long time ago, along with all other recessive traits.
Furthermore, do you understand how species development works? Have you heard of this "evolution" thing?
That would be the natural tendency of people with normal vision to out-compete people with impaired vision, and for people without diabetes to out-compete those with it, right?
Didn't we kind of lose that pressure when we started intervening technologically by putting up audible crossing indicators, manufacturing glasses, manufacturing injectable insulin, doing allergy testing, developed cochlear implants, started vaccinating people against diseases, and so on?
Most of the historical evolutionary pressures on humans which kept the number of recessive genes in the gene pool small (because the people who had them who expressed the traits... well, they died, rather than reproducing..) are no longer applicable. Thanks for playing, though.