You do realise there are AI checkers online.
https://www.zerogpt.com/ assesses this content as: 27.49% ChatGPT
While this writer obviously had a lot of input into the model, they even state (or more accurately according to zerogpt, ChatGPT wrote this whole paragraph) "The writing process should be highly iterative", so they have added their own flavour into the writing, but it is still, (probably not for much longer) but still obvious when this is used.
Great observation! Not only does ChatGPT produce seemingly human-authored output—humans can also produce ChatGPT-style output.
If you really want to fly below the radar you can even include instructions to adopt a certain writing style, e.g.: you can tell it to use a Gen-Z style with minimal formatting.
While normalization is usually one-way, if you're doing DSP normalization & have a record of the level offsets you've applied, it's reversible. This is never the case for compression - you can't increase dynamic range of a compressed file (short of AI-generating something that never was)
You’re right. I think it ends up working out to a 4096 page on x86 machines, that’s probably what I remembered.
Yes, _FORTIFY_SOURCE is a fabulous idea. I was just a bit shocked it wasn’t checked without _FORTIFY_SOURCE. If you’re doing FD_SET/FD_CLR, you’re about to make an (expensive) syscall. Why do you care to elide a cheap not-taken branch that’ll save your bacon some day? The overhead is so incredibly negligible.
Anyways, seriously just use poll(). The select() syscall needs to go away for good.
You've had a good chance to really see 4096 descriptions in select() somewhere. The man is misleading because it refers to the stubbornly POSIX compliant glibc wrapper around actual syscall. Any sane modern kernel (Linux; FreeBSD; NT (although select() on NT is a very different beast); well, maybe except macOS, never had a chance to write network code there) supports passing the descriptor sets of arbitrary size to select(). It's mentioned further down in the man, in the BUGS section:
> POSIX allows an implementation to define an upper limit,
advertised via the constant FD_SETSIZE, on the range of file
descriptors that can be specified in a file descriptor set. The
Linux kernel imposes no fixed limit, but the glibc implementation
makes fd_set a fixed-size type, with FD_SETSIZE defined as 1024,
and the FD_*() macros operating according to that limit.
The code I've had a chance to work with (it had its roots in the 90s-00s, therefore the select()) mostly used 2048 and 4096.
> Anyways, seriously just use poll().
Oh please don't. poll() should be in the same grave as select() really. Either use libev/libuv or go down the rabbit hole of what is the bleeding edge IO multiplexer for your platform (kqueue/epoll/IOCP/io_uring...).
(◔_◔)