ESP8266 is a great device, but serves completely different needs. It can't act as a wireless repeater/bridge, for example -- it's not a router. Also, it only has ~80KB RAM and can be run at max 160MHz, whereas this device has a 400MHz AR9331 and 64MB RAM and runs Linux; you are basically comparing apples and oranges here.
My mind is already boggling with the possibilities, I think I'll be buying a few. I wish I had known about these things sooner than this, but, well, better late than never!
Why would you need to be a hardware-hacker to use these? You can just use telnet or any of the other vulnerabilities they found to access the device's internals via software and proceed from there to install OpenWRT-proper.
I ordered an Orange Pi PC on eBay just recently and... boy-howdy do I regret it. It was only after ordering it that I found out that e.g. the CSI-connector isn't actually a CSI-connector and you need some expansion board to make use of it, and the expansion board isn't even supplied with the device itself -- and of course, none of this is mentioned either on the official website or their store! The forums are at the brink of self-immolation, no verification e-mails are ever received by people who try to register accounts there, the official website has a bunch of broken or outdated links, the Steven - guy behind the project has been missing for at least a week now and so on.
The hardware is real nice and personally I find their newly-announced OPi-Lite an exceedingly attractive device, but fuck if they're ever going to attract more than a few stragglers who end up horribly disappointed in the end when things are run like this. I wish I could get an OPi-Lite, but with RPi-level support.
4 gpio ports? this is not competing against a raspberry pi.
That's pretty much what I came in to say: this shit ain't an RPi - alternative, it's just a low-power PC. One of the major selling-points of RPi is the 40-pin GPIO-row, all useable natively, but with this shit you'd have to use I2C or USB GPIO-expanders and jump through extra hoops every single time you wanted to read or set a GPIO-pin state. Things get even worse if you wanted to use SPI.
If you want to know what consumer devices pose a security threat (whether cheap or expensive, webcam, router/modem or other device), just look at the list of devices that other people have loaded some version of a Linux based O/S on to. These are the devices that can be easily subverted. If your organisation is sensitive to security threats, the list of "hackable" devices should also be your list of products that should never be allowed to connect inside your company's security fence.
That's a stupid argument. The devices where it's easy to replace the firmware are also the ones that are the easiest to make sure they are secure, just replace the firmware yourself and then you can do anything you want to make it as secure as ever possible. The more closed the device is the less you can actually do to secure it!
There's not enough power/CPU to do any serious compression, and having to decompress it to do motion detection or transcoding afterwards is a waste.
Depends on what you connect the camera to. An RPi, for example, can encode the video in H/W and thus the CPU is free to do anything else. You could also do motion-detection before encoding, or you could use an actual infrared-sensor to handle motion-detection and thus the CPU could just sit idle.
If you are referring to http://www.lavrsen.dk/foswiki/... with "motion" then no, it doesn't do what I need. I was talking about making a WiFi-connected streaming camera and you're talking about a library for detecting motion -- two entirely different things. You still need a source of video to detect motion in and a device to run that library on in the first place, you know? It doesn't magically work on its own. And besides, a simple PIR attached to a GPIO-port will require a whole effing lot less CPU-power in order to detect motion than doing it in software via that library.
"Smart" webcams are always a risk, manufacturers insist on believing those devices should be available from the Internet and will try to use UPNP and other tricks to open themselves up for access from there. I have a need for a WiFi-enabled webcam that I can stream live-video from, but I was planning on just getting a ~$20 400MHz ARM-CPU WiFi-router with OpenWRT on it and a regular USB-webcam, and streaming the MJPEG - stream over RTP/RTSP -- since the video coming out of the camera is already encoded it doesn't require almost anything from the router's CPU to stream it as-is, and this way I have complete control over the entire stack and I control who and where the stream goes to.
If you perceive what they're doing as being bad, the moral thing to do is to not give them money to enable and reward the behavior.
And what if I perceive what Netflix is trying to do as a positive thing and wish to reward them for it? Netflix is just the proxy here, unsubscribing from Netflix is going to hurt them more than the content-providers -- can't both reward Netflix and punish content-providers that way. Netflix is one of the few companies that want to provide high-quality streaming-service everywhere for everyone and they provide excellent customer-support, both being things that I would like to support.
There are other ways to achieve sensory stimulation, from books to parks, or even independent films.
Yes, you can stab yourself with a knife to achieve sensory stimulation -- I do not see how that is relevant.
There was a blog-post from Netflix last year where they specifically said they are being pressured by content-providers to do this and they don't know how long they can hold out -- guess the point came where they couldn't hold out any longer. I don't blame Netflix for this, it doesn't matter to them what country you watch stuff from as long as you pay your monthly fee, but those greedy content-providers are at fault here.
You can't just compare a specific encoder against a video codec, such a comparison makes zero sense whatsoever. If you want to make a comparison then compare an encoder to an encoder or codec to a codec. There are already several HEVC-encoders out there, for example, both software-based and hardware-based, and it's ignorant to lump them all together.
50% bitrate reduction vs H.264 sure, but not vs x264 which is the current gold standard for HQ video compression.
You are comparing apples and oranges. x264 is an encoder, H.264 is a codec. There is a x265 encoder for HEVC, just as there is x264 for H.264. The rest of your post is just rambling when you don't even understand the topic you are talking about.
DX.com ( http://www.dx.com/s/esp8266 ) also has a good selection of the ESP8266 -- both bare chips and proper devboards. I got the Nodemcu - compatible devboard ( http://www.dx.com/p/esp8266-es... ) myself and it has been fabulous so far. Though, it's not exactly $3 anymore.
And now, it is a great idea for newbie programmers to write apps for those internet connected devices in BASIC?
They don't have to be connected to the Internet, you know? Unless you've got a modem/router running in bridge-mode the devices will by default be running behind a NAT and I doubt most of these folks will go to the length of using UPNP to specifically request for the modem/router to open ports to the devices from the Internet.
I am using Btrfs on my NAS/firewall/server quite happily and in my experience it's been stable and performant, but overall I agree with you. The tools could be better and there are a lot of idiosyncracies here and there. Personally, I find the fact that Btrfs is terribly fragmentation-prone somewhat of an issue as running defrag on any snapshotted or deduped content will ruin the reflinks and ends up duplicating all the blocks needlessly, thereby eliminating the whole point of using snapshots in the first place.
The OP also fails to account for the fact that the game and its libraries have to do in software a lot of the things NES did in hardware. It's easy to cram a game in a small space if you only limit yourself to 3 colours per sprite and use H/W palette-swapping to show different versions of the sprite and it's an entirely different thing to show 8-bit-per-channel RGB and not being able to use palette-swapping for simplistic alternate versions of the sprites in question.
Backwards compatibility- I'm really not aware of older Linux programs failing to work on modern Linux. Maybe, somewhere, that's true- I certainly don't see it though. Linux comes packed in with standard utilities dating back to the damned 70s for fucks sake. Windows struggles just to support shit from the Windows XP era. Linux is vastly more backwards compatible than Windows- hell, it even supports programs written for stuff from prior decades BEFORE IT EXISTED.
You are mixing two different concepts and thus comparing apples and oranges: you're comparing source-level backwards-compatibility on Linux to binary-level compatibility on Windows. Yes, you can take old source-code and have it compile happily on a modern Linux-distro, but you're not running an old binary then!
Linux runs MOST windows programs, and MANY windows games. Windows can't run a single fucking Linux binary without a goddamned VM!
Another apples-to-oranges comparison. Linux does *NOT* natively run Windows-binaries, you have to run them under Wine. There is nothing stopping one from making a similar translator for running Linux-binaries under Windows, and there isn't that much of a difference between Wine and a full-blown VM.
http://dictionary.reference.com/browse/hero says for example the following: "a man of distinguished courage or ability, admired for his brave deeds and noble qualities." -- To avoid those who love to nitpick about things let's substitute "hero" with "heroine" and "man" with "woman" here and look at the rest of the definition: a heroine is basically someone who has achieved something particularly noteworthy and possibly challenging, not done something that put them or others in danger or required great physical strength. The challenge may be intellectual or mental, like e.g. a social or physics problem, instead of a huge dragon, and the strength drawn accordingly from one's brains instead of brawn.
Einstein is definitely considered a great hero in scientific circles, but did he put himself in some sort of great danger when writing down his theories? Did it require him great physical strength?
I've mentioned it before, but I really despise the trend of everyone just making a video these days. Videos are slow, you're forced to progress at the speed the video plays and jumping back and forth or trying to find some specific phrase or word is difficult or impossible; if the discussion is about something where actually visualizing the matter is important for clarity then sure, go ahead, but even then it's preferable to keep only those parts as video and the rest as text. On the other hand, if a video-format doesn't bring anything useful to the table, like e.g. you're talking about something where moving pictures don't really help clarify the subject-matter any more than a static picture accompanied by text would then stop fucking making it a god damn video.
Uhm, alsa supports truehd and dts-hd because somebody has written the support for those. New format support does not just magically appear. Part of the problem is getting the format recognized, part of the problem is changing the sink passthrough code to allocate the higher bandwidth needed for these formats, and part of the problem is a smooth transition between passthrough and PCM, allowing different clients to handle things differently. I agree that it definitely needs to be there, but it is not trivial.
Mmmno. ALSA doesn't do anything about the data that is passed through, it only sets the HDMI-device's properties for transmission of raw encoded data. PulseAudio insists on having to understand all the data that's being passed to it because it insists on upmixing/downmixing everything and thus needs to be aware of the content.
Anyway, if you are using hdmi, why do you need passthrough? Passthrough was created as a workaround to the limitations of s/pdif. They don't exist anymore if you are using hdmi.
No, passthrough exists to allow you to pass the content forward unaltered so that more capable end-points can handle processing it. A high-end receiver knows a *LOT* more about audio, the speaker-configuration and room dynamics than Kodi does and can properly process the data for best quality sound.
Slashdot Mirror
ESP8266 is a great device, but serves completely different needs. It can't act as a wireless repeater/bridge, for example -- it's not a router. Also, it only has ~80KB RAM and can be run at max 160MHz, whereas this device has a 400MHz AR9331 and 64MB RAM and runs Linux; you are basically comparing apples and oranges here.
My mind is already boggling with the possibilities, I think I'll be buying a few. I wish I had known about these things sooner than this, but, well, better late than never!
Why would you need to be a hardware-hacker to use these? You can just use telnet or any of the other vulnerabilities they found to access the device's internals via software and proceed from there to install OpenWRT-proper.
You'd lose out on interrupts on pin-state-changes when used as inputs and you'd have to implement PWM in software if you needed that.
I ordered an Orange Pi PC on eBay just recently and... boy-howdy do I regret it. It was only after ordering it that I found out that e.g. the CSI-connector isn't actually a CSI-connector and you need some expansion board to make use of it, and the expansion board isn't even supplied with the device itself -- and of course, none of this is mentioned either on the official website or their store! The forums are at the brink of self-immolation, no verification e-mails are ever received by people who try to register accounts there, the official website has a bunch of broken or outdated links, the Steven - guy behind the project has been missing for at least a week now and so on.
The hardware is real nice and personally I find their newly-announced OPi-Lite an exceedingly attractive device, but fuck if they're ever going to attract more than a few stragglers who end up horribly disappointed in the end when things are run like this. I wish I could get an OPi-Lite, but with RPi-level support.
4 gpio ports? this is not competing against a raspberry pi.
That's pretty much what I came in to say: this shit ain't an RPi - alternative, it's just a low-power PC. One of the major selling-points of RPi is the 40-pin GPIO-row, all useable natively, but with this shit you'd have to use I2C or USB GPIO-expanders and jump through extra hoops every single time you wanted to read or set a GPIO-pin state. Things get even worse if you wanted to use SPI.
If you want to know what consumer devices pose a security threat (whether cheap or expensive, webcam, router/modem or other device), just look at the list of devices that other people have loaded some version of a Linux based O/S on to. These are the devices that can be easily subverted. If your organisation is sensitive to security threats, the list of "hackable" devices should also be your list of products that should never be allowed to connect inside your company's security fence.
That's a stupid argument. The devices where it's easy to replace the firmware are also the ones that are the easiest to make sure they are secure, just replace the firmware yourself and then you can do anything you want to make it as secure as ever possible. The more closed the device is the less you can actually do to secure it!
There's not enough power/CPU to do any serious compression, and having to decompress it to do motion detection or transcoding afterwards is a waste.
Depends on what you connect the camera to. An RPi, for example, can encode the video in H/W and thus the CPU is free to do anything else. You could also do motion-detection before encoding, or you could use an actual infrared-sensor to handle motion-detection and thus the CPU could just sit idle.
If you are referring to http://www.lavrsen.dk/foswiki/... with "motion" then no, it doesn't do what I need. I was talking about making a WiFi-connected streaming camera and you're talking about a library for detecting motion -- two entirely different things. You still need a source of video to detect motion in and a device to run that library on in the first place, you know? It doesn't magically work on its own. And besides, a simple PIR attached to a GPIO-port will require a whole effing lot less CPU-power in order to detect motion than doing it in software via that library.
"Smart" webcams are always a risk, manufacturers insist on believing those devices should be available from the Internet and will try to use UPNP and other tricks to open themselves up for access from there. I have a need for a WiFi-enabled webcam that I can stream live-video from, but I was planning on just getting a ~$20 400MHz ARM-CPU WiFi-router with OpenWRT on it and a regular USB-webcam, and streaming the MJPEG - stream over RTP/RTSP -- since the video coming out of the camera is already encoded it doesn't require almost anything from the router's CPU to stream it as-is, and this way I have complete control over the entire stack and I control who and where the stream goes to.
If you perceive what they're doing as being bad, the moral thing to do is to not give them money to enable and reward the behavior.
And what if I perceive what Netflix is trying to do as a positive thing and wish to reward them for it? Netflix is just the proxy here, unsubscribing from Netflix is going to hurt them more than the content-providers -- can't both reward Netflix and punish content-providers that way. Netflix is one of the few companies that want to provide high-quality streaming-service everywhere for everyone and they provide excellent customer-support, both being things that I would like to support.
There are other ways to achieve sensory stimulation, from books to parks, or even independent films.
Yes, you can stab yourself with a knife to achieve sensory stimulation -- I do not see how that is relevant.
There was a blog-post from Netflix last year where they specifically said they are being pressured by content-providers to do this and they don't know how long they can hold out -- guess the point came where they couldn't hold out any longer. I don't blame Netflix for this, it doesn't matter to them what country you watch stuff from as long as you pay your monthly fee, but those greedy content-providers are at fault here.
You can't just compare a specific encoder against a video codec, such a comparison makes zero sense whatsoever. If you want to make a comparison then compare an encoder to an encoder or codec to a codec. There are already several HEVC-encoders out there, for example, both software-based and hardware-based, and it's ignorant to lump them all together.
50% bitrate reduction vs H.264 sure, but not vs x264 which is the current gold standard for HQ video compression.
You are comparing apples and oranges. x264 is an encoder, H.264 is a codec. There is a x265 encoder for HEVC, just as there is x264 for H.264. The rest of your post is just rambling when you don't even understand the topic you are talking about.
DX.com ( http://www.dx.com/s/esp8266 ) also has a good selection of the ESP8266 -- both bare chips and proper devboards. I got the Nodemcu - compatible devboard ( http://www.dx.com/p/esp8266-es... ) myself and it has been fabulous so far. Though, it's not exactly $3 anymore.
And now, it is a great idea for newbie programmers to write apps for those internet connected devices in BASIC?
They don't have to be connected to the Internet, you know? Unless you've got a modem/router running in bridge-mode the devices will by default be running behind a NAT and I doubt most of these folks will go to the length of using UPNP to specifically request for the modem/router to open ports to the devices from the Internet.
The ESP8266 has only one core, not two. You may be thinking of the ESP32 that has not yet been officially released that will have two CPU-cores.
I am using Btrfs on my NAS/firewall/server quite happily and in my experience it's been stable and performant, but overall I agree with you. The tools could be better and there are a lot of idiosyncracies here and there. Personally, I find the fact that Btrfs is terribly fragmentation-prone somewhat of an issue as running defrag on any snapshotted or deduped content will ruin the reflinks and ends up duplicating all the blocks needlessly, thereby eliminating the whole point of using snapshots in the first place.
The OP also fails to account for the fact that the game and its libraries have to do in software a lot of the things NES did in hardware. It's easy to cram a game in a small space if you only limit yourself to 3 colours per sprite and use H/W palette-swapping to show different versions of the sprite and it's an entirely different thing to show 8-bit-per-channel RGB and not being able to use palette-swapping for simplistic alternate versions of the sprites in question.
Programs from the 70s that run on linux still are updated and maintained, though.
Those have absolutely nothing to do with backwards-compatibility, and many of them run under Windows, too.
Actually you do not run them under wine, wine is an implementation of the windows API, your windows binary runs natively on the hardware.
That's like saying you don't run Linux-apps under Linux or Windows-apps under Windows since they run natively on the hardware.
Backwards compatibility- I'm really not aware of older Linux programs failing to work on modern Linux. Maybe, somewhere, that's true- I certainly don't see it though. Linux comes packed in with standard utilities dating back to the damned 70s for fucks sake. Windows struggles just to support shit from the Windows XP era. Linux is vastly more backwards compatible than Windows- hell, it even supports programs written for stuff from prior decades BEFORE IT EXISTED.
You are mixing two different concepts and thus comparing apples and oranges: you're comparing source-level backwards-compatibility on Linux to binary-level compatibility on Windows. Yes, you can take old source-code and have it compile happily on a modern Linux-distro, but you're not running an old binary then!
It can't even run fucking bash and it's 2015
http://win-bash.sourceforge.ne... or https://www.cygwin.com/ -- Poof, bash on Windows.
Linux runs MOST windows programs, and MANY windows games. Windows can't run a single fucking Linux binary without a goddamned VM!
Another apples-to-oranges comparison. Linux does *NOT* natively run Windows-binaries, you have to run them under Wine. There is nothing stopping one from making a similar translator for running Linux-binaries under Windows, and there isn't that much of a difference between Wine and a full-blown VM.
http://dictionary.reference.com/browse/hero says for example the following: "a man of distinguished courage or ability, admired for his brave deeds and noble qualities." -- To avoid those who love to nitpick about things let's substitute "hero" with "heroine" and "man" with "woman" here and look at the rest of the definition: a heroine is basically someone who has achieved something particularly noteworthy and possibly challenging, not done something that put them or others in danger or required great physical strength. The challenge may be intellectual or mental, like e.g. a social or physics problem, instead of a huge dragon, and the strength drawn accordingly from one's brains instead of brawn.
Einstein is definitely considered a great hero in scientific circles, but did he put himself in some sort of great danger when writing down his theories? Did it require him great physical strength?
I've mentioned it before, but I really despise the trend of everyone just making a video these days. Videos are slow, you're forced to progress at the speed the video plays and jumping back and forth or trying to find some specific phrase or word is difficult or impossible; if the discussion is about something where actually visualizing the matter is important for clarity then sure, go ahead, but even then it's preferable to keep only those parts as video and the rest as text. On the other hand, if a video-format doesn't bring anything useful to the table, like e.g. you're talking about something where moving pictures don't really help clarify the subject-matter any more than a static picture accompanied by text would then stop fucking making it a god damn video.
Uhm, alsa supports truehd and dts-hd because somebody has written the support for those. New format support does not just magically appear. Part of the problem is getting the format recognized, part of the problem is changing the sink passthrough code to allocate the higher bandwidth needed for these formats, and part of the problem is a smooth transition between passthrough and PCM, allowing different clients to handle things differently. I agree that it definitely needs to be there, but it is not trivial.
Mmmno. ALSA doesn't do anything about the data that is passed through, it only sets the HDMI-device's properties for transmission of raw encoded data. PulseAudio insists on having to understand all the data that's being passed to it because it insists on upmixing/downmixing everything and thus needs to be aware of the content.
Anyway, if you are using hdmi, why do you need passthrough? Passthrough was created as a workaround to the limitations of s/pdif. They don't exist anymore if you are using hdmi.
No, passthrough exists to allow you to pass the content forward unaltered so that more capable end-points can handle processing it. A high-end receiver knows a *LOT* more about audio, the speaker-configuration and room dynamics than Kodi does and can properly process the data for best quality sound.