> github's infrastructure can't be compared to actual paid-for cloud hosting.
I think the idea in this thread is that since github is owned by MS, and they have Azure, that won't be an accurate statement for very long. Github doesn't have to build that infrastructure, they just need to competently integrate into MS existing infrastructure.
I can't believe I didn't piece this together sooner but I agree with this threads premise. I'm already hosting my source on Github so why not build it there? And if I'm building it there then why not deploy it there? Rather than manage a complicated pipeline, I just `git push` and everything else just works ... all the way to massive scale.
As someone who has worked on hand-built github to AWS pipelines ... I can actually see this being the killer feature Azure needs to actually win a large market share.
I use it daily for years and was shocked to find that it supports pinch zoom on iOS - but not android (where i use it).
Feels like it that's just tip of the iceberg re. things they could improve - for example they finally, finally!, added ability to create categories/tags for free (was paid feature).
I understand it's tough to run a business like this (and why google killed this, at least officially) - but i wouldn't actually mind an occasional ad.
I vaguely recall Apple getting the patent for pinch to zoom for a while, and not getting native support on Android after Apple lost it, and having to reimplement it for the longest time when doing things on Android.
Primary reason I switched back from chrome to firefox couple of years ago is for memory usage actually - got really tired of browser eating all my ram (with every extension and tab adding more and more usage).
And no, i rarely actually have enough free ram - it goes to better use.
I hope firefox handles this better than chrome - any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?
> any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?
"Sandboxing every thread" isn't exactly what Chrome does. Chrome provides a separate process for each browser tab. That, of course, requires more memory (since processes cannot directly share memory).
Firefox, on the other hand, uses a single process for the rendering for all tabs, but this process is separate from the main Firefox process. This means that the browser UI is still responsive even if one of the tabs is not responsive.
Of course, actual profiling may yield different results due to other factors that also affect memory usage, but ceteris paribus, using only two processes for n tabs should consume less memory than using n processes for n tabs.
This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.
I'd love to see a 'task manager' that can show CPU usage as well as memory use by individual tabs, because occasionally I see CPU use spike (noticed by laptop fans spinning up) and am reduced to closing random tabs in the hope it'll get better.
> This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.
My experience matches yours.
I think chimeracoder means that's the way Firefox works if e10s is enabled, which wouldn't be true for you unless you've explicitly done so. (I haven't enabled it either)
Actually, Chrome does process-per-domain. Almost always several tabs of the same domain will share a process. You can check this by killing one process and seeing lots of tabs go away.
No. We currently mostly do process-per-tab, but it gets complicated depending on how exactly a given window/tab was opened and certain resource heuristics. We're moving to process-per-origin[1], largely for the security improvement. But, that's been a huge, multi-year engineering effort that's only now approaching fruition.
Maybe the trick isn't to do process-per-tab or 1 content process and 1 UI process but to instead do some kind of "intelligent" number of content processes based on CPU and tab count? Like if you had 50 tabs on a quad core processor you could have 1 UI process and say five content processes?
Or another idea, have some kind of upper limit of memory a tab can use before it gets its own process.
That's likely what'll happen eventually. But we're starting with 1 content process because even that is a huge change and is going to cause disruption and will take a while to iron out the wrinkles.
I have tried and failed to buy X1 Carbon last month - i needed it to ship in less than a month, and their online ordering has no expedited shipping (not even an option, wtf?) and doesn't tell you when they will deliver it by (wtf??) and they don't sell X1 in any store in the area (wtf???)
I truly fail to understand this - the best laptop is not sold in stores, and takes over two weeks online. The other Lenovos are, but not that one.
I hope MS is better with this, but I don't have experience yet.
Have you actually looked at some of these benchmarks? For example, Octane contains "Code loading", sunspider has "code decompression" (not true code loading, but at least it does de-minification).
Of course it's important, and all borwsers are developed with this in mind - but it's not possible to create reproducable test suite (with a score given) that will test actual sites - sites change
They do talk about the chicken and egg situation, where top sites will optimize for engines, then engines optimize for sites... i.e. it highly depends on the sites - of course all browsers test on top sites and optimize for them. But then the cycle repeats.
However i wouldn't consider it for mission critical stuff - github's infrastructure can't be compared to actual paid-for cloud hosting.