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

Can you run AArch64 Linux on such a device, or would you better switch to 32-bit Arm due to the very limited RAM capacity?

A common reporting path for bounties and non-bounty vulnerabilities has always been problematic. This leads to weird scenarios where the company cannot accept reports of denial-of-service vulnerabilities because they are out of scope for bounties, for example. Exclusions from bounties are one thing, but not acting on relevant problems is just a bad idea. The typical bounty program terms are also incompatible with multi-vendor disclosure, where no single vendor can take complete ownership over the disclosure process.

The close proximity to the bounty process can also be challenging to corporate reporters because it could give the impression that they are individually soliciting a gift of non-nominal value from a company that is a supplier or customer in other contexts.


Even if they don't train on your content, Google reserves the right to use it for improving their services in other ways:

“ This license is for the limited purpose of operating the services, which means allowing the services to work as designed and creating new features and functionalities. ”

https://policies.google.com/terms?hl=en-US#toc-permission

The training exclusion has always been a distraction. These service providers have plenty of other uses for your data.


O'Reilly used to typeset their books using troff/groff: http://www.lemis.com/grog/Documentation/PUS/tmac.Gbignuts.G (“O'Reilly & Associates book macros by Steve Talbott, Lenny Muellner”)

Might be worth mentioning that Tim O'Reilly himself co-wrote a book about typesetting with troff. Unix Text Processing by Dale Dougherty and Tim O'Reilly, Hayden Books, 1987. This text was subsequently provided free under the Open Books Project.

Larry Kollar has provided a recreated source code repository at

https://github.com/larrykollar/Unix-Text-Processing

I recollect compiling the source from the github account having only to sort out one font path issue.


That's right. From the colophon of 1989's Nutshell Handbook on Using C on the UNIX System:

> The text of this book is set in Times Roman; headings are Helvetica; examples are Courier. Text was prepared using the troff text formatter and the devps PostScript filter. Figures are produced with a Macintosh. Printing is done on an Apple LaserWriter.


Allen AI imposes further restrictions on their model releases, I think: https://allenai.org/responsible-use


If the user is held accountable when the AI goes wrong, it discourages too many applications. Blaming people is incompatible with the business goals, I think. That's very different from weapons and other dual-use tools.


The most charitable interpretation: The new wording includes all forms of covert advertisement (say embedded in the content itself). All their plans always had that.


Not sure if the Stratus reference is correct. Big-endian x86-64 is a real thing on HPE NonStop:

“ The executable format that works on HPE Nonstop Compute's OSS is ELF64-bit, Big_Endian, X86_64. ”

https://inbox.sourceware.org/gcc-help/AM7PR02MB6483A12F6B98D...


On a more common platform, Windows has ARM64EC, which is basically ARM64 (LE) with x86-64 calling conventions.


Does the 16 come from maintenance_io_concurrency, which is also used to limit the prefetch depth?

I still think some details are missing for a true explanation of what is going on. Where does the random access pattern come from? Is prefetch unnecessarily performed for full-page images?


It's not a press embargo in the sense that the whole package of information becomes public once the embargo expires. There will be a published record on the cve.org, but often those who initiated the embargo insist that key details related to the vulnerability remain private even after the existence of the vulnerability and its remediation have been published.

Consider this example:

https://www.cve.org/CVERecord?id=CVE-2026-113119

At this time, the corresponding Chromium bug tracker entry is still private:

https://issues.chromium.org/issues/557075191

(I just picked this one at random, I haven't checked if the information is publicly available from another source.)


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

Search: