Sure there is: It's very time consuming to track down components, learn to troubleshoot the hardware, and generally fiddle around until you get it all working. The last time I did this it took me days of web surfing, half a dozen runs to local stores, and about two weeks of total time. I have also ordered a PC from Dell in the past and it was a snap to order and set-up.
I essentially agree with your comment, it's really a matter of a time/money tradeoff. And eventually, there's a point on the curve where the techs can do it cheaper and faster than you can (unless you have a lot of time or no money)
However, there are some good middle of the road options. One is custom clone builders. Another is the bare bones kit. Bare-bones kits are a great way of getting a very cheap machine, and it takes very little time to put them together.
Yes, but the government is punishing one behaviour (purchasing from the retailer) and rewarding the other. This tilts the playing field.
The reason why internet tax was thought up is because tons of people can wait for what they want, so retailers were losing money.
No, the tax was thought up, because it's inconsistent to have items taxed when they're purchased locally but not taxed if they're purchased by mail order.
If the balance between internet and retail store is broken, it would screw over everything.
It already is broken, because one behaviour is taxed, and the other isn't.
If buying over the internet costed more money AND time than retail stores, it would screw over the world.
No it wouldn't. It just wouldn't be very good for the internet stores.
If those people who normally order stuff at home went out to retail stores, traffic would be a mess, gas prices would go up since the demand would be greater, stores would be overcrowded, global warming will happen faster and we'll all die.
Not at all. Obviously, traffic levels, gas prices etc are an obstruction to travelling, and consequently an incentive to buy mail-order.Instead of causing us all to die, the result would be that it would cause us to consider buying mail order, even though the items were taxed.
In fact, no taxation without representation!
I'm a foreign national residing in the US. Are you telling me I shouldn't have to pay any taxes in the US ? And would you argue that someone who produces a NY drivers license shouldn't have to pay sales tax in NJ ?
Don't you love those people who believe that it's their place to tell "the developers" what they "should be doing" ? The way he's ranting about what Linux "should focus on", you'd think he'd just appointed himself as the supreme commander of "the developers".
Basically, he just doesn't get it. Linux is not supposed to have any particular policy or direction. It simply evolves with the needs of the users. Thus far, this appears to be one of the main reasons for its success. The idea that Linux "should focus" on a particular thing is not only completely unrealistic, it also reflects a lack of understanding as to how software on Linux actually gets written.
It's not that simple. Competitive forces are an obstruction to increasing prices. Low sales volume
is an obstruction to reducing prices. It's true that both of these factors interact, but it also appears that a lot of market dominance is necessary to remove pricing obstructions. There are very few software packages that are excessively expensive due to monopoly control.
In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.
WRONG, WRONG, WRONG. Completely false. See the Qt non-commercial license.
I can't believe this crap is marked as "informative".
But I hate the fact that it ain't C++, you need to include "foo.moc" at the bottom of your source.
You don't have to, and probably shouldn't include
it in your source. Better to put the preprocessed
moc files in different translation units, and
compile those seperately.
Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?)
No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more
recently, it has an OO socket implementation,
and XML support (Sax and DOM) You're on to something with your Java comment though -- think
of it as a C++ version of the Java standard
library, if you like.
Fat fucking chance. Trolltech will never admit that their solution is full of shit.
I hear moc trashed quite often, but I've yet to hear
anyone succesfully enumerate the tangible disadvantages of it. Trolltech have been able
to stick to the same design for a long period of
time, maintain binary compatibility over minor
releases, and for the most part source compatiblity over all releases, while continuing to develop, extend and refine their toolkit. This IMO is a sign
of far-sightedness.
Let's face it C++ is a pile of shite and we need something much better to move onto
There are lots of other things to move onto, and
many of them are very well thought out (Eiffel,
for example). However, C++ still stands up pretty
well against the competition IMHO.
While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.
The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
sure that KDE has been as stable, though this
should improve. (The move to DCOP resulted in growing pains)
To get some appreciation of how fragile binary compatibliity is, read this. Binary compatibility is fundamentally
difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
changes in interface or exposed structure
(that means anything besides opaque pointers) will break binary compatibility.
Personally, I think the fundamentals need to be
nailed down. C++ and C libraries need to preserve
binary compatiblity. On the other hand, I don't
think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)
if your widget set gets a re-write, why should you have to recode your entire GUI?
One hopes not. Trolltech have done a good job of maintaining source compatibility. Binary
compatibility however is a much more fragile thing, especially in C++. It is broken by many things, some smaller than changing the interface. I recommend this link
here
as a good explanation of binary compatibility issues.
AKAIK it's C++ and there hasn't been a standard ABI until GCC 3.0.
That's also partly true. There hasn't been a stable ABI, so the dependency on the standard library (libstdc++ 2.7/8/9) has resulted in more relinking than changes in Qt.
The new ABI for g++ is not standard, but
it's supposed to be well a defined ABI that is
reconcilable with the standard.
I'd read up on what chips are more overclockable (the Celeron is probably a good candidate). If the chip has a lot of headroom for over-clocking, it probably also has a low heat output.
You could always do something radical and underclock, and that would reduce heat output.
However, how many motherboards have 64bit PCI slots?
The Tyan THunder dual AMD motherboard has 64 bit slots. IIRC, the cheaper Tyan Tiger also does.
64 bit slots are fairly common in dual-capable
motherboards.
> Yes, but will they work with Linux? Promise has "issues" under Linux.
There's a kernel module for them, so the short
answer is "yes". A slightly longer answer -- I
was getting some corruption problems with the 3ware (kernel 2.4.5), and it appears several others also reported problem. They updated the driver. I'm using 2.4.10 now, and it seems to be working.
In summary, they do work with Linux, there have been issues, and it's an open question (at least as far as I'm concerned) whether the issues have been fully addressed.
Full striping plus Parity-Checking is RAID 5 but (someone correct me if I'm wrong) this isn't available for inexpensive ATA disk arrays.
The 3ware cards support RAID5. I'd think twice about betting the farm on IDE RAID, but it is supported.
In this, they're just following what was learned long ago on mainframes:
A problem here is that what we know about mainframes could well be wrong for desktop systems. Many services (eg http, nntp, email) are
IO intensive, while many desktop uses (eg compiling software, gaming) are CPU intensive.
I'm using these at the moment, but we had all sorts of corruption problems on Linux (with 2.4.5). I've upgraded to 2.4.10 and it seems to be working. I'd still recommend the 3ware as a cheap
storage solution, but I don't have much confidence
about it providing the "protection of RAID".
With an IDE RAID card, like 3ware's Escalade controllers. Great if you need a lot of storage,
and want something that performs better than
software RAID (which is *terrible* on 4 IDE disks)
but cheaper than SCSI.
SCSI is expensive. "Worth it" is a very subjective term, it really comes down to a question as to
whether or not you have the money to spend. If you're on a tight budget, SCSI is probably out.
IOW, I think budget requirements dictate whether
or not it's worth getting SCSI. Given a $1000-
budget, SCSI is almost certainly out. Given a $2500 budget, SCSI becomes a good option. It would
be interesting to see machines configured for different price targets (eg like Sharky Extremes guides, only
for a Linux machine)
Slashdot Mirror
That's not legal C++ (though g++ will compile it unless you use -pedantic)
I essentially agree with your comment, it's really a matter of a time/money tradeoff. And eventually, there's a point on the curve where the techs can do it cheaper and faster than you can (unless you have a lot of time or no money)
However, there are some good middle of the road options. One is custom clone builders. Another is the bare bones kit. Bare-bones kits are a great way of getting a very cheap machine, and it takes very little time to put them together.
Yes, but the government is punishing one behaviour (purchasing from the retailer) and rewarding the other. This tilts the playing field.
The reason why internet tax was thought up is because tons of people can wait for what they want, so retailers were losing money.
No, the tax was thought up, because it's inconsistent to have items taxed when they're purchased locally but not taxed if they're purchased by mail order.
If the balance between internet and retail store is broken, it would screw over everything.
It already is broken, because one behaviour is taxed, and the other isn't.
If buying over the internet costed more money AND time than retail stores, it would screw over the world.
No it wouldn't. It just wouldn't be very good for the internet stores.
If those people who normally order stuff at home went out to retail stores, traffic would be a mess, gas prices would go up since the demand would be greater, stores would be overcrowded, global warming will happen faster and we'll all die.
Not at all. Obviously, traffic levels, gas prices etc are an obstruction to travelling, and consequently an incentive to buy mail-order.Instead of causing us all to die, the result would be that it would cause us to consider buying mail order, even though the items were taxed.
In fact, no taxation without representation!
I'm a foreign national residing in the US. Are you telling me I shouldn't have to pay any taxes in the US ? And would you argue that someone who produces a NY drivers license shouldn't have to pay sales tax in NJ ?
Basically, he just doesn't get it. Linux is not supposed to have any particular policy or direction. It simply evolves with the needs of the users. Thus far, this appears to be one of the main reasons for its success. The idea that Linux "should focus" on a particular thing is not only completely unrealistic, it also reflects a lack of understanding as to how software on Linux actually gets written.
I'd like to propose a moratorium on the following:
of a question mark
Do you have a cite to support this claim ? It seems questionable at best.
WRONG, WRONG, WRONG. Completely false. See the Qt non-commercial license. I can't believe this crap is marked as "informative".
Cheers,
You don't have to, and probably shouldn't include
it in your source. Better to put the preprocessed
moc files in different translation units, and
compile those seperately.
No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more recently, it has an OO socket implementation, and XML support (Sax and DOM) You're on to something with your Java comment though -- think of it as a C++ version of the Java standard library, if you like.
I hear moc trashed quite often, but I've yet to hear anyone succesfully enumerate the tangible disadvantages of it. Trolltech have been able to stick to the same design for a long period of time, maintain binary compatibility over minor releases, and for the most part source compatiblity over all releases, while continuing to develop, extend and refine their toolkit. This IMO is a sign of far-sightedness.
I think the lack of good compilers had a lot to
do with the approach, at the time. This also
had a lot to do with them re-inventing STL.
I notice Qt is not on the list of GPL software on
fsf.org. Oversight perhaps ?
There are lots of other things to move onto, and
many of them are very well thought out (Eiffel,
for example). However, C++ still stands up pretty
well against the competition IMHO.
The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
sure that KDE has been as stable, though this
should improve. (The move to DCOP resulted in growing pains)
To get some appreciation of how fragile binary compatibliity is, read this. Binary compatibility is fundamentally
difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
changes in interface or exposed structure
(that means anything besides opaque pointers) will break binary compatibility.
Personally, I think the fundamentals need to be
nailed down. C++ and C libraries need to preserve
binary compatiblity. On the other hand, I don't
think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)
One hopes not. Trolltech have done a good job of maintaining source compatibility. Binary compatibility however is a much more fragile thing, especially in C++. It is broken by many things, some smaller than changing the interface. I recommend this link here as a good explanation of binary compatibility issues.
That's also partly true. There hasn't been a stable ABI, so the dependency on the standard library (libstdc++ 2.7/8/9) has resulted in more relinking than changes in Qt. The new ABI for g++ is not standard, but it's supposed to be well a defined ABI that is reconcilable with the standard.
You could always do something radical and underclock, and that would reduce heat output.
The Tyan THunder dual AMD motherboard has 64 bit slots. IIRC, the cheaper Tyan Tiger also does.
64 bit slots are fairly common in dual-capable
motherboards.
There's a kernel module for them, so the short
answer is "yes". A slightly longer answer -- I
was getting some corruption problems with the 3ware (kernel 2.4.5), and it appears several others also reported problem. They updated the driver. I'm using 2.4.10 now, and it seems to be working.
In summary, they do work with Linux, there have been issues, and it's an open question (at least as far as I'm concerned) whether the issues have been fully addressed.
The 3ware cards support RAID5. I'd think twice about betting the farm on IDE RAID, but it is supported.
In this, they're just following what was learned long ago on mainframes:
A problem here is that what we know about mainframes could well be wrong for desktop systems. Many services (eg http, nntp, email) are
IO intensive, while many desktop uses (eg compiling software, gaming) are CPU intensive.
I'm using these at the moment, but we had all sorts of corruption problems on Linux (with 2.4.5). I've upgraded to 2.4.10 and it seems to be working. I'd still recommend the 3ware as a cheap storage solution, but I don't have much confidence about it providing the "protection of RAID".
With an IDE RAID card, like 3ware's Escalade controllers. Great if you need a lot of storage, and want something that performs better than software RAID (which is *terrible* on 4 IDE disks) but cheaper than SCSI.
SCSI is expensive. "Worth it" is a very subjective term, it really comes down to a question as to
whether or not you have the money to spend. If you're on a tight budget, SCSI is probably out.
IOW, I think budget requirements dictate whether
or not it's worth getting SCSI. Given a $1000-
budget, SCSI is almost certainly out. Given a $2500 budget, SCSI becomes a good option. It would
be interesting to see machines configured for different price targets (eg like Sharky Extremes guides, only
for a Linux machine)