23,345 karma · joined May 29, 2010
I had to click the other link https://support.mozilla.org/en-US/kb/profile-management to understand that this is all about simple UI improvements to make it easier to work with existing profiles.
The blog post is more than confusing, it is misleading. HN should link to the support page instead of the blog post.
So the tl'dr is: the leading very preliminary theory is that the MD-11's left engine fell off the wing just like https://en.wikipedia.org/wiki/American_Airlines_Flight_191 (a DC-10, the immediate predecessor of the MD-11) which was caused by maintenance errors weakening the pylon structure holding the engine.
Also, Bitcoin can process far more than 7 tps through the Lighting network.
I wonder where your misconceptions come from?
If they had produced a platform with four 10 Gbps ports, then it would become interesting. But the whole hardware and bitstream would have to be redevelopped almost from scratch.
Actually, to be exact: I just checked my data and I forgot that technically the 2nd and 3rd longest sightlines I discovered are slight variations of the Pik Dankova sightline. 7 km east of this peak is another mountain with two spots from which there are two sightlines of 521.1 and 510.49 km ending in the same mountain range in China (a few hundred km away from the end point of the 1st sightline.)
Then the 4th longest sightline I found is the one that's arguably unique: 510.45 km, fully contained within China in the Kunlun Mountains from 38.614706,75.184529 to 36.517500,80.333333. So that's an interesting find.
Then my 5th, 6th, 7th, 8th longest sightlines are again slight variations of the 1st Pik Dankova sightline.
Then my 9th longest sigthline in the one in Colombia I mentioned.
It's very possible you could find different results and new longest sightlines, so I encourage you to continue your own research.
For starters here is a limitation of my implementation: my heuristic for finding a potential viewpoint (mountain peak or ridge of a plateau) is imperfect: in the DEM, a tile is considered a potential viewpoint if it is higher than or equal to it's 8 neighbors, and if it is strictly higher than at least one neighbor. Think about a group of 3x3 tiles. They are all the same height, except one tile on the edge of the group that is slighly lower than the others. Then in this case, the central tile is a potential viewpoint because we could have a sightline standing on this central tile, looking over the one neighbor tile that is slightly lower. That would be the case when standing on the edge of a plateau right next to the start of a valley.
But I can think of at least one case where I would accidentally dismiss potential viewpoints: if, when standing on this ridge, the tile behind us is slightly higher (even if it's just by 1 meter), then my heuristic would dismiss the central tile as a potential viewpoint, because my thought was the tile that is sligthly higher is going to be selected by my heuristic as a (better) potential viewpoint instead. But, in reality, if the tile behind us is only a few meters higher, then it is not high enough to look over our initial tile, then over the start of the valley. In that case the central tile is a viewpoint but would be dismissed by my heuristic. This is a very narrow corner case that probably doesn't affect my results, but I am not 100% sure. If the height difference is about 3 or 4 meters or more, the tile behind us would definitely have a clear and longer sightline, so my heuristic isn't breaking anything.
Anyway my whole project was just a weekend thing so I didn't care to be very precise. But now seeing your effort is renewing my interest in fixing my code. Oh and I should definitely port this to GPU as this workload is 100% compute-bound, mostly, sin, cos, sqrt and divisions.
"resolution of 3 arc-seconds (~100m²)"
This resolution is equivalent to tiles of 8500 m² not 100 m². I think the author confused tile edge length (92 meters exactly) with tile area.
My code was relatively unoptimized, it ran for 95 days on an 8-core 16-thread AMD Ryzen 5750G to crunch all the data. I have never published my code or results. I should really do it...
I downloaded a digital earth model of about 30 gigabytes from http://www.viewfinderpanoramas.org/Coverage%20map%20viewfind... which had a resolution of 3 seconds, so I had the elevation of each 90x90 meters "tile" of land. I wrote a simple algo in C that: finds potential viewpoints (mountain peaks or plateaus above a minimum ), calculates the longest sightline 360° around you, taking into account an atmospheric refraction coefficient (I used 0.13 which seems to be a default used by some panorama tools like https://www.udeuschle.de). It's really basic trigonometry: look one tile ahead of you, and the next one, etc, until you find the one with the highest vertical angle of view. Stop one sightline exploration when reaching a certain maximum distance (750 km in my implementation) when it becomes mathematically impossible to find a visible tile beyond this distance. And I found the longest sightline:
In Kyrgyzstan from Pik Dankova (41.059167,77.683333) which is at 5977.5 meters (in my DEM data), you can see 538.1 km into China if you look toward bearing 169.7° (roughly south) as you see some distant minor peak at 36.295364,78.75593 which is 6444.0 meters high. However this sightline is already known. But it's only theoretical. No one ever encountered good enough atmospheric clear-sky conditions to observe it from Pik Dankova. Using the panorama tool maintained by this cool German guy, you can verify it: https://www.udeuschle.de/panoramas/panqueryfull.aspx?mode=ne...
However one notable finding my tool gave me was it discovered the second longest sightline that is competely unknown up until this day AFAIK:
In Colombia, from Pico Cristóbal Colón (10.838333,-73.687500) which is at 5668.5 meters (in my DEM data), you can see 502.6 km over the plains of the Caribbean region all the way to the Colombian Andes if you look toward bearing 206.2° (roughly south-south-west) as you see some distant peak at 6.777286,-75.692304 which is 3347.0 meters high. Here you can verify it here: https://www.udeuschle.de/panoramas/panqueryfull.aspx?mode=ne...
I am not sure if this Comlombian sighline has ever been observed.
As I said I should really publish my code and results. And at some point I would like to optimize it and re-run it using a higher-precision DEM with 30x30 meters tiles instead of 90x90 meters. I think there are a few 30-meter DEMs available but I need to find the highest-quality one.
font-family: System UI;
That's incorrect. It should be: font-family: system-ui;
Author has it right in some CSS examples, but not the first one.I wouldn't call it "much harder". All you need to bypass the signature is to choose random ciphers (list at https://curl.se/docs/ssl-ciphers.html) and you mash them up in a random order separated by colons in curl's --ciphers option. If you pick 15 different ciphers in a random order, there are over a trillion signatures possible, which he couldn't block. For example this works:
$ curl --ciphers AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA:... https://foxmoss.com/blog/packet-filtering/
But, yes, most bots don't bother randomizing ciphers so most will be blocked.To be clear, I am comparing power consumption only. In terms of mining power, all these GPUs could only mine a negligible fraction of what all specialized Bitcoin ASIC mine.
Edit: some math I did out of sheer curiosity: a modern top-of-the-line GPU would mine BTC at about 10 Ghash/s (I don't think anyone tried but I wrote GPU mining software back in the day, and that is my estimate). Nvidia is on track to sell 50 million GPUs in 2025. If they were all mining, their combined compute power would be 500 Phash/s, which is 0.05% of Bitcoin's global mining capacity.
It's as much a bad idea as websites trying to reinvent scrollbars. No thanks. I prefer to use my native windows and scrollbars.
https://hwbusters.com/cpu/amd-ryzen-9-9950x-cpu-review-perfo...
I am not too surprised though. Samsung has a reputation for bloating their Android stack with junk.
"Moore's Law is already dead"
That's clearly false, have a quick look at this chart: https://semiconductor.substack.com/p/the-relentless-pursuit-...
I was thrown off by your statement, so here are some numbers: a modern chip like Nvidia's GH100 manufactured at a 5 nm process is 80 billion gates in 814 mm². That means a gate is 100 nm wide which is the width of 500 silicon atoms. On a 2D area that's 250k atoms. I don't know the thickness but assuming it's also 500 atoms then a gate has a volume of 125 million atoms.
So I guess you get your "8 orders of magnitude" difference if you compare the three-dimensional volume (7 atoms vs 125 million). But on one dimension it's only 2 orders of magnitude (7 atoms vs 500). And the semiconductor industry measures progress on one dimension so to me the "2 orders of magnitude" seems the more relevant comparison to make.
CO2 sensors are generally pretty accurate, but PM2.5 sensors are notoriously prone to false spikes usually caused by dust in or around the sensor: https://www.reddit.com/r/Awair/comments/10r1uyo/inaccurate_p... or https://forum.airgradient.com/t/unusual-pm2-5-readings-on-ne... or https://community.purpleair.com/t/what-to-do-about-incorrect...
My guess is it's likely a sensor in a hotel room accumulates dust over time, leading to high PM2.5 measurements maybe when something (eg. suitcase) bumps against the case, shaking the accumulated dust and releasing it around the sensor.