MiLo

Want een transistor is heel koud wat geluid betref en een buis heel warm.

Helemaal mee eens, een transistor doet "tokkerdetok" en een buis doet heel mooi "rinkeldekinkel" als hij tegen de vloertegels ketst.

"Buizen klinken anders dan transistoren. Als je ze op de grond kapot gooit."

Mogelijk heeft je terminal (ssh/dropbear?) een upgrade gehad, waardoor je verbinding verbroken werd, en de upgrade voortijdig afgebroken is?

Probeer 't in dat geval nog een keer.

Anders wordt 't opnieuw flashen vrees ik.

The German text is just marketing bullshit. It just says that it COULD use it to do fancy stuff. But until someone actually programs it, it won't really happen.

As for current E2, you could create bitblit and filrect methods using OpenGL, and probably several more as well. It won't really be noticable though, the CPU is pretty fast at 2D drawing already and hasn't got much better to do...

What I meant is: If you have a board (ANY manufacturer, any chipset, not limited to broadcom) and added OpenGL support for it (basically, add "opengl" to the MACHINE_FEATURES), you can use it if you like.

E2 itself has no use for OpenGL, and won't use it.

All broadcom chipsets (and even the old ATI chipset in the 7025 which BCM took over) have support for OpenGL. The manufacturers have never purchased the information to actually use it. Probably the ioctls for bitblit and fillrect are based on the OpenGL core in some way.

So having OpenGL in hardware is nothing new. To have a manufacturer actually purchase a license for it, now that would be a novelty.

You're probably trying to do something like:

 

- Extract image (or mount it or...)

- Change contents (e.g. add a softcam)

- Update the image with changes for flashing.

 

If that is what you want to do, it may be easier to build your own image from scratch.

Er was hier ooit iemand die dacht wel high-end audio uit de tulp-plugjes te kunnen halen.

Ik wil nog wel verder gaan: High end audio uit prikkeldraad.

Ik wil best demonstreren dat je het verschil tussen een audiosignaal dat een keer het weiland rond is geweest en dat direct naar een versterker gaat niet kunt horen en ook niet kunt meten.

En ik heb het dan over gewone basisband analoge transmissie, dus geen modulatie, en geen digitale constructies.

http://git.busybox.n...n/docs/mdev.txt

 

If you plug in the board, mdev will match the device in /etc/mdev.conf. By default it will only create the "ttyUSB0" nodes.

 

There's a line "tty.*" which matches any tty device. Add a line above that, ttyUSB[0-9] that will match sooner than the generic case.

 

you can call a script from there, by adding a "*" entry, start by creating a hello world style script that just writes interesting things to a file in /tmp/ (because you won't see your script's output).

 

Look at /etc/mdev/ for an example script.

Linux allows everything in a filename, except a slash "/" (directory separator) and a null character ('\0'). Unicode, comma, space, tab, semicolon and smileys are just fine as filenames.

Your "validfilename" should be as simple as: Replace '/' with something else and just try to create the file without bothering about anything else. If it fails to create the file, you're probably writing to a more restrictive disk (e.g. NAS or Windows machine) and then you can start encoding.

from Tools import Notifications, ASCIItranslit

filename = ASCIItranslit.legacyEncode(filename)

Nog geen oplossing?

http://sourceforge.n...d7a03ddece993e/

Which box?

Before anything else, stop exposing your box to the internet. Don't forward ports to it from your router/modem.

"If you have kernl 3.10 I would suggest not using zram for swap as there are better alternatives.  More later.

Our boxes have relatively slow CPUs, and usually no disk swap storage. So likely even on the newer kernels, zram will perform better on this particular set of hardware/software than zcache and friends.

Our "disk pages" are usually filled with compressed audio/video data, and these are totally uncompressible, so any attempt to compress these pages are a waste of those precious CPU cycles we have. So that rules out "cleancache" and "frontswap" from doing anything useful - no point attempting to compress disk data, it will be uncompressible.

The memory that we have that is compressible are the pages filled with program code and (non-video/audio) program data (e.g. bitmaps and EPG data). Which implies that you should set "swappiness" to its default or higher. The kernel can move these to a swapfile like zram if memory runs tight. The idea behind zram was to have some "spare" things to do when memory is running low, and to move hardly used pages to a compressed area of memory. In particular, I hoped that the EPG data could be moved there...