Computing desk
< August 2	<< Jul \| August \| Sep >>	August 4 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 3[edit]

Android tablets[edit]

I'm considering purchasing a tablet. I don't have many particular requirements, but there is one thing I'm looking for. The primary use is going to be for watching video files and I want to do that with the least amount of hassle. There are ways to upload a video file onto my iPhone, say, but going via iTunes is a pain the ass, both in terms of time and effort. What I want is the ability to plug in a thumbdrive with videos on it, be able to access them directly on the device, and play them - either straight from the drive or via some on-tablet application that lets me upload the files to the device. Apple products can't do that; they're closed. I assume some versions of Surface do it since they're using Windows, but the price point is so high I'm not really considering them. Can Android devices do what I'm looking for? Product descriptions sometimes mention that they're "expandable", but it's not clear to me exactly what that means; they often have some specific amount listed which seems counter-intuitive if it allowed me to swap in a thumbdrive at will. Matt Deres (talk) 02:31, 3 August 2017 (UTC)[reply]

Some can. Most likely if the device has a USB type A port (not mini or micro!) it can. If it doesn't have such a port, it probably can with an appropriate USB OTG adapter. If you get a USB memory stick with a USB type C port and a tablet with type C then I think the answer is most can. (Even phones normally can.) Some manufacturers may choose to disable it for whatever reason though. Also, the device may not support ExFAT or NTFS so you may need to format it with FAT32 and suffer the limitations therefore (like a lack of support for files bigger than 4 GiB) or some supported Linux filesystem and suffer the compatibility issues with Windows and Mac computers. Of course you will also need a player capable of supporting the files with the hardware available. By now, I think even the cheapest of cheap devices will probably work with most H264 1080P videos, but don't quote me on that, and they may not support HEVC or resolutions higher than 1080P. BTW, I'm pretty sure most Windows tablets support this not just Surface ones. (Although again HEVC and beyond 1080P file support could be an issue.) Nil Einne (talk) 04:32, 3 August 2017 (UTC)[reply]

Oh forgot to mention, expandable most likely means it supports a microSD card. From my experience the values they put are often questionable. Some for example say they only support up to 32 GiB but what they actually mean is they don't support ExFAT so if you have an SDXC you need to have it FAT32 (or whatever formatted). I suspect some do support ExFAT and just put it since someone told them to. Some put values like 64GiB or 128GiB but again, I think in most cases they aren't actually limited to that capacity. (Although devices with more than 128GiB are so rare this isn't often tested.) That said IIRC when I did look in to this, I did come across at least one person who seemed to know what they are doing and said they had some device which even after formatting etc still wasn't able to use a large microSD card, I think possibly 64GiB so it's probably not wise to assume all modern devices definitely support all SD cards when properly formatted. Nil Einne (talk) 04:41, 3 August 2017 (UTC)[reply]

Thank you for the explanation, Nil; in particular I was unaware of the OTG option. Much appreciated. Matt Deres (talk) 12:41, 4 August 2017 (UTC)[reply]

I think most, but not all, android tablets will support OTG. It's worth looking up before you place an order. Then grab a cheap two-headed flash-drive like this one.

ApLundell (talk) 14:18, 4 August 2017 (UTC)[reply]

.apk[edit]

Could you refer me to a good ‘skeleton’ reviewer please? 43.245.123.39 (talk) 16:22, 3 August 2017 (UTC)[reply]

I'm afraid I don't understand what this question means. So far as I know "Skeleton reviewer" is not a type of app. If you could drescribe in more details what you're trying to do we may be able to help. ApLundell (talk) 14:16, 4 August 2017 (UTC)[reply]

A reliable [skeleton scanner] please. 103.67.156.67 (talk) 07:14, 5 August 2017 (UTC)[reply]

Cell phones do not produce Xrays. These apps are at best simulations, at worst scams.-gadfium 07:17, 5 August 2017 (UTC)[reply]

Smart Phone Android version[edit]

I’ve recently updated mine. This version notifies when the battery ‘discharges’ to 30%, but doesn’t when ‘recharging’. Any idea why?

Also, I would like to change the markings of the ‘‘charging’’ and ‘‘discharging’’, what do I do?

43.245.123.39 (talk) 16:22, 3 August 2017 (UTC)[reply]

Linux: how are calls to kernel private methods prevented?[edit]

If a Linux program knows the specific kernel build it's running on, what's to stop it from escalating privilege by executing a subroutine jump to a private method in kernel space, or to an address that's at the middle of a method and right after the security checks it wants to bypass? Neon Merlin 22:34, 3 August 2017 (UTC)[reply]

Userspace processes cannot set their PC to the kernel's code segment, because those pages are not mapped for them, and trying to do so would cause a SEGV. Userpace processes don't call (in the usual C way) the public API of the kernel either - they must use the syscall mechanism, which effectively causes a processor exception (whether an interrupt, a special instruction, or in weird cases a deliberate special kind of SEGV) which the kernel handles. -- Finlay McWalter··–·Talk 22:48, 3 August 2017 (UTC)[reply]

In other words, memory protection is an integral element of the hardware- and software- security policy implementation on Linux, and most of the other computer systems in common use today. An executable program does not manage its own memory - it must ask the operating system to manage memory on its behalf. The operating system protects itself from illegal memory access in many ways. One feature of Linux, and many other modern operating systems, is kernel virtual memory randomization. This means that only privileged code even knows where the protected, sensitive program text is - your user program wouldn't even know where to jump. A totally separate, distinct security feature is hardware-assisted page mapping. For example, Intel CPUs use Intel-VT, among its instruction set technologies, to restrict management and access to the memory mapping. Even if a malicious program guessed correctly where it wanted to jump, it would not have permission to jump to that address. This is an example of defense in depth - two unrelated technologies must both be broken in order for the malware to break the system.

Obviously, if a user program did find a way to do both tasks - (1) to correctly know where sensitive executable code is mapped; and (2) to be able to jump the program counter to that address - this would constitute a privilege violation, and would ultimately be a "software bug." Bugs of this specific nature are uncommon in Linux, but at least a few have historically been discovered.

For example, last week, an attack was published as CVE-2017-11472, satisfying "step 1" of this two-step attack. If a hypothetical attacker also knew how to make Step 2 work on a system that is vulnerable to Step 1, there would be a true privilege-escalation security hole in need of an urgent patch.

Nimur (talk) 23:02, 3 August 2017 (UTC)[reply]

So why does the top of the address space still need to be reserved for kernel use? I.e. why can't anything be mmap'd to make `(void *)(-1)` a valid address? Neon Merlin 19:47, 6 August 2017 (UTC)[reply]

Memory maps are conventions used throughout the operating system. If you want to use operating system services, you have to conform to the system's conventions. If you want to manage memory differently, you may do so - but you won't be compatible with a lot of other really important software - things like your EFI device drivers, let alone any reasonable modern general purpose operating system.

mmap(2), in particular, uses the user-provided address as a hint on almost all implementations. MAP_FIXED will fail on many (most?) POSIX-y platforms.

Here are some useful whitepapers -

Intel's Tour of the UEFI Memory Map
Linux Kernel's documentation for the x86_64 memory map
Perhaps the best resource - Understanding Process Address Space, from Mel Gorman's excellent free textbook, Understanding the Linux Virtual Memory Manager (PDF version). That book was current up to kernel-2.6, which is amazingly now over a decade old - but the knowledge you gain will be relevant on newer linux, and will translate to almost any other reasonable operating system, *nix-like or otherwise.

It is possible to write your own operating system - in some advanced computer engineering classes, you might do so on a simple microcontroller - and when you do so, you have the flexibility to do anything you want to memory.

Nimur (talk) 00:52, 8 August 2017 (UTC)[reply]