dgnorton

Mine was snorkel.

D1 1v1 ladder matches on Case's and IDL...good memories.

Interesting :)

It’s impressive, to me at least, given the antenna is in an NVIS configuration (configured for distances of ~1k miles) and given that anything below S7 is in the noise. I have tried QRP and cannot reach overseas with this antenna placement.

Might be using a digital mode designed for weak signal communications. I'm not familiar with what might be used commercially but in amateur radio FT8 is popular and amazing. I live in a neighborhood with ~900 homes, restrictions on antennas, and quite a high noise floor. On 20m wavelength (granted, quite different from the 2m λ of this modem) with a center fed dipole antenna (SWR 1.5) that is 2m off the ground (not good for long distance because the ground reflects most of the radiated energy is up rather than out) and transmitting at 100 watts, I can send and receive messages 17700km (11000 miles). Using regular analog voice instead of FT8, I get about 3200km (2000 miles) with the same setup. Those distances are on the surface of the earth. The actual radio signal is traveling a bit further because it bounces between Earth and ionosphere as it travels. For this modem, the signal would be traveling line-of-sight and probably less than 1000km?

He’s good at running the pace they ask him to run and it varies from race to race. Harder than it sounds. Ideally, the pacer runs that pace with little variance rather than looking at their watch halfway through a lap and speeding up or slowing down.

Member of the engineering team here - I would break the history into 3 phases:

1) Alpha / Beta phase where we experimented with several off-the-shelf key-value stores (RocksDB, LevelDB, & BoltDB). During this early phase, we learned from observing a wide variety of workloads / use-cases that we needed a custom built engine to achieve our early performance goals. But, using these off-the-shelf key-value stores allowed our (at the time) very small team to focus on developing a useful beta product and gathering user feedback.

2) TSM storage engine for 1.0 - Developed from scratch based on our learnings from phase 1, this was the first production storage engine that shipped with 1.0 in 2016 and carried us through 2.0. It served as the workhorse for 3 - 4 years as both the number of users and size of their workloads skyrocketed, eventually bumping into architectural limits of TSM.

3) IOx - equipped with a larger engineering team and years of experience with a wide variety of workloads and use-cases, IOx was developed to handle rapidly growing time series workloads that users need to handle.

Excellent book if you're looking to understand the foundations of 2D & 3D graphics / game dev, although the topics covered have even more broad applications. I had quite a bit of experience with C/C++ going into it but no experience with game programming / math. I went through the book cover-to-cover when it was first published. Did all the exercises. Ran and stepped through all the code. Came away from it with a solid understanding of the basics and could have written a simple game engine I believe. I went on to tinker with a few real game engines and the knowledge gained from this book made it easier to get started with them. Highly recommended. Excited to see it updated and available online.

Hi halfmatthalfcat, InfluxDB team member here. I wouldn't say we encourage mixing InfluxQL, Flux, and TICK scripts. We encourage new use cases to use Flux and existing use cases to start migrating to Flux when possible. Allowing the three to interact enables existing users to migrate gradually and take advantage of newer features before they're fully migrated.

Regarding docs on advanced use cases, if you haven't already, try posting questions in the community forum: https://community.influxdata.com. Or, if you prefer Slack, there's a link at the top of that page to join our community Slack. We do our best to help with specific issues in those spaces and we also look for common themes that are causing problems for multiple users so that we can focus our efforts there, whether that's bug fixes, performance, features, or docs.

I haven't looked but the latest 1.7.x is probably close to 2 years old. There have been quite a few improvements since 1.7 so you might see some improvements by upgrading to the latest 1.x.

Minor nit on "TSM (not TSI)" - TSM (.tsm files) are the data files and that format hasn't changed. TSI is the newer, although mature at this point, indexing option that spills onto disk and can therefore be larger than the original in-mem index. You're probably using in-mem indexing.

We're always interested in feedback. My name is david. You can email me at <name> at influxdata dot com.

Hi physicles, member of the InfluxDB team here. What version of 1.x are you running? Also curious to know if you've tried 2.x.

No. When you get a spam call, the caller ID is often not random. It's usually the number of some other person on the spam caller's list of people to call, often someone from your same area code. That way, you see a call from your area code and are more likely to answer it. If you get upset and call it back, you won't be calling the spammer. You'll be calling some other innocent victim of the spammer.

Because spammers populate the caller ID with other people's phone numbers. For example, a spammer might make the caller ID show your (or my) phone number. The caller ID that shows up when a spammer calls you is usually useless.

Ditto, except the one I wrote only works for landlines. https://github.com/dgnorton/norobo