[Q] Android RAM-terms and explanation? - Android Q&A, Help & Troubleshooting

Hi I wanted to see what you guys make of these apps. Does anyone know where I could get a reference guide specifically pertaining to such apps.
Even the "Performance control" feature found in most AOPK Custom Rom's have these weird terms.
Any help would be great.
Here's a picture for reference...sorta

WestxtseW said:
Hi I wanted to see what you guys make of these apps. Does anyone know where I could get a reference guide specifically pertaining to such apps.
Even the "Performance control" feature found in most AOPK Custom Rom's have these weird terms.
Any help would be great.
Here's a picture for reference...sorta
Click to expand...
Click to collapse
init.d -- a system that allows for running services at boot that are not run by the init.rc scripts
swap -- virtual memory. unlike ram, swap is stored on disk/flash storage, and as a result is slower but larger.
dirty -- memory that may need to be written to disk/flash. consider it used.
soft reboot -- a reboot that only restarts high-level system functions (essentially, the android part of android rather than the linux part)
couldn't tell you about the other options in android tweaker. see if it has a help file or similar.
hope it helps!
--ultraviolet

ultravioletnanokitty said:
init.d -- a system that allows for running services at boot that are not run by the init.rc scripts
swap -- virtual memory. unlike ram, swap is stored on disk/flash storage, and as a result is slower but larger.
dirty -- memory that may need to be written to disk/flash. consider it used.
soft reboot -- a reboot that only restarts high-level system functions (essentially, the android part of android rather than the linux part)
couldn't tell you about the other options in android tweaker. see if it has a help file or similar.
hope it helps!
--ultraviolet
Click to expand...
Click to collapse
Thanks! :good: that's pretty much what I'm looking for; leads that help me get my mind around it a bit more

iglo a109 problem
se.. all of those aren`t checked, when i tried to connect, in the photo, they are like that because it was i made a mistake when i created the print screen, so... i don't see how that's the problem, when i connect my phone and then after 2 sec it disconnects itself and starts charging

Related

[THINK TANK - WIP] Apps2SD on Nexus with Option on Install Location

Hi all,
If you are going to say we don't need Apps2SD on the N1, please leave the thread now . (Actually, read on) There are various reasons I can think of why we need Apps2SD on the N1, and one of the biggest is actually Games. I don't really play any games to begin with, but the last I checked, some games are as large as 19MB, possibly more. Isn't it kind of crappy that the N1, the superphone, can't hold more than 10 such games?
I started this thread with the intention of gathering more information, and hopefully some coders will do it (including myself, if I've the time). Package Manager (the thing in charge of installing, if I'm not wrong), is in the AOSP, under frameworks/base. In such a case, wouldn't it be possible for some programmer to mod it such that it will ask you whether to install to (SD/Phone) before each installation process?
The other issue is, looking at current implementation of A2SD, it seems all apps on Phone are moved to the SD card partition. If we can have an implementation that allows both to co-exist, in addition to the Package Manager mod, I'd say we'll have a pretty nice implementation.
Your thoughts/findings? I may be completely off, have yet to actually look at the AOSP source.
Update:
@ChrisSoyars has an early implementation of this in his SnackPack - http://forum.xda-developers.com/showthread.php?t=638301
I would also like to thank everyone else for their valuable input and support ! Keep them coming. Lastly, sorry I'm not doing much code-wise (not at all), school work's too much .
Would be nice!
....I've got the same problem. Some application are very big and so i have got only 10MB free space anymore...
ADB is god
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
lazinase said:
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
Click to expand...
Click to collapse
that doesnt work on roms like the desire by modaco. app2sd doesnt work, ive tried that method and it just hangs. true there is a thread already for app2sd, but its not going anywhere in terms of the newest desire release. i know its still early, but i only had like 50mb for apps and i have over 120 apps and i didnt feel like reinstalling. someone fix it please.
Apps to SD is of course necessary. The Nexus doesn't really have that much space for apps - about 190mb which is only the same as the Hero.
I have apps 2 SD working with CM 5.0.3 from the kitchen.
its also addable to a CM rom using the how to thread.
It WAS working ok with MoDaCo ROMS but for some reason has ceased to work and causes bootloops if you bake it in - shame...
I've no coding experience, but willing to test stuff out anytime.....
Dayz xx
i think what Wysie is trying to do is stimulate discussion about a different way to do A2SD.
He, and a lot of people believe (including myself) that running apps from the sd makes them slower, so what he wants is like WM where when you install an app it gives you an option to install it either onthe device or on the sd. So you can choose to install your most used and apps that require speed the most on your device...
And if this isnt thread development where the hell should he have posted it? It certainly is development if you ask me. he is thinking of ways to develop a better A2SD.
Seems like unionfs + some kind of app to manage which apps live where might work. This would require kernel support, however. You would set up /data/app and /data/app-private as union mounts of (say) /data/app-internal with /sdcard/app and /data/app-private-internal with /sdcard/app-private. You would then want a custom app management tool to move things to the appropriate places.
Nice initative Wysie.
My suggestions are as follows:
Use a different mount point, not inside any of the other file systems.
Like /apps2sd, this makes it alot easier to handle in the recovery realm (which is what I care about).
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Ext filesystem is mounted on /apps2sd on boot.
New installs of apps are done in /data/app like normally. /data/app is not symlinked to the apps2sd directory like it is today.
If a user want a app to be stored on apps2sd instead of in /data/app a management app can just move the .apk from /data/app to /apps2sd and set up a symlink it up into /data/app again.
Simple demonstration:
Initial state, two apps installed normally:
/data/app:
SomeApp.apk
SomeOtherApp.apk
/apps2sd
<empty>
Now the user moves SomeApp to apps2sd:
/data/app
SomeApp.apk -> /apps2sd/SomeApp.apk (symlink)
SomeOtherApp.apk
/apps2sd
SomeApp.apk
If this is possible, i.e. making sure that Android doesn't bork on symlinked apps (can't see why it would, but best to make sure). This is clean simple way handle it. It gives more control on what apps are stored where, better handling of ext stuff in recovery.
Also writing scripts/apps to facilitate this is trivial since it's so simple.
What do you think? Want input especially from ROM makers.
packetlss said:
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Click to expand...
Click to collapse
Okay, that's better than my idea, assuming it works. One disadvantage is that removing the SD card breaks all the links. You could conceivably swap cards with the unionfs approach, as long as you were not using any widgets or launcher icons which rely on APKs in the SD storage, and had a way to properly unmount the disk. Might not be worth the complexity, though.
I think the biggest issue is with regards to removal of SD card. You guys have made it way more complex than I thought, thanks for enlightening/sharing !
I thought it could be as simple as simply modifying the Apps2SD script to allow apps to exist on both the sdcard and the phone, and then modifying the Package Manager to prompt the user on where to install to. Keep those thoughts/opinions coming!
If it wasn't for my school work and lousy time management i'd definitely start doing something. For now, it's good enough if all the necessary knowledge is shared here, then some dev can actually start work and put it on github or something for the rest of the community to contribute!
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
arctu said:
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
Click to expand...
Click to collapse
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
I tried to simlink apk's but for some reason it didn't work, simlink the app directory works.
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
rj3005 said:
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
Click to expand...
Click to collapse
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
Again, this is the problem. A general technique suitable for XDA-type applications must require only root or changes to GPL code. You can't touch the framework, which can (and does) have proprietary branches.
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
i would say that we have no choice but to implement it without considering those groups. however, i do suggest that we should make the implementation compatible, just that, on modded frameworks like cyan, it works to the fullest.
olearyp said:
unionfs
Click to expand...
Click to collapse
Everything old is new again. Oh well.
olearyp said:
Everything old is new again. Oh well.
Click to expand...
Click to collapse
Unionfs is not available for android devices without kernel sources.
Concerning ported rom, I am not sure the package installer get modified by vendors. So it may be possible to implement the changes done to aosp code using baksmali.
So my two cents are:
- modify AOSP sources to have android lookup at /sd/app for apps
- modify package installer to have it asks where to install apps
Sure the removing of sdcard problem is still there. I don't know how we can ever handle a straight manual remove of it. It implies big modifications to AOSP sources to have the system aware of missing applications that have existing home shortcuts or widgets, so it "hides" them until app is back...
Anyway we can start implementing the functionality and look after for that sdcard removal problem.
I've been thinking of doing this for a while, has any progress been made?
I like the idea of modifying pm to prompt for the install location, I was thinking of just writing an app to manage that (but probably would be a good idea to have both).
If progress has been made, great, if not, I may start a fork of CM5's vendor tree for this.
Lox_Dev said:
Unionfs is not available for android devices without kernel sources.
Click to expand...
Click to collapse
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
olearyp said:
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
Click to expand...
Click to collapse
Well.. it is not the case in real life.... For eg, acer Liquid kernel sources they acer provided is unusable.
Just a clue for aosp source modification:
services/java/com/android/server/PackageManagerService.java:frameworks/base/ Log.d(TAG, "Scanning app dir " + dir

Searched and NOTHING!

Hey guys, so I searched and search, using the search function as described in the forum rules, and couldn't come across anything with this nature, so if anyone has an urge to help out a noob I would really appreciate it!
So I downloaded the new Android Desire V4 rom, someone told me there were instructions in the download, which there were...they read as follows...
set mtype 2524
set ramaddr 0x20000000
set ramsize 0x0fc00000
set KERNEL zImage
set initrd initrd.gz
set initrd_offset 0x00a00000
set cmdline ""
boot
So my question is, again, um how do I do any of that! LOL Those look like a list of things I am supposed to do as opposed to actual instructions on how to do them LOL
If I run HaRet, it boots, but from my understanding I need to do the above list to make it functioning to it's (current) fullest potential?
Thanks for any assists!
i haven't tried android, not interested in kids play things, but that to me lookslike a list of setup commands, , sure they aren't supposed to go in an initialization file of some kind?
thats the startup txt details, and all you hav to do is copy it all to ur sd root and thats it its honestly not worth it at the min unless u just gonna play about for a bit
hmm
samsamuel said:
i haven't tried android, not interested in kids play things, but that to me lookslike a list of setup commands, , sure they aren't supposed to go in an initialization file of some kind?
Click to expand...
Click to collapse
Probably, but I don't even know what that means! LOL
I am like a super noob..haha.
I guess I am asking specifically what you would do, every step, to do the list of setup commands.
1. How do I change to those values, like which part of the phone I go into.
2. If they need to be installed, how exactly, specifically do I install them.
I am basically looking for full instructions. For example if I were teaching someone to watch a DVD who has never used a DVD/movie playing device before, I wouldn't just say "put it in and watch it." I would say. "This is the power button. Click that to turn the device on. This is the open tray button, click this, and place the DVD shiny/mirror side down flat. Click the open tray button again to close the tray. Once closed it should automatically play, if not click the button with the sideways triangle on it to start the movie."
Like that is how nooby I am with this stuff LOL..but not stupid enough to change something I shouldn't, screw something up. If the instructions are there, I got it.
Demon_man said:
thats the startup txt details, and all you hav to do is copy it all to ur sd root and thats it its honestly not worth it at the min unless u just gonna play about for a bit
Click to expand...
Click to collapse
So I don't have to do anything? I have booted Android Desire V4 rom about 22 times so far, and every single time it is stuck in fast forward mode, does not give me the sim option like in the instructions on the website to download the file, and is generally the exact opposite of what everyone is claiming it is/doing.
So I would assume I am missing some key crucial steps no? Also My radio rom is fine, I reformatted my SD Card, it's fresh and all files are on the root of the card. From the sounds of it, you have to do something with the zImage (from what I have read), and something else... this is why I am confused.
as far as i'm aware there are still a few issues where certain models cant run it properly? and isn't there something about there being a few different digitizers, and it only works on some? (that might not be an issue anymore, i've not been keeping up)
i tried android quite a few times on my previous device (htc kaiser). i believe nearly the same concepts apply to the HD2 at the current stage of android development for the HD2.
facts:
1. you should know that android's files are to be kept on the sd card according to the instructions (more details here: http://forum.xda-developers.com/showthread.php?t=719646)
2. you should know that your windows and any settings made under windows will remain INTACT. this is because android, being in the storage card, is like an independent operating system.
3. point 2 above implies that any settings specific to windows or specifically made in the windows system settings (etc) have NO IMPACT on android. so no need to ask:
1. How do I change to those values, like which part of the phone I go into.
Click to expand...
Click to collapse
4. the only things important to android are the radio ROM version and MAYBE the (Hard)SPL version.
5. android is spun into action using "haret". haret is a little program that is started from windows but it essentially kicks out windows (temporarily) and tricks the phone into booting android from the sd card.
so from all of the above points, we can conclude that any and all configurations for android must be made in some text files. this text file must be placed according to the instructions somewhere along side haret and the rest of the android files on the sd card. this should answer:
2. If they need to be installed, how exactly, specifically do I install them.
Click to expand...
Click to collapse
this text file, as suggested by demon_man in post 3 in this thread is the "startup.txt". another name for startup.txt is "default.txt". these files are the same, except that haret pre-selects "default.txt" as your startup script when you launch haret. this saves you the step of manually selecting a particular startup file (you can have a bunch of startup files with different settings in each to experiment and you can name them ANYTHING). so after experimenting, you should arrive at a startup file containing configurations that work well for you. you can then name this file as "default.txt" and you can also optionally delete all the other startup files you created while you were experimenting.
i hope the above gives you some idea of what to do. if i had tried android on the HD2 for myself and if i had personally done more research of android on the HD2, i would have certainly given you some links of material that i am CERTAIN already exists, if you fancy searching just a little bit. being a noob is no excuse, because "search" is the FIRST forum rule. and just saying that you searched without posting some example keywords of what you searched for sounds "fishy", so not sure you searched well
i have written the above to help you build your concept, but we would all applaud for you (yay!) if you post in the appropriate threads for android and android tutorials from now on. i doubt you will need to post more because what i have tried to detail for you above should be a very solid foundation for you to understand how the wonderful people here at xda have gotten android to work on devices it was never released for.

[Q] [REQ] Andoird on I8910 OmniaHD??

can someone tell me if is possible port Android on this amazing device??
someone is working on this???
I wuold like a lot if someone port Andoid on oHD!!!
lukas_ita said:
can someone tell me if is possible port Android on this amazing device??
someone is working on this???
I wuold like a lot if someone port Andoid on oHD!!!
Click to expand...
Click to collapse
I was working on it for a long time. Unfortunately it is impossible, due to limited bootloader space (not enough for an android one) and no recovery partition. Also it would need a totally new partition layout (as it only has two accessable internal and one external drive, so no cache, recovery access, nor swap.
And also do not forget about the hardware incompatibility. Even if we manage to boot it, you will hardly be able to even make a phone call. Not to say use WiFi, or GPS, BT, or anything.
hi i joined because of some interest in this,
first of all let met tell you that i own a samsoung i8320 (vodafone h1).
this in some way helps because we now have a 'working' limo kernel, in my opinion it might help us out here.
the problem i have is that i never ever yet have been able to do 'any of the work here under' - the fact that i know howto doesn't make me capable of doing, (its like the fact that you know a plain fly's because of big wings and an engine, doesn't make you a pilot)
---------
the H1 uses a rather standard linux kernel as far as i can tell from the source could, though i havn't been able to run it inside quemu yet..
some guys allready interested in porting android say that they got android running but without functions like phone or wifi. this is because thay used an android kernel rather than the samsung one.
step 1:
so what if you would strip the samsung rom from all 'userland' software, keeping only the kernel, its drivers and busybox stuf.
creating a root shell only - you may even be able to make it mount as /boot rather than /
step 2:
now ad ad adtional filesystem on the internal phone memory or an external sdcard ... format it as you like (ext3 with noadtime could do, but other options are also availible).
this should now be where the remaining of the android rom should be. you could now always update most of your your android and apps exept for your linux kernel or drivers. without reflashing. this idea is largely based on apps-2-sd so we all know its been done before.
fonix232 said:
I was working on it for a long time. Unfortunately it is impossible, due to limited bootloader space (not enough for an android one) and no recovery partition. Also it would need a totally new partition layout (as it only has two accessable internal and one external drive, so no cache, recovery access, nor swap.
And also do not forget about the hardware incompatibility. Even if we manage to boot it, you will hardly be able to even make a phone call. Not to say use WiFi, or GPS, BT, or anything.
Click to expand...
Click to collapse
The i8910 community is great....this phone is great...a porting of android on this phone wuold mean a great number of donations!
cannot you use E\ (massmemory...8Gb or 16Gb) like partition?

[Q] Parallel File Systems / ROM hacks

I had an odd thought. A lot of us like to test out other ROMs, but NANDROID backups and restores result in significant downtime. I'm curious if it would be possible to nest a fully installed ROM inside a subdirectory of the current running one and then swap them out in Recovery by rewriting the pertinent directory paths.
Obviously, there would be a requirement that both ROMs be compatible with the file system in question (Ext4 , etc.)
I mention all this because I would like to be able to quickly boot into Cyanogen 7 every now and then for the bluetooth stack and some of the other features here and there, but my daily driver is Bionix.
Obviously, a nice chunk of space would be "wasted" having duplicate copies of lots of files for apps and such (in addition to the space used having a second ROM) but I think the Galaxy S series NAND space is sufficient to try something like this.
Holy crap that's an amazing idea!!!
Theres already a way to do this its called dual booting and uses your internal memory.
Complicated though.
Are there any guides?
Yes, their in the android section (lol)
http://forum.xda-developers.com/showthread.php?t=847423
work in progress.....close to alpha release
Aww I thought it could already be readily available .
Nice though can't wait .
edit nevermind

cifs.ko module / Busybox / mounting CIFS shares

Hello all. In the last 24 hours I've racked my head against a wall and I can't seem to get past this. So some pointers would be very welcome.
Backstory - Been doing backups of Titanium Backup onto my Nexus 9 (16GB internal storage) and I'm running into problems with running out of storage space. So I thought I'd look into doing a CIFS share mountpoint to my tablet and backup directly to the CIFS shares on my FreeNAS box. I figure a couple TB of storage is enough to store my Titanium Backups.
So first I read about CIFS Manager. Seems it may be discontinued or not functional on Lollipop.
Then I read about Busybox. Very cool, I think I'd marry Busybox if it was a woman. It seems so amazing I bought the Busybox Pro version.
So I tried to mount the CIFS/SMB share but I keep getting the dreaded "no device found" which means the cifs.ko isn't loaded. Apparently it's not in OS by default, so I need to compile it. (I'm not against someone giving me the .ko file, but I'd rather learn how to fish for myself than expect someone to give me a fish when I'm hungry) I have no clue how to compile it or even where to start to get a resemblance of the necessary steps. My experience is mostly Windows and FreeBSD, with only enough knowledge of linux to be very dangerous. I've tried searching all over for some kind of guide, pointers on what files I need to get, where to go to compile, etc but there seems to be nobody out there with any kind of good guide, even an outdated one I could use to fill in the blanks. I was hoping to put together a fairly detailed guide that includes steps on how to compile the cifs.ko yourself from source as well as mount your share on the device for whatever purposes you desire. But I'm finding that there is basically no info online on how to do this, where the source is, how to compile it, etc. If you know how to do this and are willing to help me write the guide (I've written quite a few articles on FreeNAS and ZFS) I'd be more than happy to give you some credit. I have no doubt lots of people will use the document once it is created.
Alternatively I considered doing the same with NFS but again I'd need to compile the nfs.ko module, so I'm stuck at the same point there.
Anyone have any pointers on how to do this? Or, anyone have any other options that will work just as well that allow me to not have to store the actual titanium backup files locally?
About the only thing I can find is someone saying that you need a Linux VM, the kernel sources, sdk, some knowledge in unix, and patience. But hell, I don't know if by saying "kernel sources" they are talking about the kernel source for the Linux VM or the Android OS I'm running (or both), if the SDK is referring to the Android SDK or not, etc.
Thanks in advance!
Joshy8 said:
Or, anyone have any other options that will work just as well that allow me to not have to store the actual titanium backup files locally?
Click to expand...
Click to collapse
I was in the same boat as you a few years back. Basically I would root, find a kernel that had the CIFS module, then use CIFS Manager to mount the shares. I would also use rsync & busybox. This stuff is tricky. The command to get Android to mount the shares, the CIFS module and kernel always has to be up to date, changes in busybox, etc.. I dreaded Android system updates. It starts to feel like a Rube Goldberg machine.
I started using an app called FolderSync (there's a paid version, too) and never looked back. It works quietly in the background and have never had any problem with it. It's one of the best apps on Android.
I do thank you for the advice, but that's how I've been doing backups for several years. I bought it back when the original Droid phone came out.
However in this case, since my tablet has only 16GB of internal memory and you can't easily have permanently attached external storage I'm forced to come up with an alternative of some kind.
I have had some problems lately with FolderSync. Not sure exactly what the problem is, but FolderSync seems to have issues from time to time and it gets stuck on random files and never finishes, even if left to complete for several days. I've had this issue randomly on 3 different devices, and one of my friends that also uses FolderSync has had the same issue on his. So I'm pretty sure there's a bug of some kind in FolderSync that sometimes breaks it.
Anyway, since my tablet has only 16GB of internal memory and you can't easily have permanently attached external storage I'm forced to come up with an alternative where the data is never actually stored on the device itself. :/
I know this isn't the answer you were looking for, but have you seen these:
http://www.meenova.com/st/p/mrg2.html
It's the closest thing I've found to convenient usable external storage.
Sent from my Nexus 9
The Fire-Ice kernel (http://forum.xda-developers.com/nexus-9/orig-development/kernel-fire-ice-t2930451) supports CIFS. I use it to connect to my SAMBA linux server. I also did the following, not sure if both of these are necessary: set SELinux to permissive with SELinux Mode Changer, and use the "patched" version of CIFS Manager (found on this forum).
I'm still hoping somebody will just write or cross-compile a FUSE module (like SMBnetFS) that works on all rooted devices, so we don't have to rely on custom kernels/modules anymore...
Since you asked for alternatives, you can also just get an OTG cable and hook up a USB stick or external HD to your phone (needs root and an app like StickMount).
Thanks for the reply. Been a bit busy with life stuff and just finally got to sit back down and look at this again.
I agree that a FUSE module would be useful for something like this. I don't have a need for high performance with regards to this problem, so a FUSE module would seem very appropriate.
I do have an OTG cable and I do have a 64GB thumbdrive I can use. I was just hoping for something that was a little non-obtrusive and passive so that I'm not actively having to be involved in the backup process itself. As soon as someone in the meat-world has to take active steps to make a backup every time, that's when backups typically stop happening, and then the next thing that happens is data loss. So I'm trying to remove myself from the equation as much as possible.

Categories

Resources