News for hackers. Stuff that matters.

bmdhacks

Re:Apple M5 chip on Wednesday October 15, 2025 @02:09PM (#45596397)
Asahi linux is essentially in a holding pattern with only support up to M2. Likely linux will never be supported above M2 and even M2 has a lot of rough edges. When my monitor sleeps on M2 linux it can never reawaken without a reboot.
Re:Go kit: Go in the modern enterprise on Thursday February 12, 2015 @02:27PM (#9040797)
Take a look at the Stack class (an example of a free monad) and how it's used to compose clients:

https://github.com/twitter/finagle/blob/master/finagle-core/...

https://github.com/twitter/finagle/blob/master/finagle-core/...

http://twitter.github.io/finagle/guide/Clients.html

A client is a layer of various components like load balancers and stats recorders, but they're also all configurable. Only using the expressiveness of scala could such a data structure be created to compose all of these pieces, yet still keep them modifiable and type-safe.

Re:Interview with Raffi Krikorian on Twitter's Infrastructure on Tuesday January 21, 2014 @10:24AM (#7095763)
Fanout is soft realtime, but yeah, we don't block lady gagas tweets to 40 million people until they're all delivered. Note that she counts as 1 in the tps calculation when she tweets. Btw, we're hiring if you'd like to help us make twitter even better.
Re:Interview with Raffi Krikorian on Twitter's Infrastructure on Tuesday January 21, 2014 @10:11AM (#7095674)
34k tweets per second * follower fanout. Trading platforms don't deliver curated individual timelines of single trades you are interested in.
Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @08:59PM (#6106003)
One of the projects I've been working on is doing more aggregate analysis of zipkin data: https://github.com/twitter/zipkin/pull/276

We're using this at Twitter to better understand usage patterns for services upstream and downstream. For example, Gizmoduck, the user store at twitter is backed by memcache, and some disk-based storage behind the cache. While we can view individual traces that hit by memcache, the aggregate info shows us both the proportion of traffic for services calling Gizmoduck, as well as the proportion of time Gizmoduck spends in memcache versus the backend store.

Furthermore, it can be useful for notifying of unusual behavior. If a service's aggregate durations has changed since yesterday, perhaps that's something we want to look at. Or if the ratio of traffic from some upstream service doubles, that's interesting to know.

Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @07:41PM (#6105676)
That's what we do, but it's built into the RPC library we use, finagle: https://github.com/twitter/finagle/blob/master/finagle-core/...

BTW, to the readers at home, note how almost all our core infrastructure is open-sourced.

Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @07:33PM (#6105649)
Merged thanks
Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @07:32PM (#6105648)
Zipkin is designed to piece together operations that are distributed across a fleet of systems. IE: nginx calls your rails server which calls memcache then calls your login server which hits a mysql database. It's most useful when your serving architecture is distributed across many many machines and many many different services.
Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @07:30PM (#6105632)
Re:Twitter's Tool For Debugging At Scale on Thursday July 25, 2013 @07:17PM (#6105577)
Hey, developer on zipkin here. Happy to answer any questions you have.