<OppositeDay_>
I'm trying to choose between the Neo900 and the Pyra (or perhaps some other similar device). There are a couple of things I'm not sure about:
<OppositeDay_>
1. I initially wanted an open broadband modem in my next phone, but I don't think such a thing exists in mass production right now. So my second best option is a phone with proper isolation. Do the Neo900 and Pyra both offer that? (I use GPS literally never and would like to keep it hardware-disabled at all times, even with LTE/telephony enabled. I don't need this 100% though)
<OppositeDay_>
(I disconnected right after writing that)
OppositeDay_ has quit [Ping timeout: 240 seconds]
qwazix has quit [Ping timeout: 240 seconds]
qwazix has joined #neo900
louisdk has joined #neo900
OppositeDay_ has joined #neo900
<OppositeDay_>
2. I don't use many closed-source programs, but almost all of the ones I do use (e.g. Discord) are compiled for x86. Would the Neo900 and the Pyra both run programs like Discord with decent performance on Wine? (Or should I look for something a little more high-performance?)
<OppositeDay_>
3. How open is the Pyra compared to the Neo900? I know that the Neo is meant to be as open as possible, but I'm not sure if the Pyra has a similar aspiration.
<OppositeDay_>
4. How's the keyboard on the N900? I've never owned one, and I'm not sure if such a small keyboard is practical.
<OppositeDay_>
5. What's up with Turing Robotic Industries and their Chaconne?
louisdk has quit [Ping timeout: 240 seconds]
louisdk has joined #neo900
<sixwheeledbeast^>
I can certainly say the N900 keyboard is great, very tactile
<Wizzup>
Why do you want an open modem and then use discord
<OppositeDay_>
I don't use discord voice chat, and discord doesn't have control of my entire telephony/LTE stack
<Wizzup>
no, just possibly over the entire os ;)
OppositeDay_ has quit [Client Quit]
OppositeDay_ has joined #neo900
OppositeDay_ has quit [Client Quit]
ArturShaik has quit [Quit: WeeChat 1.5]
ArturShaik has joined #neo900
ArturShaik has quit [Client Quit]
ArturShaik has joined #neo900
louisdk has quit [Ping timeout: 240 seconds]
louisdk has joined #neo900
jagenau has joined #neo900
Kabouik_ has joined #neo900
louisdk has quit [Ping timeout: 240 seconds]
louisdk has joined #neo900
ravelo_ has joined #neo900
sebboh` has joined #neo900
sebboh has quit [Remote host closed the connection]
ravelo has quit [Ping timeout: 260 seconds]
pagurus has quit [Ping timeout: 240 seconds]
pagurus has joined #neo900
louisdk has quit [Ping timeout: 260 seconds]
<Joerg-Neo900>
wpuld x86 spyware take over an ARM system?
<Joerg-Neo900>
hpnest question
<Joerg-Neo900>
s/p/o/g
t_ has joined #neo900
t_ has quit [Client Quit]
<MonkeyofDoom>
I've never heard of x86 soyware also infecting phones
<Wizzup>
Joerg-Neo900: I mean, the only way to run it by emulating it, and in that sense it'll just be a native program on arm
<Wizzup>
e.g. with qemu-user it will have access to the same system calls
<Wizzup>
so then all you need to do is find a local privesc and you're done
<Wizzup>
(either buy running 'sudo gainroot' or something else)
<Wizzup>
s/buy/by/
<Joerg-Neo900>
do emus run syscalls directly or do they emulate them?
<Joerg-Neo900>
and are the syscalls same ABI and have the same vulnerabilities?
<MonkeyofDoom>
the ABI has to be different because of different register names
<Joerg-Neo900>
of course the emulation machine is "just an ARM program", but the x86 stuff inside emu is somewhat contained a bit in it
<Wizzup>
Joerg-Neo900: regardless of the answer to your question, the answer is yes, you can still exploit from there
<Wizzup>
just talk to a unix socket, spawn a process, invoke dbus, etc, etc
<Joerg-Neo900>
ok
<Joerg-Neo900>
I see. Thanks
<Wizzup>
and the abis are definitely difference
<Wizzup>
sometimes linux swaps arguments around even
<Wizzup>
like with clone(2)
<Wizzup>
idk how qemu deals with that
<Wizzup>
s/difference/different/
<MonkeyofDoom>
qemu has a translator
<Joerg-Neo900>
a pity oppositeday is gone already
<Joerg-Neo900>
though >>un programs ... with decent performance on Wine?<< sounds just odd
<MonkeyofDoom>
the translator is 12000 lines of C ;_;
<Joerg-Neo900>
I'm just puzzled. Would ARM wine run x86 binaries?
<Wizzup>
I've ran pcsc-lite x86 w/ proprietary pcsk11 libs, and then talked with the socket from arm
<MonkeyofDoom>
yeah
<Wizzup>
Joerg-Neo900: no, x86 wine runs x86 binaries om arm
<Wizzup>
s/om arm/on arm/
<Wizzup>
you can do some hacks like make the wine from x86 talk to the arm wineserver
<Wizzup>
but it's pretty hacky and mostly unstable
<Wizzup>
(and again qemu is required here)
<Joerg-Neo900>
so qemu[ wine[ x86-win-prog]]?
<Wizzup>
yes
<Joerg-Neo900>
ouch
<Wizzup>
it works for notepad.exe ;)
<Wizzup>
but I've compiled wine on/for arm too, and that has a win32-arm notepad.exe, so yeah :D
<Joerg-Neo900>
anyway let me try to answer oppositeday, point by point:
<Joerg-Neo900>
1. open broadband modem: no, such thing doesn't and never will exist
<Joerg-Neo900>
pyra and Neo900 both offer same level of isolation, but Neo900 has tight monitoring on top
<Joerg-Neo900>
Neo900 allows disabling GPS, not sure about Pyra
<Joerg-Neo900>
2. >>Would the Neo900 and the Pyra both run programs like Discord with decent performance on Wine?<< probably not
<Joerg-Neo900>
>>3. How open is the Pyra compared to the Neo900?<< I don't think Pyra schematics are meant to be as public as Neo900's. So far I've only ever seen pdf from eagle long after the device started sales (in a way similar to N900), while Neo900 provides proper kicad project files
<Joerg-Neo900>
>>4. How's the keyboard on the N900?<< I prefer the N900 kbd over that of any other embedded device I've used so far, maybe except the N810 where I'm still not clear which of both I prefer
<Joerg-Neo900>
5. no idea, never heard of
louisdk has joined #neo900
<Joerg-Neo900>
(Chaconne) >>mind boggling pixel density of 688ppi<< indeed, what a waste of resurces. Unless you want to wear the thing as VR goggles. For normal usage I'd say this outperforms what human eye can theoretically see by factor 1.5
<Joerg-Neo900>
or even 2
<Joerg-Neo900>
yet all your infra from storage to CPU to GPZ to video bus neeeds to support this pointless overhead
<Joerg-Neo900>
GPU*
OppositeDay_ has joined #neo900
OppositeDay_ has quit [Client Quit]
<Joerg-Neo900>
basically similar considerations regarding a 60Mpx camera with a crap optics that's significantly shorter than 5cm, which I think would be the minimum optic length when you want to put that many pixels to purpose. What's the use of insane pixelcount when the optics can't deliver an image to the sensor that's faintly as high a resolution?
<bencoh>
Joerg-Neo900: better quality after downscaling
<bencoh>
note I still think it's a bit of a waste
<bencoh>
but even with "bad" optics, it's better than the same setup with a 5M sensor
<bencoh>
plus, that kind of sensor usually are less noisy (because they're more recent, and because you just have to work on noise issues if you want to deliver that kind of resolutions)
<bencoh>
(and it's not just about noise but overall quality)
<bencoh>
it's a tradeoff and you compensate lack of good/big optics with highres and image processing
<Joerg-Neo900>
I'm not a photographer nerd nor very savvy on the topic, but I know that you can't regenrate data that been lost. When data gets lost in optics due to whatever inevitable limitations of small optics (ask for example speedevil, he once explained in in gory detail) you can't recover them with as many petapixel as you like to throw at it
<bencoh>
I'm not saying you'll recover it
<Joerg-Neo900>
there are efects with light wavelength and diffraction on edges and idunnowhat that limit the theoretical resolution of a sensor depending on physical size of lens
<bencoh>
just that a 42MP->5M with crappy optics will look better than a native 5MP with same optics
<bencoh>
indeed
* Joerg-Neo900
almost feels tempred to google for "the megapixel myth debunked"
<Joerg-Neo900>
but then... not exactly my primary domain of interest
<bencoh>
hey I agree with you that the current megapixel trend is mostly marketing stuff :)
Pali has joined #neo900
Kabouik_ has quit [Read error: Connection reset by peer]
Kabouik_ has joined #neo900
Kabouik_ has quit [Remote host closed the connection]
Kabouik_ has joined #neo900
<Joerg-Neo900>
here's a nice article why megapixel don't matter as much in a physiological (perveive) way: http://www.nytimes.com/2007/02/08/technology/08pogue.html However what I'm after are the physical limitations where megapixel become pointless in whatever test equipment you run against the sensor
<Joerg-Neo900>
sth along the line of >>Typically the goal in optimizing the camera resolution is to match the pixel size with smallest resolution element that the optical system is capable of producing. In terms of sampling theorem, the pixel pitch defines the spatial sampling frequency, fS, and thereby Nyquist frequency, fN = ½*fS of the imaging system. Nyquist frequency defines the frequency above which aliasing can happen, but it doesn’t yet tell at
<Joerg-Neo900>
what frequency image details can be resolved.<<
<Joerg-Neo900>
>> In layman's terms, for best detail at any given resolution, you really need to process data from double that resolution. << finer pixel pitch than that is detrimental to the quality
<Joerg-Neo900>
due to lower quality of every involved pixel, in that two half size pixels can't sum up to the quality of one original size pixel, for a number of reasons
<Joerg-Neo900>
no matter which algorithms you apply in postprocessing
OppositeDay_ has joined #neo900
<Joerg-Neo900>
>>the '41MP' resolution of the Nokia 808 PureView and Lumia 1020 is just the underlying resolution of their sensors, remember that mumbo jumbo about Nyquist frequencies above? The PureView algorithms (in the 808 or 1020, etc.) are there in each case to 'oversample' from this massive amount of data down to 'purer' pixels, outputting at 5MP, but hopefully with almost zero noise as a result of the conversion of each group of 6 or 7 pixels' data (
<Joerg-Neo900>
on average) down to individual pixel data in the eventual output.<< this is a fallacy. One physical sensor pixel with 6 to 7 times the size _always_ will have less noise and better sensitivity than the virtual pixel made by an algorithm from 5 or 7 small physical pixels
<Joerg-Neo900>
so when the best focus detail of your optics is size of min 2 pixel in the 10 Mpx sensor, going to anything higher than 10Mpx with same sensor size and optic will actually be detrimental to the picture quality
<Joerg-Neo900>
and that's not yet diving into the topix how good your optics actually can do, regarding physical properties of lightwaves and their interaction with (ideal) lenses etc
<Joerg-Neo900>
s/topix/topics/
Beaches has quit [Excess Flood]
Beaches has joined #neo900
<Joerg-Neo900>
wavelength is 0.8micrometer for red. No focus point can get near that
<Joerg-Neo900>
that's btw the reason why in chip fabs they use ultrahard UV or even xray or electron beam to expose the chip photresist: shorter wavelength needed for the finer structures
<Joerg-Neo900>
(wavelength sounds a tad odd for electron beam, but I think it's clear)
<Joerg-Neo900>
that's already the reason for "blue" in BluRay
<Joerg-Neo900>
you *physically* can't read out a bluray disk with a red laser, no matter how good your optics. Not because of color but because of structure size of the bits on bluray disk that's physically invisible to wavelength of a red laser
<Joerg-Neo900>
for a hypthetical 10*10mm sensor with 100Mpix the particular pixel is 1micrometer size. Well within the range where wavelength of light starts mattering
<Joerg-Neo900>
I'd not be surprised to find that finally pixel sensor size of less than maybe 5*5 or 10*10 micrometer is just useless. and the other optical rules forbid a useful sensor with more than 20Mpix when the lens has no more than 5mm diameter, Whatever numbers might apply in the end, I made up those right now
Pali_ has joined #neo900
Pali has quit [Quit: No Ping reply in 360 seconds.]