| 00:40.35 | Maxdamantus | 11:17:34 < DocScrutinizer05> the shell should use pipes for stdin, stdout, stderr ;-) I'm planning since long to have different fonts or colors for stdout and stderr |
| 00:40.39 | Maxdamantus | It does. |
| 00:40.54 | Maxdamantus | You can open files over the existing fd using exec. |
| 00:40.58 | Maxdamantus | exec >foo.txt |
| 00:41.24 | Maxdamantus | That should open the file, dup2 it over the 1 fd and close the original fd. |
| 00:43.25 | Maxdamantus | (close the original fd from the open, that isâdup2 will close the original stdout fd) |
| 00:54.23 | DocScrutinizer05 | [2016-04-16 Sat 01:11:14] <Linkandzelda> that system of fg and bg is missing a crucial thing |
| 00:54.25 | DocScrutinizer05 | [2016-04-16 Sat 01:11:23] <Linkandzelda> the ability to stop output from background processes |
| 00:55.20 | DocScrutinizer05 | [2016-04-16 Sat 01:12:30] <DocScrutinizer05> yeah, linux shell lacks a means to change file handles when they are already opened [2016-04-16 Sat 01:12:49] <DocScrutinizer05> actually I guess that's linux at large |
| 00:56.01 | Maxdamantus | Ah, well those aren't part of the shell anymore. |
| 00:56.08 | Maxdamantus | except in being a child process of it. |
| 00:56.20 | DocScrutinizer05 | It evades me how this is related to a process closing own filehandles and opening them to a different destination |
| 00:57.27 | Maxdamantus | You'd probably do something involving ptrace to swap fds in that case. |
| 00:57.44 | Maxdamantus | wonders if someone's written such a tool. |
| 01:01.12 | Maxdamantus | Doesn't look like it. |
| 01:01.29 | Maxdamantus | Someone on SO basically suggests doing that manually, using gdb. |
| 01:07.11 | Maxdamantus | might write one. |
| 01:08.01 | Maxdamantus | swapfd 1234 1 >(sed 's/ //' >/tmp/fixed) |
| 01:12.18 | DocScrutinizer05 | sounds decent |
| 01:25.26 | DocScrutinizer05 | prolly a 'starting point' - at least for me if I'd try to understand how to tackle that: http://paste.opensuse.org/13602740 |
| 01:28.19 | *** join/#maemo eMHa (~mh@p54B0F662.dip0.t-ipconnect.de) |
| 01:30.36 | DocScrutinizer05 | cat /proc/2971/fd/1 already results in 'funny' effects |
| 01:32.04 | Maxdamantus | Yes, you basically need to make the other process do that (so it opens an fd belonging to the `swapfd` process) |
| 01:32.29 | Maxdamantus | When you cat it you're just duplicating that fd into a new one in the cat process. |
| 01:33.11 | DocScrutinizer05 | echo -e "date\n" >/proc/2971/fd/0 |
| 01:33.59 | DocScrutinizer05 | a process' STDOUT filehandle is a pty's input |
| 01:34.19 | DocScrutinizer05 | and vice versa |
| 01:35.11 | DocScrutinizer05 | I didn't completely wrap my mind around that yet |
| 01:35.42 | Maxdamantus | Yeah, and to change that you need to make the process open something else and overwrite that STDOUT (1) fd. |
| 01:36.04 | Maxdamantus | which requires something like ptrace. |
| 01:36.25 | Maxdamantus | The /proc/*/fd interface just lets you duplicate fds into other processes. |
| 01:36.27 | DocScrutinizer05 | just you can't make the process do that, unless you somehow insert code via GDB or sth |
| 01:36.41 | Maxdamantus | You can do it using ptrace. |
| 01:36.54 | Maxdamantus | It doesn't involve injecting code, just system calls. |
| 01:37.21 | Maxdamantus | A process does some computation, invokes a system call and repeats. |
| 01:42.01 | *** join/#maemo robotanarchy (~robotanar@x590f3146.dyn.telefonica.de) |
| 01:43.07 | DocScrutinizer05 | I would try tolocate the data structure that represents the file handle and replace its content by the content of a similar filehandle I prepared for the process |
| 01:44.04 | Maxdamantus | There is no datastructure. |
| 01:44.09 | Maxdamantus | The datastructure is in the kernel. |
| 01:44.28 | Maxdamantus | At the process level, the file handle is the integer 1. |
| 01:44.43 | DocScrutinizer05 | in shell the filehandles you see (0, 1, 2, etc) are indizes into an array of file descriptor structures |
| 01:44.53 | Maxdamantus | That's not just a shell thing. |
| 01:45.06 | Maxdamantus | If you do `write(1, "foo", 3);` in your program, it writes to whatever the `1` fd is, according to Linux. |
| 01:45.20 | Maxdamantus | If you strace a program that does that, you'll simply see exactly that code. |
| 01:45.39 | DocScrutinizer05 | in other processes the file descriptor data structures are no indexed array bit possibly static variables |
| 01:45.43 | Maxdamantus | because the program is telling the kernel to write data at some address to the file descriptor 1. |
| 01:45.58 | Maxdamantus | not "stdout", or "the file handle at some address" |
| 01:46.31 | Maxdamantus | All processes ultimately use these read/write/etc calls, which address file descriptors using integers. |
| 01:46.57 | Maxdamantus | When you use `stdout`, you're going through a `FILE *`, which is a C concept implemented by glibc. |
| 01:46.59 | DocScrutinizer05 | then the integer is an array index to a per-process table in kernel |
| 01:47.16 | Maxdamantus | so that has a datastructure, but not all processes use `FILE *`s (which use fwrite, etc) |
| 01:47.38 | Maxdamantus | Yes, but you can't practically modify that datastructure directly in the kernel. |
| 01:47.48 | DocScrutinizer05 | prolly not |
| 01:47.52 | Maxdamantus | The best way to do that would be to just make the process do the system calls that have that effect. |
| 01:47.57 | Maxdamantus | using ptrace. |
| 01:47.59 | DocScrutinizer05 | unless you are the kernel |
| 01:48.34 | DocScrutinizer05 | which is basically identical to "make process do the systemcalls" |
| 01:49.16 | DocScrutinizer05 | idly wonders if debugfs has an API for that |
| 01:50.16 | DocScrutinizer05 | so you don't do the systemcalls from process space but via debugfs |
| 01:54.06 | DocScrutinizer05 | you prolly also could try to go via /dev/kmem |
| 02:01.10 | DocScrutinizer05 | you'd need to find the address of the kernel's process descriptor data structure for the process first, I guess |
| 02:01.38 | DocScrutinizer05 | then the rest should be relatively simple |
| 02:03.03 | Maxdamantus | It wouldn't be relatively simple. |
| 02:03.08 | Maxdamantus | What would you replace it with? |
| 02:03.09 | DocScrutinizer05 | since process descriptor table is fixed length, odds are that job is relatively simple too to find the process descriptor table and the right entry for your process you want to tweak in it |
| 02:03.12 | Maxdamantus | How would you close that fd? |
| 02:03.50 | DocScrutinizer05 | I's simply swap two file descriptors, then close the old one in the donator process |
| 02:04.05 | Maxdamantus | "the donator process" |
| 02:04.17 | Maxdamantus | file descriptors belong to particular processes. |
| 02:04.33 | Maxdamantus | When the "donator process" exits, all of its file descriptors are closed. |
| 02:04.41 | DocScrutinizer05 | why? |
| 02:04.47 | Maxdamantus | Because that's how POSIX works. |
| 02:04.55 | DocScrutinizer05 | sorry that's no answer |
| 02:05.13 | Maxdamantus | when you do something like `(foo & bar) | cat`, how do you think the `cat` process knows when to stop reading? |
| 02:05.29 | DocScrutinizer05 | I don't see a POSIX rule that says "whenever there is a donator process it has closed file handles only" |
| 02:05.52 | Maxdamantus | POSIX doesn't have a concept of "donator process" so it wouldn't refer to anything as that. |
| 02:06.05 | DocScrutinizer05 | that's why it wasn't an answer |
| 02:06.22 | Maxdamantus | When any process exits, all of its file descriptors are closed. |
| 02:06.32 | Maxdamantus | and again, try to answer my question. |
| 02:06.34 | DocScrutinizer05 | sorry that's nonsense |
| 02:06.43 | Maxdamantus | It's really not. |
| 02:07.02 | DocScrutinizer05 | when all filehandles of all processes are always closed, then what the heck do we need filehandles for? |
| 02:07.30 | Maxdamantus | They're not always closed. |
| 02:07.33 | Maxdamantus | They're closed on exit. |
| 02:07.45 | DocScrutinizer05 | it's plain obvious that there exist processes with open filehandles |
| 02:07.51 | Maxdamantus | or on exec if it was opened with CLOEXEC or configured as such afterwards. |
| 02:08.09 | DocScrutinizer05 | who said "exit"?? |
| 02:08.14 | Maxdamantus | 14:06:21 < Maxdamantus> When any process exits, all of its file descriptors are closed. |
| 02:08.17 | Maxdamantus | Me. |
| 02:08.22 | DocScrutinizer05 | who cares? |
| 02:08.26 | Maxdamantus | You. |
| 02:08.29 | DocScrutinizer05 | no |
| 02:08.37 | Maxdamantus | Then what the fuck are you going on about? |
| 02:08.45 | DocScrutinizer05 | I never talked of an EXITED donator process |
| 02:08.58 | DocScrutinizer05 | au contraire |
| 02:09.15 | Maxdamantus | You were responding to my statements about what happens when a process exits as if they were incorrect. |
| 02:09.59 | DocScrutinizer05 | since when the donator process would already have exited, then how would it go to close the swapped filehandle after donating his own filehandle to the process-under-tweaking? |
| 02:10.58 | DocScrutinizer05 | sorry I missed to notice the "when exiting" in your statement |
| 02:13.29 | DocScrutinizer05 | swapfd creates and opens a filehandle, finds own process table in kernel and finds destination process' table in kernel, swaps the two file descriptors, then closes own (now swapped) filehandle |
| 02:13.55 | DocScrutinizer05 | done |
| 02:15.01 | DocScrutinizer05 | you just need to block premeptive multitasking during the whole swap process |
| 02:15.40 | DocScrutinizer05 | swapfd must not get interrupted amidst doing the swap |
| 02:16.19 | DocScrutinizer05 | prolly not even after locating the process table entries |
| 02:17.00 | DocScrutinizer05 | otherwise odds are the destination process exits meanwhile and a new process gets same table entry in process table |
| 02:17.16 | DocScrutinizer05 | would cause funny havok |
| 02:18.38 | DocScrutinizer05 | prolly swapfd's own process table entry can safely considered stable during runtime of swapfd |
| 02:21.15 | DocScrutinizer05 | so seach process table for destination process, on find do lock the multitasking, verify that the process table entry you found is still valid, write the own new file descriptor to target process table entry, re-enable multitasking, write 'old' file descriptor to own process table entry, close own file descriptor, exit |
| 02:23.41 | DocScrutinizer05 | lemme augment to make it comprehensive... |
| 02:25.48 | Maxdamantus | or you can just use ptrace to back up the process' registers, modify the ones inside the process' address space such that it will make the appropriate system calls, then restore the registers again afterwards. |
| 02:25.53 | DocScrutinizer05 | so swapfd creates own fd to new file, finds own process table entry, and in there the file descriptor, seaches process table for destination process, on find do lock the multitasking, verify that the process table entry you found is still valid, write the own new file descriptor to target process table entry, re-enable multitasking, write 'old' file descriptor to own process table entry, close own file descriptor, exit |
| 02:26.31 | Maxdamantus | Then its only dependent on a stable interface for each architecture, rather than internel assumptions about how the kernel works at any given time. |
| 02:27.48 | DocScrutinizer05 | good point, I just fail to understand how a process that already has opened a filehandle would do a systemcall to close() and open() again, without losing another systemcall you used to patch the process |
| 02:28.34 | DocScrutinizer05 | unless you divert the write() and read() systemcalls to own code that does all this |
| 02:28.50 | *** join/#maemo Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 02:28.57 | DocScrutinizer05 | and even then you need to wait until the process calls write() or read() next time |
| 02:29.07 | DocScrutinizer05 | which might be quite a while |
| 02:29.35 | DocScrutinizer05 | maybe I comletely missed to understand your concept |
| 02:30.50 | Maxdamantus | You might need to check to see if it's in the middle of a call involving the replace fd. |
| 02:31.45 | Maxdamantus | even if you didn't, it wouldn't block anyway since that old fd would be closed shortly afterwards. |
| 02:32.25 | DocScrutinizer05 | yeah, that for sure :-) An advantage of the concept I sketched is that you can safely assume that the process isn't inside a kernel function call when it gets suspended, unless it's poll() or the like |
| 02:34.42 | DocScrutinizer05 | and yes, my concept has nasty dependencies on deep knowledge about kernel data structures |
| 02:35.29 | DocScrutinizer05 | I still wonder if it could already be there waiting for us, in debugfs |
| 02:37.06 | DocScrutinizer05 | basically what forbids a filedescriptor node that's writeable, in a debug-enabled /proc/$pid/fd/${fd}_descriptor |
| 02:37.31 | DocScrutinizer05 | it's just not there because... |
| 02:38.39 | DocScrutinizer05 | in /proc/8113/fdinfo you are almost there already, just the right node missing, plus write permissions |
| 02:39.25 | DocScrutinizer05 | cat /proc/8113/fdinfo/1 |
| 02:40.04 | DocScrutinizer05 | now make that writeable and allow a "path: <filename>" as well |
| 02:41.36 | DocScrutinizer05 | I'm missing /debug/8113/fd/1* or sth like that. Just because no debugfs installed here |
| 02:43.01 | DocScrutinizer05 | mount -t debugfs none /sys/kernel/debug |
| 02:48.00 | *** join/#maemo ian_r (~ianr@c-73-92-40-9.hsd1.ca.comcast.net) |
| 02:48.15 | Maxdamantus | suspects it could be made less architecture-dependent by creating another child process that appears to do the actual system calls. |
| 02:48.55 | DocScrutinizer05 | hmm, no, doesn't look like anything I'm dreaming up is in debugfs. only stuff like /sys/kernel/debug/tracing/events/ext4/ that might or might not have something useful |
| 02:49.31 | Maxdamantus | so it will ptrace both that child (which just does the open, dup2, close) and the target process, but will swap the registers structure around so it looks like the calls are done in the other process. |
| 02:49.36 | DocScrutinizer05 | yeah, new lightweight thread |
| 02:49.49 | DocScrutinizer05 | sharing memory space |
| 02:50.36 | Maxdamantus | It doesn't need to share its address space. |
| 02:50.54 | DocScrutinizer05 | would simplify stuff, I guess |
| 02:51.15 | DocScrutinizer05 | maybe not |
| 02:51.20 | Maxdamantus | You just need to copy the registers from the new child to the target child before the system call, then from the target child to the new child after the system call. |
| 02:51.24 | DocScrutinizer05 | too tired to think that in deep |
| 02:51.56 | Maxdamantus | then you resume the new child (PTRACE_SYSEMU), so it looks like the call was made there. |
| 02:52.32 | DocScrutinizer05 | it anyway seems this _can_ get done, one way or another, but it's nontrivial and you prolly correctly say nobody implemented it yet |
| 02:52.33 | Maxdamantus | since open/dup2/close only involve inputs/outputs in the registers themselves. |
| 02:53.22 | DocScrutinizer05 | I haven't even looked into ptrace in depth yet |
| 02:53.37 | DocScrutinizer05 | I just know what it's used for |
| 02:53.43 | DocScrutinizer05 | usually :-) |
| 02:54.54 | DocScrutinizer05 | I prolly would know how to (ab)use gdb to do this FD redirection |
| 02:56.50 | DocScrutinizer05 | first I'd patch the program text to append the code doing the close() and open() stuff, then change program counter to point to that interim new code, wun it, and continue where we left regular program text, not without restoring all registers etc to their original values |
| 02:57.12 | DocScrutinizer05 | s/wun/run/ |
| 02:58.22 | DocScrutinizer05 | finally I could delete the interim code from target's programtext again |
| 03:00.04 | DocScrutinizer05 | this approach should work as long as the target process is susceptible to running under GDB monitor |
| 03:01.08 | DocScrutinizer05 | IOW as long as the tracee is ptrace-enabled |
| 03:02.18 | *** join/#maemo lxp1 (~lxp@unaffiliated/lxp) |
| 03:04.27 | DocScrutinizer05 | afaik only one tracer can get attached to a tracee at any given time |
| 03:05.08 | DocScrutinizer05 | so this excludes traced processes from the set of valid candidates for swapfd |
| 03:05.57 | DocScrutinizer05 | some nasty programs may do tricks like tracing themselves to blocj RE via gdb and the like |
| 03:06.08 | DocScrutinizer05 | iirc skype is such a nasty candidate |
| 03:06.58 | DocScrutinizer05 | anyway the ptrace approach seems sound |
| 03:07.17 | DocScrutinizer05 | regardless of the implementation details |
| 03:07.32 | DocScrutinizer05 | and yes, way more portable and generic |
| 03:10.38 | DocScrutinizer05 | you probably can just ptraqce_attach to target, close($fd); open($fd, "new/path/to/file") and detach - well you should check the filehandle options that the original open() used, I guess |
| 03:12.21 | Maxdamantus | I think the only option you might want to maintain would be CLOEXEC. |
| 03:12.29 | DocScrutinizer05 | there are some "details" to take care, like mmap() instead of open() etc |
| 03:12.32 | Maxdamantus | also, open is only one way to create an fd. |
| 03:12.41 | DocScrutinizer05 | :-D ^^^ |
| 03:13.32 | Maxdamantus | I'd expect it to actually open /proc/$swapfd/fd/$x |
| 03:13.34 | DocScrutinizer05 | I wonder if mmap is a simple fd on /proc level. prolly should be |
| 03:13.48 | Maxdamantus | so that you can do things like that first command I gave. |
| 03:13.58 | Maxdamantus | swapfd 1234 1 >(blah) |
| 03:14.14 | DocScrutinizer05 | yeah, makes sense, as long as we talk about write-only FDs |
| 03:14.17 | Maxdamantus | (`>(blah)` is some bash syntax) |
| 03:14.34 | DocScrutinizer05 | I know that syntax |
| 03:15.28 | DocScrutinizer05 | write-only would already be a great tool, much better than what we got now (zilch) :-D |
| 03:15.52 | DocScrutinizer05 | read-only is similarly simple I guess |
| 03:16.07 | DocScrutinizer05 | read-write is a tad more involved |
| 03:16.53 | DocScrutinizer05 | and with pipes like you use them in that command, positioning the write pointer gets tricky too :-) |
| 03:17.05 | Maxdamantus | fds are usually considered to be read or write anyway, not both. |
| 03:17.14 | Maxdamantus | except with files. |
| 03:17.23 | DocScrutinizer05 | yep |
| 03:17.30 | DocScrutinizer05 | of course |
| 03:18.04 | Maxdamantus | but even reading and writing to the same file fd is reasonably uncommon. |
| 03:18.32 | *** join/#maemo DocScrutinizer06 (~saturn@ppp-88-217-12-38.dynamic.mnet-online.de) |
| 03:18.38 | *** join/#maemo DocScrutinizer06 (~saturn@openmoko/engineers/joerg) |
| 03:18.41 | DocScrutinizer05 | sorry, reconnect |
| 03:18.51 | Maxdamantus | 15:18:03 < Maxdamantus> but even reading and writing to the same file fd is reasonably uncommon. |
| 03:18.54 | Maxdamantus | in case you didn't see it. |
| 03:19.04 | DocScrutinizer05 | ta |
| 03:19.21 | DocScrutinizer05 | really time for a nap |
| 03:19.23 | DocScrutinizer05 | o/ |
| 03:31.50 | *** join/#maemo ian_r1 (~ianr@c-73-92-40-9.hsd1.ca.comcast.net) |
| 03:34.47 | *** join/#maemo vahe1 (~funtoo@130.193.124.135) |
| 06:21.49 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 06:35.20 | *** join/#maemo Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 06:50.56 | *** join/#maemo Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 06:55.14 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 07:21.06 | *** join/#maemo ian_r (~ianr@c-73-92-40-9.hsd1.ca.comcast.net) |
| 07:32.31 | *** join/#maemo ian_r1 (~ianr@c-73-92-40-9.hsd1.ca.comcast.net) |
| 07:41.38 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 08:08.29 | *** join/#maemo futpib_ (~futpib@37.113.252.112) |
| 08:25.56 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 09:17.53 | *** join/#maemo M4rtinK (~M4rtinK@ip-78-102-146-111.net.upcbroadband.cz) |
| 09:49.02 | *** join/#maemo joga_ (~joga@unaffiliated/joga) |
| 09:54.42 | *** join/#maemo SpeedEvil (~quassel@tor/regular/SpeedEvil) |
| 09:56.23 | *** join/#maemo bredebid (~bredebid@es-217-129-26-160.netvisao.pt) |
| 10:18.34 | *** join/#maemo futpib (~futpib@37.113.252.112) |
| 10:28.10 | ceene | i've advanced a little bit with the port to libwa |
| 10:28.27 | ceene | it's not much, to be honest, but it's enough to see a little spot of light at the end of the tunnel |
| 10:28.34 | ceene | it now seems at least feasible |
| 10:29.04 | *** join/#maemo disco_stu_droid (~wrt54gl@190.211.82.70) |
| 10:29.08 | KotCzarny | is your api properly separated into frontend--backend ? |
| 10:29.24 | ceene | so-so |
| 10:29.37 | KotCzarny | improve that separation while you are at it? |
| 10:29.37 | ceene | when i finish the port to libwa, it'll be |
| 10:29.49 | ceene | yes, i'm basically forced to do it |
| 10:29.58 | ceene | as libwa does less things than yappari-wa |
| 10:30.06 | ceene | but it does them better |
| 10:30.06 | KotCzarny | :) |
| 10:30.17 | ceene | for example, yappari-wa was in charge of storing logs |
| 10:30.35 | ceene | so once i finish porting to libwa, there'll be nobody to store logs |
| 10:30.42 | ceene | so i'll have to do that in a separate module |
| 10:30.43 | kerio | how long is the ban, btw |
| 10:30.56 | ceene | it's a bit more work, but it'll be better in the end |
| 10:30.57 | KotCzarny | 24 to 120h |
| 10:30.59 | KotCzarny | depends |
| 10:31.04 | ceene | three months i think |
| 10:31.22 | kerio | 3 months is a little bit more than 5 days |
| 10:31.24 | ceene | nope, i think it's 60 days |
| 10:31.32 | ceene | let me check |
| 10:31.42 | KotCzarny | i guess they have different bans available |
| 10:31.46 | ceene | there was a time when they banned for 24 hours users of whatsapp plus |
| 10:31.56 | ceene | but nowadays they just ban you for good |
| 10:31.59 | KotCzarny | for different 'offenses' |
| 10:32.06 | ceene | yes |
| 10:32.12 | ceene | but i think it's almost always the longest one |
| 10:32.28 | ceene | 60 days, confirmed |
| 10:32.40 | ceene | that's the longest i've ever seen |
| 10:32.52 | KotCzarny | 60 days < 3 months |
| 10:32.59 | ceene | yes, i was mistaken |
| 10:33.01 | ceene | it's two months |
| 10:33.22 | *** join/#maemo NIN101 (~core@mail2.quitesimple.org) |
| 10:50.43 | Luke-Jr | DocScrutinizer05: what kind of video out port(s) are on the Neo900? |
| 10:51.37 | KotCzarny | isnt that a question more suiteable for #neo900 ? |
| 10:52.22 | KotCzarny | less traffic there i guess and he snoops that channels more closely |
| 10:52.52 | Luke-Jr | didn't know it existed |
| 10:53.19 | Luke-Jr | (also brushing against the channel limit) |
| 10:53.25 | KotCzarny | :) |
| 12:10.19 | Linkandzelda | DocScrutinizer05: i just took off the batlog.txt. it discharged over night and the calibration script finished. http://sprunge.us/jhYJ LMD now 1431 |
| 12:29.53 | *** join/#maemo tissi (~Valle@a88-112-2-11.elisa-laajakaista.fi) |
| 12:32.38 | *** join/#maemo Valle_ (~Valle@a88-112-2-11.elisa-laajakaista.fi) |
| 12:42.41 | *** join/#maemo l_bratch (~l_bratch@87.244.66.26) |
| 12:53.45 | *** join/#maemo vahe1 (~funtoo@130.193.124.135) |
| 12:54.51 | *** join/#maemo xorly (~xorly@ip-86-49-15-121.net.upcbroadband.cz) |
| 13:22.45 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 13:26.03 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 13:34.33 | *** join/#maemo krnlyng (~liar@83.175.90.24) |
| 13:34.43 | *** join/#maemo antranigv (~antranigv@109.75.43.22) |
| 13:34.44 | antranigv | guys |
| 13:34.47 | antranigv | sup |
| 13:34.52 | antranigv | anyone uses encfs on maemo? |
| 13:45.45 | *** join/#maemo sunshavi (~user@190.235.18.236) |
| 13:46.50 | DocScrutinizer05 | Luke-Jr: CVBS and USB |
| 13:48.10 | Luke-Jr | DocScrutinizer05: is USB video out different from standard USB host? |
| 13:49.02 | *** join/#maemo krnlyng (~liar@77.117.104.14.wireless.dyn.drei.com) |
| 13:49.07 | DocScrutinizer05 | no |
| 13:49.23 | Luke-Jr | CVBS is with the same video-out connector N900 had? |
| 13:51.21 | *** join/#maemo pcfe (~pcfe@ip5b423e30.dynamic.kabel-deutschland.de) |
| 13:51.24 | *** join/#maemo pcfe (~pcfe@redhat/pcfe) |
| 13:52.43 | DocScrutinizer05 | yes |
| 13:53.58 | Luke-Jr | DocScrutinizer05: also, am I interpreted https://my.neo900.org/index.php?id_product=1&controller=product&id_lang=1 correctly? 480 EUR is 40% of the total price of 1200 EUR? |
| 13:54.38 | DocScrutinizer05 | possible, yes |
| 13:56.30 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 13:57.41 | *** join/#maemo trumee_ (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 13:58.16 | DocScrutinizer05 | see http://neo900.org/estimate |
| 13:59.08 | *** join/#maemo phlixi (~phlixi@ppp-88-217-41-170.dynamic.mnet-online.de) |
| 14:01.25 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 14:03.21 | Luke-Jr | DocScrutinizer05: so 900-1200 EUR basically; or is the lower estimate there not including the N900 parts? |
| 14:03.38 | DocScrutinizer05 | exactly |
| 14:03.59 | Luke-Jr | which? |
| 14:04.09 | *** join/#maemo phlixi (~phlixi@ppp-88-217-41-170.dynamic.mnet-online.de) |
| 14:05.51 | DocScrutinizer05 | both |
| 14:06.35 | DocScrutinizer05 | 990 for NeoN, + ~150 for N900 |
| 14:06.43 | DocScrutinizer05 | and mounting etc |
| 14:08.32 | DocScrutinizer05 | and when we could sell 5000 (like pyra prolly does) instead of 500, we could cut a 300 off from that |
| 14:09.58 | DocScrutinizer05 | a 300 bucks that is |
| 14:14.55 | DocScrutinizer05 | apropos pyra and video-out: pyra using omap5 which supports digital video, something that omap3 doesn't |
| 14:18.01 | Luke-Jr | yeah, expected that |
| 14:19.05 | Luke-Jr | DocScrutinizer05: no ETA yet for Neo900, right? |
| 14:19.22 | Wizzup | It says Q32016 on the page |
| 14:19.28 | Luke-Jr | oh |
| 14:19.59 | DocScrutinizer05 | well, Q3 is optimistic, 2016 is honest |
| 14:20.57 | Luke-Jr | puts "No earlier than July" ⺠|
| 14:21.03 | Luke-Jr | https://www.pyra-handheld.com/wiki/index.php?title=Comparison_Chart FWIW |
| 14:21.18 | DocScrutinizer05 | if and only if we can find another few hundred customers, we're not at our feasibility level yet |
| 14:21.51 | DocScrutinizer05 | ooh nice :-) |
| 14:22.08 | ceene | isn't cooperation with the pyra guys feasible? |
| 14:22.53 | ceene | to increase component reutilization |
| 14:22.56 | DocScrutinizer05 | pyra has same touchscreen like Neo900 |
| 14:22.57 | ceene | or whatever |
| 14:23.24 | Luke-Jr | an issue for Pyra right now is min. order of 500 for each of the modems.. |
| 14:23.39 | Luke-Jr | apparently ED isn't expecting >500 of each 4G model for some reason O.o |
| 14:23.42 | ceene | that comparison chart says a different thing |
| 14:23.53 | DocScrutinizer05 | Neo900 has a 3 LEDs on side of KBD for shiftlock, modem-active and whatever |
| 14:24.52 | DocScrutinizer05 | what's "Dvorak impossible"?? |
| 14:25.40 | Luke-Jr | ceene: ? |
| 14:25.52 | Luke-Jr | DocScrutinizer05: not physically possible to align the keys for Dvorak |
| 14:25.52 | Sicelo | how much is the Pyra? |
| 14:25.59 | DocScrutinizer05 | you can have whatever keymapping you like, just the writing on keymat won't magically change, you need to blindtype or manually change the writing like on 99.99999% of other kbds |
| 14:26.13 | Luke-Jr | DocScrutinizer05: the LEDs: colour or binary? |
| 14:26.22 | DocScrutinizer05 | err? |
| 14:26.43 | Luke-Jr | DocScrutinizer05: Dvorak has the middle row far to the left of the bottom row; N900's keyboard doesn't have that many keys wide |
| 14:26.57 | DocScrutinizer05 | ok |
| 14:27.01 | Luke-Jr | [14:23:53] <DocScrutinizer05> Neo900 has a 3 LEDs on side of KBD for shiftlock, modem-active and whatever <-- are these single colour or RGB? |
| 14:27.03 | DocScrutinizer05 | now that makes sense |
| 14:27.27 | DocScrutinizer05 | actually I think they are RGB, need to look tbh |
| 14:27.44 | Linkandzelda | DocScrutinizer05: any idea about my battery log data? |
| 14:27.56 | DocScrutinizer05 | Linkandzelda: URLÃ |
| 14:28.01 | DocScrutinizer05 | ? |
| 14:28.05 | Linkandzelda | DocScrutinizer05: http://sprunge.us/jhYJ |
| 14:28.20 | Linkandzelda | calibration finished, im running it again |
| 14:28.40 | Linkandzelda | ending LMD was 1431 now instead of 16xx |
| 14:30.03 | DocScrutinizer05 | I'd say your battery has around 1100 to 1200mAh |
| 14:30.33 | DocScrutinizer05 | can't tell for sure since the discharge starts at 77%, not 100% |
| 14:31.14 | Luke-Jr | DocScrutinizer05: on the side of the kb is underneath the face when closed? or way over to the side? (which side?) |
| 14:31.16 | Linkandzelda | i see |
| 14:32.56 | antranigv | so, no one uses encfs :/ |
| 14:33.10 | DocScrutinizer05 | those 3 LEDs are probably left to kbd and not visible when kbd closed. We have a planned 2 pattern LEDs on the two device lower corners visoble from 180° to 270° around device no matter if device sits on display or back |
| 14:34.51 | DocScrutinizer05 | Luke-Jr: you know we just have the drivers to control them just like the indicator LED in N900, and we got that spacerframe that literally asks for intergratinf LEDs into it |
| 14:35.34 | DocScrutinizer05 | and visibility of indicator LED never was really great |
| 14:35.48 | Luke-Jr | DocScrutinizer05: the N900 LED is fairly well-positioned inside the N810 case BTW |
| 14:36.01 | NIN101 | antranigv: well I use luks |
| 14:36.02 | DocScrutinizer05 | yes, sort of like N810 |
| 14:36.15 | DocScrutinizer05 | but 2 corners, not 1 |
| 14:36.51 | antranigv | NIN101: on N900? o.O |
| 14:36.55 | Linkandzelda | DocScrutinizer05: so with a new battery having 1320mah, is it worth getting a fresh one? |
| 14:37.02 | NIN101 | antranigv: yes |
| 14:37.10 | DocScrutinizer05 | Linkandzelda: I'd say prolly not |
| 14:37.24 | antranigv | NIN101: any instructions? |
| 14:37.43 | NIN101 | https://n900.quitesimple.org/crypto/encrypted_home/ |
| 14:37.56 | antranigv | NIN101: love you 0_0 <3 |
| 14:38.10 | NIN101 | but it's rather difficult (annyoin /time consuming) to set up |
| 14:49.20 | antranigv | NIN101: I'll give it a try on one of my N900s |
| 14:49.53 | *** join/#maemo corvinux (~hashcore@mail.hash.si) |
| 14:49.53 | *** join/#maemo corvinux (~hashcore@unaffiliated/corvinux) |
| 14:53.11 | ceene | well, i've replaced yappari's registration code with the one on libwa |
| 14:53.22 | ceene | now, that's the easy part, because that's a pretty small module |
| 14:53.45 | ceene | but at least i've verified that the build system is working, linking and that the basics are fine |
| 14:54.16 | ceene | issue now is that i think it's mandatory now the newprotocol |
| 14:59.04 | DocScrutinizer05 | ok, on with the comparision chart |
| 14:59.51 | DocScrutinizer05 | Luke-Jr: kbd backlight: YES (RGB) |
| 15:02.02 | Luke-Jr | interesting |
| 15:02.09 | DocScrutinizer05 | Luke-Jr: Primary Operating System ... well, maemo? Devuan bare bones BSP incl factory test programs and installer wizard? |
| 15:02.51 | Luke-Jr | DocScrutinizer05: what's it ship with? website said Debian :p |
| 15:03.07 | DocScrutinizer05 | it should already say Devuan |
| 15:03.25 | DocScrutinizer05 | it however say nothing about armhf |
| 15:03.26 | Luke-Jr | cool, cuz Debian sucks now ;) |
| 15:03.42 | DocScrutinizer05 | it says BSP |
| 15:07.35 | DocScrutinizer05 | Luke-Jr: afaik pyra and Neo900 use identiacal WLAN/BT module |
| 15:07.37 | Luke-Jr | ok, so change to Devuan..? anything else? |
| 15:07.53 | KotCzarny | fremantle compatibility |
| 15:08.08 | DocScrutinizer05 | afaik this module can't do ac |
| 15:08.20 | DocScrutinizer05 | http://neo900.org/stuff/block-diagrams/neo900/neo900.html |
| 15:08.39 | Luke-Jr | DocScrutinizer05: The WiLink8? |
| 15:08.45 | DocScrutinizer05 | yup |
| 15:09.42 | Luke-Jr | wonders if he misunderstood https://pyra-handheld.com/boards/threads/gpd-is-going-to-release-an-x86-console-palmtop-computer.76762/page-27#post-1370758 |
| 15:11.02 | DocScrutinizer05 | we also use same modem module 8though Neo900 offers more variants) which means GNSS is also identical, though the Neo900 one has additional safeguard to block GNSS |
| 15:11.16 | *** join/#maemo krnlyng (~liar@77.117.104.14.wireless.dyn.drei.com) |
| 15:11.55 | DocScrutinizer05 | upgrade: Via USB in battery compartment |
| 15:12.54 | Luke-Jr | that's there already ;) |
| 15:13.09 | DocScrutinizer05 | s/USB/<a href=http://neo900.org/stuff/papers/hb.pdf>HackerBus/ |
| 15:13.17 | Luke-Jr | (although hns was curious how you managed to get a 3rd USB port on OMAP3) |
| 15:13.26 | Luke-Jr | oh |
| 15:14.50 | DocScrutinizer05 | high power draw: 4..5h |
| 15:15.23 | DocScrutinizer05 | s/hotswap/warmswap/ |
| 15:15.55 | *** join/#maemo krnlyng (~liar@77.117.104.14.wireless.dyn.drei.com) |
| 15:16.26 | DocScrutinizer05 | we don't do the hotswap anymore, too much effort and we got suspend-to-disk meanwhile so we suspend device and then swap battery. The hotswap trick is maybe still working but not officially supported/warranted |
| 15:17.05 | Luke-Jr | suspend-to-disk means it's not really Neo900-specific then? |
| 15:17.16 | DocScrutinizer05 | USB: micrio-AB |
| 15:17.59 | Luke-Jr | What is Micro-AB? O.o |
| 15:18.06 | DocScrutinizer05 | well, it's not completely Neo900 specific, though our complete hw allows to do suspend to disk, which isn't warranted for arbitrary other platforms |
| 15:20.11 | DocScrutinizer05 | NFC: <a href=http://neo900.org/stuff/papers/nfc-draft.pdf>YES</a> |
| 15:21.09 | DocScrutinizer05 | https://en.wikipedia.org/wiki/USB#/media/File:USB_Micro-AB_receptacle.svg |
| 15:22.18 | DocScrutinizer05 | that's it I guess |
| 15:23.14 | Luke-Jr | no battery life during usage claim? :P |
| 15:23.57 | DocScrutinizer05 | err |
| 15:24.28 | DocScrutinizer05 | https://pyra-handheld.com/boards/threads/gpd-is-going-to-release-an-x86-console-palmtop-computer.76762/page-27#post-1370758 chip is nonsensical, 802.11a is 5GHz and fine |
| 15:24.58 | DocScrutinizer05 | ac is multichannel and possibly even spread over both bands 2.4 and 5 iirc |
| 15:25.43 | DocScrutinizer05 | http://www.ti.com/lit/ds/symlink/wl1837mod.pdf |
| 15:26.48 | DocScrutinizer05 | WLAN Baseband Processor and RF Transceiver Support of IEEE Std 802.11a, 802.11b, 802.11g, and 802.11n 20- and 40-MHz SISO and 20-MHz 2 Ã 2 MIMO at 2.4 GHz for High Throughput: 80 Mbps (TCP), 100 Mbps (UDP) 2.4-GHz MRC Support for Extended Range and 5-GHz Diversity Capable |
| 15:27.50 | DocScrutinizer05 | ((<Luke-Jr> no battery life during usage claim? :P)) ??? |
| 15:28.29 | DocScrutinizer05 | I don''t see anything except >>Battery life (claimed, high power draw)<< |
| 15:28.34 | DocScrutinizer05 | I answered that |
| 15:29.04 | Luke-Jr | you did? |
| 15:29.08 | DocScrutinizer05 | though I think "high power draw" is not the typical usecase for Neo900 |
| 15:29.30 | Luke-Jr | oh |
| 15:29.31 | DocScrutinizer05 | we rather brag with 10 days standby |
| 15:30.36 | DocScrutinizer05 | and over 24h with light use |
| 15:31.58 | DocScrutinizer05 | wich actually brings the conceptual differneces between Neo900 and Pyra to the point like nothing else does |
| 15:32.06 | Luke-Jr | 1320mAh is correct? any idea what voltage? |
| 15:32.14 | DocScrutinizer05 | the usual |
| 15:32.18 | Luke-Jr | I guess users can put any battery in |
| 15:32.20 | DocScrutinizer05 | it's LiIon |
| 15:32.40 | DocScrutinizer05 | yes, you can connect arbitrary LiIon to HB |
| 15:32.52 | Luke-Jr | will you be shipping with any battery? |
| 15:34.36 | DocScrutinizer05 | of course! standard Bl-5J |
| 15:34.41 | DocScrutinizer05 | BL |
| 15:34.58 | DocScrutinizer05 | or compatible |
| 15:35.12 | DocScrutinizer05 | whatever we can source and is decent |
| 15:36.30 | Luke-Jr | did the side-of-kb LEDs turn out to be RGB? |
| 15:36.37 | Luke-Jr | or just the backlight? |
| 15:36.45 | DocScrutinizer05 | (nik wondered where we got the 3rd USB) well, OMAP3 has 1 OTG and 2 host USB interfaces |
| 15:37.14 | Luke-Jr | "OMAP3 has up to USB 3 ports (according to the data sheet). One is used for the OTG port. The next one needs an external controller chip and is needed for the 3G/4G module. And the third one is not available through pinmux or only if the second one is not high speed. So to my knowledge there are only 2 ports and no spare one." |
| 15:39.09 | DocScrutinizer05 | lemme check (http://neo900.org/stuff/eaglefiles/proto_v2/3-2015-09-09/Neo900_no-vectorfonts.pdf)... |
| 15:39.36 | DocScrutinizer05 | p33 sheet29 |
| 15:39.58 | DocScrutinizer05 | indicator and 2 corner LEDs |
| 15:40.13 | Luke-Jr | pokes KDE for not liking neo900.org |
| 15:41.02 | DocScrutinizer05 | next page (34) MOD 3 momocrome LEDs left to KBD |
| 15:42.02 | DocScrutinizer05 | err ooops, seems we picked a single RGB for that |
| 15:42.30 | Luke-Jr | so 1 RGB on face, and 1 RGB on left side of kb? |
| 15:42.36 | Luke-Jr | and 1 RBG kb backlight |
| 15:42.40 | DocScrutinizer05 | kbd are backlight LEDs |
| 15:42.58 | Luke-Jr | I don't know how to read schematics btw |
| 15:44.07 | DocScrutinizer05 | well, let me count: we got: indicator LED and 2 AUX (corner) LEDs which are RGB and can do patterns like N900 |
| 15:45.26 | DocScrutinizer05 | then we got 6 RGB backlight (KBD) LEDs, each individually controllable in color and brightness (N900 has 6 white LEDs for that) |
| 15:46.22 | DocScrutinizer05 | then one more RGB LED plain visible at left side of kbd |
| 15:46.38 | Luke-Jr | hm |
| 15:46.47 | DocScrutinizer05 | and one RGB privacy LED which replaces the red-only LED at camera lens |
| 15:47.05 | Luke-Jr | the 3 face LEDs are all independent, or share the same signal? |
| 15:47.19 | Luke-Jr | not sure he was aware of the red LED O.o |
| 15:47.19 | DocScrutinizer05 | which ones? |
| 15:47.23 | Luke-Jr | [15:44:07] <DocScrutinizer05> well, let me count: we got: indicator LED and 2 AUX (corner) LEDs which are RGB and can do patterns like N900 |
| 15:47.35 | DocScrutinizer05 | those are completely independant |
| 15:47.50 | DocScrutinizer05 | all our LEDs are "solitaire" |
| 15:48.10 | DocScrutinizer05 | except the display backlight white ones |
| 15:48.28 | Luke-Jr | backlight has RGB *and* white ones? |
| 15:48.33 | DocScrutinizer05 | no |
| 15:48.38 | DocScrutinizer05 | DISPLAY |
| 15:48.42 | Luke-Jr | oh |
| 15:48.54 | Luke-Jr | forgot that even existed XD |
| 15:48.58 | DocScrutinizer05 | hehe |
| 15:49.01 | buZz | hmm, there isnt a GSM-free neo900? |
| 15:49.11 | buZz | i thought it was a privacy oriented platform :D |
| 15:49.13 | DocScrutinizer05 | FSM-free? |
| 15:49.18 | Luke-Jr | ok, so Notification LEDS: 3 RGB LEDs on the face, 1 on left side of keyboard (not visible when closed) |
| 15:49.20 | DocScrutinizer05 | GSM even |
| 15:49.27 | buZz | no we always need finite state machines DocScrutinizer05 :D |
| 15:49.31 | Luke-Jr | And Keyboard Backlight: Yes (6 RGB LEDs) |
| 15:49.54 | Luke-Jr | buZz: Neo900 allows you to power off the GSM, IIRC |
| 15:50.14 | buZz | why would i buy a car with a gun, only to disable the gun |
| 15:50.19 | DocScrutinizer05 | Luke-Jr: yep when 'on the face' means 'surface'. 2 are on case corners |
| 15:50.45 | Luke-Jr | so actually on the corner, ok |
| 15:50.49 | DocScrutinizer05 | why would you buy a car? |
| 15:51.02 | buZz | yeah good point |
| 15:51.10 | Luke-Jr | so Notif LEDs: 3 RGB LEDs on the display (2 visible from the sides), 1 on left side of keyboard (not visible when closed) |
| 15:51.21 | DocScrutinizer05 | yes |
| 15:51.33 | DocScrutinizer05 | er wait |
| 15:52.20 | DocScrutinizer05 | we got N900 indicator LED plus 2 new ones in case corners (360° visoble), then we got a little one left side of kbd |
| 15:52.31 | DocScrutinizer05 | so 4 LEDs |
| 15:52.34 | Luke-Jr | right |
| 15:52.54 | DocScrutinizer05 | plus privacy LED |
| 15:53.02 | KotCzarny | buzz: because you want to hide under the radar |
| 15:53.08 | DocScrutinizer05 | the litthe formerly red light next to main camera lens |
| 15:53.19 | DocScrutinizer05 | now also RGB |
| 15:53.22 | Luke-Jr | how do I turn the red light on? O.o |
| 15:53.38 | buZz | i just dont wanna support systems i want to take no part in :) |
| 15:54.01 | DocScrutinizer05 | buZz: welcome, and thanks for the constructive contributions |
| 15:54.18 | Luke-Jr | DocScrutinizer05: oh, in the middle of the torch? |
| 15:54.32 | DocScrutinizer05 | Luke-Jr: you lost me |
| 15:54.37 | Luke-Jr | the red light |
| 15:54.42 | DocScrutinizer05 | yes |
| 15:54.58 | DocScrutinizer05 | between the 2 big white flash LEDs |
| 15:55.02 | buZz | i guess i need to stick to N800/N810 then :/ sad |
| 15:55.32 | KotCzarny | you can always desolder modem chip from n900 |
| 15:55.33 | DocScrutinizer05 | yes, a N900 successor is no valid replacement for N810 |
| 15:55.40 | DocScrutinizer05 | if that wasn't obvious yet |
| 15:55.58 | buZz | i really wish ppl would just make PDAs again :( |
| 15:56.07 | DocScrutinizer05 | when you don't like N900 you won't like Neo900 either |
| 15:56.20 | Luke-Jr | buZz: Pyra will have a modem-free model, and there's GPD Win |
| 15:56.36 | buZz | Luke-Jr: ah cool, didnt see that yet (@ modemfree) |
| 15:56.40 | DocScrutinizer05 | Neo900 can also be ordered without any modem |
| 15:56.50 | buZz | ah it can? also didnt see that |
| 15:56.55 | buZz | which is why i asked |
| 15:56.56 | DocScrutinizer05 | just don't hope for substantial savings from this |
| 15:57.04 | *** join/#maemo pagurus (~user@p548CA2F0.dip0.t-ipconnect.de) |
| 15:57.32 | buZz | if money was a motivation i wouldnt be looking at neo900/pyra at all ;) |
| 15:57.43 | DocScrutinizer05 | fair point |
| 15:57.58 | DocScrutinizer05 | buZz: Neo900 get built to order |
| 15:58.28 | Luke-Jr | DocScrutinizer05: look good now? |
| 15:58.35 | DocScrutinizer05 | lemme F5 |
| 15:58.44 | Luke-Jr | throws "Optional" on Neo900 modem |
| 15:59.03 | KotCzarny | make it 'option: modem free' |
| 15:59.42 | DocScrutinizer05 | pyra still lacks a dualtouch r-ts like Neo900 got |
| 16:00.07 | DocScrutinizer05 | Pyra uses "our" chip ;-) |
| 16:00.24 | Luke-Jr | fixes |
| 16:01.21 | Luke-Jr | now if only someone would fork Pyra and add the Neo900-exclusive features to it.. :p |
| 16:01.44 | DocScrutinizer05 | LEDs look good enough, though "on display" is a tad missleading since the corner two are in main body spacerframe |
| 16:02.12 | Luke-Jr | so when kb and display separate, they stay with the kb half? |
| 16:02.14 | DocScrutinizer05 | so basicaly above stylus and symmetrically on left side |
| 16:02.20 | DocScrutinizer05 | yes |
| 16:03.07 | DocScrutinizer05 | on the lower left and right corner/edhe of device |
| 16:03.14 | Luke-Jr | Total 5 RGB LEDs: 1 on the display; 2 on the sides; 1 on left side of keyboard (not visible when closed)<br>1 on the rear above the camera (between the flash LEDs; visible only when camera open) |
| 16:03.27 | DocScrutinizer05 | YES!! :-) |
| 16:05.25 | DocScrutinizer05 | BT is identical between Pyra and Neo |
| 16:05.39 | DocScrutinizer05 | http://www.ti.com/lit/ds/symlink/wl1837mod.pdf |
| 16:06.37 | Luke-Jr | do you have some way to get FM & NFC off that, or use a separate chip? |
| 16:06.58 | DocScrutinizer05 | 3.7V vs 4.2V -- this is just nominal vs maximal voltage of a standard LiIon cell |
| 16:07.41 | DocScrutinizer05 | we got separate chip for FM, and a very unique and versatile NFC subsystem of our own design |
| 16:07.58 | DocScrutinizer05 | designed by Werner Almesberger |
| 16:08.09 | DocScrutinizer05 | (with a little 'help' by me) |
| 16:08.10 | Luke-Jr | seems like the wl1837mod *should* have FM on the chip, but it's disabled I guess |
| 16:08.34 | DocScrutinizer05 | We'll check that |
| 16:08.55 | DocScrutinizer05 | if we can use it, we will |
| 16:09.21 | Luke-Jr | I didn't see any mainline kernel code for it at least |
| 16:09.26 | DocScrutinizer05 | unless effort is lower with a separate FM-TX/RX chip |
| 16:09.53 | Luke-Jr | that sounds likely if you already have a separate chip done |
| 16:10.00 | DocScrutinizer05 | again, check our *very* nice blockdiagram! |
| 16:10.02 | DocScrutinizer05 | ~bd |
| 16:10.03 | infobot | [bd] Bangladesh |
| 16:10.07 | Luke-Jr | lol infobot |
| 16:10.09 | DocScrutinizer05 | ~#neo900 bd |
| 16:10.09 | infobot | methinks #neo900 bd is http://neo900.org/stuff/block-diagrams/neo900/neo900.html the very fine and detailled Block Diagram, or http://talk.maemo.org/showthread.php?p=1445200#post1445200 |
| 16:10.40 | DocScrutinizer05 | makes me wonder why we don't have this chat in #neo900 instead of here where it's rather OT |
| 16:10.59 | DocScrutinizer05 | now we're almost done so nm |
| 16:11.18 | Luke-Jr | whoa, Neo900 has dual SIM? |
| 16:11.21 | ceene | which software has that diagram been made with? |
| 16:11.39 | DocScrutinizer05 | Luke-Jr: (block diagram) you get all the datasheets from there, just a mouseclick away |
| 16:11.52 | DocScrutinizer05 | Luke-Jr: yep, 'dual' SIM |
| 16:12.04 | DocScrutinizer05 | ceene: ask wpwrak |
| 16:12.14 | DocScrutinizer05 | ceene: /join #neo900 |
| 16:13.55 | DocScrutinizer05 | ceene: (dual SIM) depending on what modem might support in future with a firmware update, we might support dual SIM dual standby, for now we canonly support SIM swap. Plus you can use either of both slots as smartcard reeader muutually exclusive to modem SIM |
| 16:27.53 | *** join/#maemo corvinux (~hashcore@unaffiliated/corvinux) |
| 16:35.21 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 16:37.22 | *** join/#maemo alien2003 (~alien@230.97.121.77.pool.smart.vn.ua) |
| 16:38.40 | *** join/#maemo xray256_ (~xray256@90.213.9.29) |
| 16:40.12 | *** join/#maemo Avasz (avash@unaffiliated/avasz) |
| 16:43.48 | ceene | well, so it seems that the guy from Chat-API which implements WA protocol on PHP lives also here in Madri |
| 16:44.00 | KotCzarny | :) |
| 16:44.03 | ceene | s/Madri/Madrid |
| 16:44.15 | KotCzarny | beer coding session? |
| 16:44.37 | ceene | probably, yeah |
| 16:44.51 | ceene | he's almost studied on the same building as me |
| 16:44.53 | ceene | lol |
| 16:45.00 | ceene | he's done the shorter grade |
| 16:45.05 | KotCzarny | small world |
| 16:45.11 | ceene | but we're profession colleagues |
| 16:47.00 | *** join/#maemo Avasz (avash@xayide.jones.dk) |
| 16:47.01 | *** join/#maemo Avasz (avash@unaffiliated/avasz) |
| 17:16.28 | *** join/#maemo xray256_ (~xray256@2.223.40.173) |
| 17:50.31 | *** join/#maemo lobito1 (~lobito@190.177.210.44) |
| 17:51.06 | KotCzarny | offtopic but funny: http://i.imgur.com/pTYT70h.png |
| 18:08.15 | APic | Hi. |
| 18:08.37 | APic | is going to buy a spare N900 from a Friend. How can he securely erase all his private Data, but leave the Device flashable for me? |
| 18:09.46 | KotCzarny | just do full flash ? |
| 18:10.04 | kerio | there's a thing in settings, isn't it |
| 18:10.06 | KotCzarny | run rescueos and do dd ? |
| 18:10.14 | kerio | idk if it makes it a "secure" erase though |
| 18:10.36 | KotCzarny | unless he works in data forensics simple dd </dev/zero is enough |
| 18:11.19 | kerio | writing zeroes over the emmc is enough in any case |
| 18:13.55 | DocScrutinizer05 | ~tell apic about flashing-cmdline |
| 18:16.07 | DocScrutinizer05 | when you want to make sure, do a dd if=/dev/urandom of=/home/user/xxx; rm /home/user/xxx; dd if=/dev/urandom of=/home/user/MyDocs/xxx; rm /home/user/MyDocs/xxx |
| 18:16.32 | DocScrutinizer05 | *after* flashing |
| 18:17.03 | APic | Thanks. |
| 18:17.08 | DocScrutinizer05 | yw |
| 18:17.11 | APic | B-) |
| 18:18.13 | KotCzarny | <PROTECTED> |
| 18:23.23 | DocScrutinizer05 | you could do (ls -lR /; cat /home/user/xxx)|dd of=/home/user/xxx to speed up |
| 18:24.47 | DocScrutinizer05 | particularls for /home/user/MyDocs/xxx instead of /home/user/xxx which otherwise will take quite a while via dev/urandom |
| 18:25.28 | KotCzarny | full flash should be enough, if there are any files in mydocs remaining, just delete them |
| 18:26.47 | kerio | APic: most definetely do not do dd if=/dev/whatever of=/path/to/file without a count= |
| 18:28.00 | APic | Ok |
| 18:28.02 | APic | Thanks |
| 18:28.54 | kerio | boot from rescueOS, zero out the emmc, then flash both COMBINED and VANILLA |
| 18:31.53 | KotCzarny | DAMN |
| 18:31.58 | KotCzarny | i see hotpixel on my lappy |
| 18:31.59 | KotCzarny | :/ |
| 18:32.12 | KotCzarny | my life is ruined :/ |
| 18:32.17 | DocScrutinizer05 | kerio: yes, he shall do exactly that |
| 18:32.35 | DocScrutinizer05 | do dd until no more room on storage left |
| 18:32.48 | DocScrutinizer05 | APic: ignore that |
| 18:32.49 | KotCzarny | now that i look.. 4 of them |
| 18:33.10 | APic | Ok |
| 18:33.13 | DocScrutinizer05 | APic: what you should NOT do is "zero out the eMMC" |
| 18:33.14 | kerio | KotCzarny: rip |
| 18:34.59 | KotCzarny | wth, 6 |
| 18:35.31 | kerio | display a checkerboard pattern fullscreen |
| 18:35.41 | kerio | or a solid color i guess |
| 18:35.52 | kerio | checkerboard would make them easier to spot |
| 18:35.54 | KotCzarny | could be i just didnt look at the screen closely before |
| 18:36.07 | KotCzarny | 1680x1050 is quite high dpi |
| 18:36.14 | KotCzarny | (for 15") |
| 18:44.42 | DocScrutinizer05 | APic: for two reasons: you shouldn't write brute force to the device anyway, and for sure not all zeros since that might get optimized out by the eMMC's contrller and not result in any real write |
| 18:47.18 | DocScrutinizer05 | after you did fill the complete storage with one file with pseudo random data (not all zeros), you can optimize the eMMC again by doing exactly that: write all zeros to a file until storage full, then delete the file |
| 18:48.13 | DocScrutinizer05 | this will possibly tell the controller that the flash pages are unused |
| 18:48.26 | DocScrutinizer05 | unlikely but possible |
| 18:48.42 | APic | Ok |
| 18:48.51 | KotCzarny | still, overthinking |
| 18:48.59 | DocScrutinizer05 | your chances are better on the vfat fs than on any other |
| 18:48.59 | KotCzarny | remove the files then do full flash |
| 18:49.12 | kerio | either the controller knows about all zeroes and will just mark the pages as unused or it doesn't know about all zeroes and will just write them |
| 18:49.24 | kerio | but by marking the pages as unused you'll still obtain the desired result |
| 18:49.36 | kerio | and most definetely you need to do that on the whole device anyway, not on a single partition |
| 18:49.40 | DocScrutinizer05 | or the controller knows about vfat and optinizes |
| 18:49.45 | kerio | because the controller doesn't split the device in partitions |
| 18:50.46 | KotCzarny | also, 'controller optimizing' would mean that you get meaningful data on read, still, you would get all zeros. so as i said, unless you are doing forensic flash data retrieval as a work/hobby, no point in overthinking |
| 18:50.49 | DocScrutinizer05 | good point, make that dd if=/dev/urandom of=/home/user/xxx; dd if=/dev/urandom of=/home/user/MyDocs/xxx; rm /home/user/MyDocs/xxx; rm /home/user/xxx; |
| 18:51.13 | kerio | still no need to use urandom but ok |
| 18:51.24 | kerio | and you forgot about the swap, which is probably even more critical |
| 18:51.33 | kerio | considering that private material ends up there all the time |
| 18:51.37 | DocScrutinizer05 | no, you also could use /dev/one |
| 18:51.59 | kerio | surely it depends on the innards of the controller |
| 18:52.02 | KotCzarny | what about fingerprints on the screen? |
| 18:52.08 | kerio | deleted nand pages appear as 0xff, not 0x00 |
| 18:52.11 | KotCzarny | dna samples in keyboard? |
| 18:52.17 | kerio | KotCzarny: eeew |
| 18:52.22 | kerio | what do YOU do with your n900 |
| 18:52.28 | DocScrutinizer05 | I didn't forget about swap, I considered it safe enough and likely enough to get corrupted for all but the most security relevant purposes |
| 18:52.51 | KotCzarny | kerio, i assume you are treating n900 with white gloves, eh? |
| 18:53.04 | kerio | ( ͡° ÍÊ Í¡Â°) |
| 18:54.07 | DocScrutinizer05 | (use dev/one (which doesn't exist)) or do what I suggested to speedup |
| 18:54.44 | DocScrutinizer05 | (ls -lR /; cat $file)|dd of=$file |
| 18:55.02 | KotCzarny | ls -lR is WRONG |
| 18:55.13 | KotCzarny | find / -type f is right |
| 18:55.24 | kerio | wat |
| 18:55.31 | kerio | that's just to generate some data or whatever |
| 18:55.41 | KotCzarny | kerio, do ls -lR and see the output |
| 18:56.05 | KotCzarny | also, using ascii is no better than /dev/zero |
| 18:56.26 | kerio | ? |
| 18:56.46 | kerio | the idea is that only writes of zeroes are optimized away |
| 18:56.53 | kerio | for whatever meaning of "optimized away" doc means |
| 18:57.34 | kerio | writing anything else will trigger an erase/write cycle on the page that the controller wants to use |
| 18:57.34 | KotCzarny | idea is that doing reverse write then doing statistical analysis on the floating data still present on data cells |
| 18:57.38 | kerio | no, that's not the idea |
| 18:57.43 | kerio | everyone here agrees that that's bullshit |
| 18:57.50 | kerio | especially for flash memory |
| 18:58.03 | kerio | where if you trigger an erase you're pretty damn sure that the data is gone |
| 18:58.13 | kerio | literally shocked out of existance |
| 18:58.27 | KotCzarny | kerio, sure, but you think data cells are 0/1 |
| 18:58.32 | KotCzarny | it's not exactly 0/1 |
| 18:58.52 | kerio | but even on rotational drives there's literally no account of anyone ever recovering data from a zeroed out platter |
| 18:58.57 | kerio | because if you could do that |
| 18:59.02 | kerio | then you could use the same principle to store more data |
| 18:59.22 | kerio | which is what hard drive manufacturers *do* |
| 18:59.40 | KotCzarny | kerio, thing is they did that |
| 18:59.49 | KotCzarny | residual magnetism |
| 18:59.49 | kerio | citation needed |
| 19:00.36 | KotCzarny | http://m.www.na-businesspress.com/JMPP/MedlinWeb.pdf |
| 19:01.07 | KotCzarny | see residual magnetism |
| 19:01.50 | KotCzarny | that's why corpos destroy media physically |
| 19:01.55 | kerio | "This data can be recovered with certain software and hardware scans" |
| 19:02.46 | KotCzarny | https://en.wikipedia.org/wiki/Data_remanence |
| 19:03.33 | KotCzarny | https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_recovering_overwritten_data |
| 19:03.55 | kerio | yes, i was about to link that |
| 19:04.30 | kerio | An analysis by Wright et al. of recovery techniques, including magnetic force microscopy, also concludes that a single wipe is all that is required for modern drives. |
| 19:04.39 | kerio | (where modern = after 2001, over 15gb) |
| 19:05.15 | kerio | and you destroy drives instead of overwriting them because physically punching through the platters with a lever takes like 5 seconds |
| 19:05.16 | KotCzarny | also remember, it's official info in wikipedia |
| 19:05.25 | KotCzarny | what is in nsa arsenal is another story |
| 19:05.49 | APic | Friend posted this: http://www.microsoft.com/en-us/mobile/support/faq/?action=singleTopic&topic=FA121650 |
| 19:05.52 | APic | How about that? |
| 19:06.14 | kerio | all i asked was an article where someone shows recovery of at least one byte from a hard disk platter that was overwritten with a NUL |
| 19:06.26 | kerio | APic: that's what i suggested initially but i'm not sure if it actually overwrites stuff |
| 19:06.31 | KotCzarny | kerio: http://imgur.com/gallery/zMuJzWt |
| 19:06.37 | KotCzarny | punching leaves some data instact |
| 19:08.02 | *** join/#maemo xelo (~xelo@ip-176-198-129-195.hsi05.unitymediagroup.de) |
| 19:09.17 | kerio | ok actual question |
| 19:09.26 | kerio | is there a way to restore mtd1 (CAL) to a pristine state? |
| 19:12.58 | *** join/#maemo krnlyng (~liar@178.112.208.204.wireless.dyn.drei.com) |
| 19:17.15 | KotCzarny | kerio: http://www.vistax64.com/system-security/208829-who-can-crack-gutmann-method.html#post960915 |
| 19:20.41 | kerio | lots of sources |
| 19:20.47 | KotCzarny | i guess connecting n900 to pc and feeding it to truecrypt format would be faster than 'on device' clear |
| 19:21.08 | KotCzarny | kerio, thing is you won't hear about such low level data recovery |
| 19:21.42 | KotCzarny | if there is a backdoor, who's gonna brag about it? |
| 19:22.22 | DocScrutinizer05 | kerio is right about flash erase |
| 19:23.41 | KotCzarny | regarding flash: http://www.freerepublic.com/focus/f-chat/2678482/posts |
| 19:23.55 | salamisami | eh |
| 19:24.01 | kerio | DocScrutinizer05: the thing is |
| 19:24.09 | kerio | if the controller is smart enough to treat zeroes differently |
| 19:24.21 | salamisami | i ran apt-get update fcam-drivers and reboot and camera doesnt work |
| 19:24.22 | kerio | why wouldn't it also do background garbage collection of the pages? |
| 19:24.30 | DocScrutinizer05 | ((and you destroy drives instead of overwriting them because...)) ...you can't erase a disk that's already defect |
| 19:24.32 | kerio | salamisami: normal kernel? |
| 19:24.39 | salamisami | power v53 |
| 19:24.47 | kerio | DocScrutinizer05: that, too |
| 19:24.53 | kerio | can't ATA Secure Erase if the drive doesn't work |
| 19:25.13 | DocScrutinizer05 | kerio: (garbage collection) they do, usually |
| 19:28.08 | KotCzarny | 3. If you fill your hard drive with porn, they may stop looking for hidden data, and just fap instead. |
| 19:28.09 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 19:28.10 | KotCzarny | lol |
| 19:28.27 | kerio | DocScrutinizer05: so what's the issue with writing zeroes? |
| 19:31.45 | salamisami | so.... is there any way to make the camera work again (which does not include flashing the phone) |
| 19:32.01 | KotCzarny | uninstall fcam and fcam-drivers |
| 19:32.11 | KotCzarny | or fcam-modules, dont remember |
| 19:32.20 | salamisami | so no blessn900 for power kernel then? |
| 19:32.40 | kerio | i never understood who's responsible for the kernel module |
| 19:32.40 | KotCzarny | i think it's just incompability of the modules |
| 19:36.32 | KotCzarny | btw. did you reboot after installing fcam? |
| 19:36.48 | Sicelo | you just need to reinstall :) |
| 19:37.06 | Sicelo | has PK & BlessN900 |
| 19:37.37 | Sicelo | and also PK & FCamera on the 2nd N900. just reinstall the drivers. it should be in wiki |
| 19:38.01 | salamisami | i did reboot |
| 19:38.13 | salamisami | well i removed fcam drivers and now the default cam works again |
| 19:41.24 | salamisami | whats the nicest calculator application for maemo btw |
| 19:41.35 | KotCzarny | i use bc |
| 19:49.57 | DocScrutinizer05 | clearly HP45 :-) |
| 19:53.35 | Linkandzelda | any of you tried meego? |
| 19:54.16 | salamisami | you mean harmattan? |
| 19:54.22 | Linkandzelda | yea |
| 19:54.32 | salamisami | well i own N0 |
| 19:54.33 | salamisami | n9 |
| 19:55.12 | DocScrutinizer05 | sorry, HP42 http://my-maemo.com/software/applications.php?fldAuto=812&faq=41 |
| 19:55.22 | Linkandzelda | just wondering if there's any point in trying it out on my n900 |
| 19:56.20 | DocScrutinizer05 | http://maemo.org/packages/view/free42/ |
| 19:58.54 | DocScrutinizer05 | Linkandzelda: harmattan doesn't work too nice on N900 afaik |
| 19:59.05 | Linkandzelda | i see |
| 19:59.15 | DocScrutinizer05 | also it's abandoned very early during development |
| 19:59.32 | Linkandzelda | im still searching for a vsync fix, saw that harmattan had it apparently |
| 19:59.33 | salamisami | dunno why you'd even want harmattan on n900 |
| 19:59.42 | salamisami | whenever i was using n9 i wished it had maemo instead |
| 19:59.53 | DocScrutinizer05 | there are fremantle/N900 vsync fixes I think |
| 20:00.13 | DocScrutinizer05 | salamisami: indeed |
| 20:00.17 | Linkandzelda | if you find something i'd like to try it |
| 20:00.33 | DocScrutinizer05 | ask pali |
| 20:00.39 | DocScrutinizer05 | he might know |
| 20:00.45 | DocScrutinizer05 | or freemangordon |
| 20:00.59 | Linkandzelda | the bug report was closed with Status:RESOLVED WONTFIX a long time ago, thats about all i discovered |
| 20:04.50 | DocScrutinizer05 | hmm I _think_ some kernel hackers found a way to enable the hw vsync |
| 20:05.17 | DocScrutinizer05 | or maybe they hoped for such and didn't manage to implement it, dunno |
| 20:13.34 | *** join/#maemo krnlyng_ (~liar@83.175.90.24) |
| 21:09.44 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 22:03.47 | *** join/#maemo pagurus (~user@p548CA2F0.dip0.t-ipconnect.de) |
| 22:05.38 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 22:18.40 | Linkandzelda | DocScrutinizer05: Last Measured Discharge: 1252 mAh |
| 22:27.17 | kerio | that's pretty decent |
| 22:27.21 | kerio | what was the draw? |
| 22:33.30 | DocScrutinizer51 | Linkandzelda: sounds correct |
| 22:34.43 | DocScrutinizer51 | now after next unplug from charger start the calibrate script right away |
| 22:35.14 | Linkandzelda | DocScrutinizer51: i'll let it charge up again until tomorrow morning, and will run it again |
| 22:35.56 | Linkandzelda | though it died from 100% in 9 hours in standby with only SSH running and xchat for 5 mins |
| 22:35.59 | DocScrutinizer51 | yes, let it charge up tonight, and tomorrow after unplug start the script |
| 22:37.18 | DocScrutinizer51 | ideally run bq27200.sh 60 >>xxxxm in parallel |
| 22:41.35 | DocScrutinizer51 | Linkandzelda: actually I ponder to make bw27200.sh >>/var/log/batlog.txt an autostart on my device |
| 23:13.59 | *** join/#maemo ian_r (~ianr@c-73-92-40-9.hsd1.ca.comcast.net) |
| 23:35.03 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
