condiment

The site is incomplete, and there are way, way more trains active at a given time. For instance the Tri-Rail and Brightline (high-speed rail) in Florida each have 5-6 trains running simultaneously. Brightline is notable as the US's first credible foray into high-speed rail. Similarly most major cities in the US have either light rail, rapid transit, or both, which is maybe not included in this map. "Passenger rail" might have some highly specific semantic meaning that leaves these out of this map.

Yesterday was “National silent film day” in the US, a holiday only celebrated by indie movie theaters. If you haven’t been to a silent film, they’re a worthwhile experience. Many original scores are lost, so typically a pianist (and silent film enthusiast) will score the film and perform live in the theater during the screening.

Most big cities have a 1-2 day annual silent film festival, and several small events throughout the year. There are even new silent films being produced, mostly as university projects.

The article assumes that Meta's bad news strategy is intended to reduce readers of bad news. I'm not so sure about that. The strategy to release bad news on a Friday is intended to prevent that bad news from becoming the media narrative of the week. Likely that approach doesn't work for a company of Meta's size and importance.

When they release their bad news in the midst of another strong prevailing narrative, all eyes are on the other story, not on meta. There's a fixed capacity for headline news, oped columns and blogs, and hot takes / outrage on social media. If all eyes are focused on FTX or the Queen or the US elections, they might notice Meta's news but they're not going to start the flywheel spinning on it. So even if the same-day readership for their bad news is high, memory of it is low because interest isn't sustained.

The best case scenario for an operational failure is the loss of a single AZ, but many of the scenarios you described are things that could impact an entire cloud vendor simultaneously. As others have pointed out (in discussing the Carrington event and the recent Facebook outage), it's not a matter of if it will happen, but a matter of when. And then it's just a question of duration and scope of the impact.

At this point around half of the world's leasable compute is concentrated in fewer than 100 facilities, the locations of which can easily be found with a google search. Using public satellite imagery you can identify network connection points as well as follow power transmission lines. In a wartime scenario, these are industrial targets with astounding strategic value, a tiny geographic footprint, and limited collateral damage in terms of human life. The Nagasaki and Hiroshima of the future could simply be kinetic attacks against a couple of datacenters. I'm alarmed that nobody is prepared for this and the industry zeitgeist seems to be to continue the consolidation of our economies into the cloud.

I’m very impressed by the video quality and the bitrate. The DJI FPV systems sending HD video use either 25 or 50 mbit/s, while this is getting comparable quality with an order of magnitude less throughout. It has me wondering if the 25mbit/s is a large amount of error correction bits sent in order to improve latency.

Two questions I have - what is the video latency for this system versus a DJI FPV system? And how many devices can be supported concurrently from a single access point?

It would be exciting if this tech could evolve to support “crowded fields” for FPV races.

The article is suggesting daily testing and used "testing at the door" as an example.

Wouldn't it stand to reason that you could be tested once per day, in the parking lot to a mall or some other shopping establishment, and thereafter _verify_ that you had been tested that day for the remainder of your commercial transactions?

Thinking in those terms, 10 minutes per day is not so great of an imposition. We could formalize it and create drive-through test centers where you drive up, spit into the tube, have a bar code on your phone scanned, and drive off. On your way to the mall you get a text message with your results. Everywhere else you visit that day scans your phone upon entry and confirms that you've been tested.

I own a Xiaomi Mi m365 scooter that I use daily for commutes around downtown Denver and while it's lighter than this bird, it is by no means lightweight. It won't fit under a desk. It attracts funny looks if I bring it into a business or restaurant, and locking it up on the street is annoying and time-consuming. Even when it's folded and locked up, people try to steal it.

The Bird One marketing document doesn't really go into detail, but the huge battery and GPS functionality suggests to me that the expected approach for using these scooters is to park them on the street and leave them there. If they borrow the anti-theft functionality that you see in VanMoof bicycles, this scooter makes a lot of sense. You ride it around town. You charge it in your garage. You leave it on the street when you're done with it. If it's stolen you look up its GPS location and the police help you get it back. There's low urgency to charge it. If it breaks, they'll fix it for you. And if you don't have it with you, Bird comps your rental scooter.

That's a lot more compelling of an offering than just a "heavier, faster, longer-range" scooter.

I don’t disagree. What I meant was that it’s a nonstarter for replacing any existing installation of splunk, which is desirable for me as an enterprise customer who spends a nontrivial amount of money every year on this sort of tool. There are a lot of obstacles to replacing an existing, effective implementation of a tool, and I listed what they are in the hopes that somebody pays attention.

Speaking frankly, unless a Splunk alternative implements API compatibility for search, it’s a nonstarter in the marketplace. At the enterprise I work at, developers and operations teams both use splunk to observe and analyze application behavior, and have thousands of dashboards and alerts set up and integrated into mature operational processes. Migrating this over to another application is nontrivial. And the biggest problem isn’t even a technical one, it’s a social one - how do you train three hundred engineers to use a different log search tool.

I would absolutely love to see a competitor emerge that addressed the migration problem through a compatible search api. Handling other timeseries data like metrics would just be icing on the cake.

I use a combination of tools for visual documentation. Block diagrams and sequence diagrams together are a pretty effective means of communicating.

For block diagrams that illustrate relationships between components as a sort of directed graph, I prefer Omnigraffle (on OSX). It's fast and effective, easy to label boxes, lines, and interactions, and supports exports to pdf and png for quick sharing. Where omnigraffle falls over is in terms of its popularity and accessibility. You can't really review the diagram source as a part of the code review process, and the output diagrams are not useful to the visually impaired. Popularity is a factor because even if a dev knows some piece of block diagram software well, it's likely that they know a different one than anyone else. For that reason, we're not prescriptive about the tool used on our team, only that some form of block diagram is included with the documentation for a feature or component.

For sequence diagrams I use web sequence diagrams, for which I hold a commercial license. These diagrams are great for illustrating different workflows, with the caveat that we generally need several very similar diagrams to explain even the simplest features. These also benefit from having a straightforward text format that can be shared as a reviewable part of the source tree, and which can be read and edited by the visually impaired. Sequence diagrams are a more effective tool for demonstrating the veracity of code against a desired specification than block diagrams are, but understanding the top-level component layout is generally a prerequisite.

Not sure about the general popularity of either of these, but they've been an effective toolchain for me so far.

I think taxes based on users or revenue are misguided.

This sort of tax ought to be based on a relative share of megawatts of compute power, and should be progressive in a way that prevents any single entity from controlling more than N% of all computational capacity.

I would suggest speaking with a tax attorney. Depending on how long you've owned it, and how much you paid for it, the sale of your house may constitute income, which would be taxed at 39.6% and (at this level) also subject you to the AMT.

That may limit some of your options. If it turns out your sale isn't tax exempt, renting the property out through a property management firm or reinvesting in real estate may make the most sense. Otherwise I'd echo what others have said, some sort of CD.

I use million short to search for howtos written by real craftsmen in their field.

One example is an end-grain cutting board that I made recently. For most things Ike that, the top 1000 are dominated by made-for-Pinterest blogs or major sites that aggregate low quality content that's good enough to get hits but not good for much more than that.

> Peaks are going to be really big

This got me thinking, what does the power draw look like?

A Model S has two battery options

- 60kWh / 335km @ 5.85km/kWh - 85kWh / 426km @ 5.01km/kWh

So a battery will need to recharge 1kWh for each 5km traveled. The typical US commuter travels 48km per day. 50km per day / 5km/kWh is 10kWh per day of required draw.

Say 10 hours of charging per day smooths this out to an additional draw of 1kW per driver (a big assumption).

With 100M additional electric cars (there are only 165M daily commuters) in the US, the additional draw on the power grid would require 1,000GW of additional capacity.

That's a 25% increase over 2016 power generation. Compared to the 1999-2016 growth rate of 9.5%, it is significant, but seems manageable. Especially considering it'll take 10+ years for electric cars to be widely used by a significant fraction of the US workforce.

Seems like it might be prudent to first try extracting 35% of the heat from a volcano smaller than the Yellowstone Caldera. We might learn some things, and if we get it wrong the consequences don't result in widespread starvation.

That said, it's obvious that this plan is just the start of serious investigation into how we can engineer mitigations to an eruption at Yellowstone. I would be interested in seeing a model of the impact that surface-level cooling would have on the pressures deeper in the system. If we prevent an eruption now, are we making it worse in the future?

Other solutions I can envision might be to deliberately trigger smaller eruptions over longer timescales at the boundaries of the caldera. We could also look at large-scale mitigations for volcanic particulates in the atmosphere, including solutions that may require several hundred or thousand years of advanced preparation for success. If we could control the impact of a significant yellowstone eruption to a single hemisphere, or limit the duration to a single summer, most ecosystems would be able to recover quickly.

Variety of reasons.

Early on, I had a lot of trouble getting the flood and drain system to work correctly. Substrate would get caught in the siphon, and prevent it from initiating the drain.

Once the flood and drain system was working, I ran into issues related to my use of heterogeneous substrate. I had both hydroton pellets and perlite in the grow bed. When you mix substrates of multiple densities, both of which are lighter than water, the flood and drain cycle will result in the lightest substrate filtering to the top of the bed. This caused all of my plants to sink into the water.

After solving that problem, it became a simple matter of fish nutrition. I live in Colorado, which has very hot summers. Around 90°F is typical, but in the evenings the temperature gets down quite low. As it would happen, the average daily temperature was between 60 and 70°F. Fish modulate their diet according to the temperature of the water that they're in. And my koi would not eat enough.

In the end, the project was a lot of fun and I learned a lot. But I couldn't justify repeating the effort after all of the fish died in the winter. It didn't seem humane.

Real estate is cheap, power is cheap, personnel are cheap, equipment is cheap.

A few years ago I was pursuing aquaponics as a hobby over the summer. It was clear then that economies of scale were rapidly driving down the costs of indoor horticulture. My aquaponics project failed, but the basic economics of grocery-attached farms make a lot of sense. I built a business model to determine the economics of running a farm in a shipping container that could be deployed to an underutilized Whole Foods parking lot.

The model accounted for a 81m3 shipping container being filled top-to-bottom with fruiting plants, like tomatoes, but it's easily adjustable to other plants, like lettuces. The model is pretty sensitive to things like the productive life of the plant, lead time to productivity, and sale price.

Selling heads of lettuce for $3 each yields around $6000/yr in gross revenue per container per year.

This was $17k net less $720 in labor, $6k in equipment, $3k in real estate and $1k in electricity. Lots of room for optimizations that could push this business over the $1B mark.

The model, in case anyone's interested: https://docs.google.com/spreadsheets/d/1DkjOIs7hXyxIiN_iWXK0...

Your MacBook microphone can detect ultrasonic frequencies above 22khz, though I'm not sure whether my observed ceiling is an artifact of the microphone, or of the speaker I was using to emit the tones.

In my informal tests, most people are unable to hear any tone above 20khz or so. This is discovered, naturally, by starting with the highest pitch tone I can generate at the loudest volume, and lowering the pitch gradually until somebody covers their ears and starts screaming. This is usually the youngest person in the room.

You can generate and receive audio using web audio APIs. Creating a browser extension to detect ultrasonic comma would be fairly straightforward.

We ran into the same ksoftirqd issue in our own bare-metal deployment. Turns out there's a performance regression in the linux kernel that manifests when we configured the system with more receive queues than we had physical cores in a single socket.

We dropped the receive queues down to 12, from 48, and hit line rate. More info here:

https://github.com/coreos/bugs/issues/1275

Here's the press release from the Max Planck Institute:

http://www.ipa.fraunhofer.de/en/cable-driven_parallel_robots...

I've been experimenting with it as well and it looks like you have to copy several directories to get it to work out of the box - templates, public, custom, log, and data.

But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration.

What we've done for our internal Go projects is wrap them up with an .rpm installer that handles the creation of directories throughout the system, drops init scripts where they're appropriate, and sets up necessary cron jobs and logrotate rules. I don't think this is the best approach, but at the same time I'm not familiar with any good alternatives.

For all the hand-wringing about ISPs creating an "internet fast lane", OpenConnect sure seems like a step in that direction. If Netflix is allowed to colocate their server in an ISP's facilities (effectively eliminating the cost of their egress bandwidth), how does that not give them an unfair advantage against other internet video operators who lack the leverage necessary to broker this kind of deal?

OpenConnect isn't the first attempt at this sort of business model, either. Back in the 90s, Akami tried this same thing with their "FreeFlow ISP" service model - putting their servers in the ISP's point of presence in order to eliminate their bandwidth costs. Then, as now, major ISPs refused.

I read the documentation today and it's actually very straightforward and in some ways easier than managing migrations using South.

Essentially, you'll run a single initial/fake migration at the outset, after which the manage.py syntax is almost identical to that of South. The big win from my perspective is that excluding an app name from the migration commands results in all apps being migrated.

https://docs.djangoproject.com/en/dev/topics/migrations/

I had the same attitude, so I forked it and rewrote the PHP endpoints as a Python script, which I execute outside of the context of the application via a cronjob.

https://github.com/arbuckle/linux-dash

Useful post. NTILE operations are also useful for evaluating the results of 50/50 tests against revenue or other metrics where your data fits an exponential curve, or where outliers tend to skew the performance of one group incorrectly. After normalizing your datasets so that each group has identical numbers of users, a graph comparing the distribution of your metrics on a percentile basis can make it trivially easy to visually evaluate the results of a test.

As far as using NTILE to find the one metric that matters is concerned, it's a useful tool, but the challenge isn't in structuring and executing SQL queries so much as it is deciding which metrics to focus on and attempt to correlate to user retention.

In my experience there can be hundreds of metrics to search through, and correlations between your metrics and user retention are not always obvious at face value, or worse, they might represent a tautological consequence of retention without being the cause of retention (ie, the user has lots of badges because the user is active on the site, but they are not active because of the badges). In these cases, you risk investing valuable development resources optimizing for something that will have no impact on the bottom line, when that time might have been better spent trying to identify novel metrics and getting them into the database for analysis.

The fact that many of San Francisco's homeless are suffering from mental illness in some way doesn't ameliorate the damage caused by the growing divide between the haves and the have-nots in the region. While it's fine to address the causes of persistent homelessness, and to look for solutions to it, it's a completely different phenomenon compared to intermittent or temporary homeless the average middle-class family works to avoid.

The video mentioned that many middle-class families are one paycheck away from financial ruin. That is, rent and expenses in the city are so high in relation to wages, that missing a single paycheck or being out of work for just one week will result in a family losing their apartment and possibly being homeless.

As an outcome of the disparity between incomes and housing costs, low-income families are living 2- and 4- families to an apartment. 40x rent for a 3-bedroom (family) apartment in SF is $120,000 a year - a wage that is more than double the median household income in the US.

This is the more pressing of the problems the video addressed, and I think we would benefit more from discussing solutions for this than we would from wringing our hands about the myriad causes of persistent homelessness.

I agree with this. Media queries are a tool that eliminates the need to maintain separate HTML templates for mobile- or tablet-specific versions of a website. They work well at this task.

Element queries as described by the author address an entirely different set of concerns, which is that modular components of HTML might be re-used in varying situations, and depending on the implementation you might want to style them differently. Media queries are the wrong tool to solve this problem.

The problem is that when we want to use this:

  .testimonial (max-width:27em) {font-size: 0.8em;}

We have to use a context-specific style definition instead:

  .testimonial {font-size: 1em;}
  .signup .testimonial {font-size: 0.8em;}

Or, better (from the parent):

  .testimonial.vertical {font-size: 0.8em;}
  .testimonial.horizontal {font-size: 1em;}

You might still have to revisit each of these styles in a media query to apply changes depending on the global presentation. So while the proposed element query might eliminate the need to chain selectors, I do not believe that it simplifies media queries in any meaningful way.

Correct me if I'm wrong, but wouldn't the best place to combine and transform model data be in the model itself?

For trivial cases, this could be implemented in the model's 'defaults' function. (by computing the transformed field value in the function and returning a hash) If you forsee the need to update the value of the dynamic field in response to the client updating the model, you can perform the calculation again in the Model's 'validate' function.

Speaking from experience, logic in templates is convenient for trivial use cases, but can be very difficult to maintain once a project grows.

This looks to me to be a page-for-page clone of another url screenshot service that made it to the front page a couple weeks ago.

http://news.ycombinator.com/item?id=5257432

Compare: https://urlbox.io/docs

http://www.url2picture.com/Home/Docs

I'm curious to know how VS compares to PyCharm in terms of how rapidly the Python environment is able to restart after a code refresh.

It's been my personal experience that PyCharm's Run/Debug configuration is fast to restart in Run mode, but considerably slower in Debug mode, taking 5-10 seconds to restart and attach the debugger. So while I'd like to be able to work with breakpoints and inspection always available, in practice those tools have been harmful to my productivity.

If VS is better or faster in this regard, it might be worth a try.