Readit News logoReadit News
Dylan16807 commented on Ban me at the IP level if you don't like me   boston.conman.org/2025/08... · Posted by u/classichasclass
SoftTalker · 3 hours ago
You save them in a database. Probably in clear text. Six of one, half-dozen of the other.
Dylan16807 · an hour ago
A password being put into a normal text field in a properly submitted form is a lot less likely than getting into some query or path. And a database is more likely to be handled properly than some random log file.

Six of one, .008 of a dozen of the other.

Dylan16807 commented on Google's Liquid Cooling   chipsandcheese.com/p/goog... · Posted by u/giuliomagnifico
smachiz · a day ago
in their first serial design, that's exactly what it was doing.
Dylan16807 · 3 hours ago
They mean it doesn't sit around and wait until it's hot, which then makes it "used" and unable to cool something else. It keeps moving through the first chip and is only a small percent saturated.
Dylan16807 commented on Google's Liquid Cooling   chipsandcheese.com/p/goog... · Posted by u/giuliomagnifico
friendzis · a day ago
While there is some truth to your comment, it has no practical engineering relevance. Since energy transfer rate is proportional to temp difference, therefore you compute the flow rate required, which is going to be different if the chips are in series or in parallel.
Dylan16807 · 3 hours ago
If you're heating up the water by 10 or so degrees on typical computer hardware, I bet you're not bottlenecked by energy transfer. Your flow rate is based on how hot you want the water to get, so series or parallel goes back to not mattering.
Dylan16807 commented on The Limits of NTP Accuracy on Linux   scottstuff.net/posts/2025... · Posted by u/signa11
wowczarek · 16 hours ago
The problem with these types of posts is that this is an area that many are unfamiliar with (at least not in depth) and making lots of authoritative statements makes it believable at face value. There are so many variables to network time sync that you design to minimise them. For example no multipath and no asymmetry unless you have PTP P2P transparent clocks everywhere.

The author also mixes precision with accuracy and relies on self-reported figures from NTP (chrony says xxx ns jitter). With every media speed change you get asymmetry which affects accuracy (not always precision though). So your 100m->1G link for example will already introduce over 1 us of error (to accuracy!), but NTP will never show you this and nothing will unless you measure both ends with 1PPS, and the only way around it is PTP BC or TC. There is a very long list of similar clarifications that can be made. For example nothing is mentioned about message rates / intervals, which are crucial for improving the numbers of samples filters work with - and the fact that ptp4l and especially phc2sys aren't great with filtering. Finally getting time into the OS clock, unless you use PCIE PTM which practically limits you to newer Intel CPUs and newer Intel NICs, relies on a PCIE transaction with unknown delays and asymmetries, and without PTM (excluding few NICs) your OS clock is nearly always 500+ ns away from the PHC and you don't know by how much and you can't measure it. It's just a complex topic and requires an end to end, leave no stone unturned, semi-scientific approach to really present things correctly.

Dylan16807 · 12 hours ago
It's not that the author is mixing accuracy and precision, it's that they only care about precision.

Any asymmetry that is consistent is irrelevant.

Dylan16807 commented on The Limits of NTP Accuracy on Linux   scottstuff.net/posts/2025... · Posted by u/signa11
ainiriand · 19 hours ago
If those times are produced on different architectures, then yes, the comparison can never be accurate enough since the underlying measurement mechanisms differ fundamentally. While the author goes to great lengths to demonstrate very small time differences, I believe the foundation of their comparison is already flawed from the start. I do not want to generate any polemic sorry!
Dylan16807 · 12 hours ago
But you do or don't think chrony knows how to do the memory barriers and everything else properly?

Making the sync work across existing heterogenous hardware is the goal of the exercise. That can't be a disqualifier.

Dylan16807 commented on The Limits of NTP Accuracy on Linux   scottstuff.net/posts/2025... · Posted by u/signa11
ainiriand · 19 hours ago
He uses Chrony, which uses system time, and compares those times across different machines. Unless proper setup is done the benchmark is faulty.
Dylan16807 · 19 hours ago
Chrony is what's comparing the times. Zero code written by the author is running except to log the statistics chrony created. Are you accusing chrony of failing at one of its core purposes, comparing clocks between computers? What could the author do differently, assuming the author isn't expected to alter chrony's code?
Dylan16807 commented on The Limits of NTP Accuracy on Linux   scottstuff.net/posts/2025... · Posted by u/signa11
ainiriand · a day ago
In my opinion when you want such precision, you need to stablish strict constraints to the measurements, for example memory fences: https://www.kernel.org/doc/Documentation/memory-barriers.txt

If you do not do this, the times will never be consistent.

The author produced a faulty benchmark.

Dylan16807 · 20 hours ago
What benchmark? The only numbers he's measuring himself are on the oscilloscope. Everything else is being measured by chrony. Unless you're talking about a different post on the blog?
Dylan16807 commented on Standard Thermal: Energy Storage 500x Cheaper Than Batteries   austinvernon.site/blog/st... · Posted by u/pfdietz
Veedrac · a day ago
I'd assume the design as proposed isn't overbuilt, so we'd need to go from, say, 4 months cycle times to 8 hour cycle times, which is maybe 350x.

While that's not going to increase the cost by 350x directly, it is going to change the character of the pile from a bunch of dirt to a bunch of dirty pipes. This makes a lot of the simplifying assumptions no longer work; like you can no longer ignore the heat losses through the rods, or the lower thermal mass of the rods.

And to be clear, you can do this. There are faster-cycling thermal storage solutions out there. It's just not implied from the claim that these solutions would be so much better than batteries.

Dylan16807 · 21 hours ago
The heat right next to the rods is easier to access. With less dirt per rod, you can also get more watts per rod, so the number of rods doesn't need to scale directly with the cycle time.
Dylan16807 commented on Ban me at the IP level if you don't like me   boston.conman.org/2025/08... · Posted by u/classichasclass
closewith · a day ago
> Visiting the website" is the method. It's nonsense to say that visiting from a different location is a different method.

This is a naive view of the internet that does not stand the test of legislative reality. It's perfectly reasonable (and in our case was only path to compliance) to limit access to certain geographic locations.

> I don't care if you won those disputes, you did a bad thing and screwed over your customers.

In our case, our customers were trying to commit friendly fraud by requesting a chargeback because they didn't like a geoblock, which is also what the GP was suggesting.

Using chargebacks this way is nearly unique to the US and thankfully EU banks will deny such frivolous claims.

Dylan16807 · 21 hours ago
The ancestor post was about being unable to get support for a product, so I thought you were talking about the same situation. Refusal to support is a legitimate grievance.

Are you saying they tried a chargeback just because they were annoyed at being unable to reach your website? Something doesn't add up here, or am I giving those customers too much credit?

Were you selling them an ongoing website-based service? Then the fair thing would usually be a prorated refund when they change country. A chargeback is bad but keeping all their money while only doing half your job is also bad.

Dylan16807 commented on What are OKLCH colors?   jakub.kr/components/oklch... · Posted by u/tontonius
itishappy · a day ago
> Someone asking for those colors doesn't actually want a gradient with two anchor points.

I thought the same until I googled "blue and orange tie-dye." I'll be honest, more white and black than I expected!

> So yes there are many answers but because it's not a quintessential example of a gradient.

We may have to agree to disagree that tie-dye isn't a quintessential example of a gradient. Would you argue that rainbows aren't either?

Dylan16807 · a day ago
> I thought the same until I googled "blue and orange tie-dye." I'll be honest, more white and black than I expected!

Putting white or black in between adds another anchor point.

And looking more around examples of blue and orange tie dye, most aren't really gradients overall, they have big splotches of solid color with small gaps or overlaps in between, and at least half the time the gaps and overlaps don't even have a gradient inside them.

> We may have to agree to disagree that tie-dye isn't a quintessential example of a gradient. Would you argue that rainbows aren't either?

Hmm. How about this. I would say a rainbow is not a gradient between two colors, and the color space discussion is about a gradient between two colors. The exact border of "quintessential" is not something I really want to spend too much time on.

u/Dylan16807

KarmaCake day34561February 4, 2010View Original