Microsoft makes a hardware platform. They raise the price of Windows to all the present manufacturers, while selling the hardware at or below cost, driving them out of business. Now it is ok for them to bundle whatever apps they want [?]
No, this would be using its monopoly in
operating systems to not only enter a new
market, but to throttle that market in its
favor. This would be a clear violation of
anti-trust laws.
Apple is not a monopoly. People have to
choose to use Apple products, and can just
as easily choose not to.
Note that this is a discussion of the legal
aspects of the issue, not anything concerning
morality or ethics.
For doing the exact same thing. And, save the monopoly bullshit, that's no excuse.
The monopoly status of Microsoft makes all the
difference, as a matter of fact.
Not everybody has a problem with bundling, per
se. I do not think it is appropriate to
artificially define where an OS ends and where
applications begin. Historically, there have
been many operating systems far less powerful
than Linux or the NT kernel, so it would be
rather silly to set a hard limit on where an
OS must end.
What was the problem? Their variable pricing.
Since the cost of Microsoft Windows is both
variable and unavoidable for OEMs, this
allows Microsoft to exert extraordinary
pressure on them to ban things like pre-installing
Netscape. There was very few reasons
otherwise for an OEM to not pre-install
Netscape, which was free anyway. This is also
why simply requiring Microsoft to sell Windows
at the same price (as determined by Microsoft)
would already greatly reduce the undue
influence they have over OEMs.
Software, especially popular software, all tend
to grow. If you write Photoshop filters for
a living, be prepared that Adobe may one day
ship a similar one by default. This isn't
really a new thing.
More interestingly, consider Linux. Linux may
have killed any number of small operating
systems for various niches, and if its
advocates are to be believed, it may one day
kill off Microsoft Windows. Can Microsoft
assert some moral right to keep selling
Windows, rather than "find a new gig"?
I believe (for right or wrong) it is common for developers to have an "if you can't understand it, that's your problem" attitude.
FWIW, this has not been my professional
experience. IME, there are far more of the
"yes, you're right, but fixing it would make
us lose time and stability, so I won't." The
end result is the same (code deteriorates
over time), but the attitude is slightly
different.
you believe commercial software developers have to put release schedule ahead of feature completeness due to customer restraints.
You forgot to consider the phrase "(real or
imagined)" in my statement. The former
refers to customers banging down your door,
the latter refers to management concluding
that unless we shipped right now, something
even worse (than shipping prematurely) is
going to happen.
I don't think it's because there is no "customer" to demand timeliness. I just think the people running those projects have a better understanding that users prioritize feature completeness over release dates.
I don't know about your professional experience,
but mine typically involves very powerful
customers who in turn have deadline commitments
to even more powerful customers. In a nutshell,
if you slip your schedule, you will surely be
blamed for everything else that goes wrong.
If you ship something inferior, you might
be able to issue a patch later, or you might
be able to blame another vendor who screws up
even more badly. The temptation is often
overwhelming, but yes, this is an
unprofessional thing to do.
This is not to say these customers don't want
a bug-free and feature-complete product by the
deadline. They do, and we know they do. The
problem is that they make missing the deadline
an even bigger deal.
I felt insulted that you read my comments as an excuse for poor behavior
This is what led me to it:
if I'm writing my own one-man-show app for my employer, knowing nobody else is likely to ever see the code, it'll end up more like a Q&D.
As you know, the longevity of any given piece
of code is very difficult to predict. Murphy's
Law dictates that it's too often the quick and
dirty hacks that haunt forever. What I'm
trying to stress is that even the fact (which
you can't really be sure of) that nobody will
ever see the code should not be a reason to
do a sloppy job.
So, you disagree that human nature makes folk work harder when someone they think is important is paying attention?
No, not at all. I completely agree that it's
human nature. I'm saying it's not an excuse,
and it is unprofessional to vary the quality
of your work depending on how closely you are
examined. Ethical behavior is fundamentally
something you ask of yourself.
Many professional developers [...] don't care if anybody or everybody is looking.
Then they should not be paid to do the work.
I don't care if it's human nature or not.
Every project out there is developed for somebody regardless of the model used to develop it. Apache, PHP, sendmail, bind, Evolution, ghostscript, gimp, (shall I continue) all have customers.
The general lack of a financial relationship
between free software "customers" and their
developers permits a different focus for
development. While it is true that a project
completely oblivious to its customers will
doubtlessly fail, free software does get away
with more author-driven development.
Releasing software before it's ready just to "make the date" is fucked up. Look at Oracle 11i. Guess the users wanted it, so it must've been the right decision, eh?
Who said it was the right decision? In fact,
your example (which I am not familiar with)
proves my point that commercial software have
various pressures that free software don't.
This allows and causes them to optimize in
different directions.
Stop blaming your customers for your need to hack in stupid features. Blame management.
Sometimes it's management, sometimes it's
customers. The point is that a developing
software as a business means you are subject
to external influences that may not make
good technical sense, and a commercial
developer is less able to resist that
influence.
You and I both know people tend to cut corners when nobody's looking.
Yes, I know. I'm not sure what I wrote to
make you think otherwise. The point is,
however, that it shouldn't be. It's
unprofessional to do that, and should not be
excused by human nature.
I didn't say my house was a fucking wreck when nobody's around. I said it's not immaculate. It's clean and orderly, but not immaculate.
The key question here is whether you are paid
to keep your house immaculate. As you pointed
out, your CEO emphasizes "make it work" over
"document it". That's fine, because he or
she is responsible for that business decision.
This means that if you run out of time, you
will probably fail to document some things.
The key point is what your employer is paying
for, and whether he or she is getting it.
However, if you have months of free time at
the end of a project, and still fail to
document your code because nobody is looking,
that's human nature, and that's unprofessional.
The precise problem here is that you are
in fact expected to document the code properly
if you had the time, whether or not your boss
is going to look over your work.
I would also appreciate if you left your
profanities at home, if you are actually
interested in discussion. That's another
sign of professionalism.
Of course code that is peer reviewed by a large group of coders will become better over time.
I don't believe that is the reason.
Free (beer) software is more analogous to an
engineer-driven company. They use what
the engineers think is good development
practices, and optimize for a better (fewer
bugs, faster, more configurable, etc.) product.
The result is in fact a better product, if
the company doesn't run out of money before
shipping anything. Most other companies do
not have this kind of luxury, and must bend
over backwards to keep customers happy. Often
this means incorporating ill-suited features
and fixes, polluting the source code. Just as
often, releases are rushed out the door because
they're needed, not because they're ready.
Fundamentally, free software isn't even playing
the same game as commercial software.
On the flip side, what's the most common
criticism of free software? Poor UI. That's
of course not inevitable, but a project run
by engineers will often emphasize function
over "form", which is a common blind spot.
Most proprietary code is only reviewed until the developers have ironed all the bugs necessary to get it to run reliably. Then it's shelved until the support lifecycle requires a fix.
What are you talking about? Every place I've
ever worked reviewed code at or about the time
you check the code into source control.
Conversly, Open Source projects have a huge interested user base [...]
These are the exceptions, not the rule. Most
open source projects don't attract much
attention at all, which is exactly the folly
of this study.
From what I know, I'm willing to believe that
it's possible for the best open source software
to surpass the best commercial software in
terms of code quality. However, I would not
be surprised at all if the average quality of
open source software is much lower than the
average quality of commercial software. By
"average", I'm counting all those projects on
Sourceforge, and so should you.
What this means is that open source is not a
magic pill that attracts lots of highly
qualified developers to help you debug. The
code doesn't clean itself up just because you
uploaded it to Sourceforge.
And that's simply because of human nature. It's like cleaning house. If I *know* people are coming over and likely to see my house, I want it clean and orderly. If I *know* the reverse is true, I have less incentive to make my house immaculate.
To extend the analogy, considering that you're
getting paid in part to keep your house clean,
you're doing an utterly unprofessional job, and
blaming human nature is just ridiculous.
Commercial software are subject to one more
constraint than free software: customers.
Customers (real or imagined) demand that the
software be released at a particular time,
ready or not. Customers demand specific
features, however poorly that fits into the
software's architecture. The need to stay
competitive in terms of features (frequently
unforeseeable at initial design) also results
in hacks that don't quite fit in.
This is the nature of commercial concerns.
Most professional developers I know care about
the quality of the code they put out, even if
only co-workers will ever see the sources.
Don't extrapolate your own lack of
professionalism to the rest of the industry.
Linux has a stable tree and an unstable tree. Developers work on the stable tree to fix bugs and on the unstable tree to put in new features. I think this is a great system. I wish Microsoft learns from it.
Unless Microsoft does things differently from
just about every other commercial software
developer, they have a (or a few) developer
trunk where new features are added in. At
some point before a release, a release branch
is created off the main trunk. Modifications
to the release branches are tightly controlled,
mainly restricted to bug fixes. After a
sufficient level of stability has been
achieved on the release branch, you designate
a "golden master" which is then shipped. The
release branch can continue to be used for
maintenance releases, or a new branch can
be created off it to make maintenance releases.
That's not fundamentally different from the
Linux process, as you can see. The frequency
of releases and control over the release
branches do differ from project to project,
but I'll be really surprised if Microsoft
does all its work on a single trunk line of
code.
The only thing I didnt like was when
Microsoft moved away from Windows 95 to
Windows 98 and others before fixing all
the bugs in Windows 95.
Demand the quality level you require. You're
the customer!
I would prefer their to be far more handset choice than there is.
Handsets cost a lot of money to develop, and
they devalue very very quickly. If you want
more variety, that'll probably come at the
price of having to pay quite a bit even for
older models.
year after year Congress gives the Pentagon more money than they ask for.
The money is intended for the Pentagon to buy
weapons and other products from manufacturers
from their home states. I don't see how
saving taxpayer money by switching to Linux
benefits anybody in Congress.
I think that if calling something one thing leads to a bunch of confusion, that is not good.
You're right, but I'm not arguing if
"Linux" is a good or unconfusing name for
anything, including an operating system kernel.
I'm objecting to people calling it an "improper"
name, which implies wrongdoing.
Irrelevant of the GNU/Linux (proper) vs. Linux (improper) way to say it, Linus Torvalds did not create the OS. He started the kernel.
Sure, but now it's named after him. That in
itself is "unfair" to a number of people who
have contributed a lot to the kernel. The
point is, things get named frequently as
historical accidents. Linus obviously didn't
intend to "hog" all the "glory", and Red Hat
probably didn't deliberately choose to not
credit GNU contributions. Remember Christopher
Columbus? Well, the continent got named
"America", not "Columbia". Life's like that
sometimes.
I'm objecting to the distinction between
"proper" and "improper" naming, not disputing
that credit should be given where due. Yes,
a journalist should do good research before
writing; no, it's not "improper" to call it
Linux. It's not even "improper" to call it
"Red Hat Operating System", for example.
He did not write the entire operating system -- properly called GNU/Linux. He wrote one component necessary for the operating system that is now improperly called "Linux".
You can argue (on and on) about what
is a better name for an operating system
composed of the Linux kernel and the GNU
user space utilities, but don't dismiss
opposing opinions as "improper". When Red
Hat put together their distribution, they
called it "Red Hat Linux". There's nothing
unethical about that, because the GPL does
not require any credit. In fact, they could
have called it "Red Hat Operating System",
and credited no one.
Remember the Linux Router Project guy who
was lambasted for wanting credit (and money)
for his volunteer work? Same deal. If GNU
wanted the "glory", it should've required it
as a condition in the GPL.
Note that I'm not saying it isn't arguable,
just that there was no impropriety in not
crediting GNU.
[Torvalds] has simply claimed credit for the Linux kernel.
Not even that. He said recently, "as the owner of the copyright in the collective of the Linux kernel, I shepherd even more [intellectual
properties]", a clear statement that he is
not even claiming credit for the entire
kernel. Even then, most other important
kernel contributors are not credited nearly
as much as Linus has been, especially when
you consider that the kernel bears his name.
Would you like to rename Linux the kernel
as well?
The part they lacked most, the kernel, has been so long in coming almost because of that fact -- they recreated the OS to work with existing kernels, so there wasn't a dire need for one.
Given the philosophical drive of the GNU
Project, I highly doubt this statement. I
don't think GNU thought it was such a great
idea to run free utilities on top of a
closed-source proprietary kernel.
the FSF owns copyright to every line of code in a GNU project (to prevent silly suits such as this one).
Nothing can prevent a lawsuit. Some things
help you win one. In any case, somebody who
steals code (say, from the company he works
for) and contributes it to the GNU project
will result in the same actionable
contamination.
Does this bill have any chance of getting through the two houses of Congress?
There are three important factors here:
Disney doesn't really care if it passes.
They can easily afford the registration fee
and procedure to protect their copyrighted
works.
Disney would look really stupid if it
opposed even this bill. At the time of the
Sonny Bono Act, Disney was "protecting its
investment" from lapsing into the public
domain, so the question was "how long should
copyright really be?" Today, the question
is "should copyright last over fifty years
with no obligation from the creator to even
register?"
Disney can use the works that do lapse
into the public domain in its own products,
without having to pay royalties.
If Disney realizes the opportunity to create
some good PR for itself (for little or no
cost!), then maybe it'll have a chance.
Pretty much all Linux apps can be compiled
for all supported architectures
I seriously doubt that.
A lot of C programs out there (both commercial
and free) contain assumptions on the size of
various types like "int" being 32 bits and
"short" being 16. Some also assume a certain
byte ordering (usually assuming little-endian).
Some assume that structures are padded in a
particular way (i.e., no padding). Some
rely on the order of evaluation on a particular
platform. Most of these are mistakes that
are quite difficult to catch on a single
platform, because the code works "correctly"
on that platform. This is a problem common
to C and C++ programs, and is not unique to
Linux but certainly affects Linux.
Darwin is only a little bit open. You can see the source but there are a lot of licensing restrictions imposed on what you can actually do with it.
What restrictions are you referring to?
Since Linux works very well on my Mac hardware and doesn't impose the limitations of OSX it's what I prefer to run most of the time
Let's discuss the "limitations" you cited,
one by one.
"restrictive licenses" - doesn't affect
daily use, so it shouldn't affect which OS
you run most of the time.
"can get source code" - likewise irrelevant
to daily use.
"can reconfigure" - how much time do you
spend reconfiguring as opposed to working?
"can become involved" - you can volunteer
for Darwin development as well, you know, and
you can likewise write a new OS X app.
So I'm afraid I don't see why you prefer
Linux to use "most of the time". The factors
you cited are valid, but are not relevant,
because the limitations don't affect usage.
As I see it, even if Apple fudged the numbers a bit (like what manufacturer hasn't), these new G5s are still the first time Apple can justifiably say that they are "comparable" (whatever that mean, and, like I care!) to Windows machines.
Correct. The most relevant conclusion one
should draw from the Apple benchmarks is that
the artificial benchmarks are now officially
irrelevant, because the difference is now small
enough that what application you run will make
all the difference.
I am not a computer guru (by any stretch of the imagination), but don't you all find it pretty lame that Apple needs a 64 bit processor to come close to the speeds of a 32 bit Pentium?
That's entirely irrelevant. For example, some
tasks can be more quickly accomplished with
a CPU with half the raw clock speed, but
twice the cache size. The relevant question
is which really is faster (for those with a
real need and no budget constraint), and
which has a better performance per dollar.
To be more specific, the personal computer
started with 8-bit CPUs. Since the numbers
we process are frequently larger than 255,
moving to 16-bit CPUs alone gave a large
performance boost. Similarly, 32-bit CPUs
gave a boost to processing larger numbers.
However, since 32-bit CPUs can handle
numbers up to over 4 billion, the inherent
advantage of going to 64-bit is diminished,
especially compared to the costs. That is,
32-bit CPUs are really at a sweet spot, and
have undergone many many optimizations without
going 64-bit.
If you look back in history, the 8-bit Apple
][ came out in 1977. The 16-bit IBM PC
followed in just four years. The 32-bit
IBM PS/2 followed in just three years, which
was 1987. Then, we stayed at 32-bits for
the next 16 years. IOW, the P4 you see today
is the culmination of 16 years of 32-bit
computing, which is not to be scoffed at.
As 64-bit computing becomes more prevalent,
we will find applications for which 32-bit
CPUs really struggle at, but it's quite
understandable that for many existing
applications 32-bit CPUs are really quite
good at their job.
All this talk of gcc removing a variable is naive at best, misinformation if the speaker is knowledgable on the subject.
Actually, we should pretend it isn't. We
should take the gcc comparison as holy gospel,
and buy lots of Macs because of it. This
will compel Intel and AMD to start pouring
lots of resources into improving gcc's x86
optimizations, which will compel Apple and IBM
to do even more for the PowerPC, and so on.
All of these optimizations will not only
make gcc a kick-ass compiler, it will also
make Linux and other free software run faster.
If anything, Apple should be talking up the benefits of the OS and the "Apple System" (where everything works seamlessly) rather than the raw speed of the processor and leaving the benchmarking to review sites.
They have been doing that for years, in case
you haven't noticed. The question that the
public has about the G5 is not how well it
runs MacOS X. We take it for granted that it
will run MacOS X just fine. The big question
is how fast the G5 really is, and this is a
question that Apple cannot dodge.
Before the G5, Apple was at serious risk of
losing a core group of customers who really
do need high end power - people who deal with
large graphics images, audio, and video.
QuarkXPress taking forever to port to OS X
didn't help, and even Pro Tools took a while
to get an OS X version running. Apple
customers are loyal, yes, but at some point
they do have to upgrade. It was increasingly
undeniable that the x86 not only had the
better price performance ratio (which Mac
users generally accept and dismiss in favor
of a more pleasant overall experience), it
was also much faster. That really does
impact the bottom line for these users.
So no, I don't think Apple could've done
anything except confront the performance issue
head on.
You don't design a processor without also
creating a compiler architecture designed for
that CPU- it is one and the same.
I'm not sure what you are referring to by
"compiler architecture". Most compilers
are structured in the same way, with a
front end that parses source code to
generate some form of intermediate code,
a back end to generate and optimize assembly
code from the intermediate code, and an
assembler to actually generate binary code.
Having said that, you are correct that an
optimizing compiler is not a distinct
product from a high performance CPU. In
fact, early RISC chips relied greatly on
having good optimizing compilers to help
re-order instructions for a lot of its
speed.
I guess that means Netflix is crossed off my list.
I don't think anyone needs to be too hasty.
In this business environment, many patents are
"defensive" in nature. That is, apply for a
patent in case your competitor does it first
and pulls the rug from right underneath you.
It might be instructive to see what NetFlix
does with the patent before deciding whether to
punish them.
Now, that's not to say the US patent system
doesn't need reform, just that there's a
difference between a predatory abuse of a
bad system, and a self preservative abuse.
And how many of these computer illiterates are buying state-of-the-art G5 desktop machines?
Come ON. It's a power user's machine.
You are very, very confused.
You are equating people who need a lot of computing
horsepower ("power user") with those who know a lot
(or even want to know a lot) about computers. A
graphic artist or video editor might drive the high end
demand for CPU power, yet not want to deal with many
of the intricacies that you would consider commonplace.
have a bit of respect for your other (non-imbecile) customers.
Do they have to design and sell every bit of equipment
to have this respect? Exactly what is wrong with just
buying another mouse from another vendor? Or are
you just worried that the color won't go well together?
Re:XP catch-up release (flamesuit on...)
on
Jaguar is Over
·
· Score: 2, Insightful
I hate to say this, but it looks like a bit of a Windows XP-catch up release to me.
There's feature as it appears on a bullet
list, and there's feature that's worth using.
Apple was not the first to come up with an
portable MP3 player, or probably even a hard
disk based MP3 player. Yet the iPod is among
the best portable MP3 players in the market,
if not the best. iTunes was not the first MP3
player and organizer. Final Cut Pro was not
the first video editing software. MacOS X
is not the first Unix descendant to try to
make it on the desktop.
I suggest a little benefit of the doubt for
a company that has been playing a brilliant
game of catch up for the past couple of years.
How would they sell it? There's no copyright, everyone can just makes copies for free.
There are at least two viable business models
in this case.
Like Red Hat, you can sell support. Note that
a big famous company selling support for free
software can be more attractive to a client
than the original author offering paid support.
Like CheapBytes, you can sell convenience.
Their costs are low (mainly consisting of
downloading Linux distribution ISOs, and making
CD masters), and they can't legally prevent
people from making copies, yet they're still
around.
Either way, the original author will see none
of the money.
If your going to start up something in GPL and release it.. don't EXPECT anything more than a "Hey thats cool" e-mail in return..
Don't even expect that. I released a little
game that I made as an exercise, and it was
downloaded about 1,500 times over two versions.
It got 7 comments on Versiontracker, and I got
maybe three or four email with kind and
appreciated words. I'm not at all bitter
about it, because I got what I wanted (a
programming exercise in a new platform), but
it's important not to expect a lot of
expressed gratitude.
It's too bad that this person turned into an
object lesson for:
Release software for free
???
Profit!
but as you said, he had unreasonable
expectations. Besides, since his work is
based on Linux, it would be interesting to
know if he had forwarded a portion of
the donations he received to the Linux
kernel hackers.
the reason the GPL is often referred to as "copyleft" is because there's no reason it should exist if it were not possible to copyright software. It's a manner to fight copyright using its own laws.
No, the GPL attempts to control what the recipient may
or may not do with the source code. Specifically, it
requires (not requests, requires) that you distribute
modified source code if you distribute modified
binaries. There is no legal basis (though
there is of course an ethical one) for this requirement
if not for copyright.
Basically, these "licenses" depend on copyright because it exists, but open source would do very well without them if no other software was copyrighted.
Without copyright, a company can take GPL code,
modify it slightly, and actually sell your hard work
simply because they can afford marketing. I'm not
as sure as you are that the open source community
would be just as vibrant.
Slashdot Mirror
No, this would be using its monopoly in operating systems to not only enter a new market, but to throttle that market in its favor. This would be a clear violation of anti-trust laws.
Apple is not a monopoly. People have to choose to use Apple products, and can just as easily choose not to.
Note that this is a discussion of the legal aspects of the issue, not anything concerning morality or ethics.
The monopoly status of Microsoft makes all the difference, as a matter of fact.
Not everybody has a problem with bundling, per se. I do not think it is appropriate to artificially define where an OS ends and where applications begin. Historically, there have been many operating systems far less powerful than Linux or the NT kernel, so it would be rather silly to set a hard limit on where an OS must end.
What was the problem? Their variable pricing. Since the cost of Microsoft Windows is both variable and unavoidable for OEMs, this allows Microsoft to exert extraordinary pressure on them to ban things like pre-installing Netscape. There was very few reasons otherwise for an OEM to not pre-install Netscape, which was free anyway. This is also why simply requiring Microsoft to sell Windows at the same price (as determined by Microsoft) would already greatly reduce the undue influence they have over OEMs.
Software, especially popular software, all tend to grow. If you write Photoshop filters for a living, be prepared that Adobe may one day ship a similar one by default. This isn't really a new thing. More interestingly, consider Linux. Linux may have killed any number of small operating systems for various niches, and if its advocates are to be believed, it may one day kill off Microsoft Windows. Can Microsoft assert some moral right to keep selling Windows, rather than "find a new gig"?
FWIW, this has not been my professional experience. IME, there are far more of the "yes, you're right, but fixing it would make us lose time and stability, so I won't." The end result is the same (code deteriorates over time), but the attitude is slightly different.
you believe commercial software developers have to put release schedule ahead of feature completeness due to customer restraints.
You forgot to consider the phrase "(real or imagined)" in my statement. The former refers to customers banging down your door, the latter refers to management concluding that unless we shipped right now, something even worse (than shipping prematurely) is going to happen.
I don't think it's because there is no "customer" to demand timeliness. I just think the people running those projects have a better understanding that users prioritize feature completeness over release dates.
I don't know about your professional experience, but mine typically involves very powerful customers who in turn have deadline commitments to even more powerful customers. In a nutshell, if you slip your schedule, you will surely be blamed for everything else that goes wrong. If you ship something inferior, you might be able to issue a patch later, or you might be able to blame another vendor who screws up even more badly. The temptation is often overwhelming, but yes, this is an unprofessional thing to do.
This is not to say these customers don't want a bug-free and feature-complete product by the deadline. They do, and we know they do. The problem is that they make missing the deadline an even bigger deal.
I felt insulted that you read my comments as an excuse for poor behavior
This is what led me to it:
if I'm writing my own one-man-show app for my employer, knowing nobody else is likely to ever see the code, it'll end up more like a Q&D.
As you know, the longevity of any given piece of code is very difficult to predict. Murphy's Law dictates that it's too often the quick and dirty hacks that haunt forever. What I'm trying to stress is that even the fact (which you can't really be sure of) that nobody will ever see the code should not be a reason to do a sloppy job.
No, not at all. I completely agree that it's human nature. I'm saying it's not an excuse, and it is unprofessional to vary the quality of your work depending on how closely you are examined. Ethical behavior is fundamentally something you ask of yourself.
Many professional developers [...] don't care if anybody or everybody is looking.
Then they should not be paid to do the work. I don't care if it's human nature or not.
Every project out there is developed for somebody regardless of the model used to develop it. Apache, PHP, sendmail, bind, Evolution, ghostscript, gimp, (shall I continue) all have customers.
The general lack of a financial relationship between free software "customers" and their developers permits a different focus for development. While it is true that a project completely oblivious to its customers will doubtlessly fail, free software does get away with more author-driven development.
Releasing software before it's ready just to "make the date" is fucked up. Look at Oracle 11i. Guess the users wanted it, so it must've been the right decision, eh?
Who said it was the right decision? In fact, your example (which I am not familiar with) proves my point that commercial software have various pressures that free software don't. This allows and causes them to optimize in different directions.
Stop blaming your customers for your need to hack in stupid features. Blame management.
Sometimes it's management, sometimes it's customers. The point is that a developing software as a business means you are subject to external influences that may not make good technical sense, and a commercial developer is less able to resist that influence.
You and I both know people tend to cut corners when nobody's looking.
Yes, I know. I'm not sure what I wrote to make you think otherwise. The point is, however, that it shouldn't be. It's unprofessional to do that, and should not be excused by human nature.
I didn't say my house was a fucking wreck when nobody's around. I said it's not immaculate. It's clean and orderly, but not immaculate.
The key question here is whether you are paid to keep your house immaculate. As you pointed out, your CEO emphasizes "make it work" over "document it". That's fine, because he or she is responsible for that business decision. This means that if you run out of time, you will probably fail to document some things. The key point is what your employer is paying for, and whether he or she is getting it.
However, if you have months of free time at the end of a project, and still fail to document your code because nobody is looking, that's human nature, and that's unprofessional. The precise problem here is that you are in fact expected to document the code properly if you had the time, whether or not your boss is going to look over your work.
I would also appreciate if you left your profanities at home, if you are actually interested in discussion. That's another sign of professionalism.
I don't believe that is the reason.
Free (beer) software is more analogous to an engineer-driven company. They use what the engineers think is good development practices, and optimize for a better (fewer bugs, faster, more configurable, etc.) product. The result is in fact a better product, if the company doesn't run out of money before shipping anything. Most other companies do not have this kind of luxury, and must bend over backwards to keep customers happy. Often this means incorporating ill-suited features and fixes, polluting the source code. Just as often, releases are rushed out the door because they're needed, not because they're ready.
Fundamentally, free software isn't even playing the same game as commercial software.
On the flip side, what's the most common criticism of free software? Poor UI. That's of course not inevitable, but a project run by engineers will often emphasize function over "form", which is a common blind spot.
Most proprietary code is only reviewed until the developers have ironed all the bugs necessary to get it to run reliably. Then it's shelved until the support lifecycle requires a fix.
What are you talking about? Every place I've ever worked reviewed code at or about the time you check the code into source control.
Conversly, Open Source projects have a huge interested user base [...]
These are the exceptions, not the rule. Most open source projects don't attract much attention at all, which is exactly the folly of this study.
From what I know, I'm willing to believe that it's possible for the best open source software to surpass the best commercial software in terms of code quality. However, I would not be surprised at all if the average quality of open source software is much lower than the average quality of commercial software. By "average", I'm counting all those projects on Sourceforge, and so should you.
What this means is that open source is not a magic pill that attracts lots of highly qualified developers to help you debug. The code doesn't clean itself up just because you uploaded it to Sourceforge.
To extend the analogy, considering that you're getting paid in part to keep your house clean, you're doing an utterly unprofessional job, and blaming human nature is just ridiculous.
Commercial software are subject to one more constraint than free software: customers. Customers (real or imagined) demand that the software be released at a particular time, ready or not. Customers demand specific features, however poorly that fits into the software's architecture. The need to stay competitive in terms of features (frequently unforeseeable at initial design) also results in hacks that don't quite fit in.
This is the nature of commercial concerns. Most professional developers I know care about the quality of the code they put out, even if only co-workers will ever see the sources. Don't extrapolate your own lack of professionalism to the rest of the industry.
Unless Microsoft does things differently from just about every other commercial software developer, they have a (or a few) developer trunk where new features are added in. At some point before a release, a release branch is created off the main trunk. Modifications to the release branches are tightly controlled, mainly restricted to bug fixes. After a sufficient level of stability has been achieved on the release branch, you designate a "golden master" which is then shipped. The release branch can continue to be used for maintenance releases, or a new branch can be created off it to make maintenance releases.
That's not fundamentally different from the Linux process, as you can see. The frequency of releases and control over the release branches do differ from project to project, but I'll be really surprised if Microsoft does all its work on a single trunk line of code.
The only thing I didnt like was when Microsoft moved away from Windows 95 to Windows 98 and others before fixing all the bugs in Windows 95.
Demand the quality level you require. You're the customer!
Handsets cost a lot of money to develop, and they devalue very very quickly. If you want more variety, that'll probably come at the price of having to pay quite a bit even for older models.
The money is intended for the Pentagon to buy weapons and other products from manufacturers from their home states. I don't see how saving taxpayer money by switching to Linux benefits anybody in Congress.
You're right, but I'm not arguing if "Linux" is a good or unconfusing name for anything, including an operating system kernel. I'm objecting to people calling it an "improper" name, which implies wrongdoing.
Sure, but now it's named after him. That in itself is "unfair" to a number of people who have contributed a lot to the kernel. The point is, things get named frequently as historical accidents. Linus obviously didn't intend to "hog" all the "glory", and Red Hat probably didn't deliberately choose to not credit GNU contributions. Remember Christopher Columbus? Well, the continent got named "America", not "Columbia". Life's like that sometimes.
I'm objecting to the distinction between "proper" and "improper" naming, not disputing that credit should be given where due. Yes, a journalist should do good research before writing; no, it's not "improper" to call it Linux. It's not even "improper" to call it "Red Hat Operating System", for example.
You can argue (on and on) about what is a better name for an operating system composed of the Linux kernel and the GNU user space utilities, but don't dismiss opposing opinions as "improper". When Red Hat put together their distribution, they called it "Red Hat Linux". There's nothing unethical about that, because the GPL does not require any credit. In fact, they could have called it "Red Hat Operating System", and credited no one.
Remember the Linux Router Project guy who was lambasted for wanting credit (and money) for his volunteer work? Same deal. If GNU wanted the "glory", it should've required it as a condition in the GPL.
Note that I'm not saying it isn't arguable, just that there was no impropriety in not crediting GNU.
[Torvalds] has simply claimed credit for the Linux kernel.
Not even that. He said recently, "as the owner of the copyright in the collective of the Linux kernel, I shepherd even more [intellectual properties]", a clear statement that he is not even claiming credit for the entire kernel. Even then, most other important kernel contributors are not credited nearly as much as Linus has been, especially when you consider that the kernel bears his name.
Would you like to rename Linux the kernel as well?
Given the philosophical drive of the GNU Project, I highly doubt this statement. I don't think GNU thought it was such a great idea to run free utilities on top of a closed-source proprietary kernel.
the FSF owns copyright to every line of code in a GNU project (to prevent silly suits such as this one).
Nothing can prevent a lawsuit. Some things help you win one. In any case, somebody who steals code (say, from the company he works for) and contributes it to the GNU project will result in the same actionable contamination.
There are three important factors here:
- Disney doesn't really care if it passes.
They can easily afford the registration fee
and procedure to protect their copyrighted
works.
- Disney would look really stupid if it
opposed even this bill. At the time of the
Sonny Bono Act, Disney was "protecting its
investment" from lapsing into the public
domain, so the question was "how long should
copyright really be?" Today, the question
is "should copyright last over fifty years
with no obligation from the creator to even
register?"
- Disney can use the works that do lapse
into the public domain in its own products,
without having to pay royalties.
If Disney realizes the opportunity to create some good PR for itself (for little or no cost!), then maybe it'll have a chance.I seriously doubt that.
A lot of C programs out there (both commercial and free) contain assumptions on the size of various types like "int" being 32 bits and "short" being 16. Some also assume a certain byte ordering (usually assuming little-endian). Some assume that structures are padded in a particular way (i.e., no padding). Some rely on the order of evaluation on a particular platform. Most of these are mistakes that are quite difficult to catch on a single platform, because the code works "correctly" on that platform. This is a problem common to C and C++ programs, and is not unique to Linux but certainly affects Linux.
Darwin is only a little bit open. You can see the source but there are a lot of licensing restrictions imposed on what you can actually do with it.
What restrictions are you referring to?
Since Linux works very well on my Mac hardware and doesn't impose the limitations of OSX it's what I prefer to run most of the time
Let's discuss the "limitations" you cited, one by one.
- "restrictive licenses" - doesn't affect
daily use, so it shouldn't affect which OS
you run most of the time.
- "can get source code" - likewise irrelevant
to daily use.
- "can reconfigure" - how much time do you
spend reconfiguring as opposed to working?
- "can become involved" - you can volunteer
for Darwin development as well, you know, and
you can likewise write a new OS X app.
So I'm afraid I don't see why you prefer Linux to use "most of the time". The factors you cited are valid, but are not relevant, because the limitations don't affect usage.Correct. The most relevant conclusion one should draw from the Apple benchmarks is that the artificial benchmarks are now officially irrelevant, because the difference is now small enough that what application you run will make all the difference.
I am not a computer guru (by any stretch of the imagination), but don't you all find it pretty lame that Apple needs a 64 bit processor to come close to the speeds of a 32 bit Pentium?
That's entirely irrelevant. For example, some tasks can be more quickly accomplished with a CPU with half the raw clock speed, but twice the cache size. The relevant question is which really is faster (for those with a real need and no budget constraint), and which has a better performance per dollar.
To be more specific, the personal computer started with 8-bit CPUs. Since the numbers we process are frequently larger than 255, moving to 16-bit CPUs alone gave a large performance boost. Similarly, 32-bit CPUs gave a boost to processing larger numbers. However, since 32-bit CPUs can handle numbers up to over 4 billion, the inherent advantage of going to 64-bit is diminished, especially compared to the costs. That is, 32-bit CPUs are really at a sweet spot, and have undergone many many optimizations without going 64-bit.
If you look back in history, the 8-bit Apple ][ came out in 1977. The 16-bit IBM PC followed in just four years. The 32-bit IBM PS/2 followed in just three years, which was 1987. Then, we stayed at 32-bits for the next 16 years. IOW, the P4 you see today is the culmination of 16 years of 32-bit computing, which is not to be scoffed at. As 64-bit computing becomes more prevalent, we will find applications for which 32-bit CPUs really struggle at, but it's quite understandable that for many existing applications 32-bit CPUs are really quite good at their job.
Actually, we should pretend it isn't. We should take the gcc comparison as holy gospel, and buy lots of Macs because of it. This will compel Intel and AMD to start pouring lots of resources into improving gcc's x86 optimizations, which will compel Apple and IBM to do even more for the PowerPC, and so on. All of these optimizations will not only make gcc a kick-ass compiler, it will also make Linux and other free software run faster.
They have been doing that for years, in case you haven't noticed. The question that the public has about the G5 is not how well it runs MacOS X. We take it for granted that it will run MacOS X just fine. The big question is how fast the G5 really is, and this is a question that Apple cannot dodge.
Before the G5, Apple was at serious risk of losing a core group of customers who really do need high end power - people who deal with large graphics images, audio, and video. QuarkXPress taking forever to port to OS X didn't help, and even Pro Tools took a while to get an OS X version running. Apple customers are loyal, yes, but at some point they do have to upgrade. It was increasingly undeniable that the x86 not only had the better price performance ratio (which Mac users generally accept and dismiss in favor of a more pleasant overall experience), it was also much faster. That really does impact the bottom line for these users.
So no, I don't think Apple could've done anything except confront the performance issue head on.
I'm not sure what you are referring to by "compiler architecture". Most compilers are structured in the same way, with a front end that parses source code to generate some form of intermediate code, a back end to generate and optimize assembly code from the intermediate code, and an assembler to actually generate binary code.
Having said that, you are correct that an optimizing compiler is not a distinct product from a high performance CPU. In fact, early RISC chips relied greatly on having good optimizing compilers to help re-order instructions for a lot of its speed.
I don't think anyone needs to be too hasty. In this business environment, many patents are "defensive" in nature. That is, apply for a patent in case your competitor does it first and pulls the rug from right underneath you. It might be instructive to see what NetFlix does with the patent before deciding whether to punish them.
Now, that's not to say the US patent system doesn't need reform, just that there's a difference between a predatory abuse of a bad system, and a self preservative abuse.
You are very, very confused.
You are equating people who need a lot of computing horsepower ("power user") with those who know a lot (or even want to know a lot) about computers. A graphic artist or video editor might drive the high end demand for CPU power, yet not want to deal with many of the intricacies that you would consider commonplace.
have a bit of respect for your other (non-imbecile) customers.
Do they have to design and sell every bit of equipment to have this respect? Exactly what is wrong with just buying another mouse from another vendor? Or are you just worried that the color won't go well together?
There's feature as it appears on a bullet list, and there's feature that's worth using. Apple was not the first to come up with an portable MP3 player, or probably even a hard disk based MP3 player. Yet the iPod is among the best portable MP3 players in the market, if not the best. iTunes was not the first MP3 player and organizer. Final Cut Pro was not the first video editing software. MacOS X is not the first Unix descendant to try to make it on the desktop.
I suggest a little benefit of the doubt for a company that has been playing a brilliant game of catch up for the past couple of years.
There are at least two viable business models in this case.
Like Red Hat, you can sell support. Note that a big famous company selling support for free software can be more attractive to a client than the original author offering paid support.
Like CheapBytes, you can sell convenience. Their costs are low (mainly consisting of downloading Linux distribution ISOs, and making CD masters), and they can't legally prevent people from making copies, yet they're still around.
Either way, the original author will see none of the money.
Don't even expect that. I released a little game that I made as an exercise, and it was downloaded about 1,500 times over two versions. It got 7 comments on Versiontracker, and I got maybe three or four email with kind and appreciated words. I'm not at all bitter about it, because I got what I wanted (a programming exercise in a new platform), but it's important not to expect a lot of expressed gratitude.
It's too bad that this person turned into an object lesson for:
- Release software for free
- ???
- Profit!
but as you said, he had unreasonable expectations. Besides, since his work is based on Linux, it would be interesting to know if he had forwarded a portion of the donations he received to the Linux kernel hackers.No, the GPL attempts to control what the recipient may or may not do with the source code. Specifically, it requires (not requests, requires) that you distribute modified source code if you distribute modified binaries. There is no legal basis (though there is of course an ethical one) for this requirement if not for copyright.
Basically, these "licenses" depend on copyright because it exists, but open source would do very well without them if no other software was copyrighted.
Without copyright, a company can take GPL code, modify it slightly, and actually sell your hard work simply because they can afford marketing. I'm not as sure as you are that the open source community would be just as vibrant.