I’m moving my master list of potential future topics here and will extend it over time.
… The hardest decisions to make are the ones where you can’t identify an obviously better or worse choice. Just choose. (triggered by http://lifehacker.com/make-tough-decisions-and-move-on-with-the-two-minute-ru-615962167)
… Do what you are passionate about because you can be world class at it - I administered the Sun networks for they wanted me for physics and math at Temple University. Profs wanted me to switch majors to both because I could be a top student in their topics but I knew I’d be a Salieri or worse, never great, never seeing the problems and geeking and dreaming the solutions. (triggered by http://blogs.wsj.com/economics/2013/07/08/math-science-popular-until-students-realize-theyre-hard/)
… On partners and cofounders - make sure you’re a match in values and goals, of course. Ideally you could all represent biz, tech, internal managemen, finance, marketing well enough to speak with the ‘voice of the company’ to insiders or outsiders, and sync with the others/the domain expert partner. At Akamai, working with Jonathan Seelig (had run the network group, + did BD, + was cofounder) and Tim Weller (CF) was amazing for this reason as we worked together.
(triggered by http://blog.aha.io/index.php/how-to-choose-a-great-co-founder/)
… Link to Matt Ringel’s Akamai post about “don’t spend more than N minutes before asking for help”.
… On hiring - compsci degrees used to ensure that you had written a program of more than a few hundred lines and had worked on a team. Often in the compiler or OS classes. Now we have github and OSS, but fewer universities seem to be doing this. Still, asking about both of these things is useful. Not to strictly no-hire but to know if people have worked in teams before, in particular.
… I used to think every manager should ideally be able to (train to) do the job of everyone in their org, except for maybe CEO. Have seen many horror shows where that was not true. Now I think everyone should have a good BS detector about the functions/roles/tech/mktg/other specialty in their org. Don’t have to do the job but have to be able to make decisions that are consistent and usually correct when there is disagreement. Some people have exceptionally strong BS detectors. Some can just do it all and/or come up to speed super fast. Ideal is both of course.
… Passive/aggression is still hard for me to see and deal with quickly enough. Another, worse, behavior is people who treat me one way because they respect me or feel they have to, but shit on the peons. KEY: Friend the peons and look for people engaging this behavior. They will eventually shit on you. Briding the spark gap is easy for me because I can geek for days on anything of moderate interest. Use such conversations to hear about the from-the-trenches view of the company and people in it. Don’t take any one or two data points too seriously. Develop a drama and agenda detector as well (can be hard).
… Topics in content storage: Erasure coding and its applications.
… Praise people when they do a really cool hack. Even if just in private. Much more harmful than lack of well-places praise is when people get publicly congratulated for wiping their ass well and getting all the klingons. This happens when management in larger companies doesn’t have good BS detection and doesn’t engage enough to stay in touch with the clueful peon class.
… ATT negotiation story - what was said in Mofo bathroom.
… Danny Lewin’s greatness: Being the best but encouraging teams to form and be successful. Bridging the spark gap between clueful ‘peons’ and managemnet in a biggish company was one of the key things he did. Lead from the front, be the hardest working and care the most.
… SDN: What people are excited about ; old-school SDN + config management ; what seems to make sense now and for who ; what seems most likely over the next 1-3 years
… Pressplay story. Write tools or even scripts. If your data fits in RAM on reasonable machines (96gb-1tb now) sometimes clustered fancy solutions are wrong. (triggered by http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html) (http://onstartups.com/tabid/3339/bid/3055/Startups-and-The-Problem-Of-Premature-Scalaculation.aspx)
… But any time you need to buy one bigger machine to replace one other machine and you do it 3 times, get a scale-out soltion.
… Virgin America is awesome. I pay $200+ to upgrade for cross-continental first class vs free upgrades on USAIR if the base fares are the same. Power outlets, seats w/ legrests that go up, can climb out of a window seat without disturbing the guy/gal next to you as much; flight attendants aren’t too loud, quieter 1st class passengers, happier passengers, better food; in 1st class all bags go up top so no worries about bringing a larger laptop case/backpack.
… In PHL airport, if the C line is long, go down to the train. The same platform does C+D terminals. D now has Prepass. But Southwest doesn’t participate. Pthhhhhpt.
… Great people are just people. If you have passion and are pretty smart they will respect what you do and have done. Steve Bellovin story. (ispired by https://medium.com/design-startups/3600f4672b3e, on “Act as If”)
… For super loud flights (Southwest in particular, but pretty much any airline including frequent USAIR 1st class) - highly recommend http://www.earplugstore.com/snproinwhnom.html - not cheap but works well in combo with folding hearing protection (from a shooting range). On the other hand, it’s worth engaging the person in the seat next to you if they want. Regularly have very valuable, fascinating, and profitable conversations (at reasonable volumes) that way! Hearing protection is more for remote passengers who talk loudly, especially if traveling together.
… Remember and be grateful for each step above student wanting to play with fun stuff and/or have money and freedom to do what you want. Remember that when you get frustrated with work/job/customer/employees/investors. When I was in school if someone had offered me $100k/year inflation adjusted to play with computers and networks for the rest of my life I would have signed pretty quickly. Life is much better now with fun geek stuff, freedom, creating things so it’s hard to get too frustrated with bad results.
… Net Neutrality isn’t black/white. Comcast can have their network back when they repay all the subsidies they had by being a monoploy. You also on the other hand can’t tell networks they can’t investigate, block, and rate-shape ddos traffic and traffic that is causing other problems for most customers (though again generally this is not ‘authorized/requested/desired’ traffic in some sense).
… Settlements and traffic ratios can be engineered by the clueful. I pay more if I send you more traffic? I’ll get content providers. The reverse? I’ll get or build search engine customers.
… How netaxs got peering with UUNet, Sprint, ANS, and other biggies of the day.
… How I learned to program - BASIC, C (badly), 6809 assembly, PDP assembly (ahhhh), C (much better), LISP, Scheme, Perl
… Replacing myself with little scripts at united engineers my first week on the job. Write tools. Be lazy. Don’t be overbearing about being clever, though (the politics of it all)
… Riff on Joe Greco’s 2000-ish Usenet architecture description; describe modern Usenet architecture and tools.
… Managing people with geek binary-itis (an “asperger” symptom). Explaining that “it is not sufficient to be correct” and in particular, that if people are being happy and productive there need to be good reasons to go bother them to assuage your geek OCD.
… Technical product management - biggest frustration I had at one large company I was at over many years. I recognize there are many kinds of skills but I do feel that people in product management for tech (especially infrastructure-related) services have to be intellectually curious, read GigaOM, TechCrunch, see what’s coming in how customers, vendors, and service providers are changing. One point of validation: One TPM I was frustrated with over many years asked for and got some raw feedback from me (not personal attack, more functional), took it to heart, and has advanced far organizationally and in the work he does.
… My mother told me - remember that the annoying person you’re dealing with may be in a position of power or influence over/for you in the future. Cultivate friends and treat people well and it will benefit you. Have definitely seen the multi-decade benefit of this.
… Intro to diabetes - Type 1 is no insulin produced. Unknown if viral or autoimmune. Type 2 is insulin resistance. Treatable with drugs. Can lead to Type 1-like function, needing insulin injections/pump. 2 big problems: Low blood sugar causes strange behavior, car accidents, coma, some evidence of long term heart and other damage. Bigger problem is that high blood sugar for (?reasons not well understood?) damange small blood vessels. Causes problems w kidney, eye, heart, hands, feet/legs.
… My disc herniation story - chiropractic, accupuncture, physiatrist, orthopod, physical therapy, and a conversation over poker leading to the super traction machine that fixed it (DRX-9000).
… Starting in a small open-plan office for non-coders, or at least having people work in the same area some of the time, is a great way to sync, ask questions, and generally be high-bandwidth and on the same page. I didn’t understand how powerful it was because the office space we had at netaxs was just 2 rooms where we could at least somewhat hear all converstaions. When we moved to a bigger set of offices, things definitely changed and groups became more insular and isolated.
… If you’re a founder, don’t work from home if you have people in the office. I did that at netaxs and things stalled.
… Agonostic vs atheist. Igor said he’s a militant atheist. I say he’s an agnostic; that is, willing to believe that it’s possible to be presented with evidence of a higher power and not be crazy, but seeing no evidence proving it without requiring faith to date.
… I was never impressed with program correctness proofs. The same logic and problem staement errors are likely to creep in to proofs. I think iteration is a great process, and am a big believer (because it has worked for me) in quickly building “running specification” to give to actual engineering-minded coders. Jeff is a better programmer than I am so encouraging that he agrees. (triggered by http://www.codinghorror.com/blog/2004/11/good-programmers-get-off-their-butts.html)
… about netflow ; netflow for netops ; for ddos ; for forensics ; for SDN ; for network view of APM
… Yes, I drink 6 liters/day of diet soda. Being 300 pounds again would be more unhealthy. (triggered by http://loneprairie.net/diet-coke/)
… Why it’s always nice to be in silicon valley in summer and winter (for an east coast guy). (triggered by http://swizec.com/blog/weather-the-best-thing-about-silicon-valley/swizec/4771)
]]>The background is - I subscribed to a mailing list and shortly thereafter there was a call for feedback posted. One of the points was:
“We’re looking specifically for systems that offer strong search and archiving features, to help manage the wealth of knowledge that [redacted] generates. What other specific functionality should we look for in a new platform?”
This is a closed list so google doesn’t pick up and index the archives.
There was a lot of discussion and it seemed to me that most people really were fine with status quo but wanted to add search.
I was surprised that noone’s done a quick and dirty search hack - the search integrations that are out there are relatively more complex to integrate, though less cumbersome than porting a Unix utility from one variant to another was in the 90s…
I despite posting the code, a demo of it, and an offer to integrate it (I don’t run any mailman sites myself), but…
It turns out that the bigger issue was probably the list/group runners’ wanting to outsource the whole thing and not have volunteers need to maintain things.
So everything’s the same a few months later (though they may move to discourse eventually, which looks awesome).
So in case it’s useful to anyone, the code is below.
Feel free to ping me as I’d be open, depending on my schedule, to moving it from proof of concept to nasty but integrated little hack.
Note - this just operates on a bunch of articles retrieved with wget and put into a directory. Indexing could be done without too much difficulty, but for low search volume, especially on a closed list, it shouldn’t be a problem.
{% codeblock %}
use CGI qw(:standard);
my $searchstr = param(‘search’); my $globalfound = 0;
print “Content-type: text/html\n\n”;
$searchstr =~ s/[\W]//g;
print ”
if (length($searchstr) < 3) { print “
Sorry, your search request ($searchstr) is too short.
“;
exit(0); }
print “
Search Request:
You asked to search for $searchstr
Search Results:
";
foreach $file ()
{
my $inbody = 0;
my $matches = 0;
my $base = "";
my $title = "";
my $date = "";
my $from = "";
open(IN, $file);
while ()
{
if (/ (.*)/) { $title = $1; }
if (/<I>(.*20.*)<\/I>/) { $date = $1 ; }
if (!/Messages so/ && /<B>(.*)<\/B>/) { $from = $1; }
if (/^\<\!\-\-beginarticle/)
{
$inbody = 1;
}
else
{
if ($inbody)
{
if (/^\<\!\-\-endarticle/)
{
$inbody = 0;
}
else
{
if (index($_, $searchstr)> -1)
{
$matches = 1;
}
}
}
}
}
close(IN);
if ($matches)
{
$globalfound++;
print "[$date] <a href=\"$base\"><b>$title</b> ($from)</a>\n";
}
}
if ($globalfound == 0)
{
print "Sorry, no matching articles found.\n";
}
print "
</pre>
<p></body>
</html>
“;</p>
<p>exit;
{% endcodeblock %}</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Making Mistakes Fast]]>
2013-08-12T00:00:00-04:00
2020-12-07T02:07:51-05:00
http://avi.net/2013-08-12-make-mistakes-fast.html
tl;dr - “Wow, you make mistakes too… But you make them REALLY fast.”
Not really sure what category to put this in so I’ll just file it under “hacking”.
Back at Temple University I had been running MUDs (multi-user dungeon games) on
my machine, bigboy.cis.temple.edu. It was a great way to learn Unix IPC and
work on complex C systems, but I had a summer free to hack and I decided I wanted
to build an object-oriented adventure game development system. (The game would
be an environment supporting objects like places, monsters, players, etc, but it
was written in C.)
So I designed a language that resembled a mismash of dBase, Pascal, with
some object-ification. Dr. Kapps told me “semicolons are for lazy compiler
writers” so semicolons became optional.
I spent over a week on the data structures for the parser and game engine
and then it was time to write the code.
The office I inhabited was hot that week so I went out to the lab to start
writing. After a while my friend came up and watched me code for a while.
You know, type type type, compile, fix syntax error and hope you are paying
enough attention to not have any subtle semantic errors along the
way. I think I was doing the parser at the time, just dumb stuff because I
was too lazy to think hard and do lex/yacc.
After a while my friend said to me…
“Wow, you make mistakes too… But you make them REALLY fast!”
Most of the mistakes were just typos, but in some cases it was whacking
away a function or two and re-implementing a different way.
20+ years later, my style is the same - see it enough to know it’s
possible and whack out what I call “running specification”.
That’s how I generally make the first version of something that I
need to do or think needs to exist. But for docs, edge
cases, config parsing, and in some cases scaling, if the code is going
to get used, especially by others,
it’s time to bring in someone who’ll do the actual software engineering.
So was that a compliment or a criticism?
He meant it as a compliment but I took it as a bit of criticism (for
not exerting the focus to just do it perfectly).
And my current take -
Without understanding that it’s OK to try things rapidly as part of the
learning or just implementing process, people get stuck and can stay there
for way too long trying to analyze their way out of it. Wishful coding,
printf() debugging, and other lazy techniques continue to be useful for me.
But… It’d be interesting to see what I could do or at least how I would
do things if I could get un-lazy or un-distracted enough to focus on
precision for hours at a time. I don’t feel like it’s been a blocker as
I know how to identify things that should be done by focus-ers and just
engage them.
]]>
I’ve been using the Logitech Ultra-Thin Keyboard for the iPad mini for a few months now, and have found that the combo makes for a great portable almost-productive combo. ssh, chrome, RDP, and native apps all work but I wouldn’t really want to use it for more than a few hours of light work or 30 minutes of quick fix while on the go.
Yesterday, while dropping my Retinabook off to have the touchpad clicker fixed, I saw that the Zagg stand had their new cover.
Overall I’d say that I prefer it - it’s a bit more solid, and while the Logitech holds the iPad well with a magnetic slot, it’s still a bit awkward to unfold it and set it in the slot. With the Zagg, there is no need to remove the iPad - it just unfolds and is semi-rigid even when holding the whole thing by the keyboard.
… and the control key on the keyboard works, whereas with the Logitech I have to use the on-screen ctrl key in ssh apps (haven’t spent a ton of time trying to debug, though).
The function key is needed to get ~, }, and ] but that’s not the end of the world - even for typing
{% codeblock %} ps auwwx | grep fooblah | grep -v booarg | awk ‘{print $2}’ | xargs kill -9 {% endcodeblock %}
Ultimately the functional ctrl key is more important.
So… I’ve had some issues with Zagg quality and functionality in the past but this new keyboard seems like the best of the batch for me.
And a quick note - I also have the 7” and 9” larger Zagg keyboards. They’re better for typing, the 9” especially, but they make it thick enough that the combination isn’t nearly as portable.
]]>Is network budgeting about saving money or increasing revenue?
Or -
Does squeezing network costs run the risk of impacting users, revenue, or whatever your important metric is?
A bit of both, though the usual focus is mostly on cost.
If your business model is related in any way to customer performance though, this can be a very short-sighted way to look at things.
At AboveNet in the late 1990s, we were aggressively going after traffic sinks (eyeball networks) and trying to peer with them directly, ideally via private interconnect, and ideally with much more total capacity than we needed at the time.
The motto was “QoS should stand for Quantity of Service, not Quality of Service”.
At first this may look pretty expensive - but if you have a positive gross margin on your services, in most cases, the expensive thing is to congest your bandwidth or allow it to be congested.
Every time we turned up substantial new private interconnects we saw traffic go up.
Why? Well, if traffic is congeted, there is a slight increase in traffic from retransmits, but the throughput per stream goes to hell and what happens is outside the TCP stack - users just go away and find something else to do.
At Akamai, we had similar experiences with directly placing boxes into many edge networks - even for networks we peered with (or bought transit from). In many cases, though, juggling was needed to make sure that the boxes had better network connectivity - connecting from within many major networks’ data centers was WORSE than using transit to get to them due to data center network aggregation.
In many cases, the problem is easy to find - a full transit link somewhere. For most networks, I recommend that the NOC or an eng group take a look 3-4 times/day (shift change at the NOC is a good time, especially if the NOC shifts are offset so someone is coming or going every 4 hours). Humans are really good at eyeballing pathological graphs. Take a look at the top 10 transit, peering, customer, and backbone graphs and you can often find links in need of investigation.
If the congestion is ‘behind’ one of your transit providers, though, you’ll need to get more clever.
The first avihack-ish way I did this involved one a large AboveNet content provider. This customer (we’ll call them ddrive) served content of a specific nature that was highly popular. As with many content provider customers, when there were network issues, they would open a ticket claiming that ‘signups are down’, which doesn’t really provide much information to go on to a network engineer.
What I wound up doing was writing a perl program for them that downloaded a daily BGP dump, looked at their signup logs (on their servers), aggregated signups by Origin ASN, and then sent a report to them and to us. From that, we actually could occasionally find that singups were in fact down proportionally in some networks and use that as a way to hunt for connectivity issues. And when we turned up more and more direct connectivity to those networks, signups did in fact go up proportionally to those networks.
AboveNet’s (and Akamai’s) business model worked very well for this since it billed all customers on a usage (vs flat-rate) basis.
That’s one reason that I think that the flat-rate model can be unhealthy - it drives customers towards trying to fill pipes, which hurts their business and ultimately the industry.
So anyway -
How do you find out where these problems are on your network?
The easiest way I know of is with passive monitoring of the TCP statistics - the actual performance of the TCP sessions that your customers are seeing across your network.
There are three places this can be done:
First, on the client. This is messy, as the client environment can be slow. There have been a few service providers to take this approach. Some have been bought, some are very expensive, and I don’t really follow this space thoroughly so perhaps there are better options now.
Second, ‘in the middle’. This is what you’re stuck with if you run a network and don’t interface with smart customers who have TCP statistics. To get stats at this level you’ll need to copy traffic (optical tap or switch SPANning) to boxes that watch the traffic and do TCP state reconstruction. There are some packages that do this (Argus), and at a simple level you can approximate performance by just looking at the time delta between the SYN-ACK and the ACK of the SYN-ACK. Ideally you want to look at peak throughput over periods of time (say, 1-2 seconds) and, most importantly, the retransmit rate/ratio.
Third, and perhaps best, you can grab the TCP statistics from the kernel before it throws them away. The kernel’s already accumulating this data, so it’s just a matter of getting it out. The Web100 patches for Linux do this, and some others have developed custom patches as well. There are some notable tricks with HTTP - with persistent connections, the session may be idle for reasonable lengths of time, so the retransmit ratio and session setup timing will be interesting, but throughput will appear abnormally low. Ideally for that you’d snapshot the stats at every transaction end, which can be done by the application if you set up a path to query the TCP stats for the socket.
Some other approaches to consider:
For readnews, I wanted a simple passive monitoring system and played with both Argus and Web100. Being a fussy geek, neither exactly suited. Generally I prefer not to run custom kernels, and I also didn’t want to set up a bank of machines and stripe with hashing or other hackery.
So I instrumented the Usenet server software to throw a log entry when the response started and a log entry when the last \r\n.\r\n was sent, and we have some perl code that trolls the logs computing throughput per transaction, aggregating by origin AS, and throwing the results into various RRDs.
The most generally-applicable way for http-based applications is pretty simple, but in my experience rarely done - just turn on start and stop time for http transactions!
Most web logs only have the time the transaction started, which doesn’t really help. With start and stop time, and object/transaction size, you have all the data you need to catch the gross badness and look for repeated throughput that’s less than N kbps (say 200) and aggregate/alert/etc. You could even do that by POP, machine, and URL base and find application or application components that are slow to everywhere, in addition to looking for destinations that are slow to all application segments.
Anyway, hope this helps or at least inspires some insight and network monitoring projects!
]]>I’ve experienced this first-hand from both sides.
The benefits continue to accrue from the Internet Routing articles and tutorials that I started doing in the mid-1990, but I also have realized that the people who I learned from indirectly are just smart guys that I can hang out with, geek with, and even debate with and assist.
I started the Internet tutorials because I was quite upset with how hard it was to come up to speed about routing, BGP, peering, transit, and generally understanding how the Internet works and how to play in the ‘big boy’ sandbox of networking.
15 years later, I still run into people who are networking professionals who think I ‘invented’ BGP, and the sales people I work with run into CIOs and VPs in enterprise IT who were helped out by the routing tutorials or inet-access mailing list posts.
One thing that I find helps and is a good indicator that you may have something interesting to write about is whether you just learned something that was full of things that were confusing that shouldn’t have been - that is, sub-topics that, once puzzled out, were not that hard after all (just poorly-explained).
Luckily, I remembered most of the things that frustrated me - Cisco-specific terminology, strange Cisco CLI issues, iBGP vs eBGP complexity (this was before any easily-approachable book on BGP was available). When I realized how simple some of the issues were when I ultimately figured them out, they stuck in my head long enough for easy recall when I decided to start documenting the Internet infrastructure.
That’s probably key - write about something while you remember what confused you when you were learning it. I’m quite sure that noone would want to learn to program from me. All I could say is to keep playing with it until you figure it out. I learned when I was 8, and took (and still take) that approach. I remember trying to type a basic program in and (please no laughs) not really getting what a subroutine was and omitting the lines with RETURN because I thought well, I’m hitting RETURN anyway to enter the command. Then I read some more, got it, and moved on.
For the routing tutorials, my intended audience for the geekly bits was the vast set of people familiar with basic routing on computers, but who had no routing terminology background.
I think there continues to be a big need, and I’m not sure the eHows and Demand Medias will really address the problem.
For highly specialized topics, the state of the art of approachable introductory material to given topics is generally pretty sad. I’d encourage you, the next time you find yourself just having come up to speed on a particular topic in your or another field, to document it. You’ll benefit, either by gaining even more insight as you write it up, or by personal exposure - Google and Bing crawlers are good enough to find pages, especially if you have other content you’ve generated on your site.
Topics in your field are probably the easiest, but as an examples of some topics outside the geekly fields that I have on my list to write up:
1) Explaining the basics of diabetes to smart, generally-educated people. My wife has Type 1 and I am still amazed and how poor some of the introductory FAQs are, and I still have some basic questions that they don’t seem to answer - particularly about the sugar and fat metabolism, and how the body recovers on its own from low blood sugar, the relation to the use of Glucagon and the body’s manufacture of it.
2) Documenting what I’ve learned from having a disc herniation (image 1) (image 2) (image 3). It’s now symptom-free but got bad enough to require painkillers for uninterrupted sleep. I was completely frustrated with the lack of clear and good explanation of the typical course of treatment, and even more frustrated at the lack of the ubiquity of disc decompression as a recommended option after NSAIDs and physical therapy. In my case, it was a former pitchman for a company that made specialized traction devices (look at the VAX-D and DRX9000) that led me to get treatment using a DRX, which cured my symptoms after the second treatment. Even more frustrating was that the Physiatrists and Orthopaedists that I saw were unwilling to answer some of my basic questions and were also unwilling to explain the course of treatment beyond the current step that they were recommending.
]]>Like many, I was frustrated with the overview system functionality in diablo as retention volume started to grow a few years back.
The real issue started back in the 32 bit days when the Linux mmap() need to allocate contiguous ram per process was biting us with boneless and other groups.
Our first fix was to just go from mmap() to file semantics - open(), close(), pread64(), etc. We actually saw that either go faster or at least not slower than the mmap()-based access, and have been running that for 4 years.
About 3 years ago, I finally got really pissed off at the monolithic overview indices, largely in combination with dexpireover sometimes getting confused and eating data files just because the overview index got corrupted or dexpireover got confused. Secondarily of course, it would be nice to have a solution that allows for retention of articls from the moment the group is created (the standard dexpireover throws away any data files that dreaderd didn’t store index data for).
What I wound up going with was to put the overview index data for each article INTO the data files.
All that’s left in the over.* file is the OverHead struct, basically:
{% codeblock %} -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.80011c3e.6087a5f3 -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.8100543e.40107707 -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.829a403e.5597596f -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.836c1d3e.0d9a576d -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.8396433e.6478c8a5 -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.83c8ed3e.603853f4 -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.8463b93e.3c18a685 -rw-r—r— 1 news news 276 2007-10-09 10:34 over.0.8472e03e.34c925c1 {% endcodeblock %}
(We ran a conversion program to convert everything to the new format, so the oldest stuff all has the same date…)
Then in each data file it is:
{% codeblock lang:c %}
{% endcodeblock %}
So to make a new file:
{% codeblock lang:c %} ftruncate( od->od_HFd, VERSION4_PADDING_SIZE + ( ov->ov_Head.v.dataEntries * sizeof(OverArt) ) ); {% endcodeblock %}
And to get an OverArt:
{% codeblock lang:c %} pread64( ov->ov_HCache->od_HFd, oa, sizeof(OverArt), VERSION4_PADDING_SIZE + ( (artno - ov->ov_HCache->od_ArtBase) * sizeof(OverArt) ) ); {% endcodeblock %}
Now, the major downside of this approach is that canceling article headers becomes much harder (have to touch O(# of data files) to cancel by mid), which we deal with by not canceling headers…
Cancelling article bodies has been fine for dealing with DMCA requests. We’ve actually commented out the code to do header cancellation, though it could be supported. Doing scans for 4 billion-article groups, with data files that are sometimes stored compressed (that’s another article), would take a loooong time.
Advantages of the approach include:
We actually have a multi-threaded reader/finder with overview proxying, but just thinking about implementing overview proxying in dreaderd caused blood to come out of my ears, and NFS mounting has been working well for us for a few years. Now, that means having a dreaderd server NFS re-export its volumes to other readers. HA is left as an exercise for the reader. If you’re at really large scale you can even go SSD, though 18TB of SSD is probably pushing things. Or you can use a compressing filesystem on SSD (what we’re experimenting with in a new deployment). Nehalms are fast. For optimal results, you may even want to do a unionfs and then migrate ‘mature’ data files to the SSD filesystem(s) one they’re full of entries.
Start being able to store (forever) headers for newly created groups.
No dexpireover process. No rebuilding overview indices.
There is a program, nbupdate, that can be used to scan the disks and update the NB counter if one does do expiration, and there is a janky perl script that is lying around somewhere to cancel by deleting data files, but soon after we converted, the infinite retention race began, so this hasn’t been an issue for the last few years.
You can compress the data.* files (if you can do on-the-fly decompress, and get compression on the index data as well)
The code is mostly in group.c, with a few lines in nntp.c. The overview conversion program and nbupdate are C. The scripts are all perl.
But…
This was implemented as running specification that sort of just worked, so has never been prettified
Also, it has only been tested (and scripts are hard-coded) for the older hash system we use (over.* and data.*)
The overview conversion program can create overview index entries for data files. When we did the initial conversion we had actually stopped deleting data files as part of dexpireover a year before, and after the conversion we could reference those articles.
So… the conversion program does use the oa_ArtSize and oa_TimeRcvd from the old overview index if it is there, but if not it fudges. We didn’t get any complaints from fudging oa_ArtSize, but it was a concern. - And, as mentioned, it’s not beautiful code, especially the overview conversion and nbupdate code.
So…
If there is interest, I’d be willing to give the code over to someone to prettify, or potentially do it myself. If noone cares any more (which I suspect may be the case given list traffic and the insane current scale of things limiting the people who care about doing up years worth of overviews), that’s fine too of course.
Avi Freedman readnews.com
(Postscript: Aug 29, 2011 - no one cared. The 3 other remaining large Usenet sites all did their own modifcations, and most of the other folks who wrote me about this wound up outsourcing anyway.)
]]>Reasonable battery life (vs Evo). Will still probably want a fattery but it is pretty slim, great keyboard feel, great screen, fast enough, 4g w/ hostpsot is great.
I still have to use a blackberry as my main device; too much mail to delete without a del key, though I’ll poke around Android mail apps again at some point.
Mainly I use it for connectbot, greader pro, web browsing, kindle, occasional nav, and occasional hotspot. Meaning some days not at all.
The big problem I had was generating a control key with connectbot. Eventually I’ll download the android SDK and play w/ connectbot code but for now I mapped ccc in screen to ^C which gets me what I really need (to be able to use vi or kill a bad shell cmd entry, or bw monitoring script, etc).
]]>Oh well, back it goes. It might be a keeper if I didn’t like the Vaio Z better for resolution, form factor (usability in coach), and built-in broadband and the Vaio X better for massive battery life with usable resolution.
]]>For some time I’ve wanted to start blogging, but as is often the case, when I start looking at the popular software it all seems like a major time commitment to make it do what I really want. I came closest with WordPress, where I spent some energy on code, and blogspot (protosite here), which looked simple enough and easy to extract the content from later. I was really itching to write something simple to get started, but didn’t have the plan in my head.
However, I am really overdue to start some cloud architecture and technology evangelism, so figuring out the solution had hit the top10 of my todofile.
This week I stumbled upon Jekyll, which implemented an even better version of a simple geekly system for blogging. It’s written in ruby, which isn’t my favorite, but integrates simple logic to support various simple text markup systems (I’m using textile, which is the default).
All you do is edit text files and run jekyll to re-assemble your site into static files. Most people using jekyll use an offboard commenting engine, often disqus. Edit, assemble, rsync to the final location, done. It can be automated in various ways (often based on using git or other source code control systems).
Anyway, what you see is the first version. I’ll probably find someone to work with me on layout/design. Something more like the blogspot template, perhaps.
And if I get too frustrated or decide I can’t stand ruby, I can always write something in perl to take the source files and do things differently.
Thanks, Tom, Nick, and the other Jekyll contributors!
]]>
