Hacker Newsnew | past | comments | ask | show | jobs | submit | compiler-guy's commentslogin

It's a highly specialized use-case where every little detail of the timing and hardware is important. So that, for example, games run exactly right.

For folks without this particular use case, other emulation solutions are probably better.


That’s not what the idiom “don’t do x for fun” is about.

The expression means that X is the best of unpalatable options to accomplish something else, where X is taken in a literal and narrow sense.

People don’t fly with babies for fun. They do it because visiting grandparents is fun, and driving isn’t a good option. Or, if it involves a trip across the ocean, the alternative would be sailing.


Well that’s idiotic. Approximately nobody “flies for fun” under that tortured definition.

It’s a common idiom. And idioms are often weird. But that is exactly the point.

> Approximately nobody “flies for fun” under that tortured definition.

Yes. That is exactly how it’s supposed to be used. The vast majority of people do not enjoy the airport/airline experience and were there any other reasonable way to get where they are going they would probably take it. They are not doing it because it is fun, they are doing it because they have to.


The VP also needs to know if the fix will require some sort of resource reallocation, or if the timeline is long so they can deal with the other stakeholders, or whatever. These are all forward looking things that the details influence but the details aren't what matter.

I agree with the 2023 decode there, but there is still a bit of a puzzle:

If someone knew to replace the battery just three years ago, I would expect they also would have enough knowledge to set the clock itself. Or at least explain what was going on. Maybe this person isn't connected with the building anymore. But I would expect the new owners would be able to contact the old owners for help on this instead of sending a generalized call for help.


According to [1] Yuasa battery date codes are year-month-day-plant/shift so 090323J0 indicates a battery from 2009.

The building also was "out of operational use by Police Scotland for almost 10 years" and was purchased for community ownership earlier this year, according to [2]

> If someone knew to replace the battery just three years ago, I would expect they also would have enough knowledge to set the clock itself.

From the pictures, it looks like this clock needs to be manually changed on the last Sundays of March and October, for the start and end of daylight savings (they also need to be re-set any time there's a long power outage).

This article is dated early April; it's possible the new community owners of the building (and clock) just needed someone to adjust it by an hour.

The motor in the photo is probably a synchronous AC motor, where the rotation of the shaft matches the exact frequency of the AC supply. Then a long series of gears converts 50 rotations per second to 1 rotation per hour. Which avoids gradual clock drift - but without the fancy digital control needed to automate the daylight savings adjustments.

Nowerdays, you can buy 'clock controllers' [3] that take care of daylight savings time etc automatically.

[1] https://www.hardwarexpress.co.uk/pages/yuasa-date-codes [2] https://www.edinburghnews.scotsman.com/news/edinburgh-plans-... [3] https://www.hawkinsclocks.co.uk/clock-controllers


There are lots of random web sites claiming how to read the Yuasa date code format, but the only official document I found from Yuasa says "contact us for help decoding the date". Here's a photo of the exact same battery on Amazon with a date code of "291118H0". That must be DDMMYY unless the battery was sent to Amazon from the future (or the photo is forged):

https://www.amazon.co.uk/Yucel-Y1-2-6-Sealed-Rechargeable-Ba...

And I just found this EU Declaration of Conformity which includes the Y1.2-6 and says the date code is DDMMYY:

https://www.farnell.com/datasheets/4633451.pdf


I would GUESS that someone tried figuring it out in 2023 and replaced the battery as troubleshooting. If it were me, I'd probably do the same then stop when I hit a wall so I didn't damage it further. I don't wanna be the guy who damages a 100+ year old public clock

I could just hear the clockmaker James Martin calling me a butcher in his disapproving manner


Because that's the way courts work. This court only had jurisdiction over Germany. It is possible that other courts with broader jurisdiction would rule similarly, but someone has to bring the case.

It’s hard to imagine a company more all in on ai than Google. The pressure to use it is intense and they are throwing ai at basically every problem. If a proposal doesn’t have ai in the title somewhere it has no chance of funding.

I don’t really think it has made Google products better, but it is absolutely the expectation.


To me, it's easy to imagine them going more all in. For example, they could let their employees use ChatGPT and Claude!

They love to say "AI" but they don't seem to want to accept the reality of what AI is right now.


I do want (some, carefully curated as to certain usecases) AI. But I don't want to waste my diskspace for this AI.

Being short on disk space is a pretty good reason to not upgrade.

I would rather keep my personal picture library on my local disk (with backups, of course) than gigabytes and gigabytes of Apple models.

They were the ones who thought that 256Gb was a reasonable number. And it actually did work pretty well, until they wanted to fill it with models.


The linux kernel didn't even gain SMP until 1996. Solaris was running circles around it both before and after that point. Solaris was vastly more mature and stable.

Of course, after that, Solaris just kept running in very expensive circles while linux went on to make steady progress.


And if nothing happens after 1996 then Linux would not have been better than Solaris.

This is obviously not an attempt at anything remotely resembling documentary history. It’s more of a just so story explaining what problem each step solved.

Unless of course one thinks that smooth gray stones from a riverbed two miles away reflects some historically significant point in money’s evolution.


I'm not going to explain David Graeber's Debt to you, but yes, this exact 18th century fantasy of the emergence of money in caveman times contains the same kind of misunderstandings that also leads to most people having an incredibly misguided view of how the contemporary global financial system operates.

I certainly don't think anything like this actually happened. And the linked article doesn't really do so either. I do think it can be a useful illustration of what problem each technology solves.

In another thread you talk about how the internet really is a series of tubes. We all know that "tubes" can be a useful analogy for understanding certain things about circuits and things built upon them. But we also don't think that tubes are more than a very basic analogy. Tubes don't really do packet switching.


By leading with the improvement-order-barter story, the article announces a bias that borders on propaganda. It's maybe worth objecting to even if the goal isn't to be historically accurate.

The problem that was actually being solved when money was invented was how to get recently conquered villagers to support the soldiers that recently conquered them. (Demand taxes in the coinage that you pay your solders with, then they can live off the local economy and you don't have to feed them directly, which might be hard if they're very far away--tax collectors can take years to show up, but the demand for the new currency is instant, so your soldiers get fed right away).

The system of interpersonal debt that predated money likely outperformed money in a variety of ways from the perspective of the users. It was only for the conquerors that the invention of money solved any problem at all. It's hard to keep reading the article when it starts with the story that is used to distract from this.


There's a central problem, a blind spot, that plagues economics: because the fundamental credo of the discipline is that it's all about free people engaing in mutually beneficial trade to maximize their respective well-being, it completely neglects how important armed force and violence are in shaping the economic system we know.

Agreed. We should acknowledge that it has historically been about ensuring that conquerer grandpa and conquered grandpa end up with different qualities of life even after they're too old to swing a sword. I.e. extending violence begotten structure into places where violence is impractical.

The problem is the story is wrong, and that leads to misunderstandings of what money is and how economic institutions arose in fact vs mythology.

For starters, debt records came before money basically everywhere we have evidence for the invention of money.

i would very strongly suggest reading David Graeber. It completely revolutionized my understanding of how human social and economic institutions emerge and evolve in actual fact vs imagined myth.

We can just tell the real story, it's far more interesting and useful than the myth.


You are arguing a point I didn’t make.

No, what I and the other commenter are saying is you don't understand why the article is misleading because you don't know the actual scholarly knowledge here.

In your other comment you use wording along the lines of "still useful to show what problem each technology solved" but the part you're missing is the explanations are largely wrong, not just in the sense of not telling actual history but you will come alway with mistaken conclusions because the imagined/example history is fundamentally wrong.

So, consider if you're getting this from multiple people, perhaps you're missing something on the topic.


There are two commenting critics. So "multiple" is true, I suppose, but only quite weakly so. And there are more than 4x that many upvotes on the top-level comment. So I don't think it is as simple as "everyone is saying you are wrong."

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

Search: