dgaudet

yeah one of the trackmania games -- which feature a nominally deterministic physics engine, allowing for replays from a recorded sequence of inputs... except the physics engine relies on libc transcendental functions. players are generally on windows, but backend servers doing anti-cheat validations via replays are running linux. this resulted in false cheat positives when the linux server was running glibc prior to the glibc rounding fixes... and as a result the guy's world record kept being flagged as a cheat. it's a pretty good video with a lot of detail on how they narrowed it down to specific glibc versions/etc.

it has become unfortunately common in marriott hotels in the (western) US, specifically the current generation of residence inn; and i think i've seen it in new towneplace suites as well. it's entirely a form over function decision: you end up with cool air wafting in while you shower, and you end up with a wet bathroom floor (including a soaked floormat).

the same hotels have a kitchen sink tap which has hot/cold selected on the vertical axis, with no indication of which direction is hot/cold.

form over function. so annoying.

if you're up for a road trip, then cedar city utah is an option from southern california. the mountains on the east side of town have plenty of fall colors (lots of hiking options, national forests/parks).

the article claims the playlist is "scientifically verified" ... but doesn't seem to cover the science behind the list construction or verification. is there a background article somewhere else?

FWIW the peakbagger app (android, ios) includes excellent fire and smoke layers. andrew has added these features over the past few years as fires have complicated the quest for peaks.

caltopo.com is another great tool with fire layers, useful for planning hikes in affected areas.

yeah i dunno how people live in the PNW, i was totally depressed the 8 months i spent in vancouver BC!

it would be kind of cool to have calendar software which has a "bad weather" feature: correlate the 10-day forecasts of the required attendees, and pick the least sunny timeslot. mind you i'd also want the software to keep track of how frequently i've hiked, because even a sunny day of meetings is OK after a couple days of hiking. gotta mix it up. i'm sure this bin-packing problem has a reasonable enough solution :)

i would prefer sunny days off, and bad weather days for meetings.

well i guess i won't be moving my music to spotify: i'm on google play music right now, and so i'm in the market.

> Some past, present, and potential clients include ...

i'm having a hard time reading past the word "potential". that suggests exaggeration to me.

i'm not sure i agree.

$100 of gas gets you about 24 gallons at california average prices, even at 20mpg that's 2x what you need to get to reno (218mi), on the way to reno you travel through sacramento. there are alternately many other central valley options at less distance from SF (from which many uber/lyft drivers commute to SF for their day -- for example stockton, modesto). redding is also 217mi from SF if you want to go north instead. eureka is only 271mi. grants pass OR, and los angeles are both in the 380mi ballpark, still within the $100 budget.

i'm not sure why you think vegas has a wider diversity of options -- it could be i don't understand your criteria for options. vegas is central in a vast amount of desert. it's 271mi to LA, 286mi to bakersfield, 302mi to phoenix and 421mi to salt lake city. a massive amount of NV north/northwest of vegas is off-limits military test range -- population density is extremely thin in most directions from vegas.

sources: gmaps for distances, and AAA for gas price (https://gasprices.aaa.com/?state=CA) i rounded up to $4.20/gal. 20mpg i picked semi-arbitrarily because i didn't find a good hit in the first search i did.

this pleases me in so many ways.

as a former public radio listener, who grew increasingly tired of finding something else to listen to during the all-too-regular fund drives, i very much appreciate the ability to skip forward on podcasts.

i'm also happier paying for good audio content than i am willing to pay for a dozen different news site subscriptions. my regular day is full of visual-attention-required tasks, and having an audio-only source of information and entertainment is worth paying for.

it's nice to know that it appears to be a successful business model for NPR.

for a long time i used a variation of this as an interview question for performance analysis positions at google. instead of focusing on I/O costs i was focusing on cache miss costs, but it's pretty much the same observation at a different scale. it's always seemed like an excellent educational example of the difference between theoretical and practical concepts in computer engineering, such as big-O and turing machine vs. practical problem sizes and hierarchical storage/cache capacities/costs.

the news article left me wanting to know more about the hike, and i discovered this ropewiki article[0] which seems to be related, and link to a more detailed trip report[1]. i'm more of a peakbagger myself, but the photos of the canyons are fascinating (many examples in google images).

i'm guessing satellite locator beacons (such as resqlink, spot or in-reach) don't work very well in canyons. you'd need a much more monster antenna and transmitter.

[0] http://ropewiki.com/Arroyo_Seco_Gorge_(Los_Padres) [1] http://www.teamsk.org/arroyo/seco.html

flying heavy components in a location where the winds are strong enough for wind power generation might pose some exciting challenges.

since C pretty much requires a stack, and a stack requires "RAM" of some form, it used to be necessary that the memory system be trained prior to executing any C code. however once the cache grew large enough, and appropriate "cache as ram" hooks were designed, it became possible to stand up a stack before even the memory system was alive. this definitely reduces the footprint which has to be assembly.

named ranges and DGET "sql-like" queries are in google sheets as well. (or perhaps what you meant is that few people know about these things, and don't use them, so you end up with unreadable messy code...)

motherboard features such as x16 or 2x8 are achieved with "pcie mux" chips. these are devices which select which of N pairs of differential wires is attached to the input/output differential pair. search for "pcie mux" will find many, such as [0]. if you look at the diagram you'll see that it connects wire pair A+/A- to either B+/B- or C+/C- based on the value of the SEL line.

these generally basic passive devices operating at analog signals level, no higher layer activity required. however some may exist which operate as "retimers", which do participate in the lowest layer of the PCIe electrical protocols (generally to extend reach). these are unlikely to be used for a typical x16 <-> 2x8 sort of motherboard feature though.

the example i picked here is 4 lanes, and you would need 4 such chips to do a x16 <-> 2x8. (spoiler: you mux lanes 8-15 from slot X to lanes 0-7 of slot Y, and there are both TX and RX pairs which need muxing.)

there do exist devices called "pcie switches" which operate at all layers of the pcie protocols, and allow for all sorts of sharing of the point-to-point links. examples at microsemi [1] ... for example a 48 lane switch could be used to connect two 16 lane GPUs to a 16 lane slot. this would allow either of the GPUs to burst to the full 16 lanes, or on average if both GPUs are communicating with the host then they would see 8 lanes of bandwidth. there's a picture of such a dual GPU card in this article [2], you can see the PCIe switch ASIC centered in between the two GPUs, above and to the right of the edge connector.

[0] http://www.ti.com/product/HD3SS3412

[1] https://www.microsemi.com/product-directory/ics/3724-pcie-sw...

[2] https://graphicscardhub.com/dual-gpu-graphics-cards/

the article seems to suggest that this is a port of the original (not web) google earth app to webassembly ... but what i'm seeing is another version of the web app. the desktop app has a zillion more features which are not available in the web app... aside from the similarity of their name, and the shared imagery, the two are completely different things. i'm bummed, i was hoping the desktop app was being given a breath of fresh air. it's one of the most important tools i use for planning hikes on infrequently climbed mountains.

is there technology around this? i mean i can imagine an API where the CC# itself is only necessary in the first transaction with a new vendor, during which the vendor makes a (signed) request for a vendor-specific token to use for future payments, and can forget the CC# immediately; future payment requests use the same signature chain and the vendor-specific token... making it easy to invalidate any/all of these tokens if the data is compromised, or if the end-user wants to invalidate a specific recurring payment, etc.

i'm in fantasy land, right?

unfortunately there are still many "land locked" public lands among those protected lands in california: public lands which are encircled by private lands, with no easement. in the sierra the access situation is generally very good, however there are definitely examples elsewhere which beg the question of what it means to be "public" when it can't be accessed.

for example, although the summit of berryessa peak is on BLM land, the only access is through private land. fortunately one land owner was convinced to allow an easement on a short section of trail to allow the opening of the berryessa peak trail, and access to this peak, but for years it was public and yet off-limits.[1]

on the west side of lake berryessa, cedar roughs wilderness, currently has no access. there are old roads/trails in there which are accessible from private land, but no public easement.

there was an article posted here last year about similar issues surrounding the crazy mountains in montana[2].

[1] https://www.summitpost.org/berryessa-peak/766290 [2] https://www.bloomberg.com/news/features/2017-10-25/this-land...

is it possible that airlines have arrivals quotas or limits in certain airports, or pay per passenger which arrives at an airport? this could cause what looks like "batshit" pricing.

taxes, airport fees, etc.

more clos advantages:

- simplified operations: can service/remove/add ToRs without affecting global routing or the forwarding capacity of the fabric.

- tor uplink flexibility: if a rack has higher bandwidth needs then double up the links (4 vs 8 in your example)

- tor location mobility: it's a lot easier to manage 4 fiber runs per tor than it is to manage 43 different fiber runs... backhaul to 4 spine blocks vs. a complex web of interconnect spreading all over the datacenter floor. with the fly network it's unlikely you can move a rack once it has been placed, at least not until you're ready to tear down the whole fabric and build something new. so you better get your rack density and layout just right. with tor you're stuck with your spine locations, but everything else can be moved around.

the fly advantages for homogeneous supercomputers built and decom'd N years later are clear... but for datacenters which grow and evolve with heterogeneous devices, fly doesn't seem to really hold up well compared to clos.