You have to use a signed int because you can do seeks with a negative offset. So you're limited to a 2 GB seek space, and virtually everyone uses the same type for the seek offset as they do for storing the actual pointer into the file.
A few vendors do it differently, but you get a performance hit for it. And, frankly, it's just not worth it - if a 2 GB file isn't big enough, a 4 GB one isn't likely to be either. Go for 48-bit or 64-bit and you're much better off. Most vendors go 64-bit for simplicity and future expandability.
The 2038 "crisis" isn't magically solved by 64-bit CPUs.
Until every vendor changes the #define of time_t from a 32-bit int (usually "int" or "long") to a 64-bit int (int64_t) it will still be there.
And a 32-bit CPU can handle a 64-bit int just fine... it just takes longer to process. Most systems offer 64-bit file systems on 32-bit CPUs right now, because a 2 GB file size limit is really, really inadequate.
2 GB is the usual max because you use a signed integer. You can specify negative offset values afterall.
And MS didn't put in the 36-bit addressing, Intel did. But utilizing the extended address mode is a significant performance hit, plus it's annoying to utilize. Which is why virtually nobody actually uses it.
So, in other words, right now a 64 bit CPU is not needed for this. Why did you list it?
Uh... sure it is. Right now you can't easily address a file >2 GB on a 32-bit CPU. Doing so requires a file pointer larger than 32 bits in size (most vendors go to a 64-bit unsigned int, but implementations do vary) and that causes a pretty dramatic slow down on a 32-bit CPU. A 2 GB DB may have been large once upon a time, but it's trivial nowadays. Medium sized databases are in the hundreds of gigs, large in the terabyte range, and some of the biggest are pushing a petabyte.
Moving a database (or any other large file I/O heavy operation) to a 64-bit CPU can dramatically improve performance for this reason alone.
I believe the original poster said common applications
I believe watching a DVD on a PC is becoming increasingly common. HDTV on PCs isn't too uncommon, and HDTV dumps make DVDs look puny - even when compressed. Video editing is becoming more common as well, which utilizes both large files and can take advantage of the larger operations on a 64-bit CPU.
probably done on a unix system with a 64 bit cpu already
Yes, as are all of the applications... and it only costs 100x as much for a slower CPU. The point is that x86-64 will bring 64-bit computing to an entirely new price point - you'll be able to build a fast 64-bit PC for less than the price of a single 64-bit chip from Sun, IBM, Intel, or HP. That's pretty significant.
Honestly, there isn't much need for a 64-bit desktop CPU. But there isn't much need for a 2 GHz desktop CPU either. For those that can take advantage of the higher bit width, or speed, or both, the improvements are indeed massive.
Re:Excellent move
on
Corporate KDE
·
· Score: 2, Insightful
windows 2000 is very stable
This I'll agree with... I haven't had any problems with Win2k at my current job.
very manageable from the administration end
Shrug... I'm not an admin, but if you can administer the entire desktop from a remote location it's certainly not apparant to our admins. Otherwise they wouldn't have to login to our PCs to install new software. Frankly, however, most of the TCO studies show Unix requiring fewer admins for a given number of machines, and Unix was built from the ground up for remote administration.
Plus active directory is something we use so that people from all over the country can go to any other facility, log in, and have everything work just as it did at their desk
Wow. Nice to see that Microsoft got that done... twenty years late.
I don't think Linux is ready for the desktop (home or corporate) yet myself (although I'd like it on mine... sigh), but not for the reasons given. Application availability and usability are bigger issues still. The latter is improving steadily, and the former is highly dependant on what you need.
That's very nice. But know what? AMD really couldn't care less about you and your one system.
Release dates are very important to businesses, however, and anyone that is planning to make a large purchase of high-end workstations or servers (although servers are more interested in Opteron) is interested in release dates. As are system integrators and OEMs (who usually have better, albeit unofficial, info anyway, as well as access to samples if they're large enough).
There's quite a few companies that are waiting for a low priced 64-bit chip to be released. Generally these companies are using high-priced Sun/HP/IBM/whatever systems that either use their own CPU or a Itanium. The cost savings to move from one of these platforms to an Opteron or Athlon64 would be substantial, presuming you don't also need the higher I/O provided by such a system.
But, really, AMD doesn't care about your single system. Honestly.
IBM's Visual Age for C++ compiler was a pain in the ass to figure out
It's even more of a PITA to actually use.
We've just spent the last couple days getting gcc 3.2.1 to compile properly (on AIX 4.3.3), as well as some random support libraries. We're still in the testing stages, but we're really hoping we can move from xlC to g++ -- because wow does xlC suck for development. dbx is utterly useless for debugging, since it gets "lost" and can't display the code while debugging, and often can't even set breakpoints because of being lost (debugging a 2000 line cpp, and it claims there's no executable code on line 1532 of xstring.cpp -- well, yah... but I'm not in xstring.cpp). The linker really, really sucks as well, and compile performance has been so miserable that we were forced to move to shared libraries. Which are a pain to setup and maintain. Optimization? Forget it -- the one time we tried we cancelled the build after 10 hours (it only takes 30 mins to build a fresh tree w/o optimization).
Oh, and forget using libraries like boost or Loki - xlC's STL isn't up to the task and won't compile most of them.
So we're really hoping to move to gcc right now... currently compiling is slower, but we get binaries that can actually be debugged if we need to. The resulting files are smaller, but we haven't done any performance testing to see the speed impact. We're hoping to utilize more of boost and/or Loki in the future, as well as other large libraries if needed.
Oh, and most of the issues related to xlC/ld appear to be template related - we're heavy on STL and our own templated functions.
Frankly, we're hoping to move to Linux boxes in the long run. Excepting the database server, there's nothing we need the big iron for, and we'd gain more from a bunch of small, fast x86 boxes. Our system is designed to be very modular, so it'd work well even if not every process is on the same box.
I'm not sure that one is worth porting to Linux. It sounds like more of an issue if you are using binaries.
Welcome to the real world, where you may not have source to everything. If you have legacy applications being able to run them when you upgrade your machine is very important.
I believe Linux on x86-64 will do this just fine though, so it's a non-issue.
Ignoring the minor fact that the video output from a GF2 (and, frankly, all nVidia cards) sucks, the poster was pretty obviously wanting to put a high-end game-capable video card in his HTPC in order to play the latest and greatest PC games on a big screen.
A GF2 really won't cut it -- you can run UT2k3 on it with all the eye candy off, but even then it's marginal (yes, I know -- I ran UT2k3 like this for 2-3 months on a GF2). It simply won't have the horsepower to handle D3 in any reasonable capacity.
Yes, but realize that "made available" is not a free thing... it costs money to get it. It costs more money to not get it though...
SOME US based telemarketers will do what they're supposed to and leave the people on the list alone
More like most.
Others (I know one personally) will laugh and hand the list over to their call center as a list of verified numbers. If someone goes after them, they will weasel out of the lawsuit via claims of clerical errors
And most judges will let him know that it would behoove him to not have clerical errors in the future, and here's a fine for $500 per incident as incentive. Next case.
Frankly, your acquaintence is an idiot and a moron. He's using telephone numbers of people who have explicitly said "I won't buy from you" as "verified numbers"? That's called wasting money - and it's his own money, not his client's money, because he can't charge significantly more for telemarketing services than his competitors. Filtering out DNC numbers is a quick, computer-driven task. Having people call the number and be told off is a slow, expensive task.
Sure, you won't get as many calls from US telemarketers, but you'll get a boatload from Indian Telemarketers who laugh at phrase "Put me on your do not call list" reply
Uh huh... because running a call center using international phone rates is so much cheaper than using state-to-state rates... Sure, you save on labor costs, but you're still going to get nailed by the "calling people who will never, ever buy your product" bit.
Frankly, let the scum of the scum do this crap. They'll be weeded out by market forces alone.
They'll probably install into one of many alternate directories. Hell, if I was evil and wrote crap like this I'd use a randomly generated name.
As a last resort, I could make a stupid script that would nuke the directory on system startup. Let's see them get around that.
Trivial. All you do is load the necessary files early on (which is done by Windows itself since this is a plugin for IE, which is part of the OS) and now you can't delete the files because they're in use.
This is good news in a nebulous sense, but what about actually getting 3rd party adoption? How many players out there support FLAC? Or even Ogg Vorbis?
I've been contemplating a digital audio player like the Turtle Beach AudioTron for awhile now, and while the AT has better support for a variety of formats than most, it's missing both FLAC and OGG (and the developers have stated it's not coming due to lack of CPU power).
I'd love to encode all my CDs onto a central server and have several units around the house playing from that. But I'd rather not rip around 1000 CDs more than once. And it's still not cost effective to just store them as WAVs - using FLAC would double the capacity.
Yeah, I know... Samba can translate files on the fly now, but that requires a good bit of horsepower. The Celeron 300A in the server just isn't going to be capable of transcoding FLAC->anything in real time, much less do it for 2 or 3 streams at once.
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support? Is it technical, financial, or what? And what can Xiph do to help them in this?
And the only way that'll happen is if someone gives Linux support
You mean, kinda like how id Software does? Or maybe Epic (Unreal, Unreal Tournament)?
The reality is that there are some companies supporting Linux - id Software is probably the best as far as it goes - but it's not making money. For id it's not a huge deal, since they've specifically chosen a portable development structure, but for most companies it's a huge ordeal to not use DirectX, or to port from DirectX to anything else. And sales (and usage) figures aren't indicating that it's worth the money to do so.
Depends on just how much hacking you're willing to do, but it's a pretty safe assumption that most sane people wouldn't be willing to draw new traces...
a Dual G4 1.42GHz is roughly equal to a single P4 4.26GHz
No it's not. SMP does not give you 2x the horsepower. If you get 80-90% of the horsepower you're doing well... and even then you only get the horses if you're actually doing something that take advantage of SMP. Which most users don't. Ever.
Frankly, most of the time your CPU is sitting idle waiting on you to do something. Or waiting on the I/O bus if you are doing something. SMP doesn't mystically solve this problem... usually it just makes it worse.
Are there applications for SMP? Sure. No question. But even most geeks who lust after SMP won't ever actually utilize it to the fullest.
currently the fastest P4 is 3.06GHz
Yes, and it can simulate two CPUs in one, which according to your SMP math makes it 6.12 GHz. Of course, even in the latest linux development kernels nobody's seeing a speed improvement of more than 30-40% in optimal conditions. In most scenarios it adds nothing, or actually slows things down due to I/O contention (which, admittedly, is more severe in a hyperthreading situation than a true SMP one).
Frankly, for the price of the Dual G4 1.42 GHz I can buy more than 2 P4 3.06 GHz boxes, which is a much better solution for most cases.
Well over a thousand titles have been released for the Game Boy Color and Game Boy Advance platforms
Oh, hey, lets talk about MAME and stuff too! Think about the thousands of games available that way!
Talk about irrelevant.
First off, most people don't want to play GB/GBA games on the PC. They want to be able to go down to the store, buy some game released for the PC, and install it. Period.
Linux fails on this... even when you use Transgaming and whatnot. Until that changes, it will continue to fail on this.
Alternately, games could start coming with Linux binaries and auto-installers, but that's even more far fetched... the market is too small. To get this you'd have to solve the first problem, and then demonstrate some significant advantage of spending development time on Linux binaries over running it via Wine/WineX/whatever.
Then why does the least expensive edition of Windows XP support only one processor per machine
Maybe because home users would not benefit in the slightest from a dual CPU setup? Or most power users either? And, look, use XP Pro and you suddenly have multiple CPU capability. How is this something Windows can't do?
And why does the Windows kernel limit the number of simultaneous open incoming TCP connections to a ridiculously low level unless you're running Advanced Server?
Because you're not running a server? Uh... this is part of MS's licensing scheme. You can complain about that, but you can't say it's "something Windows can't do".
And why do the headers to write a file system module cost $1000 [microsoft.com] to license, putting it far out of the CS student/hobbyist price range
Because MS has no interest in that market would be my guess. Stupid of them, but that's their choice. How does this make it impossible to write alternate FS's though? Difficult, yes. Undoable? No.
BTW, I wouldn't agree with the parent poster that "anything you want to do can be done with a Windows PC", but I would agree that for what most people want to do on a computer, it's a lot easier to do under Windows (or a Mac - dependant on what you're looking for really). Linux as a desktop OS still requires far more Unix knowledge than most people want to deal with.
All the GeForce FX does it improve effects using the DirectX 8 dynamic pipeline improvements
Huh?
It's a DX9 compliant part... it can do quite a bit using DX9 that DX8 can't. The same is true for the ATI 9700.
No, there aren't any DX9 games available yet. And there weren't and DX8 games out when the GF3 was released. But if you're buying with an eye toward the future then you'd be smart to buy a DX9 compliant card, whether it's the ATI 9700 or GFFx. That or buy a $100 GF4 Ti4200 now and the 9700/Fx a year or so from now for $150ish.
I'll agree with you on the cooling issues, and it's pretty clear that nVidia blew it on this one. The ATI 9700 is a better card, cheaper, and has been out longer. The drivers don't seem to be an issue right now (although they may be in a year or two... ATI has a pretty crappy track record on extended support). The new revision of the ATI chip should be out in a month or two as well, and they've claimed 20-30% higher performance than the 9700... which really hurts nVidia.
BTW, there are Fx drivers in the nVidia module (see Appendix A of the README - NV30 is listed). They're probably not completely tuned, but neither are the Windows drivers. Based on past history, you can expect significant driver improvements in 3-6 months.
Video cards have had 2D acceleration for the past 10 years, and it makes a huge difference. Letting the card do simple operations like BitBlt, line draws, etc. instead of the CPU doing all the work and then pushing it off to the DAC offloads a ton of work. You clearly do not remember when text scrolling in a window was orders of magnitude slower than scrolling it full screen. I do. I also remember the first card that reversed this for me - a Number9 Imagine128 that I won at Comdex. This was back when 3D acceleration meant an Onyx with RealityEngine for $500k+.
2D performance is rarely an issue nowadays. If it is, then you're either doing something unusual in 2D or you're using amazingly crappy drivers.
In my previous job we regularly processed credit data files >2 GB. All the data is processed serially (as someone else mentioned), so seek time is not an issue (nor is it an issue in a binary data file - seek to 1.4GB. Done. Next.).
The real issue we ran up against was compression... we wanted to have the original and interm data files available on-disk for awhile in case of reprocessing. The processing would generally take up 10x as much space as the original data file, so you compressed everything. Except that gzip can't handle files >2GB (at the time an alpha could, but we didn't want to touch it). Nor can zip. So we had to use compress. Yay. (bzip could handle it, but was decided against by the powers that be).
Compression of large files is still an issue, unless you want to split them up. Unless you download a beta version gzip still can't handle it. As I understand it zip won't ever be able to do it. There are some fringe compressors that can handle large files, but, well, they're fringe.
Yes, because while your GPU may very well handle the rendering, your CPU still has to render most of the geometry itself as well. You have to handle physics, collisions, etc.
BTW, UT2k3 was playable on an Athlon 750... quite a step down from a 2 GHz CPU.
Yeah, because I'm sure MOO3 will have a 3D immersive environment utilizing the latest rendering features of your video card...
Oh... hold it... you mean there's no 3D graphics at all? Well, heck, why does it require a 300 MHz P3 then? You can do pretty much anything needed in 2D with a 486. Must be pretty damn inefficient code.
Hint - comparing games of totally, utterly different genres and then whining about one giving "more bang per cycle" is so abundantly stupid it's sad.
ALWAYS use a credit card. It's your only protection
Be aware, however, that if you buy goods from a foreign country (overseas or not) all sales are final. Federal law does not apply and your credit card company won't help you -- frankly, if they refunded you the money they would be out the cash because there's no way for them to reclaim it. (I note that Microsono is incorporated in Delaware and located in California, so it shouldn't be an issue in this case).
And to the sibling poster - return receipt requested is an additional service on top of certified mail, which is what you were suggesting in the first place.
Excellent advice though. Hopefully richardbondi will follow it.
Helium doesn't cancel gravity, it just happens to have a low density
The one true bit in your post.
BTW, there aren't "many" Helium containing compounds. At least not as compared to other elements, or even other noble gases. There are no currently known stable compounds of Helium.
Second, I would assume the "Gi" was a typo
Or would you assume the "Hi" later was actually HI? And he actually did mean Germanium the first time?
clearly meant "HeGI", which is Helium Gallium Iridide and is widely used in chip manufacture
I is Iodine. And before any compound can be widely used it has to exist in the first place.
Not that it matters, you are a known trollbuster and should be modded down
It's always funny seeing a troll whining about a troll buster. Your standard MO is no different from the original poster's.
And yes, you may now be happy that you got some attention. Your life as a troll has been fulfilled for today.
Frankly, I'm bored and it's rather fun debunking your posts. They're at least somewhat better than Jack Wagner's.
Also how enforcable is a patent that hasn't been enforced for a long time
100% enforceable. It doesn't matter if you bring the violation up on the last day of the patent and it's been infringed for the previous 16 years and 364 days. A patent does not require active enforcement to protect it, unlike trademarks. Copyright is a bit murkier - generally all you can do is force them to not continue infringing (but the copyright is still in force).
There are exceptions -- if you enter into an agreement that requires you to disclose all relevant patents that are applicable to a standard being developed and fail to do so then your patent can be rendered unenforceable. This happened to Dell a few years back, and RAMBUS more recently (not sure if that one has been played out entirely yet).
That's not really the issue... the issue is that they are (allegedly) engaging in the scummy business of submarine patents.
Get a patent on a business model/method... don't act on that patent until it's widely used in the industry. Then have your lawyers pop out and sue everyone.
Exactly what choice is provided here? Most vendors wouldn't have even known about the patent, since people in the industry would assume that it's common practice and unpatented (for a variety of reasons).
At that point you can either cease use of the patented technology (which may still leave you open to licensing fees for prior sales, depending on how a judge rules - you're not supposed to be liable, but lawyers can make IP law dance a jig), pay the extortion money, or attempt to get the patent invalidated. Good luck on the latter - if they're doing it toward the end of the patent life then you'll have a hard time getting facts for prior work 15 years ago, and you'll probably wind up paying more in lawyer fees than you would have paid in extortion.
And yes, I do mean extortion. Submarine patents are nothing but that. It's one thing to raise a patent claim when you didn't know it was being violated. It's another thing to intentionally lie low until it's too late. IP law rarely acknowledges the difference with regards to this though.
Of course, there is one other option, and probably one that we'll see used if SCO is stupid enough to press their case. If someone tries to blackmail you, there's always the possibility of blackmailing them back. IBM has enough software patents to make SCO (or anyone else) wonder if they actually invented anything themselves.
Slashdot Mirror
You have to use a signed int because you can do seeks with a negative offset. So you're limited to a 2 GB seek space, and virtually everyone uses the same type for the seek offset as they do for storing the actual pointer into the file.
A few vendors do it differently, but you get a performance hit for it. And, frankly, it's just not worth it - if a 2 GB file isn't big enough, a 4 GB one isn't likely to be either. Go for 48-bit or 64-bit and you're much better off. Most vendors go 64-bit for simplicity and future expandability.
The 2038 "crisis" isn't magically solved by 64-bit CPUs.
Until every vendor changes the #define of time_t from a 32-bit int (usually "int" or "long") to a 64-bit int (int64_t) it will still be there.
And a 32-bit CPU can handle a 64-bit int just fine... it just takes longer to process. Most systems offer 64-bit file systems on 32-bit CPUs right now, because a 2 GB file size limit is really, really inadequate.
2 GB is the usual max because you use a signed integer. You can specify negative offset values afterall.
And MS didn't put in the 36-bit addressing, Intel did. But utilizing the extended address mode is a significant performance hit, plus it's annoying to utilize. Which is why virtually nobody actually uses it.
So, in other words, right now a 64 bit CPU is not needed for this. Why did you list it?
Uh... sure it is. Right now you can't easily address a file >2 GB on a 32-bit CPU. Doing so requires a file pointer larger than 32 bits in size (most vendors go to a 64-bit unsigned int, but implementations do vary) and that causes a pretty dramatic slow down on a 32-bit CPU. A 2 GB DB may have been large once upon a time, but it's trivial nowadays. Medium sized databases are in the hundreds of gigs, large in the terabyte range, and some of the biggest are pushing a petabyte.
Moving a database (or any other large file I/O heavy operation) to a 64-bit CPU can dramatically improve performance for this reason alone.
I believe the original poster said common applications
I believe watching a DVD on a PC is becoming increasingly common. HDTV on PCs isn't too uncommon, and HDTV dumps make DVDs look puny - even when compressed. Video editing is becoming more common as well, which utilizes both large files and can take advantage of the larger operations on a 64-bit CPU.
probably done on a unix system with a 64 bit cpu already
Yes, as are all of the applications... and it only costs 100x as much for a slower CPU. The point is that x86-64 will bring 64-bit computing to an entirely new price point - you'll be able to build a fast 64-bit PC for less than the price of a single 64-bit chip from Sun, IBM, Intel, or HP. That's pretty significant.
Honestly, there isn't much need for a 64-bit desktop CPU. But there isn't much need for a 2 GHz desktop CPU either. For those that can take advantage of the higher bit width, or speed, or both, the improvements are indeed massive.
windows 2000 is very stable
This I'll agree with... I haven't had any problems with Win2k at my current job.
very manageable from the administration end
Shrug... I'm not an admin, but if you can administer the entire desktop from a remote location it's certainly not apparant to our admins. Otherwise they wouldn't have to login to our PCs to install new software. Frankly, however, most of the TCO studies show Unix requiring fewer admins for a given number of machines, and Unix was built from the ground up for remote administration.
Plus active directory is something we use so that people from all over the country can go to any other facility, log in, and have everything work just as it did at their desk
Wow. Nice to see that Microsoft got that done... twenty years late.
I don't think Linux is ready for the desktop (home or corporate) yet myself (although I'd like it on mine... sigh), but not for the reasons given. Application availability and usability are bigger issues still. The latter is improving steadily, and the former is highly dependant on what you need.
That's very nice. But know what? AMD really couldn't care less about you and your one system.
Release dates are very important to businesses, however, and anyone that is planning to make a large purchase of high-end workstations or servers (although servers are more interested in Opteron) is interested in release dates. As are system integrators and OEMs (who usually have better, albeit unofficial, info anyway, as well as access to samples if they're large enough).
There's quite a few companies that are waiting for a low priced 64-bit chip to be released. Generally these companies are using high-priced Sun/HP/IBM/whatever systems that either use their own CPU or a Itanium. The cost savings to move from one of these platforms to an Opteron or Athlon64 would be substantial, presuming you don't also need the higher I/O provided by such a system.
But, really, AMD doesn't care about your single system. Honestly.
IBM's Visual Age for C++ compiler was a pain in the ass to figure out
It's even more of a PITA to actually use.
We've just spent the last couple days getting gcc 3.2.1 to compile properly (on AIX 4.3.3), as well as some random support libraries. We're still in the testing stages, but we're really hoping we can move from xlC to g++ -- because wow does xlC suck for development. dbx is utterly useless for debugging, since it gets "lost" and can't display the code while debugging, and often can't even set breakpoints because of being lost (debugging a 2000 line cpp, and it claims there's no executable code on line 1532 of xstring.cpp -- well, yah... but I'm not in xstring.cpp). The linker really, really sucks as well, and compile performance has been so miserable that we were forced to move to shared libraries. Which are a pain to setup and maintain. Optimization? Forget it -- the one time we tried we cancelled the build after 10 hours (it only takes 30 mins to build a fresh tree w/o optimization).
Oh, and forget using libraries like boost or Loki - xlC's STL isn't up to the task and won't compile most of them.
So we're really hoping to move to gcc right now... currently compiling is slower, but we get binaries that can actually be debugged if we need to. The resulting files are smaller, but we haven't done any performance testing to see the speed impact. We're hoping to utilize more of boost and/or Loki in the future, as well as other large libraries if needed.
Oh, and most of the issues related to xlC/ld appear to be template related - we're heavy on STL and our own templated functions.
Frankly, we're hoping to move to Linux boxes in the long run. Excepting the database server, there's nothing we need the big iron for, and we'd gain more from a bunch of small, fast x86 boxes. Our system is designed to be very modular, so it'd work well even if not every process is on the same box.
I'm not sure that one is worth porting to Linux. It sounds like more of an issue if you are using binaries.
Welcome to the real world, where you may not have source to everything. If you have legacy applications being able to run them when you upgrade your machine is very important.
I believe Linux on x86-64 will do this just fine though, so it's a non-issue.
Ignoring the minor fact that the video output from a GF2 (and, frankly, all nVidia cards) sucks, the poster was pretty obviously wanting to put a high-end game-capable video card in his HTPC in order to play the latest and greatest PC games on a big screen.
A GF2 really won't cut it -- you can run UT2k3 on it with all the eye candy off, but even then it's marginal (yes, I know -- I ran UT2k3 like this for 2-3 months on a GF2). It simply won't have the horsepower to handle D3 in any reasonable capacity.
List will be made available
Yes, but realize that "made available" is not a free thing... it costs money to get it. It costs more money to not get it though...
SOME US based telemarketers will do what they're supposed to and leave the people on the list alone
More like most.
Others (I know one personally) will laugh and hand the list over to their call center as a list of verified numbers. If someone goes after them, they will weasel out of the lawsuit via claims of clerical errors
And most judges will let him know that it would behoove him to not have clerical errors in the future, and here's a fine for $500 per incident as incentive. Next case.
Frankly, your acquaintence is an idiot and a moron. He's using telephone numbers of people who have explicitly said "I won't buy from you" as "verified numbers"? That's called wasting money - and it's his own money, not his client's money, because he can't charge significantly more for telemarketing services than his competitors. Filtering out DNC numbers is a quick, computer-driven task. Having people call the number and be told off is a slow, expensive task.
Sure, you won't get as many calls from US telemarketers, but you'll get a boatload from Indian Telemarketers who laugh at phrase "Put me on your do not call list" reply
Uh huh... because running a call center using international phone rates is so much cheaper than using state-to-state rates... Sure, you save on labor costs, but you're still going to get nailed by the "calling people who will never, ever buy your product" bit.
Frankly, let the scum of the scum do this crap. They'll be weeded out by market forces alone.
They'll probably install into one of many alternate directories. Hell, if I was evil and wrote crap like this I'd use a randomly generated name.
As a last resort, I could make a stupid script that would nuke the directory on system startup. Let's see them get around that.
Trivial. All you do is load the necessary files early on (which is done by Windows itself since this is a plugin for IE, which is part of the OS) and now you can't delete the files because they're in use.
And, lookee... I even said that I know Samba can do transcoding, but it requires more CPU power than my server has.
The AT cannot play FLAC files natively.
This is good news in a nebulous sense, but what about actually getting 3rd party adoption? How many players out there support FLAC? Or even Ogg Vorbis?
I've been contemplating a digital audio player like the Turtle Beach AudioTron for awhile now, and while the AT has better support for a variety of formats than most, it's missing both FLAC and OGG (and the developers have stated it's not coming due to lack of CPU power).
I'd love to encode all my CDs onto a central server and have several units around the house playing from that. But I'd rather not rip around 1000 CDs more than once. And it's still not cost effective to just store them as WAVs - using FLAC would double the capacity.
Yeah, I know... Samba can translate files on the fly now, but that requires a good bit of horsepower. The Celeron 300A in the server just isn't going to be capable of transcoding FLAC->anything in real time, much less do it for 2 or 3 streams at once.
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support? Is it technical, financial, or what? And what can Xiph do to help them in this?
And the only way that'll happen is if someone gives Linux support
You mean, kinda like how id Software does? Or maybe Epic (Unreal, Unreal Tournament)?
The reality is that there are some companies supporting Linux - id Software is probably the best as far as it goes - but it's not making money. For id it's not a huge deal, since they've specifically chosen a portable development structure, but for most companies it's a huge ordeal to not use DirectX, or to port from DirectX to anything else. And sales (and usage) figures aren't indicating that it's worth the money to do so.
Also P4's can't run in SMP mode
Depends on just how much hacking you're willing to do, but it's a pretty safe assumption that most sane people wouldn't be willing to draw new traces...
a Dual G4 1.42GHz is roughly equal to a single P4 4.26GHz
No it's not. SMP does not give you 2x the horsepower. If you get 80-90% of the horsepower you're doing well... and even then you only get the horses if you're actually doing something that take advantage of SMP. Which most users don't. Ever.
Frankly, most of the time your CPU is sitting idle waiting on you to do something. Or waiting on the I/O bus if you are doing something. SMP doesn't mystically solve this problem... usually it just makes it worse.
Are there applications for SMP? Sure. No question. But even most geeks who lust after SMP won't ever actually utilize it to the fullest.
currently the fastest P4 is 3.06GHz
Yes, and it can simulate two CPUs in one, which according to your SMP math makes it 6.12 GHz. Of course, even in the latest linux development kernels nobody's seeing a speed improvement of more than 30-40% in optimal conditions. In most scenarios it adds nothing, or actually slows things down due to I/O contention (which, admittedly, is more severe in a hyperthreading situation than a true SMP one).
Frankly, for the price of the Dual G4 1.42 GHz I can buy more than 2 P4 3.06 GHz boxes, which is a much better solution for most cases.
Well over a thousand titles have been released for the Game Boy Color and Game Boy Advance platforms
Oh, hey, lets talk about MAME and stuff too! Think about the thousands of games available that way!
Talk about irrelevant.
First off, most people don't want to play GB/GBA games on the PC. They want to be able to go down to the store, buy some game released for the PC, and install it. Period.
Linux fails on this... even when you use Transgaming and whatnot. Until that changes, it will continue to fail on this.
Alternately, games could start coming with Linux binaries and auto-installers, but that's even more far fetched... the market is too small. To get this you'd have to solve the first problem, and then demonstrate some significant advantage of spending development time on Linux binaries over running it via Wine/WineX/whatever.
Then why does the least expensive edition of Windows XP support only one processor per machine
Maybe because home users would not benefit in the slightest from a dual CPU setup? Or most power users either? And, look, use XP Pro and you suddenly have multiple CPU capability. How is this something Windows can't do?
And why does the Windows kernel limit the number of simultaneous open incoming TCP connections to a ridiculously low level unless you're running Advanced Server?
Because you're not running a server? Uh... this is part of MS's licensing scheme. You can complain about that, but you can't say it's "something Windows can't do".
And why do the headers to write a file system module cost $1000 [microsoft.com] to license, putting it far out of the CS student/hobbyist price range
Because MS has no interest in that market would be my guess. Stupid of them, but that's their choice. How does this make it impossible to write alternate FS's though? Difficult, yes. Undoable? No.
BTW, I wouldn't agree with the parent poster that "anything you want to do can be done with a Windows PC", but I would agree that for what most people want to do on a computer, it's a lot easier to do under Windows (or a Mac - dependant on what you're looking for really). Linux as a desktop OS still requires far more Unix knowledge than most people want to deal with.
All the GeForce FX does it improve effects using the DirectX 8 dynamic pipeline improvements
Huh?
It's a DX9 compliant part... it can do quite a bit using DX9 that DX8 can't. The same is true for the ATI 9700.
No, there aren't any DX9 games available yet. And there weren't and DX8 games out when the GF3 was released. But if you're buying with an eye toward the future then you'd be smart to buy a DX9 compliant card, whether it's the ATI 9700 or GFFx. That or buy a $100 GF4 Ti4200 now and the 9700/Fx a year or so from now for $150ish.
I'll agree with you on the cooling issues, and it's pretty clear that nVidia blew it on this one. The ATI 9700 is a better card, cheaper, and has been out longer. The drivers don't seem to be an issue right now (although they may be in a year or two... ATI has a pretty crappy track record on extended support). The new revision of the ATI chip should be out in a month or two as well, and they've claimed 20-30% higher performance than the 9700... which really hurts nVidia.
BTW, there are Fx drivers in the nVidia module (see Appendix A of the README - NV30 is listed). They're probably not completely tuned, but neither are the Windows drivers. Based on past history, you can expect significant driver improvements in 3-6 months.
Windows doesn't really use 2d accelleration
Huh?
Since when?
Video cards have had 2D acceleration for the past 10 years, and it makes a huge difference. Letting the card do simple operations like BitBlt, line draws, etc. instead of the CPU doing all the work and then pushing it off to the DAC offloads a ton of work. You clearly do not remember when text scrolling in a window was orders of magnitude slower than scrolling it full screen. I do. I also remember the first card that reversed this for me - a Number9 Imagine128 that I won at Comdex. This was back when 3D acceleration meant an Onyx with RealityEngine for $500k+.
2D performance is rarely an issue nowadays. If it is, then you're either doing something unusual in 2D or you're using amazingly crappy drivers.
In my previous job we regularly processed credit data files >2 GB. All the data is processed serially (as someone else mentioned), so seek time is not an issue (nor is it an issue in a binary data file - seek to 1.4GB. Done. Next.).
The real issue we ran up against was compression... we wanted to have the original and interm data files available on-disk for awhile in case of reprocessing. The processing would generally take up 10x as much space as the original data file, so you compressed everything. Except that gzip can't handle files >2GB (at the time an alpha could, but we didn't want to touch it). Nor can zip. So we had to use compress. Yay. (bzip could handle it, but was decided against by the powers that be).
Compression of large files is still an issue, unless you want to split them up. Unless you download a beta version gzip still can't handle it. As I understand it zip won't ever be able to do it. There are some fringe compressors that can handle large files, but, well, they're fringe.
Yes, because while your GPU may very well handle the rendering, your CPU still has to render most of the geometry itself as well. You have to handle physics, collisions, etc.
BTW, UT2k3 was playable on an Athlon 750... quite a step down from a 2 GHz CPU.
Yeah, because I'm sure MOO3 will have a 3D immersive environment utilizing the latest rendering features of your video card...
Oh... hold it... you mean there's no 3D graphics at all? Well, heck, why does it require a 300 MHz P3 then? You can do pretty much anything needed in 2D with a 486. Must be pretty damn inefficient code.
Hint - comparing games of totally, utterly different genres and then whining about one giving "more bang per cycle" is so abundantly stupid it's sad.
ALWAYS use a credit card. It's your only protection
Be aware, however, that if you buy goods from a foreign country (overseas or not) all sales are final. Federal law does not apply and your credit card company won't help you -- frankly, if they refunded you the money they would be out the cash because there's no way for them to reclaim it. (I note that Microsono is incorporated in Delaware and located in California, so it shouldn't be an issue in this case).
And to the sibling poster - return receipt requested is an additional service on top of certified mail, which is what you were suggesting in the first place.
Excellent advice though. Hopefully richardbondi will follow it.
Helium doesn't cancel gravity, it just happens to have a low density
The one true bit in your post.
BTW, there aren't "many" Helium containing compounds. At least not as compared to other elements, or even other noble gases. There are no currently known stable compounds of Helium.
Second, I would assume the "Gi" was a typo
Or would you assume the "Hi" later was actually HI? And he actually did mean Germanium the first time?
clearly meant "HeGI", which is Helium Gallium Iridide and is widely used in chip manufacture
I is Iodine. And before any compound can be widely used it has to exist in the first place.
Not that it matters, you are a known trollbuster and should be modded down
It's always funny seeing a troll whining about a troll buster. Your standard MO is no different from the original poster's.
And yes, you may now be happy that you got some attention. Your life as a troll has been fulfilled for today.
Frankly, I'm bored and it's rather fun debunking your posts. They're at least somewhat better than Jack Wagner's.
Also how enforcable is a patent that hasn't been enforced for a long time
100% enforceable. It doesn't matter if you bring the violation up on the last day of the patent and it's been infringed for the previous 16 years and 364 days. A patent does not require active enforcement to protect it, unlike trademarks. Copyright is a bit murkier - generally all you can do is force them to not continue infringing (but the copyright is still in force).
There are exceptions -- if you enter into an agreement that requires you to disclose all relevant patents that are applicable to a standard being developed and fail to do so then your patent can be rendered unenforceable. This happened to Dell a few years back, and RAMBUS more recently (not sure if that one has been played out entirely yet).
That's not really the issue... the issue is that they are (allegedly) engaging in the scummy business of submarine patents.
Get a patent on a business model/method... don't act on that patent until it's widely used in the industry. Then have your lawyers pop out and sue everyone.
Exactly what choice is provided here? Most vendors wouldn't have even known about the patent, since people in the industry would assume that it's common practice and unpatented (for a variety of reasons).
At that point you can either cease use of the patented technology (which may still leave you open to licensing fees for prior sales, depending on how a judge rules - you're not supposed to be liable, but lawyers can make IP law dance a jig), pay the extortion money, or attempt to get the patent invalidated. Good luck on the latter - if they're doing it toward the end of the patent life then you'll have a hard time getting facts for prior work 15 years ago, and you'll probably wind up paying more in lawyer fees than you would have paid in extortion.
And yes, I do mean extortion. Submarine patents are nothing but that. It's one thing to raise a patent claim when you didn't know it was being violated. It's another thing to intentionally lie low until it's too late. IP law rarely acknowledges the difference with regards to this though.
Of course, there is one other option, and probably one that we'll see used if SCO is stupid enough to press their case. If someone tries to blackmail you, there's always the possibility of blackmailing them back. IBM has enough software patents to make SCO (or anyone else) wonder if they actually invented anything themselves.