You need to tighten up your tinfoil hat. When HN features all the discussions on OpenAI's shenanigans on Navier-Stokes, you weren't seeing claims this was anti-US.
> Why is this the top comment? Many of the comments, as well as this one, have no relation to content and only mention a triviality
This is hardly a triviality. If you are interested in a topic and you find a paper interesting, more often than not you are interested in reaching out to the author.
If a paper features a list of authors that outnumber the paper's pages 10-to-1, it's a major red flag, and it's quite plausible and expectable that 99%of the names in that list had zero input and might even have zero contribution to give to the topic. I'd even argue it's a kin to academic fraud.
By the way, the same goes for those researchers who work on paper mills, and manage to rake in production metrics that go well beyond an article per day.
If you're confused about who to contact to follow up on the ideas of a particular paper then write to the first author, or whichever author is listed as the contact person. This is not hard and is an orthogonal consideration to the length of the author list.
> At that time, 36 years ago, the C flexible integer sizes were already obsolete.
This is a highly ignorant comment. You're confusing the fact that you only had to work with a single target architecture with the whole concept of multiple processor architectures being somehow obsolete, as if there was a sudden law of nature that forced every single computer, being full blown HPC stuff or small microcontrollers used in embedded applications.
Take a look at arduino. They still have 16-bit models out there. Also noteworthy, it seems some DSPs also have ints larger than 32 bits.
The parent is completely right in the sense that for actually portable C code it was always better to use fixed-width integer types which were chosen for the problem to solve instead of target hardware capabilities.
For instance if your integer arithmetic needs to happen with 32 bit precision (no matter if the code runs on a 16- or 32-bit CPU), there is no scenario where using 'int' makes sense. Instead you'd use a fixed-width 32-bit integer type and accept that math operations are compiled into two instructions on a 16-bit CPU.
And OTH if you only require 16 bits integer width, there's not much point in picking a 32 bit integer type. Since two's-complement integer encoding has been standard since at least the 70s, the CPU can do narrow operations in the native register width. Any overflow/wraparound is still correct when only looking at the lowest 16-bits of the result.
> The parent is completely right in the sense that for actually portable C code it was always better to use fixed-width integer types which were chosen for the problem to solve instead of target hardware capabilities.
You're confusing things. It's one thing to claim that either they never used a feature or they even have a personal preference to do things one way or another.
Another entirely different thing is to proclaim a programming language designed to target any conceivable CPU architecture somehow no longer needs to support basic cpu arch traits such as word size.
As I pointed out,there are still processors being sold today that do not support 32-bit ints. If you expect C to be able to target these architectures, obviously this feature is still a critical feature.
Also, people who maintain yesterday's systems that require non-32bit ints still need to work on them.
Chesterton's fence is still relevant. Why are we pretending that it's ok to mindlessly proclaim a feature is not requires because we don't understand why it was necessary to begin with?
As I have said, I have not worked with a single architecture.
Before 1990, I had worked with a variety of ISAs, from IBM mainframes and DEC minicomputers to many kinds of microprocessors.
After 1990, I have used C on a great variety of x86, Motorola 68xxx, IBM/Motorola PowerPC and many generations of ARM ISAs.
Even if you use explicit 32-bit integers in a program, that will not create any correctness problem when the program is run on 16-bit microcontroller. At most such a program may have a suboptimal performance. Performance problems are much easier solved during porting than obscure bugs.
There have been some popular DSPs with 24-bit integers, e.g. Motorola 56xxx. Nonetheless, nobody would want to run on such a DSP a program that was written for another kind of CPU, even for another kind of DSP, because the performance would be pathetic. Any program for such a fixed-point DSP, even when derived from an existing program, would need to be rewritten while using at every point in the program the knowledge that the size of "int" is 24 bits (because the programs for fixed-point DSPs need copious amounts of scaling operations, to avoid overflows and underflows), so such a program should not actually use "int", but it should typedef an "int24_t", to make this assumption explicit.
> Newly released court filings quote an OpenAI researcher saying: “I was just worried about optics (...)"
As a side-note, most orgs already cover the need to STFU in their training material for new hires, particularly how personal comments should not and cannot represent the company. I'm sure this lawsuit will be explicitly mentioned in upcoming versions of this sort training material in multiple orgs.
Legal incentives against better internal communication/coordination create so much inefficiency. The legal system should focus on outcomes more than internal comms.
i am of the belief that papering over a fundamental lack of integrity and ethics will usually fail to conceal it. it is ineffective.
lack of ethics and integrity is of course part of the design of a capitalist economy.
you can't change the economy as an individual but i like this quote: "Do the right thing for the right reasons, at the right time with the right people, and you'll have no regrets for the rest of your lives."
Prioritization and escalation exists in most companies. I guarantee you that once an issue hits the HN front page, even engineers who might have totally different talks will get involved. (Never worked at GH or have talked to anyone there in years but this is how everything works pretty much everywhere)
> Prioritization and escalation exists in most companies.
Yes, indeed public awareness of a problem affects how an issue is reprioritized. Some companies even employ web scrapers to do sentiment analysis at each release, and visible issues do get bumped to high priority.
It's amusing how some people in this thread try to pretend this doesn't happen, and make these bold assertions with a straight face in replies to people who were in actual meetings where issues were escalated because of this.
The public shaming will continue until the internal incentives improve. Make sure to drop that HN thread link into the internal task tracker y'all. Don't forget to report to journalists if the severity warrants it (Brian Krebs, 404media, etc).
"Show me the incentive and I'll show you the outcome."
> The preprint papers on arXiv are like 99% the same as the published versions, except they're free instead of locked behind a multi-thousand dollar/year paywall.
I don't think you fully understand the problem. It doesn't matter if you can find in arxiv a preprint of an article published on a reputable journal. What matters is that right besides that paper you will find a dozen other papers that can be utter nonsense generated by a poorly calibrated slop factory. You don't find those in papers published in respectable journals which enforce double blind peer review and were filtered for relevance and quality.
It's that peer review process that creates value and relevance. Otherwise all you have is a glorified file server.
> How is science to evolve if good research requires $49 a pop to view?
This kind of criticism is misplaced. The answer to reputable journals being held hostage by the likes of Elsevier is not dropping peer review and dump articles in a blog-like site such as Arxiv.
I'm confident the bulk of academia would love to move away from Elsevier et al and have free open journals as their discourse venue. However, the publish or perish situation created pressure to count only the papers published in reference publications in their productivity metrics, and those were hijacked by for-profit editorial companies which unscrupulously abuse their dominant entrenched position.
You need to tighten up your tinfoil hat. When HN features all the discussions on OpenAI's shenanigans on Navier-Stokes, you weren't seeing claims this was anti-US.
reply