What Ubuntu did was very unsatisfactory. You still cannot easily compile your own kernel. What that ex-RedHat guy did was a lot better since you can load anything you want as long as you confirm your choice on boot.
Here is what RMS should be doing instead of this petition which is going to get nowhere:
1. Restart work on coreboot
Coreboot is still being worked on, I've personally done patches to it while employed by Google. It's even shipping on a number of ChromeOS platforms from a number of vendors. I think what you are advocating here is actually returning it to its original "Open Source BIOS replacement" role; I think that's unlikely for a number of reasons.
2. Make coreboot work with Windows and Linux as is
It's not going to work with a Windows that requires a UEFI boot, and Windows is moving in that direction. You can't buy new Windows XP licenses, and they are not patching the zero days on IE that will run on XP as part of discouraging it, above and beyond not selling XP licenses. So Windows that boots without UEFI boot and runtime services is quickly going to become completely unavailable.
The consequence of this is that in proposing a coreboot that can boot Windows by default, you are actually proposing replacing the current coreboot with an Open Source UEFI implementation. This is probably not workable, since vendors like non-disclosure from their BIOS vendors until they ship, and the ACPI implementation alone is so chipset specific that it would take a very long time to grow all the chipset support. To further hamper this effort, a number of the PMUs and other chips that get tied into here, such as the EC in laptops, and the EC firmware for each laptop, is also typically under NDA. Coreboot as a BIOS replacement alone, not even considering UEFI boot and runtime services, never really got that far, except on the Chrome OS devices and one or two vendors reference work for single motherboard SKUs.
For Linux, the Coreboot generally requires uboot on ARM devices, and Linux is somewhat hampered in adoption by the fact that the Linux kernel uses different device tree sources than the coreboot/uboot code. While it's technically possible, it's politically untenable.
I tried to get to the bottom of this while working on ARM on Chrome OS at Google, and from what I can tell, the device tree stuff dated back to the Open Firmware code for PPC machines, and there was an intentional Apple policy decision to make it impossible to identify specific cores. This prevented locking threads to cores, which in turn allowed the platform support code to take cores on and off line out from under the OS for power management purposes. So all cores showed the same ID. Linux power management is based on ACPI, and since ACPI is significantly primitive compared to the Mac OS stepper code (which is why Mac OS on Mac hardware gets significantly better battery life than Windows on the same hardware), losing the ability to lock threads to cores, which is a basic tenet of Linux scheduling and CPU groups, lost Linux features compared to other systems, without a corresponding power management benefit from adhering to the policy. So Linux built up an infrastructure that "distrusts" the vendor device tree information. For coreboot/uboot systems, this translates to "distrusting" the device tree compiled into them by the vendor compared to the one in the kernel (compiled from the same sources). Which is to say, it's all still there as a means of working around an intentional Apple design decision, and removing it is a political hot potato.
3. Convince more motherboard manufacturers to support coreboot
This is relatively easy, if you are willing to work in a private tree and not publish until after they ship so that your commits don't telegraph information to their competitors. Samsung and other manufacturers have enough trust that Google won't disclose prematurely that they are willing to trus
Look dude, I'm the one who tracked down the bug. I'm the one who reported it to all the UEFI BIOS vendors, and as far as I know, H2O is the only company which has fixed their implementation to list the code and data tagging to place that static library into the runtime services region rather than the boot time services so that it's not reclaimed out from under the runtime services by an aggressive OS page reclaim.
I know the specification, and I know that the implementation doesn't match the specification for almost every UEFI implementation out there. I know about the talks on attack surface, but that's not going to fix the F-ed up BIOS in hardware that's already out there, and motherboard vendors generally don't ship BIOS updates unless they pay the contracted BIOS company to do the work, and they only do that for problems which can't be worked around in software.
For the (majority) busted UEFI implementations, the workaround of delaying the reclaim of the pages until the memory call has been made leaves the attack surface open. Not delaying the reclaim of the pages doesn't close the attack window, it just moves it into whatever crap the OS has loaded into those pages rather than whatever crap that UEFI had there before the boot time services were terminated.
That aside, regardless of whether the busted UEFI leaves the attack surface there, the point is that, like POSIX conformance testing, when the spec and the code disagree, the code wins. Period.
This is the same problem the ACPI implementation has been suffering from for years: The vendor can make it totally correct according to the specification, or they can make it possible to continue booting unmodified Microsoft Windows distributions. The result is that the ACPI implementation never gets totally technically correct.
You can keep modding my posts down because you don't like their content, but it won't make the content untrue, or make that truth any less inconvenient for people like the OP who had problems getting Linux running on their UEFI based grey boxes they were trying to build themselves.
I've told the OP where to put the workaround in Linux, and I've told the OP where the bug lives in the UEFI implementation (good luck getting the vendor to fix that just for Linux, unless there's an offer to pay their BIOS vendor contract costs for doing the work, or an offer to buy a large enough number of units in a single order with the sale condition on getting the fix.
It'd be nice if the vendors fixed the bug so Linux didn't have to work around it, and it's also be nice for Linux if nVidia and ATI released the sources to the hardware acceleration portions of their drivers too, but that's just not going to happen without some serious $ changing hands.
I guarantee you that the bug report I filed with Apple (one of the vendors with a broken UEFI from using the broken Intel reference implementation) has been P3'ed as a "nice to have", and then moved to a component where it's not visible to most Apple engineers who could actually fix the problem, if they had a bug report to hang the fix on.
It isn't stupid, it is just buggy firmware. That's what is stupid.
Anyway... I use 64-bit Flash on Linux.
Actually, I don't think I have any 32-bit software installed on this 64-bit Linux machine.
You don't use it on Amazon, Google Play, our YouTube protected content. Flash Access isn't built into Flash, it's a plugin to the Flash plugin.
And you're right, it's "just buggy firmware", but unless you are running a post-July version of the H2O UEFI/BIOS implementation, you can't shut down the boot time services.
You appear to be unaware of the details of protected content vis-a-vis Flash; I shall try to lay it out for you:
Protected content sold by Amazon, and also by Google Play, is protected via Adobe Flash Access.
Adobe Flash Access relies on a unique machine identifier to implement the key escrow in order to lock your content to the download machine so that it can not be re-uploaded in a digital form without having to use the analog hole in order to degrade the content.
The way it obtains this unique machine identifier is by synthesis of a lot of different machine information via libhal (a library with an associated daemon, intended as a Hardware Abstration Layer). As you can easily see here: http://www.freedesktop.org/wiki/Software/hal libhal has been deprecated since May of 2008, yet Adobe chose to require it anyway.
This four-year-out-of-date library is not installed by default on Ubuntu systems, and doesn't give the answers Adobe Flash Access wants in order to be able to successfully run on 64 bit systems. Even when hacked up, there are typically symptoms during video playback, such as the video playing fine up to the first commercial break, and then after the commercial, the audio continues working, but the video is nothing but a black screen.
These problems do not occur on a 32 bit Linux, as they do on a 64 bit Linux running 32 bit software. The need to support multiple Linux platforms, combines with the Jan 31st 2012 rollout of the new version of Adobe Flash Access protection on content by Amazon no doubt influenced the decision, announced Feb 20 2012, to drop Adobe Flash Support for Linux outside official Google Chrome builds: http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html
Now that you have the context, do my earlier comments on 64bit vs. 32 bit make more sense?
It's only on 64 bit installs, and only because Linux use UEFI differently than all other operating systems.
The UEFI problems are well known to be a problem in the reference UEFI implementation not mapping a region of a statically linked library used in the UEFI implementation as being part of runtime services rather than boot services.
When 64 bit Linux *stupidly* shuts down the boot services, it unloads a number of pages of memory that would be used by runtime services. Then it calls into the runtime services to remap the memory map so that the Linux reorganization of RAM is known to the runtime services, and the machine crashes. Anyone with a JTAG who tried to track the problem down would have seen this.
I said "stupidly" because it's a few pages of memory they get by shutting down the runtime services, and it's only done in 64 bit mode, which means instead of gigs of RAM minus a few pages, you get a crash. The pages don't matter in the larger scheme of things.
This is also only a problem if you insist on using 64 bit Linux, which means you can't use Flash, Skype, or anything else that's 32 bit only, and your Linux ends up less compatible with all the content on the Internet than it usually is.
The fix is a couple line patch to disable turning off the boot services. And then to stop bitching that everyone copied the bug in the initial reference implementation, and refuses to patch their UEFI implementation to update it because of the cost and security issues that would raise.
For what I gather, spaceX is mostly made up of ex-NASA people. From that it follows that spaceX probably did not invent the wheel, but simply copied and improved the one invented (and paid for) by NASA.
I expect that it's more of a case of "NASA won't let us build the cool vehicles we want to build, it makes us build all this expensive crap, and we get to do it for maybe three vehicles before we end up dead from old age; hey! Let's go work for this billionaire who actually has a vision of the future he wants to build, instead of these politicians and bureaucrats who don't get that roller coaster feel in their stomach every time someone plays the Kennedy moon speech..."
Personally, I'd rather work for someone with an actual vision beyond "let's send up some robots and get results in a decade and a half so we can justify sending up some more robots".
If you have differences in depth of field for your eyesight, particularly if you've had your eyes lasered into monovision
I'm not quite sure what you're saying. "Depth of field" is a photography tem referring to how much of a scene is in focus. A smaller aperture leads to a larger depth of field, and vice-versa. Are you referring to one eye being at a different focal length than the other? And if that's the case, you're going to be wearing corrective lenses bringing both eyes to the same focal length (or your eye doctor is incompetent).
No, I mean "depth of field", as in "everything in the 3D movie was in focus at the same time, which led to an uncomfortable viewing experience". The dumbass thing the cinematographer did was to do a 3D movie and computer generate it with everything in focus regardless of the virtual distance from the viewers forced perspective location within the scene.
Then you end up having problems seeing the 3D effect because theater 3D effects are generally achieved using either circular polarization ("Real3D") or horizontal vs. vertical polarization. This is because the polarization based 3D effect is achieved through forced perspective due to the eyes natural use of parallax to achieve binocular visions. This is also why you can't exceed 50% of the screen height for an apparent 3D projection.
And what do you mean by "lasered into monovision?" LASIK doesn't affect your stereoscopic vision at all, unless you poke one of your eyes out with the laser.
Yes, it does. Generally, if you start out with myopia due to curvature of your cornea, as you get older, you develop presbyopia as well as the lenses in your eye lose elasticity due to aging, and you end up with vision that is not normally correctible to perfect vision via LASIK. To combat this, and achieve the widest market possible for eye surgeries, a technique called monovision LASIK was developed, in which one eye is lasered for near vision and one eye lasered for far vision. The technique is similar to the use of bifocals, except it's per-eye. If your eyes are lasered into monovision, as in Monovision LASIK, as is described here: http://www.allaboutvision.com/visionsurgery/presbyopia_surgery.htm#monoLasik you end up still getting blurry in one eye parallax so your ability to judge distances doesn't end up damaged, you just end up with one eye being dominant for close vision, and the other eye dominant for distance visions. But it blows the hell out of your ability to see 3D in movie theaters using forced perspective techniques.
if your eyesight is bad enough you need correction in a movie theater in the first place, you are likely already carrying around a second pair of corrective lenses
Son, my eyes were 20/400 most of my life; extremely nearsighted. I couldn't focus farther than my elbow, but only had one pair of glasses. Sorry, but it sounds like you don't really have much of a clue what you're talking about.
Sounds like you never broke your glasses and had to drive some place to get them fixed. I've had a second pair available to me since third grade, and carry one in my car in case I'm out somewhere and my glasses get broken. Alternately, you've always had someone with you, or you take public transportation everywhere, but in either case, it's likely you have an old pair of glasses at home in a drawer "just in case", or you are not telling the truth about your level of myopia.
This is what the original article claimed as well.
If you have differences in depth of field for your eyesight, particularly if you've had your eyes lasered into monovision, then yes, I could see it being uncomfortable; however, that's easily solvable by not watching in a 3D theater or by using equal polarization in both eyes so you simply don't see the 3D effect at all, and get the same polar frame in both your eyes. And yes, such "2D glasses" do exist.
You can also get 3D prescription lenses, which, if your eyesight is bad enough you need correction in a movie theater in the first place, you are likely already carrying around a second pair of corrective lenses, since polarized sunglasses will back out one or both eyse when using an LCD screen at work, so what's yet another pair.
The place I've seen 3D truly failing has mostly been in movies that drop in and out of 3D, or have limited depth of field because it's digitally separate planes that have been poorly composited in post-production. In those cases, I hold the cinematographer responsible, which may be why he's feeling uncomfortable about the technology.
Specifically, last August, they required that the identities of file sharers must be turned over to rights holders.
So, for example, if someone posted a link to a file sharing site outside of German jurisdiction on their Facebook page, Facebook would be responsible for turning over the identity information for the nickname. At which point they would have a hell of a time complying with the court order to turn over the information they didn't have on file.
So, short of German tort reform, this severs their legal liability to shutting down the account in compliance with their Acceptable Use Policy, with the ability to reasonably claim ignorance that the person who registered the account did not do so in good faith compliance with said policy. The policy allows them to limit their legal liability.
Here's the Slashdot story on the German Federal Court of Justice ruling, which kind of trumps a decision by a privacy regulatory body with no actual legal teeth to contravene German Federal Court rulings, case law, or the German Federal law on which the ruling was based:
This allows outbound connections from Google to J-random-POP3-server to be reliably encrypted.
The other option would have been to permit you to upload, and cause Google to use, J-random-certificate for an outbound POP3 connection. However, doing this doesn't reliably achieve the "reliably encrypted" goal, since you could upload an intrinsically compromised POP3 peer certificate.
The reason for wanting the reliable encryption is that an untrustworthy ISP, government agency, or some with the capability of forging BGP could compromise the encryption with a MITM attack.
With the requirement in place, the eavesdropping agency has commit fraud, or obtain cooperation of the certificate authority, and should that become public knowledge, they would quickly find themselves untrusted by all major browsers.
The point, then, is that it is now impossible to cheaply and unobtrusively perform Great Firewall Of China or NSA-style "cast a wide net" operations on email traffic, or the type of warrantless wiretap of email that several recent US court decisions have said is "legal and not an invasion of privacy" for any email left on a server for more than 90 days.
If you start encrypting the email itself with S/MIME on top of that, you have an end-to-end guarantee that doesn't make the people using S/MIME "look suspicious, because if they didn't have anything to hide, they'd let us see it".
This type of thing is definitely a move in the right direction: drag the trusted CA's into it, and let them go out of business if/when they violate the trust place in them.
I stopped subscribing to physical newspapers as soon as their content hit over 50% advertising on the normal news pages, and they became nothing more than a cheaper-than-the-USPS method for distributing sales circulars and coupons.
Electronic publishers, including those for eBooks, and not just limited to "eNewspapers", have become nearly unreadable, because they no longer employ actual, human editors to correct spelling and grammatical errors; if I have to correct it in my head, that's work I'm doing that they should be doing before I even see it.
The eNewspapers are even more egregiously failing me than eBooks, since for non-fiction, their fact checking is seriously lacking -- not that the print versions are doing any better in this regard.
The profession of investigative journalism of the type practiced by Neil Sheehan, Bob Woodward, and Carl Bernstein is effectively dead in todays news media. The closest you will see is the occasional television journalistic "scoop", in which a whistle-blower has effectively handed the story to the likes of 60 Minutes, with a bow on it, and they ran with the story because it lacked sufficient controversy to get them in legal hot water.
A pay wall will likely not get me to read this eTripe any more than I already do, which is best characterized as "infrequently at best", and will certainly disincentivize me further if, on paying the fee, I find that there are still large tracts of ads fighting for my attention as they attempt to further monetize my already monetized eyeballs.
Look, morons, it's very simple:
(1) Provide your ad-blasted tripe for free (2) Write stories that have more depth than their first sentence, or you will not be seeing me click through (3) Hire some damn editors (4) Clearly mark syndicated vs. non-syndicated content (5) Let me have a try-before-I-buy time limited subscription without asking for my billing details up front; I do not have a business relationship with you unless I like you (6) Profit!!!!
Do I think this model will work for you? Not long term, as the New York Times is in the process of demonstrating. So approach the problem a different way.
Personally, I would prefer that you just syndicate your original content through Google, and concentrate on that, rather than fitting it in the column inches of syndicated content I can get anywhere else I happen to look. Let Google or whoever emerges as "the one new portal" pay your syndication fees out of their ad revenue, and leave me the hell out of it.
You need to realize that you are not going to do ad serving better than Google does it. Just give the hell up now, and do what you can do better than Google (and do it before Google gets better at it than you are because you are running around with no focus).
And hire some damn editors. If my 6th grade niece can point out your grammar faux pas, you should damn well be able to hire someone with an English degree, whose other options for a career would otherwise be limited to either making more people with English degrees or asking me "would you like fries with that?" to fix your spelling and grammar.
Oh, and finally: some idiots blog doesn't count as news, so leave their publication to Blogspot, and stick with actual news, please.
It would be even better if there were tort reform capping the liability limits for malpractice, and if the same insurance company, or group of companies, didn't get five hits at the insurance trough for you going in for one MRI.
Is there a free middleware that would do similar things?
If the answer is 'no' (or if whatever there is isn't large enough to be useful,) then a developer has the choice of either using a closed service with a solid history or rolling their own and entering a very costly "not invented here" cycle with all of the attendant bugs and crap to deal with that could have been avoided.
Nobody's going to use a fly-by-night company to host important parts of their project to be sure.. but GameSpy and IGN have been around for years and years and nobody could have foreseen such problems 5-10 years ago!
The answer is "no". The GameSpy platform provided several things:
(1) Matchmaking (2) Centralized storage of user generated content (3) Cross-platform support (4) Player statistics/leaderboards (5) Discussion communities (6) Centralized identity for multiple games (7) Third party hosting (8) Scalability
#1 is not actually that valuable, unless you are into PVP games; I'm not, but I could see it being an issue for a lot of the slop games that are out there.
#6 is more valuable to the players than it is to the game companies, since they'd want to tie you into playing them with no portal to other detinations, but it's a tolerable trade-off.
The rest of them add value, and aren't easily replicated. There certainly aren't open APIs for this stuff, as a single package, and a company that wanted to monetize as much as possible be silly to offer such a package for direct licensing, without them at least owning the comunities and the centralized identities for marketing purposes.
Guido wasn't 'here's a box for you crap, you have five minutes before security escorts you out the door" fired. It was closer to 'we don't see a role for you here, quit now and save us both the hassle of having to let you go' type fired.
He has really accomplished nothing since he was hired. And needless to say with Google actively replacing Python in the company with Go, he was acting like a petulant ass.
Google is a strange place to work. It's entirely possible that, by the performance metrics they typically use, it was a mutual parting of the ways; I don't know, and unless you are on the performance review committee for his engineering subgroup, neither do you (and if you are, you should be keeping your mouth shut, instead of posting here, even as an AC). But assuming your theory is correct, don't mistake an organizational inability to effectively utilize his talents with him not having them.
That said, your second paragraph is basically BS. Go never really caught on because it did not have a cross-platform library; the reason was that it insisted on directly trapping its system calls itself, which is great, if you aren't an engineer with a MacBook Pro trying to do work at home, and want the same system call semantics for e.g. "kill" or "sigaction". Hint: at the top of Libc on Mac OS, kill takes 2 parameters; at the user/kernel boundary, it takes 3 so the kernel knows whether it should use traditional Mac OS signal semantics, or use POSIX 1003.1-2001 semantics (same as Linux). Until they drop Mac OS X for Linux (probably still running on Apple hardware), or the Go folks fix their language binding to use LibSystem (Libc) instead of trapping their own system calls, I don't see that changing in favor of Go adoption any time soon.
While Go is an "official language", along with C/C++ there are two others, one of which is Python, and not a lot of work was actually being done in Go. My last major project at Google was exclusively Python, and all of the testing infrastructure for Chrome OS is written in Python. One of the first classes you are offered as part of new employee orientation, apart from "How to use Perforce" is "Python Programming".
Personally, I could see him leaving as being part of the generally publicly announced Larry Page effort to focus Google on working on fewer total projects, and on hiring for specific roles, instead of just hiring everyone who met the right level of smart, and figuring something for them to do afterwards. But frankly, I do not see increased focus fixing what Larry's attempting to fix with it. I suspect this is more likely than your theory.
Either way, I expect his contributions at Dropbox will be valuable to them, and wish him luck there.
You know, I always liked the system layout of the TI-99/4a
Me too. Having to jam everything through a 4K window made you write a lot more efficient code, instead of what we get today when people have free memory to waste on calculating frames that never get composited or displayed.
Private health care has been a disaster, consistently going 0 for 4 on your list of, "lean, organized, efficient and responsible".
Private health care has been very effective.
Private health insurance, on the other hand, truly has been a disaster.
Pay the insurance company for health insurance, to pay your Dr. to pay the insurance company for malpractice insurance, to pay the hospital to pay the insurance company to pay for malpractice and liability insurance, to pay the lab equipment manufacturers to pay the insurance companies for liability insurance.
Private drug companies have also been a disaster.
Develop a cure: get paid once; develop a treatment: get paid over and over again. Microsoft didn't invent the subscription model, Merck , Sandoz, and others did.
He asked the questions because he was qualified to. It would be utterly absurd for an interviewer to ask you questions on the relative merits of different weave patterns for baskets, if the interviewer was not themselves an accomplished basket weaver.
The interviewer in question was likely chosen precisely because you had worked on a lot of cool stuff, in order to decide whether you had a broad general ability, or whether your focus in those areas had lost you your breadth. Someone who has to look up an algorithm, isn't going to look at a problem, generalize it to a class of problems, and then pull the appropriate most optimal algorithm for the problem out of their toolbox.
Even if the algorithm were in your toolbox (i.e. you were able to generalize the problem, pick the most appropriate algorithm, and apply it), and you just didn't have the stats associated with it (i.e. you knew it should be Vanadium, but you didn't know it was atomic number 23, or that it's electronegativity was 1.63), you would not have been in a position to discuss with code reviewers. Unless you can say why you chose that particular algorithm, compared to some other algorithm, by quantifying its relative merits (e.g. "it was O(N) rather than O(N^2)", or "algorithm X conserves space better than the slightly more efficient algorithm Y, and space is at a premium in this application"), then you would not be an effective member of the team.
Minimally, someone who was able to explain would have to follow along after you cleaning up the code and/or check in comments so that the basis of your decision wouldn't be lost to a future engineer working on the code, who might then make the mistake of changing the algorithm, thinking your years of experience were unimportant because they had not been documented. Three years down the road when you are off at Google X working for Sergey on a space elevator, or Google Glass, or whatever, you aren't going to remember why the hell you picked a particular algorithm for a particular job.
So yeah, you may not value that interviewers input into the hiring process, but given what you've said, you would likely need to brush on these things you imagine are "stupid" before you'd be a suitable hire, for the reasons noted above. I have no doubt that someone who has worked for 20 years on a lot of cool stuff could do that.
You should be aware that other companies in the valley, either started by ex-Googlers (and it's easier to get VC funding if you are one), or those who are greedily hiring as many (sometimes ex-) Googlers as they can, are going to have similar requirements, due to the culture your interviewer comes from, or is attempting to emulate.
This isn't all wine and roses; there are some really terrible problems with the Google engineering practices that these people will have brought with them, as well, but realize that Google, for better or worse, is effectively homogenizing the valley environment so that no matter where you go, you are likely to see either a watered-down version of Google, or a poorly drawn characterture.
The people you know should contact their recruiters and inform them. This is probably unnecessary, since if it occurred, the internal checks and balances will have already pulled them from the interview rotation. In general, those questions would have shown up in the write-ups, and the hiring committee would not have been pleased.
They may want to make the effort anyway, and ask for a re-interview, if they actually want to work at Google. For a lot of people in a lot of ways, it's a fantastic place to work.
Cheaper labor doesn't get you the same amount or quality of work. Replacing one coder with three coders 12 timezones away doesn't get the job done 3 times faster either.
Didn't we just have this argument? How is the quality of work argument any more valid here, now that there are time zones involved? Do time sones have some magic deleterious effect on worker productivity that mimics aging?
The Communications Workers of America: http://en.wikipedia.org/wiki/Communications_Workers_of_America is a labor union for communications and media workers; if you read the previous link, you'll see that it's the largest, with about 700,000 employees under their purview.
I'm rather certain that software engineers don't count as communications workers, although I'll agree that communications workers are being displaced, as more and more telephone companies turn into providers of dumb internet pipes.
Now the fun part! For a typical salaried software engineer in California, between state and federal income tax, you re paying nearly 50% of your income in taxes. The average salary for an engineer at IBM in the US (average, meaning band 6) is ~$100,000/year. So that works out to $1,300/year in union dues, if they are successful, which is ~$2,500 of your pre-tax dollars, or double the 1.3%, were it taken off your net, instead.
But the really fun part is what 120,000 workers at IBM being unionized would mean to them: 120,000 * $1,300 = $156M/year in additional income to the union.
I'm guessing that these people are either used to dealing with people who are bad at math, unlike engineers, or they believe engineers are fairly gullible, and can be used as a replacement source of income, as their traditional milk cows run dry over time.
NB: For full disclosure, I was a band 9 engineer at IBM before leaving them, and the CWA picketed our offices, which were the offices of a small company which IBM had acquired, to try and unionize us, as well. They had not a chance in hell.
Slashdot Mirror
What Ubuntu did was very unsatisfactory. You still cannot easily compile your own kernel. What that ex-RedHat guy did was a lot better since you can load anything you want as long as you confirm your choice on boot.
Here is what RMS should be doing instead of this petition which is going to get nowhere:
1. Restart work on coreboot
Coreboot is still being worked on, I've personally done patches to it while employed by Google. It's even shipping on a number of ChromeOS platforms from a number of vendors. I think what you are advocating here is actually returning it to its original "Open Source BIOS replacement" role; I think that's unlikely for a number of reasons.
2. Make coreboot work with Windows and Linux as is
It's not going to work with a Windows that requires a UEFI boot, and Windows is moving in that direction. You can't buy new Windows XP licenses, and they are not patching the zero days on IE that will run on XP as part of discouraging it, above and beyond not selling XP licenses. So Windows that boots without UEFI boot and runtime services is quickly going to become completely unavailable.
The consequence of this is that in proposing a coreboot that can boot Windows by default, you are actually proposing replacing the current coreboot with an Open Source UEFI implementation. This is probably not workable, since vendors like non-disclosure from their BIOS vendors until they ship, and the ACPI implementation alone is so chipset specific that it would take a very long time to grow all the chipset support. To further hamper this effort, a number of the PMUs and other chips that get tied into here, such as the EC in laptops, and the EC firmware for each laptop, is also typically under NDA. Coreboot as a BIOS replacement alone, not even considering UEFI boot and runtime services, never really got that far, except on the Chrome OS devices and one or two vendors reference work for single motherboard SKUs.
For Linux, the Coreboot generally requires uboot on ARM devices, and Linux is somewhat hampered in adoption by the fact that the Linux kernel uses different device tree sources than the coreboot/uboot code. While it's technically possible, it's politically untenable.
I tried to get to the bottom of this while working on ARM on Chrome OS at Google, and from what I can tell, the device tree stuff dated back to the Open Firmware code for PPC machines, and there was an intentional Apple policy decision to make it impossible to identify specific cores. This prevented locking threads to cores, which in turn allowed the platform support code to take cores on and off line out from under the OS for power management purposes. So all cores showed the same ID. Linux power management is based on ACPI, and since ACPI is significantly primitive compared to the Mac OS stepper code (which is why Mac OS on Mac hardware gets significantly better battery life than Windows on the same hardware), losing the ability to lock threads to cores, which is a basic tenet of Linux scheduling and CPU groups, lost Linux features compared to other systems, without a corresponding power management benefit from adhering to the policy. So Linux built up an infrastructure that "distrusts" the vendor device tree information. For coreboot/uboot systems, this translates to "distrusting" the device tree compiled into them by the vendor compared to the one in the kernel (compiled from the same sources). Which is to say, it's all still there as a means of working around an intentional Apple design decision, and removing it is a political hot potato.
3. Convince more motherboard manufacturers to support coreboot
This is relatively easy, if you are willing to work in a private tree and not publish until after they ship so that your commits don't telegraph information to their competitors. Samsung and other manufacturers have enough trust that Google won't disclose prematurely that they are willing to trus
Look dude, I'm the one who tracked down the bug. I'm the one who reported it to all the UEFI BIOS vendors, and as far as I know, H2O is the only company which has fixed their implementation to list the code and data tagging to place that static library into the runtime services region rather than the boot time services so that it's not reclaimed out from under the runtime services by an aggressive OS page reclaim.
I know the specification, and I know that the implementation doesn't match the specification for almost every UEFI implementation out there. I know about the talks on attack surface, but that's not going to fix the F-ed up BIOS in hardware that's already out there, and motherboard vendors generally don't ship BIOS updates unless they pay the contracted BIOS company to do the work, and they only do that for problems which can't be worked around in software.
For the (majority) busted UEFI implementations, the workaround of delaying the reclaim of the pages until the memory call has been made leaves the attack surface open. Not delaying the reclaim of the pages doesn't close the attack window, it just moves it into whatever crap the OS has loaded into those pages rather than whatever crap that UEFI had there before the boot time services were terminated.
That aside, regardless of whether the busted UEFI leaves the attack surface there, the point is that, like POSIX conformance testing, when the spec and the code disagree, the code wins. Period.
This is the same problem the ACPI implementation has been suffering from for years: The vendor can make it totally correct according to the specification, or they can make it possible to continue booting unmodified Microsoft Windows distributions. The result is that the ACPI implementation never gets totally technically correct.
You can keep modding my posts down because you don't like their content, but it won't make the content untrue, or make that truth any less inconvenient for people like the OP who had problems getting Linux running on their UEFI based grey boxes they were trying to build themselves.
I've told the OP where to put the workaround in Linux, and I've told the OP where the bug lives in the UEFI implementation (good luck getting the vendor to fix that just for Linux, unless there's an offer to pay their BIOS vendor contract costs for doing the work, or an offer to buy a large enough number of units in a single order with the sale condition on getting the fix.
It'd be nice if the vendors fixed the bug so Linux didn't have to work around it, and it's also be nice for Linux if nVidia and ATI released the sources to the hardware acceleration portions of their drivers too, but that's just not going to happen without some serious $ changing hands.
I guarantee you that the bug report I filed with Apple (one of the vendors with a broken UEFI from using the broken Intel reference implementation) has been P3'ed as a "nice to have", and then moved to a component where it's not visible to most Apple engineers who could actually fix the problem, if they had a bug report to hang the fix on.
It isn't stupid, it is just buggy firmware. That's what is stupid.
Anyway... I use 64-bit Flash on Linux.
Actually, I don't think I have any 32-bit software installed on this 64-bit Linux machine.
You don't use it on Amazon, Google Play, our YouTube protected content. Flash Access isn't built into Flash, it's a plugin to the Flash plugin.
And you're right, it's "just buggy firmware", but unless you are running a post-July version of the H2O UEFI/BIOS implementation, you can't shut down the boot time services.
You appear to be unaware of the details of protected content vis-a-vis Flash; I shall try to lay it out for you:
Protected content sold by Amazon, and also by Google Play, is protected via Adobe Flash Access.
Adobe Flash Access relies on a unique machine identifier to implement the key escrow in order to lock your content to the download machine so that it can not be re-uploaded in a digital form without having to use the analog hole in order to degrade the content.
The way it obtains this unique machine identifier is by synthesis of a lot of different machine information via libhal (a library with an associated daemon, intended as a Hardware Abstration Layer). As you can easily see here: http://www.freedesktop.org/wiki/Software/hal libhal has been deprecated since May of 2008, yet Adobe chose to require it anyway.
This four-year-out-of-date library is not installed by default on Ubuntu systems, and doesn't give the answers Adobe Flash Access wants in order to be able to successfully run on 64 bit systems. Even when hacked up, there are typically symptoms during video playback, such as the video playing fine up to the first commercial break, and then after the commercial, the audio continues working, but the video is nothing but a black screen.
These problems do not occur on a 32 bit Linux, as they do on a 64 bit Linux running 32 bit software. The need to support multiple Linux platforms, combines with the Jan 31st 2012 rollout of the new version of Adobe Flash Access protection on content by Amazon no doubt influenced the decision, announced Feb 20 2012, to drop Adobe Flash Support for Linux outside official Google Chrome builds: http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html
Now that you have the context, do my earlier comments on 64bit vs. 32 bit make more sense?
It's only on 64 bit installs, and only because Linux use UEFI differently than all other operating systems.
The UEFI problems are well known to be a problem in the reference UEFI implementation not mapping a region of a statically linked library used in the UEFI implementation as being part of runtime services rather than boot services.
When 64 bit Linux *stupidly* shuts down the boot services, it unloads a number of pages of memory that would be used by runtime services. Then it calls into the runtime services to remap the memory map so that the Linux reorganization of RAM is known to the runtime services, and the machine crashes. Anyone with a JTAG who tried to track the problem down would have seen this.
I said "stupidly" because it's a few pages of memory they get by shutting down the runtime services, and it's only done in 64 bit mode, which means instead of gigs of RAM minus a few pages, you get a crash. The pages don't matter in the larger scheme of things.
This is also only a problem if you insist on using 64 bit Linux, which means you can't use Flash, Skype, or anything else that's 32 bit only, and your Linux ends up less compatible with all the content on the Internet than it usually is.
The fix is a couple line patch to disable turning off the boot services. And then to stop bitching that everyone copied the bug in the initial reference implementation, and refuses to patch their UEFI implementation to update it because of the cost and security issues that would raise.
And therefore having a serious Microsoft bias.
For what I gather, spaceX is mostly made up of ex-NASA people. From that it follows that spaceX probably did not invent the wheel, but simply copied and improved the one invented (and paid for) by NASA.
I expect that it's more of a case of "NASA won't let us build the cool vehicles we want to build, it makes us build all this expensive crap, and we get to do it for maybe three vehicles before we end up dead from old age; hey! Let's go work for this billionaire who actually has a vision of the future he wants to build, instead of these politicians and bureaucrats who don't get that roller coaster feel in their stomach every time someone plays the Kennedy moon speech..."
Personally, I'd rather work for someone with an actual vision beyond "let's send up some robots and get results in a decade and a half so we can justify sending up some more robots".
And that 1000-mile cross range capability is useful for space travel... how?
Landing away from the weather that would otherwise prevent you from landing before your life support ran out?
If you have differences in depth of field for your eyesight, particularly if you've had your eyes lasered into monovision
I'm not quite sure what you're saying. "Depth of field" is a photography tem referring to how much of a scene is in focus. A smaller aperture leads to a larger depth of field, and vice-versa. Are you referring to one eye being at a different focal length than the other? And if that's the case, you're going to be wearing corrective lenses bringing both eyes to the same focal length (or your eye doctor is incompetent).
No, I mean "depth of field", as in "everything in the 3D movie was in focus at the same time, which led to an uncomfortable viewing experience". The dumbass thing the cinematographer did was to do a 3D movie and computer generate it with everything in focus regardless of the virtual distance from the viewers forced perspective location within the scene.
Then you end up having problems seeing the 3D effect because theater 3D effects are generally achieved using either circular polarization ("Real3D") or horizontal vs. vertical polarization. This is because the polarization based 3D effect is achieved through forced perspective due to the eyes natural use of parallax to achieve binocular visions. This is also why you can't exceed 50% of the screen height for an apparent 3D projection.
And what do you mean by "lasered into monovision?" LASIK doesn't affect your stereoscopic vision at all, unless you poke one of your eyes out with the laser.
Yes, it does. Generally, if you start out with myopia due to curvature of your cornea, as you get older, you develop presbyopia as well as the lenses in your eye lose elasticity due to aging, and you end up with vision that is not normally correctible to perfect vision via LASIK. To combat this, and achieve the widest market possible for eye surgeries, a technique called monovision LASIK was developed, in which one eye is lasered for near vision and one eye lasered for far vision. The technique is similar to the use of bifocals, except it's per-eye. If your eyes are lasered into monovision, as in Monovision LASIK, as is described here: http://www.allaboutvision.com/visionsurgery/presbyopia_surgery.htm#monoLasik you end up still getting blurry in one eye parallax so your ability to judge distances doesn't end up damaged, you just end up with one eye being dominant for close vision, and the other eye dominant for distance visions. But it blows the hell out of your ability to see 3D in movie theaters using forced perspective techniques.
if your eyesight is bad enough you need correction in a movie theater in the first place, you are likely already carrying around a second pair of corrective lenses
Son, my eyes were 20/400 most of my life; extremely nearsighted. I couldn't focus farther than my elbow, but only had one pair of glasses. Sorry, but it sounds like you don't really have much of a clue what you're talking about.
Sounds like you never broke your glasses and had to drive some place to get them fixed. I've had a second pair available to me since third grade, and carry one in my car in case I'm out somewhere and my glasses get broken. Alternately, you've always had someone with you, or you take public transportation everywhere, but in either case, it's likely you have an old pair of glasses at home in a drawer "just in case", or you are not telling the truth about your level of myopia.
It's not just Lockheed. It's a joint venture with Boeing that Robert Stevens is presiding over.
And yeah, that's the same Boeing that ate McDonnell Douglas and killed the Delta Clipper program.
And most of it ends up getting spent in memory for unnecessary eye candy.
This is what the original article claimed as well.
If you have differences in depth of field for your eyesight, particularly if you've had your eyes lasered into monovision, then yes, I could see it being uncomfortable; however, that's easily solvable by not watching in a 3D theater or by using equal polarization in both eyes so you simply don't see the 3D effect at all, and get the same polar frame in both your eyes. And yes, such "2D glasses" do exist.
You can also get 3D prescription lenses, which, if your eyesight is bad enough you need correction in a movie theater in the first place, you are likely already carrying around a second pair of corrective lenses, since polarized sunglasses will back out one or both eyse when using an LCD screen at work, so what's yet another pair.
The place I've seen 3D truly failing has mostly been in movies that drop in and out of 3D, or have limited depth of field because it's digitally separate planes that have been poorly composited in post-production. In those cases, I hold the cinematographer responsible, which may be why he's feeling uncomfortable about the technology.
Specifically, last August, they required that the identities of file sharers must be turned over to rights holders.
So, for example, if someone posted a link to a file sharing site outside of German jurisdiction on their Facebook page, Facebook would be responsible for turning over the identity information for the nickname. At which point they would have a hell of a time complying with the court order to turn over the information they didn't have on file.
So, short of German tort reform, this severs their legal liability to shutting down the account in compliance with their Acceptable Use Policy, with the ability to reasonably claim ignorance that the person who registered the account did not do so in good faith compliance with said policy. The policy allows them to limit their legal liability.
Here's the Slashdot story on the German Federal Court of Justice ruling, which kind of trumps a decision by a privacy regulatory body with no actual legal teeth to contravene German Federal Court rulings, case law, or the German Federal law on which the ruling was based:
http://yro.slashdot.org/story/12/08/15/0043256/german-court-isps-must-hand-over-file-sharer-info
The bottom line is that the privacy regulator is likely to lose in a court battle because of existing laws and rulings which contradict them.
This allows outbound connections from Google to J-random-POP3-server to be reliably encrypted.
The other option would have been to permit you to upload, and cause Google to use, J-random-certificate for an outbound POP3 connection. However, doing this doesn't reliably achieve the "reliably encrypted" goal, since you could upload an intrinsically compromised POP3 peer certificate.
The reason for wanting the reliable encryption is that an untrustworthy ISP, government agency, or some with the capability of forging BGP could compromise the encryption with a MITM attack.
With the requirement in place, the eavesdropping agency has commit fraud, or obtain cooperation of the certificate authority, and should that become public knowledge, they would quickly find themselves untrusted by all major browsers.
The point, then, is that it is now impossible to cheaply and unobtrusively perform Great Firewall Of China or NSA-style "cast a wide net" operations on email traffic, or the type of warrantless wiretap of email that several recent US court decisions have said is "legal and not an invasion of privacy" for any email left on a server for more than 90 days.
If you start encrypting the email itself with S/MIME on top of that, you have an end-to-end guarantee that doesn't make the people using S/MIME "look suspicious, because if they didn't have anything to hide, they'd let us see it".
This type of thing is definitely a move in the right direction: drag the trusted CA's into it, and let them go out of business if/when they violate the trust place in them.
Apple is dying.
I, for one, will not believe it until the following two thing come to pass:
(1) Netcraft must confirm it; this is non-negotiable.
(2) You must be able to misquote, out of context, an email from Mike Smith, as to why he left; as of right now, Mike Smith is still working for Apple.
Only then will you be able to:
(3) Profit!!!
I stopped subscribing to physical newspapers as soon as their content hit over 50% advertising on the normal news pages, and they became nothing more than a cheaper-than-the-USPS method for distributing sales circulars and coupons.
Electronic publishers, including those for eBooks, and not just limited to "eNewspapers", have become nearly unreadable, because they no longer employ actual, human editors to correct spelling and grammatical errors; if I have to correct it in my head, that's work I'm doing that they should be doing before I even see it.
The eNewspapers are even more egregiously failing me than eBooks, since for non-fiction, their fact checking is seriously lacking -- not that the print versions are doing any better in this regard.
The profession of investigative journalism of the type practiced by Neil Sheehan, Bob Woodward, and Carl Bernstein is effectively dead in todays news media. The closest you will see is the occasional television journalistic "scoop", in which a whistle-blower has effectively handed the story to the likes of 60 Minutes, with a bow on it, and they ran with the story because it lacked sufficient controversy to get them in legal hot water.
A pay wall will likely not get me to read this eTripe any more than I already do, which is best characterized as "infrequently at best", and will certainly disincentivize me further if, on paying the fee, I find that there are still large tracts of ads fighting for my attention as they attempt to further monetize my already monetized eyeballs.
Look, morons, it's very simple:
(1) Provide your ad-blasted tripe for free
(2) Write stories that have more depth than their first sentence, or you will not be seeing me click through
(3) Hire some damn editors
(4) Clearly mark syndicated vs. non-syndicated content
(5) Let me have a try-before-I-buy time limited subscription without asking for my billing details up front; I do not have a business relationship with you unless I like you
(6) Profit!!!!
Do I think this model will work for you? Not long term, as the New York Times is in the process of demonstrating. So approach the problem a different way.
Personally, I would prefer that you just syndicate your original content through Google, and concentrate on that, rather than fitting it in the column inches of syndicated content I can get anywhere else I happen to look. Let Google or whoever emerges as "the one new portal" pay your syndication fees out of their ad revenue, and leave me the hell out of it.
You need to realize that you are not going to do ad serving better than Google does it. Just give the hell up now, and do what you can do better than Google (and do it before Google gets better at it than you are because you are running around with no focus).
And hire some damn editors. If my 6th grade niece can point out your grammar faux pas, you should damn well be able to hire someone with an English degree, whose other options for a career would otherwise be limited to either making more people with English degrees or asking me "would you like fries with that?" to fix your spelling and grammar.
Oh, and finally: some idiots blog doesn't count as news, so leave their publication to Blogspot, and stick with actual news, please.
It would be even better if there were tort reform capping the liability limits for malpractice, and if the same insurance company, or group of companies, didn't get five hits at the insurance trough for you going in for one MRI.
Is there a free middleware that would do similar things?
If the answer is 'no' (or if whatever there is isn't large enough to be useful,) then a developer has the choice of either using a closed service with a solid history or rolling their own and entering a very costly "not invented here" cycle with all of the attendant bugs and crap to deal with that could have been avoided.
Nobody's going to use a fly-by-night company to host important parts of their project to be sure.. but GameSpy and IGN have been around for years and years and nobody could have foreseen such problems 5-10 years ago!
The answer is "no". The GameSpy platform provided several things:
(1) Matchmaking
(2) Centralized storage of user generated content
(3) Cross-platform support
(4) Player statistics/leaderboards
(5) Discussion communities
(6) Centralized identity for multiple games
(7) Third party hosting
(8) Scalability
#1 is not actually that valuable, unless you are into PVP games; I'm not, but I could see it being an issue for a lot of the slop games that are out there.
#6 is more valuable to the players than it is to the game companies, since they'd want to tie you into playing them with no portal to other detinations, but it's a tolerable trade-off.
The rest of them add value, and aren't easily replicated. There certainly aren't open APIs for this stuff, as a single package, and a company that wanted to monetize as much as possible be silly to offer such a package for direct licensing, without them at least owning the comunities and the centralized identities for marketing purposes.
Guido wasn't 'here's a box for you crap, you have five minutes before security escorts you out the door" fired. It was closer to 'we don't see a role for you here, quit now and save us both the hassle of having to let you go' type fired.
He has really accomplished nothing since he was hired. And needless to say with Google actively replacing Python in the company with Go, he was acting like a petulant ass.
Google is a strange place to work. It's entirely possible that, by the performance metrics they typically use, it was a mutual parting of the ways; I don't know, and unless you are on the performance review committee for his engineering subgroup, neither do you (and if you are, you should be keeping your mouth shut, instead of posting here, even as an AC). But assuming your theory is correct, don't mistake an organizational inability to effectively utilize his talents with him not having them.
That said, your second paragraph is basically BS. Go never really caught on because it did not have a cross-platform library; the reason was that it insisted on directly trapping its system calls itself, which is great, if you aren't an engineer with a MacBook Pro trying to do work at home, and want the same system call semantics for e.g. "kill" or "sigaction". Hint: at the top of Libc on Mac OS, kill takes 2 parameters; at the user/kernel boundary, it takes 3 so the kernel knows whether it should use traditional Mac OS signal semantics, or use POSIX 1003.1-2001 semantics (same as Linux). Until they drop Mac OS X for Linux (probably still running on Apple hardware), or the Go folks fix their language binding to use LibSystem (Libc) instead of trapping their own system calls, I don't see that changing in favor of Go adoption any time soon.
While Go is an "official language", along with C/C++ there are two others, one of which is Python, and not a lot of work was actually being done in Go. My last major project at Google was exclusively Python, and all of the testing infrastructure for Chrome OS is written in Python. One of the first classes you are offered as part of new employee orientation, apart from "How to use Perforce" is "Python Programming".
Personally, I could see him leaving as being part of the generally publicly announced Larry Page effort to focus Google on working on fewer total projects, and on hiring for specific roles, instead of just hiring everyone who met the right level of smart, and figuring something for them to do afterwards. But frankly, I do not see increased focus fixing what Larry's attempting to fix with it. I suspect this is more likely than your theory.
Either way, I expect his contributions at Dropbox will be valuable to them, and wish him luck there.
You know, I always liked the system layout of the TI-99/4a
Me too. Having to jam everything through a 4K window made you write a lot more efficient code, instead of what we get today when people have free memory to waste on calculating frames that never get composited or displayed.
I don't know what you're still crying about.
Private health care has been a disaster, consistently going 0 for 4 on your list of, "lean, organized, efficient and responsible".
Private health care has been very effective.
Private health insurance, on the other hand, truly has been a disaster.
Pay the insurance company for health insurance, to pay your Dr. to pay the insurance company for malpractice insurance, to pay the hospital to pay the insurance company to pay for malpractice and liability insurance, to pay the lab equipment manufacturers to pay the insurance companies for liability insurance.
Private drug companies have also been a disaster.
Develop a cure: get paid once; develop a treatment: get paid over and over again. Microsoft didn't invent the subscription model, Merck , Sandoz, and others did.
He asked the questions because he was qualified to. It would be utterly absurd for an interviewer to ask you questions on the relative merits of different weave patterns for baskets, if the interviewer was not themselves an accomplished basket weaver.
The interviewer in question was likely chosen precisely because you had worked on a lot of cool stuff, in order to decide whether you had a broad general ability, or whether your focus in those areas had lost you your breadth. Someone who has to look up an algorithm, isn't going to look at a problem, generalize it to a class of problems, and then pull the appropriate most optimal algorithm for the problem out of their toolbox.
Even if the algorithm were in your toolbox (i.e. you were able to generalize the problem, pick the most appropriate algorithm, and apply it), and you just didn't have the stats associated with it (i.e. you knew it should be Vanadium, but you didn't know it was atomic number 23, or that it's electronegativity was 1.63), you would not have been in a position to discuss with code reviewers. Unless you can say why you chose that particular algorithm, compared to some other algorithm, by quantifying its relative merits (e.g. "it was O(N) rather than O(N^2)", or "algorithm X conserves space better than the slightly more efficient algorithm Y, and space is at a premium in this application"), then you would not be an effective member of the team.
Minimally, someone who was able to explain would have to follow along after you cleaning up the code and/or check in comments so that the basis of your decision wouldn't be lost to a future engineer working on the code, who might then make the mistake of changing the algorithm, thinking your years of experience were unimportant because they had not been documented. Three years down the road when you are off at Google X working for Sergey on a space elevator, or Google Glass, or whatever, you aren't going to remember why the hell you picked a particular algorithm for a particular job.
So yeah, you may not value that interviewers input into the hiring process, but given what you've said, you would likely need to brush on these things you imagine are "stupid" before you'd be a suitable hire, for the reasons noted above. I have no doubt that someone who has worked for 20 years on a lot of cool stuff could do that.
You should be aware that other companies in the valley, either started by ex-Googlers (and it's easier to get VC funding if you are one), or those who are greedily hiring as many (sometimes ex-) Googlers as they can, are going to have similar requirements, due to the culture your interviewer comes from, or is attempting to emulate.
This isn't all wine and roses; there are some really terrible problems with the Google engineering practices that these people will have brought with them, as well, but realize that Google, for better or worse, is effectively homogenizing the valley environment so that no matter where you go, you are likely to see either a watered-down version of Google, or a poorly drawn characterture.
The people you know should contact their recruiters and inform them. This is probably unnecessary, since if it occurred, the internal checks and balances will have already pulled them from the interview rotation. In general, those questions would have shown up in the write-ups, and the hiring committee would not have been pleased.
They may want to make the effort anyway, and ask for a re-interview, if they actually want to work at Google. For a lot of people in a lot of ways, it's a fantastic place to work.
Cheaper labor doesn't get you the same amount or quality of work. Replacing one coder with three coders 12 timezones away doesn't get the job done 3 times faster either.
Didn't we just have this argument? How is the quality of work argument any more valid here, now that there are time zones involved? Do time sones have some magic deleterious effect on worker productivity that mimics aging?
http://tech.slashdot.org/story/12/11/28/017239/silicon-valleys-dirty-little-secret-age-bias
Alliance@IBM = Communications Workers of America: http://www.endicottalliance.org/
The Communications Workers of America: http://en.wikipedia.org/wiki/Communications_Workers_of_America is a labor union for communications and media workers; if you read the previous link, you'll see that it's the largest, with about 700,000 employees under their purview.
I'm rather certain that software engineers don't count as communications workers, although I'll agree that communications workers are being displaced, as more and more telephone companies turn into providers of dumb internet pipes.
The interesting thing to note is that their dues are typically set to about 1.3% of your gross pay: http://www.cwa-union.org/pages/what_does_cwa_mean_for_att_mobility_employees , are not tax deductible, and get deducted from your post-tax pay.
Now the fun part! For a typical salaried software engineer in California, between state and federal income tax, you re paying nearly 50% of your income in taxes. The average salary for an engineer at IBM in the US (average, meaning band 6) is ~$100,000/year. So that works out to $1,300/year in union dues, if they are successful, which is ~$2,500 of your pre-tax dollars, or double the 1.3%, were it taken off your net, instead.
But the really fun part is what 120,000 workers at IBM being unionized would mean to them: 120,000 * $1,300 = $156M/year in additional income to the union.
I'm guessing that these people are either used to dealing with people who are bad at math, unlike engineers, or they believe engineers are fairly gullible, and can be used as a replacement source of income, as their traditional milk cows run dry over time.
NB: For full disclosure, I was a band 9 engineer at IBM before leaving them, and the CWA picketed our offices, which were the offices of a small company which IBM had acquired, to try and unionize us, as well. They had not a chance in hell.