I think it depends less on workflow and more on screen layout. If you run your browser maximized on a landscape-mode display, there's a lot of horizontal real estate that isn't very well-used, while vertical space is at a premium. So it makes sense to move tabs to the side.

On the other hand, if you don't maximize your window but keep it as narrow as possible (so you can see other windows) but just wide enough that sites render well, then you'll probably prefer them on top.

On the gripping hand, if you're like me and run your browser full-screen on a portrait mode screen, then you have gobs of vertical real-estate and tabs on top definitely makes sense.

(I have three monitors, a 32" (landscape) in the center, which is where my IDE, editors, and "focused" work lives, and a 27" portrait orientation monitor on each side. The left one has a full-screen browser window for work stuff and the right one has a full-screen browser window for personal stuff. It's fantastic.)

Mmmm.... if anything it's "what the Google engineers want emphasized". Executives at Google have surprisingly little control over technical decisions. For nearly all of Google's existence it's been an almost completely bottom-up driven company and while in the last few years management has been trying to exert more control it's a very, very slow process.

It's actually the engineering-driven culture that produces Google's infamous tendency to abandon products. Stuff gets built because some engineers think it's a good idea and convince their managers to let them run with it. Then eventually it gets boring and engineers tend to wander off to other teams in search of something interesting. If the product has managed to achieve significant userbase and/or revenue stream (and keep in mind that both are measured on Google scales; so anything less than 100M users or $1B/year is "not signficant").

In a top-down company products don't get built until they have significant executive support, which requires a fairly detailed plan, which gets executed and adjusted, and if an exec's project is in trouble it will get support. At Google products kind of wander out the door and into the world and if they happen to be a hit, great, if not, well, unless there are legally-binding contracts obligating the company to support something, it just gets shut down. Even with the projects that the executive leadership are really excited about (like AI!), their influence is mostly limited to shoveling resources at it.

Anyway, the point is that execs likely have little to no influence on Gemini training beyond setting very broad guidelines, and even those might not have much effect.

That's a strong statement. Can you explain why that isn't also true of human brains? What's the intrinsic difference?

But was that figure provided by AI?

Even if not, we all know that 793% of all statistics are invented.

If something is inaccurately presented as being the truth, then it is a lie of omission because it is dishonest about the fact that the information isn't actually known.

Gemini is exceptionally bad, as LLMs go. I really have no idea why it is so dreadful, even compared to other LLMs. It isn't context window. and it doesn't seem to be training material either.

Cyber Implications have been noted. Mondas security is to be Cyber Vibed until we have Cyber Security capable of defeating The Doctor.

When I test the different AI systems, Google's AI system loses track of complex problems incredibly quickly. It's great on simple stuff, but for complex stuff, it's useless.

Unfortunately.... advice, overviews, etc, are very very complex problems indeed, which means that you're hitting the weakspot of their system.

I've designed a few machines - some rather more insane than others - in meticulous detail using AI. What I have not done, so far, is get an engineer to review the designs to see if any of them can be turned into something that would be usable. My suspicion is that a few might be made workable, but that has to be verified.

Having said that, producing the design probably took a significant amount of compute power and a significant amount of water. If I'd fermented that same quantity of water and provided wine to an engineering team that cost the same as the computing resources consumed, I'd probably have better designs.But, that too, is unverified. As before, it's perfectly verifiable, it just hasn't been so far.

If an engineer looks at the design and dies laughing, then I'm probably liable for funeral costs but at least there would be absolutely no question as to how good AI is at challenging engineering concepts. On the other hand, if they pause and say that there's actually a neat idea in a few of the concepts, then it becomes a question of how much of that was ideas I put in and how much is stuff the AI actually put together. Again, though, we'd have a metric.

That, to me, is the crux. It's all fine and well arguing over whether AI is any good or not (and, tbh, I would say that my feeling is that you're absolutely right), but this should be definitively measured and quantified, not assumed. There may be far better benchmarks than the designs I have - I'm good but I'm not one of the greats, so the odds of someone coming up with better measures seems high. But we're not seeing those, we're just seeing toy tests by journalists and that's not a good measure of real-world usability.

If no such benchmark values actually appear, then I think it's fair to argue that it's because nobody believes any AI out there is going to do well at them.

(I can tell you now, Gemini won't. Gemini is next to useless -- but on the Other Side.)

This means you shoud NOT, under any circumstance, run Claude at 88mph. Unless you really want to.

Artemis II is breaking Apollo 13's record by about 4100 miles. The primary reason they're going further is because they're passing much farther from the moon, about 4000 miles, compared to 158 miles for Apollo 13. The moon is also a little further from Earth, accounting for the other 250 miles.

Agreed. I live in the mountain west, and our forest and mountain landscapes are just covered with fencing, even though most of it is public land, because it's BLM "multi-use" land -- a lot of cattle graze on it. Fences are expensive to build and expensive to maintain. If you think a fence is something you build once and then ignore, you've never dealt with cattle.

Cowboys (and sheep herders) have a term "ride fence" as in "Bob, you're gonna ride fence today", and it's a regular and tedious task that means "get on your horse (or ATV) and ride past miles and miles of fenceline, looking for places where the fence is broken or going to break, and fixing them". It's necessary and expensive drudgery and having all of those fencelines is bad for other uses, and bad for wildlife. I've put down a few deer that jumped a barbed wire fence and didn't quite clear it, slicing their guts open and leaving them in agony as they slowly die.

In addition, there's an obvious tension between the cost of building and maintaining fences and the cost of rounding up cattle when it's time to move them. Obviously if you slice the land up into lots of small fenced areas, the cattle will be easy to find -- but they're also going to graze it out fast, so you're going to have to move them more often. If you use very large enclosures (common on BLM land), then your cows may have hundreds of square miles to roam and feed... but when it's time to move them you have to find them. Luckily they're herd animals so when you find a few you've found them all, but still. And occasionally, singles get separated from the herd and you just lose them, which isn't great since a cow is worth about $2k.

So... if we can replace those miles of expensive and constantly-breaking fences with virtual fences, that's good news for everyone. Wildlife and outdoorsmen can roam unimpeded, cattle can be far more tightly controlled, strays quickly identified, located and reunited with the herd -- via remote control!. This is an innovative idea that is worth quite a lot.

Does it actually bog down a reasonably-speced computer? I don't think it does, I think the sluggishness is just from the sheer volume of stuff that has to be downloaded, and the inefficient way it's downloaded. And the reason the web devs don't notice the awfulness is (a) their browsers have 98% of it cached and (b) they have a GigE (or 10 GigE) connection to the server. They certainly don't have computers faster than your M4.

I think you didn't understand what this feature is. It's pretty much the opposite of annoying, and it has no effect at all on bandwidth consumption. Though I suppose when devs get used to their sites seeming to load faster they'll bloat them up even more...

I was hoping at the bottom of the article it would say that Professor Utonium accidentally added Chemical X.