trelliscoded

https://en.bitcoin.it/wiki/Block_size_limit_controversy#Argu...

There's a bunch of political reasons on both sizes as well.

Like bcoates said, there's a bunch of dumb stuff out there designed by people who barely understood TCP/IP and used non-RFC1918 ranges for customer equipment. Occasionally they leak indirectly into a table that's being redistributed into some mom and pop ISP's BGP announcements, and this happens. The backbone carriers of the Internet all (well, maybe not tata) have much stronger filters than Honest Achmed's used car sales and Internet transit, so they tend to leak only within a country or region.

Occasionally its some ISP internal services and it's done deliberately to have easy to remember IP addresses for techs working on the network. I mean, do you want to have to remember to point SNMP traps to 216.31.49.167 or would you rather only have to remember 1.1.1.1 instead? Then the prefix hits the border bogon filter and remains entirely with that ISP's network.

Now that I think about it, scanning ISPs for known unannounced prefixes in the global table would be kind of a fun project to discover all the little internal services ISPs might have squirreled away throughout their network.

At the moment, I see a lot of ridiculous stuff like phone apps talking to some cloud instance which tries to jam the packets back through your firewall into your Internet light bulbs. Congratulations, you literally just used thousands of kilometers of fiber and billions of dollars of routing infrastructure to make the world's most expensive how many... light bulb joke.

http://jslinux.org/

Also, the watch has a clock frequency measured in kilohertz, and the processor is probably some dumb as rocks 8051 variant or something with a tiny amount of static RAM. Big difference in power consumption compared to a 32-bit ARM core.

Cortex-M0s are pretty competitive with that power regime though these days, especially if your application (like the watch) will allow you to run the M0 at sub-1MHz speeds.

Anyway, TI has stuff like this specifically designed for these applications, so it's kind of a nonissue these days:

http://www.ti.com/lit/ds/symlink/tps62730.pdf

I think Mouser had them for like $0.50 or something.

Regardless, profit is important and someone had to get squeezed out of the BoM of these things being manufacturing in the billions. It finally happened because of a combination of improvements to system on chip security, CMs cracking down on security, and the carriers hauling their EDI based provisioning systems into the 21st century. As a result, carriers can now securely provision devices after manufacturing. AT&T is kind of a jerk about it though, they do some stuff to the SIM when you onboard an unlocked device sometimes to tie it to their network.

I'm still not entirely clear how the keys get distributed in a SIMless world though. The process I use to onboard stuff into Verizon's IoT cloud involves me uploading a CSV file to a server somewhere and making some REST requests, but it's just IMSIs. The virtual UICC in the products like your watch works pretty much the same way, according to my chip vendor. But they have a multicarrier solution where the virtual UICC already knows about the major networks, so maybe they're exchanging keys as part of the OTA activation flow and securing it with a hardware key they give to the carriers in a HSM or something. Or maybe the manufacturers are getting HSMs at the factory and doing it right in the manufacturing process. I tried to wrap my head around the 3GPP documents on the subject and I just got more and more confused.

There's definitely a vendor proprietary aspect to what's going on though, because I can see the OTA provisioning packets in QXDM and it says it doesn't know how to decode them.

But yeah, I've made MCU boards in my toaster oven, it's fun times for little non-RF projects.

The several gigabytes of stuff TI makes you install just to do hello world on their simple link products is kind of nuts though. There's nothing simple about it tbh.

But yeah, I've made MCU boards in my toaster oven, it's fun times for little non-RF projects.

The several gigabytes of stuff TI makes you install just to do hello world on their simple link products is kind of nuts though. There's nothing simple about it tbh.

He's spot on about the data firehose problem, though. IoT data usage patterns break all kinds of assumptions that network and storage engineers have about how computers do stuff. The packet sizes are really small, so routers have to work way harder, and all those tiny I/Os blow through IOPS way more than a typical web app does.

And then there's the data formatting issues, like how searching this pile of stuff makes you want to put it in columnar formats but time-series type displays want row oriented formats. Oh, and the indexers. Ugh. A lot of good indexing code has trouble keeping their internal trees balanced with all the I/O going on at the same time the big data reporting stuff is going on a spelunking expedition through your storage. There's probably some group at Amazon going insane trying to come up with solutions to keep up with even the limited IoT deployments out there already. I wouldn't be surprised if their storage solutions are operating in a constant state of imminent capacity breakdown of some kind.

CR2032s have a much higher surface area on the contacts, which is required to dissipate the heat from the weld as well as have more surface contact with the springs if you use a battery socket instead.

It's not exactly self-healing in the same way 802.11s is, iirc it's your basic distance-vector routing protocol with all the usual problems that has.

These chips are totally amazing. TI used every trick in the book to help the designers save power. There's even a specialized coprocessor that uses special low leakage silicon to handle some simple 16 bit I/O processing so you don't have to wake up the main processor, and the main Cortex-M3 is pretty darn low power already.

I am kind of annoyed that you have to call into their ROM routines to use the radio, though. The datasheet is a snarky little tease that says ha ha, the radio registers are somewhere around these addresses but we aren't going to tell you what they do! Shhhh it's a secret! This is particularly annoying because I could make my life a lot simpler if I could interface with the Nordic shockburst protocols, and TI's firmware only knows how to speak TI simplelink packet formats.

The thing that TI isn't talking about is that they did some stuff around the voltage regulation that looks like they were planning on pushing some kind of energy harvesting companion silicon. It's just a guess, but they might announce something in the future along those lines. Whoever ends up first to market with a productized energy harvesting IoT chip is going to print bucketloads of money.

There's also a lot of stuff going on in the low power LTE space right now. Altair semi announced the 1250 chip, which is -- get this -- power competitive with the TI chip for low frequency telemetry applications. AT&T and Verizon have already launched their cat-M1 networks and cat-NB1 is going to be out by the beginning of next year. Those protocols use oversampling and a bunch of other mad scientist RF hacks to get even more range than the LTE radio in your phone. The bandwidth is really low, like modem or ISDN low, but there's a ton of applications that can be implemented with literally one bit per day worth of data. The chips are getting pumped out in volume now, and the cost regime is actually causing revenue jitters at the carriers. They want to squeeze some extra revenue out of LTE IoT space since it's basically free for them to implement since the LTE IoT designers figured out how to reuse the otherwise useless guard bands surrounding the real full-fat LTE signals your phone uses.

However, it's kind of a tough problem to figure out a cost model where customers are paying something like $10 a year for maybe hundreds of devices that are so cheap that the most expensive item on the board is the SIM card. And even that's going away in the 2nd generation IoT chips now that someone figured out how to get around the UICC requirement for provisioning by doing something funny with a protected element in the main LTE radio.

Also check out my profile. It's not a joke, someone made a homebrew monitoring solution out of someone else's IoT chip to keep track of cow farts because they wanted to adjust the feed based on farts per minute or something, I didn't really understand it.

TI keeps trying to push their MSP432 cortex-M4 series on me as a replacement for MSP430. I guess they don't want to have customers go with a different vendor just because TI doesn't have an ARM solution that supports whatever code module or toolchain the customer wants to use.

I browsed through a copy a few jobs ago and it's honestly kind of boring.

The problem is that there's no single definition for devops. Aside from involving automation, companies all mean different things when they say devops. Some companies want to migrate to CI/CD type deployments for their webapp, some want to move to DSC instead of RDPing into everything because they just grew to 1000 Windows machines, and some want to deploy OpenStack because VMware wants to renew their contract at 2x the price. There's no single interview process which can reliably predict a successful hire for all of these examples.

If I were trying to hire for such a role, I wouldn't do whiteboard interviews or look at their github page or any of that. I'd look for flexibility in their career history. The ideal candidate would have two of SWE, system admin, or network administration roles on their resume on a variety of platforms (or all three, like me.) Then there's the security aspect intersecting all of those, and finding someone who's done real whitehat work on top of that is just impossible to hire for.

Like it or not, devops tooling is in a constant state of flux. Regardless of what you're running now, you want someone who can adapt to changing business circumstances on the fly with the best technology they can find. It's not uncommon for the chosen solution to be something no one in the whole company has ever worked with before. You want someone who adapts quickly and learns fast.

As far as interviewing goes, the more mature companies I've interviewed at have had me do multi-hour projects (usually involving Hashicorp products) in a virtual container somewhere. Let them use man pages, autocompletion, etc. Look over their shoulder and have them explain their thought process out loud. Have the candidate do the same things they're going to get paid to do if they're hired. Why would you want to filter them any other way?

Less mature companies do whiteboard interviews about things that you'll never do on the job, usually involving recursion or binary trees. I think the idea is that they're using that as a proxy for general intelligence or CS knowledge, but that doesn't matter if you're trying to add vswitch redundancy throughout your clusters and slinging ruby and XML around all day.

        int a=0, b=4;

        while(a < - - - - --b) {
                printf("b: %d\n", b);
        }

My customers and employers have all had these rube goldberg enterprisey backup systems, usually Symantec or Veritas talking to HP MSAs.