00:00.05 | Oksana | By the way, a side-step about metadata: if they are collecting URLs visited by you, use websites which do not store information in the URL. Like, DuckDuckGo. It can be confusing when web-browser cannot restore a search after restart, but it keeps browser history much more readable. |
00:37.21 | DocScrutinizer05 | we got a law that requires everybody who gets observed or eavesdropped by law enforcement to get a notice about the fact 6 months after end of the measure. Guess what... Reports talk about X surveillance measures in a year, but X/30 notices getting sent |
00:38.20 | DocScrutinizer05 | 30 is random, may be 100, or 1000 |
00:46.29 | DocScrutinizer05 | related: https://de.wikipedia.org/wiki/Ãberwachungsstaat#.C3.9Cberwachung_in_der_Bundesrepublik_Deutschland |
03:33.10 | *** join/#neo900 M13 (~MirandaLS@83.149.35.57) |
03:37.01 | *** join/#neo900 M13 (~MirandaLS@83.149.35.57) |
04:33.55 | *** join/#neo900 wicket64 (~wicket@gateway/tor-sasl/wicket64) |
04:57.40 | Oksana | On July 3, 2014 ARD revealed that XKeyscore is used to closely monitor users of the Tor anonymity network, people who search for privacy-enhancing software on the web, and readers of Linux Journal. |
05:03.54 | Oksana | About Taxpayer Identification Number (created in 2008): a person may have one or two (or more?) TINs, and none of these numbers are commonly used for other than their specific purpose, nor is such (ab)use legal. Bundestag found the concept of an identification system for the entire population to be incompatible with the existing legal framework. |
05:13.41 | Oksana | The law became valid on 1 January 2008. Any communications data had to be retained for six months. On 2 March 2010, the Federal Constitutional Court of Germany ruled the law unconstitutional as a violation of the guarantee of the secrecy of correspondence. As such, the directive is not currently implemented in Germany. |
05:29.37 | Oksana | I do not understand Telecommunications Monitoring Order, though. Is Monitoring happening now, or not? |
05:44.24 | Oksana | Quiet... |
05:48.12 | Oksana | Marvol is silent. I sent a query yesterday, no reply yet. |
05:50.30 | *** join/#neo900 XDS2010 (sid1218@gateway/web/irccloud.com/x-todxsbphpbcfsgeu) |
05:56.09 | jonwil | http://talk.maemo.org/showthread.php?p=1440453#post1440453 |
05:56.20 | jonwil | That should take care of what we need to know to handle GPS on the Neo900 |
05:56.53 | jonwil | From the looks of liblocation-dev, re-implementing that library probably wouldn't be all that hard for someone with the requisite glib know-how |
06:00.44 | jonwil | Going forward I will post similar posts for various parts of the cellular subsystem |
06:24.39 | freemangordon | jonwil: re kernel interfaces - Pali has that info already gathered somewhere, ask him where it is, when he is online |
06:25.55 | freemangordon | wpwrak: the "remote NFC phone" scenario you described is pretty much possible, with 2 things to consider: |
06:27.37 | freemangordon | 1. contactless transactions happen in less than half of a second, so the internet connection should no only be fast, but with minimum latencies. Not sure what is the upper time limit fo such a transaction to happen (need to check in the docs), but iirc it is less than a second |
06:30.19 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
06:32.30 | freemangordon | 2. there is PIN on NFC "cards", which is used in the same way as with your normal chip card. There is a possibility that a transaction can happen offline and without PIN, but it doesn't worth it for the amount of such a transaction. One of the banks I was involved in a contactless cards project, had set offline limit to 25 euros. not to say that there is a counter in the card which forces every Nth transaction to be online, no matter what the amount |
06:32.32 | freemangordon | <PROTECTED> |
06:33.18 | freemangordon | so, the scenario is possible, but one won't gain much money of it IMO |
06:53.24 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
06:57.32 | freemangordon | hehe, iBend :D |
06:59.31 | mvaenskae | freemangordon: who would have known that apple is the first to come with a bendable phone? :D |
06:59.54 | mvaenskae | something the neo900 cannot do, it's solid as a brick :) |
07:02.30 | freemangordon | I wonder how's that possible - isn't there engineers in Apple? or only marketing people and designers? |
07:02.58 | freemangordon | ofc a thin aluminium frame will bend |
07:03.49 | freemangordon | esp if made of low-quality alloy |
07:04.02 | freemangordon | al alloy that is |
07:11.19 | mvaenskae | freemangordon: form > function |
07:11.30 | freemangordon | :nod: |
07:11.36 | mvaenskae | that is apple's design policy |
07:11.45 | freemangordon | well, iSheeps deserve it |
07:12.08 | mvaenskae | also about the same height were the bend happens there is a fissure of battery and motherboard |
07:12.15 | mvaenskae | that even makes it worse |
07:13.52 | freemangordon | "fire in my pocket!!!" :D |
07:14.52 | mvaenskae | amazon will be furious |
07:15.02 | mvaenskae | they want the only fire phone there is D: |
07:47.13 | jonwil | is happy with the work put into reverse engineering the GPS stuff |
07:49.23 | jonwil | Not sure what task I will take on next though |
07:59.16 | jonwil | anyone with suggestions on what I could work on, feel free to speak up :) |
08:04.52 | *** join/#neo900 kolp (~quassel@55d40e8d.access.ecotel.net) |
08:17.43 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
08:43.01 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
08:47.06 | jonwil | Looks like making the Neo900 GPS compatible with the N900 and its GPS apps should be fairly simple |
08:47.42 | *** join/#neo900 Xseba360 (~Xseba360@user-94-254-144-118.play-internet.pl) |
08:47.47 | jonwil | Basically the only interface we need to duplicate is the interface of liblocation :) |
08:52.46 | *** join/#neo900 M13 (~MirandaLS@83.149.35.53) |
09:06.49 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
09:08.06 | *** join/#neo900 Xseba360 (~Xseba360@user-94-254-193-57.play-internet.pl) |
09:26.12 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
09:40.22 | *** join/#neo900 freemangordon_ (~ivo@85-118-92-30.mtel.net) |
09:55.44 | *** join/#neo900 Xseba360 (~Xseba360@user-94-254-193-57.play-internet.pl) |
09:58.09 | enyc | jonwil: im just curious if neo900 GPS will be substantially lower power consumption =) |
09:58.51 | enyc | jonwil: I recall using gpsd to translate SiRF binary to text-based etc etc. |
09:59.39 | jonwil | I have no idea how the GPS will work on the Neo900 |
10:00.25 | jonwil | I have just provided the info one needs to know in order to keep the Neo900 GPS system compatible with the N900 apps that use it like maps |
10:12.24 | *** join/#neo900 Mihanizat0r (~MirandaLS@83.149.35.115) |
10:13.21 | enyc | jonwil: ok =) |
10:13.54 | enyc | jonwil: does N900 ever use 'gpsd' ? do the apps olok at searial port directly? i (expect) there is some kind of abstraction/moderator going on inbetween? |
10:17.31 | *** join/#neo900 norly (~norly@enpas.org) |
10:18.06 | jonwil | The N900 uses a library (liblocation) to talk to various daemons that in turn talk to the GPS hardware (which is part of the cellular modem) |
10:19.56 | jonwil | N900 has never used gpsd |
10:20.12 | jonwil | although it uses gypsy to talk to external (i.e. bluetooth) GPS hardware |
10:47.06 | *** join/#neo900 djang0o (~dj@core.0n1.fr) |
10:47.08 | djang0o | hi |
10:47.56 | djang0o | Estimated release: Q4 2014, any confirmation ? |
10:51.14 | *** join/#neo900 freemangordon_ (~ivo@85-118-92-21.mtel.net) |
11:02.01 | jonwil | I can tell you now that the Neo900 will NOT be comming out in 2014 |
11:02.11 | jonwil | its nowhere near complete enough for that |
11:02.36 | jonwil | There are still hardware items to track down I believe |
11:04.06 | freemangordon_ | jonwil: that was stated a couple of times already :) |
11:04.43 | jonwil | I was just responding to the question of djang0o who posted just before you entered chat |
11:05.33 | freemangordon_ | oh, sorry |
11:05.34 | jonwil | Still not sure what to tackle next now that I have done GPS |
11:05.44 | freemangordon_ | eapd? "P |
11:05.50 | freemangordon_ | :P |
11:05.59 | jonwil | Given up playing with eapd |
11:06.14 | freemangordon_ | yeah, I am kidding |
11:06.42 | freemangordon_ | xprot PA plugin? |
11:07.05 | jonwil | No way can I handle pulseaudio stuff either |
11:07.11 | jonwil | or GPU drivers |
11:07.41 | freemangordon_ | that one could be not that complicated as it might seem, nemo has a nokia .a library with all the neon stuff in it |
11:07.47 | freemangordon_ | (xprot) |
11:07.58 | jonwil | got a link? |
11:08.34 | jonwil | although its probably totally different to the way PulseAudio works on N900 |
11:08.43 | freemangordon_ | a sec |
11:08.47 | jonwil | and to what other parts of the system expect the closed blobs to do |
11:09.58 | jonwil | I would say pulseaudio-modules-nokia and powervr are the 2 single most complex closed-source components in the entire Fremantle system |
11:11.41 | freemangordon_ | https://github.com/nemomobile/pulseaudio-modules-nemo/tree/master/src/common |
11:14.06 | jonwil | It looks like the .a files are just optimized versions of src-16-to-48.c, src-48-to-16.c, src-48-to-8.c and src-8-to-48.c |
11:15.03 | jonwil | I see no sign of xprot in that tree at all |
11:15.13 | jonwil | closed or otherwise |
11:15.34 | freemangordon_ | yes, xprot is not there |
11:15.53 | freemangordon_ | the point is that most of the neon code should be in that lib |
11:20.41 | jonwil | ok, a quick look at pulseaudio-module-nokia-voice from Fremantle, I see a named function called xprot_process_stereo_srcdst (as one example) |
11:20.55 | jonwil | I see this function calling a function labeled sub_2855C |
11:20.59 | jonwil | i.e. unnamed |
11:21.50 | jonwil | This function when I look at it in HexRays contains a number of instructions HexRays wont decompile including SMULBB, SMULBT and QDADD |
11:21.55 | jonwil | Looks like FPU to me |
11:22.14 | jonwil | not neon maybe but definatly FPU |
11:22.22 | freemangordon_ | yep |
11:23.31 | jonwil | I even see functions named a_fix_fir_neon_mono and a_fix_fir_neon_stereo that are laden with FPU or Neon |
11:25.40 | djang0o | ok thnx jonwil for the answer |
11:28.16 | wpwrak | freemangordon_: (NFC relaying attack) thanks ! i read a bit more about NFC security, and it seems that the feasibility of this attack is rather well-researched. also with various modes of getting at the victim card. (e.g., via "enhanced" NFC, or by infiltrating the smartphone) |
11:29.12 | wpwrak | in general, i get the vibe that common uses of NFC are a bit of a security nightmare. two-factor (PIN and such) would solve most of these issues, but may be less common than one would hope. |
11:29.34 | wpwrak | except in high-security applications, like your banking example. |
11:30.29 | wpwrak | but if i think of fare cards for public transport, a turnstile suddenly asking for a PIN would be an operational nightmare. |
11:32.45 | freemangordon_ | wpwrak: what is used here is MiFare, which is a different beer |
11:33.18 | freemangordon_ | the security is based on pre-shared keys |
11:33.33 | freemangordon_ | (MiFare security that is) |
11:33.56 | *** join/#neo900 Xseba360 (~Xseba360@user-94-254-193-37.play-internet.pl) |
11:34.02 | wpwrak | in BUE, we have two fare card systems: one that was done by the city in cooperation with credit card companies (monedero, dying in the fare domain but now being diversified into other areas - with questionable success), and the other pushed by the national government (pretty successful, you charge a credit to the card. tracks all your movements, but you can easily get "anonymous" cards) |
11:34.20 | wpwrak | yes, that could be just mifare |
11:34.52 | freemangordon_ | I am almost sure it is just MiFare card |
11:35.06 | freemangordon_ | BTW "our" chip supports it as well |
11:35.44 | freemangordon_ | I did some experimenting with S3 (which has the same chip) an year or so ago, it works pretty much ok |
11:36.54 | wpwrak | i can already imagine a nice attack scenario: a) equip/find smartphones with enhanced RF (for better range), b) create a "club of freeriders", c) set up a p2p network where members can steal from any card within reach, d) when you pay, you send a call for fare on your network, which then one of the members will answer - with stolen credentials. |
11:37.58 | *** join/#neo900 M13 (~MirandaLS@83.149.35.22) |
11:38.00 | wpwrak | that wuold also defeat local protection against multiple use of the same card. of course, if they don't even have that, you could just pick someone who is crossing the barrier when you do |
11:38.12 | jonwil | On my local transit network if the inspectors are working (which they sometimes do on trains and occasionally on buses) they not only check the card with a reader doohicky but they also physically inspect the card |
11:38.44 | jonwil | If you cloned the card to another card (or a phone) you would probably be treated as though you had no card |
11:38.46 | wpwrak | (experimenting with S3) S3 acting as card or as reader ? |
11:38.49 | jonwil | and get hit with a big fine |
11:38.57 | jonwil | So anyhow, pulseaudio-* is OFF the table for reverse engineering (by me anyway) |
11:39.05 | jonwil | As is eapd |
11:39.07 | jonwil | and powervr |
11:40.31 | jonwil | even the smaller pulseaudio blobs used for meego-on-N900 are still far too complex to understand |
11:40.41 | wpwrak | jonwil: never hard of controls on the subway in BUE. on trains, they have about 90% of the passengers jump/bypass turnstiles, to give you an estimate of the level of compliance to expect :) |
11:40.50 | jonwil | heh |
11:42.36 | jonwil | I think people who ride without paying are the scum of the earth, they are basically stealing from the transport company |
11:42.51 | jonwil | and making it more expensive for fare-paying passengers like me |
11:45.13 | wpwrak | jonwil: well, here it's a cultural thing. everybody is trying stealing from someone else, so in the end it evens out. e.g., the transport companies exist on lavish government-paid subsidies anyway. the pax fares are just for show. and the subsidies get squandered both by companies and government. e.g. they had lush funds for critical infrastructure work. |
11:45.35 | jonwil | makes sense :) |
11:46.04 | wpwrak | after decades of neglect, it took an accident with 50+ dead before at least bumpers were replaced. (which proved to be a very very good idea, just weeks later, when another train failed to stop) |
11:47.07 | jonwil | My local transit network has announced that because of the removal of a federal government tax, fares will be cut by 5% |
11:47.33 | wpwrak | the rails are still awaiting maintenance, though (that accident was a few years ago, so there's no hurry anymore), but to keep those embarrassing derailments out of the press, trains move below walking speed in critical areas. like switches or curves. |
11:48.07 | jonwil | Here they do actually do maintanence on the network |
11:48.22 | wpwrak | from my office i have a view of part of the train station where that 50+ victims accident happened. and i can see the trains crawl in and out. sometimes it's hard to tell they're moving at all. |
11:50.04 | wpwrak | oh, and they also plan to put some of the tracks into tunnels, to avoid the level crossings that constantly cause accidents (in part because people are just stupid and try to cross when the half-barriers are down, but in part also because it's sometimes not clear whether a train is really coming or whether the barriers are just malfunctioning) |
11:50.19 | jonwil | Although they do seem to have a lot of "at police request xyz is shut down, delays are expected" notices on their official Twitter account |
11:51.21 | wpwrak | these plans have been around since ... i think when the british lost interest in running argentina's train network, some 100 years ago. yet not much had happened since - at least not in the parts under control by the national government. |
11:51.26 | freemangordon_ | wpwrak: acting as a card |
11:51.51 | wpwrak | on the other hand, the city has been converting a few bothersome crossings. at least someone has a concept of doing their job. |
11:52.25 | wpwrak | freemangordon_: do they provide an app or did you have to use some hack to get this to work ? |
11:53.16 | freemangordon_ | we have some specially cooked firmware from sammy |
11:53.34 | wpwrak | aah. you're part of the inner circle :-) |
11:53.37 | freemangordon_ | which supported some API |
11:54.13 | freemangordon_ | but I programmed the SIM via an external chip reader and a SW from Gemalto |
11:54.31 | freemangordon_ | by issuing APDUs to the card |
11:55.20 | freemangordon_ | wpwrak: (inner..) not exactly, it was one of the local mobile operators that was in there ;) |
11:55.28 | wpwrak | programming the SIM required certain privileges you have but most of us wouldn't enjoy, correct ? |
11:55.50 | wpwrak | (mob op) insideness by proxy ;-) |
11:56.15 | freemangordon_ | yep, you need to know a couple of keys to be allowed to program the card |
11:57.42 | *** join/#neo900 Mihanizat0r (~MirandaLS@83.149.35.170) |
12:00.21 | freemangordon_ | jonwil: could you please look at con_ic_connect function in nm-nav-provider, is it me or g_mutex_lock is called twice for one and the same mutex? |
12:03.21 | jonwil | I dont see any calls to g_mutex_lock in nm-nav-provider |
12:04.11 | freemangordon_ | yeah, it is a bit complicated |
12:04.29 | freemangordon_ | it is called via a function pointer |
12:04.41 | freemangordon_ | initialized when glib is initialized |
12:04.45 | freemangordon_ | howeve |
12:04.49 | freemangordon_ | r |
12:05.18 | freemangordon_ | actually it is g_static_mutex_lock macro |
12:06.07 | wpwrak | freemangordon_: i suppose things like mifare wont be given access to a SIM, right ? i.e., mob ops would be likely to reserve that privilege for higher-value entities, like banks, correct ? |
12:07.30 | wpwrak | so if we wanted to use myfare and the like, we'd either have to break it, or set up some networked relay. e.g., card on reader at home, smartphone connects over internet |
12:07.44 | freemangordon_ | wpwrak: you mean if MiFare reader can access anything but MiFare part of the SIM card? |
12:07.52 | freemangordon_ | ofc not |
12:08.30 | wpwrak | what i mean is whether mob ops are likely to admit applications like mifare to their SIM |
12:09.36 | freemangordon_ | well, if there is a business case, why not? |
12:10.26 | wpwrak | sure. is there ? i.e., are they doing this ? or are they reserving their precious space for bigger fish ? |
12:11.02 | freemangordon_ | it is not like that, a JavaCard has plenty of free space on it :) |
12:11.39 | wpwrak | i've heard that before, "640 kB is more than enough" ;-)) |
12:11.53 | freemangordon_ | http://en.wikipedia.org/wiki/Java_Card |
12:13.02 | freemangordon_ | such a card runs jvm and http server, so I imagine it has plenty of space/memory |
12:13.55 | wpwrak | oh, even http. wow. |
12:14.08 | wpwrak | amazing for 1996 technology. |
12:17.30 | wpwrak | lemme rephrase my question: do you know of cases where "lesser" applications (fare cards, other low-value charge cards, supermarket fidelity cards, etc.) have been incorporated into SIMs, be it pre-installed or as a field upgrade (all with the cooperation from the SIM issuer, of course) ? |
12:19.40 | freemangordon_ | no, but keep in mind we are not exactly bleeding edge here :). If there is such a thing like "bleeding edge" given that it is only recently phones with NFC to become widespread |
12:20.40 | freemangordon_ | what an irony - nokia was pushing NFC for ages, now there is no nokia it becomes reality |
12:21.06 | wpwrak | and even on a former nokia platform ;-) |
12:23.16 | wpwrak | (bleeding edge) yeah, i'm trying to reduce the "known unknowns" a bit. predictions are always hard, but if we have an idea of what's already out there in the field, that already helps |
12:24.14 | jonwil | my bank has given me one of those stupid Visa contactless cards, never use the thing, I pay more fees if I use it than if I use EFTPOS debit |
12:24.17 | wpwrak | helps at least to have more graceful responses to "oh, you have NFC ! so can I do X ?" than "errm, interesting question... wee, ehm, haven't really though of that, err, ..." :) |
12:25.12 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
12:25.18 | wpwrak | yeah, saw that the visa i got last week also has that stuff. still have to find out of it's already a risk if i don't touch it at all. |
12:36.52 | *** join/#neo900 modem (~modem@fsf/member/modem) |
13:04.04 | *** join/#neo900 DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
13:04.04 | *** mode/#neo900 [+v DocScrutinizer05] by ChanServ |
13:11.12 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
13:29.29 | DocScrutinizer05 | ((if it's already a risk if i don't touch it at all)) only when you carry it into public. I strongly suggest using metal coated wrapper for the card |
13:30.02 | DocScrutinizer05 | so it cannot do any RF activity until you take it out from that wrapper/sleeve |
13:30.20 | DocScrutinizer05 | those wrappers are already commercially available |
13:41.16 | wpwrak | yeah, if i can't get them to disable the "feature", then that seems to be the only way :-( |
13:44.56 | enyc | I can totoally believe the whole its ocmplicated wont be out this year thing |
13:45.10 | enyc | but can these issues be listed on webpage/article? ;-)) |
13:52.09 | DocScrutinizer05 | issues? |
13:55.18 | DocScrutinizer05 | enyc: the complications been a almost 6 months delay due to organizational restructuring |
13:58.25 | DocScrutinizer05 | we fist had to wait for funds getting transferred by our supporters/donors from GDC to Neo900 UG before we were able to contract GDC for continued development |
13:58.30 | DocScrutinizer05 | first* |
14:02.43 | enyc | kk |
14:03.13 | enyc | DocScrutinizer05: can this be written into artcile partIII and just write down what the complications are on one papage, and what remainig tasks are ... and what you woul like help with are ... |
14:05.22 | DocScrutinizer05 | we will try to do this, yes. List of remaining tasks is not exactly simple thing to do |
14:06.29 | DocScrutinizer05 | unless we just state "build and test proto_V2 (ongoing), build and test proto_V3, get all parts and build series devices" |
14:08.28 | DocScrutinizer05 | one thing we for sure would like help for: find or create all the linux drivers needed for all the subsystems listed in http://neo900.org/stuff/werner/web/gta04b7v2-wip-2014092209.pdf |
14:08.56 | enyc | DocScrutinizer05: indeed, just keep updating th elist. point to a wiki page from the partIII page |
14:09.05 | enyc | DocScrutinizer05: so the task list can be amended etc etc |
14:13.29 | DocScrutinizer05 | wpwrak: we've not yet decided if we go for 32 or 64 GB of eMMC |
14:14.15 | enyc | wpwrak: whats the compromises? only cost? |
14:14.17 | DocScrutinizer05 | I think the idea of using second uSD instead of eMMC is off the table, right? |
14:15.18 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
14:17.13 | DocScrutinizer05 | (off the table) due to interface bandwidth |
14:19.48 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
14:22.43 | DocScrutinizer05 | enyc: ((find or create all the linux drivers)) we will need that in 3 months or so, to test proto_V2 |
14:23.11 | DocScrutinizer05 | for most if not all of those subsystems there whould be drivers readily available |
14:24.43 | DocScrutinizer05 | s/whould/should/ |
14:28.14 | DocScrutinizer05 | [note to everybody] get your system updated to fix bash! |
14:31.25 | wpwrak | DocScrutinizer05: (uSD vs MMC) i'd still like the flexibility of a card, even if it's a bit slower. |
14:31.53 | DocScrutinizer05 | it's always hard to believe which funny simple bugs linger on in core software for ages until somebody finds out about them |
14:32.11 | DocScrutinizer05 | wpwrak: we have one card |
14:32.28 | wpwrak | (uSD) less sourcing pain and a lower BOM cost would be additional benefits :) |
14:33.13 | wpwrak | yup. once card is good, two would be better :) especially if the 2nd is of the slot-in type and accessible without opening the case. like in the ben. |
14:33.15 | DocScrutinizer05 | well, that's arguable, and not really a valid point for design |
14:33.45 | wpwrak | then one could also use it as a connector with UBB -> very convenient hackability |
14:34.11 | DocScrutinizer05 | you can do same with internal uSD |
14:34.28 | DocScrutinizer05 | plus we got hackerbus for that |
14:34.53 | enyc | DocScrutinizer05: and you need all the linux_drivers to pass/test the board properly +? |
14:35.10 | DocScrutinizer05 | sure |
14:35.12 | enyc | DocScrutinizer05: rather than accepting some things will need softawer fixed after hardware released (for 'optional' things ?) |
14:35.43 | DocScrutinizer05 | we need to test the hardware, how we gonna do this without at least some form of driver for it |
14:36.00 | wpwrak | internal uSD and hackerbus are inside -> less easy to access. dunno how painful they will be in the end, but i doubt anything can beat UBB in terms of easy access :) |
14:36.11 | enyc | DocScrutinizer05: kk i see so this is rather more than reorganizing GTA04 board for neo900 hrrm |
14:36.25 | DocScrutinizer05 | USB will beat it hands down |
14:36.52 | wpwrak | for hacking ? USB is a LOT more complex |
14:37.11 | DocScrutinizer05 | for hacking you don't need external plugs |
14:37.57 | DocScrutinizer05 | nah, forget about that |
14:38.14 | wpwrak | i use UBB for outbound JTAG, all sorts of in-circuit programming protocols, etc. it's not for hacking the device (ben / neo900) but for playing with a circuit. it's great to have a full linux system available for these things. |
14:38.27 | DocScrutinizer05 | what device lacks is fast storage, we need to get at least one that's as fast as possible |
14:38.38 | *** join/#neo900 mvaenskae_ (~mvaenskae@unaffiliated/mvaenskae) |
14:39.15 | wpwrak | yeah, i didn't expect to be able to change your mind on the eMMC issue :) |
14:39.20 | DocScrutinizer05 | wpwrak: sorry for the inconvenience but you will have to open the battery lid for that |
14:40.00 | wpwrak | regarding hackerbus, how does one connect to it ? will it be a connector, some special board, solder contacts, ... ? |
14:40.15 | DocScrutinizer05 | I'd be more than happy to fulfill your dreams re external uSD slot if it could compete with eMMC bandwidth |
14:41.05 | DocScrutinizer05 | ((hackerbus)) not yet decided, suggestions welcome |
14:41.51 | DocScrutinizer05 | I already elaborated on position: on daughterboard right above hinge of uSD tray |
14:42.27 | wpwrak | how many contacts will HB have ? |
14:42.47 | DocScrutinizer05 | probably pads are just fine, so our hackers could either solder or use pogopins |
14:43.07 | DocScrutinizer05 | last time I counted I think it been some 14 or so |
14:44.02 | DocScrutinizer05 | maybe make that thru hole pads |
14:44.14 | wpwrak | something pluggable would be preferable. if you have to solder, you either have to come up with your own connector system or you have a very high cost of switching between projects |
14:44.18 | DocScrutinizer05 | would even allow special connectors to plug in directly |
14:44.42 | wpwrak | would we gave enough room for 50 mil or 1 mm headers ? |
14:44.48 | wpwrak | #s/gave/have/ |
14:45.23 | wpwrak | pogos are messy because you now only need those expensive pins but also a mechanical fixture that holds them in place. that's a serious amount of work. |
14:45.35 | DocScrutinizer05 | check it out! the area is ~ 5x15mm |
14:46.33 | wpwrak | 5 x 15 mm in the xy plane should be enough for headers (checking ...). how much height is available ? |
14:46.43 | DocScrutinizer05 | might even suffice for standard posts |
14:47.11 | DocScrutinizer05 | ((height)) you tell me, after finishing the scans ;-) |
14:47.30 | DocScrutinizer05 | also depends on exact make of the daughterboard |
14:47.33 | wpwrak | best to have receptacles on the neo900. less risk of bending, accidental contact, etc. also, they're a wee bit harder to source, so it's nice if they come with the device |
14:47.56 | DocScrutinizer05 | yep, ack |
14:48.21 | DocScrutinizer05 | is there a thing like 1.25mm post connectors? |
14:48.30 | DocScrutinizer05 | I think there is |
14:49.16 | DocScrutinizer05 | should take simple wires as well. Pretty convenient |
14:50.10 | wpwrak | "Height Above Board" starts at 2.1 mm (for 0.8-1.27 mm pitch, 1.00-1.27 row spacing) |
14:50.44 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
14:52.02 | DocScrutinizer05 | https://de.wikipedia.org/wiki/Stiftleiste |
14:52.43 | wpwrak | something like this one maybe: http://www.digikey.com/product-detail/en/M50-3150842/952-1373-5-ND/2264354 |
14:53.01 | DocScrutinizer05 | 2.1mm - without any checking, only guts feeling - seems feasible |
14:54.15 | DocScrutinizer05 | yup, seems that's exactly what I thought of. can also get rear-mounted and plug posts go through holes in PCB |
14:54.42 | DocScrutinizer05 | (not this particular one maybe) |
14:54.48 | wpwrak | yup. plenty of possibilities |
14:55.00 | wpwrak | "Receptacle, Bottom or Top Entry" :) |
14:55.22 | DocScrutinizer05 | :-D |
14:55.37 | DocScrutinizer05 | and only 2.1mm height. Great! |
14:55.56 | wpwrak | 2.2 +/- 0.25 mm |
14:56.07 | DocScrutinizer05 | as said: I haven't checked at all yet, but that's what I planned to check |
14:56.12 | wpwrak | says the data sheet |
14:56.47 | DocScrutinizer05 | I think we have "plenty of2 space below daughterboard |
14:57.39 | DocScrutinizer05 | unless our B2B connector connecting DB sits exactly in this position, on the rear |
14:58.42 | DocScrutinizer05 | (which of course is something we should have under control) |
15:00.41 | DocScrutinizer05 | even on N900 DB this area is basically unused and free for "future use" |
15:02.15 | DocScrutinizer05 | suspects Nokia only placed the test points under battery to allow for easier fixture of the pogopin thingie, just mimics a battery that snaps into bay |
15:03.42 | wpwrak | it's nice to be able to do tests with the complete case present, yes |
15:05.33 | DocScrutinizer05 | counting again (let's hope I don't miss out on sth): USB:4 + I2C:2 + UART:4 + GND (+ VBAT, other VCC), yup around 12..14 contacts |
15:06.21 | DocScrutinizer05 | (complete case) I rather meant: why they didn't place the pads more conveniently, so they were reachable without removing batt |
15:07.22 | DocScrutinizer05 | I missed sth: IRQ |
15:07.52 | wpwrak | is it really a good idea to route usb there ? i could imagine that this may introduce signal integrity issues |
15:07.58 | DocScrutinizer05 | we want a IRQ/WAKE/RING signal (bidir?) for sure. We also *might* want audio |
15:08.21 | DocScrutinizer05 | (signal integrity) yes, that's a huge concern |
15:08.51 | DocScrutinizer05 | needs careful routing, to have short T branches |
15:09.43 | DocScrutinizer05 | then OTOH USB connector (main) is as close to DB as it gets |
15:10.51 | DocScrutinizer05 | shouldn't be a huge detour for routing. And the T branch is no longer than maybe 5mm max |
15:10.54 | wpwrak | does it really have to be there ? guess most applications will be happy with one method of communication, e.g., USB xor I2C xor UART. and for usb you already have a proper connector |
15:11.32 | DocScrutinizer05 | yes, we need USB since the other methods/IFs have "insufficient" bandwidth |
15:11.57 | DocScrutinizer05 | think RTL-SDR |
15:12.08 | wpwrak | (interrupt) in general, the more gpios the better. one concern is 1.8 V, though. that's not the world's most convenient voltage for DIY critters. manageable, but still uncommon. |
15:12.23 | DocScrutinizer05 | yup |
15:12.38 | DocScrutinizer05 | I'm aware of this. hackerbus needs proper protection |
15:12.40 | wpwrak | (other methods) just make a general USB board ? |
15:12.49 | DocScrutinizer05 | hm? |
15:13.47 | wpwrak | a rtl-sdr board wouldn't have to be neo900-specific. so why would someone want to design it for the neo900's custom connector when they can make it generic, with a standard usb connector ? |
15:14.10 | DocScrutinizer05 | that's the plan more or less |
15:14.10 | wpwrak | sounds like an improbable use case |
15:14.32 | DocScrutinizer05 | no, it's actualy a very likely and much asked for usecase |
15:14.53 | wpwrak | funny |
15:15.01 | DocScrutinizer05 | get cheap RTL-SDR stick, dismantle, unsolder USB plug, connect to hackerbus |
15:15.29 | wpwrak | hmm. let's see if anyone will actually do it :) |
15:16.08 | DocScrutinizer05 | our design is not driven by "will anybody do it?" but by "what *could* get done?" |
15:16.13 | wpwrak | from my qi-hw experience, i see a lot of people ask for features they'll never actually use. kids may love the candy store but they can't eat all the lovely things in there :) |
15:16.41 | DocScrutinizer05 | chicken-egg problem |
15:16.45 | wpwrak | yeah, but it's frustrating if you spend weeks on designing something, and everybody pays for it, and then it sees zero use |
15:17.11 | wpwrak | naw, the eggs have been provided (in the qi-hw case) but the chicken ignored them |
15:17.19 | DocScrutinizer05 | the BOM and development cost particularly for USB on hackerbus are negligible |
15:18.03 | wpwrak | sure. i'm only concerned about signal integrity. usb is the sort of thing that's no pleasure to debug at that level. especially not high-speed. |
15:18.32 | wpwrak | besides, for hardware hacking, i'd rather have more general-purpose gpios |
15:18.47 | DocScrutinizer05 | yep, i'm aware of this. Then OTOH I seen USB cable contrapture that make your toenails curl and still the stuff worked |
15:19.15 | DocScrutinizer05 | sorry, GPIOs are a penny a dozen, with I2C extender |
15:20.06 | wpwrak | not exactly what i'd call convenient |
15:20.11 | wpwrak | and slow |
15:20.17 | DocScrutinizer05 | and actually iirc you can dual-use the USB IF on OMAP, nearly *everything* is also a GPIO |
15:20.43 | DocScrutinizer05 | ooh, not USB ;-P |
15:20.44 | wpwrak | what if i want to do spi plus a few control signals ? with gpios, i can do that easily |
15:20.59 | DocScrutinizer05 | sorry, waiting for coffee to kicj in |
15:21.03 | wpwrak | hehe :) |
15:22.21 | DocScrutinizer05 | Neo900 isn't that sort of development board |
15:22.51 | DocScrutinizer05 | we need maximum flexibility in minimum number of interface pins |
15:23.57 | DocScrutinizer05 | you got UART3, use it a 4 GPIO if you want to. Sorry, 4 GPIO (plus one for IRQ and maybe another one for RING) is as good as ot gets |
15:25.15 | DocScrutinizer05 | Neo900 is similar, but not identical (purpose) to BeagleBoard |
15:26.08 | DocScrutinizer05 | and a lot of hw extensions you could think of will need the 480MBps USB speed |
15:26.35 | DocScrutinizer05 | e.g. SDR |
15:26.56 | DocScrutinizer05 | or cameras (FLIR) |
15:27.10 | DocScrutinizer05 | or additional displays |
15:27.22 | DocScrutinizer05 | or audio extensions |
15:28.57 | DocScrutinizer05 | for your simple numeric key block you will have to cope with using a I2C interface chip, no way we expose sufficient GPIO so you could attach the matrix directly |
15:29.26 | DocScrutinizer05 | just for "convenience reasons" |
15:30.41 | wpwrak | my applications so far (with UBB) are mainly various in-circuit programming protocols, driving of key signals in mechanical design prototypes, and such. |
15:30.58 | wpwrak | if i need more "intelligence" , then i add an MCU anyway |
15:30.58 | DocScrutinizer05 | so? use uSD! |
15:31.38 | DocScrutinizer05 | conveniently positioned exactly next to hackerbus |
15:31.51 | wpwrak | yeah, i'll have to check if UBB could be used in the N900 |
15:33.28 | DocScrutinizer05 | and "ship a hacker prototype board, possibly on flex PCB, with a MCU already pre-installed" was actually a suggestion from our users |
15:34.23 | DocScrutinizer05 | I considered to actually do that, when I still thought our hackerbus would sit under battery (max inconvenience) |
15:35.22 | DocScrutinizer05 | nevertheless you designing such a hacker tool and offering it as accessory for Neo900 would for sure get appreciated |
15:36.01 | wpwrak | yes, people will praise you - and nobody will buy it :) |
15:36.23 | DocScrutinizer05 | *shrug*. Depends on your marketing |
15:36.33 | DocScrutinizer05 | same been said about Neo900 |
15:37.04 | DocScrutinizer05 | collect enough preorders before you even start designing it |
15:37.23 | DocScrutinizer05 | "you" meant literally as wpwrak here |
15:37.31 | DocScrutinizer05 | ;-) |
15:37.48 | wpwrak | think neo900 is much easier to sell than such a board |
15:37.56 | DocScrutinizer05 | probably |
15:38.21 | DocScrutinizer05 | I also don't see demand reaching 3 fugure numbers |
15:38.26 | DocScrutinizer05 | figure* |
15:38.47 | DocScrutinizer05 | then otoh how many UBB got sold? |
15:39.46 | wpwrak | don't know the numbers, but not a lot. even these were too demanding (= require soldering). rather disappointing, that experience. |
15:40.20 | wpwrak | well, i use them a lot and i'm rather happy with them, so at least i got what i wanted :) |
15:41.43 | *** join/#neo900 modem (~modem@1.17.90.92.rev.sfr.net) |
15:42.22 | *** join/#neo900 modem (~modem@fsf/member/modem) |
15:42.22 | DocScrutinizer05 | hehe |
15:42.28 | wpwrak | perhaps one problem with UBB was the pricing: at tuxbrain they were i think around EUR 5 apiece, at pulster they're now EUR 4. i wish they had been sold in packs of ten or so, not individually. |
15:42.48 | wpwrak | i mean, there are few things that are easier to produce in huge volume than UBB :) |
15:42.59 | mvaenskae | nobody thought pre-facebook that people will fly in like flies towards sith but humanity has once again proven humans wrong; may i ask what UBB is? :D |
15:43.00 | DocScrutinizer05 | :nod: |
15:43.29 | wpwrak | mvaenskae: http://en.qi-hardware.com/wiki/UBB |
15:44.18 | wpwrak | fun things you can do with it: vga http://downloads.qi-hardware.com/people/werner/ubb/vga/web/ |
15:44.22 | mvaenskae | is the one side a microSD connector? |
15:44.47 | wpwrak | logic analyzer: http://downloads.qi-hardware.com/people/werner/ubb/la/ |
15:45.00 | mvaenskae | if it really is universal then that looks fun |
15:45.06 | wpwrak | pattern generator: http://downloads.qi-hardware.com/people/werner/ubb/patgen/ |
15:45.26 | wpwrak | jtag: http://downloads.qi-hardware.com/people/werner/ubb/jtag/ |
15:46.00 | mvaenskae | would that jtag allow reprogramming of the hardware on the neo900? |
15:46.38 | mvaenskae | but wow, that thing is awesomely cool |
15:46.47 | wpwrak | drive a test board with OLED and jog wheel: http://downloads.qi-hardware.com/people/werner/anelok/tmp/dui-arrow.jpg (UBB not visible, but the cable on the left ends with one) |
15:47.41 | mvaenskae | wpwrak: why didn't it sell again? |
15:48.20 | wpwrak | drive a passive test / programming fixture: http://downloads.qi-hardware.com/people/werner/anelok/tmp/ybpgm-0-parts.jpg |
15:49.58 | wpwrak | in-circuit program an AVR: http://downloads.qi-hardware.com/people/werner/tmp/c2-use.jpg |
15:50.39 | freemangordon | Pali: could you look at http://pastebin.com/qZzG7AGE ? That code is part of nm-nav-provider (according to hexrays). It is either hexrays is buggy (though I looked at the disassembly too and it looks like it is not) or that nokian had NFC what is thread and what is mutex and how to use them. I can pastebin the original hexrays output if needed |
15:50.56 | wpwrak | another test fixture: http://downloads.qi-hardware.com/people/werner/tmp/lt-pgm-ben.jpg |
15:51.21 | freemangordon | BTW if anyone else feels comfortable with that matter may look at the code too |
15:51.25 | wpwrak | don't like to make fixtures ? there's direct soldering, too: http://downloads.qi-hardware.com/people/werner/tmp/lt-pic-proto.jpg |
15:52.06 | wpwrak | and it works for in-circuit programming NXP's LPCxxxx, too: http://downloads.qi-hardware.com/people/werner/tmp/tornado2-cpu-blink.jpg |
15:52.14 | wpwrak | and so on :) |
15:53.01 | wpwrak | (didn't sell) seems that people were afraid of getting their hands dirty with actually making circuits |
15:53.38 | mvaenskae | wpwrak: i for one had no idea that a uSD slot can be this powerful |
15:54.00 | DocScrutinizer05 | hah! told ya. Marketing |
15:54.01 | mvaenskae | and there is also an even more advanced project at the end of the ubb page, very cool ideas |
15:54.26 | mvaenskae | i bet the ubb would sell like hotcakes once shown a cool implementation with the neo900 |
15:54.42 | DocScrutinizer05 | harly anybody ever heard of ben NN or qi-hardware |
15:54.51 | wpwrak | the VGA thing abuses the MMC controller (and pretty much takes over the whole little ben). else i couldn't do 1026x768. all the rest uses uSD just as a bunch of GPIOs and for power |
15:55.16 | mvaenskae | maybe have some starter tutorials on some simple and easy to acquire things and you can get at least those interested hooked on one |
15:55.32 | DocScrutinizer05 | hands wpwrak a "king of hackers" medal |
15:55.43 | wpwrak | feels flattered :) |
15:56.00 | mvaenskae | i for one have as mentioned not a big clue what i could do with it, BUT if i had i would order like 10 of them likely |
15:58.06 | DocScrutinizer05 | wpwrak: btw to use ubb in Neo900 you probably need to grab your coarse file and take away substantial parts of the plastic case |
15:58.29 | DocScrutinizer05 | or shorten ubb |
15:58.39 | wpwrak | (things in the way) yeah, with this sort of holder that's often the case |
15:59.31 | wpwrak | (shorten ubb) could perhaps make it end in a 50 mil receptacle. not sure if this would be enough, though. |
15:59.46 | freemangordon | not a single C developer here? Oo |
15:59.53 | mvaenskae | could i reprogram a 32plcc chip with that? |
16:00.06 | mvaenskae | freemangordon: aspiring C developer here |
16:00.16 | mvaenskae | but i am not really far into C yet :/ |
16:00.16 | DocScrutinizer05 | looks at C hacker per definitionem: wpwrak |
16:01.00 | DocScrutinizer05 | freemangordon: I think the context is lacking. |
16:01.45 | DocScrutinizer05 | general rule: if you want irc users have a look at $random-document, provide enough info why they might be temped to go there |
16:01.52 | wpwrak | mvaenskae: that would depend on the chip :) |
16:02.13 | mvaenskae | http://pdf1.alldatasheet.com/datasheet-pdf/view/133493/MCNIX/MX29LV040CQC-70G.html this one in particular |
16:03.07 | mvaenskae | best would be a setup where i am not in need of desoldering the chip and the ubb seems like a very smart and cool solution if i had that on my neo900 for mobile chip reprogramming :D |
16:03.16 | DocScrutinizer05 | rationale for "general rule": nobody is supposed to click on a URL to find out what it is. And when not even doing so nevertheless reveals what been the question, nobody ever will answer |
16:03.17 | wpwrak | bad: "something seems wrong in some obscure subsystem when i do something obscure" |
16:03.23 | wpwrak | good: "i'm trying to decode those celebrity nude pics but my program crashes" |
16:04.18 | mvaenskae | hm, it is a document about the chip housing the bios of my mips device where the bios is horribly outdated and broken |
16:04.57 | mvaenskae | and upon becomng better in C and hardware hacking i want to update it but i am fearing breaking the system thus getting a nice paperweight |
16:05.19 | DocScrutinizer05 | wpwrak: :-P |
16:05.39 | mvaenskae | if i could reprogram the chip from the outside i would be more likely to toy around with flashing as i am not in fear of breaking it :) |
16:05.47 | wpwrak | hmm, parallel flash memory. naw, you need lots of io pins for that |
16:06.10 | mvaenskae | DocScrutinizer05: add more uSD slots to the neo900 =p |
16:06.12 | mvaenskae | :D |
16:06.36 | DocScrutinizer05 | how would that make any sense when we only have one interface to share? |
16:06.56 | wpwrak | connect them to gpios ;-) |
16:06.58 | mvaenskae | :( |
16:07.12 | DocScrutinizer05 | yeah, bitbank the protocol |
16:07.21 | DocScrutinizer05 | why would we need a memory controller |
16:07.22 | mvaenskae | wpwrak: if i had 32 gpio ports i could use that to reprogram the chip from the outside? |
16:07.30 | DocScrutinizer05 | bitbang even |
16:07.55 | wpwrak | mvaenskae: i guess so. would depend on whether anything nasty is connected to it. but in general: yes |
16:08.10 | mvaenskae | wpwrak: it is soldered onto the motherboard... |
16:08.12 | wpwrak | if it's socketed, even better |
16:08.17 | mvaenskae | would i need to desolder it? :/ |
16:08.24 | wpwrak | ah, then you have to hope for the best :) |
16:08.45 | mvaenskae | i rather not solder around, i am terrible at that :( |
16:08.51 | wpwrak | you could try to do it in-circuit. power would be your main problem. |
16:09.06 | mvaenskae | in what sense? |
16:09.08 | wpwrak | but you'd have to reach the contacts somehow. which may be difficult |
16:09.32 | wpwrak | (power) if you apply power to the chip, that power will also supply other things. things that may act up. |
16:09.45 | mvaenskae | i can see the contacts from the side just fine but they go a couple mm below the chip as well and that's where the soldering happened |
16:10.20 | mvaenskae | so it's very nasty to desolder, especially if i have no desoldering station |
16:10.32 | DocScrutinizer05 | freemangordon: actually I don't see any question you asked, except "can somebody look at that code please?" |
16:11.17 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
16:11.35 | DocScrutinizer05 | a proper question might be "how does threading and mutex work in: http://pastebin.com/qZzG7AGE ?" |
16:11.58 | DocScrutinizer05 | but probably not even that is the question that's actually to the point |
16:13.25 | *** join/#neo900 e2718 (~hdesk@p4FD36F49.dip0.t-ipconnect.de) |
16:13.47 | freemangordon | DocScrutinizer05: the question is - how is that possible this code to be on a production device, did I overlook something, etc. |
16:13.54 | DocScrutinizer05 | when the question however is "Is hexrays buggy of a Nokia subcontractor coder had NFC?" then I already know what I bet on |
16:14.05 | DocScrutinizer05 | ;-) |
16:14.20 | *** join/#neo900 kolp_ (~quassel@55d40f22.access.ecotel.net) |
16:14.39 | DocScrutinizer05 | freemangordon: not specific enough a question |
16:15.08 | DocScrutinizer05 | "how is it possible that...2 usually never gets answered in any meaningful way |
16:16.16 | DocScrutinizer05 | pointing to a particular line and asking if this line looks like a coder error or a decompiler bug *might* help |
16:21.51 | *** join/#neo900 b1101 (~b@107.191.33.9) |
16:21.51 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
16:22.14 | DocScrutinizer05 | the code you pasted are 51 lines and no clue what this thing is all about and where to look to spot what you're talking about |
16:23.12 | DocScrutinizer05 | btw pali anounced that he's basically not available for quite some time (several months aiui) |
16:23.51 | DocScrutinizer05 | actually I asked him to stay in channel nevertheless |
16:24.12 | DocScrutinizer05 | doesn't mean he's online and available 24/7 |
16:25.01 | DocScrutinizer05 | is afk now too |
16:25.31 | DocScrutinizer05 | caught a mild cold, hoping for it not getting worse |
18:50.48 | freemangordon | DocScrutinizer05: ever heard about "code review"? |
18:55.30 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
19:02.23 | DocScrutinizer05 | yeah! takes at least 4h, plus another one work day for preparation. Usually done on sourcecode that's clearly defined by a module requirements specification. Shouldn't get done in a way where the reviewed coder explains own code, since otherwise the reviewer(s) will most likely fall for the same conceptual errors like the original coder |
19:05.19 | DocScrutinizer05 | there are two controversial schools abotu comments in sourcecode. While A says that comments are mandatory and should be sufficiently verbose and clear to allow understand the code's purpose without any additional docs, B says there mustn't be any comments in sourcecode, rather the source itself needs to be clear enough to be obvious |
19:07.20 | DocScrutinizer05 | generally despised is source code level optimization, this is considered obsolete since modern compilers beat every coder hands down on it. Rather code shall be clear and verbose |
19:09.31 | DocScrutinizer05 | review is frequently neglected though, particularly in FOSS where even signed-off-by doesn't mean anything anymore |
19:11.28 | freemangordon | that (because it is a time consuming task) I did not pasted the whole ~1800 lines of code, but just 50 of them, where IMO is something obviously fishy. And asked if anyone could look at it and comment |
19:11.30 | DocScrutinizer05 | or simply see https://en.wikipedia.org/wiki/Code_review |
19:11.33 | DocScrutinizer05 | ;-) |
19:12.23 | DocScrutinizer05 | well, I looked at it. My comment: no clue what it's all about |
19:13.31 | freemangordon | ok, thanks. doesn't calling 2 times G_LOCK on the same mutex in one and the same thread ring a bell? |
19:13.49 | freemangordon | or even 3 times |
19:14.52 | DocScrutinizer05 | looks like typical ARM compiler mega optimization that makes you wonder if the assembler code has *anything* in common with what you coded |
19:15.16 | freemangordon | G_LOCK translates to g_static_mutex_lock, which has undefined behaviour if called more then once from the same thread according to glib docs |
19:15.33 | DocScrutinizer05 | I'm not familiar with all the macros |
19:17.07 | DocScrutinizer05 | depending on compiler and libs this may expand to whatever and actually may be a valid optimization |
19:18.36 | freemangordon | "Note: GMutex is neither guaranteed to be recursive nor to be non-recursive, i.e. a thread could deadlock while calling g_mutex_lock(), if it already has locked mutex." |
19:19.15 | freemangordon | however |
19:20.21 | DocScrutinizer05 | to me it looks like compiler happily moved around and optimized code from one function into the other etc |
19:21.14 | DocScrutinizer05 | partial conversion to inline-function is a very usual optimization, I think |
19:21.32 | DocScrutinizer05 | when compiler concludes some code can get saved by this |
19:22.10 | freemangordon | what I am concerned is that such optimization could easily lead to a deadlock. if it is an optimization at all |
19:22.28 | DocScrutinizer05 | note there's a G_LOCK() in one function. maybe there's a G_UNLOCK() in another |
19:22.37 | freemangordon | yes, there is |
19:23.05 | freemangordon | but in that "one" function G_LOCK can be called 3 times in a row |
19:23.19 | freemangordon | which is undefined behabiour, see the ^^^ quote |
19:23.36 | DocScrutinizer05 | so instead of placing a G_LOCK() and G_UNLOCK() arounf each similar sequence of functions, the compiler maybe moved the former into first function and the latter into last |
19:24.27 | DocScrutinizer05 | a pretty simple optimization |
19:25.34 | freemangordon | I don;t believe gcc knows what G_LOCK/G_UNLOCK do, not to say that the function G_UNLOCK is called from is a callback. Still I am not concerned about having the mutex held without releasing it, rather I am concerned about (possible)calling of G_LOCK 3 times in a row |
19:26.04 | freemangordon | anyway, I'll attach a debugger and will see what happens |
19:26.56 | DocScrutinizer05 | {lock; A; C; D; unlock; Y; Z; lock; A; B; D; unlock;} -> {A; C; D; Y; Z; A; B; D; }; A(){lock;...} D(){...; unlock} |
19:28.43 | DocScrutinizer05 | make that {lock; C; D; unlock; Y; Z; lock; B; D; unlock;} -> {lock; C; D; Y; Z; lock; B; D; }; D(){...; unlock} |
19:29.27 | freemangordon | I am not sure changin the call sequence is an allowed optimization |
19:29.31 | DocScrutinizer05 | or any other permutation that fits |
19:29.43 | DocScrutinizer05 | it is |
19:30.01 | DocScrutinizer05 | also there's no change in call sequence |
19:30.07 | DocScrutinizer05 | not at all |
19:30.22 | freemangordon | yes, there is, lock() and unlock() are functions as well |
19:30.31 | DocScrutinizer05 | that's what compiler optimization does and it's usually beter on it than any coder |
19:31.55 | DocScrutinizer05 | the compiler even detects dependencies between A; B; C; and resorts the sequence just to do such optimizations, when the (missing) dependencies allow for |
19:33.06 | DocScrutinizer05 | usually for debugging you are better off when disabling any such mega optimizations at build time |
19:33.58 | DocScrutinizer05 | I spemt whole days trying to understand why what Lauterbach shown me on source level and what been the opcodes/assembler is actually equivalent |
19:34.08 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
19:34.13 | mvaenskae | erm |
19:34.22 | mvaenskae | DocScrutinizer05: can you help me understand something? |
19:34.28 | DocScrutinizer05 | dunno |
19:34.50 | freemangordon | DocScrutinizer05: no way the compiler can reorder library functions call sequence, it doesn't have information on what data those operate |
19:34.58 | mvaenskae | "user reports pixel errors, let's make an irreversible system update without notifying him and just return it without checking" |
19:35.18 | mvaenskae | i think i lost a couple braincells trying to follow the logic |
19:35.39 | DocScrutinizer05 | your bad! :-P there is no such logic, all a big void |
19:36.06 | DocScrutinizer05 | don't expect logic in service |
19:36.09 | mvaenskae | DocScrutinizer05: is it actually legal for a service repair center to make such an update without the owners consent? |
19:36.29 | DocScrutinizer05 | dunno. depends on their fineprint I guess |
19:36.47 | DocScrutinizer05 | usually they explicitly warn user that they might have to do it |
19:36.57 | mvaenskae | n.b: the owner was not notified such actions can happen upon applying for repairs at the counter and nothing was signed |
19:37.21 | DocScrutinizer05 | then they done sh*t, they lose |
19:37.46 | mvaenskae | good, i hope the fellas i will yell at will not have to work on saturday :) |
19:37.53 | DocScrutinizer05 | you won recompensation |
19:38.28 | DocScrutinizer05 | however will be *very* hard to get that |
19:38.46 | mvaenskae | not if i can still se the failures |
19:38.47 | DocScrutinizer05 | in the end you'll win, but it may take years |
19:39.19 | mvaenskae | even better, i should ask a couple students i study with to take a look at what they think is faultless so that i have witnesses :) |
19:39.35 | mvaenskae | in case they try to tamper with it someway |
19:39.58 | DocScrutinizer05 | freemangordon: ((doesn't have information)) you sure about that? |
19:40.35 | DocScrutinizer05 | freemangordon: particularly when you don't know which compiler been used at all |
19:40.58 | mvaenskae | is the question about reordering in C? |
19:41.09 | DocScrutinizer05 | :nod: |
19:41.46 | DocScrutinizer05 | though... for decompilations you only can do educated guess even about it being C sourcode |
19:41.52 | mvaenskae | i would take extensive care in processors these days, it still might schedule some stuff to have full hyperthreading running and other reorderable things and branches |
19:42.35 | DocScrutinizer05 | compiler does exatly this, even exploits it to optimize code |
19:43.14 | DocScrutinizer05 | we're not talking about portable sourcecode but about a decompiled binary |
19:43.31 | DocScrutinizer05 | ARM binaries are *nasty* |
19:43.45 | DocScrutinizer05 | exactly because such optimizations |
19:44.37 | DocScrutinizer05 | compiler ruthlessly reorders instructions and instruction groups to allow optimal pipelining |
19:45.19 | DocScrutinizer05 | when you try to decompile, you get giberish |
19:45.37 | mvaenskae | oh, so we are not given the source? |
19:46.23 | DocScrutinizer05 | no, aiui it's a xrays decompiler result |
19:46.30 | DocScrutinizer05 | hexrays |
19:47.08 | DocScrutinizer05 | thus the "peer review" mentioned by freemangordon been pretty misleading |
19:48.24 | mvaenskae | hm, so the decompiled code has been translated from assembler to C? |
19:48.31 | freemangordon | yes |
19:48.33 | DocScrutinizer05 | maybe hexrays can "guess" a lot of compile time optimizations and revert them to get "usual C code structures" |
19:48.37 | DocScrutinizer05 | but for sure not all |
19:48.48 | mvaenskae | don't trust the C stuff, assembler -> C can and will fail |
19:48.51 | freemangordon | DocScrutinizer05: I looked at the assembly code too |
19:49.01 | freemangordon | it still looks the same |
19:49.13 | DocScrutinizer05 | sure |
19:49.25 | DocScrutinizer05 | but the *source* for sure looked pretty different |
19:49.36 | mvaenskae | i would recommend only trusting the assembly code even if that is very unreadable and takes much longer |
19:49.48 | DocScrutinizer05 | :nod: |
19:50.26 | mvaenskae | translating it is fine to make it understandable but you have to be 100% it is a correct one :) |
19:50.53 | mvaenskae | i wouldn't be of much help though, never looked at arm assembly, only mips so far |
19:53.28 | DocScrutinizer05 | and pulling an unlock() from behind a function call into the called function at end looks like a typical optimization exploiting out-of-sequence execution in pipeline which delays the unlock() effects till after return from function completetd. For example |
19:54.20 | DocScrutinizer05 | makes code both faster and smaller |
19:54.27 | mvaenskae | maybe it is important to know the processor the code was written for and compiled on |
19:54.41 | DocScrutinizer05 | ARM I guess |
19:54.54 | DocScrutinizer05 | v7? |
19:55.57 | DocScrutinizer05 | compiler doesn't even need any knowledge about what unlock() does in this context, it's still a valid optimization |
19:56.29 | DocScrutinizer05 | given the function doesn't get called anywhere else without an unlock following *eventually* |
19:57.24 | DocScrutinizer05 | and I see compiler optimizations that handled a special case for this one other call of the function that doesn't fit into the optimization strategy |
19:57.33 | DocScrutinizer05 | i've seen, that is |
19:58.12 | DocScrutinizer05 | that's the daily headache ARM assembler code gives you |
19:58.38 | DocScrutinizer05 | best advice: switch off optimization during development and debugging |
19:59.34 | DocScrutinizer05 | when code got tested, compile with optimization and test again |
20:00.08 | DocScrutinizer05 | *usually* it's just smaller and faster with optimization, but functionally identical |
20:00.27 | DocScrutinizer05 | and massive gibberish when you decompile it ;-) |
20:04.14 | *** join/#neo900 mva (mva@gentoo/contributor/mva) |
20:10.45 | DocScrutinizer05 | LOL! TV news moderatress, for announcing a news story about beach, took off her shoes and walked around barefoot |
20:11.02 | DocScrutinizer05 | in studio |
20:13.21 | DocScrutinizer05 | bluebox madness "what? I'm not going to walk around in that virtual sand with my high-heels!" ;-) |
20:13.47 | DocScrutinizer05 | silly |
20:15.38 | DocScrutinizer05 | and looked pretty odd |
20:26.58 | DocScrutinizer05 | freemangordon: doesn't hexrays-for-ARM have an option to set the compiler which got used? Maybe even the version of compiler? AIUI hexrays is using a huuuge database to decode/ungarble whole sections of code, based on prior knowledge from its database about the optimizations and garbling the particular compiler does to simple strucktures like case, or if-then-else and also optimizations like the one we seem to face here |
20:27.37 | freemangordon | no, there is no such option |
20:27.42 | freemangordon | afaik |
20:35.03 | DocScrutinizer05 | check "analytic modules" if there's such a menu item. (I never looked into hexray/IDA) |
20:37.16 | *** join/#neo900 R0113 (~quassel@31-211-200-248.customers.ownit.se) |
20:38.38 | DocScrutinizer05 | ""facts about hexrays: [...] - Since decompilation in general is an unsolvable problem, the output is not 100% reliable (which is the case with disassemblers as well) "" https://www.hex-rays.com/files/hexrays_info.pdf ;-P |
20:47.51 | DocScrutinizer05 | hehe! https://www.hex-rays.com/products/decompiler/compare_arm0.shtml#5 |
20:55.17 | DocScrutinizer05 | can't find the user-community provided database mentioned anywhere. Probably I'm mixing it up with something else |
20:56.00 | Sicelo | just sending a greeting DocScrutinizer05 |
20:56.14 | DocScrutinizer05 | hi Sicelo :-) |
20:59.55 | Sicelo | :) |
21:02.02 | DocScrutinizer05 | waves and heads out for dinner |
21:09.32 | freemangordon | DocScrutinizer05: when you're back, check the backscroll on #maemo, it is nor hexrays neither gcc, but the nokia developer who coded that |
21:37.42 | DocScrutinizer51 | you might ahve missed, but I'm not on #maemo anymore |
21:39.27 | DocScrutinizer51 | but of course I would"mt doubt a millisecond that some of Nokia's code makes your eyes bleed |
21:40.53 | DocScrutinizer51 | actually seen some before, and allegedly some of the closed stuff is even worse. Dunno if it's always Nokia to blame though, or some of the subcontractors |
21:42.53 | DocScrutinizer51 | ~botsnack |
21:42.53 | infobot | DocScrutinizer51: thanks |
21:46.16 | freemangordon | DocScrutinizer05: in short - the code is buggy as hell, it just deadlocked (in gdb) |
21:46.27 | freemangordon | and yes, I have missed you're not on #maemo |
21:46.44 | freemangordon | code == stock nokia binary |
22:01.41 | Pali | DocScrutinizer51: problem is that they misused linux futexes... futex can be unlocked from any thread (not only which locked it) because kernel does not check owner of futex (due to speed) |
22:02.40 | Pali | and futex was used to make blocking function from async one (callback from async function unlock futex locked by blocked function) |
22:03.23 | freemangordon | Pali: not only that, actually it is even worse, the first thread that calls this function always deadlocks |
22:03.28 | freemangordon | verified with gdb |
22:03.32 | Pali | :D |
22:03.51 | freemangordon | because it calls G_LOCK twice, before calling con_ic_connection_connect |
22:03.56 | Pali | do you think that other mobile systems are better??? |
22:04.18 | Pali | I not |
22:04.19 | freemangordon | no idea, but this is... dunno |
22:09.19 | freemangordon | Pali: what happens if you unlock a futex that is not locked? |
22:12.44 | freemangordon | hmm, stupid question |
22:28.10 | DocScrutinizer05 | yuck! maemo the way we know and love it, no? |
22:28.44 | *** join/#neo900 jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
22:29.30 | freemangordon | :) |
22:29.49 | DocScrutinizer05 | freemangordon: realy stupid? nah, I'd think there are at least 2 possibilities: return immediately with "OK", or return immediately with "-ESTUPID". Possibly even "undefined behavior" |
22:31.08 | DocScrutinizer05 | Pali: seems Nokia loved to "misuse" stuff |
22:31.26 | DocScrutinizer05 | I just say "metapackage" |
22:32.12 | DocScrutinizer05 | or "hacked apt to 'protect' ovi store" - ROTFL |
22:34.16 | DocScrutinizer05 | mohamadAG: "download unhacked apt at $URL ;-) " |
22:34.36 | DocScrutinizer05 | misses moh a lot |
22:46.41 | FIQ | why was that necessary? |
22:47.09 | FIQ | isn't paid apps secured in some other twisted way, making the entire thing pointless |
22:48.12 | FIQ | now the only paid app that was actually remotely interesting back then was joikuspot... then someone made mobilehotspot |
22:53.00 | kerio | oooh, question |
22:53.03 | kerio | can the neo900 wifi do hostap? |
22:53.21 | kerio | without having it to do via software |
22:53.25 | Pali | freemangordon: kernel just try to find process (thread) which holding that futex and prepare it... so nothing |
22:53.26 | kerio | *having to do it |
22:55.15 | DocScrutinizer05 | kerio: check the advertising sheet of WLAN module |
22:56.19 | Pali | hm... another update for bash? |
22:57.29 | Pali | yesterday was update: SECURITY UPDATE: incorrect function parsing debian/patches/CVE-2014-6271.diff: fix function parsing in bash/builtins/common.h, bash/builtins/evalstring.c, bash/variables.c. CVE-2014-6271 |
22:57.46 | Pali | today is SECURITY UPDATE: incomplete fix for CVE-2014-6271 debian/patches/CVE-2014-7169.diff: fix logic in bash/parse.y. CVE-2014-7169 |
22:57.56 | Pali | how many bugs are in bash? |
22:58.11 | Pali | and how many CVEs will be tomorrow assigned for bash? |
22:59.42 | DocScrutinizer05 | Pali: those are madmen |
23:00.46 | DocScrutinizer05 | Pali: thanks anyway for again ponting at it |
23:01.20 | Pali | ok |
23:01.43 | DocScrutinizer05 | no update from Suse yet |
23:02.22 | Oksana | People who ride without paying... I know only one such person; an excellent chess player. Metal coated wrapper... Like, metal-mesh lined pocket in a coat. Internal uSD and hackerbus... Easier to water-dust-sand-proof, thank you. UBB is interesting.. As in, adding sensors and mobility and connectivity to a phone through uSD slot? |
23:02.58 | DocScrutinizer05 | cannot blame them, I guess a bugfix for vulnerability, however untested and buggy, was top priority to roll out. Today they do the beautifying |
23:03.03 | mvaenskae | Pali: just install bash and use busybox sh =p |
23:03.15 | DocScrutinizer05 | *cough* |
23:03.21 | DocScrutinizer05 | ~messybox |
23:03.21 | infobot | messy... err busybox is meant for lean scripting. Regarding all the missing options and immanent limitations (see su, passwd, nice, ps, diff as used by mc...) it's not really the interactive shell of choice. A lot of people hate busybox because a lot of system integrators don't understand the difference between busybox and a decent user interactive shell plus unix utils |
23:03.50 | Pali | messybox, yes :D |
23:04.03 | Pali | here is link for new bash patch: http://www.openwall.com/lists/oss-security/2014/09/25/10 |
23:04.26 | DocScrutinizer05 | I'll nervusly wait for a patch made for my distro |
23:05.37 | DocScrutinizer05 | Oksana: (UBB) yep, exactly |
23:05.38 | mvaenskae | DocScrutinizer05: so it is less a problem of bb but more one of useless coders? copy that :) |
23:05.44 | Pali | I'm happy that ubuntu does not have bash in /bin/sh |
23:06.31 | Pali | so system(3) libc function is not vulnerable |
23:06.32 | mvaenskae | Pali: you sure? i thought that's the default |
23:06.51 | Pali | no, ubuntu using dash for /bin/sh for a long time |
23:07.18 | DocScrutinizer05 | ~reinvent |
23:07.19 | mvaenskae | oh, interesting |
23:07.30 | Pali | I know this because internal echo command of dash does not support argument -e |
23:07.37 | DocScrutinizer05 | ~reinvent is <reply>"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer |
23:07.37 | infobot | okay, DocScrutinizer05 |
23:07.49 | Pali | and all Makefile(s) which using echo -e does not work on ubuntu :D |
23:08.04 | mvaenskae | hahaha, ubuntu, the source of all problems :D |
23:08.18 | mvaenskae | seriously, there is a reason i spend hours upon hours on gentoo |
23:08.31 | Pali | but really POSIX shell (/bin/sh) does not have any -e param |
23:09.02 | DocScrutinizer05 | ((dash)) yeah, meag annoyance |
23:09.03 | Pali | so it is perfectly correct to have echo without -e in /bin/sh |
23:09.08 | DocScrutinizer05 | mega, even |
23:10.14 | Pali | it is same as using system(3) call |
23:10.28 | Pali | php authors did not read man page |
23:10.43 | Pali | otherwise they should not have used it |
23:10.55 | DocScrutinizer05 | php authors were illiterate |
23:11.44 | DocScrutinizer05 | rumor has it they bonobo wrote the code they dreamt up after 8 beers |
23:11.51 | DocScrutinizer05 | their* |
23:11.53 | Pali | and same for anybody who write 'echo -e' in script which starts with #!/bin/sh or write 'echo -e' in any code which is invoked by system shell (defined by posix) |
23:12.28 | Pali | same for 'echo -n' |
23:12.32 | mvaenskae | whenever you feel really bad about your code, think always about php |
23:12.43 | mvaenskae | and that it will be where you end if you fail |
23:12.52 | mvaenskae | it keeps me going >3 |
23:12.55 | DocScrutinizer05 | anybody using /bin/binaries should qualify FQN anyway |
23:13.19 | DocScrutinizer05 | or not use bashisms |
23:13.33 | DocScrutinizer05 | or use #!/bin/bash |
23:13.51 | Pali | yes, #!/bin/bash is correct way to use echo -e or echo -n |
23:14.09 | DocScrutinizer05 | among others |
23:14.45 | DocScrutinizer05 | ~bq27k-detail |
23:14.46 | infobot | i heard bq27k-detail is http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2 |
23:17.14 | Pali | I think that perl is better option for complicated scripts as bash |
23:17.30 | Pali | and for simple scripts classic shell is enough |
23:18.00 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail-perl ;-D |
23:23.19 | DocScrutinizer05 | dang! maybe I just ran into a bash-induced bug in konqueror? clicking on a *.sh opens up a requester asking what to use to execute it, but that requester very unusually can't get closed resp pops up again infinitely |
23:24.23 | Pali | I think this is one of millions KDE/KIO/konqueror bugs |
23:24.47 | DocScrutinizer05 | had to actually kill the browser instance. And no, this is a pretty new bug |
23:25.04 | Pali | million or million+1... it is same |
23:25.32 | DocScrutinizer05 | maybe. Just I'm used to the million, not to the +1 though |
23:25.51 | Pali | last working version of KDE was 3.5 |
23:26.40 | Pali | akonadi, nepomuk, ... |
23:26.57 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27200.sh killed it |
23:27.14 | DocScrutinizer05 | Pali: 10000% ACK# |
23:27.29 | DocScrutinizer05 | unbearable crap |
23:27.55 | Pali | my own patched version of KDE4 kmail with removed akonadi and nepomuk: http://quickgit.kde.org/?p=clones/kdepim/pali/kdepim-noakonadi.git |
23:28.06 | DocScrutinizer05 | worst of all: developers have that "use most recent release, stupid!" idiotic mindset |
23:28.36 | DocScrutinizer05 | does it search in mail? |
23:28.48 | Pali | yes this is working! |
23:29.04 | Pali | without nepomuk |
23:29.16 | DocScrutinizer05 | how ould I mighrate back from fackonadi to plain? |
23:29.30 | FIQ | Pali, re@bash fixes - the 2 patches are for the same bug |
23:29.43 | FIQ | whoever made the 1st patch didn't do it well enough |
23:29.44 | DocScrutinizer05 | yep, I thought tat's obvious |
23:30.02 | FIQ | yeah but Pali seemed to imply they were unrelated |
23:30.10 | FIQ | thus why I said that, sorry :p |
23:30.12 | DocScrutinizer05 | [2014-09-26 Fri 01:02:58] <DocScrutinizer05> cannot blame them, I guess a bugfix for vulnerability, however untested and buggy, was top priority to roll out. Today they do the beautifying |
23:30.19 | Pali | DocScrutinizer05: just compile that my kdepim version from my git repo |
23:30.42 | DocScrutinizer05 | I rather meant how to migrate data |
23:30.54 | Pali | migrate? from akonadi? :D |
23:30.57 | Pali | this is joke |
23:31.10 | DocScrutinizer05 | haha thanks! thought as much. CRAP!! |
23:31.25 | Pali | there are 2 ways: 1) copy emails to IMAP mail server |
23:31.38 | Pali | or 2) try to export emails in MBOX format from KMail |
23:31.39 | DocScrutinizer05 | *cough* |
23:32.43 | Pali | kmail has support for that archiving folder (in mbox format) |
23:33.05 | Pali | so you can archive every folder and then you can import mboxes into any mail client |
23:33.24 | DocScrutinizer05 | hmmm... thanks |
23:33.36 | Pali | I have stored all emails in IMAP server, so I did not have problems with migration |
23:33.36 | DocScrutinizer05 | I have sub-sub-sub-sub-folders |
23:33.59 | Pali | I just downloaded them from imap again (it took lot of time) |
23:34.01 | DocScrutinizer05 | IMAP is a glorified web mailer frontend |
23:34.08 | DocScrutinizer05 | ;-) |
23:34.42 | DocScrutinizer05 | can't be arsed to use a protocol that can delete mails on all clients when one client has a hickup |
23:36.14 | Pali | its up to IMAP mail client what will do if server told him that folder has emails with id 1, 2, 3, ... 100 and in local storage are also emails with id 101, 102 and 103 |
23:36.57 | Pali | correct way would be: message box: do you want to delete these mails? really? |
23:37.24 | DocScrutinizer05 | it feels as nonsensical as daily "sync phone with PC" and then pray that the old existing entry will at least survive syncing with the accidentally deleted entry on the other machine |
23:38.02 | Pali | working solution for syncing emails is to use git |
23:38.11 | DocScrutinizer05 | o.O |
23:38.21 | Pali | you have full history of emails |
23:38.31 | DocScrutinizer05 | leaves, screaming |
23:38.46 | DocScrutinizer05 | wpwrak: ^^^^ ;-P |
23:38.59 | FIQ | lolol |
23:38.59 | Pali | and thanks to git you can sync between any machines |
23:39.41 | DocScrutinizer05 | votes for throwing out ext4, btrfs et al, and have gitfs on root |
23:39.48 | FIQ | lol |
23:39.53 | Pali | :D |
23:39.56 | DocScrutinizer05 | actually a gitfs I might consider using |
23:40.55 | DocScrutinizer05 | can't get used to the shell-only and weird syntax and semantics and workflow though, with git (sans -fs) |
23:41.05 | Pali | but to sync *text* data between different machines (when on each you did some modification), git is really perfect for it |
23:41.33 | Pali | absence of GUI for it is something other |
23:41.47 | Svetlana | "... and have gitfs on root ..." |
23:41.53 | Svetlana | parsed that as "gifts" |
23:41.59 | Svetlana | :o |
23:42.10 | DocScrutinizer05 | worked too long on mainframe computers with OS and "fs" where you first hat to "load stack" before you could open the file |
23:42.43 | Svetlana | " ... actually a gifts I might consider using ... " ok, clearly I need a better font or memory (or both) |
23:42.44 | DocScrutinizer05 | hi Svetlana! how about inviting idoru? |
23:43.09 | DocScrutinizer05 | wait, is staff on ACL? |
23:43.32 | DocScrutinizer05 | noooope! shame on me! |
23:43.57 | Svetlana | I think it'd make sense to invite her if it's ongoing (I saw some spam earlier but it was a come-and-go case) |
23:44.18 | DocScrutinizer05 | Svetlana: could you please toss over the freenode hostmask, or - even better - complete chanserv command? |
23:45.35 | DocScrutinizer05 | aaah, already got it: [Notice] -ChanServ- 5 *!*@freenode/staff/* +Aiortv [modified 4 years, 6 weeks, 4 days, 00:15:58 ago] |
23:46.03 | Svetlana | yup that looks right, thanks |
23:46.20 | DocScrutinizer05 | [Notice] -ChanServ- Flags +Aiortv were set on *!*@freenode/staff/* in #neo900. |
23:47.31 | DocScrutinizer05 | feel free to invite idoru any time |
23:47.45 | DocScrutinizer05 | haven't seen her misbehave since years |
23:49.34 | DocScrutinizer05 | once she klined a user for saying "good morning!" in 15 os so channels, in 2 minutes ;-P |
23:50.45 | DocScrutinizer05 | and un-klining a user is pretty annoying. "Has to be done by user, per mail!!!" ;-) |
23:50.47 | Svetlana | good morning! |
23:50.47 | Svetlana | :o |
23:51.34 | Svetlana | (I'll invite her if the spam keeps coming regularly of course; it's annoying) |
23:51.47 | DocScrutinizer05 | yup |
23:52.21 | DocScrutinizer05 | I wonder why that script kiddie picked this tiny channel, haven't seen it on other more popular ones |
23:53.15 | DocScrutinizer05 | maybe a total noob who didn't know about #I-Just-Opened channel? |
23:53.55 | DocScrutinizer05 | how's exploit front meanwhile? |
23:54.56 | Pali | who is idoru? |
23:55.09 | FIQ | staff |
23:55.29 | DocScrutinizer05 | spmmaer killer bot |
23:55.33 | FIQ | maybe he doesn't like someone in here |
23:55.34 | DocScrutinizer05 | spammer* |
23:55.59 | FIQ | (or she) |
23:56.34 | DocScrutinizer05 | hmmm, https://blog.freenode.net/2014/09/server-issues-2/ Posted on 2014-09-13 by mrmist |
23:57.03 | DocScrutinizer05 | Pali: wrong! right spelling: /whois idoru |
23:58.40 | DocScrutinizer05 | GRRR! http://code.google.com/p/pyfibot/ -> !! We have moved !! This repository is archived, all future development will go to GitHub |