in reply to Nanook

you have no idea about another bios softwares in your hardware, don't you? its all backdoored also long before you even heard about its exists. even if you put libreboot, etc, etc, etc on your hw, i'm very sure they still can find the way how to sneking in. so better don't lie to yourself. ps. i remember also ~few decades back ceeayey has on site shop where they sells lots of bugs and spy stuff to anyone who pays buks globaly (to another shepherds). before snowdens start leaking out to public. funny, huh? ;) so they sells so tiny-winny toys they can be plugged to in your hw without your knowledge and keeps leaking data out. by end of 90s its was like spacetech looks. i forgot the name of german guy who leaked this sht later and they just destroyed his life after few years. this sick slave-owners-mentality owners love stalking games and very boring i guess.
in reply to Nanook

the systems I described do not have coprocessors to support a ME. so, no Minix.

they may have other defects, but no ME. one is a really old processor, pre-2000, and the other is new but a prototype without a lot of internal complexity. (the prototype RiscV chips are probably going to be scarce; I'm starting to see advertising for SoC versions of them)

This entry was edited (4 years ago)
in reply to Nanook

both Robert and I are old farts -- we have watched the computer industry mutate and metastasize through the decades.

for what it's worth, the chip in your cellphone would have been a 'supercomputer' in 1990. but this thread isn't about that. it is about security.

and, security can only be had by abandoning some of our complexity. building your 'supercomputer' out of compromised chips from monopolistic corporations is not the way.

in reply to BR 549 ☎

@BR 549 ☎ There really is no other option. And really when kernels are 200MB in size and you have gigabyte applications and you're doing 10 billion operations per second, YOU ARE going to have flaws, exploitable holes, the best you can do is a multi-layered approach with multiple layers of security and detection and KEEP ON TOP OF IT, it is not static like physical security.
in reply to Nanook

about ten years ago, I built my own server for the house here. it was based on a little POS computer I got for cheap off of Newegg. it had a Cyrix 486 and 16MB of RAM, as I recall, on a small motherboard with a common bus, what was it called? anyway, I got a cheap NIC for it, and loaded this operating system.

it was more for the challenge of installing a new system from scratch, etc. it loaded from a removable disk, as I recall. and it was interesting to enable logging, and watch it from my desktop, the sheer quantity of malicious packets coming in. if you would ping it from some other place, it would not respond -- basically a black hole in the 'net.

eventually I abandoned it, because I upgraded my DSL and it was too slow. but it was interesting.

Unknown parent

friendica (DFRN) - Link to source

Nanook

@spacedream I wrote a programming language I called COMBASIC in Z-80 assembly. I specifically wrote it for writing BBS's. It had the same structure as BASIC but was a superset of BASIC keywords and functionality. It also ran 40% faster than Microsoft BASIC on the same hardware, did some primitive multi-tasking using the clock interrupts to run background tasks, and handled the functions of a host program since TRASH-DOS had no support for the RS-232 serial port. It also did not have the VAL() bug that MS Basic had, my VAL correctly handled strings with '%' in them. It could format text files to variable screen width, and it had the ability to generate save files with different names for each user for games so that I could put games online and each user had separate saves. It did read-aheads on the floppy drives with buffering so you didn't see the spin-up delays when text was being read like most BBS's of the time had.
This entry was edited (4 years ago)
in reply to Nanook

it was a PCI bus. the NIC had a PCI bus, and the motherboard had a spare slot.

interestingly, someone had written a web server for it in BASH, in amazingly few lines. on the internal network you could simply open the web page for status and control. everything was RAM based, so logfiles would rotate very quickly into /dev/null. if anyone wanted to run malware on it, they'd have to make it super small. unpacking a compressed file would likely fill up RAM and cause a reset.