All sounds reasonably safe. I am sure you are correct - I should look into how hcitool scan is implemented.
This is something I will never understand - Bluetooth is "implemented " in Linux kernel.
It uses "blueZ" "stack"... "blueZ" source code is "available" in several versions and ALL of them are lacking code comments or function descriptions ... basically a code nobody maintains...
My Linux version runs a "bluetooth manager " and my QT implementation of "blueZ" library interact with this flaky manager - perhaps by using the Linux " blueZ stack "...
A "stack" is the set of programs and/or system services needed to supply a given end-user (in this case) service.
As I understand it, for bluez there's
User programs : e.g. hcitool
System software : e.g. whatever system processes are needed to monitor/provide bluetooth services
System libraries : e.g. libbluetooth this provides interfaces for both system and user programs
Kernel module : e.g. bluetooth module, which provides the kernel side implementation details
As you can see, this forms a "stack", with each layer needing services from the layer below it to provide the services it needs to the layer above.
I am making sure this forum can accept / discuss and resolve "Bluetooth" as DEVICE.
With that let me make a statement:
For many reasons , irrelevant to the following post,
I do not fancy to utilizing "blueZ" library.
And please let us NOT discuss that.
i do prefer to use one of many open or hidden derivatives of "blueZ" library.
End of story.
I am pretty much done using "hcitool" .
Unfortunately "hcitool" has no easy or visible means to "pair" Bluetooth devices.
It looks as "bluetoothctl" can be used to pair.
hcitool and bluetoothctl DO NOT use same terminology describing Bluetooth processes.
device became controller
and who knows what is "agent" ?
Think of RAID as providing long term reliability. A RAID cluster can normally survive at least one drive going bad. A backup, on the other hand, is what you need in the event of anything from "finger trouble" erasing data, or a bug writing bad data, to a critical systems failure, such as a flood or file, from which you need to rebuild your operating environment.
If the only way to loose your files is a hard disk failure, then you may consider RAID5 to be a "backup" solution (the "backup" being stored in the redundancy bits of the non-crashed disks.
For all other issues - fire, flooding, machine/disk stolen/lost, inadvertent file deletion or content modification, ransom virus, discovering that a virus has infected a lot of your files, ... - you need a decent backup. For a great number of the risks, you also need offline, offside backup. You need frequent backup, at least daily, which implies that you need incremental backup.
My "grub" identifies a partition ( dev/sde7 ) as bootable.
It attempts to boot, but ends up in "maintenance mode ".
I like to recover SOME of the contents of the partition
but preferably REMOVE the OS.
I have had a very limited success using Linux maintenance / recovery
options and would prefer to remove the OS from the partition.
What makes a microprocessor different from a microchip? Is is the ability of a microprocessor to load information into transistors, use it/process it and then reset it`s state so that new information may be loaded and used again. Microchips are just an entity meant to direct information based on a hardcoded algorithm, rather than execute mathematical operations. Is this exact?
In exactly the same way as my house is multiple houses, right?
There were a number of processors thirty to forty years ago requiring multiple chips. Maye there still are some, but I haven't seen any multi-chip processors for quite some time.
In any case, you turned my analogy upside down. A processor (the functional part, the housing unit) resides in a physical unit, a chip, a building. Like an apartment can house multiple functional housing units, can a physical chip house several processors. In a multi-core CPU, some of the processors may be identical, but the chip may in addition house I/O-processors, graphic processors, debug processors and other specialized pones.
It can't, in economical terms, they a single piece.
Several of my friends have housing units which has a main house, a garage, a shed and even other houses. They are one housing unit, but spread on several physical units.
In the old days, you could have one main CPU, supported by a Floating Point Unit, possibly also a Memory Management Unit - the CPU, FPU and MMU being three different chips, making up one single processor.
If you go further back in history, even the CPU core was built on multiple chips: The iAPX432 processor had one chip to fetch and decode instructions, one to execute them, and a third chip controlling I/O.
For some years, many 16- or 32-bit CPUs were built from an array of "bit slice" chips - typically 4-bit AMD290x. The 290x were labeled 'bit slice processors', but they were not: They were hardcoded ALU logic that could be activated through control lines. The programming was external to the 290x. (That's exactly what you did when building a real processor from 4 or 8 290x chips.
Way back in time, CPUs were typically built from hundreds of 74 series chips, usually with support of a fair number of discrete components.
So in the old days, processors were built from several chips. Nowadays, several processors may be placed on the same chip.
You saying a chip can be a microprocessor and a microprocessor can be a chip?
"<x> can be a <y>" is the wrong way of saying it. To build the functionality of a processor, you might need to use several chips, although that is rarely the case today. And you can build the functionality of multiple processors onto the same chip. A chip is a physical electronic component. A processor is a functionality realized by (a) suitable chip(s).
My problem is understanding how this can be a problem to understand.
Last Visit: 31-Dec-99 19:00 Last Update: 2-Dec-22 13:19