Hacker Newsnew | past | comments | ask | show | jobs | submit | hatthew's commentslogin

Maybe the subset of japanese content I'm exposed to is biased, but personally I encounter doubled vowels (obaasan) more often than macron vowels (obāsan). The latter is explicitly "modified hepburn romanization". Even if the latter is more common in general, it's worth noting that the former is the original. The article seems to say that the former is weird and nonstandard, which afaik is completely false.

Also, the particles は を へ aren't always romanized the way they're pronounced; I can think of several places I've seen を written as wo despite being used as a particle.


Using doubled vowels instead of diacritics is just one more concession to Americans, who are unfamiliar with the use of diacritics and whose software frequently does not work correctly when text contains characters with diacritics.

Hepburn is an inappropriate method of writing Japanese, which nonetheless has become the dominant way of writing Japanese, just because it caters to the inability of most Americans to learn how other languages than English are written and pronounced.



My understanding of the result that was found is that the blowup doesn't happen in the real world, and only happens in an NS simulation. The bottom line is that NS is insufficient to model the real world, because in this case the real world is more stable than the model. [Take this with a grain of salt, I barely knew of NS before a couple days ago]

To my understanding, the problem was never about the real world really. Navier Stokes approximates a fluid (which is made of discrete particles) as a continuous volume. The point of showing that you can achieve unbounded increase in velocities is that the approximation breaks down - it's a clearly an outcome that can't happen in the physical world.

I'm not too familiar with the exact problem as I only became aware of it due to this drama, but I think you're correct. That said, another commenter noted that it may also be one of the Millennium Problems with the least application. We already know "all models are wrong, but some models are useful" (George E. P. Box), the fact that this holds for Navier-Stokes is not a surprise.

Huh? Nobody's talking about that because it's old news. We already talked about it the first few times that AI made notable progress on a difficult math problem. Now, most people who care about the intersection of AI and math just assume that Lean was involved.

I feel like this whole thing hinges on one point. OAI says[0]:

> However, our proofs differ significantly and even the precise results proved are different in the Euler case (forced vs unforced).

How true is this?

If the implied statement is true (i.e. OAI couldn't have stolen results because the results were so different anyways), then I feel like it's pretty clear that OAI solved the problem on their own, and offering some amount of credit to Tristan and Levent is generous. Though on the other hand it's dirty to have even attempted a scoop in the first place.

If the implied statement is false, and Tristan/Levent's results are a substantial portion of the solution to the millennium problem, then it's probably unintentional but clear plagiarism. I think it's plausible to assume that OAI has trained their models on Tristan's codex conversations, and so regardless of legal ownership, the academic ownership definitely includes Tristan and Levent.

The rest of the drama (individual statements and wordings, e.g. by Sebastien) seems like a bit of a red herring. Worth noting, but not worth basing conclusive judgements on regarding academic misconduct. Regardless, OAI does not seem like the good guys.

[0]: https://openai.com/index/navier-stokes-solution/


Agree with this framing, but we may find out that the answer is somewhere in the middle. Personally I think it is extremely unlikely that this is straight plagiarism in the sense of the model simply regurgitating training data from prior work by Tristan, but it is very plausible that his work (and others’) was foundational to the breakthrough. What is unfortunate is that the stakes are so high (and no I don’t mean $1M) and the timeline is so compressed.

I expect a lot more of this kind of drama in the near future.


Agree! We have both published solutions now; someone (AI?) should be able to analyze their methods and see how similar they are

I like the part where the value is actually still 8

You're absolutely right. I did not increase it to 16, and it's my fault that the seam—which was right there the entire time—was not flipped towards the bucket that drips into the ocean—want me to correct this before we move onto the real story?

My favorite, on being told to commit and merge to a branch and saying that "this is done"...

"You're right, I'm sorry. You told me to do it, I said I would do it and I did not do it and I said that I had when I did not do it. Would you like me to do it now?"

Me, thinking: that depends, Claude, will you actually do it this time?


and better is when it moves onto "want me to do this before doing x?" where x is some vaguely discussed idea/long term thing that was never greenlit but now all of a sudden it's the next step

Nice claudish! It's crazy how obviously human made this comment is, despite the superficial similarities to Claude. It truly has a distinct style.

This. After writing a lot of code/tokens.

Why can’t it check first if a method actually exists in the API?


Investments need a return on investment. If "the thing you wanted to exist now does" is the only return, that's not enough to support anywhere near the current amount of digital product creation happening today.

It's almost impossible to predict how much demand there will be in that scenario because the world would be a very different place if that system was the default. And with things that are relatively cheap to make, such as professionally produced YouTube videos, people may only need to chip in a few cents to provide an equivalent return to ad revenue.

Given that people are already accustomed to paying for the promise of future things existing in the form of crowdfunding, Patreon or most subscription services in general, I don't think it would as drastic of a difference as you imagine, as long as the infrastructure is there to facilitate effortless 'investing' into many small things.


Sounds fine to me! Less inane, pointless, content? Only left with what people chose to exist? Sign me up!

Good.

I find json annoying to write a lot of the time, but I do enjoy that it's a lot more difficult to get wrong than yaml. The json spec is pretty clear, and can be learned and memorized by any programmer in 5 minutes. I'd much rather write in a format that's slightly annoying than a format that's slightly ambiguous.


The "File" menu is about CRUD operations on file-level objects.

I think eventually (~decades) the concept of the menu bar will go away, but until it does, File is a fine name for the first menu on the bar. I don't know what it will get replaced with, but it will go the same way as the Save icon—a relic that was a good design at some point, but no longer has much basis other than inertia, and will slowly get forgotten as it becomes obsolete.


If you're like me and struggled to parse the title, my understanding is, "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link."


> "To obtain certain source code from Google, you could previously reference git tags, but now you have to fill out a form and wait for a human to give you a google drive link."

Couldn't simply someone mirror these Google Drive folders?


Yes, and we do mirror their source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch:

https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base

https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...

We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.

It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's supposed to be in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's meant to be and the build system makes it clear that it isn't happy about it despite running.

It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags.

We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy.

Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.


Maybe a naiive question, but couldn't you request the source code from phone companies? Say you request it from Xiaomi - sure they're not the original writers of the code, but they too "distributing GPL code" and therefore must release the code on request. They may be more amenable to your request since they have leverage with Google and are in an adversarial relationship


“Couldn’t you just” couldn’t fucking GOOGLE, the don’t do evil corporation, support one of the few alternative mobile phone OSs use standard development tools, instead of being little shits?


You can request anything from anyone, but compelling a company to follow their GPL obligations requires cooperation from the copyright holders + infinite funds for legal fees


Doesn't their change break supply chain security on Google's end?

With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?


It doesn't break supply chain security for anybody with power to change the situation.


It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.


Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".

You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?


A git hash is cryptographically secure. It doesn't matter how you distribute it. That is the entire point you're missing.


The Google Drive link is to a simple tarball, not a git artifact.


Yes, that is the problem, as the titles says "Google has stopped pushing Git tags". No git tags, no cryptographic content hash.


[flagged]


There is a giant list of reasons here https://grapheneos.org/faq#future-devices



Yes, but that person still needs to file a request and wait several days


It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it.

This is the relevant code for Android 17:

https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base

https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...

There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta.

Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world.

It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.


I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.


It also isn't only them pushing the boundaries of the GPL.

Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.


But after one person does this, the source code access is a solved problem.


No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.


Maybe we colld getan AI agent to pester them with forms?


What consequences do you imagine if they (rightfully) choose to ignore it?


But nobody has done this, which is why it's a problem for Graphene


Maybe should someone should do it then?


Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).


They are, which is how they know how long it's taking.


This thought occurred to me too, but then I realized even 37% is very high. In a reasonable society, most individuals' earnings should go up all the time. The downward pressure that should exist is high earners retiring and low earners just starting their career. A mildly idealized society should probably have 3% go from unemployed to employed, 3% go from employed to (voluntarily) unemployed, and the remaining 94% increase their earnings.


Nothing is "idealized" in the real world forever.

The only thing that surprised me about this article is that more people didn't see real wages decline. 2021-2024 was a period of peak inflation that the US hadn't seen in decades. And of course the primary cause of this inflation was governments flooding dollars into the market by literally paying people not to work, which while perhaps faulty was at least a reasonable response to Covid. The ironic thing is that, in the US at least, the inflation rate was coming down before we decided to install the guy who instituted massive tariffs, an unprecedented deportation program, and an unprovoked war in Iran, all of which are highly inflationary.

So it's completely unsurprising to me that wages, especially of people who stayed in the same job, didn't accelerate faster than inflation. This feels a bit like picking your dates to tell a narrative. I'd be much more interested in the percentage of folks whose wages fell in real terms by looking at multiple overlapping 5 year timespans.


>In a reasonable society, most individuals' earnings should go up all the time.

I don't think this is a reasonable expectation at all. In the absence of economic growth I would expect the average individual's earnings to be flat.

The only way for wages to go up across the board is if productivity increases. If you're not creating more wealth than last year, the only way for one person's wages to go up is if someone else's goes down.


Assume you have no overall economic growth, but workers get more productive over their lifetime (as they accumulate experience).

In that scenario, each individual worker sees increases over their lifetime, even though the average stays flat.


I read it as 3% retire, 3% enter the workforce, and everyone else is slightly better / more senior than the year before. So the average wage could be flat.


Isn't that the core issue? Productivity isn't being shared with the workers who actually produce it.


> The downward pressure that should exist is high earners retiring and low earners just starting their career.

> and the remaining 94% increase their earnings.

This is an extremely unrealistic expectation. There are a multitude of reasons for people's incomes to fluctuate other than retirement. People make career changes that result in lower income for many reasons, like taking a better job, changing careers, transitioning to a lower demand job when they have children, or moving to a new city with lower wages for personal preference.

For many jobs the earnings are also dependent on the company's earnings. Incentive structures, bonuses, RSUs. Even low paying companies scale their staff up and down based on demand. They can't hold a monotonically growing set of staff and also monotonically increase their wages when the incoming demand for their product is not monotonically growing.

The only way to come close to an "idealized society" like you're proposing is a totally self-sustaining, command and control economy where a central authority determines not only everyone's income, but their expenditures too. It's not possible to keep the entire economy and everyone in it moving in the same direction unless you're dictating where all of the money goes in society to a fine degree. Variations of this have been tried. The members of that society do not find themselves more well off.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: