On Thursday, 2 November 2017 at 05:13:42 UTC, H. S. Teoh wrote:
On Thu, Nov 02, 2017 at 04:13:39AM +0000, codephantom via
Digitalmars-d wrote:
On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote:
> /Signed: A pissed off Windows user
I think you've summed it all up right there ;-)
But seriously, Windows rightly has its place... and for good
reasons.
Most importantly, it provided the ease of installation along
with a easy to use and easy to understand GUI, that simply
could not be provided by open source alternatives.
It's a matter of opinion. *I*, personally, find Windows
atrociously hard to do anything useful in. I get an aneurysm
trying to click through countless nested menus just to find
that one button I need, when I could have typed the right
command in 3 seconds in a Bash shell. But OTOH, I also know
that my opinion is in the minority (by far!). :-P I think it
just boils down to personal preference and habit built from
past familiarity. As they say, there is no accounting for
taste.
One thing is clear, though: claiming that Windows is "dead" is,
frankly, ridiculous. Even a non-Windows person like me who
rarely has any reason to notice things Windows-related, can see
enough circumstantial evidence around me that Windows is still
very much alive and kicking. (Even if in my ideal world there
would be no Windows... but then, if the world were my ideal,
90% of computer users out there would probably be very angry
about being forced to use obscure text-only interfaces that I'm
completely comfortable in. So it's probably not a bad thing
the real world doesn't match my ideal one. :-D)
[...]
But software is for the user, not the vendor. A user should be
able to adapt software to meet their own requirements. Closed
source prevents that.
I think open-source really is the future, and Windows will
fade into obscurity - but only if open source continues to
deliver the benefits that Windows has always been able to
deliver. If that keeps occuring, then there is little
justification for having a closed source operating system -
whether you call it Windows or whatever.
And I think trust will become a bigger issue in the near
future too...i.e. how can you trust code you can't view? You
can barely even trust code you can view ;-)
[...]
There is another side to this argument, though. How many times
have *you* reviewed the source code of the software that you
use on a daily basis? Do you really *trust* the code that you
theoretically *can* review, but haven't actually reviewed? Do
you trust the code just because some random strangers on the
internet say they've reviewed it and it looks OK?
Yes, yes, yes, so true.
It is a common argument among open source proponents that
having more eyes will reduce the number of bugs... It sounds
convincing, but the problem with that, is that this only works
when there is a relatively small amount of code and a very
large pool of potential reviewers. Unfortunately, the hard
reality today is that there is so much open source code out
there, and the rate at which open source code is being written
far exceeds the rate of growth of the number of open source
reviewers, that I'd venture to say 80-90% of open source code
out there has never seen more than a very small number of
reviewers. Probably not more than 1 or 2 for a significant
fraction of it, if even that. I have seen open source code
that probably has *never* been reviewed, because any review
would have instantly brought to light the blatantly-obvious
bugs and problems that riddle just about every page of code.
And some of that code is so ugly that even if I had personally
reviewed it to death, I still wouldn't trust anything that
depends on it, sorry to say.
And that's a nice argument for D (dmd, phobos) as it is quite
compact and relatively well written so that it can be reviewed by
mere mortals. Ever tried to read gcc or glibc ? Forget about it
if you're not an astronaut.
Even when not knowing D all to well I could understand what was
going on in phobos and check some of the common pitfalls (file
copy functions are hilariously often buggy in books and code
samples, half the time they forget the O_TRUNC in open() or the
ftruncate() to delete the old content on overwrites).
And among the scant few projects that do get above average
contributors (and thus code reviewers), we *still* have bugs
like Heartbleed that go undetected for *years*. And this is in
cryptographic code that, ostensibly, undergoes far more careful
scrutiny than more "ordinary" code. Where does that leave the
trust level of said ordinary code? Especially code that comes
from lesser projects that don't enjoy the same level of review
as high-visibility projects like OpenSSL?
That's not to say that proprietary code is any better, though.
Having worked in proprietary software development ("enterprise"
software development) for the past 2 decades or so, I can say
that the code quality isn't any better. Just because you pay
somebody to do the job doesn't guarantee they'll do a *good*
job, let's just put it that way. There's a widespread mentality
of "not my problem" that goes around in proprietary software
development. You don't want to touch some ugly code that isn't
directly your responsibility, because it could break and the
blame would fall on you. You often don't know why something
was written a certain way -- it could be part of an elaborate
bugfix for a critical customer bug, so you really don't want to
touch it and break things. So you just work around it in the
code you *are* responsible for, and let whoever it is figure
out what to do with *their* code. Unfortunately, often this
"whoever" is actually "nobody", because said persons have moved
on. So things end up never getting fixed. Also, sometimes bad
designs are left untouched because of office politics, and code
quality can greatly suffer because of that.
So true. When I worked in embedded industrial appliances, we had
to be able to reproduce exactly the same code (i.e. eprom's)
years out. Even if the code had been fixed of some other bugs,
when we had to correct a specific bug from one client, it was
only that one bug that could be fixed. Any other bug or
enhancement was off limit. The hardware and the software were
required to behave
exactly the same. There was one time when one of our controller
blocked the production line at Opel Rüsselsheim for a morning, I
wish no one that days stress level to anyone.
At least with open source code disinterested 3rd parties can
review the code without undue bias and notice problems (and
ostensibly, fix them). But let's not kid ourselves that open
source is *necessarily* better. It *can* be better in some
cases, but it depends. Trust is a far more complex issue than
"proprietary is bad, open source is good", as certain open
source zealots would have us believe. It takes more than just
being open source; other factors also play a critical role, so
just because something is open source guarantees nothing.
There's also some open source projects are also maintained by
dicks and working with them make the whole experience nasty.
