Farewell, Multiply

I was able to build JNOS on the Pi, and better yet, I was able to build the headless version and run it as a service.  Very nice. OK, there were some flaky things around running JNOS as a service that I'm not so sure I completely understand, but I can say    systemctl start jnos.service    systemctl status jnos.service    systemctl stop jnos.service and it all seems to work.  I haven't always been successful with    systemctl enable jnos.service but I think that will succumb with a little more beating my head against the wall. (Fedora is just about complete with the systemd conversion, so although the service jnos start stuff still works, it is the old thing, and probably will disappear at some point.) One hiccup I observed.  In making it headless, I wanted to deconfigure as many options as possible.  I had trouble on F17 making the headless version work, but I had configured in everything I thought I might some day like to play with.  On the Pi I took the alternate approach of configuring out everything I didn't absolutely need. The problem here is Maiko has a bit of a bug.  At the end of config.h he makes sure that if, for example, you select NETROM off, anything that depends on NETROM is also off.  But he missed something (and of course now I forget what it was!)  Fortunately, this caused JNOS not to build instead of occasionally hanging later, so finding what I missed wasn't too much of an issue. So, on to running JNOS on the Pi.  Well, first thing I ran into an uh-oh.  The minute I started JNOS the OS hung.  Eventually, I concluded that the system hung as soon as I tried to attach the TNC-X.  I got the same result with the normal Fedora 18 as well as with the new Pidora. Wondering whether the problem was in JNOS or lower in the stack, I connected the TNC and tried to poke it with gtkterm.  As soon as I selected ttyUSB0 the Pi hung! The USB chip in the TNC-X is basically a USB to Serial converter, so I tried a couple of others, and no problem with them.  Unfortunately, all the USB to Serial converters I had, all two of them, used the same chip, so I can't be sure, but it looks as if the issue is related to the chip in the TNC-X. Since this worked on Fedora 17, perhaps I could make it work on some other Rasperry Pi operating system.  I had both Wheezy and Arch Linux for the Pi, so I decided to try them. Unfortunately, I am sufficiently immersed in Fedora that these other distros are just weird, particularly their package managers.  Wheezy's apt-get wasn't too strange, but I couldn't figure out how to search the repos, and it is clear that the packages have different names than I'm used to, so I couldn't install a package that messes with the serial port, nor could I install enough stuff to build JNOS.  Arch Linux was even worse.  While I could browse their repos on the web and see what was there, Pacman didn't seem to do anything useful. So, I posted a bug around the USB to serial converter and on to the next idea. Actually, there are two potential courses here.  JNOS won't use the native AX.25 stack since it has its own, but soundmodem could be a nice, cheap approach. Unfortunately, the Raspberry Pi only has sound out, so it would require a soundcard dongle and some sort of transmit/receive circuitry, so not as simple as I would like.  Still, a transistor and a sound or modem chip might be put on a daughter card pretty cheaply, so that idea isn't totally scratched off the list. The other approach, somewhat simpler but more expensive, is to use a normal USB to serial converter with a TNC-X.  Along the same lines, the newer TNC-X's use a different USB chip, so they might well work. I tried converting my TNC-X back to serial, but the result was weird.  When JNOS said to transmit, the transmit light came on but no audio came out.  Evidently, there is some jumper or another that I missed, so the next thing is probably to track that down. But it looks like I need to order another TNC-X and maybe another Raspberry Pi or two while I'm at it, perhaps even a sound chip.  An even more interesting possibility is to convert the TNC-X code to the dsPIC, which has enough gas to generate and detect the tones itself, making for a single-chip daughter card.  The newer TNC-X code, as far as I know, hasn't been published, but the original has, and I suspect a lot of the stuff in the newer code has to do with his GPS and APRS addons so probably not interesting anyway. And going back to the top, I really need to find someone to take point on a project to construct a few gateways between our packet network and the NTSD/WinLink network.  Supposedly doable, but not yet demonstrated, and then of course there is the issue of supporting something permanent. Ahh, so much fun to be had, so little time. 73 de WB8RCR

2012-02-03 MCSAR extraction training.  Rolling subject onto a stretcher using a blanket, properly securing subject into a Stokes basket, required first aid equipment - a very full classroom session.  Then teams went into the field, located a "victim", checked with EMS for permission to transport, then extracted from the Averill Conservatory.

The proposed dsPIC-EL would utilize the dsPIC30F4011 which is a 40 pin part which includes 48K of Flash, 8K of RAM, 30 I/O pins, 2 UARTs, 1 SPI port, one I2C port, 4 CCP/PWM ports, 6 motor control PWM channels, a quadrature encoder interface, 5 timers, and a 9 channel/1ksps A/D converter.  With the commonly available 7.3728 MHz crystal, the 4011 will run at just over 29MIPS.  The 7.3728 MHz crystal has the added advantage of dividing directly to most common serial baud rates.  The dsPIC30F4011 currently costs $5.70 quantity one from Microchip Direct.

The Telegraph reports a large number of British and U.S. warships are massing near the Straits of Hormuz. Their read is that this is preparation for an Israeli strike on Iran.  The official story is apparently war games.  Curious, none of the U.S. outlets seem to have this story. In a (supposedly) unrelated report, Israel is moving its larger bases away from populated areas, ostensibly to realize the dream of "making the desert bloom". Now, think about this for a moment.  If we are at war with Iran, there is virtually no chance of Obama NOT getting re-elected.  If things are wild in October, he might avoid some potentially embarrassing debates. Am I reading too much into these events?

This is a short video showing a test of the 4011 LCD library which has been inserted into the standard C I/O stack, so the LCD may be written with normal printf's.  The display is a Newhaven Display 2x16 negative display.

Saturday, Midland County Search and Rescue held a Field Team Leader training session at the Midland City Forest.  These are the teams that went into the woods to locate the "subject".   The training largely involved leadership, navigation and flagging.  The "subject" was a particular tree.

H/T Jan Wildeboer: 21 years ago: Tim Berners-Lee announced the World Wide Web. "This project is experimental and of course comes without any warranty   whatsoever. However, it could start a revolution in information access." Yep, it did. https://groups.google.com/forum/?fromgroups#!topic/comp.sys.next.announce/avWAjISncfw[1-25]

Sigh.  The "next Multiply" activities are very discouraging. First, we have anotherblogspot.com.  I have to applaud herbearjc for taking the bull by the horns and making something happen, but I don't think it will last. He took an existing FOSS application (good plan), put it on a commercial host (for starters, another good plan), and is hacking away at it trying to make it look like Multiply. Unfortunately, the starting point is a LONG way from Multiply.  I doubt very much he will be able to get close enough to make it appealing.  There is something about Multiply that makes it so much nicer than Facebook or Blogspot, or Wordpress, or livejournal, and it is hard to put your finger on just what that is. But there is another problem.  The site is already quite slow, and as it develops and gets more users, it will get slower.  If it keeps expanding, the bandwidth costs are going to become unmanageable.  That's the thing about the off the shelf hosting providers; they are quite affordable for low bandwidth sites, but as you add users and increase the bandwidth demand, the costs explode. Plus, as basically one individual doing this as a personal project, at some point he is going to get fed up with it.  I give it two years, tops. Paul and Kimberly are going at it from entirely the other direction.  They realize they need a business plan so they are working that angle. Now, Kimberly clearly has a LOT on the ball.  Paul hasn't really provided me enough data to be able to judge, but there is at least some evidence he hasn't got a clue. Their problem is that they are convinced they need to build their own datacenter. Not only is this an expensive undertaking, but it entails long term costs that are far more manageable when shared with others through some commercial host or the cloud.  The probability of them ever getting off the ground seems slim, although they are at least looking at some of the hard problems. Their main concern seems to be privacy, which is really kind of worrisome.  They have this illusion that if they control the hardware it will be more secure than if a team of experts is adding to their own security.  This is a fairly common fantasy among folks with relatively little experience. If they ever get it off the ground they are going to have to charge big time to support their private infrastructure. I don't see it becoming a reality. herbearjc may have a more economic model, if he can 1) find some income source and 2) recognize the need to change models over time.  He can buy bandwidth and cycles, and at some point move to the cloud or to a large scale provider, perhaps first the cloud and then to an Akami or somebody like that. But he somehow needs to build a sustainable business structure, and I see no evidence of that happening.

Well, like so many others, I am disappointed.  Multiply has tended to be more "personal" than other SN sites.  Over time I've taken less advantage of that. As much as I enjoy the late night chats, even the debates, they eat too much time that I don't have. I am on a number of other sites, mostly with some purpose. Of course, like everyone, I'm on FB, and there I am connected to many of my Multiply friends.  I hate all the game stuff, and although I have managed to block all the stupid game requests when I access FB from my PC, those blocks seem to be ignored on my phone.  All that noise on the small screen makes the mobile application pretty much useless. I do blog on LiveJournal from time to time.  Mostly that is intended to be Fedora stuff, and lately it has been only cross posts from Multiply of those posts I want to share with my Fedora friends. http://jjpmcd.livejournal.com/ I'm also on Linkedin, that's mostly Emcomm folks and former co-workers; there's like a bazillion "groups" on Linkedin, but I rarely post on any of them.  Seems like most of them are places for headhunters and similar folks to advertise, although there are some groups that seem to be pretty interesting, but to be useful they take too much time. Oh, and don't forget G+.  This is basically FB without the games, and it could be really good except that not a lot of folks are on it. And of course twitter and identi.ca.  These are, of course, a totally different model, but still useful.  Admittedly, I don't check either as often as I should. None of these, tho, comes close to Multiply in the really great combination of features.  Is there another similar thing anywhere?

Today I was in Lansing for a Tabletop Exercise.  Governor Snyder attended.  I have to say, I was favorably impressed with how engaged he was, and his spin on several issues that arose during the exercise. On the drive home I got thinking about emergency management, politicians, and governing. For a politician, emergency management is a good thing to stay away from.  I'm sure the governor has lots on his plate, and has to be careful where he spends his time.  The community of responders is relatively stable, so if there's a screw up somewhere, there is bound to be someone around to blame it on that was appointed by your predecessor. On the other hand, if things are done right, nobody ever knows.  So if you are a politician, there is simply no gain to be had from spending time on emergency management. On the other hand, if you are the governor of a state, and take your responsibilities seriously, there can't be a lot of priorities higher than keeping the citizens of your state safe. It appears to me that Snyder may well be the guy he claimed to be during his campaign.  Given the degree of confidence I have in elected officials lately, that is very disorienting.

I first tinkered with MPLAB-X during beta.  Although it was promising, it seemed flaky enough that I didn't want to move to it yet, plus, I wasn't doing a lot of PIC stuff anyway. More recently I've been doing a bit more with the PIC.  I had installed the release version but had quite a few problems so I put it on the back burner.  I thought maybe it was time to go back and see whether it was going to be a good thing.  All of this is based on MPLAB-X version 1.00 on Fedora 16. For whatever reason, perhaps updated libraries, perhaps the last time I played with it I had got the configuration right, whatever, but it worked quite well for me.  Mostly I used the C30 toolchain, although I did tinker with the C18 toolchain. One of the first things you notice is that the buttons are all different.  Nicer looking to be sure, but since they don't look like the old version, confusing. One of the very nice features is that there is a build, program and run button.  That is a departure from MPLAB 8 where they are all separate steps.  Also, instead of having production and debug configurations and targets, you can simply click "Debug this project" and the project gets rebuilt for debugging, programmed and started.  As in earlier versions, the debug buttons don't show up until you start the debugger. Another big change is that the window is tiled.  You could set MPLAB 8 up that way if you wished, but when debugging you need so many windows that it is pretty unwieldy.  On MPLAB-X, though, everything is tabbed, so the tiled model is actually pretty nice.  Once you get the idea of where things are, you aren't always hunting for hidden windows like in earlier versions. The left hand area has a number of surprising choices.  The most obvious, perhaps, is the dashboard.  This seems to take a page from Piklab, but there are a couple of nice features, like bars showing memory used and a section showing the status of the programmer. You can have multiple projects open at once, and the "Projects" tab shows all the open projects, and allows you to navigate for files in those projects.  the "Files" tab is similar, but also allows navigating the various project subdirectories for object files, executables, etc.  Yes, MPLAB-X makes a number of subdirectories so your main project directory doesn't get cluttered with all the odd MPLAB created files. The services tab allows you to add team servers like java.net to your project,  also issue trackers such as bugzilla.  I tried adding a local instance of bugzilla with no joy.  Not sure if it's broken or something lacking from my bugzilla instance.  the only other issue tracker available is JIRA.  Whether Trac or similar trackers could be added reasonably I have no idea. But to a degree that fits.  There is also a "Team" menu that allows connecting with CVS, Mercurial or Subversion.  Where is git?  Who knows.  Seems odd to have all these old RCSs and not the most popular.  But it appears that perhaps the Pony Express doesn't make it out to Arizona with news more than once a decade.  Still a step up from the time when the only choice was SourceSafe. On the bottom is a tabbed area very similar to the "Output" window in earlier versions, but with a lot more capability.  Besides showing you the compiler output and the status of the programmer/debugger, it also has a very cool "variables" tab when debugging.  If you halt in a function, this tab shows the values of all the automatic variables in the function, as well as any watches you have defined.  This really cuts the need for the various debugging windows, and automatically shows you the exact things you probably want to see. There is also a tab showing all the breakpoints you have defined, along with checkboxes allowing you to disable them without having to track down the source line.  But wait, there's more.  When debugging, hovering over a variable will show you its current value (if it is in scope, of course), and if it is a structure, will even show you the bits and pieces -- especially handy for special function registers. For your static variables, it also shows the address of each element.  Very, very handy. MPLAB-X starts very slowly, being a huge Java app I suppose that isn't much of a surprise, but once started, it seems to be quite speedy.  It seems especially quick for compiling and programming, odd, since it apparently uses the same compilers as MPLAB 8.  The build, program and run button, one of the most common things to do during development, seems especially quick. But there are some things that seem to take an inordinate amount of time.  When a program is running, placing into reset seems to take forever.  A simple task like that shouldn't take visible time, but it is at least 3 seconds on a very fast computer.  Releasing from reset also seems slow, but nothing like holding the target in reset. Probably the biggest win, though, is the editor.  It seems to make a lot more sense than the old one, especially with tabs.    It automatically puts in closing parentheses and braces, but unlike most other editors, if you habitually type that closing paren, yours simply writes over the provided one, unlike other editors where you may find yourself constantly erasing extra parens. If you click on a variable or function, it highlights all other occurrences of that variable or function on screen, and places little tic marks to the right of anywhere else that function appears within the file, so you can even track down off screen occurrences easily. The right-click menu lets you go straight to the declaration (or header or implementation in C++),  find other occurrences, etc.  It will even generate a call graph. With all these features, though, I am still left with the feeling that there are important features from earlier versions of MPLAB missing.  The more I use MPLAB-X, though, the less I feel that, and the more it does seem like a significant step up. Now if I can just figure out how to make a git plugin ...

So now I'm sitting here grumbling, scratching my head, wondering what my next move is.

Breathtaking http://www.fedsocblog.com/blog/justice_ginsburg_advises_egypt_to_look_to_south_african_not_u.s._const/ Even if the SA constitution didn't include some really abhorrent stuff, for a sitting Justice to make such comments borders on treason.

This post, rather long and geeky, is more of an attempt to record a little project for myself, but I am copying it to the Planet, even though it has little Fedora content, because my fellow Fedorans deserve an occasional peek at just how weird I am! For Christmas, Santa brought me a PIC24FJ256DA210 Development Board.  This is quite a cool board, with an especially cool PIC.  The board includes the obligatory buttons and LEDs, along with a PICtail socket, Host, Device and OTG USB ports, a serial port, parallel and SPI Flash, SRAM, mTouch pads, and a display connector.  Plugged into the display connector is a 3.2" TFT display with a resistive touch panel. The PIC24FJ256DA210 itself is quite interesting, including not only USB and PMP, and gobs and gobs of Flash and RAM (by PIC standards), but also a graphics controller.  I had done some graphics a while back on a 24F on the Explorer 16 Development Board.  I was interested in seeing how things changed with the controller on the PIC. The demo app was pretty neat, one of the (many) things it did was to read JPGs off a thumb drive and display them.  On a PIC this is kind of a big deal since few PICs even have a USB stack, let alone the capability to interpret the FAT filesystem and decode JPGs in finite time. In looking for a project to get my head around this thing, it turned out that a friend (N8ERO) was working on decoding the output from a TV remote. He was trying to draw the output graphically on a little black and white LCD.  It occurred to me that this was a sort of interesting project and would exercise the PIC. I began by coming up with a scrolling graph on the Explorer 16 since I was already familiar with the older version of the Microchip Graphics Library, and I thought a speed comparison would be interesting.  Since I didn't need the touch screen for this application, but did need speed, I stuck to the graphics primitives portion of the library and avoided the Graphics Object Layer (GOL).  Although the scrolling wasn't terribly fast, handled by redrawing rather than memory copying, it was still pretty tolerable on the PIC24FJ128GA010, so now off to the the PIC24FJ256DA210 to see what the graphics controller could do with a pretty simple case. (For the pathologically curious, the code for all these little exercises is on gitorious at https://gitorious.org/pic16/graphtest/trees - there's actually nothing in the master branch; each of these experiments is in its own branch.  The GA010 display is in graphAD branch.) Microchip has some pretty slick hardware, but their software has never been anything to write home about.  The older Graphics Library had a mess of directories and files that made little sense.  I was hopeful that the new library would be an improvement. Well, it was worse.  "Back in the day", you could download the Graphics Library.  Now, you need to download the "Microchip Application Library", which includes not just the Graphics Library, but all sorts of other things.  It isn't that the download is so burdensome, or the disk space is unmanageable, but the addition of all the other features, even if they are pretty neat, gives Microchip the opportunity to make it even more of a mess than it was before. And it gets worse.  over the past few years Microchip has added a number of experimenter boards to their stable, including quite a collection of displays and a few graphics controllers.  When you dig down into the source, every line of code is preceded by about a half page of #ifdefs to select the appropriate PIC, board, controller, display panel and touch controller combination.  In some cases there are choices between serial and USB interfaces and SPI or parallel external flash. It is totally unreadable. There are no actual "libraries" in the Graphics Library, something I thought a little odd.  Their sample projects include lots of source files into the project.  Well, of course, you need to set all those various #defines before compiling the code.  In many cases it isn't at all clear how you get some symbol or another defined without editing the Microchip code, but with a lot of digging you can get around it with our old friend -D.  (Would have been nice if the documentation provided a clue, tho.) Speaking of documentation, there is quite a bit.  Most of it .chm files.  Now, .chm files in general tend to be trash.  The templates that Visual Studio provides lead the developer down the path of useless help files.  But to Microchip's credit, the MPLAB help files are among the best I've seen. Unfortunately, the files provided with the application library are a newer version than can be handled by anything I could find in Fedora, newer even than could be read on the XP image I have on a VM.  Fortunately, the critical (to me) stuff was also available as .pdf.  There's a lot of stuff there I would like to explore that is only in .chm files, tho. Sadly, the documentation is mostly disjointed.  They do have a pretty nice function reference for the Graphics Library, but it doesn't give you any help as to what the dependencies are, what symbols need to be defined for what purposes, etc.  There are other documents that help you figure out how to set the two dozen jumpers on the board, but those documents are scattered.  The best bet seems to be reading the schematics.  Those are annoying because they are spread out over umpteen pages.  I would rather deal with a humongous fold-out like Icom does.  A bit unweildy but at least you can trace lines with some degree of confidence. After a bit of a struggle I managed to get my GA010 code working on the DA210, and the speed improvement was startling.  Even without using features of the controller the display was almost 20 times faster, although it felt faster than that. (graphAD-DA branch). Earl provided me with an IR sensor he had ripped out of an old VCR or something.  I tacked it onto a PICtail prototyping board I had been using for various experiments, and when supplied with 5 volts, it seemed to be able to see my remote.  Unfortunately, it was totally blind when powered with 3.3 volts.  This is a problem.  The PIC24's are 3.3 volt parts.  Although the DA210 isn't a horribly expensive part, it is a TQFP100.  I've been able to deal with parts like that before, and although possible, it isn't any fun at all.  I really wanted to avoid damaging the PIC. But I'm also a big fan of simple, so rather than some elaborate voltage conversion scheme, I simply put a 10K between the sensor and the PIC on the theory that the sensor wouldn't be able to drive damaging current into the PIC through the 10K. So, now we have the IR sensor connected to the PIC, but the PIC didn't seem to be able to detct anything.  Most of the PIC lines are used for the graphics controller.  Even tho the DA210 has 100 pins, the board has enough different functions that every pin has multiple uses.  The pins connected to the buttons, which are share by mTouch pads and LEDs, seemed to be the best bet, and I count convince myself that I had the right pin by putting my meter on the PICtail and pushing the button, but still the PIC couldn't see anything. After spending way too much time, I realized that the pull ups for the pushbuttons couldn't be overpowered through the 10K by the sensor.  But another blatantly obvious thing I should have seen; the pushbutton was enabled by a jumper!  Simply removing the jumper allowed the PIC to see the sensor. Up to this point the slugging had been pretty slow.  Every step became a battle.  But from here on, once I had my head around the graphics so-called library and the board, things went surprisingly well.  From here on the vast majority of time was spent, well, tinkering.  I can really get wrapped up in making this or that look just right.  Foolish, really, since I have absolutely no eye for making things look right! As I looked at the data from the sensor it became obvious that a scrolling display wasn't going to be much help.  Ultimately, the point is to be able to decode the pulses from the remote.  There were a LOT of pulses going by very fast.  If the data were scrolling by there would be no opportunity to examine it to look for patterns. So, the scrolling display went out the window, in preference to a static graph. (readIR).  The approach I used, since I didn't know the speed, was to sample the data and put it in an array, then plot the data after the fact.  The PIC24DA256DA210 has a lot of RAM, so a fairly large array wasn't out of the question.  I could then adjust the sampling time without messing with the graphing code until I could see the relative length of the pulses. But, it turns out there are a LOT of pulses.  Given the 320x240 resolution of the little display I couldn't display even a significant fraction on them, and even if I could, the display wouldn't make much sense. So, the next optimization was to make the array very large, and display the data a page at a time.  This was effective, and made for a nice display, but still it was difficult to make sense out of what I was seeing. At this point I started digging around on the web to see if I could come up with the codes for my remote.  Unfortunately, not only did I not find my particular remote, but different sites seemed to have entirely different opinions of how to interpret the data stream. It seemed to me that a less pretty approach might be more enlightening.  So the next approach was to display a string of characters, green for a low and white for high.  This evolved to displaying underbars for low and a digit, increasing as the pulse persisted, for high.  This made it quickly obvious that, other than the start pulse, there were only two pulse lengths.  Short pulses were either 1 or 2 samples, long 7 or 8 (after adjusting the sampling time to optimize the display).  (listIR commit 58bfdd2) Once it became evident I only had two states, it seemed obvious to convert the pulse train into a number, using 0 for a short pulse and 1 for a long pulse.  Now I could easily see whether I had the timing right and understood the signal; if the same button resulted in the same number, and a different button gave a different number, I was close to having it decoded. So initially I was pretty timid; get the number, look for one of a few hits in a case statement.  Of course, the case statement became immediately annoying as I added codes, so it went out the window in favor of a table lookup, which was not only shorter, but much easier for adding codes. I also quickly dispensed with the string display, and pretty soon my fancy graphics display was pretty boring.  All I really needed was the hex code (for adding new buttons) and the result. So at this point, I'm kind of at the end of this experiment. I did notice that, although there are all sorts of claims of standards, the pulse lengths vary widely between different remotes.  But honestly, I don't have a burning application for this capability anyway, so I doubt I'll be motivated to expand to other remotes.

Another good day, in a surprising way. Last night the roads were pretty poor, but this morning, in spite of a little more snow last night, were good.  Apparently they have salt in Virginia. The main event planned today was the Docs hackfest.  We never did find the agenda, but we did get one thing done; all the Beats are ready to start on F17. This isn't a huge job, but it is really tedious and annoying.  With multiple hands it was done in no time.  So now everything is in place to get started on the Fedora 17 Release Notes. After lunch they wanted to move us to another floor, and lots of folks were headed back home, so I headed back to my hotel room.  It had warmed up considerably; so much so that I decided to seize the top-down opportunity for the short drive back to the hotel, interrupted by a quick stop at Starbuck's.  (I may not have mentioned, there was NO COFFEE at FUDcon.) I needed to get out my monthly report for my day job(?).  I was missing two reports, sent out a request for one and got it back almost immediately.  The second one might not make it; only about an hour now before I have to just send the report. I plan to meet my godson later today.  He is on the way back to VT as I write this.  He is in Civil Engineering at VT, so it will be nice to have a chance to see him. Tomorrow we will try to get out as early as possible and head back north.  I don't much like the way the weather reports look back in Michigan, so we want to get as many miles behind us as possible before we hit the weather. I don't know how it went for others, but for me, this was a very productive trip.

At FUDcon we've been complaining about the net all weekend.  Well, Jan Wildeboer posted a "What's up with the Internet" post that made me think maybe it ain't the network at VT. A little digging revealed something disturbing.  There are 37 top level routers in North America.  15 of those routers are down, and 2 more are barely limping along.  I have no idea why this is happening, but it is very disturbing.  So if the net is doggy for you, don't blame your ISP. (The above screenshot doesn't show all the routers, only as many as would fit on my screen.  For current data see http://www.internettrafficreport.com/namerica.htm).