Ted: Certainly making the big cpe makers and ISPs better able to meet their market requirements in the open source age is high on my list of things to fix.
In the bad old days, a cpe maker would put out a big RFP with their requirements, some big ODM or ODMs would bid on it, and after 5 years the next product would come out, 2+ years late, there would be acrimony and finger pointing on all sides, and the product would not be as good as it could be. In the present day, it really pays for the cpe maker (or ISP) to "feed the penguins" - to identify key technologies *and their primary authors* during their RFP process, and to try to put a floor under them directly, to get the code more "out there" in an 18 month timescale... and thus thoroughly tested before it has to be integrated and then burned into flash by the ODM. I think this approach chops of *years* of development time off of shipping new stuff into embedded systems, and results in a much higher quality product overall as the new features have the elegance, and robustness that only an author with time, taste, and resources, can produce. On Sun, Aug 31, 2014 at 9:45 AM, Theodore Ts'o <[email protected]> wrote: > On Sun, Aug 31, 2014 at 12:05:52AM -0700, David Lang wrote: >> >> One other place this sort of thing is likely to be useful is for Raspberry >> Pi and other small (embedded by some defintions) systems that use SD cards >> for their OS system. The I/O to the storage is so slow that the saved I/O >> time is likely to more than cover the cost of the decompression. > > Yeah, that's the main argument I've heard for wanting to do > decompression; it's to speed up I/O when using HDD's and cheap flash > that has a minimal number of flash channels. Faster boot times are good. I also tend to think "using less flash" out of your total might extend the service life. I do not have a good awareness of what filesystem(s) people are planning to ship in the next generation of embedded systems, certainly I see a lot of ext4, I've seen some try btrfs, and the old standbys of squashfs and jffs2 are still good choices when you are below 32MB flaash. Better tailoring a fs (as ubi did) for better speed, higher reliability and easy updates in the field strikes me as a very good idea. > >> Raspberry Pi systems have had to move to 4G cards as their base because it's >> just not possible to have the standard install do more than boot on a 2G >> card. > > 2G SD cards -- $42.95 for a 10-pack > 4G SD cards -- $53.95 for a 10-pack It really is astounding isn't it! > > I have a design for adding compression, but except as a hobby effort, > I've had a lot of trouble finding a company who would be willing to > support an engineer to actually do the effort. :-( > > Unless the company is making a truly vast number of devices, and are > very sensitive to the BOM cost, it might not make sense from an > engineering / business plan point of view. It's a small matter of finding a company or companies with sufficient vision, moving potentially millions of units, that want to save 20 cents each, realizing that they can't go it alone. I am loving the hipnet, homenet and homewrt's efforts to further their goals, which are much wider than "saving money" - but in making new technologies more available on cpe. http://www.cablelabs.com/the-future-of-home-networking-putting-the-hip-in-hipnet/ http://www.homewrt.org/doku.php These groups have realized that for certain key new features, once identified, they can't get them from the ODM, but have to go direct to the authors of the technologies in our new age modern open source world in order to get them done enough - and "out there" enough and tested enough - for the ODM to integrate and ship, and put floors under various things needed. (I was delighted comcast stepped up to get dnssec into dnsmasq, in particular. So many people were whining about lack of dnssec adoption... and there has been much work on routing protocols as an outgrowth of all that, also... and so much behind the scenes integration and automation work in that quest for extra nines of reliability. ) > > So it will probably be something I do "for fun", when I can find the > time.... and there are a lot of other projects where companies are > willing to sponsor engineers to add new features, such as encryption, > reflink support, data checksums, etc., where if I can help them land > those features, it's unfortunately going to be higher priority than my > personally working on compression support for ext4. > > But if someone is interested in working on it, they should talk to me; > I'd be happy to work with someone interested in working on the > project. I will put possible work on ext4 compression and on ubifs on the possible roadmap for the next phase of the cerowrt effort. > - Ted -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
