1) All the subsystems boot quickly 2) None of them need to communicate back and forth about status in complex ways 3) The list isn't too long
There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.
What is being done to mitigate risks?
What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.
How is this going to impact how Linux fits in with other Unixen?
The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.
Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.
I'm having a hard time seeing what in this article is unique to tech. The examples given are all places where the interests of the company providing the service and the interests of customers / users conflicted and the supplier decided to go with their own interests over those of their users / customers. Any business is based on having to make those choices and some of those choices need to be decided in the supplier's favor.
For example Twitter needs to boost advertising revenue per user, now that they probably have about the maximum number of users. If people want advertising supported services they are going to have to deal with advertising.
Absolutely. Where I've seen Linux successful it has never been about OS costs. So we completely agree that substantial in-house almost never makes sense to save money vs. licensing costs. I also agree that lock-in in house is far worse. More so because in house allows the business processes to become highly non standard as they become semi automated. So often about a decade after in house development the institution finds itself:
a) Not understanding their own processes well enough to completely analyze them (i.e. too many are embedded in the code) b) Having highly non standard processes that no off the shelf system can support without substantial customization
As for build vs. buy more generally though I'd say it depends on the vertical. My opinion is that in those areas where developing your own technology gives can give you a substantial edge over the competition it can make a huge difference. Walmart for example is a company that invested heavily in their in house custom logistics down to programming hardware and benefitted handsomely. Or to use an example I've worked on the claims engine for an insurance company is something where it makes sense to spend a ton.
I don't know Munich well enough to know if they had any systems where they could benefit tremendously from in house development. But that's a very different question though then what it costs to spend for a municipal systems. Still I'm surprised that they didn't get much further along after a decade. Perhaps they have and now they'll find they can't really effectively backtrack to Windows either. They may have crossed over into having a very expensive infrastructure for decades to come.
Sort of. Using your analogy the wrapper in this case is full featured and has all the capacities (plus a bit more) of a Linux for almost all applications. Each applications only needs a library set that aren't provided by Docker. And of course Docker can be modified so if you need the same library over and over... it can be added to the wrapper.
No the engine uses LXC as a component. There is a lot more to Docker then just LXC. But this comes up a lot so it is in the FAQ and I'll just quote the FAQ: Docker is not a replacement for LXC. "LXC" refers to capabilities of the Linux kernel (specifically namespaces and control groups) which allow sandboxing processes from one another, and controlling their resource allocations. On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:
Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any Docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. LXC implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom LXC configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same Docker container can run - unchanged - on many different machines, with many different configurations.
Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less RAM. We think there's more to containers than just that.
Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, Debian packages, RPMs, source tarballs, or any combination of the above, regardless of the configuration of the machines.
Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs.
Component re-use. Any container can be used as a "base image" to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal Python environment, and use it as a base for 10 different applications. Your ideal Postgresql setup can be re-used for all your future projects. And so on.
Sharing. Docker has access to a public registry where thousands of people have uploaded useful containers: anything from Redis, CouchDB, Postgres to IRC bouncers to Rails app servers to Hadoop to base images for various Linux distros. The registry also includes an official "standard library" of useful containers maintained by the Docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.
Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with Docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (Maestro, Salt, Mesos, Openstack Nova), management dashboards (docker-ui, Openstack Horizon, Shipyard), configuration management (Chef, Puppet), continuous integration (Jenkins, Strider, Travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.
Containers play the role of VMs. They are competing paradigms for how to deploy services. The Docker engine is responsible for allocating resources to, terminating and starting containers which is what the hypervisor does.
Docker is legit and important. There are a 1/2 dozen of these containerized OSes. Docker is the most flexible (it runs on a wide range of Linuxes while most of them are specific to a particular cloud vendor). It is also the most comprehensive though SoftLayer's and Azure's might pass it in that regard. A Docker container is thicker than a VM, thinner than a full Linux distribution running on a VM. It is more accurate to consider Docker an alternative to VMs and Linux distributions running in each VM.
The Docker platform doesn't actually interface with hardware it relies on Linux to do that, the same way that Google Play makes use of Android to address the actual physical hardware. I think it is accurate to say that Docker is a flavor of Linux.
Do you really expect Betty from accounting to move her screen to another user's system?
Where I've seen network transparency I'm talking about environments where the employees have high school or less. Thinks like repair or warehouse. I'm talking to someone we decide on what to do, then I push the screen to the terminal next to the relevant piece of equipment. Then maybe I duplicate it in the back to look for a part that's non-standard...
Betty from accounting is college or more. I've never seen it used in an accounting department. But I have seen it used above that level for things like planning meetings.
Why do you feel such a need to push the horror of user-friendliness that is Linux upon regular users?
I don't. In my own company we have a Mac culture. OTOH I have seen those companies and that was the point in question.
It will save you a penny in the short run but will cost you a boatload of money in lost productivity.
Actually in my experience it is the opposite. The cost of in house development is considerably higher than just paying for commercial. The benefit is much higher productivity.
Me thinks you've never seen a non-windows environment being broadly used.
Problem is you can't just change one business. Most people average only a few years between employers. By knowing the Windows way you make yourself a whole lot more employable. And by sticking with the Windows way, the cost of hiring new staff is far simpler and cheaper. Incumbency has huge, huge benefits...
This is government and it is Germany not the USA. Much slower turnover. In general though:
a) High turnover b) Demand for immediate high productivity from new employees and low-medium training costs c) Non-standard applications
I've converted those Excel power users. BTW also Word Power users can be tricky. First off one can just leave them on Windows and just treat it as an isolated non-intergrated application. So for example the accounting department uses Excel in a VM or Wine (lags about 3 years and some addons fail but core program works) or they run Linux with their office integrations in a VM on their windows boxes. That's the easy way.
If you want to make them go fully open source generally it requires a complete shift in their workflow which ultimately is beneficial. Your typical Excel poweruser is someone who is benefiting greatly from the flexibility and short time to answer of Excel while having become a poweruser to compensate for the lack of dimensionality and scalability of Excel. Introducing them to BI and Business modeling tools which are better in these areas allows the to offload their more complicated Excel functions. This transition makes them into non-powerusers and then you can switch the spreadsheet on them. They actually become more effective as they are now using tools which can handle what they really want to do with Excel. But..., and this is not a small thing, they training costs of bringing on new people are large. Accountants don't walk in the door with those skills. Which is fine for government (and Germany for that matter) with long employee retention.
Most companies have IT accounting. If you can get those people on board and they have the skills, then via. training it can migrate down to the Excel Powerusers and from there to the Excel heavy users.
Again this comes down to understanding Windows is a culture not just software and to change the software you really need to change the culture. Obviously this keeps getting easier as LibreOffice Calc gets more feature rich. It certainly would be easier today than it was a decade ago.
I've seen non windows office environments. They have an answer to you ". "What's this weird Linux thing they're making me use? I never had to use that anywhere else! Other organizations aren't converting, why are we?" They do things that Windows just doesn't do. For example a lot of them actually use network transparency and share windows between workers. I can't message "Ron take a look at this" and send him an image of my screen. Then he says come over and I move the applications screen to his system. Or (especially prior to things like VMWare View) they loved to pass whole environments between physical computers so they don't have fixed desks. The same way that employees frequently login and logout of their phone in remote offices they can now do that with their computer so they don't even need a laptop. Something like building their applications on Docker and thus they get the advantage would be the modern equivalent where Linux far surpasses Windows where they can run just about any piece of software on any system without having to worry at all about the underlying Linux. Or a lot of the gurus who in the windows world would be your Excel or Word gurus pick up a little scripting and love to automate tasks and so you have shell scripts or Perl scripts flying around the office. There is for example much more blurring of lines between servers, and network shares and desktops because server solutions are also free.
If they are still doing things the Windows way then Linux is just a bad Windows. That's the key. The office culture changes and people don't do things the Windows way anymore. When new workers come in the work culture is so different they immediately see it is nothing like their old job.
No. I imagine that over the last decade what Munich has found is that a competitive marketplace of multiple software developers has created a pretty nice rich ecosystem of software that's improving and updating while their linux stack has been largely dependent on their internal team to push forward.
Excellent point they might not be getting the benefit of sharing. They might be something like 30%+ of the entire budget for municipality specific OSS development. They would either need to sell it, sell support or fall behind. They have a chicken and the egg problem. They need to get a system close to usable before other municipalities would pick it up. Since they were trying to switch to Linux they had to hit lots of applications at once which means they couldn't spend a fortune on each one. Hence it took a long time and they were falling behind...
My general opinion that the easiest way for open source operating systems to move in was first a switch from: mostly closed and some open software on proprietary OS (windows) mostly open and some closed on proprietary OS
Which shouldn't have been that big a deal. File formats generally aren't that complex and of course they always could have set up conversion servers. Hopefully we will get ore details.
The one example of transitioning to desktop Linux. And it's failed.
That's not the one example. Lots of unix, mainframe and mini shops transitioned quickly and easily. Lots of business where the owner forced the change transitioned easily. Lots of institutions with a Windows culture looked at the cost and balked early on. Munich was an example of a large public group that put the time and effort in. But it is not the only example.
and the desktop for a regular office worker isn't it.
It is pretty good in places that never developed a Windows culture. There are certain advantages for a regular office worker that come for the Unix way of doing things. I'm surprised that after a decade they hadn't switched paradigms and people weren't enjoying the Unix advantages.
Is there anyone who really thought it would go any other way?
I did. I've been following this since it started. They seemed to have a fairly high degree of commitment and had made tons of progress. I'm shocked to see them throwing in the towel since after a decade I'd assume they no longer have a Windows culture. We know that institutions that never developed a Windows culture were able to switch to Linux easily.
Funny your suggestions already exist. Any phone can go against any server via. downloading an alternative profile and that server can have its own app distribution. https://developer.apple.com/pr...
It doesn't require rooting your phone. So yes Apple not only could do this, they do it now and have for years.
I think the app store should be organized for hundreds of thousands of applications better categorized. In particular searching by verticals, searching by interconnections to other applications, searching by level of sales... Mostly though I think the app store works pretty well the issue for most applications is they are yet another version of something for which better apps exist. The problem app developers are having is they aren't going after verticals which is where they should be in a more mature market.
If costs are anywhere near that high, this should just be a national system and not handled by localities at all. It is just insane to do this more than once.
If one reads the computerworld article it makes far weaker claims than this post. It is talking about revenue and cost of revenue. It isn't clear about inventory on hand so to get a maximum figure it marks the manufactured but unsold Surface 3's at $0. Part of a $733 million charge came from the Surface mini (developed and never shipped). There never was any claim remotely as strong as Microsoft having lost close to $1.7b in a meaningful sense. This figure is coming from:
a) Whisper down the lane where articles are summarizing each other getting successively less qualified in their calculations. b) Accounting being boring so the article writers not understanding what the original analyst (Jan Dawson at Jackdaw Research) was doing.
Slashdot Mirror
What's broken is this. The initt system assumes:
1) All the subsystems boot quickly
2) None of them need to communicate back and forth about status in complex ways
3) The list isn't too long
There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.
What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.
The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.
Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.
I'm having a hard time seeing what in this article is unique to tech. The examples given are all places where the interests of the company providing the service and the interests of customers / users conflicted and the supplier decided to go with their own interests over those of their users / customers. Any business is based on having to make those choices and some of those choices need to be decided in the supplier's favor.
For example Twitter needs to boost advertising revenue per user, now that they probably have about the maximum number of users. If people want advertising supported services they are going to have to deal with advertising.
Absolutely. Where I've seen Linux successful it has never been about OS costs. So we completely agree that substantial in-house almost never makes sense to save money vs. licensing costs. I also agree that lock-in in house is far worse. More so because in house allows the business processes to become highly non standard as they become semi automated. So often about a decade after in house development the institution finds itself:
a) Not understanding their own processes well enough to completely analyze them (i.e. too many are embedded in the code)
b) Having highly non standard processes that no off the shelf system can support without substantial customization
As for build vs. buy more generally though I'd say it depends on the vertical. My opinion is that in those areas where developing your own technology gives can give you a substantial edge over the competition it can make a huge difference. Walmart for example is a company that invested heavily in their in house custom logistics down to programming hardware and benefitted handsomely. Or to use an example I've worked on the claims engine for an insurance company is something where it makes sense to spend a ton.
I don't know Munich well enough to know if they had any systems where they could benefit tremendously from in house development. But that's a very different question though then what it costs to spend for a municipal systems. Still I'm surprised that they didn't get much further along after a decade. Perhaps they have and now they'll find they can't really effectively backtrack to Windows either. They may have crossed over into having a very expensive infrastructure for decades to come.
Sort of. Using your analogy the wrapper in this case is full featured and has all the capacities (plus a bit more) of a Linux for almost all applications. Each applications only needs a library set that aren't provided by Docker. And of course Docker can be modified so if you need the same library over and over... it can be added to the wrapper.
No the engine uses LXC as a component. There is a lot more to Docker then just LXC. But this comes up a lot so it is in the FAQ and I'll just quote the FAQ: Docker is not a replacement for LXC. "LXC" refers to capabilities of the Linux kernel (specifically namespaces and control groups) which allow sandboxing processes from one another, and controlling their resource allocations. On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:
Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any Docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. LXC implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom LXC configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same Docker container can run - unchanged - on many different machines, with many different configurations.
Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less RAM. We think there's more to containers than just that.
Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, Debian packages, RPMs, source tarballs, or any combination of the above, regardless of the configuration of the machines.
Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs.
Component re-use. Any container can be used as a "base image" to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal Python environment, and use it as a base for 10 different applications. Your ideal Postgresql setup can be re-used for all your future projects. And so on.
Sharing. Docker has access to a public registry where thousands of people have uploaded useful containers: anything from Redis, CouchDB, Postgres to IRC bouncers to Rails app servers to Hadoop to base images for various Linux distros. The registry also includes an official "standard library" of useful containers maintained by the Docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.
Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with Docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (Maestro, Salt, Mesos, Openstack Nova), management dashboards (docker-ui, Openstack Horizon, Shipyard), configuration management (Chef, Puppet), continuous integration (Jenkins, Strider, Travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.
Containers play the role of VMs. They are competing paradigms for how to deploy services. The Docker engine is responsible for allocating resources to, terminating and starting containers which is what the hypervisor does.
The Docker Engine is much thicker than a hypervisor essentially containing the full suite of services of the guest OS.
Docker is legit and important. There are a 1/2 dozen of these containerized OSes. Docker is the most flexible (it runs on a wide range of Linuxes while most of them are specific to a particular cloud vendor). It is also the most comprehensive though SoftLayer's and Azure's might pass it in that regard. A Docker container is thicker than a VM, thinner than a full Linux distribution running on a VM. It is more accurate to consider Docker an alternative to VMs and Linux distributions running in each VM.
The Docker platform doesn't actually interface with hardware it relies on Linux to do that, the same way that Google Play makes use of Android to address the actual physical hardware. I think it is accurate to say that Docker is a flavor of Linux.
No. Reread what I wrote. I'm talking desktops users.
Where I've seen network transparency I'm talking about environments where the employees have high school or less. Thinks like repair or warehouse. I'm talking to someone we decide on what to do, then I push the screen to the terminal next to the relevant piece of equipment. Then maybe I duplicate it in the back to look for a part that's non-standard...
Betty from accounting is college or more. I've never seen it used in an accounting department. But I have seen it used above that level for things like planning meetings.
I don't. In my own company we have a Mac culture. OTOH I have seen those companies and that was the point in question.
Actually in my experience it is the opposite. The cost of in house development is considerably higher than just paying for commercial. The benefit is much higher productivity.
Me thinks you've never seen a non-windows environment being broadly used.
This is government and it is Germany not the USA. Much slower turnover. In general though:
a) High turnover
b) Demand for immediate high productivity from new employees and low-medium training costs
c) Non-standard applications
Pick any 2 for your business.
I've converted those Excel power users. BTW also Word Power users can be tricky. First off one can just leave them on Windows and just treat it as an isolated non-intergrated application. So for example the accounting department uses Excel in a VM or Wine (lags about 3 years and some addons fail but core program works) or they run Linux with their office integrations in a VM on their windows boxes. That's the easy way.
If you want to make them go fully open source generally it requires a complete shift in their workflow which ultimately is beneficial. Your typical Excel poweruser is someone who is benefiting greatly from the flexibility and short time to answer of Excel while having become a poweruser to compensate for the lack of dimensionality and scalability of Excel. Introducing them to BI and Business modeling tools which are better in these areas allows the to offload their more complicated Excel functions. This transition makes them into non-powerusers and then you can switch the spreadsheet on them. They actually become more effective as they are now using tools which can handle what they really want to do with Excel. But..., and this is not a small thing, they training costs of bringing on new people are large. Accountants don't walk in the door with those skills. Which is fine for government (and Germany for that matter) with long employee retention.
Most companies have IT accounting. If you can get those people on board and they have the skills, then via. training it can migrate down to the Excel Powerusers and from there to the Excel heavy users.
Again this comes down to understanding Windows is a culture not just software and to change the software you really need to change the culture. Obviously this keeps getting easier as LibreOffice Calc gets more feature rich. It certainly would be easier today than it was a decade ago.
I've seen non windows office environments. They have an answer to you ". "What's this weird Linux thing they're making me use? I never had to use that anywhere else! Other organizations aren't converting, why are we?" They do things that Windows just doesn't do. For example a lot of them actually use network transparency and share windows between workers. I can't message "Ron take a look at this" and send him an image of my screen. Then he says come over and I move the applications screen to his system. Or (especially prior to things like VMWare View) they loved to pass whole environments between physical computers so they don't have fixed desks. The same way that employees frequently login and logout of their phone in remote offices they can now do that with their computer so they don't even need a laptop. Something like building their applications on Docker and thus they get the advantage would be the modern equivalent where Linux far surpasses Windows where they can run just about any piece of software on any system without having to worry at all about the underlying Linux. Or a lot of the gurus who in the windows world would be your Excel or Word gurus pick up a little scripting and love to automate tasks and so you have shell scripts or Perl scripts flying around the office. There is for example much more blurring of lines between servers, and network shares and desktops because server solutions are also free.
If they are still doing things the Windows way then Linux is just a bad Windows. That's the key. The office culture changes and people don't do things the Windows way anymore. When new workers come in the work culture is so different they immediately see it is nothing like their old job.
Excellent point they might not be getting the benefit of sharing. They might be something like 30%+ of the entire budget for municipality specific OSS development. They would either need to sell it, sell support or fall behind. They have a chicken and the egg problem. They need to get a system close to usable before other municipalities would pick it up. Since they were trying to switch to Linux they had to hit lots of applications at once which means they couldn't spend a fortune on each one. Hence it took a long time and they were falling behind...
My general opinion that the easiest way for open source operating systems to move in was first a switch from:
mostly closed and some open software on proprietary OS (windows)
mostly open and some closed on proprietary OS
Which shouldn't have been that big a deal. File formats generally aren't that complex and of course they always could have set up conversion servers. Hopefully we will get ore details.
That's not the one example. Lots of unix, mainframe and mini shops transitioned quickly and easily. Lots of business where the owner forced the change transitioned easily. Lots of institutions with a Windows culture looked at the cost and balked early on. Munich was an example of a large public group that put the time and effort in. But it is not the only example.
It is pretty good in places that never developed a Windows culture. There are certain advantages for a regular office worker that come for the Unix way of doing things. I'm surprised that after a decade they hadn't switched paradigms and people weren't enjoying the Unix advantages.
I did. I've been following this since it started. They seemed to have a fairly high degree of commitment and had made tons of progress. I'm shocked to see them throwing in the towel since after a decade I'd assume they no longer have a Windows culture. We know that institutions that never developed a Windows culture were able to switch to Linux easily.
So yeah put me down for surprised.
Yes. But once you examine an application you get detailed review information. You can also see summary review information when you examine the list.
Apps get reviewed by users and have a star rating for their functionality. That already happens.
Funny your suggestions already exist. Any phone can go against any server via. downloading an alternative profile and that server can have its own app distribution. https://developer.apple.com/pr...
It doesn't require rooting your phone. So yes Apple not only could do this, they do it now and have for years.
I think the app store should be organized for hundreds of thousands of applications better categorized. In particular searching by verticals, searching by interconnections to other applications, searching by level of sales... Mostly though I think the app store works pretty well the issue for most applications is they are yet another version of something for which better apps exist. The problem app developers are having is they aren't going after verticals which is where they should be in a more mature market.
If costs are anywhere near that high, this should just be a national system and not handled by localities at all. It is just insane to do this more than once.
If one reads the computerworld article it makes far weaker claims than this post. It is talking about revenue and cost of revenue. It isn't clear about inventory on hand so to get a maximum figure it marks the manufactured but unsold Surface 3's at $0. Part of a $733 million charge came from the Surface mini (developed and never shipped). There never was any claim remotely as strong as Microsoft having lost close to $1.7b in a meaningful sense. This figure is coming from:
a) Whisper down the lane where articles are summarizing each other getting successively less qualified in their calculations.
b) Accounting being boring so the article writers not understanding what the original analyst (Jan Dawson at Jackdaw Research) was doing.
Franchise destroying blunders are peer reviewed by the business press among others.