Or you could try something that has been proven to actually work in a community near one of the largest collection of large observatories (on the summit of Mauna Kea on the big island of Hawaii), they passed an ordinance that requires all streetlights to be shielded to minimize upwards and sideways light. So the large parking lots instead of pumping a bunch of light sideways and reflecting up all goes towards the ground where it actually is useful. They also use specific color temperature LEDs that the observatories can more easily filter out. Local article on what they did from about a decade ago: https://bigislandnow.com/2012/... Sometimes low tech works just as well.

Instead of looking for a camera that can push to an FTP/SMB server, look at setting up software that can pull RTSP feeds from the cameras. Almost any IP security camera made in the last 10 years supports RTSP. Any software package that supports RTSP feeds would let you pull the video feeds from the cameras and store the files locally.

So they're going back to the Multi-Chip Module concept? Which has been used by multiple companies before, including Intel (Pentium Pro was the first).

Wikipedia:MCM

It's like technology companies are starting to behave like Hollywood. Come out with a rehash of what they did a few years ago instead of any new revolutionary ideas.

Unless they're referring to WWV rather than WWVB. Which broadcasts on 2.5/5/10/15/20/25 MHz.

Could you do last mile over wireless? Sure.

Now how do you get the signal from those thousands of towers back somewhere to give them network access? The most common way is via copper or fiber cabling. Push enough towers out deep into every neighborhood to have minimal contention, good enough signal strength, and 99.9% coverage over the area (including all those old houses with nice thick walls that KILL signal) and you've probably spent as much or more than hiring a trenching/construction/OSP crew for a few months. And you still probably need 10-20% of those copper/fiber connections back to your headend to get to the network. And you have to provide power at several hundred locations instead of a small handful.

So why don't you just backhaul everything using multi-hop wireless? With a proper design, you're going to have one radio for subscriber use, and one for backhaul. So that's 2X the amount of equipment on every pole/tower. Then if you're over a large enough area that you can't do all the remote towers back to the main one, you're taking up bandwidth from every downstream tower coming back in addition to the upstream towers.

T1->T2->T3->T4->HE

The amount of backhaul bandwidth you're going to need for T4->HE is the sum of all the bandwidth needed for T1, T2, T3, AND T4.

The idea has been thought of many times. Economics are the biggest reason it fails, not the technology. To get sufficient density, it costs a lot more than just running wires.

I looked at doing this a few years ago when living in a mid-sized US/Midwest city of about a half million people. Live about 8-10 miles from downtown, a few blocks away from an interstate interchange that goes into downtown.

To get to work by 8AM, I would have to walk 3-4 blocks to the bus stop leaving by 6:40AM (not so nice when there's 6" of snow and -15F temps or when it's 90F+ at 7AM). I get on one bus to go about 2 miles away, then wait 15-20 minutes for another bus to get downtown.

Leaving work at 5PM, a 5 minute walk to the nearest bus depot at work MIGHT catch the 5:05PM bus, otherwise it's a 30 minute wait, then another transfer to another 15-20 minute ride and a 4 block walk uphill to home.

I could drive even with 7:30AM/5PM traffic in about 20-30 minutes either by Interstate or by a major through town federal highway. So I can give up an extra 1-1.5 hours a day of my time and walk several blocks in quite likely to be less than pleasant weather, or I can drive my car and pay about the same amount for a monthly parking pass as what a monthly bus pass would cost. Due to having children, I couldn't give up the vehicle, it would just mean different routes for the car and the bus.

Having visited cities like San Francisco, New York, Houston, and San Diego in the last year, cities that have well developed urban centers with public transit in mind seem to do much better with this than ones that were designed around cars and are trying to retrofit mass transit into them. The biggest difficulty in getting around NYC was figuring out whether to grab a cab, get on a subway, get a bus ticket, or get on one of the multiple trains. In several cases, there were at least 3 different options to get from A to B in roughly the same amount of time, though prices varied quite a bit. Subway was cheap, trains were pretty cheap, cabs were reasonable only because of the short distances.

So they're trying to reproduce what IBM did 10 years ago on the first ThinkPad W series laptops?

http://www-01.ibm.com/common/s...

I remember looking at these when they first came out and thinking it would be useful for sysadmins/coders who work in odd areas, but the form factor is pretty much useless on a plane/train, inside a rack, or anywhere else you don't have a full desk to set it on. And the fact that it was an 8.5lb laptop in the days of their competition getting down into the 5-6lb class. Coupled with the high (even for IBM) pricetag, it didn't do so well.

http://help.twcable.com/twc_se...
I've read through a number of peering agreements over the last year, and this is one of the most onerous and one-sided that I've seen. Mandating minimum connection speeds that are out of the realm of all but probably the 20-30 largest carriers in the world, minimum of 8 POPs with 4 of them in distinct regions peering with TWC, must have at least 500 downstream AS's, and must be advertising 2000+ /24s of IPv4 space.
Definitely taking the stance of they have everything to gain from this relationship and any benefit to the peer is only if it benefits TWC more. The Google's and Facebooks of the world have fair and reasonable policies that most large enterprise customers can easily meet to benefit from peering. Maybe this is why peeringdb doesn't list many locations or peers for TWC. Glad Charter is buying them. Hopefully peering policies like this go away soon. For those interested, Charter's policy is here for those interested in how far apart they are from each other:
https://www.charter.com/browse...

Just a 5V Pentium that's been on my keys since I got it from Intel when the Pentium launched. It's a 60/66MHz model core encased in acrylic. Keyfob has outlasted 5 cars and 7 houses.

If she is interested in learning programming, there's several courses on Khan Academy that do basic Java/Javascript that are age appropriate. My 9 year old had never shown any prior interest in learning how to do anything beyond games and Youtube on the computer, but I set her up on KA one afternoon and she spent about 30 minutes figuring out how to draw boxes on the screen to finish the requirements, then spent another hour and a half drawing things on the screen with Javascript. Access is free, and has other things she might be interested in as well.

I was at a hotel chain about 10 years ago that was using magstripe cards for room entry. Checked in, walked up to my room, swiped my card, and got no green light. Tried it again, no light. Just out of curiosity, I tried the handle and the door opened. Called down to the front desk to let them know my card wasn't working right, and they sent a maintenance guy up to fix it. The fix, a torx screwdriver and 4 AA batteries. When the batteries went dead, the door defaulted to open. With insecurity by default, what's to stop someone from walking up to a door with a small power screwdriver, pulling a battery, and walking into your room in about the same time as it takes you to swipe a card and get in?

Wrong. Redhat's first release was October 1994. RPM didn't come along until 1997. Debian's first release was August 1993. Their history doesn't indicate the date that the first release of dpkg was unleashed, but it was prior to 1.1, which was in June 1996. apt is a more recent addition, dselect was the package management tool of choice prior to that, and was around since 0.93R6 in November 1995.
https://www.debian.org/doc/man...
http://en.wikipedia.org/wiki/R...
http://en.wikipedia.org/wiki/R...

I've been a Debian user since sometime in 1996, was a RH user from 3.0.3 until around the 6.X days, and was a Slackware user before that (back in the pre-kernel 1.0 days when a distro was 50+ floppies for a full install)

From the sound of the post, this sounds more like a build lab rather than a server room/data center. Temporary equipment, unboxed long enough to configure/burn-in, then put back in the box and shipped out to another location for production. The needs of this kind of space are drastically different than a production data center.

Your goals here are make it quick and easy to get stuff out of the box, configured, and back out the door as quickly and efficiently as possible.

Things I'd do to start:
If doing racks, consider shelves so you can slide equipment in and out quickly. Some racks will let you do shelves that mount to the sides rather than taking up 1U for a shelf, these may let you get more density in the rack and need fewer racks.
If doing shelves, don't stack equipment, try to put it like books on end, makes it a lot easier to get one piece out without moving a bunch of others.
Plenty of power cords/outlets where you need it, make sure if everything isn't a C13 that you account for this. Newer switches are starting to use C15s or C19s for larger equipment. Make sure you have a large enough UPS to handle startup current for all these devices. Constantly turning up/down equipment is hell on your power feeds, good clean UPS power is important.
Patch cables wired in and velcro'ed off to the rack where you need them, and run extras. That way if you have a suspected bad cable or a broken end you aren't worrying about replacing it right away to get the equipment out the door.
Terminal servers are a godsend in an environment like that. Configure them so you know that TS1, port 1 is the top (or bottom) device in the rack. Keep them in order or you'll be tearing your hair out why the wrong device just rebooted.
As someone else mentioned, USB barcode scanners if you have to do any kind of inventory tracking is a GREAT tool to have.
Separate but adjacent boxing/unboxing room with a sturdy table. And a sturdy cart to move equipment back and forth between them. You want to keep all the cardboard and styrofoam out of the equipment config area.

What single book are you the most proud of, and see as your best work? Or which one have you had the most people tell you was _the_ book they use/recommend the most?