I completely agree that it always depends on the goal. I'd also add a second vector: experience. If you've already worked with distributed and/or storage systems and have understanding of the field, you can jump straight to papers and code. However, for people who are just starting, it may be beneficial to read an overview book and get familiar with a field. This book attempts to be that a starting point that can help to navigate database papers and code.
Some of the folks I talked to who have already worked with databases a lot mentioned they've benefited from the book as well, since there were some concepts they were less familiar with or never had to learn (for example, transactional processing for the folks who have mostly worked with on eventually consistent databases; or B-Tree details for the folks who have mostly worked on LSM-Based storage engine)
Author here. Thanks for the heads up, it did look a bit bleak on the mobile. Increased the font size, made grey much more dark, and increased heading sizes. Hope it's easier to read now!
I don't know if I'm seeing the old version or the new version, but this is still very hard to read.
Advice to all web designers: Please do not use "font-weight: 300" for body text, ever. Simply changing that to 400 in the developer tools made it much more readable. The font was still bugging me, so I tried killing the "font-family: futura pt" too.
Wow! What a world of difference. Now it is super easy to read, instead of looking like it's trying to show off some design style.
Know your audience: you are addressing potential database developers with this book, not graphic designers.
Preferring one font over the other is more a question of taste, but I think you're right about font-weight: it does read better with 400. Thanks for the tip!
If you could list the mistakes, the author could try making corrections and improve the text.
As regard O_DIRECT vs DMA, not sure what exactly you're saying. Understanding Linux Kernel book, for example, is using them quite interchangeably as well (4th edition, 2.6 kernel). Block devices are handled through interrupts and DMA, and these are lower-level means for doing IO. Scylla devs are using it quite interchangeably as well: https://github.com/scylladb/seastar/blob/master/core/reactor...
Wording might have been not optimal, but author never implied that O_DIRECT is DMA.
The author of the post refused to avail himself of other peoples' help
Chris. Please stop following my posts around the internet and spreading lies about me. Last time we talked chat was like that:
ifesdjeen: i don't want anyone to fix my problems)
bitemyapp: I don't give a fuck what you want.
(sic.)
There were several occasions on both IRC, and Mailing Lists when people were like:
x: ifesdjeen: that's all functorial
ifesdjeen: functorial?
x: ifesdjeen: and dont you know that
Or:
x: just write a function of that type for fmap
x: thats YOUR problem now isnt it
Yes, I didn't know what functorial is. And yes, it happened more than once.
Please, stop spreading these lies. I have explained you more than once that I'm not posting things to Haskell Mailing List and try avoiding asking questions on IRC due to 2 reasons:
1. When I have a more complicated question (such as thunk leak detection, monadic order traversal, implementing StateT instances to allow state to be handled transparently in concurrent apps), these questions take more than 2 minutes to answer. And both you and other people couldn't answer them (see your email from several month from now). And I do not blame you or them for that.
2. When a beginner comes with a simple question, he gets based by "experts"
So there are no questions you can ask and be happy: hard ones get ignored (by everyone including you). And easy ones make (some) "experts" talk with condescending tone.
Yesterday, 5 people wrote me a DM saying that I should ignore you, because your behaviour has been known to be offensive and bad even since the days you've been doing Clojure.
As for everyone else, please don't get offended if anyone happens to say you something condescending or offensive on IRC or Mailing List. People are people. But it doesn't mean you _have_ to keep posting your questions if you don't feel sure you're welcomed there.
Would you mind posting links to the unhelpful behaviour you have seen on mailing lists or IRC (http://ircbrowse.net/)?
The reason that I ask is that I'm concerned to hear more and more reports of such behaviour, but I've never seen it on the only Haskell mailing list I read (haskell-cafe) and I can't remember seeing that kind of thing on Haskell Reddit either, at least not without a number of helpful replies alongside unhelpful or dismissive ones. I'd like to see where this sort of behaviour is arising and see what I can do to improve things.
@tome to be honest, I don't really want to dig and search for these things. I've had these ones saved in my Evernote, since they were a part of discussion I've been involved into and considered interesting enough to save.
I'll report if I find something. Also, it'd be good not to do it in public (even though links are public, I don't want to be associated with a report).
noone cares that Ruby on Rails is a registered trademark of DHH, see '"Rails", "Ruby on Rails", and the Rails logo are registered trademarks of David Heinemeier Hansson. All rights reserved.' on the bottom of rails website.
They want to use that name, and they won't sue people for making consultancy business based on that technology for certain, since that's the way development of platform goes.
That sounds a lot like House MD :D
He seems to solve all of his diagnostical problems when thinking of a different / abstract thing, and approaching problem from a completely different angle. Nice idea, worth experimenting with
Article delivers a very smart thought also seems to give no facts or real advises. You can always blame stuff and use common sense rules such as don't optimize until you know what to optimize and don't bring too much complexity to your system. Although both of these are applied differently when developing for different systems.
Article is extremely abstract and same though may have been delivered through 140 symbols of Twitter message.
Some of the folks I talked to who have already worked with databases a lot mentioned they've benefited from the book as well, since there were some concepts they were less familiar with or never had to learn (for example, transactional processing for the folks who have mostly worked with on eventually consistent databases; or B-Tree details for the folks who have mostly worked on LSM-Based storage engine)
Disclaimer: I'm author of this book.