I was just reading what Stephan from ports wrote about the "Tor" based privacy suite. He thinks it's a little too outdated and offered to help, which is encouraging for people like myself.
I bought the,"privacy suite" discs, with Linux magazines, and it cost me in excess of A$60/=.The Tecra M-10 (Toshiba 14",(old Intel dual-core chipset, hence closer to the Centrino than any other contemporary IBM PC-AT compatibles)) booted into the OS fine, the first time around. Getting it to install onto the HDD, seems difficult currently. Changing the boot sequence at the BIOS is not an option for me currently, because the boot sequence is hardwired and the BIOS does not offer changes to the primary and secondary devices, primary being, "tape drive", and secondary being, "SD card", so the interrupt option for the, "switch-toggle mode", if remote assistance is possible. I will still need to shop around for a tape cartridge, although I was fortunate to be able to buy a new battery for the panel and a, "docking station", too for port replication. Have'nt engaged them yet, probably another 2-3 weeks away, in transit currently. When I engage the docker, the DiVX port will only engage from the Open-Server end, not at the Tecra M-10, although that option may be available because of it's current configuration and resource limitations. So in all probablity, DiVx @ OS end only, if I have to engage the DiVx at the Tecra, it will be for boosting resources for a fully functional Toshiba, if I can make that happen, meaning the boot into a resident OS variant, has to be clean and flawless, and password authentication, need not play up everytime. Regarding Stephan's concerns about, the "Tor" variant being too old, I'am not too worried currently, because the tools for Microsoft's Visual Studio integration facilitate backward compatibility. You can port them later, and can find them at: www.telos.info/download/i2c-studioframework/?fbclid=IwAR29AyQrPQJe-FSS40TTqntTwZ4vjj-OFbtAg8fWPrfoQTw4xbQgnG81i30 hope that's a useful binder for those of you genuinely worried. best regards, rajneesh The i2C architecture was initially designed to lessen costs by streamlining massive wiring systems with an easier interface for connecting a central processing unit (CPU) to peripheral chips in a television. It had a battery-controlled interface(a normal battery which we used for transistor radios and the like) but later utilized an internal bus system (for circuitry and communication patterns between integrated circuits on a printed circuit board). In 1992, version 1.0 was the first i2C standardized. By 1995, Intel introduced the system management bus (SMBus), which is derived from the i2C. The SMBus defined firmer protocols for communication with low-bandwidth modules and sometimes supported the i2C that required marginal reconfiguration. The SMBus is comparable to the i2C bus but has different enhanced features such as voltage levels, clock frequency and a preference for an additional interrupt request wire. Although slower than the majority of buses, the i2C is an inexpensive architecture and is ideal for peripherals that do not require a lot of speed such as digital-to-analog and analog-to-digital controllers, built-in tests, real-time clocks, colour-balance, tone and volume control. Rajneesh N. Shetty On Tuesday, 8 October 2019, 10:59:07 pm GMT-5, Theo de Raadt <dera...@openbsd.org> wrote: Sometime in the last week OpenBSD crossed 400,000 commits (*) upon all our repositories since starting at 1995/10/18 08:37:01 Canada/Mountain. That's a lot of commits by a lot of amazing people. (*) by one measure. Since the repository is so large and old, there are a variety of quirks including ChangeLog missing entries and branches not converable to other repo forms, so measuring is hard. If you think you've got a great way of measuring, don't be so sure of yourself -- you may have overcounted or undercounted.