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 

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:


hope that's a useful binder for those of you genuinely worried.
best regards,

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 

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.


Reply via email to