Hacker Newsnew | past | comments | ask | show | jobs | submit | Telemakhos's commentslogin

In 2023, 55% of visits to NYT's website were to games, not news. The puzzle-only subscription points to the NYT's fate as a game company that also offers news, much as airlines are credit card/loyalty point companies that also offer flights.

So my hunches were correct (majority of people were subbing to play the games), but not my conclusion: that they wouldn't split it off.

I've always thought that Will Shortz was one of the most powerful people at the NYT (slightly joking, but sorta not).


The WD in WD-40 stands for "water displacer." It makes water go somewhere else. Secondarily, it is a solvent, and it's great for dissolving glues, like the glue used to affix government-issued tax licenses to automobiles. It's not really a lubricant, but in a pinch it can temporarily function as one.

I like Swiss army knives, but they collect lint and gunk from my pockets. I use WD-40 to dissolve gunk, and to drive out water after an ultrasonic bath, but I lubricate with the light machine oil used for barber's clippers.


It is a blend of oils. Light oils evaporate (like kerosene does for example), and dissolve thicker oils and grease. Oils displace water in general and once in the surface pores they prevent water from getting in there again, a mixture containing light oils flows in easier and does that better. Being predominantly a light oil it is a poor lubricant, but it is better than nothing, and can flow in crevices where thicker stuff would not.

It is really simple and there is no magic.

The name took off as a brand and completely different stuff from the 40th iteration of a Water Displacer formulation is being sold under it as well.


> It's not really a lubricant, but in a pinch it can temporarily function as one.

That's wrong. WD-40 is a literally a lubricant mixed with a solvent that makes it very fluid so it can enter small interstices, the solvent then evaporates quickly, leaving the lubricant in place.

There's not a lot of lubricant in there compared to a pure lubricant, because the solvent takes a significant share of the volume, but it's still a lubricant once the solvent dries up.


You're technically correct, the best kind of correct.

However, if you're looking to lubricate something and have it last for a reasonable time, then WD-40 is a poor choice. However, using WD-40 first to hopefully dissolve contaminants/rust and remove water and then after a quick wipe to remove excess, applying something better such as 3-in-1 or silicone grease etc is a good idea.

The clue is in the name - Water Displacement 40.

If you want a spray on penetrating lubricant, then GT-85 is usually better as it has PTFE included to better lubricate. It still won't last that long though as it'll only make a thin film.

Edit: I've just seen that WD-40 make mention of a bus driver in Asia using WD-40 to remove a python from his bus' under-carriage. If in doubt, spray it with WD-40.


wd40 is not a lubricant.

It literally says it is a lubricant on the can but you can’t find a thread on the Internet about it without someone saying that. It is a lubricant, just not a very good one for most situations.

I can't believe you're being downvoted for that comment, that's legit insanity.

I’m not surprised. If your hobbies include things that take you to the DIY corners of Reddit you are exposed daily to the “WD-40 is not a lubricant” morons who cannot be swayed by either reading the can or Googling.

“WD-40 is not a very good lubricant and you should almost always use something else” is a mouthful I guess, but their denial of reality over something so meaningless is always astounding to me.


Social media systemically rewards "Um actually" behavior and punishes nuance and discussion.

This is the expected outcome.


There is a certain type that loves to be contrarian, and they keep a whole mental library of "unintuitive factoids" at the ready for the topic to arise.

The unexpected part though, is that I don’t think this is causing people to actually believe that WD-40 is not a lubricant. It’s causing them to post that perhaps.

And it seems like such a strange thing to become emotionally attached to. But these people will sooner die then admit the thing that says it is a lubricant is a lubricant.


>is that I don’t think this is causing people to actually believe that WD-40 is not a lubricant.

Why do you believe this? The vast majority of people commenting on the internet haven't used WD-40 in the past year. Why wouldn't they end up believing a wrong thing that has been confidently stated that they otherwise know nothing about?

People have always loved these factoids, long long before the internet. It was common conversation fodder for upper class folks in history to repeat outright falsehoods as "um actually"s or "You should know"s.

https://en.wikipedia.org/wiki/List_of_common_misconceptions_...

Do you know how many people for whatever reason believe that Columbus believed the earth was round and everyone else thought it was flat, despite all historical evidence being contrary?

Basically "Common consensus is X but I'm super smart and know REAL truth Y" is like the optimal meme shape for the human brain. The biases in our brain will always support such an argument shape, and humans get a reward for relaying that info, correct or not. All our innate and fundamental physiological biases will be triggered by this kind of statement.

IMO the super interesting aspect is the second and third generations of "Um actually" where a previous "um actually" gets further "um actually!"d, and even that gets "um actuallyyyyy"d. I wonder if we will get a cycle at some point!


How can you see downvotes?

One (not recommended) way to test this statement is to spray some on the kitchen floor and see what happens later.

that's fine, but because it is sometimes slippery does not make it a lubricant.

Fine, put up or shut up. Post some proof.(About WD-40, not slippery things.)

Some things are lubricants for a little while, until they suddenly become the opposite. Wood glue, for example.

That’s how I would describe the original and most common WD-40 formula: a passable short-term lubricant for quick and dirty jobs, but not a long-term high quality lubricant, like, say, 3-in-1 (graphite) or silicone lubricants.

Adding to the confusion is that WD-40 sells a silicone lubricant that is a much better lubricant for many purposes than the original formula.


Repeating bullshit many times doesn't make it true.

It is a mixture of a lubricant and a solvent. And once the solvent evaporates, only the lubricant remains.


I remember playing Doom on a single-core 25MHz 486 laptop. It was, at the time, an amazing machine, hundreds of times more powerful than the flight computer that ran the Apollo space capsule, and now it is outclassed by an earbud.

Can we finally end this Apollo computer comparison forever? It was a real time computer NOT designed for speed but real time operations.1

Why don't you compare it to let's say pdp11, vax780/11 or Cray 1 supercomputer?

NASA used a lot of supercomputers here on earth pior to mission start.


> It was a real time computer NOT designed for speed but real time operations.

More than anything, it was designed to be small and use little power.

But these little ARM Cortex M4F that we're comparing to are also designed for embedded, possibly hard-real-time operations. And dominant factors in experience on playback through earbuds are response time and jitter.

If the AGC could get a capsule to the moon doing hard real-time tasks (and spilling low priority tasks as necessary), a single STM32F405 with a Cortex M4F could do it better.

Actually, my team is going to fly a STM32F030 for minimal power management tasks-- but still hard real-time-- on a small satellite. Cortex-M0. It fits in 25 milliwatts vs 55W. We're clocked slow, but still exceed the throughput of the AGC by ~200-300x. Funnily enough, the amount of RAM is about the same as the AGC :D It's 70 cents in quantity, but we have to pay three whole dollars at quantity 1.

> NASA used a lot of supercomputers here on earth pior to mission start.

Fine, let's compare to the CDC 6600, the fastest computer of the late 60's. M4F @ 300MHz is a couple hundred single precision megaflops; CDC6600 was like 3 not-quite-double-precision megaflops. The hacky "double single precision" techniques have comparable precision-- figure that is probably about 10x slower on average, so each M4F could do about 20 CDC-6600 equivalent megaflops or is roughly 5-10x faster. The amount of RAM is about the same on this earbud.

His 486-25 -- if a DX model with the FPU -- was probably roughly twice as fast as the 6600 and probably had 4x the RAM, and used 2 orders of magnitude less power and massed 3 orders of magnitude less.

Control flow, integer math, etc, being much faster than that.

Just a few more pennies gets you a microcontroller with a double precision FPU, like a Cortex-M7F with the FPv4-SP-D16, which at 300MHz is good for maybe 60 double precision megaflops-- compared to the 6600, 20x faster and more precision.


I have thought about this a little more, and looked into things. Since NASA used the 360/91, and had a lot of 360's and 7900's... all of NASA's 60's computing couldn't quite fit into a single 486DX-25. You'd be more like 486DX2-100 era to replace everything comfortably, and you'd want a lot of RAM-- like 16MB.

It looks like NASA had 5 360/75's plus a 360/91 by the end, plus a few other computers.

The biggest 360/75's (I don't know that NASA had the highest spec model for all 5) were probably roughly 1/10th of a 486-100 plus 1 megabyte of RAM. The 360/91 that they had at the end was maybe 1/3rd of a 486-100 plus up to 6 megabytes of RAM.

Those computers alone would be about 85% of a 486-100. Everything else was comparatively small. And, of course, you need to include the benefits from getting results on individual jobs much faster, even if sustained max throughput is about the same. So all of NASA, by the late 60's, probably fits into one relatively large 486DX4-100.

Incidentally, one random bit of my family lore; my dad was an IBM man and knew a lot about 360's and OS/360. He received a call one evening from NASA during Apollo 13 asking for advice about how they could get a little bit more out of their machines. My mom was miffed about dinner being interrupted until she understood why :D


What's your project/ cubesat name?

Ps. Try msp430 f model for low power. These can be CRAZY efficient.

Ps. Don't forget to short circuit the solar panel directly to system: then your satellite might talk even 50 years from now such as some HAM satellites from cold war (Oscar 7 I think)


> What's your project/ cubesat name?

NyanSat; I'm PI and mentor for a team of high school students that were selected by NASA CSLI.

> Ps. Try msp430 f model for low power. These can be CRAZY efficient.

Yah, I've used MSP430 in space. STM32F0 fits what we're using it for. The main flight computer we designed, and it's RP2350 with MRAM. Some of the avionics details are here: https://github.com/OakwoodEngineering/ObiWanKomputer

> Ps. Don't forget to short circuit the solar panel directly to system: then your satellite might talk even 50 years from now such as some HAM satellites from cold war (Oscar 7 I think)

Current ITU guidelines make it clear this is something we're not supposed to do to ensure that we can actually end transmissions by the satellite. We'll re-enter/burn up within


And perhaps more fittingly, that PC couldn't decode and play an MP3 in real time.

And by an order of magnitude or more, too!

I see the opposite effect with AI: I quickly find some error that it has made, because it always makes errors in my field, and that keeps me from disengaging with the problem, because it helps define what can be wrong. I mainly use AI like I used to use my blog, for writing out my ideas in prose that I think is comprehensible and organized. Neither AI nor my old blog ever solved a problem for me, but they help me figure out how to talk about problems. I'll solve them on my own, but being able to describe a problem well is an important step in that.

I think that's still in line with what I mean. Letting the AI solve the problem doesn't work, but I've had several times that simply trying to explain the problem to the AI helped me solve it. Sometimes it's not an interactive encyclopedia, but an interactive rubber duck. That works too.

Don't outsource the thinking to the AI, is what I mean. Don't trust it, but use it to talk to, to shape your thoughts, and to provide information and even ideas. But not the solution, because that has never worked for me for any non-trivial problem.



On the other side of the fence, I enjoy the new Spotlight-for-Applications that opens when I hit the touch bar key (I still have an M1) for the old Launchpad. It seems to sort programs by frequency, so it knows that I open Ghostty far more often than Ghostery, and typing "Gh" will bring me to Ghostty instead of Ghostery. In the old Launchpad, applications were always presented alphabetically when you began typing, so Ghostery always was selected instead of Ghostty. I had to type "gh" right key enter before, but now just I just hit "gh" enter.

From what I gather, corruption in this case means that civil servants of the Garante per la Protezione dei Dati Personali got business class travel when they should have flown economy class because the trip was under five hours (the established cut-off for upgrading to business class), and that they stayed in hotels that were better than the ones authorized for civil servants. There's also something about the head of the Garante changing the terms of his lease in Rome on an apartment that is directly adjacent to an AirB&B owned by his daughter, but my financial Italian's not up to understanding the full details. I think this is less the "point out Grok's deepfake" kind of corruption and more the "some civil servants think they're entitled to live better on the taxpayer's dime than other civil servants do."

Sounds like Baltimore

When it became cheaper to publish text, for example with the invention of the printing press, the quality of what the average person had in his possession went up: you went from very few having hand-copied texts to Erasmus describing himself running into some border guard reading one of his books (in Latin). The absolute quality of texts published might have decreased a bit, but the quality per capita of what individuals owned went up.

When it became cheaper to mass produce sneakers, tshirts, and anything, the quality of the individual product probably did go down, but more people around the world were able to afford the product, which raised the standard of living for people in the aggregate. Now, if these products were absolute trash, life wouldn't make much sense, but there's a friction point in there between high quality and trash, where things are acceptable and affordable to the many. Making things cheaper isn't a net negative for human progress: hitting that friction point of acceptable affordability helps spread progress more democratically and raise the standard of living.

The question at hand is whether AI can more affordably produce acceptable technical writing, or if it's trash. My own experiences with AI make me think that it won't produce acceptable results, because you never know when AI is lying: catching those errors requires someone who might as well just write the documentation. But, if it could produce truthful technical writing affordably, that would not be a bad thing for humanity.


When it became cheaper to publish text, for example with the invention of the printing press, the quality of what the average person had in his possession went up: you went from very few having hand-copied texts to Erasmus describing himself running into some border guard reading one of his books (in Latin). The absolute quality of texts published might have decreased a bit, but the quality per capita of what individuals owned went up.

Today the situation is very different and I'm not quite sure why you compare a time in history where the average person was illiterate and (printed) books were limited to a very small audience who could afford them, with the current era where everybody is exposed to the written word all the time and is even dependent on it, in many cases even dependent on it's accuracy (think public services). The quality of AI writing in some cases is so subpar, it resembles word salad. Example goodreads: the blurb of this book https://www.goodreads.com/book/show/237615295-of-venom-and-v... was so surreal I wrote to the author to correct it (see in comments to the authors own review). It's better now, but it still has mistakes. This is in no way comparable with the pasts goes down a bit this is destroying trust even more than everything else, because it this gets to be the norm for official documents people are going to be hurt.


You know what else would suffice plenty? Physical keys and mechanical locks. They worked (and still work) without electricity. The tech is mature and well-understood.

The reason for moving away from physical keys is that key management becomes a nightmare; you can't "revoke" a key without changing all the locks which is an expensive operation and requires distributing new keys to everyone else. Electronic access control solves that.

You might find Matt Blaze's paper on vulnerabilities in master-keyed physical locks interesting:

https://eprint.iacr.org/2002/160.pdf


Something similar happened to the macOS chess game, which has always been bundled with OSX/macOS. Once upon a time it was easy to beat in easy mode, which restricted how long it could thing in advance.

When Big Sur rolled out around 2020, Apple introduced a bug which disabled the difficulty slider: no matter what it was set to, it was hard or impossible to beat. In macOS Sequoia, the Chess app got updated again, and supposedly they fixed the difficulty slider, but in the interval silicon improved so much that the old restraints (like think for only a second) mean little. The lowest levels play like a grand master.


is there some reason to implement it as a time limit instead of iterations or something else deterministic? it being affected by CPU speed or machine load seems obvious.

or whatever makes sense if “iterations” isn’t a thing, I know nothing about chess algorithms


It’s simpler. Chess is a search through the space of possible moves, looking for a move that’s estimated to be better than the best move you’ve seen so far.

The search is by depth of further moves, and “better” is a function of heuristics (explicit or learned) on the resulting board positions, because most of the time you can’t be sure a move will inevitably result in a win or a loss.

So any particular move evaluation might take more or less time before the algorithm gives up on it—or chooses it as the new winner. To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.


> To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.

The simple thing to do is give it a limit on the total number of states it can explore in its search.

If your goal is consistency, wall-clock time makes no sense. If I run 'make -j20', should the chess computer become vastly easier because the CPU is being used to compile, not search? Should 'nice -n 20 <chess app pid>' make the chess computer worse?

Should my computer thermal-throttling because it's a hot day make the chess computer worse, so chess is harder in winter?

If the goal is consistency, then wall-clock isn't the simple way to do it.


>If the goal is consistency, then wall-clock isn't the simple way to do it.

It’s simpler than doing a limit on number of states, and for some applications consistency isn’t super important.

Doing a time limit also enforces bot moving in a reasonable time. It puts a nice limit to set up a compromise between speed and difficulty.

Doing state limit with a time limit might be better way to do it, but is harder.


> It’s simpler than doing a limit on number of states

According to who?

A counter that you ++ each move sounds a lot easier to me than throwing off a separate thread/callback to handle a timer.

> Doing a time limit also enforces bot moving in a reasonable time.

It's designed for specific hardware, and will never have to run on anything significantly slower, but might have to run on things significantly faster. It doesn't need a time cutoff that would only matter in weird circumstances and make it do a weirdly bad move. It needs to be ready for the future.

> It puts a nice limit to set up a compromise between speed and difficulty.

Both methods have that compromise, but using time is way more volatile.


A time limit is also deterministic in some sense. Level settings used to be mainly time based, because computers at lower settings were no serious competition to decent players, but you don't necessarily want to wait for 30 seconds each move, so there were more casual and more serious levels.

Limiting the search depth is much more deterministic. At lower levels, it has hilarious results, and is pretty good at emulating beginning players (who know the rules, but have a limited skill of calculating moves ahead).

One problem with fixed search depth is that I think most good engines prefer to use dynamic search depth (where they sense that some positions need to be searched a bit deeper to reach a quiescent point), so they will be handicapped with a fix depth.


> One problem with fixed search depth is that I think most good engines prefer to use dynamic search depth (where they sense that some positions need to be searched a bit deeper to reach a quiescent point), so they will be handicapped with a fix depth.

Okay, but I want to point out nobody was suggesting a depth limit.

For a time-limited algorithm to work properly, it has to have some kind of sensible ordering of how it evaluates moves, looking deeper as time passes in a dynamic way.

Switch to an iteration limit, and the algorithm will still have those features.


Heh, I was just discussing this some minutes ago: https://news.ycombinator.com/item?id=46595777


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: