packetbeats

I was thinking of it as the starting point, then you evolve from there.

Tbh, views are a bit of a leaky abstraction (for example when it comes to constraints) so adopting them gradually seems like a good idea.

You can see a live demo of Kibana here: http://demo.elastic.co/packetbeat/

Many thanks for posting it! :)

It will drop traffic in that case.

PF_RING is an option but it requires a kernel module and specific network cards. Before then, the memory map sniffing feature of the Linux kernel [1] can improve libpcap performance. Not quite to 10G speeds, though, but I think enough for most cases :-)

[1]: http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/D...

Depending on the traffic, the CPU usage of the agent could indeed be significant. We're thinking to implement sampling to reduce the effect of this. On the other hand, the agent is not "in-line" so it cannot introduce any latency, only steal CPU time from them.

So, unless you have a single CPU core, it's pretty safe to run in production. It cannot affect the application performance by much.

Thanks for noticing the broken link, we fixed it.

I haven't tried Boundary in a while, but I think they are focused on metrics. This indexes the transactions, so you can later search and do analytics on them.

Thanks! We're working on adding more information to the website and also on improving the design, based on the feedback we got so far.

We're working on a somehow similar product that works by understanding the network traffic received and sent by your application. This means it can be language independent. http://packetbeat.com/

Thanks for the question. Right now we have some heuristics to automatically take out passwords but we want to add the option to only send the URLs by default, and only enable full tracing selectively. This would help with privacy but also with the bandwidth consumption.

Link: http://packetbeat.com/

Clickable link: http://packetbeat.com/

After curl-ing for a while in a loop, and sort -u:

  Anything added dilutes everything else.
  Approachable is better than simple.
  Avoid administrative distraction.
  Design for failure.
  Encourage flow.
  Favor focus over features.
  Half measures are as bad as nothing at all.
  It's not fully shipped until it's fast.
  Keep it logically awesome.
  Mind your words, they are important.
  Non-blocking is better than blocking.
  Practicality beats purity.
  Responsive is better than fast.
  Speak like a human.

I like the idea and could use the product, so I hope you continue working on it after the 24h. Of course, the tricky part will be getting enough traction that people can use the site as soon as they discover it. When I tried it, there was only one other person "searching" and apparently not my language combination.

Fantastic in depth article. In my opinion, the tests he perform show not so much drawbacks of the tested systems, but more the fact that defining them in terms of the CAP theorem can be misleading. For example, a CP system should, in case of a partition, wait until the partition is resolved, potentially forever. This is not useful in practice, where almost always some timeout is used. This is why, if I'm interpreting the results correctly, not even a Postgres running on a single node can claim to be CP.

According to the "PayPal wars" book PayPal didn't acquire X.com, it was a 50-50 merger. It is true (again, according to this book written by a PayPaler) that Musk wasn't as important to the PayPal success as the "funder" title would imply, but he did drive innovation into the space as a competitor and then saved the company from the hands a clueless CEO.

It's very hard to say if PayPal would have succeeded without him. For one, it would have probably been much harder for PayPal to raise 100 Mio without the X.com merger. They got that amount shortly before the dotcom crash, so it was crucial for their survival.

Microsoft did something similar in BASIC, and for the same reason: http://www.pagetable.com/?p=43 The link contains the asm code and explains the obfuscation.

Usually the developers creating open source libraries benefit from the popularity of their projects. The more people using their code, the more well known they are. If nothing else, they feel proud when their software is downloaded N thousands times. In this case, Layervault can expect hundreds of sites to show up around the web looking just like their own.

Regarding the comment in the HTML, you are right, it won't make them feel better, because the design really is meant to look at. It doesn't matter how clever the source code is. That's the disadvantage the designers have, I was just saying I can understand them.

We developers get the credit when someone is using our code. The open source libraries usually require keeping the copyright notice at least in the source file. Anyone looking at the code will know who wrote it. Putting myself in the shoes of the Layervault people, I can understand that it's very hard to accept that someone is presenting as his own work something that it took me years to arrive to via iteration. Remember also the rage of Steve Jobs when he called Android a rip-off and of Dustin Curtis when people started copying the Svbtle designs. In all cases, I think the copyright law is not on their side, and perhaps not even any ethic law, but I can understand why they are pissed.

If the attacker knew about the Juniper bug and thought about a way to convince the network operators to introduce the rule of death themselves, then this is a nice hack indeed. It won't be easy for CloudFare to generically protect against these types of attacks. They could either have mechanisms to revert configurations faster or a way to test new configurations on a single router.