bbayles

Mozilla Planet! That site was a big part of how I immersed myself in open source and software generally. When I was in high school I would read every post on the web site, and eventually started reading it on Google Reader.

It's where I learned about bug trackers, version control, Javascript, CSS, web browser development (obviously), and lots more. It's interesting to drop into a long-running conversation to see how professionals talk about things, and it's a big part of why I'm an open source contributor today.

I've tested a few times - if I floss the day before and day of I don't get the "floss more!" lecture.

Citation needed? I'm just describing the Montessori method, which was developed in the early 1900s. But maybe they were driving "sales revenue" then also?

My partner became involved in Montessori a few years ago, and I've been really impressed with how it works.

If you don't know much about Montessori, here is my "in a nutshell" version: It's a method of schooling usually associated with preschool and elementary education. There are mixed age groups (e.g. 3 to 6) in classrooms. There is at least one adult who gives one-on-one lessons on how to work with "materials." The materials do the teaching, not the adult.

There are hundreds of different types of materials. They're designed to teach or exercise a particular skill, but they look like games and are all designed to be "beautiful" as to entice children to them (Montessori is really serious about this; materials are not allowed to be broken or chipped or worn). They follow a particular progression. Children may work with any material for which they've had a lesson. They can work with it as many times as they like.

My favorite example of how Montessori works is how it develops reading skills. First a child is introduced to materials that involve very short crayons - when they use them they strengthen the muscles in their hands. Then they're introduced to letter-tracing materials. Then they're introduced to letter/sound matching materials. Children who follow these lessons wind up writing first, and then reading follows very naturally. The emphasis on developing physical capabilities first really demonstrates the attention to detail that's typical of Montessori.

The math education progression is impressive also. There are materials that have children doing proto-multiplication, exponentiation, algebraic manipulation, and more. My partner developed a material that teaches counting, addition, and subtraction in base 8. (Her 4 and 5-year-olds understood it much more quickly than her colleagues!)

There are parts of the method I don't like (e.g. dogmatic resistance to rewarding performance, for example), but overall it feels like a huge improvement over typical early childhood education.

I read something once that had a real effect on me in these situations. It was "who says you have to feel like doing something to do it?"

(Is it magic? Of course not. Will it work for everyone? Of course not.)

I have to fight the hipster in me too, but Serial is an example of something that is deservedly popular. It was very entertaining, yes, but very informative. I'd recommend it to anyone who wants to know more about criminal justice.

There's even a tech angle: As a former engineer for a wireless phone company, I thought the explanation of how technical data is used and abused for securing legal convictions to be mind blowing.

You could definitely use Security Onion's tools for that. The full SO distribution is a little bit overkill for that. You could run YAF ([1]) on a box attached to a mirror port to log IP headers and then periodically check it against a tracker.

NetFlow or VPC Flow Logs (in AWS) would work just as well for this also.

[1] http://tools.netsa.cert.org/yaf/index.html

SANS has a slightly dated paper ([1]) about setting up this sort of thing that gives a flavor for how it can work.

I think AWS's VPC Flow Logs are the foundation for better tools (disclaimer, my company develops these tools - [2]). I hope Azure and others follow suit.

[1] https://www.sans.org/reading-room/whitepapers/cloud/security...

[2] https://observable.net/blog/vpc-flow-logs-virtual-private-cl...

I've been a fan of Security Onion for a while. Richard Bejtlich's book "Practice of Network Security Monitoring" discusses setting it up and how to incorporate it into an operations center's routine.

Notably, Security Onion and other tools are very difficult to use in cloud environments where you don't control the network! There are ways of getting a sensor access to the relevant traffic, but they require careful architecture. Even when set up properly, encrypted traffic defeats much of the deep packet inspection-based monitoring.

I didn't really know anything about init systems until 2014 (so I all but missed the systemd wars) when I found myself in need of process synchronization and supervision on various platforms.

My task was pretty straightforward: I had a group of processes that need to start in a certain order, restart if they die, run as a non-root user, and write logs somewhere. I needed to support RHEL 5, 6, and 7, which all use different init systems (sysvinit, upstart, and systemd). I worked with all of them and also experimented with alternatives (runit, s6, Supervisor).

For my task systemd was a pleasure to work with compared to the others. There was a bit of a learning curve, but once I mapped out what I needed to do the solution was obvious.

I found upstart to be almost good, but the version that ships with RHEL 6 is lacking compared to the later versions that came with Ubuntu. The Python-based Supervisor was surprisingly good. I sort of saw why some people might like s6, but runit's charm was lost on me.

sysvinit was by far the worst. I wound up using sysvinit to hand off to Supervisor in order to not spend my life worrying about the number of forks and pidfile locations.

I can't speak to systemd's shortcomings and perceived hegemony in other areas, but when it comes to acting like an init system it is miles ahead of everything else.

I agree that it's perfectly valid, but disagree that it's necessary. Deploying proxies has costs - it obscures the endpoints of communication from sensor software and makes anomaly detection more difficult.

Richard Bejtlich's "Practice of Network Security Monitoring" has a chapter dedicated to the costs and benefits of proxy deployments; I recommend the book for a look at one coherent method of network security monitoring.

This article is OK overall, but I could do without the "I am so brave for exposing this" trope at the beginning. The author presents some new insights, but complaining about the state universities isn't exactly original.

I don't think it's that crazy. Switching to IPv6 is painful. It's a fine standard, and better than IPv4 in most every way, ignoring transaction costs. But IPv4 + NAT persists because it's a smoother path - the same reason why HTML 5 won out against XHTML 2.0.

The need to exempt various types of traffic for business reasons is ultimately why I think monthly data caps will fade away for cable/telco-provided Internet service.

An example would be some provider like Disney saying that in order for Comcast (or some smaller operator) to be able to carry their TV channels they must also zero-rate streaming from their sites. Or Hulu and Verizon do a deal in which Hulu content doesn't count toward a cap on Verizon phones. These things are becoming more common, and I think the difficulty of figuring out which bits count and which ones don't (especially when they all come from the same CDNs) will prove to be more trouble than it's worth.

Quite so. Usually the same in mobile networks, but sometimes backhaul is a limitation there still.

Interesting! I did a search and found one example - Exede? It's encouraging to see some experiments with this.

There are other ways to discriminate, but not many have been actually tried to my knowledge.

One place where I worked studied a model with peak-load throttling. If you're trying to stream 4K video and the network isn't congested, you get full speed. If the network is congested, the subscribers who have been less active during previous peaks get priority and others get throttled. (Actually this was some years ago, before 4K video was a thing, but it's same idea)

Another model I remember studying involved charging for "time using the service" and not "number of bits transferred." This is similar to how voice plans have "anytime" and "off peak" allocations of "minutes."

So there are people thinking about this (or at least there were several years ago), but I'm a little surprised to not see any trials of alternative arrangements.

I previously worked in engineering at ISPs. There are two points to make: (1) Monthly data caps do not help manage congestion, at least not directly. However, non-engineers have a lot of trouble understanding this. (2) Telling customer support agents to say "this is not about congestion management" is a perception-management move. Cable companies are very sensitive to criticism that they are offering a "shared pipe" and that you're somehow not getting what you signed up for.

On the first point: Congestion is problem during peak hours, not during the whole month. You could download a few terabytes over the course of a month and not cause a problem for anyone else, if you avoided peak hours. Data caps only work for congestion management if they discourage you from using services during peak hours.

There's not a grand conspiracy by the cable or mobile companies about this, though - it's mostly a failure to understand this concept, or an unwillingness to go back to peak load pricing (e.g. different night/weekend rates like phone plans have/had).

Right on. If we as a society want to help those whose skills don't command a high monetary value in the market, we should pay for that help as a society (through taxes)!

The Economist describes the incident here: http://www.economist.com/node/149797

Clever! It reminds me of another story of broadcasting information such that only interested parties will receive it.

In 1997, during an auction of wireless spectrum by the FCC, some of the participants colluded by stealthily signaling the geographic region of the licenses they most valued. They made the last few digits of their bids (in dollars), which were visible to all, the area codes of those regions.