AshamedCaptain

So, exactly like what Mac OS X did with IO Kit. They managed for several decades...

Not at all. IO Kit was raw, pure C++, with all the ABI consequences you must deal with (including fragile base class). Just go to see any header of any exported IOKit class to see what I am talking about.

There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.

I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.

I'll note that Mac OS X used a C++ ABI in the _kernel_....

And basically only used by those allergic to Samba's GPLv3.

Kind of proving why accuracy is not really that important for the PC world. Most era firmware would have tried to run on as much variety of machines possible.

Or a Rosetta-based emulator (like Parallels). But 86Box is going to be very bad there.

While they claim "accuracy" as one of the goals for 86Box, I believe accuracy is overrated in PC emus (you don't really need that much accuracy due to the variety of PC clones, and emus are not that accurate anyway). For me the biggest point for using 86Box over other PC emulators/virtualizers is the large selection of virtual hardware available to emulate, not performance.

That's Box86 [not a joke].

When actually it should be software companies that should be worried. If you believe like some guys do that you can just point an LLM to any piece of software in the world and ask it to patch it / replicate it / maintain it with zero copyright repercussions, what is the point of software companies again?

There have been shitloads of open source RADs. They do not generate much interest.

I once worked on a handheld garmin gps that used a 386 ... not sure if it ever became a product, though. It definitely had moving map... 1MB of it.

Right until you release it and a minor gets the NPC to talk about rape or something.

No and you missed the "freedom" part of the adage.

While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free. Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.

This is bad enough that I'm going to stop serving cgit. I've been doing cvsweb, then subversion, then cgit over my home server for many many years and for the first time ever this is annoying my own bw usage.

It's ridiculous also how you ban an IP then 1 second later another one picks up from where the first one left on.

This still would allow one to "strobe" the power line making it impossible for a human to see the LED but the camera could still capture snapshots and at a decent framerate even.

Look, I find it funny that I find myself arguing on the other side of the discussion that I'm frequently on, but here is where I draw the line, and I think what is ridiculous is to think otherwise.

How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.

How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.

Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.

I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.

Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.

And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.

> AT&T bakes the width into the mnemonic (movb, movw, movl, movq [...] Intel’s syntax is to prefix the memory operand with byte, word, dword, or qword, but Odin’s just uses the Odin type system directly.

In GAS you can skip the width suffix from the mnemonic, and in most Intel assemblers you can skip the memory type operators like byte. They happily guess it from the operands. The problem is that on x86 (but also other ISAs, even if to a lower extent) the different operand sizes have a lot of side effects, which is why everyone just makes the operand size explicit, up to the point that apparently the author/LLM believes that it is mandatory to specify them.

This kind of defeats the headline of the article...

Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks. This is why everyone's inline assembly syntax looks like that, because they want to cover the weird cases (gcc's one is almost like an history book). You're normally using inline assembly for when you have some ridiculous corner case, if not, then what you ought to use is more akin to intrinsics...

Also it forgets Watcom C, which does have a complete but messy syntax for inline assembly (which combines nicely with its ability to specify really weird calling conventions).

From the same lunacy that forces me to write my 30-something character Wi-Fi password on a "secure password field" that only shows me the last character, almost ensuring that I will make an unlimited number of typos and spend way too much time for something that should only take 30 seconds.

It's not clear who it is protecting against, it does not seem to be effective at protecting against anything at all, it is actively annoying to the user, and has no way to disable. Perfect example of the usual "security theater" feature.

I think you forgot what the "H" in "HN" means.

This is often said but if you want to "diagnose" something then the terribly limited Android shell is about the last place you want to be, and a sandboxed one on top of it is worse ....

I now realize how hypocritical it is for Spain to ask about Gibraltar to the UK while they still are keeping Ceuta in Morocco.

In addition, when we usually say that triggering undefined behavior on C can start a game of Tetris or format your hard disk we're usually joking (or at least exaggerating), i.e. the most common failure conditions of compilers are really limited in scope, and very likely caught by whatever testing mechanism you use for the software.

No such limits for LLMs where losing all your files is about par for the course for everyone who uses them regularly.

I am quite sure AMD is already using a fork of the Linux amdgpu KMD for their proprietary driver on Windows (which in part explains why a project like this can even be done)

Porting Linux drivers to anywhere is generally hard. It either makes your kernel very Linux-like (and lots of manpower to translate the abstractions), or forces you to put Linux on it. There are bazillions of projects to put recent Intel drivers on 9x and none suceeded, for example.

Plus my recent observation that for Haiku it was easier to port the out-of-tree nvidia driver and fork Mesa, than it was to port the Linux amdgpu one.

And SPF doesn't?

But there is no evidence whatsoever for what you are saying (in fact the nvidia drivers are portable and may perform comparably or even better than the free ones).

On the other hand here we have evidence of how this has made it impossible for any OS other than Linux to provide support for amdgpu (except if you rip a huge chunk of Linux code, which only works if your OS is extremely UNIX-like to begin with), while other OSes support NVidia cards just fine (which do not really have a complete free driver to begin with!).

See the first message of TFA. The author complains that amdgpu has way too many linuxisms that make it impractical to port it to non-Linux ( unless you are already emulating Linux). On the other hand, the nv kernel driver is portable, up to the point that it is easier to port that to Haiku and then change the entire Mesa to use it than it is to port amdgpu (which wouldn't need Mesa changes).

They are literally the only one who has managed to do it,, and they do so by having a huge layer of compatibility that takes years to update to new versions and support newer generations. We do not know if it would be easier for BSD to support nvidia either ... because they already have nvidia drivers (released by nvidia itself).

On the other hand here we have a random guy that adds support for nvidia gpus, by himself, on a non-linux, non-bsd kernel. And specifically claims he will not do the radeon one because he finds it too much work.

What I find depressing is because of idiotic Linux policies, it turns out nvidia hardware is easier to run on a 3rd party OS than hardware with otherwise fully open source drivers like Radeon.

This is just yet another example that you may think things in the hardware world have changed now that Linux "rules", but they have not.

Even big US companies today are full of "Is this good for the company?", "Our company values" and other cringe-inducing loyalty/ethics-related propaganda, about as much as 30 years ago. So they are keeping the charade, for better or worse, even though it is as much hypocrisy today as it was 30 years ago.

(Maybe 60 years ago it wasn't hypocrisy, but I lack personal evidence).

I always found it relevant that in Spanish-dubs they translate the name of Homer to "Homero" which would be basically how you would refer to the classic author rather than to some american layman. (as if e.g. in France I translated Homer as Homère instead of plainly Homer).