kimixa

Yeah, many of the things we consider part of what an "Operating System" provides to programs today were provided by DOS Extenders (or forwarded to something like windows if running under that).

DPMI was pretty much an "Operating System API/ABI".

Publishing things that are still available for purchase from storefronts (like steam and gog) seems to be stretching the definition of "abandonware".

While many people would likely justify their piracy with the idea that "The people who made it don't receive that money" - that isn't always true, and even then they did get the cash from selling the rights.

It's not as it playing that one specific game is a human right, after all.

No, that didn't happen. You're confusing two different events together.

The guy who posted the photo of brown skinned people with the "imagine the smell" comment was American and lost his job. The UK wasn't involved in any way. [0]

The comedian you might be thinking of is Graham Linehan - he was arrested for inciting violence against trans people and has a long string of twitter posts quoted as possible reasons. (and had a similar post with the comment of "a photo you can smell" but with a photo of a trans rights protest, so perhaps the origin of the confusion?).

[0] https://timesofindia.indiatimes.com/world/us/indians-dogpile...

Note that the quoted laws also cover things that would be restraining or harassment orders in the USA.

I think the sheer number of people below arguing it might not be about nationalism shows this sort of "Obvious" direct work may still be needed.

Why? Most modern OSs are "tickless" - where there's no regular scheduling tick and it can sleep pretty much indefinitely if there's no work.

If this stops the core being able to drop to a lower power state it can be whole multiples of power use on some devices.

Wake ups are death for mobile form factors, even if not really doing much work.

I'd argue the issue is people have figued out that "shit stirring" can make actual meaningful differences to reality, be they foreign or local.

When the limit of effect a flamewar would have is if Star Trek or Star Wars got the top billing, or Vim was recommended to new programmers instead of Emacs, it was a fun novelty.

But now there's real money and power resulting from this shit stirring of course people will use it as a means to an ends. They've optimised professional shit-stirring because it's so valuable now.

This is also something I try to ask for - generally I get the "that's fine" from the hiring manager and HR, but both times I've then had to push back and get it added to the actual supplied contract. And that was very much not easy.

And even then there's normally a "Sufficiently Different Sector" requirement for those personal projects - which makes sense, but it is inevitably worded vague enough that it would likely require going to court for pretty much any project to show it's not directly related. And that would be near prohibitively expensive for me as an individual if the relationship actually became adversarial.

The issue was the rcs files were simply corrupt - no matter what tool you used the older deltas were just bad. Just people didn't notice/care as they were "old" revisions.

And I couldn't find any tool that supported the mks "project" files that linked multiple rcs revisions into a single "commit", so something a little custom was needed anyway. At least for the ancient mks version used.

Quite a bit of effort was put into it during the "official" migration, but they eventually gave up too as even the oldest backup archives they could find had the same issues.

Ha, I worked for a company that until ~2012 still used RCS-backed SCM, absolute hack job on a shared file share that wrapped RCS with a "project file" to allow a tree of specific revisions for a "project". "MKS" it was called. And by the sound of it the "old" '90s version, not the java EE rewrite.

That meant the files has the entire "$Revision: 1.3 $" nonsense and "file changelog" at the top too - though many newer files never bothered to include the tags to actually get RCS to replace them. Inconsistent as hell.

And while the "family" of devices the software was for traces it's origin to the mid '90s, functionally none of the code was older than ~5 years at that time.

Naturally even with only a few tens of engineers it regularly messed up, commits stepped on each other's toes and the entire tree got corrupted regularly. For fun I wrote a script that read it all and imported the entire history into git - you only had to go back a few years before the entire thing was absolute nonsense.

I have no idea why that was still being used then, but I assume it had been in use from the very start of that entire hardware family. Perhaps as it was fundamentally a "hardware" company - which until surprisingly recently seemed to consider "source control" to be "shared folders on remote machines" - "software" source control wasn't considered a priority.

I suspect there are at least as many programmers working as the ASM level today than there ever was - they're a lower proportion, but the total number of programmers has increased dramatically.

I wonder if this sort of trend will continue?

1.1 was very much commonly used in consumer marketing, to the level where there's many instances today of people referring to pcie1.x speeds as "1.1". And I'm pretty sure I've seen 2.1 in consumer marketing contexts. But you're right I didn't know 3.1 existed until I looked it up :p

But USB 3.0 is pretty much the only "speed" that hasn't changed - it always required the extra connectors for 5Gbps from the start - but no more. What about those ports is now not "3.0"?

PCIe also had things like "1.1", "2.1" and "3.1" - that fixed issues and added functionality - but there wasn't the same crossover between "feature sets and spec revisions" and "speeds" we see in USB today.

Yeah, the banners/popups aren't required by gdpr, they're the "malicious compliance" solution site owners came up with because they don't want to comply with the limitations, and make it as difficult as possible for the user not to let them.

As someone that's worked on GPU drivers for shared memory systems for over 15 years, supporting hardware that was put on the market over 20 years ago, and they've "always" (in my experience) been able to dynamically assign memory pages to the GPU.

The "reserved" memory is more about the guaranteed minimum to allow the thing to actually light up, and sometimes specific hardware blocks had more limited requirements (e.g. the display block might require contiguous physical addresses, or the MMU data/page tables themselves) so we would reserve a chunk to ensure they can actually be allocated with those requirements. But they tended to be a small proportion of the total "GPU Memory used".

Sure, sharing the virtual address space is less well supported, but the total amount of memory the GPU can use is flexible at runtime.

Yes, if you're not FP ALU limited (which is likely the case if not vectorized), or data cache/bandwidth/thermally limited from the increased cost of fp64, then it doesn't matter - but as I said that's true for every performance aspect that "doesn't matter".

That doesn't mean that there are no situations where it does matter today - which is what I feel is implied by calling it "Ancient".

But the "float" typename is generally fp32 - if we assume the "most generically named type" is the "default". Though this is a bit of an inconsistency with C - the type name "double" surely implies it's double the expected baseline while, as you mentioned, constants and much of libm default to 'double'.

> ... if you look at (say Agner Fog's optimisation PDFs of instruction latency) ...

That.... doesn't seem true? At least for most architectures I looked at?

While true the latency for ADDPS and ADDPD are the same latency, using the zen4 example at least, the double variant only calculates 4 fp64 values compared to the single-precision's 8 fp32. Which was my point? If each double precision instruction processes a smaller number of inputs, it needs to be lower latency to keep the same operation rate.

And DIV also has a significntly lower throughput for fp32 vs fp64 on zen4, 5clk/op vs 3, while also processing half the values?

Sure, if you're doing scalar fp32/fp64 instructions it's not much of a difference (though DIV still has a lower throughput) - but then you're already leaving significant peak flops on the table I'm not sure it's a particularly useful comparison. It's just the truism of "if you're not performance limited you don't need to think about performance" - which has always been the case.

So yes, they do at least have a 2:1 difference in throughput on zen4 - even higher for DIV.

Even the latest CPUs have a 2:1 fp64:fp32 performance ratio - plus the effects of 2x the data size in cache and bandwidth use mean you can often get greater than a 2x difference.

If you're in a numeric heavy use case that's a massive difference. It's not some outdated "Ancient Lore" that causes languages that care about performance to default to fp32 :P

Same reason any turing complete language needs any constructs - to help the programmer and identify/block "unsafe" constructs.

Programming languages have always been more about what they don't let you do rather than what they do - and where that lies on the spectrum of blocking "Possibly Valid" constructs vs "Possibly Invalid".

That matches my experience too - LLMs are very capable in "translating" between domains - one of the best experience I've had with LLMs is turning "decompiled" source into "human readable" source. I don't think that "Binary Only" closed-source isn't the defense against this that some people here seem to think it is.

The 256GB Mac Studio (the one with "eight times the RAM") is listed for ~$2000 more than the current 5090 prices, and another additional $1500 for the 80-core GPU variant. Only the "base" model with 96gb is a remotely similar price, $3600-$4000.

And a 5090 has a little over 2x the memory bandwidth - ~820GB/s vs ~1790GB/s. And significantly higher peak FLOPS on the 5090 too.

Sure, if the goal is to get the "Cheapest single-device system with 256GB ram" it looks pretty good, but there's lots of other axes it falls down on. Great if you know you don't care about them, but not "Better In Every Way". Arguably, better in only a single way - but that single way may well be the one you need.

And the current 5090 price might be a transient peak - only three months ago they were closer to $2500 - significantly less than half the $6000 base-spec 256GB Mac Studio. While the Mac Studio has been constant.

ROCm vs Vulkan has never been about performance - you should be able to represent the "same" shader code in either, and often they back onto the same compilers and optimizers anyway. If one is faster, that often means something has gone /wrong/.

The advantages for ROCm would be integration into existing codebases/engineer skillsets (e.g. porting an existing C++ implementation of something to the GPU with a few attributes and API calls rather than rewriting the core kernel in something like GLSL and all the management vulkan implies).

Today Claude asked if I "wanted to leave this until tomorrow" as it was a "big rework", then stopped, requiring me to tell it to continue multiple times - that seemed kinda weird to me, it doesn't have the context of time of working day or similar (I'd only just started for one).

I have no idea what link it made to ask that, what in its training data or prompts, but it's very much "not a useful result".

I don't remember seeing anything similar, but have only been using Claude on and off for 6 months or so.

It could be that the contract price for Samgsung is still below the spot price - it's just the packagers/resellers/distributors are currently pocketing the difference rather than Samsung.

*strace that is - annoyingly it seems it was autocorrected away

For just logging would it really give any more info than a trace already does?

It doesn't reveal they don't have no clue either - the problem is that both "Doesn't actually understand" and "Does understand but saying it because they think it'll benefit their products" look exactly the same from the outside.

All we know is he's saying things that are technically incorrect. And I'm not sure where that falls on the line of "Just Acceptable Marketing BS" to "Lying to the market about a Publicly Traded company" that would fall if he does understand it.

And while true he very much had deep technical education and roles, he's been C-level for over 30 years now. And a lot can change - both in the underlying technology and an individual's technical understanding - in 30 years.

Statistically you'd expect some "random" samplings of the population to show significant deviations from the mean just by chance.

Roll enough different sets of dice and you'd expect some to end up being all sixes - that doesn't mean that set is rigged. Yeah, they're the ones you'd do further tests on, but it's not evidence in itself.