mixu

> We work hard (and continue to invest) to make sure that providers serving sub-par inference can't game the system, and that our routing actively avoids them.

I'm glad to hear that y'all are doing this, as I was unaware that this was something OpenRouter does. I was surprised and disappointed that there are so many problematic providers that it seems like community best practice [1] is to ban somewhere in the realm of 5-6 providers. Would it be possible to provide some way to express an even stronger preference for high quality providers? E.g. "only route to first party for this model" or, "cost, but don't route to providers that more than x% worse than the first party". I'm sure something like that can be done via the API but I haven't found a UI way to do it - and having it in the UI would go a long way towards feeling like OpenRouter is looking out for me/helping solve the problem as opposed to leaving it to me to have to figure out.

[1] https://www.reddit.com/r/LocalLLaMA/comments/1mk4kt0/be_care...

Good! If you are wondering what this looks like in practice, I booked 3 flights this year with Ryanair and EVERY single time my tickets (directly purchased from their site) were flagged as "made through a third-party travel agent".

The "verification" workflow is super obtrusive: either pay them to use facial recognition technology or do slower verification (which I assume would be too slow if you saw this last minute). If you missed the email, you'd end up having to pay 55 eur to fix the issue. I was able to complain to customer service but it was definitely incredibly user hostile, intrusive and just ridiculous given that I booked directly via their site.

> Dear AAA this booking, AABBCC, appears to have been made through a third-party travel agent who has no commercial relationship with Ryanair to sell our flights. Therefore, Ryanair has blocked this booking.

> As third-party travel agents often do not provide Ryanair with the correct passenger email address and payment details, we need to verify a passenger's identity before they can manage their booking and check-in online.

> Ryanair needs to carry out this verification process in order to ensure we can comply with safety and security requirements.

> Once a passenger on the bookings has completed Ryanair's verification process, we will provide full access to the booking, including to the ability to make changes to the booking, add additional services, and complete online check-in.

> Express Verification is available at a cost of EUR 0.59c per booking.

> This fee covers the cost of the verification. Ryanair does not benefit commercially from this. There is no charge for Standard Verification.

> Passengers who do not avail of online verification (Express Verification or Standard Verification) to verify their bookings can verify at the Ryanair ticket desk in the airport, however they will be charged an airport check-in fee of up to €/£55.

Here's my setup:

- I use two large 64oz mason jars (best price via Walmart):

https://www.walmart.com/ip/Ball-Wide-Mouth-64oz-Half-Gallon-...

- In the past I used a metal filter from IKEA to filter the coffee by pouring into an empty mason jar:

https://www.ikea.com/us/en/p/oeverst-metal-coffee-filter-sta...

In the past year I switched to a mason jar pouring spout that has a built in filter that's at the right granularity to filter cold brew as you pour it into a glass:

https://www.amazon.com/Tea-Spot-stainless-Comfortable-Pitche...

That saves a bit of effort since the cold brew gets filtered when I pour it.

As far as how I prepare it:

I add a bit shy of 1/2 a cup of ground coffee per 64oz mason jar, mix vigorously and let it sit overnight (less than that and the flavors aren't quite yet there).

I don't proactively filter out the coffee grinds since the built in filter takes care of that. When one jar starts to run low, I start another one.

For fun, I ran this against node-glob ( https://github.com/isaacs/node-glob ).

Looks like it exhibits the slower behavior:

  n,elapsed
  1,0.07
  2,0.07
  3,0.07
  4,0.07
  5,0.16
  6,1.43
  7,19.90
  8,240.76

See this gist for the script https://gist.github.com/mixu/e4803da16e42439480eba2b29fa4448...

If you're willing to wait until Electron releases a Chrome 59 -based build, I'll be updating https://github.com/mixu/electroshot which handles screenshots and print-to-PDF along with a bunch of other niceties.

I wrote one of these for fun a while back using the following approach:

- Files are indexed by inode and device, files with the same inode + device are considered equal. (My main use case for this was to bundle up JS files.)

- Files are then indexed by size; only files with the same size are compared.

- During comparison, the files are read at block sizes increasing in powers of two, starting with 2k. The blocks are hashed and compared, and if they do not match the comparison is stopped early (often without having to read the full file). If all the hashes are equal, then the files are considered to be equal.

- Hashes are only computed when needed and cached in memory. Since the hash block size increases in powers of two, only a few dozen hashes are needed even for large files (reducing memory usage compared to a fixed hash block size).

link: https://github.com/mixu/file-dedupe

If you need static export, I wrote a project a while back that converts markdown to static output with Ghost theme support: https://github.com/mixu/ghost-render

Indeed, but ultimately covering all of those topics would require an incredible amount of time and effort. So I need to pick and choose my battles as some topics are more important or interesting to me than others. :)

Thanks for your kind words. There are definitely some cases where the topics could be reordered for greater clarity and I'll revisit them in the next iteration of the book based on the things people have pointed out (again, after a hiatus).

One of the challenges is to find the right balance between rigorous exposition one the one hand and keeping a brisk pace on the other (after all, writing for the web is different from writing a textbook). So I am grateful for all the input I've received thus far but it has definitely been challenging to find editors and reviewers - in particular because this is an unpaid effort on my part.

> The title seems to imply a practical bent, but it seems more like a collection of ideas (which are important and interesting, but not really what engineers need to know. IMO the #1 skill for distributed computing is to be competent at BOTH programming a single computer and at system administration).

I think this is something where different authors will emphasize different aspects. My view is that understanding of how to deal with the evolution of state within a system is crucial. Even systems that are not databases per se still have a dependency on how state is managed because you want to be able to reason about how some specific answer to a computation was derived and what guarantees it comes with (from strong consistency to some alternative but hopefully precise definition). I figure there will be disagreement on whether this important, and that's fine. There are other books.

That does bring up an interesting question: which books on distributed systems do you feel exhibit your preferred approach (free or paid)?

Re: the suggested topics:

Clusters of stateless web servers + single master. This is definitely a common setup, but you need very little if any distributed systems research to implement it.

Queues: I find the larger scale implications of queuing to be rather interesting (specifically, how cascading failures can be caused by an inadequate understanding of interactions between queues) but haven't found a good discussion beyond Google's findings that doing duplicate work often pays off as reduced 95th percentile latency.

MapReduce: There are many good books covering this topic in much more depth and specificity, so I didn't feel like I had that much to add. MR does use the techniques described - beyond job assignment the whole system rests on the DFS which uses block-level replication and some coordination protocol to maintain metadata state.

I kind of assume people have had some exposure to the paradigm at this point and do address MapReduce a bit in the context of the CALM theorem, which notes that a much larger set of relational algebra operations can actually be executed safely without coordination. Another point might be that MapReduce is inefficient in that it provides too much fault tolerance for typical workloads and cluster sizes.

Original GFS: the design has been largely superseded both by newer version of HDFS (e.g. eliminating the single point of failure in the initial design) and Google's (unpublished?) internal equivalents. BTW, the original GFS relies on Chubby, which uses Paxos internally.

Napster, BitTorrent and BitCoin: peer-to-peer systems definitely deserve a more extensive treatment in a later version of the book. The issues here are different in that trust, efficiency and resiliency are more important and I didn't have the bandwidth to handle them in the book as it stands.

Thanks for your comment, and I hope this doesn't sound like a rebuttal - I just wanted to think through the topics you mentioned one by one.

Any chance you could be more specific as to what you feel is missing in the book?

Granted, "distributed systems" is a enormous topic that no book can cover fully, but I have tried to cover things like:

- key papers (Lamport; Fischer, Lynch and Patterson; Chandra and Toueg etc.)

- topics relevant to highly successful commercial systems (e.g. 2PC => *SQL systems, Paxos => GFS/Chubby, ZAB => Zookeeper, Dynamo => Riak/Voldemort/Cassandra)

- and recent topics such as CRDTs and the CALM theorem.

Having a sense of how time, consistency and fault tolerance have been explained and handled is (I think) a prerequisite to more advanced topics, but I'd be interested in hearing what parts you'd feel need improvement because some day (~ some years from now) - I will revise the book and it would be nice to have a solid list of issues to revise.

Here's one way:

1) Join the HTML5 trial http://www.youtube.com/html5

2) Open Chrome inspector, select the <video> element

3) In the Chrome console, type $0.playbackRate = 2.0 ($0 refers to the element you've selected in the inspector)

This also works for other sites that use the HTML5 video element, and allows you to go faster than 2x if you prefer.

YouTube's HTML5 interface also has a menu option (gear icon) which has a speed control, but the Chrome inspector trick works with any HTML5 site.

I haven't yet fully formulated what I want to say so this is still just speculation on what the 2nd edition might contain. I can see a lot of room for improvement, especially in the latter chapters. Overall, the way I would frame the problem is much crisper now, and I think I have figured out how to better explain and implement my controller-averse approach, as well as server/client hybrid rendering and routing.

The community is more sophisticated about packaging these days so I would spend more time going beyond the basics and it's obvious what the most popular frameworks are (from ~8 contenders to ~3) so I should bring those in concretely to illustrate points. When I wrote the book, many of the frameworks were pre-1.0 and hadn't figured things out.

I also wrote another (to be released) book just on distributed systems which has helped with my thinking re: backend integration/caching/offline though I'm not sure how that will be directly reflected in this book.

Finally, I'd like to audit my use of indefinite articles, particularly within chapter headings.

It's actually available in mobi (Kindle) and epub on the front page, see the side bar at http://singlepageappbook.com/ or direct links: http://singlepageappbook.com/mixu-single-page-apps.mobi and http://singlepageappbook.com/mixu-single-page-apps.epub

If you find the book helpful - great! I'm glad. I can definitely see a lot of faults in my own work but I don't have infinite time to fix them, which is why the book is on Github ( https://github.com/mixu/singlepageappbook ).

There are things that I would definitely discuss differently if I wrote the book today - since things have developed a quite bit in the past year and half. I'll probably start working on a second edition late this year to rewrite the parts that I find most annoying in my book. I need to finish and ship a bunch of open source stuff before that though.

(author here) - if you're at YC's startup school today and have questions, come talk to me. I've got a yellow tshirt and look like my Github pic.

If you can get away with storing your data in the DOM, then go ahead. But this technique is mostly applicable to low-interactivity views (see the view layer overview chapter) - once you start displaying the same data in multiple locations, having your data tied to the DOM structure and state goes from being a easy technique to a complication. Hence I don't really consider storing data in the DOM as a single page app technique as much as an easy way to do low-end interactive components.

A VM is for most purposes identical to a dual boot setup, except for the part where you have hardware incompatibility issues and/or break your system. If you want, you can ignore the option of going back to a snapshot and stay in hardcore mode figuring out things, but you also get the option of reverting and learning from the experience. Less frustration = more fun = more motivation = more learning.

My tip would be to get VirtualBox or VMWare Workstation, and run your choice of Linux on it in fullscreen. There are two things that are annoying when learning Linux:

1) dealing with hardware issues

2) dealing with updates that break stuff

Virtualization solves both of those, at the cost of a little performance. The nice thing about VM's is that the virtual hardware is always the same and generally well tested (no hardware issues). And if you break stuff, you can roll back changes (VM snapshots). Both VirtualBox and VMWare have full screen modes and support for dual monitors out of the box.

Also, make sure you get a server as well and learn to administer it it from the command line. It's a great way to keep learning more.

You're right, I should've said "emulate blocking by checking that all of the tasks we queued have completed upon finishing a task before proceeding while allowing the event loop to run" instead of "blocking". It's not really blocking the event loop, only a controlling the flow of a particular path of execution. Only a few native API's provide synchronous versions that will block the entire process until they complete - like the filesystem API's fs.readFileSync.

This is really old - discussion from 6 months ago: http://news.ycombinator.com/item?id=2848239

Basically, async I/O gives you more options than "block the whole world while you go read this stuff", and that means that old idioms aren't effective.

You gain more control: can choose when to block, when to limit concurrency and when to just launch a bunch of tasks at the same time. At the same time, you need to adopt a few new patterns, since you can't/don't feel right blocking execution every time you use an external data source. It's definitely a tradeoff and not a magic bullet.

For my longer take on this, see http://book.mixu.net/ch7.html

A pure-Node approach is a lot simpler: you can just use Node's HTTPS (if you don't care about load balancing) and attach Socket.io to it. Just don't put your Socket.io server behind Nginx if you want WebSockets support.

With load balancing, I would recommend going with Stud/Stunnel and HAProxy. Terminating SSL with a specialized piece of software is nicer (separate SSL overhead to another box), and using a separate load balancer allows for more flexible options, e.g. serving static assets from Nginx. There is nothing wrong with node-http-proxy, it's just that these two projects have been around for longer and are better understood from an ops perspective.

You cannot use round robin load balancing, you need to have at least IP-based stickiness with Socket.io for now. Well, you can round robin if you use the Redis store but you'll run into inefficiencies with https://github.com/LearnBoost/socket.io/issues/686 . I'll do a bit more coverage on other SIO deployment-related issues once I get the chapter on Socket.io finished for my (free) book in a few weeks.

If I were starting now, I'd just ignore the Flash sockets transport since it makes the whole stack more complex due to not looking like HTTP to load balancers, and start with Engine.io / WebSocket.io to take advantage of their simplicity.

My favorite feature: a dedication from the developer to fix bugs even on Linuxes they aren't personally running (Arch Linux in this case).

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=447...

Well, how about this? I'm fairly certain it's ES 3 compatible.

https://gist.github.com/1559933

The original was 28 lines, this is 36 (mostly because I like white space).

I haven't ever really tried to emulate classes in JS, but this is probably how I would do it. The major difference is that this is written plain old Javascript rather than some special syntax - easier to understand.

Apress is a freaking publisher - shouldn't they be expected to be at least minimally professional? Whatever the initial agreement e.g. regarding advances was, the fact remains that Apress did not pay the author until several months after they had completed the work despite several months of inquiries, reminders and so on.

Either Apress is just plain unprofessional (e.g. unwilling/extraordinarily slow) or as you said they are doing this in order to put themselves in a better negotiating position.

I had a similar experience with Apress while working with them as a technical reviewer. They printed the book without asking me for my bio, so I didn't get my five lines of text credits for the work I did. It wouldn't have cost them anything to do that, but they nevertheless screwed it up.

Needless to say, I figured it's way too much of a hassle to deal with them when they approached me to write an actual book, since I want to spend my time writing rather than following up to make sure my publisher does what they are supposed to do.

Yes, with a contract you have better legal recourse. But I'd prefer to work with people I don't have to sue in order to get paid, esp. when the sums involved are tiny.

How about some books that aren't pop-sci / business books? I am kind of biased, since I love this area of psychology.

- The Sciences of the Artificial by Simon

- The Psychology of Problem Solving by Davidson & Sternberg

- The Cambridge Handbook of Expertise and Expert Performance (Cambridge Handbooks in Psychology) by Ericsson, Charness, Feltovich & Hoffman

- Minds, Brains and Computers - The Foundations of Cognitive Science: An Anthology (Blackwell Philosophy Anthologies)

- Choices, Values, and Frames by Kahneman & Tversky

The Sciences of the Artificial is a small but deep book by Herbert Simon, who is considered a key figure in founding the study of these areas (http://en.wikipedia.org/wiki/Herbert_Simon ).

Davidson & Sternberg focuses on problem solving (http://en.wikipedia.org/wiki/Robert_Sternberg ).

The Cambridge Handbooks (there are many others) in particular are excellent as they contain classic articles in Cognitive Science and Psychology, with introductions and overviews by people who actually research this area. The one on Expertise and Expert performance is edited by K. A. Ericsson (http://en.wikipedia.org/wiki/K._Anders_Ericsson )

Minds, Brains and Computers is another collection of classics, from a more model-based perspective.

Finally, Kahneman and Tversky offer a more economics-centric viewpoint. (http://en.wikipedia.org/wiki/Daniel_Kahneman & http://en.wikipedia.org/wiki/Amos_Tversky )

If you read scientific articles in this area, you'll notice that many of these author's names will keep popping up...

> "customizable tiling window manager" somehow requires the user to learn an unusual programming language and a dozen of inscrutable keyboard shortcuts

You might be interested in the tiling window manager I wrote with Node.js (mixu/nwm on github). It's very much inspired by xmonad and dwm, but the engine is Javascript running in Node.js with a native extension for X11 operations/events.

All layouting decisions are made in JS - in fact, the C++ binding doesn't even know the position of the windows or the dimension of the monitors; it's all tracked in JS. It should be easier to customize, though definitely not as battle-tested as xmonad.

So here's what LearnBoost is doing (if I understood this correctly): they're splitting Socket.io into two lower level layers, Websocket.io and Engine.io.

Websocket.io only does websockets transports (... all six of 'em)

Engine.io is a slightly higher level package that adds more transports (polling, flash), and which uses websocket.io.

These two both expose a websockets -like API over the transports they provide.

Socket.io becomes a particular implementation of a Comet stack that depends on these two, with some client extra niceties. This means that the code behind Socket.io can be reused elsewhere on a lower level without resorting to patching a full stack framework like Socket.io. Developers get a greater deal of control and the project is more clearly split into different parts. Awesome!