Getting into 8-bit NESdev with only 64-bit free software

[freem]

You cannot tell what a binary blob does, it is a security nightmare that could do anything from cryptolocking your files to installing Windows 10.

I really honestly hope that you built your own computer. Not just "putting together parts", but literally designing every single piece of hardware in there. Otherwise, you can't trust ANYTHING.

[tokumaru]

Yeah, I've heard that firmwares for example can be extremely dangerous...!

[tepples]

And is it more enjoyable to play-test a Super NES game at one-fourth speed with choppy sound on a free emulator or on a proprietary emulator at full speed with correct sound? Because that's the speed difference between free bsnes and proprietary NO$SNS on the Atom N450 in my laptop.

Is something wrong with snes9x or zsnes?

That depends on whether there's a debugger for Snes9x other than (a) Geiger's or (b) debugging the emulator as an indirect means of debugging your game.

[nicklausw]

A user wants to use an NES debugger on a 64-bit Linux PC but refuses to use any non-free software out of principle and refuses to install any 32-bit free software (such as FCEUX for Windows in Wine) out of fear that the 32-bit support libraries will take several gigabytes and "hav[ing] better use for that space".

If higan had debugging features, that would certainly fit the bill. Other than that wine seems to be the only option.

Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?

[Revenant]

Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?

All of the debugger GUI components are written exclusively using the Windows API.

[Myask]

Which, if I recall my TAS-emulator history right, was because it was that way on Gens, from which they took said parts.

[gauauu]

Why are FCEUX's debugging features only on win32, anyway? Do they use Visual Studio's C++ API features?

All of the debugger GUI components are written exclusively using the Windows API.

I've been tempted more than once to take the time to start writing GTK versions of the debugging components. But after checking out the code and starting to dig through it, I always end up shrugging my shoulders and installing WINE.

[mikejmoffitt]

You cannot tell what a binary blob does, it is a security nightmare that could do anything from cryptolocking your files to installing Windows 10.

If you are going to be so jailed by your own freedoms, then you'd be best off writing your own tools only.

[calima]

Incidentally, I'm typing this in my own web browser, while my own PDF reader and stock watching program are open More about the lacking functionality in existing programs, but hey.

From my POV, it's simply stupid to give trust where none is deserved. You're risking everything on your computer just to run a proprietary program. If that program really is worth all your data, and what can be done with it, then do use it.

[tepples]

You're risking everything on your computer just to run a proprietary program.

Which is why one runs it in a container that cannot read or write anything outside the container.

[mikejmoffitt]

You're risking everything on your computer just to run a proprietary program.

Are you running software as root? You may enjoy Jails.

[calima]

Indeed, at the cost of that container/VM.

Are you running software as root? You may enjoy Jails.

Of course not. But I'm aware bugs exist. The kernel I'm running on has easily hundreds of privilege escalation bugs, as well as bugs allowing one to escape a container.

[tepples]

You mentioned coreboot/libreboot earlier. A few PCs are compatible with libreboot. For everything else, the free operating system relies on proprietary firmware components, such as ACPI BIOS or UEFI. These act as the "container" for a free operating system, and like any other container, they may have defects that allow escalation.

[mikejmoffitt]

A few PCs are compatible with libreboot. For everything else, the free operating system relies on proprietary firmware components, such as ACPI BIOS or UEFI. These act as the "container" for a free operating system, and like any other container, they may have defects that allow escalation.

What about the small embedded programs and microkernels on the dozens of embedded devices that make a computer's peripherals work? I speak of peripherals like NICs, memory controllers, USB controllers, sound cards, et cetera. Where is the line of trust drawn, and with what justification?

[calima]

A regular NIC, sound card, etc does not have access to memory. Even a thoroughly malicious NIC is limited in what it can do.