bengoodger

Seeing the comments here talking about ancient codebases got me wistful for when Chromium was new and everything seemed possible.

That triggered a flash of feeling extremely old realizing we broke ground on this codebase 20 years ago this year!

United seems to like to hang onto extremely old airplanes even as the number of these disruptions mount. We can argue how statistically they're safer etc but these events are extremely unsettling and disruptive for passengers and frankly it's lucky no one's been killed yet. One of these planes dropped a wheel on a parked car at SFO last year.

It's not hard to notice there are other major airlines that generally maintain newer widebody fleets.

I too have nostalgia for a time when prices were reasonable, politicians didn't philander and children respected their elders.

And yet here we are :-)

For what it's worth, despite it being /en vogue/ to rag on Google, the Chrome team has some of the most talented and dedicated folks focused on building a vibrant and interesting web for most people in the world.

Genuinely curious - what do people want to see from a new/different rendering engine?

The web is crazy complex these days because it is an entire app platform.

The incentive for anyone building a browser is to use the platform that gives you the best web compat especially at the outset when you don’t have enough users of your app to be able to make big changes to the platform. Even Chrome didn’t start from scratch - it used WebKit!

The Chromium community has built an excellent open platform that everyone can use. We are fortunate to be able to use it.

Incognito clearly states how it works every time you start it, including what it doesn't protect against.

If we're saying that developers can't clearly and obviously state how things work, and are instead bound by however people think they work based on not reading anything at all, we're in a lot of trouble.

Though... can we at least then get rid of every intrusive TOS screen and cookie banner in existence? Because people click past all of those too without reading them.

netscape.public.mozilla.*

The hierarchy there was basically a reflection of the company's browser team org chart. You could find a group for every team working on the browser where many of them were having their regular technical conversations.

I'm about a half hour into this, and listening to Marc talk about newsgroups brings strong pangs of nostalgia. These days I'm a bit of a greybeard (salt-n-pepper beard?) of web browsing, but I remember getting started in the late days of Netscape, as a teenage open source hacker discovering all the Netscape engineers sitting on the npm.* newsgroups.. how wild it was to be able to turn up there with a question about the browser you used every day and have someone working on it answer! Netscape didn't survive, but what a legacy.

Have a BMW X5 with this auto-steer nonsense and have had several incidents where it's abruptly turned the wheel, where if I weren't grabbing it it would have caused an accident. Ended up disabling the assistant system.

Most Americans don't travel abroad. Those that are accustomed to frequent travel for business or leisure are acutely aware of the current situation because it's already blown up their year.

Quality can be worse in a long-time cycle project: - Engineers are motivated to slam their feature in, because if they miss the train the next one's not for 12 months. - You get one moment per year to connect with your customers & understand how well/not well your changes worked. This means either riskier things happen or that innovation slows to a crawl.

My 2 cents, speaking from some experience working on long time cycle projects and shorter cycle projects.

Is anyone concerned that even in the face of re-training, that two aircraft could find themselves in this position within the first year of operations?

Let's say you were on one of these aircraft and the pilots were able to recover. How terrifying would that be? This is the designed behavior?

It takes special effort to configure a variable width font in a code editor. I have to wonder if they do this to troll observant people like you :p

One maybe interesting anecdote.

May 2015, a few Chrome old timers reacting to the complexity of the code, decided we should try and build something new. This is nothing new for me personally (having worked on Netscape, Firefox and Chrome, and various false-starts along the way). We decided to design a browser based on a service-oriented architecture, using our new IPC and bindings tool (Mojo). This project was called Mandoline. We got a shell up and running that could complete some of Chrome's telemetry test suite. Performance was good. The architecture was clean. Problem was, the browser didn't do all that much. While a team of 6-7 people might have been able to build a browser 10-15 years ago, today browsers are just too complex (in feature requirements).

So our options were to try and convince the Chrome team (huge org) that they should drop everything and help us build this prototype into something real (unlikely, many past examples of failure of this kind of thing - see: Gecko transition/Netscape 6), or to find a way to bring this architecture into Chrome. The first not being a real option, we settled on the latter.

OK so you might ask - why labor under this delusion of building a new browser from scratch at all? Why not just stay within the confines of Chrome from the start, and look at the incremental projects that can be done to pragmatically improve things? My answer is that incrementalism should not be a destination or a goal. It's a tool that helps you get somewhere interesting. If you don't know where you're going, you're lost and incrementalism is just a delusion to trick you into thinking you're making meaningful progress. In the suffocating confines of a massive codebase, it can sometimes be hard to see the forest for the trees. It can be very valuable to step aside and try something else. Stepping aside can be creating a branch and hacking away liberally, or creating something entirely new. The other benefit of doing this is that it doesn't distract or further complicate the shipping product. But then bring the learnings back into the main line. And hopefully in your project you have leads on the main line willing to learn from such discoveries. On the Chrome team we're fortunate that we do.

So this is what we're doing now. We're bringing a service-oriented architecture to Chrome. A few of us have a pretty good mental picture in our heads of what the end state looks like (roughly) and we're using incrementalism to nudge the Chromium codebase there over a few years. The value in this approach is we get to validate our ideas against all the different platforms & features Chrome supports and test it on all of Chrome's users. It means if our changes land & stick that they really are by definition "good". By the end (if there ever really is one) we will have rebuilt much of the system architecture, while shipping every 6 weeks.

I was interested recently to read a similar story here about the plans in Firefox to integrate some of Servo into Gecko. The rationale was very similar. The reality is that you can't burn your user base by neglecting them while you build the massive new thing, or by expecting them to switch to something else. Instead you have to embrace the complexity & figure out how to work within it, while not giving up your dreams.

Chrome team co-founder/engineer/etc. here. Glad you found it useful! Some components like our net stack are particularly cleanly factored. Others have more room for improvement.

I would say that at the beginning of the project (2006-2008) we didn't have so much of a focus on platform design, just on shipping a browser as quickly as possible. Some of the abstractions from that era haven't stood the test of time as the project has scaled to many platforms, features etc.

Over the course of time we've had various refactoring projects to try and pay down some of the technical debt. The first major one was the "content refactor" from 2011. This led to the separation of the multi-process browser shell from the UI layer, which has allowed for other chromium-derived browser apps to emerge.

Today, we've observed that even this layer is a bit too complicated, so we're running more projects to try and modularize it a bit more. My mental model is that the browser is kind of like a set of system services for an ephemeral app runtime, and it's good to imagine what the APIs & separation between those things should be. To aid this we've developed a new suite of IPC tools which are way more useful than the original stuff we have used for much of the lifetime of Chrome.

Anyway this kind of thing requires an ongoing investment and a set of people who thrive on the art of API design and in grungy, challenging refactoring work. I probably have many more thoughts on this topic but this'll do for right now :-)

Throw some potato chips on there.

This seems kind of crazy to me. Why not just treat the touch strip as a second display? That would seem to afford a smoother integration.

My house is nearly 120 feet wide end to end, split across three levels. My wife & I use IM/SMS to communicate from the extremities. The struggle is real.

Have you seen the latest Civic? It's far less conventional looking than past generations. Electric car styling must reflect a desire from the target audience of small city cars, otherwise there wouldn't be a trend towards this aesthetic.

I look forward to someone discovering a line of discourse that'll de-antagonize the legions of Sanders supporters writing hateful comments across the internet. It is truly sick.

I've owned three cars with automatic cruise control for the past decade. This isn't exactly new technology, perhaps only at this price point.

The first car I had with this, an '06 Infiniti, was only able to slow to a crawl, not a full stop. So while it was useful on the highway it was useless in stop and start.

The second car, a '11 BMW, added "Stop & Go" to the formula. Great? Not quite. What would happen is that the car would come to a full stop, and then a timer would run, and if the car didn't start moving again within 10 seconds the cruise control would shut off, and to resume you'd have to push the pedal. This was especially maddening when stop & start traffic is inconsistent and the stops last 10.5 seconds. Basically the idea of being able to set & forget was completely undermined by this and driving with the feature on was more stressful than driving with it off and just doing everything manually. A complete bust. I don't know why it does this but I can see it being some combination of the product team needing to ship the feature in the state it was in, and legal requirements.

The problem with both of these implementations is that they promised to alleviate some of the issues with past "auto-drive" features (and you should consider Cruise Control to be the very first auto drive feature), but introduce their own. If you want the user experience of set & forget, you need very predictable conditions if you want any of these mass market systems to work for you, and unfortunately that's just not the way the roads are.

I think I have the feature in my latest car too, but I've given up and decided to enjoy manually driving, and just wait for fully autonomous vehicles.

I know most consumers don't really care about this stuff until it bites them, but products like this are supposedly (I guess) marketed to consumers who care about security. I think it's worth it to be skeptical of claims made by any vendor, and ask some key questions:

- what changes have been made in the fork? - can I (or people in the software development community) see the source code? - what peer review policies are applied to changes made in the fork? - when (not if) something goes wrong, what policies and mechanisms are in place to fix it?

... just to name a few. No software is perfect. No engineer is perfect. There will always be bugs. There should just be an expectation that people will take reasonable precautions.

I don't know if this is the case, but I definitely understand how it could happen.

Chrome's Incognito mode has the exact behavior of not supporting things like session restore and closed tab reopening. It's kind of annoying for those of us who occasionally use Incognito windows like a convenient transient separate profile (specifically "give me a different cookie jar because some site's login is broken"), but I think the loss of functionality is worth it given what the mode is actually /for/.

It makes me wonder though if it'd be worthwhile having a mode that gives you a separate cookie jar but keeps the browser settings otherwise identical (bookmarks, suggest, etc). I suspect the distinction is too subtle for most people however.

IMO it's foolish to think the laptop form factor is going anywhere, barring a fundamental shift in UX. Anything that requires productivity, e.g. content creation, is better done with a keyboard and some kind of instrument more precise than a finger. Any work involving accumulation of material from multiple sources (e.g. research) i.e. multitasking, is going to benefit from a larger screen form factor.

It's no surprise that mobile is eating consumption use cases as it means people can consume wherever they find themselves. But for the most part tablet UIs are just scaled up versions of phone UIs, even though individual apps may show more content laid out better with the additional real estate, multitasking and input don't work quite as well as laptops.

Funny story. I wanted to buy a cheap iPad for my son. I could have got one from Amazon but after hearing so many stories about scams or refurb devices or devices with someone else's state on it I decided not to deal with that headache and ordered direct from the Apple website.

Upon turning on the device for the first time it showed a screen saying it was controlled by the LDS Church and wouldn't proceed through guided setup until I acknowledged that. After some time on the phone with customer service, we determined there was no way to remove this configuration. I ended up having to return it to an Apple store. The rep there said "yeah that happens sometimes" (someone pulled from the wrong pile in fulfillment most likely). So sometimes you're damned if you do, and damned if you don't.

If anything Amazon's customer service is better - to resolve an issue like this for items they ship I don't have to drive anywhere, just put the box back on my front doorstep. I wish they would make it clearer when you're buying things from them, and would do a better job of associating compatible products. This seems like data they should be able to have, and UI they should be able to build.

To some extent. But we have a diversity of architecture in California, we're not all adobe mission huts and mid century modern homes. Old Palo Alto for example has a preponderance of 1920s/30s Tudor Revival homes, which really deserve an English garden.

IMO the issue here is really the ridiculously low cost of water. If someone wants to have an extravagantly lush lawn let them. But it's only fair that they pay through the nose for it. This makes it clear to consumers what their choice costs. Hitting people in the wallet is a far more effective way at changing behavior than lecturing people about civic mindedness which happens too often in California.

The irony is that a van will often handle better than a SUV with a car based platform and a lower center of gravity.

My wife has a BMW X5 and it drives like a piece of industrial farm equipment. We also own a Honda Odyssey which IMO handles significantly better - it's basically an Accord with a taller roof.

The lack of good data is really frustrating. The EPA adjusted the formula for mileage a few years ago which made things slightly better but I never come close to hitting the results in my car. Observed economy is related to personal circumstances, and in my case living at 700 elevation and traveling down close to 0 on a daily basis hurts my scores (along with tire lifetimes, etc). Another thing that bothers me is that performance cars are rated by the same standards, when the people who buy them undoubtedly drive differently than the people buying Toyota Yarises.

Anecdotal reporting online is a joke. You will find endless car forums with people boasting about how they consistently get 25mpg in their V8 sedan. Gimme a break.

What I'd love to see is some service/app that was able to gather real world data from owners of the same type of car in the same area as me along with general stats about their driving style. This would have to be automated to be accurate.

While we acknowledge some people might think they want this feature, it's been something we've been unexcited about helping them with it for the reasons stated. Having the ability to quickly deploy security fixes is fundamental to Chrome's ethos. This is as close to a point of religion for the Chrome team as you can get.

Many but not all things can be usefully parallelized. The build, and most unit tests and integration tests can, though we struggle with the latter where real hardware is required. Some performance tests are also run on real hardware. This doesn't scale as well.

Gramps was my first manager @ Netscape when I was hired after contributing patches through Mozilla. He is wickedly funny as were a lot of the rest of the people that worked there. One of these days I need to write down some of my recollections of that time.