I feel like it's slightly dishonest not to mention that (according to the Chrome devs) this problem is caused by poorly-behaved modifications to the Chrome installer made by third-party redistributors, and not by Chrome itself.
(Disclosure: I work for Google, but not on Chrome.)
It's true that based on the bug report linked in the post, the application bundle is modified by a 3rd party installer running as root. I still think Chrome should correctly handle the permissions problem with a warning or asking for root privileges to fix it, but I've updated the post to point out Chrome itself is not the origin of the problem.
> I feel like it's slightly dishonest not to mention that (according to the Chrome devs) this problem is caused by poorly-behaved modifications to the Chrome installer made by third-party redistributors, and not by Chrome itself.
What do you mean ? if I download Chrome from the official website I get a third party installer ? because I have the exact same problem with that very official installer.
It looks like the linked article has been updated at the end to clarify.
It sounds like some third party extension's installer (e.g. DivX) is reaching into Chrome.app and mucking with permissions (setting owner to root). Not sure why they don't install into "/Library/Internet Plug-Ins" (maybe it doesn't work with chrome anymore?)
(Edit: but a comment in the linked bug report suggests that this may also occur if Chrome is installed as one user and used by another.)
> I’m happily walking away from this with an extra 21GB in my pocket! And now I ask you: is your Chrome bigger than mine?
Given I don't have to rely on third party updaters, I doubt it. Let's see...
$ let size=0; dpkg -L chromium | while read path; do if [ -f "$path" ]; then let size=$size+$(du -sb "$path" | awk '{print $1}'); echo $size bytes, $(($size/1024/1024)) megabytes; fi; done;
172060669 bytes, 164 megabytes
$ du -sh .{cache,config}/chromium
8.4M .cache/chromium
25M .config/chromium
So the cache is 8M, config files 25M and program files 164M (listed by dpkg -L, then some command line magic to add up file sizes). A grand total of just under 200MB.
I made a simple firefox/chrome extension for people like you and me that horde tabs. You might find it useful to find tabs and quickly navigate to them by clicking on the link in the list. It's free and open source. The github page has a gif showing usage.
It sure it is... any idea what it should be? Firefox has a problem with re-assigning keys but in chrome you can change them inside the extension manager area. There's a bug filed for firefox to fix this.
Well it's part laziness (and priortising) and part working on an abstraction layer for the DOM API which can be quite hairy (it is known :P). So I have 10 windows open in total.
I have lots and lots of pages open of DOM documentation from many sources and many GitHub code searches to see how others' code deals with the mess. ~30% tabs are probably StackOverflow. The rest is (potentially useful) Google searches, programming blog posts and the usual pinned tabs (Gmail etc.).
I use a AutoHotKey script to make the scroll wheel switch between tabs (this is the default behavior on Ubuntu but I'm on Window), this way I can quickly scroll/look for the desired tab through an entire 100-150 tab window in 10-15 seconds. Thinking of this.. I would have probably indeed gone insane without the AHK script.. (or just kept fewer tabs opened instinctively? :P).
It was (in fact, it's not clear it was ever broken)
That's why if you look at the linked bug report, the only reports are of people who have used third party installers as root that screw up the permissions.
The bug report is basically "when i screw this up, chrome doesn't notice and fix it for me".
I'm not at all sure how this excuses things. If there is a known state that can be reached by the browser, then either a) indicate why it cannot be fixed and give tips for the users or b) put in the code to fix it for the users.
Root can modify the filesystem arbitrarily. To what extent should developers proactively scan their own files for arbitrary changes by 3rd parties? How much work should go into this, rather than fixing other bugs or improving performance?
According to the linked bug it is due to an issue to the DivX installer messing with the users chrome install. I don't know if the DivX installer on other platform experiences this issue but it sounds likely that it is only the Mac installer that has this issue.
If you're using packages on Linux, the package manager is responsible for uninstalling the old version. For example, yum/dnf on Fedora/Redhat will only keep one version of a package during 'yum update' (with the exception of the kernel, where the most recent 3 versions as well as the running kernel are kept to avoid breaking boot).
Even with 1TB disk space I'm resentful of the amount of space "leaked" by software. Maybe I'm a naz-, maybe I was born in the MB era.. can't say. The other day I booted a P3 era machine and seeing all we did with "just" 128MB made me feel chills all over.
I blame the perpetual-beta mentality along with lazy development practices.
Used to be, we specced out exactly what was in a release and no more. Now, it's just whatever they can cram in under a deadline without all that "unnecessary" optimization.
I'm probably as guilty as anyone else; I like getting a paycheck and so I keep my mouth shut, even though shit like that literally keeps me up some nights.
I see a few reasons: less compiled languages, more abstractions, more best practices, that means a lot of libs. I've seen Wirth pascal compiler, it's two files of a few hundreds of lines, but it's not decoupled in any way. Today most programs are larger than this because they compose lots of rules. It also brings false laziness, since you're not used to write short code, well you don't.
My girlfriend was given a macbook air by her parents, and after OS and her normal programs were installed (office, chrome and not much else) she was left with 5G. 64G SSDs were common not very long ago, disk space for operational components is increasing.
Perhaps. But my 128GB circa-2011 Macbook Air daily-driver is constantly full. As is my 256GB Macbook Pro work computer which has a 60GB Win7 VM just for running the VMware fat client and some Hitachi software.
With 500+GB I wouldn't care, because the media (photos/movies/etc) need to be stored elsewhere regardless.
This is embarrassingly bad. I know memory is cheap and mostly plentiful, but to have this as a bug for 5+ years is horrible. It's as though Chrome is going the route of web pages and not paying to the size of itself.
Embarrassing, obvious, multi-year bugs are common to all browsers though. In Firefox, bookmarklets on CSP pages have been broken for 3.5 years and counting, with the end nowhere in sight. A handful of bugs that have taken a while to fix is no way to judge the overall quality of the browser.
It's been a loooooooong time since I've seen the last useful bookmarklet in the wild.
Un-useful, however, was stuff that tried to hijack your FB/Twitter ("hey guys paste this in ur browser and get some n00dz in return"). The amounts of crazy stuff people do for supposed nudes or whatever is just astonishing
I have one in my work browser to redirect a journal’s website example.com to example.com.library.university.example.net in order to get the full access. Having a simple button for this made my life a lot easier, though I admit that it is somewhat of an unusual case.
Actually, no, the library-provided full-access website for APS journals is much nicer. If I want a preprint, I can usually find it on arXiv and last time I looked at it, I found sci-hub to have a rather confusing interface.
(Disclosure: I work for Google, but not on Chrome.)