in reply to Nanook

remember what we learned from Snowden: the NSA has everything it can get its claws into.

just maybe, if you are communicating via P2P with strong encryption, and the end points are Risc-V prototypes with a boot block under your control, then maybe you can have a private conversation.

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 spacedream

@spacedream There is paranoia and then there is sensical precautions. The only way to make a computer absolutely secure is to lock it in a Faraday cage without power. Accept that and go from there. Where Intel's ME is concerned, it ONLY knows about the built in NIC, so instead of connecting Ethernet to that, get a NIC card and use it.
in reply to Nanook

Robert, please... PLEASE, don't speak with me like im stupid phuk. even if my second language is looks silly to you. but you can be surprised one day then find i maybe know even more then you. you not only one here who know stuff. so please... ty. ❤
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 (Monday, March 22, 2021, 12:46 AM)
in reply to Nanook

but soon we will be available to build own supercomputers. nanotech. grow them in any garage just for fun from scrap. with literally unlimited memory and more. but lots of knowledge required to handle that task, so you guys better pay attention and don't waste your time now on memes and fun, but study real stuff. until you can.
in reply to spacedream

@spacedream The first computer I owned had a 2Mhz CPU with wait states even at that slow speed, 48K of RAM for which I paid an additional $1800 or so in 1981 dollars, at a whopping 360Kb in floppy disk storage. Compared to that todays computers ARE supercomputers.
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

@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 (Monday, March 22, 2021, 2:43 AM)
in reply to Nanook

COMBASIC


yeah! 😁 i did read it, Robert, in your first post i read from you days back. surely its was lots of fun. i did play a little with fido-net in twenty years back but not much as i wish by now (if i have time machine) as internets was growing already faster and giving so much to learn.

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.

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.