On 05/02/14 19:04, Isaac Dunham wrote: >> Nope: posix specifies "k" and "b", and that's it. This seems to have >> come from gnu, and busybox seems to have copied gnu, and this is just >> implementing what gnu did. Except busybox added "swab" last year, so the >> set of options this command is implementing is basically a snapshot of >> what busybox was doing at some point in the past. > > Please also include mega (it's handy for writing disk images).
I have yet to actually bitch at the posix guys and ask them to fix their standards, but... ascii/ebcdic conversions? In their 2013 update to the 2008 spec? Really? I may have to bite the bullet and go "dudes: what?" The subset of the gnu/dammit extensions busybox chose to implement is a useful indicator, although "why swab" remains an unanswered question. If I could get a darn bsd box working with actual development environment (which means both "installs under qemu" and "package management system does not immediately flake out afterwards") that would be a good comparison point as well. I'd prefer a freebsd variant but if netbsd or openbsd or dragonfly or pcbsd are easier to get installed... I'm also poking at MacOS X a bit, or at least Darwin, because I follow somebody on twitter who ports Darwin to new hardware for fun (she's even got an internship at Apple coming up over the summer, once she graduates high school she's going to be _dangerous_), so I can ask her questions about getting the darn thing working under qemu and thus have a reference environment. So far my big point of interest is launchd, which looks more modular than systemd and less complicated than upstart. (Somewhere between launchd and upstart and android init I need to work out what toybox's set of init programs should be able to do. Even if they're separate xinetd and such I need to document how to _use_ them to do the same thing, and there's a need for an asynchronous notification mechanism that "thing is up and running now". Maybe flock() on the pid file or something...) I _don't_ care about solaris: it's dead. Debian yanking sparc support is a trailing indicator, not a leading one; Oratroll bought it for the patents, not the technology. I blogged several links to my research on the topic back when it happened: http://landley.net/notes-2010.html#24-10-2010 AIX it's dead too. This isn't as widely recognized, but it's already over and done with. Even ignoring the "AIX 5L" with the L being full Linux emuation: IBM is no longer developing it and barely able to _pretend_ to support it. One of my coworkers at Qualcomm in 2010 used to maintain the PowerPC pci bus error handling for IBM, and he left because they were cost-cutting new development out of existence 5 years ago. Two of my co-workers at my current day job are recent ex-IBM escapees who worked on AIX right up until the bitter end, they both left in the past 6 months and tell horror stories of skeleton crews drifting through a company imploding around them that's doing everything short of selling the office furniture to make its quarterly profit targets for next year after which it crashes _hard_ because the strategy is all cuts, no investment. (The only product with expansion potential in the entire company is that Watson thing that beat Jeopardy, and that's a tiny team up in New York.) This matches up with what the computer historian who wrote "Triumph of the Nerds" has been saying in his own columns covering the company: http://www.cringely.com/tag/ibm/ When the PC kicked the minicomputer up into the server space, IBM and DEC fought to the death, with DEC losing. Now the smartphone is kicking the PC up into the server space and IBM and Amazon are fighting to the death, with IBM losing. Basically Lou Gerstner brought IBM back from the dead in 1993, and rebuilt it around profitable ideas. Gersner left his successor Sam Palmisano a business plan which boiled down to "Invest $1 billion/year in Linux for the next 5 years", which Palmisano did, then he left when that business plan ran out. The current CEO's entire plan was cutting expenses and selling assets to provide quarterly earnings for wall steet, and they're running out of corpse to butcher. >> (Why did busybox implement swab? The mailing list has somebody just >> submitting it out of the blue without actually explaining their use case >> for it. I'd think this option was on the obsolete side: the "nuxi" >> problem was fairly specific to 16 bit systems, 32 bit systems have the >> "xinu" problem instead. :) > > Don't know why it was added, but openwrt backported it with this > justification: > Some boards have the WLAN EEPROM stored in flash in big-endian format, > whereas the driver requires the EEPROM in little-endian format. > The conv=swab option in dd is particularly useful in this case. Except it's conv=swab16 and there's no conv=swab32 or conv=swab64. That's the bit I don't understand. (I suppose I can _add_ a swab32.) Or is all the hardware attached to busses that don't specify endianness in their wiring diagrams so old it's guaranteed to be a 16 bit bus? Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
