HN user
Kiwi in the bay area, working on eBPF.
[ my public key: https://keybase.io/joestringer; my proof: https://keybase.io/joestringer/sigs/Ms8Ah5Koccp2z4eHbFip4fuU4niodt-_HSujfwDK_As ]
The packet-processing BPF programs are less tightly bound to Linux kernel APIs than you might think. Even in Linux, there has been motivation to make the APIs more generic to support different kernel hooks for packets, in particular XDP which doesn't operate on the standard internal packet buffer representation (skbuff).
Even looking at the original BPF which focused on filtering packets as they are forwarded to userspace (think tcpdump)[1] and looking at the extensions that eBPF provides on top to hook into various subsystems[2,3], it's clear that this is going far beyond the use cases originally envisioned. I'd love to see an eBPF paper to follow up / contrast with the '93 USENIX BPF paper.
[1] https://www.tcpdump.org/papers/bpf-usenix93.pdf
[2] https://ebpf.io/what-is-ebpf#hook-overview
[3] http://www.brendangregg.com/BPF/bpf_performance_tools_book.p...
This seems to be around the wrong way.
For both traditional kernel modules and eBPF programs, you compile the code ahead of time. For kernel modules, if you have a bug, you load it into the kernel and the kernel hard crashes at runtime. For eBPF programs, the kernel will reject the program before you inject it.
In practice to deploy eBPF programs, you end up adding the kernel verification step into part of your CI/dev workflow so that by the time you ship your programs, you know that they will safely load and safely run in real environments.
With secure shell, you can make it significantly more useful. Of course, you still need a box to SSH into.
https://chrome.google.com/webstore/detail/secure-shell/pnhec...
What if you clone the repo before the license was added? Then do you get code in the public domain?
crosh is being deprecated in favour of a newer ssh client:
https://chrome.google.com/webstore/detail/secure-shell/pnhec...
Anyone else familiar with "Arbitrary Free Protection"? 'cause it's only turning up one search result for me.
It's actually quite scary to read the comments on TFA and see that indeed, people did know about this breach.
The first step to making software do what humans do, is to analyse what humans do.
Original source.. http://static.springsource.org/spring/docs/2.5.x/api/org/spr...
I'm not sure it is just you. Shorter columns are easier to read, which means it serves users even better; our eyes don't have to track a massive row of characters to see what the search result is.
I came across pipes the other day while attempting to link my twitter feed to a (new) identi.ca account. The concept sounds powerful and I like the idea.. although I'd like to be able to view the source without logging in.
The host-side application could already be written using Java, atleast for OpenCL applications[1] (The kernel--that is, the GPU code--was still written in OpenCL). My only concern is that Java will make it more difficult to find out exactly what's going on in the kernel code, and hence more difficult to optimise.
Now, this also doesn't solve the issue of needing to consider the parallel architecture when coding the kernel to actually make use of the hardware. Nevertheless, kudos to the guys behind this.
I'm not sure it's intended as a face-smear; but even if it is, personally I'd prefer to receive direct communication with criticism than to find out later that there is a community mocking my work.
I'd be curious to see the same analysis done but with alternate keyboard layouts, such as dvorak or colemak.
Has Valve actually confirmed the rumour this time around?
And they support keys -- Although it seems the primary way to use them is by putting your keys into your 'Downloads' folder, which isn't exactly ideal.
Looks like this will eventually replace the inbuilt ssh supplied with crosh (Chromium OS shell)
Well, I think any analogy starts to fall apart when you look too closely. But you've got the right idea. Sure, there's no reason you couldn't distribute it out further. I used the word 'entity' above in an attempt to imply that it could be "one large radio station" or "a group of smaller radio stations"--the point is that the decision-making is abstracted out to somewhere else.
Note also the use of "logically centralized", not "physically centralized".
Perhaps. I would propose that the application of this paradigm to traffic flows would have each intersection making the decisions for the drivers. A car says "I'm heading to east 42nd", and the intersection says "Sure, go left."
Furthermore, traffic controller(s) would constantly gather information about traffic conditions from each intersection, and tell them how to direct the traffic to optimise road usage.
This way, the traffic controller knows everything about the optimal way traffic should flow, and it only has to make decisions based on the number of intersections rather than the number of cars. If you consider that one intersection could have tens of thousands of cars per day, that provides a huge saving in computation.
This differs from the analogy in the article; Intersection = Router, Car = Packet.
Development and releases of the OpenFlow specification have been shifted to the Open Networking Foundation[1], so you can find the latest OpenFlow release (currently 1.2) over there. It has only come out recently though, so actual hardware & software support for the new version of the protocol is still quite young.
The idea is to build a globally consistant view of the network. Currently, each node builds up its own view of the global state and routes based on this. Sure, distributed protocols allow us to share this information, but it's not guaranteed that the state will be accurate a few hops away.
OpenFlow allows an entity to keep a global consistant state, and calculate the rules by which each of the nodes should forward. This logically centralised control can then enable higher utilisation of the network. Think about traffic reports on the radio -- If you are driving and know that there is a bottleneck on one highway, then you can take an alternative route.
EDIT: I use "Global" in this context for within an AS, not necessarily internet-wide.
Nick McKeown's OpenNetworking Summit 2011 presentation entitled "How SDN will Shape Networking"[1] explains very well the abstraction of ideas that Software-Defined Networking provides. OpenFlow is a protocol which implements the idea of SDN.
The protocol doesn't force this centralization to be physical, just logical -- Hyperflow[1] is one example of how a physically distributed control plane can be created.
[1] http://static.usenix.org/event/inm10/tech/full_papers/Tootoo...
I quite enjoy just chucking on a playlist of The Flashbulb (http://www.youtube.com/results?search_query=the+flashbulb).
There tends to be enough ambient, non-lyrical tracks to keep me interested. Some infrequent breakcore tracks get me amped as either a break or a queue to think harder :D.
For those with the RAM to spare, this seems like sensible behaviour -- If there are ways to speed up your web browsing by using otherwise idle RAM, then great!
Unfortunately, the flipside is that if you're using a computer more than a few years old, then anything more than your set of 'core' sites tends to slow your computer to a halt as your browser causes everything to be constantly swapping in and out of memory.