quesomaster9000

And even with the constant `b=BLAKE("ECCFrog512CK2 forever")` there is an open question, while not as problematic as it is with the NIST & SEC curves, it's covered in "How to manipulate curve standards: a white paper for the black hat"[1]

I'm surprised they didn't include the constant in the paper and at least a short justification for this approach, despite stating "This ensures reproducibility and verifiable integrity" in section 3.2, whereas several other curves take the approach of 'smallest valid value that meets all constraints'.

Really they should answer the question of "Why can't `b` be zero... or 1" if they're going for efficiency, given they're already using GLV endomorphisms.

Likewise with the generator, I see no code or mention in the paper about how they selected it.

[1]: https://eprint.iacr.org/2014/571.pdf

Right, but z/OS is part of a larger longer-running hardware strategy that, with virtualization, serves the needs of mixed-OS workloads and multi-decade tenures overseeing 24/7 systems.

The corpse of OpenVMS on the other hand is being reanimated and tinkered with, presumably paid for by whatever remaining support contracts exist, and also presumably to keep the core engineers occupied with inevitably fruitless busywork while occasionally performing the contractually required on-call technomancy on the few remaining Alpha systems.

VMS is dead... and buried, deep.

It's a shame it can't be open-sourced, just like Netware won't be open-sourced, and probably has less chance of being used for new projects than RiscOS or AmigaOS.

With Claude 3.7 I keep having to remind it about things, and go back and correct it several times in a row, before cleaning the code up significantly.

For example, yesterday I wanted to make a 'simple' time format, tracking Earths orbits of the Sun, the Moons orbits of Earth and rotations of Earth from a specific given point in time (the most recent 2020 great conjunction) - without directly using any hard-coded constants other than the orbital mechanics and my atomic clock source. Where this would be in the format of `S4.7.... L52... R1293...` for sols, luns & rotations.

I keep having to remind to to go back to first principles, we want actual rotations, real day lengths etc. rather than hard-coded constants that approximate the mean over the year.

That's a good question, what if it's 10 hours per year for 10 years?

In that case, I'd probably choose first-aid & the basics of emergency medicine via a couple of half-day or a full-day course per year.

Fluid dynamics simulation with OpenCL, 100 hours is about 10-15 days of concerted effort. That's plenty time to get a grasp of the algebra behind it, get something simple running, port to OpenCL naively and start optimizing.

It's a shame that the `MISA` CSR is in the 'Privileged Architecture' spec, otherwise you could just check bit 21 for 'V', but that appears to only be available in the highest privilege machine-mode.

Presumably your OS could trap attempts to read the CSR and allow it, but if not then it's a fatal error and your program shits the bed, otherwise you rely on some OS-specific way of getting that info at runtime.

At the moment I'm verifying a Rust floating point implementation, which has lead to many small snippets for not just generating test & edge cases (e.g. find inputs which falls outside of these conditions), but trying to prove completeness on all valid inputs.

Z3 is entirely different IMHO, once you get into solvers the question becomes not just 'is this satisfied' but 'what is the minimum sequence of steps necessary to arrive at the result'.

I have relied heavily on both Z3 and Alloy for ad-hoc jobs, and Prolog doesn't even come close to the inference power, and that's along-side Macsyma and Sage.

On a side note, how long until we realize the current incantation of the pile of hacks upon hacks that is SMTP is fundamentally flawed and widely adopt something that has cryptography, authenticity and transport-level security built-in from the start?

Oh wait, yes, that'll never happen.

I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell.

There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again for every end-user product they integrate with, with the more ideal alternative being that each product provides their own implementations of the standard interfaces that are plugged into interfaces.

But, the reason I'm still on the fence is that I think there's more value in the UNIX style 'discrete commands' model, whether it's WASM or RISC-V I don't think anybody cares, but it's much more about self-describing interfaces with discoverability that can be glued together using whatever tools you have at your disposal.

As somebody who's in the process of building a sandbox for RISC-V 64 Linux ELF executables, even I'm still on the fence.

The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.

Meaning... no, I can't really just output WASM from Go or Rust and it'll work, there's more to it, much more to it.

With a RISC-V userland emulator I could compile that to WASM to run normal binaries in the browser, and provide a sandboxed syscall interface (or even just pass-through the syscalls to the host, like qemu-user does when running natively). Meaning I have high compatibility with most of the Linux userland within a few weeks of development effort.

But yes, threads, forking, sockets, lots of edge cases - it's difficult to provide a minimal spoof of a Linux userland that's convincing enough that you can do interesting enough things, but surprisingly it's not too difficult - and with that you get Go, Rust, Zig, C++, C, D etc. and all the native tooling that you'd expect (e.g. it's quite easy to write a gdbserver compatible interface, but ... you usually don't need it, as you can just run & debug locally then cross-compile).

LLMs are much more than search, for example today I went through several different recipes for sea bass fillets, and then went into much deeper conversations, and ended up with this weird intersection between Bon and how to aptly describe Zen, then very abruptly tried to hone some Bulgarian grammar, then pondered upon the enshittification of hacker news.

To the point that I'm disappointed with human contact.

If you're using it for React.js you're the problem...

With SoundCloud I've found you have to pay for the 'Plus+++' subscription or whatever it is to not get audio with the higher frequencies absolutely butchered, unless you follow a very specific upload process that bypasses their conversion.

Upload 320kbit encoded MP3? Sounds great.

Upload a high-khz WAV? It gets butchered, the top-end turns to glittery noise.

Maybe others have different experiences, but honestly it felt like I'd been duped when paying for the subscription but still got trash quality audio, only to have to pay more.

Absolutely, but not just that you can jump into meta conversations extremely quickly, and rotate things through different dimensions, even with concepts that are much less familiar. But the key is in deliberately creating the transactional context where ... if anything it's like the most fantastic debugging duck I've ever come across.

It absolutely will not necessarily find the most obvious errors, but you will learn a lot in the process.

At this point I wouldn't be surprised if their site loaded a WASM-compiled remote-desktop viewer to interact with 'Edge in the cloud' just to view the page you want.

Is it just me, or does the linked microsoft.com page hijack the back button?

TL;DR PEDMAS is bullshit

If you look at the internal state of the typical physical calculate it's a beautifully simple machine that tries to catch the balance between RPN and logic... except it has stupid nonsensical human rules interjected.

So, every time this article where points out "actually it's more complicated than it seems" is where historically somebody has made deliberate design decisions to do it 'the dumb way' even though it adds complexity, to force something unnaturally.

And what you end up with is something that's half intuitive, it's in between the two systems, but it's more complicated than it needs to be.

Please, I would much prefer device for RPN calculation, that follows consistent logic, rather than silly imposed rules.

4+7*3 etc.

or 4 7 + 3 * =

Where the latter is much closer to what we do in our heads and conceptually think about it.

Go supports this with `go run`, e.g.

    # Example 1: Running the latest version
    go run github.com/rakyll/hey@latest

    # Example 2: Running a specific version
    go run github.com/rakyll/hey@v0.1.4

Depending on how much space you have, I'm using a Numark MixTrack Platinum FX, with the mapping from the forum.

Everything works! Even the display in the middle of the jogwheels, that comes with the '4 deck' version, which shows BPM, time left, rotation indicator, shift amount/mode.

At this point almost all buttons & knobs on it are in regular use, although some of the deeper menu combos accessible via buttons aren't fully intuitive but don't seem to matter.

The Rekordbox.xml format [1] is quite simple. Note the `<TEMPO>` and `<POSITION_MARK>` tags.

But Pinoeer can be weird and there's a lot of old (even ancient) equipment out there, so sometimes it's a case of finding the lowest common denominator and sticking to that.

[1]: https://cdn.rekordbox.com/files/20200410160904/xml_format_li...

I'm really happy that 2.5 added 'beats until next marker', which together with a USB controller from Numark I have pretty much feature complete DJ setup for under $500 (including cost of laptop & controller) without having to rely on Windows, Mac, subscription licenses or feature-crippled 'lite' versions.

And it's surprising how quickly people adapt to it when they're used to other setups, within an hour a few people have gone from 'oooh, can I have a go' to showing me their own tips, tricks and different styles.

Especially combined with a youtube & soundcloud downloader running on a different workspace, I can get pretty much any track into the library within a minute or two.

I considered renting out some Pioneer equipment to add RekordBox playlist writing support, mainly because I'm in a similar situation. Mixxx does have support for reading USBs & SD cards, but not writing ;_;

Unfortunately it's far down my priority list given the cost, my unfamiliarity with Mixxx development and that I rarely do anything without Mixx.

But this is absolutely what ecosystem grants/bounties should be for.

I agree, it's absolutely and entirely bullshit and is becoming an easy sloganism that you can bash around. Where "replacing developers, engineers, and scientist with AI" really is about 'doing more with less'... or... just 'doing more, faster?'.

But it is genuinely replacing workers, in real terms. And more importantly it's replacing services, which in turn means jobs and revenue. So they too turn to electricity & automation, so they can do more... so they can remain competitive.

So uh yea, I 100% agree with you there, and wish that more people saw straight through it like you do.

While average power consumption per rack has been increasing fairly steadily over the past 10 years, the metric I currently use is abound 10kW per rack under reasonable to heavy load - that's about the same as a consumer electric shower.

So, this is implying their Vienna data center has 180 racks? With 60 being about a third, if we say each rack has 40 servers... that's ~7k servers total... which is a sizeable chunk of floor space, like 3000m^2, or... 40 tennis courts?

But yea, that a non-insignificant operation just for the Vienna data center.

Some of the best events I've ever been to have been where a collective has organized the Nth annual event etc. which has taken over an entire location or venue and brought in a really diverse but very friendly crowd with them from all over the place.

But yes, every other day of the week, it's like a restaurant that serves music, the machine must go on, rent gets paid, food in bellies etc.

> I'm good I think I'll just stay home and jerk off

Exactly. There's a fine line between convenience and the cost of doing it yourself, like getting a decent smash burger or firing half of the devops team.

The most ridiculous thing is having venues trying to casually extort you at every possible opportunity, without the implicit advantage of a few very subtle but 'approved' dealers lurking around while making sure everybody is having a safe but very fun time.

It's like an escalator to nowhere

I'd have thought that iPhones would have sane defaults with USB-C, but it's a real pain when using USB-C to provide tethered internet to a laptop. No, I don't want the phone to charge the laptop, they both have batteries of their own

And there's seemingly no way to get the phone to not try to charge things regardless of what the other side thinks (and when plugging the laptop in, it starts to charge the phone).

The alternative would be using WiFi (in a very RF polluted space) or Bluetooth (horribly slow), versus USB-C where 5g via my phone in Bangkok can get 250mbit easily. Whereas my Android phone has options for 'data only' etc. without charging which seems like it's more of a UX 'Apple' thing than anything else.

If you look at the end-user API documentation[1] it's pretty good.

But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments.

This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti.

On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently.

If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less.

[1]: https://htmx.org/api/

The road is paved with good intentions, it's not they were lazy but they had intent to distill wisdom to save time. Then yes, the abstractions were adopted without fully comprehended what was hidden, and those people then naively built additional layers of abstractions.

So yes, if the original problem had been better understood, then you wouldn't have a generation of React programmers doing retarded things.

Having watched many junior developers tackle different problems with various frameworks, I have to say React is conducive to brainrot by default. Only after going through a fundamentals-first approach do you not end up with one kind of spaghetti, but you end up with another kind because it's fundamentally engineered towards producing spaghetti code unless you constantly fight the inertia of spaghettification.

It's like teaching kids about `GOTO`... That is, IMO, the essence of React.

One minor piece of insight from me is about release management vs pull-requests.

As you say it's much easier to schedule a 30 minute meeting, then we can - with context - resolve any immediate nitpicks you have, but we can also structure bigger things.

'Would this block a release?'

'Can we just get this done in the PR and merge it'

'Ok, so when it's done... what is the most important thing that we need to document?'

Where the fact that even after it's merged, it's going to sit in the repo for a while until we decide to hit the 'release' button', this lets people defer stuff to work on next and defines a clear line of 'good enough'