XPost: comp.sys.mac.system, alt.comp.os.windows-10, comp.mobile.android
From: nospam@needed.invalid
On Thu, 4/17/2025 2:45 AM, Alan wrote:
> On 2025-04-16 22:15, Paul wrote:
>> On Wed, 4/16/2025 9:52 PM, Alan wrote:
>>> On 2025-04-16 14:24, Paul wrote:
>>>> On Wed, 4/16/2025 4:26 PM, Alan wrote:
>>>>> On 2025-04-16 05:28, Paul wrote:
>>>>>> On Wed, 4/16/2025 6:53 AM, Daniel70 wrote:
>>>>>>> On 15/04/2025 6:01 am, Carlos E.R. wrote:
>>>>>>>> On 2025-04-14 17:48, Frank Slootweg wrote:
>>>>>>>>> Arno Welzel wrote:
>>>>>>>>>> Arno Welzel, 2025-04-14 13:18:
>>>>>>>>>>
>>>>>>>>>>> Frank Slootweg, 2025-04-13 15:57:
>>>>>>>>>> [...]
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Yes, I agree, that Android has the flexibility to user other
methods as
>>>>>>>>>> well, like backup apps, ADB and so on - but this needs enough
experience
>>>>>>>>>> by the user like how to set up ADB on a computer or how to transfer
the
>>>>>>>>>> backup to another device using USB and so on.
>>>>>>>>>
>>>>>>>>> The methods I mentioned do not require the user to setup
ADB. The
>>>>>>>>> Smart Switch Android-to-Windows backup does use a USB-cable, but no
ADB.
>>>>>>>>> The Smart Switch Android app can transfer to another phone by Wi-Fi
or
>>>>>>>>> USB and can backup to cloud, SD-card or USB-stick.
>>>>>>>>
>>>>>>>> That's a Samsung app, I understand. What about a generic full backup
app, non adb? For any operating system, not Windows only?
>>>>>>>
>>>>>>> Don't know about a Samsung App but, in Linux, I can use a 'dd'
commandline command to back up both my Windows and Linux installations.
>>>>>>>
>>>>>>> Is there a similar commandline command for Android and/or Apple Mac??
>>>>>>
>>>>>> On computing devices that support booting from a second OS, you can
>>>>>> gain "dd" access from the second OS. On my MacG4, I booted the Ubuntu
PPC
>>>>>> DVD, and used Ubuntu "dd" to transfer out the disk (which would be
at-rest).
>>>>>> I used a command line FTP session, and you can mix shell commands into
>>>>>> the ftp commands -- dd can be piped into a (binary) "put". And on the
computer
>>>>>> I did that on, the GbE at 112MB/sec, that's the fastest interface it
has got.
>>>>>>
>>>>>> But something like a phone, there are fewer opportunities for tricks
like that.
>>>>>> Rooting the phone, if you can manage it, is as close as you're getting
>>>>>> to a good time.
>>>>>>
>>>>>> On at least one phone, the NAND is hidden underneath something, and
>>>>>> you can't cable up and read-out the NAND chip with external equipment.
>>>>>> For some of the devices, it's pretty well secured. You would not expect
>>>>>> a simple trick to work in such a case.
>>>>>>
>>>>>> Paul
>>>>>
>>>>> Or you could just use the "dd" command built into the Unix sub-system of
every Mac since Mac OS X was first released in 2001...
>>>>
>>>> But not make a copy of the disk while it is "hot".
>>>> The MacG4 Quad Nostril does not have VSS and shadow copy for hot backups.
>>> So make a second boot drive for the Mac.
>>
>> I stopped opening up the G4 after a while. It required sitting
>> on my kitchen floor and "cradling the scissor case" when opening it.
>> That's to avoid stressing the cables in it.
>
> And you've never heard of external drives?
>
> We're talking about a special purpose boot drive you'd only use to do your
dd backup.
The boot was a DVD (Ubuntu PPC Linux, with dd on it).
Ubuntu does live sessions from the DVD. Nothing to install.
And that's really all I did with that DVD, I wasn't running
Ubuntu regularly on the G4, or making a dual boot situation
or anything. The DVD boot was pretty straight forward, and
good enough for the amount of usage it would get.
The MacG4:
Firewire 400 My enclosures with Oxsemi chip do 30MB/sec
USB 1.1 port Transfers at 1MB/sec to USB storage
GbE Ethernet Transfer at 112MB/sec to another machine.
Much easier for me, to use another machine to help out
and use the GbE for the transfer. But the best part, was
discovering you could pipe "dd" into the FTP "put" command.
That's what made it possible to do without more tricks.
(You can mix shell commands, with the FTP session commands.)
My SCSI disk collection was getting a bit old, and
the disks were 1/4 the size of the IDE drives. I'd used SCSI
for quite a while, up to that point. The SCSI drives had
ball bearing motors, and were quite loud. I wasn't about
to buy more SCSI at that point. I had enough trouble with
the SCSI chain at my desk at work. It really is voodoo
that stuff.
Computing generally sucked for a lot of years.
Unnecessary suckage. As an example of pathetic, AMD
made a chipset with PCI 32 bit (what everyone else was
using), and PCI 64 bit (which could have been special).
But due to some bug in the chip, the PCI 64 bit bus ran
at one quarter of the proper rate :-/ And they released
the chip anyway, as a salute to suckage.
The computing industry, could teach a farmer a
thing or two, about "how to milk a cow". That's what
the clumsy steps forward tell us.
I would not even be on USENET today, except for a motherboard
I bought. I tried to assemble it and get it to run, but
the board wouldn't come up. I spent about three weeks testing
it. I tried to use USENET, to find some help. There was
no one around to help out. Or to point out just what a
lemon the Northbridge on that board was. Apparently the
company making the chip, couldn't afford a chip tester
with enough channels for the Northbridge they built. They
tried to "test the chip as two halves". The chip tech
wasn't nearly fast enough. In other words, every
motherboard shipped with that piece of garbage on it,
was doomed to fail on timing. And I stuck around on
USENET after that, in the motherboard groups, to help out.
At least I could tell you, what board not to buy :-)
Paul
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
