ttj - Tom Jones

  I've just bought a server with 1.5TB of RAM.  At 1-2MB per process, that would be running a million processes.  That might not make sense with only a few dozen cores, but running more than 2^15, or ~30k, processes, which, as far as I can tell is the current limit in Linux, must be useful sometimes. According to a part of something calling itself " The Open Group Base Specifications Issue 7" [0] (I'm not sure, but this may be stuff common to both the C and POSIX standards)   : blksize_t , pid_t , and ssize_t shall be signed integer types. The relevant one is pid_t.  It doesn't place a constraint on the size.  What would break if we had a system with 32 or 64 bit signed pid_t ?  (Is it common for client code to make wrong assumptions about this?) [0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html What error do we currently get if the system runs out of pids? My basic idea is that the multi-user nature of the existing U...

There should be a direct-link protocol.  Pairing (or equivalent) a pair of devices once should result in an authenticated link over any mutually-supported underlying link such as bluetooth, usb or wifi.  The same services should be available over any of these links (where physically possible) whether accessing files, transferring photos, sharing internet, and so on. Instead, there is currently no unity across the links.  Bluetooth pairing is one thing, wifi might be used to share via a hotspot with its own WPA password, USB asks you on the screen if you trust your laptop (each time) and then presents files over MTP, which is okay for photos but horrible for general filesystem hierarchies.  There doesn't even seem to be a sockety fs protocol over USB: it's either block device, which is the wrong level, or MTP, which is unsuitable.  It should look like nfs or 9p, adapted somewhat for the purpose, stuck in its own USB profile.  Usually the best way to transfer...