"Oh, gosh, no. On Windows there's no such thing as a broken
package..."
Let W$ = Windows
Let M$ = Microsoft
On the contrary on a W$ system just about every package is broken.
Firstly, with native code programs other than the function bundled
with bare W$ itself very little code is shared between apps, the
technical details of how DLLs don't version prevents this. So when
you install a W$ app you install a separate copy of common program
parts for every program and these have to be loaded separately for
each program. Thus you use a lot of disk and memory you don't need
to, which is broken software packaging. Trisquel programs are much
better at sharing code and there is more function in the shared code.
The result is you can do more at one time with a computer running
Trisquel than you could if it were running W$.
Secondly, with Trisquel probably all your app needs will be met from
the repo. So you have one update program, which reminds you once or
twice a week when there are updates, you install them when it suits
you. W$ programs typically check individually, phoning home every
time they're loaded and if there are updates they attempt to maintain
themselves there and then. Thus interrupting your train of thought
and workflow precisely when you don't need it. Those once a month
tasks your boss sets you, which you have to use other than your usual
tools for, each become additional software maintenance sessions.
This W$ behaviour is a broken approach to delivering packages.
Thirdly you're forgetting all the software that stops working
properly or at all when maintenance, particularly a new Service Pack
has been applied. If dependencies are broken and you can still
install these are the sort of things that happen. So a percentage
are properly the consequence of not packaging properly.
