About a month ago we learned Mozilla was ceasing development of the Firefox OS, admiting it was "a failure." Today (Friday) it was announced that Japanese company MozillaFactory.org is developing a board called Chirimen that
aims to be a development board for Web developers who want to build Web-connected Internet of Things devices powered by the technologies implemented in the Firefox web browser, which means Firefox OS.
Chirimen was designed from the offset to use web browser technologies in various science projects by extending the I2C and GPIO WebAPIs to control devices powered by Mozilla's Firefox OS 2.0 and higher operating systems. As such, Web developers can easily use browser technologies to develop really awesome things.
"We will share openly the firmware code, board design, manufacturing process, API spec, and all necessary sources. In this project, we honor developer's will and work on the standardization," said the Mozilla Japan community in the project's website.
Chirimen's page on Mozilla's site.
Board specs:
RK3066 SoC, 1GB DDR3 RAM, 1GB NAND Flash, two I2C ports, two UART ports, two SPI ports, a single, configurable GPIO port, one MicroSD slot, one USB port, and one USB microUSB OTG port.
Additionally, the board will come with a video micro HDMI female port, one Analog IN port, one PWM port, as well as audio analog/stereo input and output ports. Chirimen is quite compact at a size of 80 mm x 48 mm, and it's colored in red. Its hardware design is open, and the XX GPIO pins will allow devs to connect and program a wide range of physical components, such as LEDs, sensors, buttons, etc.
Related Stories
Mozilla announced earlier today that they will be cancelling the Firefox OS effort, and will cease creation of new smartphones.
From Techcrunch:
To differentiate from Android and iOS, Mozilla and its carrier partners focused on a web-first platform, with no native and only web apps. Sales, however, were always poor and the devices themselves failed to ignite a lot of consumer interest, and a number of OEMs cornered the market with a flood of cheap handsets. In a business that depends on economies of scale, it was a failure.
This comes a week after gauging interest in spinning off Thunderbird. Is Mozilla's new focus on becoming privacy-oritented enough to save the struggling company? What experience did SoylentNews users have with FirefoxOS? I'll admit, I was optimistic and even owned a ZTE Open for a few months back in 2013, but it was a step down from my feature phone at the time (Nokia Asha 311) and ZTE never delivered on the promise to provide updates to the OS.
(Score: 3, Insightful) by q.kontinuum on Saturday January 09 2016, @12:59PM
Besides the surprise that they promote a device now based on a technology declared dead a month ago: The device seems to be in a similar price range as the raspberry pi. For the raspberry, Firefox OS [mozilla.org] is also available, as well as a lot of other periphery. I'd have expected WIFI on a board targeting IoT, but only found a note to use USB WiFi module.
Do I overlook something? What's the added value compared to raspberry for this board?
BTW: I re-read the article promoted by this summmary [soylentnews.org] (yes, I know. Following the links and reading tfa is cheating.). The announcement was not to stop the development of FriefoxOS, but only to stop the development of smartphones using this OS.
http://techcrunch.com/2015/12/08/mozilla-will-stop-developing-and-selling-firefox-os-smartphones/?ncid=rss [techcrunch.com]
(emphasis added)
To me this looks actually reasonable. FirefoxOS on phone brings IMO non benefit. There are open source systems available, they have good browsers, plus better performance for games through native SDKs. I'd not buy a FirefoxOS phone at any price point.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 1, Interesting) by Anonymous Coward on Saturday January 09 2016, @01:15PM
GREAT! After they make their own hardware and operating system, do you think they'll return to making the browser stop sucking ass?
Reminds me of when I was a "newbie" to gamedev. After completing a few cheesy games to get the hang of things I realized I wanted a reusable engine so I didn't have to do all the grunt work and boilerplate, I could just focus on making games. I'd want it to be cross platform, of course, so I created a platform abstraction layer (basically a replacement for freeglut sans all the cruft no one really needs). I'd want to do network gameplay, so I figured might as well bake that into the engine, soon I was implementing UPNP and STUN and my own compression library designed for individual packets (performed way better than all the other compressors because they have a huge Huffman tree that won't fit in little packets).
The compression lib worked so well, tailored for game objects and assets that I started wrapping the file system API and inserted it there. Now, sometimes a game client would need to fetch a map from the server, so I went ahead and started building a virtual file system with symbolic links that could be non-local -- Hey, I did try integrating LFS, but in doing so I found a remote code execution vulnerability, exploited it on myself, and threw that lib out, not up to my standards; I wouldn't be responsible for gamers getting hacked.
The cross platform streaming game asset library also needs to load things into the audio and graphics systems, so I created an asset manager to stream things. Next I ran into cache invalidation issues, so I had to add remote file synch to make sure the clients got the latest version of the server files.
Everything seemed to be working great. I had built a portable API to handle all my gamedev needs, or so I thought. I started to make a game. As with any new platform, I start with a pacman clone to smoke test things. I was using straight C with my own OOP system that allows Game Object methods to change at runtime (avoids a giant gnarly switch statement) -- At first it was just the Enemy Object that could have different states "attack" or "defend", but then I expanded that to handle any arbitrary states, and extended that functionality to all game objects so it would play nice with the incremental Garbage Collector I had made.
Now, the macros for dealing with my OOP system were a bit gnarly, but far less gnarly than interfacing with Lua... Which reminded me: it would be nice if the game logic could be updated per map, and at runtime. I needed a scripting language! However, I wanted it to run really fast and be tightly integrated with C since I already had the OOP system and macros to smooth away its raw C uglyness. So, I decided to make it a compilable language that ran as interpreted VM bytecode OR could be "compiled" down into C source files to speed up part of a dedicated script, if I ever needed a piece of code to go faster -- mind you, Pacman isn't normally very resource intensive, except I had rolled together a simple neural network AI lib to train the ghosts so they could adjust their behavior matrix somewhat to adapt to your strategies as you played -- I did the N.Net just to troll other devs who spouted the common noobie meme "hurr, NEURAL NETWORKS" (ideasmen never actually implement them, but I did, and it was easy). And let me tell you, the interpreted N.Net saw massive speedup when compiled into C sources, then compiled into the binary vs runtime bytecode. (This was about 5 years before MS decided their managed language runtime should be able to do something similar).
The script compiler had a pretty slick interface between the VM and the OOP system, since the VM had dedicated opcodes to instantiate or free objects. But what I really needed was a debugger. So I started working on one. I went to look at how x86 enabled made allowances for debuggers and decided that was bullshit. No way am I injecting opcodes into running programs! That would never work with the hybrid multi-threaded & cooperative multitasking execution model anyway. Then I realized that if I had designed the VM first, I could have made it SUPER fast and had better mapping to the actual hardware -- I could compile to binary directly, or even do Just in Time compiling.
About half way through analyzing some Verilog output to see if I could squeeze a conditional in for a hardware accelerated fixed point multiplication jump table I realized something amazing: I hadn't even played my Pacman clone in a month, let alone do any real game development. That's right! I was a game developer! I used to make games! All those gripes about the shoddiness of ARM and X86 I could fix by simply growing the stack up from zero -- They DIDN'T MATTER! What the hell was I doing running a hardware simulation of my own chipset?! No one was ever going to use the hardware I was prototyping! Was I going to make my own damn game console?! Wait.... YES! I WOULD DO JUST THAT! It would be simple! An cheap single board computer would be the target...
Mozilla is at the same stage I was before I realized that game developers actually have to work on games more than underlying systems. We both had made our products little portable OS environments that even ran on phones and synchronized settings between instances, even had our own languages (they have JS and R). The difference? I was doing gamedev in my spare time, as a hobby; All that time I wasted was time scheduled for wasting. However, Mozilla actually gets paid to get lost down the rabbit hole -- and my extensions didn't break when the client was upgraded, unlike with Firefox...
(Score: 3, Informative) by mtrycz on Saturday January 09 2016, @10:49PM
1. Firefox doesn't suck, but you can have your own opinion.
2. Browser software is more complex that it seems; you're going the right direction with comparing it with game engines; except there are plenty modern game engine alternatives, while there are almost none for browsers. And there certainly was no good opensource alternative when Mozilla started Firefox. A pretty cool feat, if you ask me.
3. Mozilla makes much more than Firefox (or Firefox OS)
4. Have a nice day.
In capitalist America, ads view YOU!
(Score: 0) by Anonymous Coward on Saturday January 09 2016, @01:17PM
* Where is the announcement? No, softpedia don't count, the original.
* Where is the code? There is nothing here https://github.com/MozOpenHard/CHIRIMEN/ [github.com]
(Score: 2) by takyon on Saturday January 09 2016, @05:53PM
This is the announcement I thought of when I saw this news [soylentnews.org].
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 0) by Anonymous Coward on Saturday January 09 2016, @08:10PM
The announcement for the SBC.
(Score: 0) by Anonymous Coward on Saturday January 09 2016, @09:44PM
Sounds interesting, but why not just run a Pi with a real and more powerful OS?
Been using my FxOS phone happily for the last year. After all the news of the phone abandonment and embracing of IoT I decided it's time to bite the big one and submit to Leisure Suit Larry and his minions. Never what I wanted, but with Mozilla shifting the focus to IoT (which I don't give a shit about) it would seem I have no other choice. Sure, I could get an Ubuntu phone or go the Jolla route, if they ever truly come to the US, but why take a step back, once again, on a platform that will likely be abandoned after a year of investing money, time, and energy in. I will probably just get burned when Canonical announces, "Isn't it great? We're going IoT now! Success!"
Why did you break my heart, Moz?