| wpwrak | heh, now the price hike is out :) let's see what happens | 02:17 |
|---|---|---|
| wolfspra1l | nothing will happen | 02:40 |
| wpwrak | ;-) | 02:50 |
| wpwrak | i guess i should try to organize some angry protests, just to prove you wrong :) | 02:50 |
| roh | hehe | 05:34 |
| roh | price-hike? ah. | 05:35 |
| roh | well.. i was actually thinking about buying a efika mx from tuxbrain. they seem to be difficult to get over here | 05:35 |
| roh | wolfspra1l: are there no working watches anymore or why does the public mean to give 10mio to these guys?! | 05:42 |
| wolfspra1l | don't understand | 05:44 |
| wolfspra1l | it's something people like, obviously | 05:44 |
| wolfspra1l | I certainly don't ask "why are 10 mio spent on this or that" - if you just look around the world a bit you could ask yourself that question for billions and billions spent every day on total bs | 05:45 |
| wolfspra1l | I do like how they pulled it off though, will watch whether they can establish strong/new sales channels. | 05:45 |
| roh | wolfspra1l: well.. it doesnt happen that often that one asks for 100k and gets 10mio | 05:47 |
| roh | just too sad that i do not carry watches anymore ;) | 05:47 |
| qi-bot | The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.full_system-20120601-0638 | 08:07 |
| qi-bot | [commit] Werner Almesberger: b2/: rename a bit too general "dump" to "dump_param" (master) http://qi-hw.com/p/eda-tools/b723c88 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/: new option -dCHARS to dump specific db; replaces use of -v (master) http://qi-hw.com/p/eda-tools/3ebac68 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/boom.c (main): rearrange to reduce indentation depth (master) http://qi-hw.com/p/eda-tools/be1277e | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/db.c: new function parts_dump to dump the whole parts database (master) http://qi-hw.com/p/eda-tools/2241276 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/: move parts dumping from lang.y to boom.c and make optional (-dc) (master) http://qi-hw.com/p/eda-tools/f09e4b2 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/test/Common: support multiple files of the same kind (!-c1, !-c2, etc.) (master) http://qi-hw.com/p/eda-tools/69701f4 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/lang.y (part): show part ID in error message (master) http://qi-hw.com/p/eda-tools/ea57323 | 08:57 |
| qi-bot | [commit] Werner Almesberger: b2/test/char: part characteristics database test (master) http://qi-hw.com/p/eda-tools/dd727b1 | 08:57 |
| viric | http://vincentpetry.net/blog/?p=151 worth for openwrt/nanonote? | 11:44 |
| Ayla | should run out of the box on the dingoo | 11:54 |
| viric | ah nice :) | 11:57 |
| viric | I even did not care to see if it is packaged already, sorry | 11:57 |
| viric | so in the dingoo you run even python games. nice | 11:58 |
| DocScrutinizer51 | wolfspraul: which nfs version? | 12:09 |
| wolfspraul | don't know | 12:42 |
| DocScrutinizer51 | well, I'm just having fun with copying a complete image of $HOMe (~27GB) from my old laptop to a new one, via scp | 15:45 |
| DocScrutinizer51 | recovers nicely (when mc is managing that copy via /#sh://) but suuuucks for speed | 15:46 |
| DocScrutinizer51 | buzzword fishfs it seems | 15:46 |
| viric | the network link is your bottleneck? | 15:49 |
| DocScrutinizer51 | nah | 15:50 |
| DocScrutinizer51 | friggin fs operations via ssh are | 15:50 |
| DocScrutinizer51 | ~20 files/s | 15:50 |
| viric | why don't you use rsync for example? | 15:51 |
| DocScrutinizer51 | facing another ~12h ETA, plus penalty for each file on source that's not readable by user | 15:51 |
| DocScrutinizer51 | viric: because I'm a lazy asshole and just realized mc can connect to the ssh of source PC | 15:52 |
| viric | not a bad reason | 15:52 |
| viric | at least mc provides ETA. | 15:52 |
| viric | I don't know any other tool that des | 15:52 |
| viric | does | 15:52 |
| DocScrutinizer51 | I nevertheless evaluated option a tiny bit before, and concluded rsync via ssh would do exactly the same, but without nice progress indicator and requesters etc | 15:53 |
| viric | I'm more of: ssh pc "tar c /home" | tar x | 15:53 |
| viric | :) | 15:53 |
| viric | well, rsync via ssh would not have a slowdown of fs operations through ssh | 15:53 |
| viric | rsync gives work to the remote rsync. | 15:54 |
| DocScrutinizer51 | you *might* be right actually | 15:54 |
| DocScrutinizer51 | initially I thought "whatever time it takes, I'm not in a hurry" | 15:54 |
| DocScrutinizer51 | now I realize I have to observe this process for 12h, to eventually hit return to make a warning requester go away, whenever there's a file owned by root and not user, and not readable by user | 15:55 |
| viric | ha. :) | 15:57 |
| viric | if you know the size of the data... use 'pv' | 15:57 |
| viric | ssh pc "tar cp /home" | pv -S 23g | tar xp | 15:58 |
| viric | and you'll get an ETA. :) | 15:58 |
| viric | ssh pc "tar cp /home" | pv -a -S 23g | tar xp | 15:58 |
| viric | the averaging may work better for ETA. | 15:58 |
| viric | store the 'tar' stderr, and you'll have a list of the errors. | 15:59 |
| viric | ssh pc "tar cp /home" 2> tarc-errors.txt | pv -a -S 23g | tar xp | 15:59 |
| DocScrutinizer51 | I used sftp from console now, logging in to source PC as root --- rocks! | 17:23 |
| DocScrutinizer51 | from scroll spreed in xterm I estimate I'm up from ~20fileops/s to >500 now | 17:25 |
| DocScrutinizer51 | well, this might have been the part where dest files already been existing | 17:27 |
| DocScrutinizer51 | suddenly it dropped significantly | 17:27 |
| DocScrutinizer51 | still, I'm confident it won't take longer than 2 hours now | 17:36 |
| DocScrutinizer51 | mhm, 2 minutes for qi ML | 17:56 |
| DocScrutinizer51 | /home/jr/.kde/share/apps/kmail/mail/.lists.directory/qi/cur/1292839187.22703.sSFlI 100% 5131 5.0KB/s 00:00 | 17:56 |
| DocScrutinizer51 | those 130,000 mails suck for sftp, even at an estimated rate of 100/s | 18:00 |
| viric | it depends on your filesystem too | 18:02 |
| viric | if it seeks once per letter... on a 7200rpm disk it will do little more than 100/s | 18:03 |
| viric | with sftp you still have each file requested remotely, one by one. | 18:03 |
| DocScrutinizer51 | sure | 18:07 |
| DocScrutinizer51 | /home/jr/.kde/share/apps/kmail/mail/.lists.directory/.openmoko.directory/.public.directory/cmty/cur/1326897176.26507.33lRp 100% 7094 6.9KB/s 00:00 | 18:07 |
| viric | good luck. | 18:08 |
| DocScrutinizer51 | I hope it'll be thru with mail eventually | 18:08 |
| viric | I don't think sftp will respect symlinks, dates, ... | 18:09 |
| DocScrutinizer51 | -pr will | 18:11 |
| DocScrutinizer51 | bottleneck CPU still, not HDD: Avg: 25.1% sy: 5.1% ni: 0.0% hi: 0.0% si: 0.6% wa: 35.4% | 18:12 |
| DocScrutinizer51 | which makes a total of 100% on one of both cores, plus a bit on other one | 18:13 |
| DocScrutinizer51 | wa is it | 18:13 |
| DocScrutinizer51 | device reads SDA (8.0): ~80/s max | 18:14 |
| DocScrutinizer51 | usually way ,ower | 18:15 |
| DocScrutinizer51 | lower* | 18:15 |
| DocScrutinizer51 | well, no, that's actually average. max is 500 | 18:15 |
| DocScrutinizer51 | those 80 though could actually be the msg files read one by one | 18:17 |
| DocScrutinizer51 | *yawn* | 18:21 |
| DocScrutinizer51 | watching make runs is more fun ;-) | 18:21 |
| DocScrutinizer51 | *yaaaawn* /home/jr/.kde/share/apps/kmail/mail/.lists.directory/.openmoko.directory/.public.directory/cmty/cur/1221116234.3915.HLS8k:2,S 100% 3816 3.7KB/s 00:00 | 18:24 |
| Action: DocScrutinizer51 sobs for all the inodes | 18:25 | |
| wpwrak | if you delete all the files, your inodes will enjoy freedom again :) | 18:26 |
| DocScrutinizer51 | jr@halley:~> find /home/jr/.kde/share/apps/kmail/mail/ |wc -l | 18:27 |
| DocScrutinizer51 | 154729 | 18:27 |
| DocScrutinizer51 | took an amazing ~5s to complete, despite this sftp monster running concurently | 18:28 |
| DocScrutinizer51 | YAY OM-kernel ML | 18:29 |
| DocScrutinizer51 | through with community | 18:29 |
| DocScrutinizer51 | anyway mail takes >30% of the files to copy | 18:30 |
| DocScrutinizer51 | number of, not volume | 18:30 |
| DocScrutinizer51 | \o/ internal | 18:32 |
| qi-bot | [commit] Werner Almesberger: fisl2011/Makefile (DL): Atben_atusb_prod_03.jpg was missing (master) http://qi-hw.com/p/wernermisc/8418a19 | 18:43 |
| DocScrutinizer51 | and stalled >:-( | 18:43 |
| DocScrutinizer51 | fsck that d-link dir615, which obviously has problems with occasionally dropping ARP table or whatever | 18:48 |
| DocScrutinizer51 | or firewall/NAT hangups | 18:49 |
| DocScrutinizer51 | fuuuuuck, sftp won't resume, I.E. will start from very first file again, ignoring all the stuff already copied. Worse: rsync does that too :-o | 19:43 |
| DocScrutinizer51 | seems rsync hold a local file where it keeps a list of files already synced, and it doesn't care at all about actually existing real files on destination | 19:44 |
| DocScrutinizer51 | or maybe not | 19:47 |
| DocScrutinizer51 | already at "xfer#25322" | 19:47 |
| DocScrutinizer51 | 44k done 61k left | 19:55 |
| DocScrutinizer51 | left 1900 of 171000 | 20:23 |
| DocScrutinizer51 | and friggin rsync is way slower than sftp: while sftp maxed out a ~11MB/s on large files, rsync gets to 3.xMB/s when lucky | 20:24 |
| DocScrutinizer51 | and the WTF: it's not been dir615 but the sis190 kernel module of source machine. Had to modprobe-cycle it to make the NIC work again | 20:25 |
| DocScrutinizer51 | "it"=the lockup | 20:25 |
| DocScrutinizer51 | sigh | 22:21 |
| DocScrutinizer51 | sent 8096479 bytes received 19742271984 bytes 2132984.34 bytes/sec | 22:21 |
| DocScrutinizer51 | total size is 28602138243 speedup is 1.45 | 22:21 |
| DocScrutinizer51 | rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1530) [generator=3.0.9] | 22:21 |
| wpwrak | make a tar and scp it ? or would that be too easy ? :) | 22:23 |
| wpwrak | extra points for rsyncing the tar, since this will let you restart | 22:23 |
| DocScrutinizer51 | make a tar of 28GB, on a disk that has 300MB free? | 22:24 |
| DocScrutinizer51 | suuure | 22:24 |
| wpwrak | delete all the porn first :) | 22:24 |
| DocScrutinizer51 | well, seems it's thru now. but now I have a dir /home/jr/halley with lots of stuff in it. And a dir /home/jr/halley/home/jr, with all the stuff in it again :-S | 22:28 |
| wpwrak | that's called a "backup" :) | 22:29 |
| DocScrutinizer51 | could you tell from the cmdline >> rsync -vaRzxP --fake-super root@192.168.1.30:/home/jr/ ~/halley/jr/ << which is the real stuff now? | 22:29 |
| wpwrak | my bet would be on the subdirectory | 22:30 |
| wpwrak | but you can just move it out. then do a du -sh to compare size | 22:31 |
| DocScrutinizer51 | indeed | 22:31 |
| wpwrak | or diff -r if you're bold and they should be the same :) | 22:31 |
| DocScrutinizer51 | already thought abizt du -sh, but thanks for the moving suggestion | 22:31 |
| DocScrutinizer51 | about* | 22:32 |
| DocScrutinizer51 | jr@HaleBopp:~/halley/jr> du -sh /home/jr/halley2/home/jr/; du -sh /home/jr/halley | 22:36 |
| DocScrutinizer51 | 28G /home/jr/halley2/home/jr/ | 22:36 |
| DocScrutinizer51 | 13G /home/jr/halley | 22:36 |
| DocScrutinizer51 | wpwrak: thanks | 22:36 |
| DocScrutinizer51 | it seems like the destination argument on that rsync cmd took no effect at all | 22:37 |
| DocScrutinizer51 | anyway 28G is what I expected | 22:38 |
| wpwrak | you could du a find with md5sum on source and origin to be 100% sure | 22:39 |
| wpwrak | s/du /do | 22:39 |
| wpwrak | cd /home/jr/halley; find . -type f -exec md5sum '{}' \; >~/output | 22:41 |
| wpwrak | then do a sort out1 out2 | uniq -u | 22:41 |
| DocScrutinizer51 | what for? | 22:41 |
| rjeffries | wolfspraul expresed interest in making hos own PCBs. this article is not bad. http://hackaday.com/2012/06/02/pcb-manufacturing-tutorial/ | 22:41 |
| wpwrak | that will allow you to see if a) all the files made it and b) if they were copied correctly | 22:42 |
| rjeffries | s /hos/his/ | 22:42 |
| DocScrutinizer51 | this will take longer than doing another rsync | 22:43 |
| wpwrak | no. worst case, it takes just as long :) | 22:46 |
| DocScrutinizer51 | friggin idiot I am, giving -R parameter without thinking | 22:47 |
| wpwrak | better than --remove-source-files :) | 22:50 |
| wpwrak | rjeffries: seems reasonably up to date. the etchant tank is a bit overkill, though, unless you plan to do monster boards | 22:52 |
| rjeffries | wprak did you see [not talking about this artcle] where one person made a spray chamber so he could etch boards quickly with no muss or fuss? amusing. | 22:53 |
| wpwrak | he seems a bit confused about what 3D printers do, too | 22:53 |
| DocScrutinizer51 | HAH, now the benefits of rsync hit | 22:55 |
| DocScrutinizer51 | +mwDGO1eWKyOiCJnpYZVFtUcItXrsync: readlink_stat("/home/jr/.gvfs") failed: Permission denied (13) | 22:55 |
| DocScrutinizer51 | rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1530) [generator=3.0.9] | 22:55 |
| DocScrutinizer51 | second run was "lightning fast" | 22:56 |
| DocScrutinizer51 | nfc what's this >>key_read: uudecode AAAAB3NzaC1kc3MAAAEBAP8Bo+QhQ...<< foo at beginning though | 22:57 |
| DocScrutinizer51 | friggin 7 lines of uuencoded key, WHY oh WHY? | 22:57 |
| wpwrak | rjeffries: the chemistry link is interesting, though: http://www.stephenhobley.com/blog/2011/03/02/still-messing-with-forces-i-dont-understand-the-formula/ | 22:58 |
| wpwrak | replacing the muriatic acid (HCl) with household chemicals | 22:58 |
| DocScrutinizer51 | OUCH | 22:58 |
| wpwrak | i just hope those people never get their hands on higher grade peroxide. the graveyard of overly adventurous pioneers is already quite full :) | 22:59 |
| DocScrutinizer51 | he could rub some marshmallows on it and let ants eat away the copper | 22:59 |
| DocScrutinizer51 | ~curse gnome and all g* | 23:03 |
| infobot | May you be reincarnated as a Windows XP administrator, gnome and all g* ! | 23:03 |
| wpwrak | that could work. probably a bit slow, though | 23:03 |
| wpwrak | faster than just waiting for proton decay, though :) | 23:04 |
| DocScrutinizer51 | wpwrak: would you be interested in getting involved into a bit of kernel development discussion? | 23:09 |
| wpwrak | the kernel is vast. what area of it ? | 23:11 |
| DocScrutinizer51 | there's this guy FreemanGordon over there at #maemo-ssu, and he investigated for almost a felt year now how to make thumb interworking working on N900 which has an OMAP with a silicon erratum that fscks up the branch prediction when you (mem)swap a thumb branch for a ARM branch, or sth like that | 23:12 |
| DocScrutinizer51 | actually there are (at least) two silicon errata, and common urban legend is the fixes for those two are mutually exclusive | 23:13 |
| wpwrak | nice ;-) | 23:13 |
| wpwrak | sounds like a topic for the linux-arm list ? | 23:13 |
| DocScrutinizer51 | freemanG now claims he made it work, but none of the "experts" is willing to listen | 23:14 |
| DocScrutinizer51 | which is kinda expected, since that OMAP3430 is rather old silicon anyway | 23:15 |
| wpwrak | did he try that list ? i'm no longer on it, so it can't check quickly | 23:15 |
| DocScrutinizer51 | and not much to earn on fixing kernel stuff to make thumb interworking fixed for that particular chip - at least unless you're a fan of N900 | 23:15 |
| DocScrutinizer51 | list not yet afaik | 23:16 |
| wpwrak | thumb is for running closed binaries ? | 23:16 |
| DocScrutinizer51 | well, thumb is a smaller (16bit) alternative opcode set | 23:18 |
| DocScrutinizer51 | or what's been the question? | 23:18 |
| DocScrutinizer51 | his interest is in reducing RAM footprint of certain libraries like Qt etc | 23:19 |
| DocScrutinizer51 | since N900 is in a permanent swap hell | 23:19 |
| wpwrak | ah, i see | 23:20 |
| DocScrutinizer51 | thumb instruction set is supposed to be ~30% smaller than ARM, but possibly slower in execution | 23:20 |
| wpwrak | i think (conceptually) what thumb is. just never saw anyone actually use it | 23:20 |
| DocScrutinizer51 | you usually don't even realize I guess | 23:21 |
| wpwrak | you mean s/instruction set/code size/ ? | 23:21 |
| DocScrutinizer51 | err yep | 23:21 |
| DocScrutinizer51 | e.g. STE modem is all thumb afaik | 23:22 |
| wpwrak | evil blobs :) | 23:22 |
| DocScrutinizer51 | sure | 23:22 |
| DocScrutinizer51 | do you think you could give some guidance what to post to linux-arm ML | 23:24 |
| DocScrutinizer51 | *my* problem with FreemanG is that our ideas of patch validation differ vastly | 23:26 |
| wpwrak | i'm only an occasional visitor there myself. haven't posted there since openmoko. so i wouldn't have any specific recommendations. just do the usual - describe problem, solution, and see what happens | 23:26 |
| wpwrak | patch validation ? | 23:26 |
| DocScrutinizer51 | somehow I think such a patch for a silicon erratum has to be validated somehow | 23:27 |
| DocScrutinizer51 | to be effective | 23:27 |
| DocScrutinizer51 | and actually target the problem comprehensively | 23:27 |
| wpwrak | well it needs testing, like anything else. if the erratum is version-dependent, it may need a switch, too | 23:27 |
| DocScrutinizer51 | esp since here we got 2 bugs in chip, with common notion (seemingly based on rumour) being that the already esisting patches are mutually exclusive | 23:28 |
| DocScrutinizer51 | and my approach is based on building a testbed that 100% reproducably and traceably invokes the problem | 23:30 |
| DocScrutinizer51 | while FMG's approach is "it's not possible to write such testbed. but ubuntu is all thumb and it runs on my N900 since 3 weeks now. That's proof enough" | 23:30 |
| DocScrutinizer51 | maybe slightly different rationale and wording, but the general idea AIUI is like that | 23:32 |
| DocScrutinizer51 | I'm affraid with this approach of his, he won't see benevolent reviews on linux-arm ML | 23:34 |
| wpwrak | he does seem to have a certain, erm, assertive style, yes | 23:35 |
| DocScrutinizer51 | that's where your comments are welcome | 23:35 |
| wpwrak | just tell him the key guys on linux-arm have had daily exercise as top of the foodchain bullies for the last 20 years. he's not going to out-stubborn them ;-) | 23:37 |
| wpwrak | well, some of them have. others are gentle :) | 23:37 |
| DocScrutinizer51 | (version dependent) one of the fixes - published by TI itself - is by setting some bit in auxiliary control register of CPU, to flush branch prediction on every context switch (whatever that means, now that I come to think of it) | 23:37 |
| DocScrutinizer51 | obviously there is a performance penalty in flushing branch prediction frequently | 23:38 |
| wpwrak | if it's just per context switch, that should be negligible | 23:39 |
| DocScrutinizer51 | usually yes | 23:39 |
| DocScrutinizer51 | then there's another bug that kicks in on that (or not), related to commands that flush branch prediction which may result in some nonsensical CPU action (like branching to a destination offset by an unrelated obscure register) | 23:40 |
| DocScrutinizer51 | and patch for that is to either not use the flush-branch-prediction-queue instructions, or to initialize that random bogus unrelated register to 0, so it won't affect stuff | 23:41 |
| wpwrak | maybe whitequark could write a thumb decompiler for you ;-) then you could recompile the whole mess with something that's actually been tested :) | 23:41 |
| wpwrak | so zero-initialize and flush, to kill both birds ? | 23:42 |
| DocScrutinizer51 | all disclaimer: IIRC & AIUI | 23:42 |
| DocScrutinizer51 | yeah, and that's where fun starts: so far nobody was able to do that (except Nokia), as you can access that auxiliary register only in secure mode / context. The secure context gets irreversibly locked during bootloader execution | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/test/curr: currency exchange test (master) http://qi-hw.com/p/eda-tools/0ba0abb | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/lang.y (provider): don't allow provider to be redefined (master) http://qi-hw.com/p/eda-tools/994ed00 | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/test/prov: provider database test (master) http://qi-hw.com/p/eda-tools/4184c01 | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/test/Common (run_boom): place inventory after parts and currency (master) http://qi-hw.com/p/eda-tools/e62bb06 | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/test/inv: inventory database test (master) http://qi-hw.com/p/eda-tools/cc5d9a9 | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/: move substitutions dump from parser to boom.c (master) http://qi-hw.com/p/eda-tools/3027dac | 23:44 |
| qi-bot | [commit] Werner Almesberger: b2/: insert a virtual empty hierarchy if test input starts with other file (master) http://qi-hw.com/p/eda-tools/d1593b6 | 23:44 |
| DocScrutinizer51 | FMG now claims he found a "BIOS call" to write to that register from normal linux context | 23:44 |
| wpwrak | OMG :) | 23:45 |
| wpwrak | how can the BIOS write to an "irreversibly locked" register ? | 23:45 |
| DocScrutinizer51 | it's basically like a usual age old sw irq | 23:45 |
| DocScrutinizer51 | "BIOS" = ROM bootloader code here | 23:46 |
| wpwrak | so it depends on the location of the executing code ? because it doesn't seem to be locked. else it wouldn't matter what you do once linux runs | 23:47 |
| DocScrutinizer51 | AIUI there's a way to trigger an exception that switches state of CPU to secure context and same time jumps to the "BIOS" code - just like good old INTxx | 23:47 |
| DocScrutinizer51 | it's just the RING0, RING-N concept | 23:48 |
| wpwrak | ah, i see. well, if that register doesn't get changed by anything else, then he can put that magic code in the platform-specific initialization | 23:48 |
| wpwrak | and still flush branch prediction on each context switch | 23:49 |
| DocScrutinizer51 | yep, probably that's what he does, or plans to do, or whatever | 23:49 |
| DocScrutinizer51 | I not *completely* wrapped my head around all that yet | 23:49 |
| --- Sun Jun 3 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!