It would have been difficult to get the CN delegation to sign off on a list that contained TW, although there are probably others.
181 karma · joined March 9, 2011
It would have been difficult to get the CN delegation to sign off on a list that contained TW, although there are probably others.
You can do the same work in Java but you can't statically link the JVM. You can sort of do these in Python, but the compiler story is murky at best, and the language isn't as type safe.
Someone made a bit of internal-only snark, and "I just want to serve 5TB" became an in-joke for turning easy problems into exercises in frustration.
Some of these things have, actually, been addressed.
2020: water, and vaccine mandates.
But one semester, the OS class added a new first assignment: write a shell. It took about a day or two, but after the second or third accidental fork bomb, a generous per-user process limit was imposed.
Arrays, struts, all other things are possible, but the things that make Lisp Lisp mean that you may get a list where repeatedly calling cdr may result in something that is not listp (cons or nil). And that’s weird. It enables some things that are wonderful, but I think the Lisps are practically unique in conflating pairs and list elements.
(Consider that the detail of improper lists is enshrined in the language.)
[edited]
I believe that's the case. The ancient and venerable UW implementation of the ancient, venerable, and awful Unix "mbox" format from the UW server has a lot of these sorts of problems.
The UW server did not have this problem with some of the other formats. It suffered a lot from supporting a lot of different formats in borderline hostile conditions (i.e., users were assumed to have filesystem access to the server so no improvement to locking or caching was practical).
None of the current commercial implementations suffer from this, but I suppose I can say that the lowest common denominator is still pretty low.
I may be overstating this because what I'm describing would also outlaw message delivery, which I don't think is the case. I think one of the formats did have problems with trivial concurrent access but I was never a UW-imapd expert. I am sure that the mbox format has problems with EXPUNGE (removing messages flagged deleted) as well as many other issues.
I guess it's also worth reiterating that STATUSing a SELECTed mailbox (one that's open in another connection) is a pretty big waste of server resources, as someone else noted.
A UIDVALIDITY change should blow your whole cache. In practice they are rare.
(I also miss USB type A and MagSafe, but the keyboard was the deal breaker.)
This can also reduce cookie size, which adds up.
Edit: found it! https://web.archive.org/web/20121107034606/http://danweinreb...
If you're using nonblocking I/O, or threads, select can become the bottleneck with a few thousand interesting connections at sizes that are much less than the FD_SETSIZE max.
The user-space CPU utilization should be near-0 since this is really a kernel I/O problem; the fact that it is much higher is an indication that a lot of wasted user space work is being done.
Select, by design, has a flaw: the kernel must scan the bitmask for the highest-numbered fd passed in, even if there is little change in the fd_set bitmask (as is usually the case). This means incurring a cost if any fd in the set has a high fd number. The fd on which you accept probably has a low number, but your client I/O fds will have increasing numbers as the server gets greater and greater utilization.
kqueue (and epoll, but I haven't used it) resolve this problem nicely. Only things that change state must be communicated. poll is better than select in this respect if the array is sparse, but if a large number of fds are interesting, it will also get expensive.