My wife was watching QVC, and I wasn't really paying attention until I saw the guy fall off the ladder. At first, I thought it was a part of the show until I heard someone saying, "It's OK, he's moving..."
Then it occurred to me that perhaps they would have a hard time selling this ladder when their own demonstrator fell off the thing on national tv!
And the best part: The host continued to plug the ladder as safe and convenient, in spite of what had just happened!
Is that the Merced core (Itanium) has only a 64 bit data bus, where AMD's Opteron has a 144 bit bus.
Intel's problem is that too much of their market is tied up in legacy 16 and 32 bit apps. AMD doesn't have this problem - they started off with a RISC core which broke down the x86 instruction set into micro ops on the fly - and these executed faster.
And once again, Intel is making the same mistake they made with the 286 - a 32 bit processor with a _24_ bit memory bus. Intel has consistently under-cached and under-bussed its processors. AMD's 144 bit bus on the Opteron doubles the processor's effective throughput.
Since DMA, processors have had to share the memory bus with PCI and other IO devices. Which means that something like a hard drive or ethernet card can effectively "steal" bus cycles from the CPU, resulting in stalling instruction execution while a physical device is doing IO.
Core designers have just about reached the theoretical limit when in comes to instruction execution efficiency. It just isn't possible to execute more than one instruction per clock cycle without adding parallel instruction units. Even then, interdependencies between instructions can slow the actual throughput down to the 1 per clock cycle level. Because of this, the bus throughput is now the largest factor when determining processor speed. And Intel, true to their tradition, has designed their Itanium with a 64 bit data bus - a design which simply isn't adequate for the high end systems for which the processor is marketed. The uses for a 64 bit architecture require both high instruction throughput and large IO capacity.
The only architecture in which an Itanium would do well is the IBM mainframe architecture in which IO units and processors do not share a common memory bus.
* - I know the McKinley core has a 128 bit data bus, but it seems to me more of a case of "too little, too late". And this isn't even taking into account that the _other_ 64 bit platform, SPARC, started off with a 16MB L2 cache (not 256kB as Itanium has!?).
The real problem is that the studies are geared toward benchmarking the few strengths of the Windows platform. A perceptive reader would note that the IDG study actually confirmed that Windows was significantly less reliable that Linux.
The IDG study mentioned that among file and print servers, Linux servers on Intel platforms averaged a higher workload with a lower failure rate. However, faithful to their master, IDG goes on to contradict itself by noting that Linux admins get paid more than Windows admins. Which means that taken on a per machine basis, Windows is cheaper, but when taken on a workload volume basis, Linux is less expensive.
The problem with such studies is that they are slanted toward the situations in which Microsoft's products do perform reasonably well. Consider for example the Windows-server against Linux-on-mainframe benchmark: a totally useless comparison. In the first place, companies don't buy mainframes for web-serving; they buy them for corporate datacenters. Then, when they want to provide web functionality, they either augment with Windows boxen which must connect to the mainframe for database access, or they run Linux servers on the mainframe. The first case involves hiring additional Windows admins, the second, merely training the existing mainframe systems programmer on Linux. Furthermore, you will never find a situation in which a company's mainframe-based webserver is outperformed by a Windows box. The reason? In real world corporate environments, business critical data is always stored on the mainframe simply because it is the most reliable platform. Thus, the screamingly-fast webserver on a windows box can never run faster than the mainframe simply because it must wait on both the mainframe database and network latency when filling requests.
In reality, the studies are worthless because they simply don't address the manner in which businesses actually use the systems. They ignore the crucial questions of reliability, robustness, compatibility, and support.
Which system should we use to convert? IIRC, an American inch is 2.55 cm, where a British inch is 2.54 cm.
So when we convert our measurements in inches, do we assume that we are using British or American conversions? After all, in engine parts machined accurate to one ten-thousandth of an inch,.01 cm makes a big difference.
Well, yes. The problem is that the Win32 compilers don't support the directory traversing API's that UNIX does, and I was trying to write something portable that could be compiled with both gcc and DJGPP. Yes, I could have gone Win32, but I would basically have two different codebases for the differing platforms. Generally speaking, anything that relies on the Win32 API's can't be ported without substantial effort.
Hate to say I told you so, but I made the same point when Microsoft published their "open" XML spec for Office documents. I got flamed for that one.
"Open" means to Microsoft something entirely different from what most MS developers claim. "Open" means to Microsoft:
Open to making independent developers pay royalties to Microsoft for code they (the independent developers) wrote.
Open to tacking on additional terms and conditions to which the users must agree, or forfeit their investment.
Open for use as a tool to combat this so-called "open source" movement.
Okay, I know this is going to sound like flamebait, but when will Microsoft developers ever learn?
I understand if you have to make a living. Granted, we've all done dirty work at one time or another. But there's a big difference between someone who write MS programs simply because their users run Windows and those who support what they're doing. If Microsoft had its way, it would be illegal to write code for any platform without their explicit approval. This patenting of XML formats is merely an indication of much more insidious intent. Yes, Microsoft would put all developers out of business had they the resources to do so. Anyone who thinks otherwise is blind to the last 10 years of the company's history.
I'm kind of interested in what you are doing.
I have a similar problem - I've got a large set of data that needs to be shared between work, home, and laptop machines. It's constantly a pain because I've got different versions of the same files on different machines, and backup is a real problem.
Supposing I have the most recent version of file A.cpp on the home machine, and most recent version of file B.cpp on the work machine, if I have to restore the laptop, I'm in a real crunch. I won't get the most up to date versions of every file - rather, I have to choose which is most likely to be more up to date, and then restore the out of date files from the other backups by hand.
Rsync did look promising, but I can't use it because it can't run correctly on Windows (in Windows, a user program cannot set the modification date on a file without actually writing to the filesystem tables. The UNIX API's for setting mod time simply return -1 with every call.) I've tried writing my own utility, with moderate success. Given that I can't set the date on a file, I can only synchronize two sources, not three or more.
That is generally the assumption. Usually, the most time-consuming algorithms process lists from front to back - i.e., searching, sorting, popping from a stack, etc...
Past the Pentium 2, the bus width went to 64 bits, so in this case, both pointers would be in cache if you were using a 32 bit system. If you're building for AMD's Opteron, you won't experience a performance hit when going 64 bit, because the Opteron's bus is 144 bits. However, the Itanium's bus is only 64 bits, so you might experience a performance decrease, assuming that you needed to access the backward pointer. Either way, it won't be that much of a difference, because as I stated previously, pointers are generally the least useful in time-sensitive or constrained memory algorithms. If you've got a program which needs more than 4GB of memory, you probably won't be using linked lists or other pointer-intensive structures simply due to the fact that these data structures aren't efficient enough to process this volume of data in a reasonable amount of time.
Eternal vigilance the cost of freedom...
on
Perens on Patents
·
· Score: 3, Insightful
I know its a cliche, but its true.
Yes, patents create a chilling atmosphere for developers in a way much worse than copyright. But the SCO case has shown that the real problem is not patents per se, but greed.
It is an unfortunate reality that we live in a world where someone with sufficient financial means (read: big corporation) can kill an OS project simply by claiming patent or copyright infringement and tying the matter up in the courts for a few years. Even should the defendant be cleared, the intervening years provide Big Corporation(tm) time to either market their own version, or destroy the market completely, as in what Microsoft did with Netscape.
When it comes down to it, most OS developers don't have the financial means to fight a patent or copyright fight with a large corporation. Even should they have the resolve to do so, the Big Corporation can effectively deny the distribution of said software with an injunction until the case is resolved, by which time the software has become obsolete.
Which leads to the problem we face today. Yes, we would like all software to be OS, but the realities of the legal climate and need to feed ourselves means that proprietary software is often the only effective model. Even if we were completely altruistic, any developer capable of developing something new and revolutionary would have to charge for the software, simply to build a war chest for the inevitable IP lawsuits which would follow. The reason why Linux has been so successful is because it hasn't taken revenue away from Microsoft. If Microsoft lost 50% of their desktop market to Linux, you can bet Microsoft would claim copyright or patent infringement. The actual substance of the claim doesn't matter; an injunction against distributing Linux which held for even a year could destroy its adoption by vendors and end users.
Seriously, it is faster. I've been writing in assembly for years, and unless I need a 32 bit pointer, I generally don't use them.
If you're that concerned about performance that you are analysing pointer size, you might as well code in assembly. Yes, 64 bit pointers have a bigger footprint, but we experienced the same problem when we went to unicode strings, 32 bit code, etc...
My advice is this: let the compiler deal with it. Unless you are willing to crank out a lot of hand-coded assembly or are interfacing with hardware, the 32/64 bit pointer question is pretty much moot. As it is, you can't control:
Where your linker places segments in the loaded image. Trust me, this is a big source of cache misses on the older processors where the libraries were in one area of memory and the running code in another.
The optimal ordering of instructions to keep the U and V pipelines of the processor filled. Some of the modern compilers can do this pretty well, but you can never be too sure. The number of clock cycles an instruction takes can vary by a factor of 3, so unless you're willing to learn some pretty hardcore assembly, you're stuck with whatever the compiler gives you.
The instruction level optimization of the compiler. Intel's new C++ compiler will turn the familiar array initialization code:
for (int x = 0; x < 256; x++)buffer[x] = 0;
Into something like this:
mov cx,64
mov eax,0
mov si,buffer
cld
rep stosd
Instead of the literal translations of the old compilers:
mov si,buffer
mov bx,0 ; this is the x variable
forlabel@10001:
mov [bx + si],0
mov ax,1
add ax,bx
xchg bx,ax
cmp bx,256
jl forlabel@10001
The former takes 68 instruction cycles, the later takes (6 * 256 + 2) = 1576!
The aforementioned issues have a much bigger impact on performance than pointer size. Given that the memory bus is at least 64 bits wide on anything newer than a pentium, you won't incur a clock cycle penalty for using 64 bit pointers.
The only thing that I would suggest is to watch where you place pointers in structures. For example, when building a linked list, you would want to do something like this:
class link {
link * ptrforward;
link * ptrbackward;
link * ptrdata;
}
rather than:
class link{
link * ptrdata;
link * ptrbackward;
link * ptrforward;
}
Because the processor pulls 64 bits per address accessed, the former structure would have the forward pointer in cache regardless of the pointer size. With the second structure, traversing a list in the forward direction would result in a cache miss on every node visited, regardless of pointer size (This applies only to the x86...).
My experience has been that pointer size is only relevant on truly tiny systems - for example, 16 bit code which has to fit into a few kilobytes. Usually, as programs scale to work with larger datasets, the percentage of memory used for pointers decreases rapidly. You'll find that as data sizes increase, the practical uses for linked structures shrink; locating an element by using a binary search on a sorted array scales much better than a linear search traversing linked list.
The information they divulged was divulged to a researcher at NASA. Though I don't have the URL, I remember reading that the researcher basically concluded that airline passenger data could not be used to predict terrorist events; that the so-called passenger profiling efforts were effectively worthless. In other words, you couldn't reliably pick out terrorists based on statistical analyses of passenger flight records.
How ironic that Northwest is getting sued for something which didn't even achieve its intended result!
He thinks everything runs Windows. It doesn't, and this is the reason why his "Digital Pearl Harbor" can't happen. Unix boxes are much more secure than Windows boxes, and even failing that, most of the important* information is stored on mainframes anyway.
Quite frankly, it doesn't matter if all Windows PC's go down and can't come back up; the resulting drop in traffic due to Windows worms no longer propogating would mean that our internet experience would get better, not worse.
Furthermore, I know for a fact that mainframes aren't subject to the massive vulnerabilities that Windows PC's are. Even if all the Windows and UNIX boxes were hacked, it still wouldn't be a major catastrophe simply because the overwhelming majority of financial institutions and large corporations use mainframes for their crucial data. Consumers could care less if the local bulk-mailer loses their customer database, and it isn't likely that such a "catastrophe" would prevent their bank from dispensing cash, etc...
* - I've heard it stated that more than 90% of all the data processing done in the world is done with mainframes. So yes, taking out all Windows and UNIX boxes might knock down the Internet, but it won't erase your bank account or stop your bills from coming.
You mean like the big boys in the enterprise market? Like IBM, which sells multimillion-dollar mainframes and charges fees upwards of 100,000 per year to license the operating system?
On one hand, I'm glad that Microsoft hasn't figured this out - I don't feel like paying a yearly fee just to use my own hardware. But let's face it - Microsoft has been literally giving away the company when it comes to enterprise contracts - they sell licenses rather than lease them. Had IBM sold software, I doubt they would be as successful as they are today.
I know a lot of people like to bash Microsoft, but when it comes to exploitation and greed, IBM wins hands down. Mainframe customers routinely pay IBM yearly fees to run hardware they've already bought. IBM software, though, is usually much better than Microsoft's. Perhaps if Microsoft did charge yearly fees, it would be possible to buy a Windows PC that didn't crash.
Regardless, one of the most disheartening aspects of my profession is the amount of sheer greed and legalized fraud that occurs. Some days, I feel as dirty as a lawyer...
UNIX services for Windows have been available for free under the Cygwin moniker for a long time. I guess no one noticed, though...
Of course, now that Microsoft is making their own version, we can be sure that our UNIX apps won't run on Windows.
I had a rather bad experience with this. I was trying to build a portable "safe" copy utility - one that wouldn't overwrite a file if the source date was before the destination's. And guess what? Microsoft's implementation of the set_time (or whatever it was called...) doesn't work - it returns -1 every time. Hence, every time I copied a file, the original date/time stamp was replaced with the current date and time, making a 3-way safe merge of directories impossible.*
So yeah, now Microsoft is offering buggy copies of the original UNIX API's, which don't work as advertised. How long will it be before the rest of the UNIX community figures this out, and Microsoft fails yet again to gain any ground against UNIX and the enterprise market?
Microsoft fails to understand that certain types of customers aren't fooled by the smoke and mirror show they're doing. We can't afford to bet our careers on the promises of a convicted felon. If you can't prove it works and back it up in writing, we can't/won't buy your software. It's that simple.
* - Yeah, I suppose cygwin might have worked. But since it isn't part of our standard package, it wasn't an option at the time.
Well, that's why you don't work at Microsoft. People like you would reduce their profit margin. The average joe doesn't care if his files get lost now and then - what he really wants is more streaming video from his dialup connection.
And supposing Windows did close any open files and flush the cache.... Why would anyone buy an upgrade?
Honestly, those people who write perfect code don't write it for long. How many programmers have been put out of work by writing code that worked the first time, only to find their users foregoing upgrades, and themselves unable to feed their families? If there aren't bugs in your code, you'll literally write yourself out of the market.
When you think about it, there's really no future for someone who doesn't write software in such a manner that it always needs fixing. Think of all the system administrators who are able to bill overtime because of the lack of effort on Microsoft's part. Think of all the jobs that would be lost if Windows didn't crash, or wasn't vulnerable to viruses.
There are real people with real jobs at stake here. Don't just think of yourself, man!
Okay, for anyone who believes I'm serious, I've got a bridge to sell you in San Fransisco. But if you take anything from this, realize that many of the jobs in the IT industry are the direct result of companies trying to use Windows for their business systems. If everyone ran Linux/UNIX/BSD/mainframes, well, a lot more of us would be looking for work.
IIRC, a law was recently passed which allows the FBI to collect a business' records without a subpeona. Which means that if your employer has your fingerprints, so does the FBI.
Someone could very easily lose their anonymity by simply working for the wrong employer. The Burlington Northern example is a case in point - IIRC, employees were forced to undergo mandatory genetic testing; those with a genetic tendency toward carpal tunnel syndrome were fired. Now the FBI has access to the genetic information for every one of BN's employees who was tested.
To be honest, the confidentiality promises a company makes mean nothing. Every company has a disclaimer stating that they will divulge information to comply with law enforcement and some (such as Ebay) make it a point to market this service to law enforcement.
Our lives are no longer private. If it is in a company database somewhere, the FBI now has access to it. The only safe option is to not turn over information you don't want the government to have to anyone, for any reason.
they scheduled five different projects, the first one of which was set up to fail(!)
This isn't as uncommon as one might think. It's an informal Army tradition that new soldiers fresh out of basic training will get assigned an impossible task. A soldier I know of was told to go get a chemlight (the military's version of a glow stick) battery from the motorpool. He returned with a 50 Lb. humvee battery...
Agreed, but the problem is compounded by SCO refusing to work with the Linux kernel programmers to remove the code. Even if SCO's intellectual property does exist in the Linux kernel, they can't claim damages because they deliberately acted in a manner which compounded the extent of the damages. It would be very hard to convince a jury of the value of their IP when they took steps that ensured that it was not removed from the Linux kernel. If indeed their IP was so valuable, why didn't they make a concerted effort to prevent its free dissemination? So yes, the jury might find the defendant at fault, but after seeing the manner in which SCO deliberately set a trap to increase the monetary damages, that jury might be well disposed to award SCO $1.
If SCO did sue, the case would be dismissed because SCO did not employ due diligence - i.e., they were requested to reveal the infringing code on numerous occasions and failed to do so.
Should the case not be dismissed initially,(IANAL) the defendant could compel the infringing code via discovery, at which point same need only remove the infringing code from their copy of the kernel sources to render the case moot and void.
Even if the defendant didn't want to remove the code from the kernel sources, it would not be difficult to show that SCO does not actually rightfully own the code that they believe they do.
Even should SCO win the case, SCO is claiming ownership of Linux only. Since the GNU operating system was originally designed for the MACH kernel, it could easily be ported, leaving RMS happy with a GNU-only OS and SCO with nothing.
Furthermore, since the terms of the GPL specifically prohibit distributing software without access to the source, it could be shown that SCO is indeed violating copyright law. Since most of the Linux kernel is not derived from SCO's UNIX, Linus, et al., could sue SCO for any profits gained from their IP licensing scheme, since SCO is/was distributing Linux without their permission.
What strikes me as odd is that the whole case would be moot if the major distros simply ported their systems to a different kernel, such as MACH, or HURD. SCO would be left with nothing, and Linus would have a very good slander case against SCO.
Slashdot Mirror
I'm in a local pizza and gaming establishment (rhymes with lucky sneeze), and lo and behold, I'm looking at a linux boot up screen on an arcade game.
And then I'm at a local clothes retailer, and I look and see Red Hat 6.0 sitting on the register display.
It's coming, folks. It's just a matter of time.
My wife was watching QVC, and I wasn't really paying attention until I saw the guy fall off the ladder. At first, I thought it was a part of the show until I heard someone saying, "It's OK, he's moving..."
Then it occurred to me that perhaps they would have a hard time selling this ladder when their own demonstrator fell off the thing on national tv!
And the best part: The host continued to plug the ladder as safe and convenient, in spite of what had just happened!
Is that the Merced core (Itanium) has only a 64 bit data bus, where AMD's Opteron has a 144 bit bus.
Intel's problem is that too much of their market is tied up in legacy 16 and 32 bit apps. AMD doesn't have this problem - they started off with a RISC core which broke down the x86 instruction set into micro ops on the fly - and these executed faster.
And once again, Intel is making the same mistake they made with the 286 - a 32 bit processor with a _24_ bit memory bus. Intel has consistently under-cached and under-bussed its processors. AMD's 144 bit bus on the Opteron doubles the processor's effective throughput.
Since DMA, processors have had to share the memory bus with PCI and other IO devices. Which means that something like a hard drive or ethernet card can effectively "steal" bus cycles from the CPU, resulting in stalling instruction execution while a physical device is doing IO.
Core designers have just about reached the theoretical limit when in comes to instruction execution efficiency. It just isn't possible to execute more than one instruction per clock cycle without adding parallel instruction units. Even then, interdependencies between instructions can slow the actual throughput down to the 1 per clock cycle level. Because of this, the bus throughput is now the largest factor when determining processor speed. And Intel, true to their tradition, has designed their Itanium with a 64 bit data bus - a design which simply isn't adequate for the high end systems for which the processor is marketed. The uses for a 64 bit architecture require both high instruction throughput and large IO capacity.
The only architecture in which an Itanium would do well is the IBM mainframe architecture in which IO units and processors do not share a common memory bus.
* - I know the McKinley core has a 128 bit data bus, but it seems to me more of a case of "too little, too late". And this isn't even taking into account that the _other_ 64 bit platform, SPARC, started off with a 16MB L2 cache (not 256kB as Itanium has!?).
IIRC, Potassium is a solid at room temperature, not to mention at absolute zero.
So why does the article say potassium gas? Did they mean a gaseous potassium compound? Or am I just missing something?
The real problem is that the studies are geared toward benchmarking the few strengths of the Windows platform. A perceptive reader would note that the IDG study actually confirmed that Windows was significantly less reliable that Linux.
The IDG study mentioned that among file and print servers, Linux servers on Intel platforms averaged a higher workload with a lower failure rate. However, faithful to their master, IDG goes on to contradict itself by noting that Linux admins get paid more than Windows admins. Which means that taken on a per machine basis, Windows is cheaper, but when taken on a workload volume basis, Linux is less expensive.
The problem with such studies is that they are slanted toward the situations in which Microsoft's products do perform reasonably well. Consider for example the Windows-server against Linux-on-mainframe benchmark: a totally useless comparison. In the first place, companies don't buy mainframes for web-serving; they buy them for corporate datacenters. Then, when they want to provide web functionality, they either augment with Windows boxen which must connect to the mainframe for database access, or they run Linux servers on the mainframe. The first case involves hiring additional Windows admins, the second, merely training the existing mainframe systems programmer on Linux. Furthermore, you will never find a situation in which a company's mainframe-based webserver is outperformed by a Windows box. The reason? In real world corporate environments, business critical data is always stored on the mainframe simply because it is the most reliable platform. Thus, the screamingly-fast webserver on a windows box can never run faster than the mainframe simply because it must wait on both the mainframe database and network latency when filling requests.
In reality, the studies are worthless because they simply don't address the manner in which businesses actually use the systems. They ignore the crucial questions of reliability, robustness, compatibility, and support.
Which system should we use to convert? IIRC, an American inch is 2.55 cm, where a British inch is 2.54 cm.
So when we convert our measurements in inches, do we assume that we are using British or American conversions? After all, in engine parts machined accurate to one ten-thousandth of an inch, .01 cm makes a big difference.
Seeing as how Bill Gates is notorious for predicting things which don't come true, I think I'm going to have to learn to live with spam....
Well, yes. The problem is that the Win32 compilers don't support the directory traversing API's that UNIX does, and I was trying to write something portable that could be compiled with both gcc and DJGPP. Yes, I could have gone Win32, but I would basically have two different codebases for the differing platforms. Generally speaking, anything that relies on the Win32 API's can't be ported without substantial effort.
Hate to say I told you so, but I made the same point when Microsoft published their "open" XML spec for Office documents. I got flamed for that one.
"Open" means to Microsoft something entirely different from what most MS developers claim. "Open" means to Microsoft:
- Open to making independent developers pay royalties to Microsoft for code they (the independent developers) wrote.
- Open to tacking on additional terms and conditions to which the users must agree, or forfeit their investment.
- Open for use as a tool to combat this so-called "open source" movement.
Okay, I know this is going to sound like flamebait, but when will Microsoft developers ever learn?I understand if you have to make a living. Granted, we've all done dirty work at one time or another. But there's a big difference between someone who write MS programs simply because their users run Windows and those who support what they're doing. If Microsoft had its way, it would be illegal to write code for any platform without their explicit approval. This patenting of XML formats is merely an indication of much more insidious intent. Yes, Microsoft would put all developers out of business had they the resources to do so. Anyone who thinks otherwise is blind to the last 10 years of the company's history.
Okay, flame away.
I'm kind of interested in what you are doing. I have a similar problem - I've got a large set of data that needs to be shared between work, home, and laptop machines. It's constantly a pain because I've got different versions of the same files on different machines, and backup is a real problem.
Supposing I have the most recent version of file A.cpp on the home machine, and most recent version of file B.cpp on the work machine, if I have to restore the laptop, I'm in a real crunch. I won't get the most up to date versions of every file - rather, I have to choose which is most likely to be more up to date, and then restore the out of date files from the other backups by hand.
Rsync did look promising, but I can't use it because it can't run correctly on Windows (in Windows, a user program cannot set the modification date on a file without actually writing to the filesystem tables. The UNIX API's for setting mod time simply return -1 with every call.) I've tried writing my own utility, with moderate success. Given that I can't set the date on a file, I can only synchronize two sources, not three or more.
Past the Pentium 2, the bus width went to 64 bits, so in this case, both pointers would be in cache if you were using a 32 bit system. If you're building for AMD's Opteron, you won't experience a performance hit when going 64 bit, because the Opteron's bus is 144 bits. However, the Itanium's bus is only 64 bits, so you might experience a performance decrease, assuming that you needed to access the backward pointer. Either way, it won't be that much of a difference, because as I stated previously, pointers are generally the least useful in time-sensitive or constrained memory algorithms. If you've got a program which needs more than 4GB of memory, you probably won't be using linked lists or other pointer-intensive structures simply due to the fact that these data structures aren't efficient enough to process this volume of data in a reasonable amount of time.
I know its a cliche, but its true.
Yes, patents create a chilling atmosphere for developers in a way much worse than copyright. But the SCO case has shown that the real problem is not patents per se, but greed.
It is an unfortunate reality that we live in a world where someone with sufficient financial means (read: big corporation) can kill an OS project simply by claiming patent or copyright infringement and tying the matter up in the courts for a few years. Even should the defendant be cleared, the intervening years provide Big Corporation(tm) time to either market their own version, or destroy the market completely, as in what Microsoft did with Netscape.
When it comes down to it, most OS developers don't have the financial means to fight a patent or copyright fight with a large corporation. Even should they have the resolve to do so, the Big Corporation can effectively deny the distribution of said software with an injunction until the case is resolved, by which time the software has become obsolete.
Which leads to the problem we face today. Yes, we would like all software to be OS, but the realities of the legal climate and need to feed ourselves means that proprietary software is often the only effective model. Even if we were completely altruistic, any developer capable of developing something new and revolutionary would have to charge for the software, simply to build a war chest for the inevitable IP lawsuits which would follow. The reason why Linux has been so successful is because it hasn't taken revenue away from Microsoft. If Microsoft lost 50% of their desktop market to Linux, you can bet Microsoft would claim copyright or patent infringement. The actual substance of the claim doesn't matter; an injunction against distributing Linux which held for even a year could destroy its adoption by vendors and end users.
Seriously, it is faster. I've been writing in assembly for years, and unless I need a 32 bit pointer, I generally don't use them.
If you're that concerned about performance that you are analysing pointer size, you might as well code in assembly. Yes, 64 bit pointers have a bigger footprint, but we experienced the same problem when we went to unicode strings, 32 bit code, etc...
My advice is this: let the compiler deal with it. Unless you are willing to crank out a lot of hand-coded assembly or are interfacing with hardware, the 32/64 bit pointer question is pretty much moot. As it is, you can't control:
for (int x = 0; x < 256; x++)buffer[x] = 0;
Into something like this:
mov cx,64
mov eax,0
mov si,buffer
cld
rep stosd
Instead of the literal translations of the old compilers:
mov si,buffer
mov bx,0 ; this is the x variable
forlabel@10001:
mov [bx + si],0
mov ax,1
add ax,bx
xchg bx,ax
cmp bx,256
jl forlabel@10001
The former takes 68 instruction cycles, the later takes (6 * 256 + 2) = 1576!
The aforementioned issues have a much bigger impact on performance than pointer size. Given that the memory bus is at least 64 bits wide on anything newer than a pentium, you won't incur a clock cycle penalty for using 64 bit pointers.
The only thing that I would suggest is to watch where you place pointers in structures. For example, when building a linked list, you would want to do something like this:
class link {
link * ptrforward;
link * ptrbackward;
link * ptrdata;
}
rather than:
class link{
link * ptrdata;
link * ptrbackward;
link * ptrforward;
}
Because the processor pulls 64 bits per address accessed, the former structure would have the forward pointer in cache regardless of the pointer size. With the second structure, traversing a list in the forward direction would result in a cache miss on every node visited, regardless of pointer size (This applies only to the x86...).
My experience has been that pointer size is only relevant on truly tiny systems - for example, 16 bit code which has to fit into a few kilobytes. Usually, as programs scale to work with larger datasets, the percentage of memory used for pointers decreases rapidly. You'll find that as data sizes increase, the practical uses for linked structures shrink; locating an element by using a binary search on a sorted array scales much better than a linear search traversing linked list.
The information they divulged was divulged to a researcher at NASA. Though I don't have the URL, I remember reading that the researcher basically concluded that airline passenger data could not be used to predict terrorist events; that the so-called passenger profiling efforts were effectively worthless. In other words, you couldn't reliably pick out terrorists based on statistical analyses of passenger flight records.
How ironic that Northwest is getting sued for something which didn't even achieve its intended result!
He thinks everything runs Windows. It doesn't, and this is the reason why his "Digital Pearl Harbor" can't happen. Unix boxes are much more secure than Windows boxes, and even failing that, most of the important* information is stored on mainframes anyway.
Quite frankly, it doesn't matter if all Windows PC's go down and can't come back up; the resulting drop in traffic due to Windows worms no longer propogating would mean that our internet experience would get better, not worse.
Furthermore, I know for a fact that mainframes aren't subject to the massive vulnerabilities that Windows PC's are. Even if all the Windows and UNIX boxes were hacked, it still wouldn't be a major catastrophe simply because the overwhelming majority of financial institutions and large corporations use mainframes for their crucial data. Consumers could care less if the local bulk-mailer loses their customer database, and it isn't likely that such a "catastrophe" would prevent their bank from dispensing cash, etc...
* - I've heard it stated that more than 90% of all the data processing done in the world is done with mainframes. So yes, taking out all Windows and UNIX boxes might knock down the Internet, but it won't erase your bank account or stop your bills from coming.
So do I, but I haven't been able to locate a compiler for it, so it's been in storage. Any suggestions?
You mean like the big boys in the enterprise market? Like IBM, which sells multimillion-dollar mainframes and charges fees upwards of 100,000 per year to license the operating system?
On one hand, I'm glad that Microsoft hasn't figured this out - I don't feel like paying a yearly fee just to use my own hardware. But let's face it - Microsoft has been literally giving away the company when it comes to enterprise contracts - they sell licenses rather than lease them. Had IBM sold software, I doubt they would be as successful as they are today.
I know a lot of people like to bash Microsoft, but when it comes to exploitation and greed, IBM wins hands down. Mainframe customers routinely pay IBM yearly fees to run hardware they've already bought. IBM software, though, is usually much better than Microsoft's. Perhaps if Microsoft did charge yearly fees, it would be possible to buy a Windows PC that didn't crash.
Regardless, one of the most disheartening aspects of my profession is the amount of sheer greed and legalized fraud that occurs. Some days, I feel as dirty as a lawyer...
UNIX services for Windows have been available for free under the Cygwin moniker for a long time. I guess no one noticed, though...
Of course, now that Microsoft is making their own version, we can be sure that our UNIX apps won't run on Windows.
I had a rather bad experience with this. I was trying to build a portable "safe" copy utility - one that wouldn't overwrite a file if the source date was before the destination's. And guess what? Microsoft's implementation of the set_time (or whatever it was called...) doesn't work - it returns -1 every time. Hence, every time I copied a file, the original date/time stamp was replaced with the current date and time, making a 3-way safe merge of directories impossible.*
So yeah, now Microsoft is offering buggy copies of the original UNIX API's, which don't work as advertised. How long will it be before the rest of the UNIX community figures this out, and Microsoft fails yet again to gain any ground against UNIX and the enterprise market?
Microsoft fails to understand that certain types of customers aren't fooled by the smoke and mirror show they're doing. We can't afford to bet our careers on the promises of a convicted felon. If you can't prove it works and back it up in writing, we can't/won't buy your software. It's that simple.
* - Yeah, I suppose cygwin might have worked. But since it isn't part of our standard package, it wasn't an option at the time.
Well, that's why you don't work at Microsoft. People like you would reduce their profit margin. The average joe doesn't care if his files get lost now and then - what he really wants is more streaming video from his dialup connection.
And supposing Windows did close any open files and flush the cache.... Why would anyone buy an upgrade?
Honestly, those people who write perfect code don't write it for long. How many programmers have been put out of work by writing code that worked the first time, only to find their users foregoing upgrades, and themselves unable to feed their families? If there aren't bugs in your code, you'll literally write yourself out of the market.
When you think about it, there's really no future for someone who doesn't write software in such a manner that it always needs fixing. Think of all the system administrators who are able to bill overtime because of the lack of effort on Microsoft's part. Think of all the jobs that would be lost if Windows didn't crash, or wasn't vulnerable to viruses.
There are real people with real jobs at stake here. Don't just think of yourself, man!
Okay, for anyone who believes I'm serious, I've got a bridge to sell you in San Fransisco. But if you take anything from this, realize that many of the jobs in the IT industry are the direct result of companies trying to use Windows for their business systems. If everyone ran Linux/UNIX/BSD/mainframes, well, a lot more of us would be looking for work.
IIRC, a law was recently passed which allows the FBI to collect a business' records without a subpeona. Which means that if your employer has your fingerprints, so does the FBI.
Someone could very easily lose their anonymity by simply working for the wrong employer. The Burlington Northern example is a case in point - IIRC, employees were forced to undergo mandatory genetic testing; those with a genetic tendency toward carpal tunnel syndrome were fired. Now the FBI has access to the genetic information for every one of BN's employees who was tested.
To be honest, the confidentiality promises a company makes mean nothing. Every company has a disclaimer stating that they will divulge information to comply with law enforcement and some (such as Ebay) make it a point to market this service to law enforcement.
Our lives are no longer private. If it is in a company database somewhere, the FBI now has access to it. The only safe option is to not turn over information you don't want the government to have to anyone, for any reason.
if I'm tagged as "red" and refused entry onto a plane?
I really don't have the option of driving. But I can see how something like this could create some very bad publicity for the airlines.
This isn't as uncommon as one might think. It's an informal Army tradition that new soldiers fresh out of basic training will get assigned an impossible task. A soldier I know of was told to go get a chemlight (the military's version of a glow stick) battery from the motorpool. He returned with a 50 Lb. humvee battery...
Agreed, but the problem is compounded by SCO refusing to work with the Linux kernel programmers to remove the code. Even if SCO's intellectual property does exist in the Linux kernel, they can't claim damages because they deliberately acted in a manner which compounded the extent of the damages. It would be very hard to convince a jury of the value of their IP when they took steps that ensured that it was not removed from the Linux kernel. If indeed their IP was so valuable, why didn't they make a concerted effort to prevent its free dissemination? So yes, the jury might find the defendant at fault, but after seeing the manner in which SCO deliberately set a trap to increase the monetary damages, that jury might be well disposed to award SCO $1.
It doesn't matter, because:
What strikes me as odd is that the whole case would be moot if the major distros simply ported their systems to a different kernel, such as MACH, or HURD. SCO would be left with nothing, and Linus would have a very good slander case against SCO.
30 and counting.
For Christmas, my wife got me a set of Legos - perhaps intended to keep me away from the computer.
It worked! Now she hates both Legos and the computer...
I don't know, but there's just something about a mental challenge that I find irresistable.