Jump to content

silversolver

Members
  • Content Count

    481
  • Joined

  • Last visited

  • Days Won

    7

silversolver last won the day on January 3

silversolver had the most liked content!

Community Reputation

607 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Sean McCreary I believe tying the keyboard and screen backlight together is exactly what LOS did in the build I'm using on my D4. I consider it a perfectly acceptable solution.
  2. I'm pretty sure that AVIdemux is a graphical frontend for FFmpeg. "Normal people" need a GUI these days. Then there's me....I'm perfectly capable of using the command line, but too lazy. ;)
  3. Personally I care nothing for 5G. I see absolutely no reason why we need to have 5 bazillion gigabits per nanosecond streaming OTA. 3G is plenty for me, and 4G is far overkill. In what use case scenario is 25mbps per device not enough? It's like processor power......we reached the limits of what is useful to most people a long time ago.
  4. I am used to LineageOS (using it to post this) and as such am unused to some of the limitations in stock. As for concatenating videos, AVIdemux is free, easy, and seamless. Open the first file, drop the others in afterward in order, then save them all in one file. I have done it many times. It is a useful tool for a lot of things, and I'm pretty sure it is also available for Linux. Just set everything to copy and the output has no quality loss and no issues.
  5. Try to find someone who has one somewhere nearby you so you can try it first, perhaps? There's a lot of people in this forum all over the world, and more if you count the lurkers ;)
  6. I think the assumption is slightly wrong. @Erik said "70% of all preorders," which in my reading, all preorders includes those already fulfilled, so I'd say this will probably put fulfillment at 90-95% of all preorders. Unfortunately, it means that I won't likely get mine for another month or so, as I didn't pay until nearly the end of November. Oh well. Droid 4 still working. Posting with it, as usual. :) I'm glad Verizonk chickened out on pulling the plug at the end of the year though, because then I'd have had to switch to the potty.....er, PRIV. ;)
  7. Most video recording programs are clever enough to work around the 4GB limitation, since it is very old yet still very common. As mentioned previously, if you don't need interoperability with Micro$oft's operating systems, EXT3/4 would be a good choice. Incidentally, software exists to make Micro$oft's OSes read EXT filesystems. I used it a long time ago and it worked fine. I can't remember to save my life why it mattered, but it did at the time.....I almost think I just wanted to know if it could be done. It could. ;)
  8. If I talked to my friend about my hurting leg and they recorded it, I fail to see what a friend would do with such a recording that would affect my insurance. On the other hand, Google is known to be evil, so I don't give them any information at all, precisely because I don't trust them to be ethical with it, albeit that's somewhat off topic here. Farcebook is very much the same way, so about the only thing they know about me is that I like driving through the woods in weird old cars.....hardly a monetizable fact. :) Certainly large corporations can and do find ways to monetize information about users, but recording phone conversations has little to nothing to do with that, hence why the very real problem you describe is an internet-era problem. Speak of user-based pricing, did you know that some online merchants show higher prices to people browsing with more expensive devices? User-based pricing is already a thing.
  9. Honestly, the only party I find it upsetting that they might be recording me is the government. If I'm talking to someone and don't want them to have a recording of me saying something, I shouldn't say it, should I? It's like when facebook went to timeline view and people complained that their private messages were made public.....only they weren't. People just couldn't fathom that they actually said those things in public, but they did. If I'm talking to someone and they choose to record it, so be it. I do my best to only say things that are repeatable, and not tell profound secrets on the phone. The government is just eavesdropping on everyone because they can, and it's none of their stinking business. That I mind.
  10. I'm well aware that many governments feel the need to babysit everyone, and I don't feel that is lucky. Freeing people from the need to take personal responsibility for their actions by removing choices doesn't make society better over time because it makes people less competent to self-manage over time, and then even more choices have to be removed, and then people become even less competent to self-manage, and then.....you get the idea. Certainly in the case of the phones the default settings, and the way it operates out of the box should comply with every conceivable mandate. However, removing the ability of the user to change the way it operates because they might break a law by doing so is treating everyone like children, and I resent that.
  11. I must be very bad at explaining this LOL! I wasn't using "real" RAM to denote physical RAM; of course, it has what it has in that regard. (Has anyone ever soldered in more on a Droid 4? 🙂I was using it to denote RAM available for use without any trickery involved. A word about swapping might help here. Swapping is an old concept where the kernel takes a page of RAM, dumps it somewhere else called a swapspace, and then frees the RAM page. If/when that data is needed later, it will copy it back, often after swapping off another page to make room. It is cumbersome to the kernel and slows things considerably in some cases, and is really only useful in situations where the physical RAM is not really enough to get the job done; it is a workaround for a low RAM configuration. ZRAM hijacks that kernel function. ZRAM creates a swapspace which it shows to the kernel as available so it will feed it RAM pages to stash for later. It compresses this data before storing it in an allocated area of physical RAM. This trickery allows the cramming of more stuff into the physical RAM. However, because ZRAM is still stored in RAM, as the amount of stuff stored in ZRAM increases, the amount of RAM accessible outside of ZRAM's trickery necessarily decreases; by a lesser amount than the ZRAM grew, if the data in ZRAM is compressible, but this means that over time, less and less native, untricked RAM is available. The degree to which ZRAM is advantageous is also directly proportional to the compressibility of the data it is storing. Filesystem swap on SD has none of these limitations. Because it is stored outside of RAM, data swapped there doesn't compete with the native RAM at all, leaving it all still freely available for use by whatever needs it, and it also doesn't matter if the data is compressible or not, since compression is not involved. You mentioned swapping to disk, but that is exactly what the kernel believes it IS doing when ZRAM is used. True, RAM is much faster than SD, but the compressing and decompressing of the data takes CPU cycles, which may or may not end up being faster than I/O in any given circumstance, depending on CPU speed, load and I/O performance. Also, in their default state, every Android ROM I've ever seen had no disk swap available at all (not counting the ZRAM virtual disk.) If they ran out of RAM, they ran out of RAM, and there was nothing to do for it but kill processes. Adding disk swap has to be done manually, first by creating the swapspace, and then by using a terminal command to activate it after every boot, or adding the command to the startup script. In my case I have a fast SD, a relatively slow CPU, and a tendency to load the CPU heavily as a result. For me, the performance of ZRAM and SD swapping on my device and in my use cases are very similar. Both would be considered very slow by normal people LOL. I choose SD over ZRAM because on my device it is much more stable, and occasionally it is actually a little faster, again because all of the RAM is accessible without trickery. Hopefully this explains the things that were puzzling you. 🙂
  12. What I was going to say. :) You got there first.
  13. I only just saw this. Internal storage is essentially the internal SD. ZRAM uses RAM, not internal storage. Performance in my use case is comparable. The SD medium is definitely slower, but there's no CPU load and more real RAM available. The exact performance comparative between ZRAM and SD swap will depend on the use case and SD speed. My SD is fast and use case tends to have high CPU loads, so I get generally comparable performance, with the benefit being better stability.
  14. None of that was a factor in my decision-making process. I am aware of limited write cycles on SD, which is why I chose it; if I'm going to wear out a storage device, I'd rather it be the one that is easy to replace. :) I am aware that some people swap on internal storage, but I would never even consider that because of write durability. I do move the swap file around from time to time on the card to try not to burn out all the cells. Ultimately it's not a big deal to me either way. SD is relatively cheap.
×
×
  • Create New...

Important Information

Terms