This story reminded me of the "BeBox" [0] PowerPC computer from the 1990's, which had Blinkenlights on its front bezel.

(It ran the very cool "BeOS" operating system[1], which was eventually ported to Mac, then x86.)

[0] https://en.wikipedia.org/wiki/BeBox

[1] https://en.wikipedia.org/wiki/BeOS

And a FOSS re-implementation of which is still alive and in active development. The project recently released beta 5 -- it's very nearly ready for version 1.0 and now runs GNOME Epiphany, Firefox, LibreOffice and more.

https://www.theregister.com/2025/01/09/testing_haiku_beta_5/

The BeBox is my holy grail of retrocomputing! Had to settle for a partition on my x86 machine. Loved BeOS back in the day.

That you felt the need to explain these makes me feel really, really old. (And you did need to explain it; it's practically Elder Lore at this point.)

It's like explaining to young people that we used to have to pay per message for SMS, or that only one person could be on the Internet at a time at your house.

Now if you'll excuse me, I see some suspicious looking clouds I need to go yell at.

As a C programmer, declarations in Go appeared "backwards" to me when I first saw them.

IMO the Go syntax is a vast improvement as it's much simpler and avoids the clockwise/spiral issue: https://appliedgo.com/blog/go-declaration-syntax

It's worth to remember that C "happened" to stick around because of UNIX, but it's been just another iteration of what started as BCPL; with Go coming from the same people who made Plan 9 (the spiritual successor to Research UNIX) and Alef/Limbo. These guys are equally interested in pushing both PL/OS research and practice.

(I also have no doubt that just like Go fixed C's type declarations, in another 20-30 years, Go's successor will finally fix error handling.)

hence why every recent programming languages are type after name (go included).

I think a proper type system that doesn't special-cases arrays are better, e.g. Array<String>. Pointers may also be part of this uniform structure, e.g. Array<Ref<String>>, and there is zero question on how to parse it even if you are not familiar.

that's the beauty of type after name, it's all left to right, even in special-cases of array, references, and the most confusing-contributor to cdecl: functions `func(int)[5]*string`: perfectly clear, just read left to right.

What about a Map<int, String>?

You can't really encode a tree structure with only linear semantics (without at least something like s-expressions).

And type declarations are s-exprs.

The advantage of type after name is that it keeps the traversing order consistently pre-order (node, left, right), instead of either:

- the notoriously ridiculous spiral cdecl: reading stuff right (output), node (func name) and left (input)

- create a new name to describe the function in pre-order: Func<Input, Output>

But you can't know how many parameters do a user-defined "node" have. I don't see how it can work for generic data structures without a specific syntax for "the children of this node". Go also uses [] for generics, doesn't it?

At that point I find a uniform system (without special-casing arrays and pointers - they are also just types) would be simpler.

I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.

even better, they should have it above or below!

or, declare the type separately, like in fortran or haskell (or in fact, pre-C99 c)

declare the type separately didn't solve the of hard-to-read cdecl problem.

true; but at the same time, any sufficiently complex type is begging to be type-aliased into something more legible/sensible in the first place ... and this is also true for "right-typed" systems.

I've seen julia types unnecessarily fill a whole terminal for otherwise simple operations before, and I have to say I wasn't too impressed...

> America/Nuuk does daylight savings at -01:00 (yes, with a negative)

Somewhat related: Europe/Dublin has a negative DST offset. Irish DST runs through the European winter (i.e. the opposite of the other European timezones).

(More details here: https://github.com/golang/go/issues/56743#issuecomment-13157... )

Edit: To be clear: the quote is referring to a negative DST start, rather than a negative DST offset.

In the github repo the article links, there is a large number of comments about the Europe/Dublin time zone in the europe file, including one quote from Ulysses: https://github.com/eggert/tz/blob/7748036bace8562b9c047f368c...

I think you misread that. America/Nuuk doesn't have reverse DST (which is easily solved by just switching DST and non-DST around). It starts DST at a negative offset because the offset is defined as relative to the previous day.

Yes, this is indeed a different situation and my comment doesn't make that clear. Thank for pointing that out. I've made an edit.

The music at many concerts and nightclubs is unfortunately loud enough to cause permanent hearing loss.

Ear plugs reduce the volume to a level where you can still hear the music, but the risk of long term damage is reduced. (You can get "musician's ear plugs" which attenuate all frequencies equally, so they don't make the music sound weird.)

Right. I didn't consider this as a possible option. It seems odd, but makes a lot of sense if you work at some place loud.

But not over a cable.

Submarine cables are clearly marked on nautical charts, and even recreational boaters know not to anchor in those areas.

A professional trawler captain is not going to accidentally trawl over such an area.

There's a big difference in seriousness between being able to show whether they were likely doing something they shouldn't be doing for the sake of making more money on the fishing, vs. if they were doing what they were doing with the intent of causing damage, though. But of course, that difficulty is also exactly why it'd also be a great way for an adversary to damage your cables.

means motive opportunity -- 3 for 3

given the use cases re: satellites on the island, and the continuing cold-yet-increasing tensions with Russia, it's absolutely reasonable to make that assumption

maybe they'll try to blame this on Ukraine like they tried with the undersea pipelines that got blown up, too

It's reasonable to assume. But it's wildly insufficient for either a prosecution or diplomatic consequences, especially given that all 3 also would apply to a trawler just intent on profiting from trawling.

I agree the odds are reasonably high Russia arranged this on purpose. And that's fine for the purposes of a discussion that doesn't have consequences, but not for much more.

Fishers are infamous for flaunting the rules though. I think we can only judge this if we see records of other ships in the area.

You can, at least at that specific time that all other boats were not trawling over cables.

Fees such as trading costs are a percentage of trading volume.

Therefore, the more money you are managing, the higher your trading costs. (i.e those costs are "fixed" but its a "fixed percentage" rather than a static number.)

I highly doubt trading costs are part of the 2% management fee.

What else would they be part of? It's an operational cost.

In my experience they absolutely are part of the 2% fee. Why do you think they aren’t?

In that case, how can the rate be fixed or does that mean that the hedge fund limits its trade turn-over. In other words, if your trading fees are 0.2% and your trading volume is 10 times the capital raised, you already burned through your management fee.

That’s why they are fixed percentage not fixed. Trading fees go up with the amount of capital moved but mostly in a linear fashion.

Calculating your trading costs (and usually more importantly slippage) is absolutely table stakes for a fund that trades.

For most funds that’s relatively easy as the trading component is a cost center that you can outsource for predictable prices.

For funds that aren’t treating trades as cost centers, well it’s presumably part of what you are selling so you better be good at it.

Endlessh periodically sends data so the read timeout won't trigger. Specifically, it draws out the crypto negotiation stage indefinitely by exploiting a feature of the SSH protocol.

(Of course, the bot author could detect that behaviour too.)

There's more info from the author of Endlessh: https://nullprogram.com/blog/2019/03/22/

For those wondering how they transfer the generated energy from the tidal kite to the shore:

> The turbine shaft turns the [onboard] generator which outputs electricity to the grid via a power cable in the tether and a seabed umbilical to the shore.

Thank you for taking the time to write such a clear and succinct readme.

I really liked the layout:

  - Why
  - How Lockbox helps
  - Main benefits
  - Drawbacks
  - How to run
  - Design philosophy

I wish more projects would follow this format :)

Out of interest, what did you use all that compute for?

ETH PoW. When ETH switched to PoS, we shut it all down. It sure was fun while it lasted, not many people on the planet have run that much compute.

I did a lot of unique optimizations to autotune each individual GPU for performance by tweaking the software knobs on them. They are all snowflakes. Same model, different batches (heck, even same batch!), can produce wildly different performance results.

Over the years, I did try to find some alternative workloads for it, but nothing could even pay for the power costs. The GPUs were very old models (rx470-rx580) and the rest of the hardware wasn't that advanced, like it is in AI, so none of it was transferred.

I'm in the process of building my own AI supercomputer now. Really looking forward to seeing how it turns out.

Make a vid. Or a blog post, at least. Please :)

Thanks, but not my style, sorry! I've been doing PoW mining since 2014 and have so many stories, I've forgotten half of them. I wouldn't even know where to start on trying to document any of it.

Perhaps reach out to a YouTube channel or podcast that could be interested?

Did you manage to recoup the investment?

Of course I can't say anything about that other than I did the job I was hired to do, and I performed far above anyone's wildest expectations.

Nobody else on the planet was able to automate the tuning like I did, which had a direct influence on ROI. I know this because it required a very specific change to the AMD drivers to enable that functionality to happen.