bmgxyz

If you're curious what's allowed on the ham bands, have a listen to 7.200 MHz LSB. (If you don't have a receiver, try one on the web[0], such as this one[1].) As of writing, someone is spamming the channel with racial slurs and KKK propaganda using a soundboard.

In my experience, enforcement of the rules is unheard of.

[0]: http://websdr.org/ [1]: http://websdr.k3fef.com:8901/

I wonder how much of the signal graph feature set could be implemented as an SDR++ module. It could even be written in Rust with some FFI.

Rather than rewrite the entire SDR++ core in a separate project, maybe it would be better to incrementally port the existing code to Rust in a fork. I don't know what attitude the maintainers have toward Rust, though.

Shannon-Hartley says the theoretical maximum data rate for a channel with AWGN is proportional to bandwidth and the log of signal-to-noise ratio. For an off-the-shelf microphone/speaker pair, I think 16 kHz and 80 dB are probably decent guesses. That would give a theoretical maximum data rate of about 425 kb/s. The practical limit is probably much lower.

It may be possible to increase the bandwidth by increasing the sample rate on both ends, but this quickly leaves the realm of consumer audio equipment (and consumer pricing). At some point you'd exceed the reasonable frequency responses for each device, as well as the medium. I imagine that air attenuates ultrasonic frequencies more than lower ones, but that's just a guess.

I think they only care about preventing data flow in one direction while still allowing it in the other. This isn't strictly an air gap, but it fits their use of the term "data diode". The fact that the unidirectional flow of information is achieved through galvanic isolation is probably just a side effect. In the ideal case, no information can flow from the photosensitive element to the LED. A determined attacker could probably exploit lots of side channels here, though.

> 25 years ago it seemed like physics was mostly complete, and the only remaining work was exploring the corner cases and polishing out all the imperfections. It doesn't feel that way anymore!

Physicists thought the same thing c. 1900, but then one of the "corner cases" turned into the ultraviolet catastrophe[1]. The consequences of the solution to that problem kept the whole field busy for a good part of the 20th century.

I'm highly skeptical of the idea that physics is anywhere near complete. The relative success of our technology gives us the illusory impression that we're almost done, but it's not obvious that physics even has a single, complete description that we can describe. We assume it does for convenience, in the same way that we assume the laws are constant everywhere in spacetime. I view this as both exciting and terrifying, but mostly exciting.

[1]: https://en.wikipedia.org/wiki/Ultraviolet_catastrophe

Writing code _has_ helped me feel better on some bad days. Even looking back at old projects brings me contentment and reassurance sometimes. On its own, it can't provide the happiness that a balanced life can, but craft and achievement are definitely pleasing. I would consider it an essential part of a good life, regardless of what the actual activity is.

This is different from meaningless work that brings you nothing except a paycheck, which I agree is important to minimize or eliminate. We should apply machines to this kind of work as much as we can, except in cases where the work itself doesn't need to exist.

My wife is also T1 diabetic. In principle, yes, a major airport's medical team should have everything that a diabetic needs to survive. However, depending on the person's blood sugar level at any given moment, it may be necessary to give them either insulin or sugar immediately or they will become disoriented, unable to move reliably, and maybe pass out. Hypoglycemia and hyperglycemia can quickly become medical emergencies. Given all that, it makes sense for a diabetic to be highly protective of their insulin and sugar supplements. In a crash, the medical team is probably going to be pretty busy and might not provide optimal treatment to a diabetic right away.

A "pancreas kit" can fit in a bag small enough to be carried in one hand, so it shouldn't be necessary to hold up an evacuation by carrying something large. As others have mentioned, this is also likely an instinctive reaction, and it's hard to criticize someone for reacting that way in such a stressful situation.

My mother said similar things before her death, and I accepted them with love while privately dismissing them. But since then I've softened a little. I still don't believe in those ideas in a literal, empirical sense, but they have emotional value for me anyway.

I guess I'm trying to say that, at least for me, it's been more pleasant to entertain these ideas as comforting fantasy, and I don't think that small personal allowance has eroded my more practical abilities elsewhere. Not struggling so much against this kind of thinking has freed me in a certain way.

This blog post[1] may interest you. As you suggested, the workflow seems to be:

1. Try various techniques that might trick the firewalls on both ends to let the connection through. This requires a relay for the initial negotiation only.

2. If (1) fails, then use a relay for everything.

[1]: https://tailscale.com/blog/how-nat-traversal-works/

>you can get a sport pilots license in as little as 20 hours of training

This is not enough training to operate safely, in my opinion. Even in VFR conditions, I think it would be negligent for an instructor to turn a 20-hour pilot loose without further oversight. Even if a student pilot has flown solo by that point in their training, their instructor still needs to sign off on all cross-country flights. Entering Class B with 20 hours is out of the question in my view.

I also disagree that the Sport license meaningfully decreases the cost of general aviation. The largest expenses are fuel and aircraft rental fees or maintenance, neither of which are mitigated in the long term by a shorter training period.

It sounds like you are probably more experienced than I am, so maybe I'm wrong.

I think this means that a previous iteration of this effort had a value of £249,000. The article is mainly about the current iteration, which has some other total value that is presumably larger. It isn't clear how much the current iteration is worth, at least from the article alone.

In general I agree that this might not be significant, unless the total value of the current contract is large or there are notable research or engineering results.

I use the Redirector[0] browser extension to do this, and it works great.

[0]: https://einaregilsson.com/redirector/

I hadn't tested it before, but yes, it looks like there's coverage for some major Canadian cities near the border, including Montreal, Ottawa, Toronto, and Vancouver. You can check your locations of interest on this map[0] (requires JS). Just click "Maximum Radar Ranges" on the left and see if you fall within the coverage circles.

As I write this, there's some light precipitation just north of Toronto, and threecast seems to give reasonable output there. Note that the radar coverage areas aren't always perfect circles because terrain can block the radar beam.

Canada may have a similar system with better coverage, but I'm not sure.

[0]: https://www.ncei.noaa.gov/maps/radar/

This seems to imply that there isn't any high-resolution precipitation data available that could provide these "minute-by-minute" forecasts, but that isn't true. The National Weather Service provides several radar products that give data with resolutions in the range of 500 m using their NEXRAD technology[0]. This allows for some pretty good estimates of when precipitation will start and end over the next hour or so. This kind of forecast product is called a precipitation nowcast. Other nations have similar systems.

If you use the NOAA desktop tool[1] to view the data from NEXRAD stations, you can compare to services like DarkSky and see that they are very likely using it without much editing.

The simplest nowcasts use optical flow techniques rather than meteorological modelling. On short time scales (less than an hour), these methods can give passable results. I built a tool[2] that pulls this NWS data from their Web server and gives you a nowcast.

[0]: https://en.wikipedia.org/wiki/Nexrad#Super_resolution

[1]: https://www.ncdc.noaa.gov/wct/

[2]: https://github.com/bmgxyz/threecast

I tried using this a year or two ago—seemed like a really cool idea, and I still think it is—but I couldn't find an actually useful application for it in my life.

Not saying there aren't plenty of neat applications out there, but once the initial "that's cool" feeling wore off, I wasn't sure how to actually get some value out of the system. For me, it felt like a time sink.

Curious to know if others have found use cases that are low-maintenance and high-value.

This sounds fun. Rust is amazing, and I've been playing with it on AVR chips lately. And I spent several summers sailing years ago. Email me if you'd like. Curious to know what you're working on.

I wonder how difficult it would be to implement a language for specifying Factorio factories without worrying about physical layouts. This post provides a lot of good insights into how that could be done. Once a factory is specified, a compiler could turn the high-level specification into a blueprint or a valid save file to be loaded up in the game.

Of course, the compiler would have no way to lay out the factory with respect to available resource deposits. Maybe that would have to be part of the specification as well? Or maybe the programmer (player?) could pass an empty map file as a compiler argument.

Also, this doesn't give any consideration to the tech tree or enemies within the game. I guess those could be compiler flags, as long as we're dreaming.

Look, all I'm saying is that it would be really cool to be able to check factories into version control.

When I started my last job, I thought I was going to be writing a lot of Python and C. It turned out that the position had a lot more React and TypeScript than I expected, and at first I was annoyed and afraid. I wasn't a frontend developer---or worse, a designer---but I didn't have much of a choice, so I dug in and learned the stack.

At first I resisted every change. What good is VS Code when I have Vim? Why would I learn TypeScript when vanilla JS has "worked" for me for so long? What's a Webpack config?

Once I began using the tools that my coworkers recommended, I started treading water and even swimming with purpose in the ocean of Web UI technology. I still have a lot to learn, but I probably would have kept on avoiding this area if my situation hadn't forced me into it. Letting my guard down and following the trends in my group helped a lot in this case.

The best lessons I learned during that period are that learning can't kill me and using good tools doesn't make you a bad engineer.

I know this joke, but in the version I've heard it's mechanical engineering students instead of programmers, their professors instead of conference participants, and the aircraft itself instead of the flight control software.

But the structure is the same.

These ideas have almost no empathy, and they frighten me. The world they describe is a dystopia.

I mistook the screenshots in the README for screenshots of [Doom Emacs][0]. The default theme looks similar.

[0]: https://github.com/hlissner/doom-emacs

I'm interested in trying to determine whether or not someone I know has this disorder by examining their 23andMe data (with their consent, of course). I imagine that it might be possible to write a program that does this for me, but I only have a high school-level understanding of genetics.

Can you recommend any resources for me to consult to try to accomplish this? Or do you think it would be too difficult for someone outside your field to attempt?

I see you mentioned that 23andMe data doesn't expose this result directly, but it seems like it might be in the full data export. If that's not the case, I suppose there's not much of an option.

I was about to write a reply claiming that you're different from autocomplete because you take input from more sources than just the words you've said before (e.g. your vision), but actually I can't see how that's much different from a language model. The approach seems the same, and all that's really different is the shape of the input data.

But this uncovers difficult questions about free will. If we're all just autocompleting based on a combination of the world around us, our internal state, and the physical laws, then what even is intelligence anyway? This view reduces thought to nothing more than an interesting dust storm.

Still, I find the original argument compelling, if not logically convincing. There does seem to be something missing from GPT-3 that differs fundamentally from human intelligence or AGI. But maybe that's an illusion.

Edit: I don't think you should have been downvoted, since your question is valid and constructive in my view.

Did this system for surface-to-air recovery more or less get its lunch eaten by helicopters?

Still, pretty neat.

I agree, at least generally. However, something I've learned is that privacy always has a cost. I wouldn't count on retailers to pay it when most of their customers won't notice or care, and I wouldn't count on governments to deliberately avoid reducing friction in their economies either.

I agree. However, in this case I believe most versions of rm would complain about passing "/" as an argument without also passing "--no-preserve-root", so there's that at least.

Thanks for this. I hadn't read it before, and it's quite interesting. In particular:

> One way to be sure? Ask them, “Are you alright?” If they can answer at all – they probably are.

When I was a kid, I spent a few summers learning to sail. Part of our training included responding to falling overboard or capsizing our small boats with crews of two. Our instructors insisted that whenever this happened we first call out to each other, "Are you okay?" and confirm it before attempting to right the boat. I never understood why, but now I do.

I think this is a neat idea, but I suspect it would be more useful as a standalone device than as a wearable. Devices like this could be installed in secure rooms or deployed on the fly in discreet locations with a high rate of success, I'd guess. Arrays of them could work together for better coverage.

Still, this may be the only real option in public spaces (i.e. outdoors). If you're okay with people knowing that you're trying to avoid being recorded, then this would probably be fine.

Perhaps more interesting to me than UNIVAC itself is the system by which all the weather data it crunched was brought to it in the first place. Without the Internet, how was weather data transmitted across the country? Wireless ground stations? Primitive digital telephony? Simple synchronous voice communication? And after that, how was it fed into the machine? I assume not all weather stations in 1956 had adopted a standardized method of storing data.

If you can't bring the data to the machine, it can't tell you anything interesting about it.

You may be right, but for what it's worth I caution you against equating being early and being smart.