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.
