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

The thermal gradient in space is meaningless because there is hardly any matter to dump the energy into. This means you are entirely reliant on thermal radiation. If you look at the numbers given by Stefan-Boltzmann law you'd see that means to radiate a significant amount of energy you need a combination of a lot of surface area and high temperatures.

This means you need some sort of heat pump. For a practical example you can look at the ISS, which has what they call the "External Active Thermal Control System" (EATCS), it's a complicated system and it provides 70kW of heat rejection. A datacenter in space would need to massively scale up such a system in order to cool itself.


The ISS comparison is a bit of a category mismatch. The EATCS is complex because it’s a life-support system that must keep humans at exactly 22C (295K) while managing ammonia loops in a manned environment.

Computers aren't humans. High-performance silicon can comfortably operate at a junction temperature of 80C to 90C (approx. 360K). Because of that T^4 relationship, a radiator at 85C rejects nearly double the heat per square meter than a radiator at 20C, unless I miss something.

So this makes it a bit more nuanced.


Is there a credible way to cool a space-based data center on that scale?

There's not even a credible way to transfer meaningful amounts of data to and from a deep-space based data center.

What good is compute if you can't interface with it? This is where we are now: https://en.wikipedia.org/wiki/Deep_Space_Optical_Communicati...

SpaceX may be leading in short-range (few hundred km) space-to-space data transfer but there is a long way to go for terabit/s deep-space links.


I love this book! I do wish there was a new edition that updated the version of Java used in the tree-walk interpreter. There's been some additions to the language, like sealed classes and exhaustive switches, that could really benefit the implementation.


It's a fun little exercise left to the reader to upgrade to current Java. It pretty much eliminates the need for his ad-hoc code generation tool.


Been there, did that, very much enjoy the result.


The DMCA notice is available here: https://github.com/github/dmca/blob/master/2025/12/2025-12-1...

The notice has a list of files and says that they were copied from ffmpeg, removed the original copyright notice, added their own and licensed under the more permissive Apache license.


Thanks for the link; sadly none of the links to the repo can be viewed to see what exactly occurred.

To those downvoting, curious why? Many of the links are not viewable, since GitHub hides them, so any discussion becomes quite tricky.


You can find an archive of the links' targets at https://archive.softwareheritage.org/swh:1:dir:5861f19187336...


Interestingly, the repo has a LICENSES folder that contains the text of the licenses used in the repo:

https://archive.softwareheritage.org/browse/directory/ed4b20...

And yep, they only included the most openly permissive ones there (APL2 and MIT), completely skipping everything else. Ugh.


Maybe because if the ffmpeg people say they have a reason and they've waited 1 year and a half for compliance, we trust them more than whoever relicensed their code without permission.


I didn't downvote. I suspect people did because it sounded like you were defending ILoveRockchip's actions, based on either 1) not understanding what they did, and/or 2) not having access to the facts. People get snippy about abusing Free Software.


One of the reasons Calibri was selected over Times New Roman was it has a lower rate of OCR transcription errors, making documents using it easier for people using screen readers.


Link on that, as OCR should be more reliable with Times New Roman due to significant serifs.


I don't have link on that, but the main difficulty with OCR isn't the OCR part (not anymore at least), it's the "clean up" part, and serifs are a pain in the ass, especially on sightly crumpled paper. My use case was an ERP plugin that digitalized and read to receipt to autofill reimbursement demands, and since most receipt use sans-serif fonts, it was mostly fine, but some jokers use serifed font (mostly on receipts you get when using cash, not credit card receipts) and the error rate jumped from like 1% to 13% (not sure about the 1%, it might be a story i told myself to make me feel better, it was a decade ago, before i pivoted to network from AI. I always take the best decision it seems)


I don't know what studies Blinken's State Department considered, but here are 2 studies on the matter.

https://www.academia.edu/72263493/Effect_of_Typeface_Design_...: "For Latin, it was observed that individual letters with serif cause misclassification on (b,h), (u,n), (o,n), (o,u)."

https://par.nsf.gov/servlets/purl/10220037: [Figure 5 shows higher accuracy for the two sans-serif fonts, Arial and DejaVu compared to Times New Roman, across all OCR engines]


The memo at the time said the serifs can cause OCR issues.

https://x.com/John_Hudson/status/1615486871571935232


Just because they claimed it, doesn't make it true. OCR and screen reader software in 2023 did not have problems with serifs.


That doesn't make much sense, since a typewriter will neither type Calibri nor Times New Roman. And OCR should only be needed for type written documents, because any document made with Calibri or TNR is already digital.


printed documents, images, horribly inaccessible pdfs, horribly inaccessible websites


> Printed documents - Use the original, which is digital.

> Images - Use the original, which is digital.

> horribly inaccessible pdfs - Use the original, which has real text in the PDF

> horribly inaccessible websites - All text on any web site is digital. Nobody uses OCR on a website.

A massive paper producer like the government shouldn't adopt their type setting to people who are using technology wrongly.



God damn...

Why didn't they fax it back and forth a few times as well, just for good measure?


it's easier to mandate font than to excise all processes within the fed bureaucracy that result in these.

images being digital have no bearing on OCR ability


Images: use the original, which is a digital text document and not an image.

Unless they are making documents on typewriters. And in those cases neither Biden or Trump font is an option.


We have a process at work where clients export information from their database as a pdf which they email to us so that we can ocr it and insert into our database.

No one else seems to think this is bat shit insane


It could've been, but it was probably a turbocharged L-series engine.


When Doyle wrote most of the Holmes stories cocaine was a popular and novel new drug, it wasn't until later that it's risks became widely known. In one of his later stories, "The Adventure of the Missing Three-Quarter", Doyle portrays it as an addiction that Watson weaned him of, but is still concerned that his friend may fall back into.

"For years I had gradually weaned him from that drug-mania which had threatened once to check his remarkable career. Now I knew that under ordinary conditions he no longer craved for this artificial stimulus, but I was well aware that the fiend was not dead but sleeping, and I have known that the sleep was a light one and the waking near when in periods of idleness I have seen the drawn look upon Holmes’ ascetic face, and the brooding of his deep-set and inscrutable eyes. Therefore I blessed this Mr. Overton, whoever he might be, since he had come with his enigmatic message to break that dangerous calm which brought more peril to my friend than all the storms of his tempestuous life."

- https://en.wikisource.org/wiki/The_Return_of_Sherlock_Holmes...


In the US copyright just requires a level of originality. The bar isn't very high, but for example simple logos, like IBMs blue lines logo is not copyrightable.

There are examples of software code that is probably not copyrightable, but that's limited to very simple code that has only obvious implementations.


I believe the RTL in RTL-SDR is "Realtek Limited", the manufacturer of the chips used in the early days of SDR. I don't think the chips these days are exclusively Realtek, but the name has persisted.


Thanks! I'm getting myself a RTL-SDR!


For clarity, they're requiring apps to be signed by a verified developer on certified Android devices. You can still side load, but the verification is still required for the side loaded apps.


Future HN headline: Pam Bondi orders Google to revoke verification status and code signing certificates of authors of {partisan/politically-unfavourable Android app}


This still means that Google is effectively gatekeeping what can be installed on the hardware you own and what cannot.


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

Search: