Doing random things over at
237 stories

Uganda's January 13, 2021 Internet Shut Down

1 Share
Uganda's January 13, 2021 Internet Shut Down

Two days ago, through its communications regulator, Uganda's government ordered the "Suspension Of The Operation Of Internet Gateways" the day before the country's general election. This action was confirmed by several users and journalists who got access to the letter sent to Internet providers. In other words, the government effectively cut off Internet access from the population to the rest of the world.

On Cloudflare Radar, we want to help anyone understand what happens on the Internet. We are continually monitoring our network and exposing insights, threats, and trends based on the aggregated data that we see.

Uganda's unusual traffic patterns quickly popped up in our charts. Our 7-day change in Internet Traffic chart in Uganda shows a clear drop to near zero starting around 1900 local time, when the providers received the letter.

Uganda's January 13, 2021 Internet Shut Down

This is also obvious in the Application-level Attacks chart.

Uganda's January 13, 2021 Internet Shut Down

The traffic drop was also confirmed by the Uganda Internet eXchange point, a place where many providers exchange their data traffic, on their public statistics page.

Uganda's January 13, 2021 Internet Shut Down

We keep an eye on traffic levels and BGP routing to our edge network, and are able to see which networks carry traffic to and from Uganda and their relative traffic levels. The cutoff is clear in those statistics also. Each colored line is a different network inside Uganda (such as ISPs, mobile providers, etc.)

Uganda's January 13, 2021 Internet Shut Down

We will continue to keep an eye on traffic levels from Uganda and update the blog when we see significant changes. At the time of writing, Internet access appears to be still cut off.

Read the whole story
14 hours ago
Share this story

Graphics Studies Compilation

1 Comment and 2 Shares

Rendering in games can be a complex topic, different approaches with their own tradeoffs are available, new techniques arise, others fall out of fashion… Studios using in-house engines need to make choices that will fit the type of game they’re aiming for.
It can be very …

Read the whole story
18 days ago
Share this story

The Futel Telephone Sanitation and Hygiene Programs

1 Share

When the pandemic first hit Portland in early 2020 we figured we were in the wrong industry. Surprisingly, Futel phone usage did not decrease by a large amount. We realized that many people were still going to be using our phones even in hazardous conditions, so we had to make them safer.

Our solution was to implement telephone sanitation and hygiene programs. These would allow the phones to be used safely and provide a valuable service for many non-users of the phones.

Telephone Sanitation Program

The telephone sanitation program consists of a cadre of telephone sanitation engineers trained and equipped to regularly sanitize the telephones. The purpose of the program is primarily to improve the health and safety of telephone users, and secondarily to assure users that the telephones are safe to use.

At first it was difficult to find supplies and equipment. Disinfectant and PPE were sold out everywhere. We were able to buy sufficient amounts of bleach and sponges, and small quantities of rubber gloves, nalgene gloves, and spray bottles. Now that the west coast has settled into our new reality, we are able to keep our supplies stocked.

To inform users, stickers with the date of sanitation and the engineer’s handle are applied after every procedure.

While the sanitization procedure is designed to limit deleterious effects on the telephone hardware, we have had to replace some handsets and appear to be experiencing accelerated keyboard wear. The procedure does create a cool patina on the chrome, however, and makes the informational copy more challenging to read and probably more satisfying for those who attempt to do so.

Progress And Outcome

We have achieved and continue to achieve the safety improvement objectives. Keeping a sustainable volunteer force is always a challenge, and the program would benefit from an additional dedicated sanitation cohort to supplement the current volunteers, who are largely the telephone hosts and already have tasks to execute.

Hygiene Program

The hygiene program deploys handwashing stations to every telephone location where we are able to do so. The purpose of the program is to improve the health and safety of Futel users or any other individuals who wish to use the stations.

The handwashing stations are essentially soap dispensers, water supplies, and hands free water dispensers. There are several ways to implement this, we chose to base ours on a foot operated pump drawing water from a tank to a spigot. This is an economical and robust solution but has the large drawback of being less accessible to wheelchair users and other people with limited leg mobility. The design objectives of our implementation are to provide water and soap with minimal maintenance and cleaning requirements, ruggedness when faced with careless or hostile users, and inexpensive parts to discourage theft. The pump is a rubber primer bulb under a pedal, the tank is a bucket or plastic barrel, and the spigot is PVC conduit. A wood and rebar frame anchors everything. A bottle of liquid soap is ziptied to the frame.

To reduce cleaning requirements, the installations do not include a basin or any other graywater collection, the spigot just empties over the pavement. Because of this the spigot must be to the side to avoid splashing the user’s foot.

Soap was difficult to acquire in the early days of the pandemic, but we were able to get a large container of blue industrial hand soap.

Progress And Outcome

We have achieved and continue to achieve the safety improvement objectives. There have been surprisingly few instances of vandalism or theft of parts and supplies.

Read the whole story
35 days ago
Share this story

I Just Don't Trust Them

1 Comment and 5 Shares
I believe in getting immunity the old-fashioned way: By letting a bat virus take control of my lungs and turn my face into a disgusting plague fountain while my immune system desperately Googles 'how to make spike protein antibodies'.
Read the whole story
35 days ago
Share this story
1 public comment
37 days ago
I believe in getting immunity the old-fashioned way: By letting a bat virus take control of my lungs and turn my face into a disgusting plague fountain while my immune system desperately Googles 'how to make spike protein antibodies'.

What’s the Value of Hackable Hardware, Anyway?


There is plenty of skepticism around the value of hackable products. Significantly, hackability is different from openness: cars are closed-source, yet support vibrant modding communities; gcc is one of the “real OG”s of open source, but few users find it easy to extend or enhance. Is it better to have a garden planted by the most knowledgeable botanists and maintained by experienced gardeners, or an open plot of land maintained by whoever has the interest and time?

Above left: Walled garden of Edzell Castle; above right: Thorncliffe Park community garden.

In the case of hardware products, consumer behavior consistently affirms a strong preference for well-curated gardens. Hardware is hard – not only is it difficult to design and validate, supply chains benefit from economies of scale and predictable user demand. The larger a captive audience, the more up-front money one can invest into developing a better hardware product. However, every decision to optimize comes with inherent trade-offs. For example, anytime symmetry is broken, one must optimize for either a right-handed or a left-handed version.

Above: touching the spot indicated by the red arrow would degrade antenna performance on an iPhone 4. This spot would naturally rest on the palm of a left-handed user. Image adapted from “iPhone 4” by marc.flores, licensed under CC BY 2.0.

Some may recall a decade ago when the iPhone 4 was launched, left-handed people noticed the phone would frequently drop calls. It turned out the iPhone 4 was designed with a critical antenna element that would fail when held naturally by a left-handed person. The late Steve Jobs responded to this problem by telling users to “just avoid holding it that way”. Even if he didn’t mean it, I couldn’t help but feel like he was saying the iPhone 4 was perfect and left-handers like me were just defective humans who should be sent to re-education camps on how to hold things.

Of course, as a hardware engineer, I can also sympathize with why Steve Jobs might have felt this way – clearly, a huge amount of effort and thought went into designing a technical masterpiece that was also of museum-quality construction. It’s frustrating to be told, after spending years and billions of dollars trying to build “the perfect product” that they somehow got it wrong because humans aren’t a homogeneous population. Rumors have it Apple spent tens of millions of dollars building micron-precision production jigs out of injection-molding grade tooling to ensure the iPhone4 was simply perfect in terms of production tolerances; duplicating all of those to make a mirror-image version for left-handers that make up 10% of the market size just made no business sense. It proved to be cheaper and easier, ultimately, to take full refunds or to give out rubber bumpers to the users who requested them.

I do think there is such a thing as “over-designing” a product. For example, contemporary “high concept” smartphone design is minimalist – phone companies have removed headphone jacks, hidden the front camera, and removed physical buttons. There is clearly no place for screws in this world; the love affair of smartphones and adhesives has proven to be … sticky. Adhesives, used in place of screws in modern smartphones, are so aggressive that removing them either requires additional equipment, such as a hot plate and solvents, or simply destroying the outer bezel by breaking the outer case off in pieces and replacing it with an entirely new bezel upon re-assembly. In other words, hacking a modern smartphone necessarily implies the destruction or damage of adhesive-bound parts.

With Precursor, I’m bringing screws back.

Precursor’s screws are unapologetic – I make no attempt to hide them or cover them with bits of tape or rubber inserts. Instead, I’ve sourced custom-made Torx T3 metric screws with a black oxide finish that compliments the overall color scheme of Precursor. Six of them line the front, as a direct invitation for users to remove them and see what’s inside. I’ve already received ample criticism for the decision to show screws as “primitive”, “ugly”, “out of touch with modern trends” — but in the end, I feel the visual clutter of these six screws is a small price to pay for the gain in hackability.

Of course, the anti-screw critics question the value of hackability. Surely, I am sacrificing mass-market appeal to enable a fringe market; if hackability was so important, wouldn’t Apple and Google already have incorporated it into their phones? Wouldn’t we see more good examples of hackability already?

This line of questioning is circular: you can’t get good examples of hacks until you have made hackable products wide-spread. However, the critics are correct, in a way: in order to bootstrap an ecosystem, we’re going to need some good examples of why hackability matters.

In the run-up to crowdfunding Precursor, I was contemplating a good demo hack for Precursor. Fortuitously, a fellow named Matt Campbell opened a GitHub issue requesting a text-to-speech option for blind users. This led me to ask what might be helpful in terms of a physical keyboard design to assist blind people. You can read the thread for yourself, but I’ll highlight that even the blind community itself is divided on whether or not there is such a thing as the “blind ghetto” — an epithet applied by some users who feel that blindness-specific products tend to lag behind modern smartphones, tablets, and laptops. However, given that most modern gadgets struggle to consider the needs of 10% of the population that’s left-handed, I’m readily sympathetic to the notion that gadgets make little to no concession to accommodate the even smaller number of blind users.

Matt was articulate in specifying his preferred design for a pocketable keyboard. He referred me to the “Braille ‘n Speak” (shown above) as an example of an existing braille keyboard. Basically, it takes the six dots that make up braille, and lines them up horizontally into three left and three right sets of buttons, adding a single button in the middle that functions as a space bar. Characters are entered by typing chords that correspond to the patterns of the six dots in the braille alphabet. Not being a braille user myself, I had to look up what the alphabet looked like. I made the guide below based on a snippet from Wikipedia to better understand how such a keyboard might be used.

Ironically, even though Matt had linked me to the picture of the Braille n’ Speak, it still took a while to sink in that a braille variant of Precursor did not need a display. I’m a bit ashamed to admit my first sketches involved trying to cram this set of switches into the existing keyboard area of the Precursor, without first removing the display entirely. I had to overcome my own prejudice about how the world should look and it took me time and empathy to understand this new perspective.

Once I had a better grasp of Matt’s request, I set about designing a customized braille variant. Precursor was designed for this style of hacking: the keyboard is a simple 2-layer PCB that’s cheap and easy to re-design, and the front bezel is also a PCB, which is a bit more expensive to redesign. Fortunately, I was able to amortize setup costs by bundling the braille front bezel variant with another variant that I had to fabricate anyways for the crowdfunding campaign. Beyond that, I also had to come up with some custom key caps to complement the switches.

The major challenge in designing any type of mobile-friendly keyboard is always a trade-off between the hand feel of the switches, versus thinness of the overall design. On one side of the spectrum, full-travel mechanical switches have a wonderful hand feel, but are thicker than a sausage. On the other side of the spectrum, dome switches and printed carbon ink patterns are thinner than a credit card, but can feel mushy and have a limited “sweet spot” — the region of a key switch with optimal tactile feedback and operational force curves. The generally well-regarded Thinkpad keyboards go with a middle-ground solution that’s a few millimeters thick, using a “scissor” mechanism to stabilize the key caps over a silicone dome switch, giving individual keys a bit of travel while ensuring that the “sweet spot” covers the entire key cap. Optimizing key switch mechanisms is hard: some may recall the controversy over Apple’s re-design of the MacBook’s keyboard to use a “butterfly” mechanism, which shaved a couple mm of thickness, but led to lawsuits over a defect where the keyboard allegedly stopped working when small bits of dust or other particles got trapped under it.

Given the short time frame and a shoestring budget, I decided to use an ultra-thin (0.35mm) tactile switch that I could buy off-the-shelf from Digikey and create custom key caps with small dimples to assist users in finding the relatively small sweet spots typical of such switches. I have sincere hopes this is a pretty good final solution; while it lacks a scissor mechanism to spread off-centered force, the simple mechanism meant I didn’t have to stick with a square key cap and could do something more comfortable and ergonomic to focus forces into the sweet spot. At the very least, the mechanism would be no worse than the current mechanism used in Precursor’s existing keyboard for sighted users, which is similarly a dome switch plus a hybrid-polymer key film.

Next, I had to figure out where to place the switches. To assist with this, I printed a 1:1 scale version of the Precursor case, dipped my fingertips in ink, and proceeded to tap on the printout in what felt like a natural fashion.

I then took the resulting ink spots and dimensioned their centers, to place the centroid of each key cap. I also asked my partner, who has smaller hands, to place her fingers over the spots and noted the differences in where her fingers lay to help shape the final key caps for different-sized hands.

Next, using the “master profile” discussed in the previous post on Precursor’s mechanical design, I translated this into a sketch to help create a set of key caps based on splines that matched the natural angle of fingers.

Above, you can see an early sketch of the key caps, showing the initial shape with dimples for centering the fingers.

Before moving ahead and spending a few hundred dollars to build a functional prototype, I decided to get Matt’s feedback on the design. We submitted the design to Shapeways and had a 3D print sent to Matt, which he graciously paid for. After receiving the plastic dummy, his feedback was that the center space bar should be a single key, instead of two separate keys, so I merged the two separate key caps of the space bar together into a single piece, while retaining two separate switches wired in parallel under the space bar. I felt this was a reasonable compromise that would allow for a “sweet spot” that serviced lefties as well as righties.

I then re-designed the keyboard PCB, which was a fairly simple task, because the braille keyboard consists of only eight switches. I just had to be careful to pick row/column pairs that would not conflict during chording and be sure to include the row/column pairs necessary to turn Precursor on after being put to sleep. I also redesigned the bezel; eliminating the display actually makes manufacturing a little bit easier because it also removes a beveling step in the manufacturing process. I kept the RF antenna in exactly the same location, as its design was already well-characterized and it takes a lot of effort to tune the antenna. Finally, I decided to manufacture the key switches out of aluminum. The switches have a lot of fine features and I needed a stiff material that could translate off-target force to the key switches to enlarge the sweet spot as much as possible.

Above: The prototype of Precursor with braille keyboard.

About three weeks later, all the parts for the braille keyboard had arrived. I decided to use purple anodization for the key switches which, combined with the organic key shapes, gives the final design a bit of a Wakanda-esque “Black Panther” aesthetic, especially when mounted in a brass case. The key switch feel is about in line with what I imagined, with the caveat that one of the switches feels a little less nice than the rest, but I think that’s due to a bad solder job on the switch itself. I haven’t had a chance to trace it down because…well, I’ve had to write a bunch of posts like this to fund Precursor. I have also been working with Xobs to refactor Xous in hopes of putting together enough code to send Matt a prototype he can evaluate without having to write gobs of embedded hardware driver code himself.

Above is a quick photo showing the alignment of fingers to keys. Naturally, it’s perfect for my hand because it was designed around it. I’m looking forward to hearing Matt’s opinion about the feel of the keys.

Above is a photo of the custom parts for the braille keyboard. At the top, you can see the custom bezel with key caps and the RF antenna matching circuitry on the top right. On the bottom, you can see the custom keyboard PCB mounted onto a Precursor motherboard. The keyboard PCB is mostly blank and, because of the small number of keys and the flexibility of the FPGA, there’s an option to mount more peripherals on the PCB.

Despite not being yet finalized, I hope this exercise is sufficient to demonstrate the potential value of hackable products. The original design scope for Precursor (née Betrusted) did not explicitly include a braille keyboard option, but thanks to modular design principles and the use of accessible construction materials, I was able to produce a prototype in about a month that has a similar fit and finish as the mainstream product.

As long as humans choose to embrace diversity, I think hackability will have value. A notional “perfect” product implies there’s such a thing as a “perfect” user. However, in reality, even the simple conundrum of left- or right-handedness challenges the existence of a singular “perfect” product for all of humanity. Fortunately, accommodating the wonderfully diverse, quirky, and interesting range of humanity implicates just a few simple engineering principles, such as embracing screws over adhesives, openness, and modularity. That we can’t hack our products isn’t a limitation of physics and engineering. Precursor demonstrates one can build something simultaneously secure and hackable, while being compact and pocketable. This suggests the relative lack of hackable products on the market isn’t a fundamental limitation. Maybe we just need a little more imagination, maybe we need to be a little more open-minded about aesthetics, and maybe companies need to be willing to take brave steps toward openness and inclusivity.

For Apple, true “courage to move on and do something new that betters all of us” was to remove the headphone jack, which resulted in locking users deeper into a walled-garden ecosystem. For hackers like myself, our “courage” is facing blunt criticisms for making “ugly” products with screws in order to facilitate mods, such as braille keyboards, in order to expand the definition of “all of us” beyond a set of privileged, “perfect” users.

I hope this braille keyboard is just the first example of many mods for Precursor that adapt the product for unique end-users, bucking the trend of gaslighting users to mold their behavior and preferences to fit the product. If you’ve got an itch to develop your own yet-to-be-seen feature in a mobile device, please visit our crowdfunding campaign page to learn more about Precursor. We’re close to being funded, but we’ve only a few days left in the campaign. After the campaign concludes on December 15th, the limited edition will no longer be available, and pricing of the standard model goes up. If you like what you see, please consider helping us to bring Precursor to life!

Read the whole story
37 days ago
37 days ago
Share this story

My list of magic numbers for your turkey day enjoyment


Hello, world! A couple of days ago, I noticed someone remarking on a line from an older post of mine that had been making the rounds. In it, I say something about adding a number to "my list of magic numbers". That person wanted to see that list.

It turns out that I've never written this down in any one coherent list... until now. I know that Thanksgiving here in the US usually brings a dull and dreary day online, in which nobody's posted anything interesting, and you just have to look at cat pictures until everyone gets over their turkey comas on Thursday and shopping burnout on Friday. This year will be even stranger since we're all trying to not get each other sick and might be doing it in isolation.

And so, I have put together this list of everything I can think of at the moment, along with a whole bunch of commentary that should be able to send you on dozens of romps through Wikipedia. Hopefully this will both satisfy the request for "the list" and provide a lot of amusement on a day which normally is lacking in content.

I might edit this page a bunch of times to add more items or links, so if it keeps popping up as "updated" in your feed reader, that's why.

Be safe out there, and enjoy.


"HTTP" is 0x48545450 (1213486160) or 0x50545448 (1347703880). If it shows up in your error logs, you're probably calling out to a poor web server instead of someone who actually speaks its binary protocol. See also: malloc("HTTP").

"GET " is 0x47455420 (1195725856) or 0x20544547 (542393671). This might show up in your server's logs if someone points a HTTP client at it - web browser, curl, that kind of thing.

"SSH-" is 0x5353482d (1397966893) or 0x2d485353 (759714643). If this shows up in your error logs, you're probably calling out to some poor SSH daemon instead of someone speaking your binary language.

1048576 is 2^20. It's a megabyte if you're talking about memory.

86400 is the number of seconds in a UTC day, assuming you aren't dealing with a leap second.

86401 would be the number when you *are* dealing with a (positive) leap second.

86399 is actually possible, if the planet speeds up and we need to *skip* a second - the still-mythical "negative leap second".

82800 (23 hours) is what happens in the spring in time zones which skip from 1:59:59 to 3:00:00 in the early morning: you lose an hour. Any scheduled jobs using this time scale in that hour... never run!

90000 (25 hours) is what you get in the fall in time zones which "fall back" from 1:59:59 summer time to 1:00:00 standard time and repeat the hour. Any scheduled jobs using this time scale in that hour... probably run twice! Hope they're idempotent, and the last one finished already! See also: Windows 95 doing it over and over and over.

10080 is the number of minutes in a regular week. You run into this one a lot if you write a scheduler program with minute-level granularity.

10140 is what happens when you have the spring DST transition.

10020 is then what you get in the winter again.

40 is the number of milliseconds of latency you might find that you can't eliminate in your network if you don't use TCP_NODELAY. See also: Nagle.

18 is the number of seconds that GPS and UTC are currently spread apart, because that's how many leap seconds have happened since GPS started. UTC includes them while GPS does not (but it does supply a correction factor). See also: bad times with certain appliances.

168 is one week in hours. Certain devices that do self-tests operate on this kind of timeframe.

336 is two weeks in hours and is another common value.

2000 is how many hours you work in a year if you work 40 hours a week for 50 weeks and the other two are handled as "vacation". This is why you can approximate a full-time yearly wage from an hourly wage by multiplying by 2: $20/hr -> $40K/year.

08 00 is the hex representation of what you get in an Ethernet packet for IPv4 traffic right after the destination and source hardware addresses. See also: EtherType.

45 00 is what comes after that, assuming a relatively boring IPv4 packet.

08 06 is what shows up in an Ethernet packet after the destination and source hardware addresses when some host is trying to do ARP for another host. You'll probably see it right before the aforementioned "08 00 45 00" when two hosts haven't talked to each other recently on the same network.

86 DD is what you'll get for IPv6, and you should see more of that in your future. Also, you won't see ARP.

33434 is the first UDP port used by the traditional (i.e., Van Jacobson style) traceroute implementation. See also: 32768 + 666.

49152 is $C000, or a block of open memory on a Commodore 64 frequently used for non-BASIC funtimes. SYS 49152 is how you jump there.

64738 is the reset vector on those same Commodore 64 machines.

64802 is the reset vector for people claiming to be even more OG than the C-64 crowd - it's from the VIC-20.

828 was the beginning of the cassette buffer on a Commodore 64, and was a place you could store a few bytes if you could be sure nobody would be using the cassette storage system while your program was running.

9090909090 might be a string of NOPs if you are looking at x86 assembly code. Someone might have rubbed out some sequence they didn't like. See also: bypassing copy protection for "software piracy".

31337 might mean you are elite, or if you like, eleet.

f0 0f c7 c8 is a sequence made famous in 1997 when people discovered they could lock up Intel machines while running as an unprivileged user on an unpatched system. See also: the Pentium f00f bug.

-1 is what you get back from fork() when it fails. Normally, it returns a pid_t which is positive if you're the parent, or zero if you're the child.

-1, when handed to kill() on Linux, means "target every process but myself and init". Therefore, when you take the return value from fork(), fail to check for an error, and later hand that value to kill(), you might just kill everything else on the machine. See also: fork() can fail - this is important.

15750 Hz is the high-pitched whine you'd get from some old analog NTSC televisions. See also: colorburst.

10.7 MHz is an intermediate frequency commonly used in FM radios. If you have two radios and at least one has an analog dial, try tuning one to a lower frequency and another to 10.7 above that (so 94.3 and 105.0 - hence the need for analog tuning). You may find that one of them squashes the signal from the other at a decent distance, even. See also: superheterodyne conversion.

455 kHz is the same idea but for AM receivers.

64000 is the signaling rate of a DS0 channel. You get it by having 8000 samples per second which are 8 bits each.

4000 Hz is the absolute max theoretical frequency of a sound you could convey during a phone call going across one of those circuits. In practice, it rolls off significantly a few hundred Hz before that point. See also: Nyquist.

1536000 therefore is the rate of a whole T1/DS1, since it's 24 DS0s. This is where we get the idea of a T1 being 1.5 Mbps.

/16 in the land of IPv4 is 2^16, or 65536 addresses. In the old days, we'd call this a "class B".

/17 in IPv4 is half of that /16, so 32768.

/15 in IPv4 would be double the /16, so 131072.

/64 is a typical IPv6 customer allocation. Some ISPs go even bigger. Just a /64 gives the customer 2^64 addresses, or four billion whole IPv4 Internets worth of space to work with. See also: IPv6 is no longer magic.

1023 is the highest file descriptor number you can monitor with select() on a Unix machine where FD_SETSIZE defaults to 1024. Any file descriptor past that point, when used with select(), will fail to be noticed *at best*, will cause a segmentation fault when you try to flip a bit in memory you don't own in the middle case, and will silently corrupt other data in the worst case. See also: poll, epoll, and friends, and broken web mailers.

497 is the approximate number of days a counter will last if it is 32 bits, unsigned, starts from zero, and ticks at 100 Hz. See also: old Linux kernels and their 'uptime' display wrapping around to 0.

(2^32) - (100 * 60 * 60 * 24 * 497)
(2^32) - (100 * 60 * 60 * 24 * 498)

49.7 is the approximate number of days that same counter will last if it instead ticks at 1000 Hz. See also: Windows 95 crashing every month and a half (if you could keep it up that long).

(2^32) - (1000 * 60 * 60 * 24 * 49)
(2^32) - (1000 * 60 * 60 * 24 * 50)

208 is the approximate number of days a counter will last if it is 64 bits, unsigned, starts from zero, ticks every nanosecond, and is scaled by a factor of 2^10. See also: Linux boxes having issues after that many days of CPU (TSC) uptime (not necessarily kernel uptime, think kexec).

(2^64) - (1000000000 * 60 * 60 * 24 * 208 * 1024)
(2^64) - (1000000000 * 60 * 60 * 24 * 209 * 1024)

248 is the approximate number of days a counter will last if it is 32 bits, signed, starts from zero, and ticks at 100 Hz. See also: the 787 GCUs that have to be power-cycled at least that often lest they reboot in flight.

(2^31) - (100 * 60 * 60 * 24 * 248)
(2^31) - (100 * 60 * 60 * 24 * 249)

128 is 2^7, and you'll approach this (but never hit it) when you fill up a tiny unsigned counter on an old system. See also: our cherished 8 bit machines of the 80s, the number of lives you could get in Super Mario Bros, and countless other places of similar vintage.

256 is 2^8, in the event that same counter was unsigned.

32768 is 2^15, and if you used a default 16 bit signed value in your SQL database schema (perhaps as "int"), this is the first number you can't jam into that field. See also: a certain company's "employee ID" column in a database that broke stuff for me as a new employee once upon a time.

65536 is 2^16, in the event that same counter was signed instead.

16777... is the first five digits of 2^24, a number you might see when talking about colors if you have 3 channels (R, G, B) and 8 bits per channel. See also: "16.7 million colors" in marketing stuff from back in the day.

2147... is the first four digits of 2^31, a number you will probably see right around the time you wrap a 32 bit signed counter (or run out of room). See also: Unix filesystems without large file support.

4294... is the first four digits of 2^32, and you'll see that one right around the time you wrap a 32 bit unsigned counter (or run out of room).

9223... is the first four digits of 2^63... 64 bit signed counter...

1844... 2^64... 64 bit unsigned counter...

"1969", "December 31, 1969", "1969-12-31" or similar, optionally with a time in the afternoon, is what you see if you live in a time zone with a negative offset of UTC and someone decodes a missing (Unix) time as 0. See also: zero is not null.

"1970", "January 1, 1970", "1970-01-01" or similar, optionally with a time in the morning... is what you get with a positive offset of UTC in the same situation. Zero is not null, null is not zero!

A spot in the middle of the ocean that shows up on a map and, once zoomed WAY out, shows Africa to the north and east of it is 0 degrees north, 0 degrees west, and it's what happens when someone treats zero as null or vice-versa in a mapping/location system. See also: Null Island.

5 PM on the west coast of US/Canada in the summertime is equivalent to midnight UTC. If things suddenly break at that point, there's probably something that kicked off using midnight UTC as the reference point. The rest of the year (like right now, in November), it's 4 PM.

2022 is when 3G service will disappear in the US for at least one cellular provider and millions of cars will no longer be able to automatically phone home when they are wrecked, stolen, or lost. A bunch of home security systems with cellular connectivity will also lose that connectivity (some as backup, some as primary) at that time. Auto and home insurance rates will go up for some of those people once things are no longer being monitored. Other "IoT" products with that flavor of baked-in cellular connectivity which have not been upgraded by then will mysteriously fall offline, too - parking meters, random telemetry loggers, you name it.

February 2036 is when the NTP era will roll over, a good two years before the Unix clock apocalypse for whoever still hasn't gotten a 64 bit time_t by then. At that point, some broken systems will go back to 1900. That'll be fun. Everyone will probably be watching for the next one and will totally miss this one. See also: ntpd and the year 2153.

January 19, 2038 UTC (or January 18, 2038 in some local timezones like those of the US/Canada) is the last day of the old-style 32 bit signed time_t "Unix time" epoch. It's what you get when you count every non-leap second since 1970. It's also probably when I will be called out of retirement for yet another Y2K style hair on fire "fix it fix it fix it" consulting situation.

1024 is how many weeks you get from the original GPS (Navstar, if you like) week number before it rolls over. It's happened twice already, and stuff broke each time, even though the most recent one was in 2019. The next one will be... in November 2038. Yes, that's another 2038 rollover event. Clearly, the years toward the end of the next decade should be rather lucrative for time nuts with debugging skills! See also: certain LTE chipsets and their offset calculations.

52874 is the current year if someone takes a numeric date that's actually using milliseconds as the unit and treats it like it's seconds, like a time_t. This changes quickly, so it won't be that for much longer, and by the time you read this, it'll be even higher. See also: Android taking me to the year 42479.

$ date -d @$(date +%s)000
Sun Mar 25 21:50:00 PDT 52874

Any of these numbers might have an "evil twin" when viewed incorrectly, like assuming it's signed when it's actually signed, so you might see it as a "very negative" number instead of a VERY BIG number. Example: -128 instead of 128, -127 instead of 129, -126 instead of 130, and so on up to -1 instead of 255. I didn't do all of them here because it's just too much stuff. See also: two's complement representation, "signed" vs. "unsigned" (everywhere - SQL schemas, programming languages, IDLs, you name it), and *printf format strings, and epic failure by underflow.

These numbers ALSO have another "evil twin" in that they might be represented in different byte orders depending on what kind of machine you're on. Are you on an Intel machine? That's one way. Are you looking at a network byte dump? That's another. Did you just get a new ARM-based Macbook and now the numbers are all backwards in your raw structs? Well, there you go. I listed them for the HTTP/GET /SSH- entries up front because I know someone will search for them and hit them some day. The rest, well, you can do yourself. See also: htons(), htonl(), ntohs(), ntohl(), swab() and a bunch more depending on what system you're on.

Read the whole story
49 days ago
Share this story
Next Page of Stories