DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
jekhor has quit [Ping timeout: 245 seconds]
apelete has quit [Ping timeout: 252 seconds]
emeb has quit [Quit: Leaving.]
wolfspraul has joined #qi-hardware
xiangfu has joined #qi-hardware
wpwrak has joined #qi-hardware
<wpwrak> whee ! back online again !
<wolfspraul> wpwrak: welcome back
<wolfspraul> what happened?
gbraad has joined #qi-hardware
gbraad has quit [Changing host]
gbraad has joined #qi-hardware
<wpwrak> PC disk started to fail. then i got a blackout (power). after than, the PC didn't want to come up anymore. when trying to nurse it back to life, another blackout struck. after that one, the disk didn't even get to the grub menu.
<wpwrak> then i tried to reinstall with one of my out-of-service disks. four disks later, still no luck.
<whitequark> wpwrak: use UPS?
<wpwrak> today, i finally went and bought a new one. this one seems to fine.
<wpwrak> whitequark: it beeped for about 30 seconds, then it shut down
<whitequark> wpwrak: man 1 battery-maintenance ;)
<wpwrak> man pointless :) power failures here are either very short (mere brown-outs) or > 1 h. there's hardly ever one in between. so buying new batteries all the time would be an exercise in futility
<whitequark> makes sense
<wpwrak> the quality of harddisks really seems to be going down the drain these days. this disk was only something like two years old. and its predecessor didn't live much longer either.
<whitequark> wpwrak: manufacturer?
<wpwrak> WD and Samsung
<wpwrak> i miss Maxtor. those were immortal.
<wpwrak> in my file server, i have two maxtor. must be about 10 years old by now. still working perfectly. then two WD. some of the first 1 TB disks. one is still okay. the other goes offline after transferring a few hundred MB.
<wpwrak> ah yes, there was some added fun: last week, i got an eye infection (conjunctivitis), which of course just about peaked around saturday/sunday. made crawling around the pc and swapping disks particularly enjoyable. murphy obviously believes in synergy :)
<kristianpaul> wpwrak: wb :)
<wpwrak> thankx :)
whitequark is now known as breakingsandboxe
breakingsandboxe is now known as whitequark
erikkugel has quit [Read error: Connection reset by peer]
<hellekin> wpwrak: you're cracking me up. Murphy's synergy :} Glad that your eyes got better
<wpwrak> still very sensitive. so reading text at daytime is painful. but yes, they're much better than a few days ago. may still be a week or so until they're back to normal, though.
<wolfspraul> wpwrak: did you take antibiotic eyedrops?
<wolfspraul> if it's as serious as you describe you most likely should
<wolfspraul> there are good eye cleaning solutions too, boric acid I think
<wolfspraul> but don't mix yourself :-)
<wolfspraul> that's just for cleaning though
<wpwrak> the ones they prescribed me are antibacterial but not antibiotic. seem to do the job, though. just takes a while.
<wpwrak> for washing the eyes, the doctors recommend ... tea :)
<wolfspraul> ok :-)
<whitequark> isn't boric acid poisonous?
<wpwrak> for the cleaning, it seems the worst of the muck gets stuck in places where it doesn't leave easily. and you can't pry it out yourself. yesterday, my doctor did a round of cleaning and removed something like 1 cm^3 of goo from one eye. thursday will be another round.
<hellekin> wpwrak: you could sell it on eBay :)
<wpwrak> do they have a category for body fluids/slimes ? :)
<whitequark> 1 cm^3?!
<whitequark> where was it
<wpwrak> inside the eye, above and below the eyeball. some mucus membranes, i think.
<whitequark> so... did he something like a blunt syringe tip into your eye? and then drain it?
<wpwrak> the eyeball is fine (besides being a bit irritated). a conjunctivitis is an infection of the tissue surrounding the eyeball.
<whitequark> I see
hellekin has quit [Remote host closed the connection]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
sivoais has quit [Ping timeout: 240 seconds]
sivoais has joined #qi-hardware
porchao has quit [Remote host closed the connection]
wolfspraul has quit [Quit: leaving]
xiangfu has quit [Remote host closed the connection]
security has joined #qi-hardware
megha has quit [Ping timeout: 276 seconds]
apelete has joined #qi-hardware
LunaVorax has joined #qi-hardware
LunaVorax has quit [Ping timeout: 260 seconds]
jekhor has joined #qi-hardware
jluis has joined #qi-hardware
gbraad has quit [Ping timeout: 264 seconds]
gbraad has joined #qi-hardware
gbraad has joined #qi-hardware
jekhor has quit [Ping timeout: 252 seconds]
dlan^ has quit [Quit: Leaving]
dlan^ has joined #qi-hardware
lekernel has joined #qi-hardware
Jay7x has quit [Read error: Connection reset by peer]
mth has quit [Read error: Connection reset by peer]
mth_ has joined #qi-hardware
unclouded has quit [Ping timeout: 264 seconds]
kuribas has joined #qi-hardware
Calyp has joined #qi-hardware
pcercuei has joined #qi-hardware
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
jekhor has joined #qi-hardware
rz2k has joined #qi-hardware
gbraad has quit [Ping timeout: 252 seconds]
wolfspraul has joined #qi-hardware
gbraad has joined #qi-hardware
gbraad has joined #qi-hardware
gbraad has quit [Changing host]
erikkugel1 has joined #qi-hardware
rz2k has quit []
wpwrak has quit [Quit: Leaving]
zear has quit [Read error: Connection reset by peer]
zear has joined #qi-hardware
fire has joined #qi-hardware
security has quit [Ping timeout: 260 seconds]
gbraad has quit [Ping timeout: 245 seconds]
pcercuei has quit [Ping timeout: 260 seconds]
pcercuei has joined #qi-hardware
kyak has joined #qi-hardware
<mwcampbell> Can the NAND flash memory on the Ben be addressed as if it were RAM? I'm asking about the capabilities of the hardware, not of Linux.
<whitequark> mwcampbell: nope
* whitequark has only recently heard of XIP NAND
<mwcampbell> XIP was what I was thinking of.
<mwcampbell> I guess that has mostly been done with NOR flash.
pcercuei has quit [Ping timeout: 272 seconds]
pcercuei has joined #qi-hardware
<pcercuei> mwcampbell: no
<mwcampbell> What is the shortest boot time that has been achieved on the Ben? From power-on to a shell
<mwcampbell> or at least, from power-on to running some user-space program
<whitequark> mwcampbell: actually nevermind, I never heard of XIP NAND flash ever.
<whitequark> it was a NOR with an SPI interface, which made it somewhat more convenient.
erikkugel1 has quit [Quit: Leaving.]
erikkugel has joined #qi-hardware
paul_boddie has joined #qi-hardware
jluis has quit [Ping timeout: 245 seconds]
<paul_boddie> Actually, when it comes to boot time, is it possible to augment the kernel so that the CPU just starts running it (the augmented bit of the larger payload, I suppose) at power on? Or does there need to be a smaller payload like U-Boot that then loads and jumps to the larger kernel payload?
erikkugel has quit [Read error: Connection reset by peer]
<whitequark> paul_boddie: well, you need a bootload
<whitequark> *bootloader
<whitequark> because nand can have bad pages
<whitequark> plus, the ROM primary bootloader only knows how to load a few leading NAND pages.
<paul_boddie> Well, I was just thinking of the situation you have where things like U-Boot starting to accumulate Linux kernel code, and then you start to wonder whether the essentials of the bootloader couldn't just be incorporated into the kernel somehow. Or rather, the kernel payload.
<whitequark> u-boot needs to set the environment up for kernel
<whitequark> when it starts to be portable across platforms, it quite naturally has an intersection with the kernel field of responsibility
<whitequark> given they're both in C
<paul_boddie> So instead of the CPU loading U-Boot, initialising the hardware, figuring out where the kernel is, loading the kernel, jumping into the kernel, and all the stuff that then tends to go wrong (the kernel doesn't have the support for hardware that U-Boot was quite happy about), why not just have a single payload?
<whitequark> paul_boddie: for one, that would require compiling a distinct kernel for each device
<paul_boddie> Yes, but there is only one NanoNote. ;-)
<whitequark> not sure about MIPS, but with ARM, you can more or less build in the support for every single board out there.
<whitequark> (now with device tree support)
<whitequark> MIPS stuff iirc has a similar mechanism
<whitequark> paul_boddie: well, you're not the only user of the kernel
<paul_boddie> It's not like some random distro loading modules for all sorts of arcane, ancient datacentre crap just in case that modern CPU is connected to some weird networking interface made by some dinosaur organisation in 1993 for ten whole minutes.
<whitequark> paul_boddie: u-boot is also useful in its arguable bloat.
<jekhor> hello. In latest snapshots of openwrt-xburst for nanonote mpd seems broken (exits with message "Failed to initialize input plugin 'ffmpeg': No protocol"). Does someone know something about this?
<whitequark> paul_boddie: I've reflashed dead kernel through tftp more than once. Without u-boot, I'd be fucked.
<paul_boddie> jekhor: Maybe the MPEG exclusion in the configuration is broken?
<paul_boddie> whitequark: I agree that U-Boot is very useful, but I just wondered that since U-Boot is probably always expanding, why not just combine it with the kernel? Let them share their hardware expertise.
<whitequark> paul_boddie: I guess because U-Boot's source is also of abysmal quality
<jekhor> paul_boddie, this is tail of 'strace mpd' output: http://paste.debian.net/243137/
<paul_boddie> I guess there is some movement towards eliminating the initial root disk versus running system discrepancies, but I can't say that I read all the details.
<paul_boddie> jekhor: It seems to look for /dev/crypto and not find it. I wonder if this device is supposed to be created somewhere by some script.
wpwrak has joined #qi-hardware
<paul_boddie> The whole initrd thing is probably well illustrated by things like Knoppix or distro live CDs which manage to run on systems, but when you try and install the actual system, you can end up with something that won't boot. I seem to recall seeing that.
<paul_boddie> jekhor: I'm no expert on things like device creation. That's another area where things have changed from static device creation for a load of devices you'll never use to more clever stuff, and maybe even getting the kernel to share its knowledge of the devices it supports, but I can't say I've looked at it much, especially with OpenWrt.
<paul_boddie> A simple mknod with the right arguments might work, but it depends on whether the kernel is able to support the functionality. Alternatively, you might be able to disable the plugin causing the error, but this might be something you actually want enabled, so that wouldn't really help you.
<whitequark> afaik the kernel now creates the device files for every device which exists automatically
<whitequark> the job of udev was reduced to setting the correct permissions
<whitequark> that is, with devtmpfs.
<paul_boddie> Sounds familiar.
<mwcampbell> What is the maximum payload that the Ben's ROM bootloader can handle?
<paul_boddie> I saw this kind of thing with Emdebian, I think.
<paul_boddie> http://en.qi-hardware.com/wiki/Ben_NAND#NAND might be informative.
<mwcampbell> and how many bytes are in a NAND page?
<paul_boddie> 4096 blocks * 128 pages/block * 4096 bytes/page = 2147483648 bytes (from the wiki)
<paul_boddie> I don't know what kind of restrictions there are when it comes to the SoC pulling stuff out of NAND in order to boot.
<mwcampbell> Perhaps the main reason for using a boot loader is to ease reflashing and avoid bricking.
<pcercuei> paul_boddie: at startup the JZ loads the first 8kB from NAND
<pcercuei> so the bootloader has to be smaller than 8kB
<pcercuei> u-boot isn't, so it's divided into two parts, the first one just init the memory and load the second bootloader from the NAND
<mwcampbell> So the first part of the boot loader could just load the kernel instead, right? But then reflashing and alternative boot options would be more difficult, I guess.
<whitequark> mwcampbell: it is not trivial to fit the NAND FTL code into 8kb
<whitequark> even less so if you have something fancy (and convenient!) like ubifs
<mwcampbell> What does FTL mean in this context?
<mwcampbell> just need the expansion, then I can google
<whitequark> flash translation layer
<paul_boddie> pcercuei: Thanks for the insight!
<paul_boddie> Faster than light! ;-)
<mwcampbell> So the first part of u-boot loads the second part form an area of NAND flash that isn't subject to the FTL?
<pcercuei> mwcampbell: yes, that's what ubiboot does (the bootloader we use on the gcw zero)
<pcercuei> it weights only ~5kB, and loads a Linux kernel from UBI or SD (FAT)
<pcercuei> mwcampbell: FTL is Flash Translation Layer
<pcercuei> it's a software layer that maps logical blocks to the real blocks of the NAND
<pcercuei> so that when one block breaks, it doesn't break the whole memory
<whitequark> mwcampbell: first block of NAND is guaranteed to have much better durability than the rest
<whitequark> 1-2 orders of magnitude better at least
<mwcampbell> and I suppose it will be even more durable if it's reflashed infrequently.
<whitequark> well, it will surely last longer
<jekhor> I am trying to install and load kmod-crypto-ocf which creates /dev/crypto, but it depends from kmod-crypto-manager and kmod-crypto-core, which doesn't exist.
<mwcampbell> Here's why I'm asking about the boot process. http://www.loper-os.org/?p=300 argues that computers only come in two speeds, fast and slow, where "slow" means any user-perceptible delay. I'm still trying to understand what makes computers slow, even with processor speeds increasing. One obvious hypothesis is that multi-layered systems and multi-step processes, as opposed to just doing what the user wants in the most direct way possible,
<whitequark> your message was truncated after "way possible,"
<whitequark> btw I can explain. there are roughly three reasons imo.
<mwcampbell> oops, too long a message
<mwcampbell> the last few words were "are to blame"
<whitequark> first, there are genuine delays, perhaps network delays. they can be ameliorated by using proper caching, scaling, shaping etc algorithms but not removed
<whitequark> it's also sometimes an UI issue ("block the app" vs "add an operations queue")
<whitequark> second, there are poorly designed systems which underutilize available resources
<whitequark> e.g. a list box with 10k elements which does not cache/prerender items will appear to scroll slowly. it could be fast on the same hardware.
<whitequark> third, there is some genuine increase in the complexity of systems. but more often than not it's intrinsic, not something due to poor design.
<whitequark> say you see that your IM client renders a megabyte of accidentally pasted text very slowly. you complain. but what does it do? it invokes the freetype engine which is ought to render every single character ever existed on this planet, with kerning, antialiasing, hinting and whatnot
<whitequark> this is a very perceptible positive change in the UI, which does increase the resource requirements by orders of magnitude
<whitequark> and it should, and this change is welcome anyway.
<pcercuei> openVG :)
<mwcampbell> The standout quote from that article I linked is, "The GUI of my 4MHz Symbolics 3620 lisp machine is more responsive on average than that of my 3GHz office PC. The former boots (into a graphical everything-visible-and-modifiable programming environment, the most expressive ever created) faster than the latter boots into its syrupy imponade hell."
<mwcampbell> That one didn't get truncated, did it?
<mwcampbell> probably did :(
<paul_boddie> No. You weren't affected by varchar(256) this time. ;-)
<mwcampbell> on the surface, that quote seems like quite a criticism of software developers over the past few decades.
<mwcampbell> But whitequark makes a good point about actual advances in software features that necessarily require more resources.
<mwcampbell> I wonder, what features would one have to sacrifice to have a fast-booting (defined as 10 seconds or less), responsive GUI on the relatively underpowered hardware of the Ben NanoNote?
<whitequark> mwcampbell: not that it is ever correct to compare cycles per second :p
<whitequark> (unless it's exact same microarchitecture, I'd say.)
<pcercuei> does it use sysinit or systemd?
<mwcampbell> Does what? That blogger's office desktop?
<mwcampbell> I have no clue
<whitequark> besides, gui responsiveness doesn't have much to do to achieve
<whitequark> it's a matter of separating gui operations into their own thread and giving it the highest priority, as the iOS clearly demonstrates
<whitequark> I guess whatever that blogger runs (gtk?) cannot do that.
<mwcampbell> I guess that blog post is more hot air than reasoned argument
<mwcampbell> I'm sorry I took us so far off-topic with that
xiangfu has joined #qi-hardware
<mwcampbell> So, someone mentioned that the ubiboot bootloader can load a kernel from ubifs or SD with only about 8KB of code. What advantages does u-boot provide over ubiboot?
<paul_boddie> I don't think it's off-topic to consider the properties of a system like fast boot, really. Everyone looks at microcomputers and asks why they are usable within a second of power on and yet today's machines need to "think about" starting up.
<whitequark> you can achieve these speeds by tuning linux correctly
<paul_boddie> Yes, I know. I mean, you can boot into a Linux plus busybox environment very quickly without really thinking about tuning at all.
<whitequark> you'd need an SSD, a custom kernel compiled for your hardware and parallelized boot process without anything extraneous. you could get to GUI very fast
<whitequark> a matter of less than 10 seconds. I think I once did four.
<whitequark> it's a given fact that PCI enumeration takes very real and significant time
<whitequark> oh also like half of the boot time of my notebook is BIOS/EIF
<whitequark> *EIF
<whitequark> argh, EFI
<paul_boddie> A lot of the focus on parallel boot and the other stuff is necessitated by the amount of cruft in the boot process, however.
<paul_boddie> Argh, EFI, indeed. ;-)
<whitequark> paul_boddie: no, not really
<whitequark> it's only cruft if you lack perspective
<whitequark> is a network managing service "cruft"? is printer server "cruft"? etc.
<whitequark> people want everything to Just Work™. Software abides.
<paul_boddie> Yes and yes. I have a desktop which doesn't need network management and I don't have a printer.
<whitequark> well, if you care about that so much, go turn it off and get faster boot.
<whitequark> ;)
<paul_boddie> And the printer doesn't need to be available immediately during the boot. Actually, I can be launching applications in about a minute after boot, so it's not important to me, but the continuation of the "telephone switch operating system" mindset means that a lot of people just accept a gazillion services running and people adding yet more without anyone asking whether they are all necessary.
<whitequark> well that is the point of parallel boot
<paul_boddie> That's what I said! :-)
<whitequark> besides, boot time doesn't matter
<whitequark> ACPI S3 is usable even on Linux for almost a decade now I think
<paul_boddie> I'll accept that I hate the alternative extreme where Windows boots (slowly) and you have to wait for it to become usable, the desktop icons appear then disappear then appear again, chugging noises are heard, the hourglass appears.
<paul_boddie> mwcampbell: I imagine that if you deployed a minimal Linux plus busybox environment, you'd get to a shell within 10 seconds.
<mwcampbell> My Ben will arrive tomorrow (hopefully), so I'll soon find out.
<whitequark> also funny how people complain that the new dynamic languages waste lots of cycles
<lekernel> "The goal is to create something which can one day be seamlessly converted to a fully-asynchronous design, implemented using Muller C-gates. The latter is extremely difficult (though not entirely impossible) on available FPGAs, so the “adult” form of the design would have to be fabbed in actual silicon"
<whitequark> even in cases when the workload is dominated by I/O time. even when I can modify one line in any given file of an equivalent of 100KLOC or 1MLOC C++ project and get to run it within four seconds.
<lekernel> ahem
<lekernel> it's easier to do it with fpgas than silicon
<lekernel> there are the same problems, only you don't need a slow and expensive respin with the fpga when you fuck up
jekhor has quit [Ping timeout: 264 seconds]
<mwcampbell> whitequark: Do you use any dynamic languages on the Ben?
<paul_boddie> I have used Python on the Ben.
<mwcampbell> Maybe this is just a psychological effect, but I assumedf that I would need to avoid dynamic languages on the Ben, because after all, it's only a 336 MHz MIPS processor, so it'll probably be hard work to write responsive applications
<paul_boddie> Well, I was using Python on early 1990s workstations with 25MHz or so processors, so the CPU speed is not really an issue, even if Python has become less lean over the years.
kuribas has joined #qi-hardware
<paul_boddie> Of course, you might want to use a systems programming language to get more horsepower. On my long list of things to do, I aim to compile some Python stuff using Shedskin for the Ben and see how that turns out.
<paul_boddie> In my experience, the more significant problem is likely to be the RAM footprint, which for an untuned version of Python is not too bad, but if you start importing modules that need other modules like numpy, then you can easily exhaust the RAM.
<paul_boddie> That's arguably a problem with numpy and the way they bundle absolutely everything into the package so that you're loading a ton of Fortran-related stuff when you (or rather pygame) imports numpy.
<mwcampbell> Good point about RAM usage.
<mwcampbell> In a language that's compiled to native code ahead-of-time, the OS can mmap in just the pages of code that it needs.
<mwcampbell> Whereas in an interpreted language, all of the code that you just imported is just data as far as the kernel is concerned, so it has to be kept in memory.
<mwcampbell> And of course JIT compilation makes RAM usage worse.
<mwcampbell> Is there an explanation somewhere of why the Ben's hardware has such modest specs in the first place? That has to be a common question.
<mwcampbell> My best guess is that it was such necessary to use low-spec hardware in order to reach an acceptable price even for a small-scale manufacturing run.
<mwcampbell> s/such necessary/necessary/
<qi-bot> mwcampbell meant: "My best guess is that it was necessary to use low-spec hardware in order to reach an acceptable price even for a small-scale manufacturing run."
<mwcampbell> oh, nice :)
<pcercuei> never heard about shedskin, looks intetesting
<paul_boddie> With the Ben you always have to remember that the starting point was someone else's device at a particular price point. That in turn would have influenced and been influenced by the availability of SoCs known to and understood by the manufacturer.
<paul_boddie> I don't use Shedskin that much, but I have used it for prototyping some stuff that others would perhaps want to rewrite in numpy-based technologies, and it was a pretty good fit and gave a nice speed-up.
guanucoluis has joined #qi-hardware
<paul_boddie> People get upset about it because there are limitations, but people tend to overstate them and want all their ultra-dynamic sugar for their programs and yet not have those programs get fat.
* paul_boddie has to go.
paul_boddie has left #qi-hardware ["Kopete 0.11.3 : http://kopete.kde.org"]
pcercuei has quit [Read error: Connection reset by peer]
<mwcampbell> The Ben was based on another device?
pcercuei has joined #qi-hardware
<whitequark> (ultra-dynamic sugar) well, that's why we use high-level languages.
<whitequark> properly used metaprogramming can reduce the size of program 10x, or even 100x, in extreme cases.
pcercuei has quit [Ping timeout: 260 seconds]
<wpwrak> (cruft) hmm, ubuntu 12.10: comes up, network manager finds Ethernet, Bens, configures each as possible internet access. then rotates between them, causing rather interesting failure patterns.
<wpwrak> in this case, there would be two choices: 1) keep it simple, or 2) only use what actually works.
<whitequark> wpwrak: that is a bug, not cruft ;)
pcercuei has joined #qi-hardware
<wpwrak> (cruft II) on to cups. as usual, printing didn't work. nota bene, this is a fresh install. turns out it somehow mis-autodetected the printer and it only figured out what it was after deleting and re-creating it. the printer is a postscript printer and all i want is postscript to be sent to it untouched. ancient lpd could handle this perfectly, without ever breaking. now we have cups that has some regression on what's the same set of t
<wpwrak> asks on each release.
<wpwrak> (cruft III) xorg. each time i have to install a new ububtu, xorg regresses in my triple-head setup, usually requiring a day of searching for returning to the status quo antes.
<viric> there you go, with ubuntu
<wpwrak> sometimes it gets worse: once, we had to debug the radeon driver. this time, i had to install a patched non-official xorg server package to get at least mousing out of the first screen. 3rd screen is still gone, without a clue why.
<mwcampbell> I'm sorry I started us on that tangent about boot time and cruft.
<wpwrak> whitequark: it's software complexity growing until the thing collapses under its own weight. in all three case, these are things that keep coming back. they're no isolated bugs. xorg is particularly bad. once you have to find some magical kernel command line option, once you need to fix the driver, once you need a very hackish downgrade to an earlier server version, etc.
Jay7 has joined #qi-hardware
<wpwrak> she sheer amount of trouble also means that community fora gets crowded with yesteryear's fixes for similar problems and it's increasingly hard to find sonething that actually helps to move forward
<wpwrak> (just venting about my experience of the last few hours :)
<whitequark> this is the price of complexity, combined with diversity, combined with proprietary devices.
<wpwrak> one could of course say that all this is an epic QA failure. maybe that's the case.
pcercuei has quit [Ping timeout: 260 seconds]
<wpwrak> whitequark: in my case, the hardware is the same for a very long time, and not exotic at all. and of course i don't use any proprietary drivers. yet each new version runs into trouble.
pcercuei has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
<mwcampbell> My Ben just arrived, a day early. I know what I'll be doing tonight. :)
<wpwrak> enjoy an uncrufted system :)
<mwcampbell> and I'll hopefully develop some uncrufted software to run on it
pcercuei has joined #qi-hardware
<mwcampbell> paul_boddie said earlier that the starting point for the Ben was someone else's device. Does this mean that the Ben is an unauthorized clone of some other product, or merely that it used the components of some other product as a starting point?
pcercuei has quit [Ping timeout: 260 seconds]
<wpwrak> it's not a clone :) it's a variant (customized keyboard, etc.) of a dictionary, made by the company that made the dictionary
<mwcampbell> ah, OK
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<mwcampbell> And presumably that company authorized the copylefting of the hardware design?
<mwcampbell> Anyway, that origin explains why the specs are so modest. One surely doesn't need a very fast processor for a dictionary.
<wpwrak> the hardware design isn't fully copylefted. i suppose they authorized the re-making of the schematics, though.
<wpwrak> things we don't have are layout and mechanical design
<mwcampbell> ah OK
lekernel has quit [Quit: Leaving]
<mwcampbell> anyway, the Ben seems to be much more hacker-friendly than many mainstream devices
<wpwrak> well, there are partial scans of the case, which have some use if you want to make mechanical add-ons: http://www.almesberger.net/misc/ben/scan/
lekernel has joined #qi-hardware
LunaVorax has joined #qi-hardware
<wpwrak> (the partial scans never got finished because one day the pc on which i had a VM with windows that was running the scanning application died)
<mwcampbell> I'll probably only be doing stuff at the software level. I'm no electrical engineer.
<mwcampbell> just a programmer
<wpwrak> actually, this is a better url. less traffic on my site :) http://downloads.qi-hardware.com/people/werner/ben-scans/
<mwcampbell> What kind of keyboard, if any, did the original dictionary product have? just curious
<wpwrak> i suppose it was somewhat similar
guanucoluis has quit [Ping timeout: 264 seconds]
xiangfu has quit [Ping timeout: 256 seconds]
<LunaVorax> Hi!
guanucoluis has joined #qi-hardware
mth_ is now known as mth
pcercuei has joined #qi-hardware
pcercuei has quit [Read error: No route to host]
pcercuei has joined #qi-hardware
<mwcampbell> In the stock software installation, is the OpenWrt logo displayed by the kernel itself, or by a user-space process early in the boot procedure?
guanucoluis has quit [Ping timeout: 256 seconds]
rz2k has joined #qi-hardware
<kristianpaul> kernel
jekhor has joined #qi-hardware
<mwcampbell> Any advice on which GUI toolkit to use if I'm writing a new app that I want to be responsive on the Ben?
<mwcampbell> I won't be writing any games; the display will be used primarily for text and UI controls.
<mwcampbell> Is GTK reasonably snappy on the Ben?
<kristianpaul> by default there is not tk
<kristianpaul> gtk*
<kristianpaul> all is framebuffer
<kristianpaul> you need compile your own openwrt for using gtk
<mwcampbell> oh, I thought there was a framebuffer version of GTK included.
<kristianpaul> better try allegro or why not pyallegro
<kristianpaul> ah there is somwhere yes
<mwcampbell> I'll check out Allegro.
<kristianpaul> pyallegro was already introcuded to the nanonote by david k so it should worth a look as well
<mwcampbell> No vector graphics or TrueType fonts in Allegro though, right?
<mwcampbell> so a UI made with Allegro would probably look retro, IIUC
<mwcampbell> then again, any UI that is responsive on a 336 MHz processor without the assistance of a GPU might look retro
<wpwrak> or very futuristic ;-)
<mwcampbell> BTW, does the Qi Hardware community need a faster download mirror, particularly in the US? I'm getting ~20 KB/s from downloads.qi-hardware.com
<mwcampbell> I'm not complaining; in fact, I'm offering to help
kuribas has joined #qi-hardware
<mwcampbell> kristianpaul: Looks like the latest Ben NanoNote image does have a DirectFB-based build of GTK.
<kristianpaul> good :)
pcercuei has quit [Read error: No route to host]
<kristianpaul> btw if you need gtk on a xfdev, there is jlime port as well
emeb has joined #qi-hardware
Calyp has quit [Quit: gone working on freeconomy =o)]
<wpwrak> not sure if one can really recommend jlime anymore. as far as i know, it'
<wpwrak> s been unmaintained for years.
<mwcampbell> X seems quite superfluous on a device like this anyway
<mwcampbell> a screen this small practically requires that you only run one app at a time, and it seems to me that X offers nothing at all if one can run GTK, Pango, Cairo, etc. directly on the framebuffer device.
pcercuei has joined #qi-hardware
<mwcampbell> So which is better on a device like the Ben: GTK or Qt?
<kristianpaul> wpwrak: well yes but it still smooth for some tasks no ;)
<mwcampbell> One appealing thing about GTK is that if I use GTK, then I can write apps in the Vala language, so I'd get ahead-of-time compilation with the benefits of a more high-level language than C/C++
<wpwrak> kristianpaul: oh, it's very smooth ... until you need a cross-development environment, and all you find is an ancient toolchain (a great one though, much easier to use than the one from openwrt)
<wpwrak> for all my little bits of development on the ben, i used SDL. but that's quite low-level. pixels and lines :)
<mwcampbell> Allegro is equally low-level, right?
<kristianpaul> wpwrak: ;)
<kristianpaul> yeap easy to use it is
<kristianpaul> not get get made i guess :)
pcercuei has quit [Ping timeout: 258 seconds]
pcercuei has joined #qi-hardware
wpwrak has quit [Ping timeout: 272 seconds]
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
LunaVorax has quit [Ping timeout: 260 seconds]
guanucoluis has joined #qi-hardware
jekhor has quit [Ping timeout: 256 seconds]
baba has joined #qi-hardware
guanucoluis has quit [Read error: Connection reset by peer]
fire has quit [Ping timeout: 276 seconds]
guanucoluis has joined #qi-hardware
wolfspraul has quit [Ping timeout: 252 seconds]
lekernel has quit [Ping timeout: 260 seconds]
pcercuei has quit [Ping timeout: 258 seconds]
pcercuei has joined #qi-hardware
lekernel has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
pcercuei has joined #qi-hardware
paroneayea has quit [Remote host closed the connection]
apelete has quit [Ping timeout: 264 seconds]
gbraad has joined #qi-hardware
gbraad has joined #qi-hardware