dap

31 ms·

241.
by dap 11y ago
> It doesn't have to be a big rewrite of "everything" to Rust. It would at the very least be a slow successive rewrite whenever a major change is needed. That's why the suggestion to implement BSD sockets first is an
242.
by dap 11y ago
Thanks for the details!
243.
by dap 11y ago
The NYT has a useful visualization of S&P 500 returns over various periods since 1920: http://www.nytimes.com/interactive/2011/01/02/business/20110...
244.
by dap 11y ago
> Wealthy individuals have access to investment strategies resemble far more the philosophy of large pension funds than robo-advisors. I know these are naive questions, but here goes: do those pension funds differ greatly from large univ
245.
by dap 11y ago
That's certainly true. I thought the article focused more on car-car crashes, but those are obviously important, too. It seems like the considerations in suburban and rural areas are fairly different than urban areas.
246.
by dap 11y ago
There are so many fallacies here that it's hard to know where to start. Others already pointed out the possibility that these effects are a short-lived result of the change in policy. > Research has shown that removing white lines
247.
by dap 11y ago
That sounds like a sign that the filesystem may be the wrong abstraction for this.
248.
by dap 11y ago
I don't necessary disagree with any of the claims, but it has a very "Old Man Yells at Cloud" sound to it: http://i.imgur.com/91sn32Q.jpg?fb
249.
by dap 11y ago
Persistence is not required for an exploit. Repeatability is just as bad. Restarting in response to compromise means every compromise is a DoS.
250.
by dap 11y ago
If the hypervisor is providing the security, I don't see how the unikernel can be said to be any more secure than anything else run under a hypervisor. Moreover, I don't see why the hypervisor should be in a better position to be
251.
by dap 11y ago
This feels specious: > The result of this is a very small and fast machine that has fewer security issues than traditional operating systems (because you strip out so much from the operating system, the attack surface becomes very small,
252.
by dap 11y ago
Doctors absolutely do this: https://en.m.wikipedia.org/wiki/Morbidity_and_mortality_conf...
253.
by dap 11y ago
The layers that ZFS violates were created years before the failure modes were well understood that filesystem-based checksums address. I'm not sure how you _can_ solve these issues without violating the old layers. In particular: chec
254.
by dap 11y ago
`ls /usr/bin/?? /usr/bin/???` can be interesting to skim through.
255.
by dap 11y ago
On the contrary: there are many bugs you will not find until software is in production. (That's not a reason not to test or roll out to staging environments first and the like, because you can continue to find new bugs that way. But
256.
by dap 11y ago
What kind of UUID? Standard UUIDs of versions 1, 2, and 3 are not really unique enough[1]. Version 4 is basically a random number, so it doesn't help to say "just use that". [1] https://en.wikipedia.org/wi
257.
by dap 11y ago
You can't use monotonically increasing numbers from multiple threads (or servers) without either synchronizing (which is terrible for scalability) or using separate prefixes for different threads or servers (in which case you have prob
258.
by dap 11y ago
He completely nailed the problem I've had with his description of looking for an iPad. If I know exactly what I want already (e.g., a book by title, or an electronic device by model number), it's usually easy. (In that case, tho
259.
by dap 11y ago
This is absurd for many reasons pointed out in this thread. The broad brush is especially problematic. If "programmers" should stop calling themselves "engineers" because of the prevalence of poor quality software, coul
260.
by dap 11y ago
That sounds interesting. I heard about you all through Abel at Surge last month and I'm looking forward to checking that out. I work primarily on illumos, where we do dump program text, and we're working on getting CTF everywhere
261.
by dap 11y ago
Great post on the structure of core files. It feels like a lot of people have an allergic reaction to core files. (Maybe because they remind you that your program just crashed? Or because they seem to take superhuman understanding to work
262.
by dap 11y ago
Agreed that's interesting (in a mostly academic sense), but the thrust of the post is about using that fact to make choices in writing code, and there's an awful lot of discussion here about that idea. That's what I was addr
263.
by dap 11y ago
This is a microbenchmark. It's a tight loop that calls the function 500 million times. The function itself just adds two numbers. It's pretty close to the best possible improvement for inlining a function. If that's what
264.
by dap 11y ago
> To me, all the lit stuff seemed completely arbitrary and made up. There were no testable hypothesis, no experiments to run. "The author was trying to tell us that ..." - well unless the author actually documented that later,
265.
by dap 11y ago
It's not that you can't find _some_ differences that way. As others have you pointed out, there should be little difference between the software deployed in staging and production. But there are can be differences in performance
266.
by dap 11y ago
This is a great write-up of a tough technical problem, and I definitely agree with their conclusion that "it's worth taking the time to understand your stack." I especially liked that it wasn't preachy. It just explain
267.
by dap 11y ago
I think you've misunderstood my point. The design I described does not require any component to be perfect. If any of these components (including the kernel) crashes, the system _still_ converges to the correct state.
268.
by dap 11y ago
That's a slippery slope argument: because we can't solve the halting problem or verify program correctness, we shouldn't try to handle crashes, either? Agreed on minimizing complexity. The only part of the chain I described
269.
by dap 11y ago
Just don't make any mistakes? Was that a joke? There are many reasons a process can die that are outside of its control, including signals from outside the process, handled (but uncorrectable) memory errors, and the OOM killer (on Lin
270.
by dap 11y ago
> Not only is it simple and does the do-the-one-thing-well thing well, which is true, it's also _correct_. How does it address the "who-watches-the-watcher" problem typically associated with service restarting?

More ›