> I find it difficult to get invested in Gemini because nobody will have access to Carbon for a few months anyways.
I feel like you're being overly dramatic here. Argon was 13 - 15 days.
Argon was announced September 30, made available on October 13 to Ultra everywhere, and Pro in the Gemini App. Pro plans got Argon on October 15 in AGY.
This is the first time they've slow-rolled a model. Who knows how long they'll wait on Carbon.
The Ultra-lite plans ($99/month) get some pretty good quota where you can actually use Argon some more. Maybe Google shouldn't be grouping together plans, but it should also be noted that $20/month also gets you 5TB of storage on Drive. If you paid for Dropbox, you get 3TB for $18/month (without any AI model usage).
If we go back only 45 days, Opus 5.5 was not even out yet. So for more than a third of the current SOTA model's existence, Google's response to it was under its own embargo. When it was finally out, paying users get 3-4 prompts a day, which means Argon will be experienced by a tiny minority of people, another unforced error on Google's side.
By the time Carbon comes out, I fully expect Anthropic, ChatGPT and/or a Chinese lab to have its answer ready to ship in less time than it took Google to approve a release.
Since you're a googler, can you trigger some internal process to improve the connection between google services?
Gemini cannot create "my maps". I like creating a map of stuff for travel and now I ask it to create an importable file (which it doesn't always get right) but it should honestly do that itself.
And I don't mean that from within the Gemini app, I'd like a shareable list of places, which you can do via a very outdated maps UI
This would be true if Gemini didn't already have some surface level access with Google maps. They just stopped short of supporting the feature I cared about
You also get YouTube premium and home premium on the Google ultra plan. I didn’t realize how nice it was not to see ads on YouTube, and the home summary of who walked next to my home each day is bizarre. The grouping doesn’t make sense at all, since I would have bought it anyways, but it’s a nice bonus.
Those integrations are my main reason of not trying it out. You get additional online storage and when your subscription runs out and you are over the limit you wont get any emails (at least that was what happened to me many years ago). What if some automatic chat classification goes wrong and google decides to close your account?
As long as there is no usable customer service and/or ways to limit the blast radius of incidents this is a nogo for me.
It's annoying that there is no way to just pay the marginal difference between Premium Lite and Premium for AI Pro subscribers. I have a bunch of interacting subsidies from Google Fi, Pixel phone purchases, and Google One AI Pro, but it's hard to keep them straight.
I have 160G of screen captures from Tumblr from my then angsty teenage kid. I think my spouse takes a few Gig of photos for each outing we go on. Several people dress for fancy thing via a process involving many clothes changes and even more selfies.
It’s hard to get interested in Google products because they throw them out all the time. If it’s not a step change in functionality why even go near their baggage.
They REALLY don't like AI, to the point of "wish I didn't need to rely on GCC and GRUB because they have AI in them" levels of hate AI. See this further down the linked page:
>The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to Libreboot. This is not mere conjecture; in said aforementioned U-Boot mailing list thread, the author stated thus. We will not, in any way, encourage or facilitate use of AI. It has been made clear that several projects Libreboot uses also have some AI-assisted commits; GCC, GRUB, etc. This is not our fault, but it is my intention that I and others will audit these projects in the future, de-slopping them and possibly even forking them entirely for that very reason.
I have learned to treat statements like that as a general red flag.
Someone who acts like a radical on practical issues will almost certainly act like a radical in other areas as well - including areas that matter to me.
There are debates to be had on every technology, but foaming-at-the-mouth kind of talk is a sure sign of a maintainer (and by extension a project) I want nothing to do with.
I respect projects with a no AI policy, but if that policy starts with the words “fuck no”, I’m out of there.
It's possible this type of "radical" behavior is why this project exists in the first place. I'm willing to bet if the Libreboot maintainer(s) were not "radical" they'd just be using a Mac and be content with a closed source bootloader.
Not to say this "radical" behavior is helpful, and I understand why people don't like it.
I don't really see it as a question of "separating art from the artist". That's usually invoked when other aspects of the personal life of the artist has the potential to distract from the art itself.
The parent comment is closer to saying that Picasso wouldn't have been Picasso if in an alternate universe he had avoided controversial/politically charged subjects like the Spanish Civil War and instead appealed to the lowest common denominator for a mainstream commercial audience to sell postcards.
AI in its current form is a commercial product created from stolen labor.
I think there are extremely legitimate reasons to be critical of that part at the very least, and I don't think it's a particularly "radical" stance within Free Software, which is fundamentally conscientious of such questions.
(I don't know whether the Libreboot authors have this particular point in mind.)
Has anyone who contributed to producing the wealth of human knowledge, art, code, and literature making up the training data been compensated in any way?
Well since the early 18th Century (in a limited way) copyright rights have been given to creators - the overwhelming majority of countries are signatories to international treaties (for the last 100 years) that give creators control of created artistic works (which has been deemed to include program code).
Exploitation of those rights is down to individuals, only since Google came on the scene has any company been able to get away with broad ranging infringement of these rights without censure.
As for your cheque, you have the right to sell your work. No-one is obliged to buy it, of course. You also, under copyright, have the right to make a license to exchange use of your works for binding the users to conditions of release of their derivative/associated works ([F]OSS licensing).
You still have the right to sell it, and if ML models have been trained on those works you have the right to seek compensation.
Is this something you've tried to figure out? I'd love to hear more from you here. Are you sure you're not just on a Plus plan? How much are you paying monthly? Are you sure it's the AI pro plan? What does Google One say? https://one.google.com/
Doesn't actually read the page, though. Or not what you see in the browser. For example right now, when I navigate to "reply" it doesn't read the comment I'm replying to - it's reading the login banner you get visiting a reply link without being logged in.
Workspace always gets things slower than normal Gmail accounts. They do a lot more to isolate data related to those accounts, so that's likely the cause here.
Anytime anything gets added to Workspace, I think Google has a lot more contractual obligations about keeping it around for X amount of time, so they tend to be more careful about adding things.
As long as you know the use cases of your fields, renaming is just fine. My team regularly does it. We also maintain our own serializer and deserializer json, XML, and fixed with formats. The json one we handle serialization using an annotation to say how it should be exported.
Of course, the whole concept of a breaking change does not really apply if all usage is within the controlled code. The problems start to appear when you have external users with old versions; then protobuf starts having a bunch of weird limitations. My favorite is that it's forbidden to move a field into or out of a `oneof`: it's a compatible change in a sense of wire format and JSON, but breaks the generated Golang code.
Breaking changes matter even with controlled code, because you can have requests that straddle upgrade boundaries, it's fiction to believe that all services are upgraded at the same moment, and pretending that is the case is the sort of thing that leads to quiet data corruption or mysterious bugs that can never seem to get reproduced.
Even if you upgrade with coordinated downtime across your entire service stack ( a bit old-school, but still happens more than you might imagine. ), then you still have to occasionally deal with requests that get persisted somewhere, possibly for support purposes, and it's much handier if the wire format remains compatible, at least between immediate versions.
Yes, breaking changes need to be staged carefully/compatibly across versions.
Simple renaming/reordering is not a breaking change between code versions. The wire format knows numeric ids, not names. It breaks code compilation until the renames are put into effect. There is a subtle breakage where someone renames a field (think: field -> old_field) and then later adds "field" to mean something else; software that isn't recompiled in this window might not recognize that "field" is potentially different. Uncompiled languages may suffer this even more subtly. -- All of this to say, breaking compilation is not the end of the world but there are more dragons as the scope grows.
Stop-the-world is usually only needed when someone has made an unplanned/incompatible change with versions that are still running. If your infrastructure+development is done right (hah) this should never happen.
> Wait — I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from CONTEXT.md.
Piper is built on lots of other tech like spanner and chubby and many others. And some of those have specific hardware requirements that only exist in Google datacenters. Untangling that web of tech is neigh impossible (or not something worth the cost to leadership).
Why is that a problem? They sell Spanner on GCP. Sell Piper as well! It's obvious as shit but Google doesn't know what it's doing anymore. They should have bought GitHub, not Microsoft, and then we wouldn't have had the problems with scaling GitHub either.
Piper only works with CitC. Which is effectively a virtual file system when mounted locally. And when you have a monorepo that big, standard tools that want to scan an entire directory will stop working. Every part of the developer tool chain has to change to deal with code base that big.
I agree that Google should have bought github. The tech they built to scale Google Code I think would have helped a ton with GitHub.
reply