Hacker News Reader

Comment by corry | Hacker News Reader

Your last point is the key point.

Any organization progressive enough to be using Google Apps for anything is unlikely a locked-down IE8/XP environment.

i.e. a venn diagram between Google App using orgs and IE8/XP lockdown orgs will have very little overlap.

This leaves a goodly number of Windows XP machines at one of my K-12 educational Customers unable to use Google Apps effectively. I suspect many other public schools will be in the same boat.

Chrome has design eccentricities that make it interact w/ some Windows management functionality (redirected "Application Data" folders, specifically) in a very suboptimal manner (maintaining 10MB+ of files in each user's redirected AppData folder is a problem on a server hosting 3,000 users' folders). Installing Chrome on the Windows XP machines isn't a slam-dunk.

I suspect we'll just have to bite the bullet and use Chrome while, simultaneously, giving up functionality in Windows to do it.

I hate to break it to you, but you could in fact update from Windows XP. I know it's hard to imagine. :)

My wifes school district just moved everyone to Windows 7. It takes 20 minutes for her computer to start in the morning and about five minutes to shut down in the evening. The computer just barely meets the minimum specifications of Windows 7 and so the district isn't going to upgrade the hardware due to budget constraints. Given tight budgets in schools I would be surprised if Windows 7 upgrades are actually feasible for some of them when Windows XP does everything they need on the hardware they already have.

How much of that 20 minutes consists of booting Windows, and how much of it consists of running the myriad policies, scripts, and startup software that "enterprise" environments push out to all their systems and run on every boot? Not exactly a fan of Windows, and newer versions often do boot slower due to added bloat, but you can't chalk 20 minutes up to Windows alone.

Hard to say, the last time I was there it was about half of the time to get to the login prompt and the other half to get to the desktop.

It shouldn't be that bad. I've seen university machines running windows 7 with less than current hardware and a whole bunch of scripts, antivirus, etc, and they still boot and shutdown in a very reasonable amount of times. Definitely sounds like the hardware rather than the myriad of scripts to me. Shrug.

1.6GHz AMD cpu with 1GB RAM with a 5400RPM 40GB HDD. It's really pathetic.

My God, people's cell phones are more powerful than that.

But conversely, there's nothing wrong with a computer of that spec, if you're doing web browsing, word processing and the like. It's just not being used efficiently.

And it was just yesterday when I stopped being a hardcore gamer and knowing about computer specs, and that spec wasn't half bad. Am I locked forever thinking that would be a decent computer?

I'm having the hardest time believing you said that with a straight face.

My phone has a 1.2GHz cortex a9 processor with 1 GB of ram and 32 GB of flash memory.

Something is very, very wrong with their environment, then. I've seen Win7 come up faster on HD netbooks with worse system specs than what you posted downthread.

I've not seen Windows 7 perform well on anything with less than about 2GB of RAM. I certainly don't doubt that district configuration has compounded what are mostly hardware issues. The point was more about what type of hardware some organizations are still using. In this case the machine handled Windows XP combined with the district configuration, slowly, but tolerably and after the upgrade has lost a significant amount of its utility.

Yeah, Win7 runs acceptably on my daughter's circa 2008 Asus EEE netbook with 1 Ghz proc. Don't know how much RAM it has though.

Windows 7 makes most hardware run better then XP unless it's really old. Really old means older then 2003. For example I have a horrible 2006 Compaq laptop that runs better with Windows 7 then it did with XP. I would have someone look at her setup because it could just be a faulty disk causing the problems.

They won't look at it unless it's completely dead. That is a side effect of budget constraints as well. It is usable, though painful, once it's up.

The school I worked at also upgraded to Windows 7, and it was completely fine. Things are quick and great. Remember that a school is meant to be teaching kids things that have at least some hope of relevance, so teaching children how to use XP is not exactly useful.

I'm talking about staff computers, not computers for childrens use.

So time to move to Linux! :)

Does Chrome Frame pose the same issue?

Not exactly. It would if we redirected the user's data. Since Chrome Frame isn't a freestanding browser, though, it's really not necessary to redirect the user's data. That's likely what we're going to end up doing, once we fully test it.

If Google got SSO to our SAML server working for Chrome Sync this would be a non-issue but, apparently, we're also the only people in the world that want that functionality, too.

You have a problem consuming an extra ~30GB of space on a server?

Yeah. 30GB of rather expensive SAS-based storage on a SAN. After having operating levies fail and seeing state funds radically cut we're pinching every penny we can. Every little bit helps.

I'd love to use something like ZFS to handle this storage, at which point this wouldn't be an issue, but I have to work under the constraint that various teachers acting as Windows admins need to be able to manage the servers. More money would solve this problem for me.

Money aside, it's galling that the developers aren't building for the enterprise deployment case. I WANT to run Chrome _badly_ in corporate environments but it's not engineered for my use-case.

It is, the installer you're looking for is just hidden very well. ;-)

You can find it by going to "Install Chrome for all user accounts" http://support.google.com/chrome/bin/answer.py?hl=en&ans..., which points to "Alternate (offline) Google Chrome installer (Windows)" http://support.google.com/chrome/bin/answer.py?hl=en&ans...

You want the "Alternate installer for all user accounts" (https://www.google.com/intl/en/chrome/browser/eula.html?syst...). That will install Chrome in the Program Files directory.

Or just go directly to http://google.com/chrome?msi=true - you can add others too (like extra=devchannel) if you have other options.

Sad how many people prefer to argue with their ignorance rather than a quick Google search.

I don't know if that's directed at me for not knowing to search for an "Enterprise" version of Chrome or what.

We're using the "Enterprise" MSI-based installer. We are seeing difficulties with it. It's storing large DLL files in each user's user data folder, which we're putting on a server so that user settings will "follow" them from computer-to-computer.

Firefox?

I believe there is a global version you can install that goes to Program Files and not AppData. Should help with your problem.

Last I heard, it was in Google Pack.

We are using this version and having difficulties with it.

While I respect the budget pressures of K-12, I'm not buying that an extra 10 MBytes/user on student-grade SAN/NAS storage is even measurable, let alone significant. Storage/Bandwidth cost curves have been remarkably consistent on their shifts over the last 20 years.

You might want to re-evaluate where you are focussing your energy on optimization.

Chrome has an MSI system installer that will meet your needs: http://www.google.com/intl/en/chrome/business/browser/

We also have full support for global policies and pretty much any administration features you could need. I'd be happy to point you in the right direction if you have specific questions or difficulties.

Policies for Windows, Linux, and Mac: http://www.chromium.org/administrators

We're using that installer, and Group Policy. We're redirecting the user's "User Data" folder into their roaming "Application Data". We're finding that Chrome is storing 10MB of DLL files there (gcswf32.dll being the big offender). We're also seeing the same behavior as described in this posting: http://productforums.google.com/forum/#!topic/chrome/xvd0gSJ...

Chrome installs a gcswf32.dll file into "Program Files" but it appears to be downloading a new one for each user, stashing it in their user data folder, then failing to load it properly on subsequent sessions because it's stored on a network path.

The DLL you're asking about is a component update. In this case, we used it to push an emergency Flash security update. These are stored in the user's profile because the component updater is built on top of the extensions subsystem. However, I expect the enterprise team can investigate segregating some of this from UserDataDir.

The thread you referenced should actually be resolved in Chrome 21. That said, it refers to a scenario where parts of the profile are remapped to a network share. It's important to understand that this is not a supported configuration for Windows profiles in general, and is known to break applications other than Chrome. Whereas standard roaming profiles should work fine in all applications, and are the configuration supported by Windows.

I've been down this road with other application development firms before. "Application Data" folder redirection is necessary for us because the roaming user profile grows an inordinate number of files in the AppData folder, which in turn causes logons to be _exceedingly_ slow when users logon to a computer that doesn't have a cached copy of their profile (such as computer labs where machines are frequently re-imaged, which is our pain point).

I don't know where you're getting the phrase "... this is not a supported configuration for Windows profiles in general". Unsupported by whom? Microsoft has been shipping Application Data Folder Redirection as feature of Windows Group Policy since Windows 2000. ) and not some kind of "registry hack" or unsupported (by Microsoft) tweak. I've yet to find any Microsoft developer documentation advising that this feature is "unsupported". I _have_ seen multiple applications broken by using this feature (including Microsoft applications) but I don't think that makes the feature "unsupported" by Microsoft. It seems like this feature is "unsupported" by applications because they make assumptions about how Windows behaves and don't engage systems administrators in their development process.

In the case of Chrome I _really_ want to use it in enterprise situations-- it's my favorite browser, personally. The attitude of installing into folders writable by individual users seems to pervade even the enterprise distribution of Chrome, however. I would argue that, in an enterprise environment, updates should only be applied to the computer's copy of Chrome and not into individual user folders. This creates pain and frustration for sysadmins. It sounds, to me, like the "component updater" doesn't take into account installs where there is a computer-wide copy of Chrome and needs some re-architecting.

Alternatively, we would be able to completely circumvent this problem and just leave the user's Chrome "User Data" folder in their local profile if we could use "Chrome Sync" with our SAML SSO that we use for Google Apps for Education. I haven't looked at it for 6 months, but the last time we looked Chrome Sync did not support authenticating via our SSO, so we had to scrap that idea and go with using a redirected user data folder to allow users to have their Chrome data "follow" them between computers.

Are there reason you can't use other browsers that are supported by Google Apps and run on XP? Say Opera, or Firefox?

Google Apps has been around for a while now. Its use is no longer all that 'progressive,' at least in my mind. I've worked with plenty of companies with FoxPro databases and ball mice that are using Google Apps.

Ah, FoxPro, tugging at my heartstrings there.

Reply on news.ycombinator.com