On Tue, Aug 27, 2019 at 12:09:46PM -0400, Theodore Y. Ts'o wrote: > On Tue, Aug 27, 2019 at 03:30:09PM +0100, Alan Cox wrote: > > > > 2. security updates > > > iot devices, mobile telephones, tv-sets etc have severe problems > > > with security updates and general updating. LSB could pobably be > > > helping out with this, especially for smaller firms, that have not > > > gotten their own systems. > > > > And this really has nothing to do with ABI problems and everything to do > > with competence and legal incentives. IOT you usually control the full > > stack so the ABI is really irrelevant, you can roll your new build > > without even caring about the ABI of the previous one. The Android > > train-wreck isn't at all LSB relevant because they don't even use the > > same libraries, and the user space ABIs are totally unrelated to LSB > > anyway. > > Alan is absolutely correct. The problems around security updates have > everything to do with business, and nothing to do with > standardization. (It's amazing: people walk around with ISO-shapped > hammers, and they think everything is an ISO-shaped nail....)o
i am not talking iso lsb, but lf lsb, iso lsb should be === lf lsb. > The cost of shipping security updates costs money, and even if AOSP > shipps security updates every month free of charge to all the handset > manufacturers, they all have to integrate those changes into their > "value added" enhancements to android, and to deal with the fact that > the different devices have different hardware devices. So that means > every update will require testing, not just of base OS, but also of > the upgrade process. Customers do get really angry when their devices > get turned into bricks.... > > The problem is how to pay for this engineering work. There are really > only a couple of different ways. > > 1) Charge a lot more for the devices. The problem is that customers > aren't really willing to pay for security. They get angry when their > device gets penetrated and their data encrypted and held for ransom, > of course, but they don't seem willing to pay for it. > > 2) Charge a monthly subscription fee to pay for the ongoing > engineering costs. The problem is the same as above; customers don't > want to pay for the engineering work. So do you make the devices stop > functioning if they don't pay the subscription costs, or do you let > the devices stay vulnerable? Both have tradeoffs. Customers get > really angry when their devices get turned into bricks. But leaving a > lot of vulnerable devices, which can be used by malware authors to > attack other devices, ala Windows XP, is also not great place to be. > > 3) Find a way to monetize the "digital exhaust" generated by customers > in a way which is least damaging of their privacy such that the > customers are OK with the use of their data. People may hate the > large US Technology firms which are pursuing this path, but what do > you think is paying for the engineering work of the free montly > security updates for AOSP? yes for a business man everything is business and money. it ts amazing, people are walking around with money, and they think everything is a money problem.... i am not talking android, although I think it is strange that google with all its money and brainpower has not thought out a scheme for updating android removing manufacturers from the loop. given the success of project treble, someting better should be made. > One other complication in this whole mess is governments and privacy > advocates, who may have their own ideas of what is good public policy > independent of what the customers want (or actually want, as revealed > by their purchasing choices). So even if *customers* are OK with the > situation, privacy advocates and EU nations, may, in their arrogance, > think they know better than their voting public. (And to be fair, > sometimes they're actually right; the hoi polloi can really make some > awful choices not in their long-term self-interest. *Cough*, Brexit, > Trump, et. al.) > > Standards really can't solve what is at its heart, an economic and > social problem. It can't even really reduce the engineering effort > unless you think ISO can standardize the hardware platforms --- and > unless ISO has an enforcement arm, that's really not going to work. > There is some amount of effort to standardize the hardware platforms > by Chrome OS and Wear OS, so that you can make the updates not require > any kind of customization and centralize the testing. I beg to differ. imho you can design an architecture that isolates work and ensures smooth transitions, viz. debian / ubuntu /mint update and upgrading framework. > However, there are those who have argued that Wear OS devices don't > have enough ways of differentiating themselves from each other from a > feature, and that has held back the Wear OS ecosystem. The point is > moot, however, since trying to force consumer products into design > straitjackets would never work if ISO was the one trying to impose the > straitjacket. on the amd64 platform hw and their drivers are normally well defined. keld _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
