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

> The districts of both representatives (Chicago for Garcia, and Harrisburg for Perry) flatly oppose it, as do their state governments.

You’ll have to cite your sources there, friend. As a constituent of one of those districts myself, I certainly do not oppose it! All my homies hate ALPRs.


Your alderman supports Chicago's deployment of them and is doing nothing to stop that. Nobody would ever claim everybody in any district supports ALPRs. Apologies to your homies.

Shoutout to Sonic Pi (https://sonic-pi.net/) for still being the best at this.

Because you still have to read the code AI writes. I would argue it’s even more important than ever for code to be human readable.


Income != profit. Income is revenue. It sure would be nice if businesses were taxed on income, given that’s how people are taxed and all. Aren’t corporations supposedly people now thanks to citizens united?


You're mistaken. Income is net of expenses. https://www.investopedia.com/ask/answers/122214/what-differe...


I appreciate your polite corrections with well sourced info! Being a bit silly, I’ll say you’re a shiny beam of knowledge in a dark expanse of confusion




Absolute cinema


A side effect of replacing entire pages with images is that the file size will expand dramatically. Most PDFs only contain a couple of images


It might be feasible to have an intermediate AI call take the generated image and slice it into individual text and image elements that it would then render into the pdf page


I always thought it was a bit silly to refer to it as a “zero player game“.


I’m surprised no one is talking about the 2038 problem.


That is not specific to 32-bit system architectures. The 2038 problem is specific to timestamps that are represented as milliseconds since the Unix epoch and are stored in a 32-bit integer. It's quite possible (and common) to deal with 64-bit integers on a 32-bit system architecture.

I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.


It's actually seconds since epoch, not milliseconds. Here's a small program to verify it:

  date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_'
It is also mentioned in perldoc Time::Piece [1], as a warning for people whose build of perl uses 32-bit integers for time.

[1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds


It got fixed in the kernel & musl in 2020. It got fixed in glibc in 2021. Everything built against the currently-supported versions of those things will have 64-bit `time_t` since the headers are updated. It mostly only matters for proprietary programs distributed only as binaries that don't get updates, for systems that no longer get updates at all, and for people running computer history museum exhibits. Some distros take a long time to update, but even the longest don't have 17-year support cycles.

I'm sure it'll cause someone some issues, but it'll be very niche by 2038. Most of the sorts of systems that it could cause problems for aren't being used to plan things years in advance, some probably don't even do anything with the date. So it's a niche within a niche (unupdatable systems used for future planning) that's likely to have problems soon, and overall probably no longer a big deal.

TL;DR: It's solved upstream, only an issue for some systems that don't get updates.


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

Search: