It's not a commercial application, but I have 2 raspberry pis rack-mounted[i] running some utilities for my home network (pi hole, gps-based NTP, ads-b data for FlightAware). Using PoE means no USB power bricks, no USB cables running all over the rack, and one less thing I need to plug into my UPS.
I am slightly disappointed that this doesn't work in Firefox, despite the fact that I have an add-on[1] installed to add U2F support. Github for instance is able to detect U2F support and let me use it.
That said, I understand the lack of support since I am an extremely small niche, and this did prompt me to finally add 2FA to facebook (U2F and code generation from my Yubikey Neo)
FLAC audio support is simpler, it's just adding a self-contained FLAC decoding library, and wiring it to the already-existing audio code.
For U2F, they have to write code to interact with the operating system USB API (for each operating system), plus the main U2F code, plus a Javascript API, all while taking care to not cause any new privacy leaks or worse.
The USB part is the simplest part. U2F uses USB HID for messaging. That's probably less complicated than using the D-Bus interface. And anyhow there's probably already an open source library for U2F USB HID clients. Mozilla will probably use whatever Chrome is using.
The real complexity is in exposing the interfaces through Javascript and orchestrating all the GUI components. In fact, U2F doesn't even require a hardware token. It was designed so browsers could implement everything in software to hasten adoption.
Facebook engineers responded to this in the U2F issue on the Firefox issue tracker. It turns out that for this particular technology determining whether or not your browser supports U2F is not yet feasible, so they resort to user agent sniffing. You can use Firefox with the third party plugin if you spoof the user agent to Chrome.
I just implemented U2F, and it's a bit of a pain to detect that the plugin is there. You have to load the real u2f js, then check if functions on the u2f object that are normally there aren't anymore, since the firefox plugin strips all of them off but 2. Doable, but a pain.
The way that the author uses GPS to get time (NMEA messages) works well for the purposes of the article, eg syncing a wristwatch to ~1 second accuracy. As another poster pointed out though, these messages are only accurate to about a half-step one, and it is actually worse than just using an internet NTP signal.
If you want to build a GPS based NTP server, you need a GPS board that outputs a PPS signal. When I built mine I used an adafruit board hooked up to a raspberry Pi's GPIO pins.
It's something of a bear to get everything to play together properly and get the extremely precise PPS signal to the NTP server, I recall it required a custom kernel module and a lot of tinkering with tick rates.
quantum computers, at best, divide the bit-strength of a symmetric key like AES in half[1]. Brute forcing a 128 bit key is theoretically possible (in the sense that you can do it if you marshal the entire world energy output to the cause, you could crack 1 key/yr), but not a 5 minute process.
that is assuming that there is no better quantum algorithm for aes specifically. grover's algorithm is only optimal if brute force search is the only possible approach and there are no other exploitable properties.
considering that there already theoretical attacks that (marginally) faster than brute force on classic computers who knows how much more one could squeeze out with quantum algorithms.
It's very obvious how special structure exists in cryptosystems that use finite cyclic groups, such as in discrete log cryptosystems.
But in AES? that sounds unlikely and really unfortunate.
I think it's more likely that large quantum computers would aid in mathmatical exploration that uncovers currently unknown vulnerabilities that could be exploited by classical systems.
Bruce Schneier and others[1] have done the math on brute forcing 256 bit keys: even with a perfectly efficient computer using the least amount of energy possible, you would have to deplete the entire energy content of the Sun to just iterate over a 225 bit keyspace once, let alone do anything meaningful with those keys.
It's estimated there are 10^80 atoms [1] in the visible universe, so 2^256 is definitely a huge number. I didn't realize 256 bit brute force was nigh feasible with only a solar system.
I'm a bit surprised the quantum algorithm only gives a polynomial speedup.
In what is probably the biggest case, FlightAware, a lot of the data comes from a fleet of users running ADS-B[1] receivers feeding data into their system. ADS-B data is what Air Traffic Control uses to track planes, and it's receivable using using a cheap TV tuner and a raspberry pi[2]. It ends up being probably the best way to track planes very precisely, as long as you can get enough coverage, which flightaware manages to do pretty well [3]. They then package this data and sell it via an API/tools for Fixed Base Operators or apps like Just Landed.
Our network ADS-B ground stations is one of our fastest-growing data sources, but we also get data from the FAA, other national aviation authorities (UK, Australia, Eurocontrol, Central America, etc.), directly from airlines, satellite avionics providers, etc. Live flight tracking is a deceptively difficult problem - on the surface it seems as if you could simply collect data and regurgitate it (that's what I thought before I came onboard), but there is actually an enormous amount of processing and inference based on sometimes incomplete, inaccurate, and conflicting data, even for mainline airline flights. That's not even getting into GA or flights in areas of the globe where we lack complete coverage. It's a really interesting set of problems!
It sounds like FlightAware is a much smarter, and more technologically innovative company than some iOS app maker. How come we aren't reading an article about them?
I use FlightAware all the time, but didn't know they pull the data directly from the planes.
I'm guessing FlightAware is one half of the "duopoly" spoken about in the submission.
Edit:
Looks like the cost per 1k queries for flight arrival times is $7.90 USD, which is a Class 2 query @ $0.0079 USD per query at the highest tier [0], but it goes down with more queries. You actually also probably want to pull their "AirlineFlightSchedules" API data to pull initial schedules for the day, which is a Class 1 query @ $0.0120 [0].
How many flights globally, per day? ~100,000 [1]. Once you fall down into their tiered pricing, and use their "15 results per query" rule, it amounts to ~$80. Once there is flight information for each flight for the day, there will likely be periodic update times. There's a firehose feed, but they don't specify pricing, so I'm not sure what the cost is to provide live updates.
If we say 5 updates per flight (total guess), that becomes ~500,000 queries daily of Class 2 data. I'm confident there's a way to batch these, so this comes down to ~33,334 requests, which puts us at ~$181.34 in additional charges per day.
So our daily costs are now about ~$261.34, or ~$7,840.20 per month, assuming they're not pulling data on-demand. This changes somewhat significantly if an app (correctly IMO) only pulls data for flights it's asked about. You get to cut out the $80/day entirely, and only some portion of the $181.34 is actually paid each day. If you consider the ~28,500 domestic flights in the US [2], and if app users only search for half of those, costs drop to ~$162 per day, or $4,860 monthly (plus the unknown cost of the firehose).
So, because of the cost of the data alone, your app will have to pull in a bunch of users. Wait, how many? Let's figure that out, based on an estimation strategy I pulled off of Quora (so it might be wrong) [3]:
Each user checks their flight status 3 times, which takes them ~1 minute overall to read, so we get 2 impressions [3]. I don't really know what these other two things are, but I guess we'll next assume 100% fill rate and eCPM of $3. But that's just per flight. 694 million passengers took flights in the US this year [4], and while I know we're getting into some pretty speculative territory, that's at least 2 flights per person per year, not to mention all the other people who also check on flight statuses of their friends/family. I feel comfortable saying that each person would check this app at least 15 times a year (you'd use it if you had it), or 0.04 times a day, which would give 0.08 impressions per day.
To cover costs for the data alone, you'd need 810,000 users. Even if each person used this app twice as often, you'd still need 405,000 users. That's completely untenable. I'm actually wondering if my math and assumptions are correct...
Since a screenshot of the Just Landed app shows up in the image carousel on your link, I am assuming that they used FlightAware for their data. FlightAware charges people for API access, and also specifically provides a set of tools for FBOs (https://flightaware.com/commercial/fbotoolbox).
well, for one, the IRS doesn't treat bitcoin as a currency, but as a commodity. While some foreign currency transactions fall under the regime of capital gains, a transaction resulting in the gain/loss of less than $200 are specifically excluded from capital gains [1].
Note that this relates specifically to changes in value of the US currency in relation to the commodity or foreign currency. In this sense there is a difference between a sports car and a cup of coffee encoded in law. If the euro you bought for $1 is suddenly worth $1.02, and you buy a 1 euro coffee, you'll only realize $0.02 in gains, and not hit the $200 threshold. If you buy a 100,000 euro sports car, you will realize a $2000 gain, and have to report that on your taxes.
Since bitcoin is a commodity, it doesn't matter if the value moves 2 cents or 2 dollars or 2 million dollars, all gains are capital gains.
So if you buy a coffee with euros you specifically don't need to report that, but with bitcoin you do. Whether the IRS is going to notice that you don't record every single capital gain arising from a bitcoin transaction is another question, but there is a major difference between foreign currencies and bitcoin as far as the IRS goes.
For one, Python is very big in the GIS space. Python is one of the main scripting language for ArcGIS, which is the main software platform that GIS folks use.
traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that.
You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid workflow for a lot of people who don't want to be sysadmins in addition to developers
[i] https://www.amazon.com/dp/B08F9X528J