Live data from Hacker News

Chrome browser for businesses

enterprise.google.com

141–150 of 282 posts

Re: Chrome browser for businesses

#141

Oh cool, a version for corporate rule fetishism admins who love controlling their MSI files. Happy I don't work in such an environment.

when the MSI file defaults to sending crash dumps that may contain confidential financial information, to a server located in the developers broom closet, yes, we have to control the MSI files.

Because admins have to answer to the auditors(and our conscience) when they ask the question "How do you ensure that personal and confidential information is not leaked from your environment"

Which is why Windows 10 is my worst nightmare.

Re: Chrome browser for businesses

#142
post #93

For me Chrome is already the new IE: good enough to saturate the market to the point where devs stops caring about standards compliance. Personally I have tried to like it, multiple times but I always get annoyed and go back to FF. But then again I prefer Linux over Mac and Netbeans over IntelliJ so maybe it's just me.

I used to switch between Chrome and Firefox all the time before finally Chrome won me over with the most convenient cloud sync for bookmarks, passwords, etc.

Password sync in browser is a piss-poor password manager solution. You should just use a password manager

Re: Chrome browser for businesses

#143

Earlier quoted context omitted.

Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app. I was once involved in an IE6 -> IE8 upgrade for a Fortune 100 corporation. It took nine months to analyze all the possible impacts and implement mitigations before…

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to co…

It's not just engineering/R&D that makes this decision. IT departments generally have the last word on what applications (browsers, for example) will be supported. A real life example:

I worked on a team that maintained a data portal website used by major pharma companies and clinical research organizations. It had to be IE7-proof for a very long time because many of our largest clients were still running very old browsers internally because of IT rules. Our R&D team would have loved to drop support for these antiquated browsers, but, shockingly, our sales and operations teams were not willing to tell multi-million dollar clients that they better upgrade their infrastructure or they couldn't use our software.

Re: Chrome browser for businesses

#144
post #66

Earlier quoted context omitted.

Firefox dev tools are sometimes painful to use and lacks some important features which Chrome's has. Some examples: - debugging with source maps: it doesn't work properly (I can set breakpoints and debug variables content on typescript files in Chrome, but not in FF) - JS exceptions: clicking on the filename inside the stack opens a new window with the source of the JS file, not the debugger (ugh) - doesn't support t…

Did you try the Fx DevEdition? I know of some recent Source Map related changes. If the issue persists (same with the other issues you mention), would you mind filing a bug [1]? [1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c...

Yup, I tried FF Dev Edition a month ago, same thing. Maybe I will try again later after updating

Re: Chrome browser for businesses

#145

Earlier quoted context omitted.

It's amusing how we see web apps as the solution to deployment woes. I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks.

I think it became harder to write true desktop apps once VB6 was killed off in favor of .Net with its higher learning curve. As bad as a real language VB6 and it's GUI builder were, it did allow even amateurs to write a decent working crud app in minimal time.

I still think VB6 was the pinnacle for writing line of business CRUD apps. I've been told there are still some VB6 apps I wrote ~15 years ago running at a big enterprise I once worked for.

Re: Chrome browser for businesses

#146
This is a big negative for security. The best thing a sys-admin can do is blindly click okay every update.

Out of date web browser bugs are pretty much THE mainstream hacking route. It is the route of least resistance.

Re: Chrome browser for businesses

#147

Earlier quoted context omitted.

Companies have far too much internal plumbing to permit browsers to auto-update themselves. Being feature-compatible with the latest SV-poster-child website is insignificant compared to maintaining stability for the tax-management team's internal web app. I was once involved in an IE6 -> IE8 upgrade for a Fortune 100 corporation. It took nine months to analyze all the possible impacts and implement mitigations before…

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to co…

> That has never been true.

Sure it has. When software existed on physical media and there was a real, material cost with distribution of software, there was absolutely a done state. Waterfall software development and actual requirement control would clearly define done states. That's not to say that there weren't bug fixes and updates, but it was (and is) possible to define what an application should do, code it to do so, test that it works, and ship it. But the world has changed, software has become easier to develop and distribute, and software development methodologies have shifted to where we don't have to have a done state in the same sense that we used to. I don't think it's a coincidence that we got agile development after the Internet.

Re: Chrome browser for businesses

#148

Earlier quoted context omitted.

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to co…

> That has never been true. Sure it has. When software existed on physical media and there was a real, material cost with distribution of software, there was absolutely a done state. Waterfall software development and actual requirement control would clearly define done states. That's not to say that there weren't bug fixes and updates, but it was (and is) possible to define what an application should do, code it to…

Definitely true, now video games on discs are manufactured completely broken or even mostly empty and they make you download 50gb on launch day

Re: Chrome browser for businesses

#149
post #93

Earlier quoted context omitted.

I used to switch between Chrome and Firefox all the time before finally Chrome won me over with the most convenient cloud sync for bookmarks, passwords, etc.

Password sync in browser is a piss-poor password manager solution. You should just use a password manager

Why is password sync in browser bad? Care to explain? I hate to have another password application; Dropbox sync t everywhere. Remember Firefox sync encrypts everything before upload. So does chrome.

Re: Chrome browser for businesses

#150

Earlier quoted context omitted.

But (most) browser apps are single threaded and you can block the UI if you do anything intensive on the client-side.

There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly. Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.

Those are relatively new features, and aren't used a whole lot.
Post reply on HN