Athas

63 ms·

601.
The “too small to fail” memory-allocation rule(lwn.net)
2 points by Athas 12y ago|1 comments
602.
by Athas 12y ago
Threads are fairly expensive - you have to allocate and map a new stack, as well as a bunch of bookkeeping data structures in the kernel. While the kernel could of course start an auxillary thread at program initialisation, and re-use it f
603.
by Athas 12y ago
A possible solution would be to devise a language with a type system that tracks allocation, such that a garbage collector is not needed, and that all allocation deterministic, and yet safe. Some work has been done on this already, in the
604.
by Athas 12y ago
Yes, it would. This is actually a benefit of Linux (and the BSDs for that matter) - since all drivers are in the main kernel, you don't get as much idiocy from hardware makers that try to do something clever.
605.
by Athas 12y ago
Huh - how can that work? Take some partially evaluated object 'F <thunk>', where F is a data constructor. This object is old and thus stored in the oldest generation. When we force the thunk, we have to update the referen
606.
by Athas 12y ago
No. There are only a few properties of functional programming that help performance, and they are mostly spent compensating for the overhead typically imposed by high-level languages: * Easier parallelisation (although compiler auto-parall
607.
by Athas 12y ago
Is this a problem even if /bin/sh is not bash? I'm pretty confused at why one would ever want /bin/sh to be bash (and not, say, dash). If you want bash, ask for it.
608.
by Athas 12y ago
Most algorithms guys don't seem to be that enthusiastic about functional programming. My personal theory is that functional programming is more rooted in abstract logic, which isn't what algorithms is really about.
609.
by Athas 13y ago
LLVM used to have a backend that could convert its low-level bitcode to portable C.
610.
Haskell parser generators: Unhappy about happy(metanohi.name)
3 points by Athas 13y ago|0 comments
611.
by Athas 13y ago
> 2. Americans are less risk-averse because Americans are mostly descendants of immigrants. And immigrants are more likely to have a less risk-averse DNA. Do you have any evidence that this is a genetic trait, and not a cultural factor?
612.
by Athas 13y ago
Given that Unix was primarily a multiuser system in those days, that would be a rarely useful optimisation. Especially if you expected most people to run ed at all times, since it was, after all, the standard editor.
613.
by Athas 13y ago
A multi-letter variable name.
614.
by Athas 13y ago
Patents can never be renewed. That's the entire point of patent systems: limited-time monopoly.
615.
by Athas 13y ago
This is true. I'm currently working on a research compiler targeting GPUs. It's 7500 lines of Haskell with all comments and blank lines removed, and the only impure part is the command line interface. Avoiding IO is not really
616.
by Athas 13y ago
But in this case, if you don't check the return value of for example the write() system call, it's more a case of "fail silently" than "fail-fast", which is perhaps the most dangerous form of bug that a program
617.
by Athas 14y ago
> At the end of the day, someone has root, and that guy can do pretty much anything. I do not disagree with your overall assessment, but this is not strictly true. Most good real-world security schemes don't follow the 'root is God'-mo
618.
by Athas 14y ago
The jury's still out on that one. Van Ripers strategies involved such things as using motorcycle messengers (without accounting for the added latency to information exchange) that were invulnerable, and his proposed ship-to-ship missiles w
619.
by Athas 14y ago
You can do that sending while you're waiting for the disk to provide said GiBs. I also believe that useless uses of cat are often acceptable for readability (many novices are not familiar with redirecting standard input, particularly not a