Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS for storage longevity.
It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi.
LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out
1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that.
2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.
Oh, there's an OTP in the MPU? I didn't know that.
Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity.
With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable.
I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design.
I never thought that I'd read about Microsoft allowing something like this. There seems to be a sea change in culture towards openess amongst the Big Guys at the moment. It's unfortunate however that these companies are only beginning to invest now that their core products are at stake.
They always allowed it on the old WinMo -- and they never tried to shut down the OS hackers making custom versions. Even Google tried to shut down Cyanogen, before finding a compromise and backing off.
And Microsoft has always allowed you to load whatever you want on Windows, even if they've worked really, really hard to make sure that what most people want installed is their own software, often by bundling and such. (The Windows 8 Marketplace will be a departure from this, but there are already loopholes and there will likely be more.)
They even let you load your own stuff on XBox -- and on the Zune HD -- using their free dev tools. Now that Sony has backed off their Linux for PS3 support, Microsoft is the only console maker to support this.
Microsoft knows that power users and early adopters are a crucial market for them if they're going to grow their tiny phone share at all. Power users and early adopters often like to do things that are outside the box. So if they can offer enough of the openness of Android (not nearly all of course, but enough), maybe more people will come on board for a sort of best-of-both-worlds thing: a locked down platform for the overwhelming majority that cares more about security, and an override for the enthusiasts who want to homebrew apps.
I guess it really was taken for granted until closed systems like iOS came along. A closed operating system from Microsoft prior to Apple would be very difficult to image indeed.
> I never thought that I'd read about Microsoft allowing something like this.
Microsoft can be surprisingly open and user-friendly when it feels threatened. Right now they are fully aware of the disaster that awaits them in the long run if WP7 fails in the market - Win8 seems like a stopgap measure, aimed more towards running legacy corporate desktop applications than being a true citizen of this brave new world of simplified user experiences. It's no culture change - it's adaptation for survival.
Although I'm happy MS is doing it, I'm absolutely positive that the only reason for it is to attract more developers to their platform and try to compete with Apple in one of the few areas they are widely regarded as deficient.
I don't think it's a sign of sea change at all, sadly.
By 'sea change' I'm not just referring to this instance, I'm thinking also of Silverlight and of Adobe's recent announcement about dropping Flash for mobile devices. There's also the fact that HTML5 is now a new focus for both companies (Windows 8, Adobe's authoring toolset).
It seems to me that the dynamic is, you can gain marketshare at the cost of profit per customer by being more open. So it's the competitors who aren't in first place in a given market that would consider it.
Considering that jail-braking cellphones is legal, Microsoft wasn't in a legal position to stop it, but I do give them credit for finding a way to make money from it.
Although I've not looked into exactly why Mozilla have adopted the rapid-release cycle, I'd imagine it may be something to do with the ability to quickly drop backwards-compatibility and support. That way the code base can mature faster and less time is spent on redunant versions.
The most important reason for it was to keep new features from being stuck in limbo just because they happened to be part of the same branch as a feature that was taking a long time to be production ready. This is what killed us with 4.0. There were big and nice features in 4 that were actually ready more than 6 months prior to release, but they couldn't go because they were "full release" features and they were waiting for other features that were considered to be "must have" for 4.0.
With the rapid release cycle, when features start development, they have the ability to be easily configured out of the release product if they aren't ready for a particular version. We have a reliable release schedule that we expect to hit every 6 weeks. Obviously, we do our best to have as many new features as are ready be part of each release, but we don't leave people wondering when it will finally happen because we keep to the schedule and release the features that are ready.
Some of the biggest parts of this release were actually groundwork improvements to make the add-ons ecosphere more comfortable in the context of rapid release.
Remote: Yes
Willing to relocate: Maybe in a year or two.
Technologies: Java/SwiftUI (Mobile). C/C++ (Embedded). Go/Node.js/PHP/Python (Backend/ML). GNU/Linux. Currently studying Advanced Cloud Engineer Bootcamp by Linux Foundation.
CV: https://www.linkedin.com/in/stephenkarllang/
Email: stephen [at] kaizen [dot] digital
Looking for freelance/contracts. 14 years experience.