The same thing happened to me. Escalating levels of non-response from my system, starting with the browser slowing down and culminating in Process Control stopping. I think it may have to do with uBlock Origin, which is default in Brave: on desktop (Edge with uBlock), it quickly spawns hundreds and hundreds of blocked POST calls to litix.io, an analytics website. These seem to be coming from the video player, which is constantly trying to beacon information back home. The site hovers around 10% of CPU on my desktop and I have to keep reloading it to poke around the devtools.
I would suggest making the analytics less aggressive and adding some kind of error catching so that it doesn't attempt to send data hundreds and hundreds of times.
I’m on plain vanilla Mobile Safari with no content blockers and the site gets unusable as you scroll down through the videos. My device is also now hot enough to melt the sun, too.
Genuinely curious -- is there a reason not to exploit someone who voluntarily enters into that relationship? I always assumed 'exploitation' meant forcing people to do things they didn't want to do.
Well, it's a moral question and therefore there is no universal answer, everyone decides it for themselves. And given the fact that when presented with a choice between starving under a bridge or working a back-breaking work for 12 hours per day, most of the people historically have voluntarily chosen to labour, one could argue that indeed it is entirely ethical.
def calculate_backlinks(
pages: Dict[str, Page], attachments: Dict[str, Attachment]
) -> None:
for page in pages.values():
for link in page.links:
linked_page = find(pages, attachments, link)
if not linked_page:
info(f"unable to find link", link, page.title)
continue
linked_page.backlinks.append(page)
No deduplication performed. Since he's parsing the backlinks directly out of the markdown, you don't have to worry about a recursive loop where the backlinks section on one page appears as links in another. A simple solution would be to change the datatype of backlinks from list to set.
I think that the UX could work really well for mobile with one significant tweak.
A typical design pattern on mobile is that if information is obscured for some reason, you click on it to expand it. Consider a drop-down text box on a blog: there's a little arrow and cut-off text with an ellipsis (...). When you click on the arrow, the cut-off text expands to fill the screen and allows you to read the rest of it. In contrast to what other users have said, this doesn't need to be idempotent. Tapping again hides the box.
To apply this design pattern to your site, simply make it so that tapping anywhere on a bar brings the UI to a known state, eg with the bar in the center with the text at a readable scale. This would work either horizontally or vertically.
Benefits:
- Your idea of the UI rescaling is preserved, and you can preserve the animations between states. I think the "rescaling bars" idea is fun.
- Cause and effect is preserved. If I want to read the text on the bar, I should not have to click on some arbitrary point above the current location of the bar.
- Further, the user does not have to hunt for the correct spot to click on a bar to make the text visible. Instead, clicking on a bar immediately and always makes all the information on that bar fully visible, by design.
I think this tweak would significantly improve the experience of interacting with the website.
It also pulls in about a hundred separate Haskell libraries along with it. Not really complaining, but it's funny that pandoc accounts for about half the programs on my laptop.
The speed of sound in an ideal (calorically perfect) gas is given by
a = sqrt( gamma * R * T )
where gamma is the ratio of specific heats (thermodynamic property of a gas, which may vary with temperature), R is the individual gas constant, and T the temperature of the fluid. All of these are going to be different on Mars versus on Earth:
Earth:
R = R_atm = 287 J / (kg * K)
gamma = 1.44
T = 293 K (taking room temperature as an average temperature)
Mars:
R = R_CO2 = 188 J / (kg * K)
gamma = 1.37
T = 210 K (from a quick google, about -60 deg C)
If the Martian and Earth atmospheres were at the same temperature, then the speed of sound on Mars would be 80% that of the speed of sound on Earth. Given the temperature difference, the speeds of sound are
a_mars = 232 m/s
a_earth = 347 m/s
So yes, much of the difference is due to the composition: the Martian atmosphere has a higher atomic weight, which leads to a lower individual gas constant, and decreases the speed of sound. However, a substantial amount of the difference is simply due to the different temperatures on the surfaces of the two planets.
The classic is How To Win Friends and Influence People by Dale Carnegie -- highly recommended. If you're young and looking for something more helpful in romance, watch Before Sunrise.
Interesting article! Given that subtraction isn't closed on the natural numbers, I wonder if it would be possible to implement subtraction as operations on a new type (Integer, Z):
Z = N x N (Cartesian product or sum type)
for p, q in Z: p=q if p.first + q.second = q.first + p.second
p + q := (p.first + q.first, p.second + q.second)
p - q := (p.first + q.second, p.second + q.first)
Rational numbers can similarly be defined by new operations and equivalence relations on the product set Z x Z. I don't know enough Rust to say whether it's feasible to implement this in the type system, but I'd be curious to hear from someone more experienced!
https://docs.rs/typenum/latest/typenum defines a "reasonable" implementation of integer arithmetic including addition, subtraction, multiplication, and division (and abs, and remainder, and a bunch of other "standard" integer ops).
I think that building rationals on top of it would be pretty easy, though not necessarily performant.
That first result re: tires is simply wrong. Wider tires don't have a larger contact patch; the size of the contact patch is determined by the weight of the car and the air pressure in the tires:
A = W / P
So the reason wider tires improve handling is more complex and subtle. Also, FTA:
Assuming a baseline of a moderately wide tire for the wheel size.
- Scaling both of these to make both wider than the OEM tire (but still running a setup that fits in the car without serious modifications) generally gives better dry braking and better lap times.
- In wet conditions, wider setups often have better braking distances (though this depends a lot on the specific setup) and better lap times, but also aquaplane at lower speeds.
- Just increasing the wheel width and using the same tire generally gives you better lap times, within reason.
- Just increasing the tire width and leaving wheel width fixed generally results in worse lap times.
A full accounting of the effects of changing tire width should explain all of these effects.
As a partial explanation, maybe it's not the case that area = weight/tire pressure as an absolute rule? In which case we get back to the layman knowledge of "wider tires have a greater contact area."
As an extreme example, run flats at atmospheric tire pressure don't drastically change their area.
I would suggest making the analytics less aggressive and adding some kind of error catching so that it doesn't attempt to send data hundreds and hundreds of times.