Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dap
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
76 ms
·
331.
▲
by
dap
12y ago
Just because lots of people say "non-blocking, good concurrency, event-based model" without understanding it doesn't mean it's not correct. With a single-threaded, event-based model, you can get an awful lot of concurre
332.
▲
by
dap
12y ago
"zpool status" will show if there have been errors reading data from individual devices. If a drive experiences enough failures, at least on illumos and Solaris-based systems, it will be marked degraded or faulted and removed fro
333.
▲
by
dap
12y ago
I wish the author had provided an explanation. The main issue I'm familiar with is that throughput and IOPS capacity generally don't increase linearly with storage capacity, so the time to recover from a drive failure increases s
334.
▲
by
dap
12y ago
I wouldn't take that lesson from it. Many of these considerations don't have anything to do ZFS per se, but come up in designing any non-trivial storage system. These include most of the comments about IOPS capacity, the comments
335.
▲
by
dap
12y ago
We've been using the file-oriented, shell-based map-reduce model for a while with Joyent's Manta, and it's been a great fit for a variety of tasks. We've used it internally for everything from log analysis to video tran
336.
▲
Engineering Principles
(despairsoftware.blogspot.com)
1 points
by
dap
12y ago
|
0 comments
337.
▲
by
dap
12y ago
It's definitely unavailable right now, for me. Glad you were able to order it, but your ability to do so once doesn't mean many people aren't prevented.
338.
▲
by
dap
12y ago
> Why does she not blame her publisher for setting the price of her books to be too high[0]? This seems to be a regular merchant/vendor price dispute - nothing new about it. Because Amazon's the one making it hard for her reade
339.
▲
by
dap
12y ago
... and since many people did the same thing, and many of the local bookstores have closed (particularly those with large selections), Amazon effectively has considerable influence over what kinds of things most of us read. Tough indeed.
340.
▲
by
dap
12y ago
While I appreciate the general principle that many others have also observed, that one should assume bugs are in one's own code before blaming the underlying system, I find that this is often an excuse to avoid understanding the proble
341.
▲
by
dap
12y ago
Just because it's hard to do technical interviews well doesn't mean that doing them well isn't worthwhile. In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bu
342.
▲
by
dap
12y ago
The paper ignores what I think is one of the biggest advantages of event-based systems over threaded ones, which is that the pathological failure modes when things go operationally sideways are often much nicer with event-based systems. It
343.
▲
by
dap
12y ago
Quite the contrary: I've had to maintain or incorporate some non-standard build processes into several build systems (mostly scons, waf, gyp), and in each one it was difficult or impossible to express what I wanted because the build sy
344.
▲
by
dap
12y ago
This is Make 001: $@ is your output file, $^ are your inputs (prerequisites, technically), and $< is your first input file. They're unfortunately ungoogleable, but just remember that they're called "Automatic variables&qu
345.
▲
by
dap
13y ago
You can bypass the scheduler by binding processes to processors. Some runtimes do this -- and sometimes get much worse performance as a result. My colleagues and I have seen many programs that think they know better than the OS do much wor
346.
▲
Joyent's Best Practices for Error Handling in Node.js
(joyent.com)
4 points
by
dap
13y ago
|
0 comments
347.
▲
by
dap
13y ago
> It's all just plumbing, and people demonstrably do it badly if we judge by how well the typical node module deals with unexpected failures. The official node policy on exceptions is that you should let the process die. Not because
348.
▲
by
dap
13y ago
There's no sane possibility of a hybrid for Node.js. The concurrency model in JavaScript is built for one thread [that runs JavaScript]. For servers, in such a model, everything has to be async. A 20ms synchronous operation means
349.
▲
by
dap
13y ago
One of the biggest problems here is that spindles usually don't handle oversubscription well. They service requests quickly up to a certain queue depth, and after that I/O times become significantly longer and more erratic. So i
350.
▲
by
dap
13y ago
You're absolutely right. The situation on Linux sounds bad, and it sounds like work's being done to improve that. Some other systems handle this case fine, though, and the problem isn't with the fsync() interface. Aside: I
351.
▲
by
dap
13y ago
>> I don't know what the intended use case actually is, >Generally speaking, if you've got a database system of some sort and want to write data to a file. But database systems have been around for years without such an i
352.
▲
by
dap
13y ago
jerf described a similar case where one is okay with losing some data, but not "too much". I'm not sure how to make that approach rigorous. (If rigor isn't important, and it's just best effort with no guarantees a
353.
▲
by
dap
13y ago
> Anything where you want an image to be guaranteed consistent, even if not complete, could use an ordering guarantee without a particular "this has been written now" guarantee. A log-structured data store where you don't
354.
▲
by
dap
13y ago
> On the other hand, some platforms don't need a frame pointer for debugging; if you emit correct unwind tables that's enough for the debugger to construct a backtrace. I haven't looked lately but am pretty sure amd64 ELF
355.
▲
by
dap
13y ago
> What bodyfour is proposing is not just getting a write-notification -- it's in tandem with being able to specify write ordering. If you need to be able to specify write ordering, you also want to be able to have a write notificati
356.
▲
by
dap
13y ago
That's potentially interesting, but the question is: if you're not going to do anything that relies on the data being on stable storage, why bother asking the system to write it out? Most of the use cases I think of involve a serv
357.
▲
by
dap
13y ago
It's good to have it at least in dev, but many bugs only show up in production, and performance work can only usefully be done on the shipping, optimized code.
358.
▲
by
dap
13y ago
> In particular, you often don't want to actually force I/O to happen immediately, since for performance reasons it's better for the kernel to buffer as much as it wants. If you don't issue an fsync(), the kernel neve
359.
▲
by
dap
13y ago
We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant
360.
▲
by
dap
13y ago
I'm saying that if black boxes are sufficient to root-cause the vast majority of commercial airline crashes, what problem are we trying to solve by "rethinking" them? The only one I can think of is speeding up the process, b
More ›