We stopped using CF because it was slow and fragile. 4.5 was a disaster, Allaire should never have released it. Doubtless MX is much better, but it's too late for us.
Regarding the user directories, a problem inherent in CF (and ASP, PHP, JSP) is that included pages can be requested from a browser. That is, if login.cfm includes/incl/check_access.cfm then I can request http://somedomain.com/incl/check_access.cfm from a browser and see what happens... more often than not an error message will appear, but I've seen sites hacked that way. Templates that are not intended to be pages simply shouldn't be in the document root. (On any
You can get around that on ColdFusion by naming included files with an absolute path, and configuring the template path in CF administrator. But that doesn't completely solve your problem.
Well, something's gotta give... I've worked several places now where I've seen IT spending grow almost without bound over the past 5 years, both in terms of staff & technology.
I hold that this is ridiculous, the technology is supposed to reduce staffing costs, yet for all of the "progress" in this industry IT costs have risen sharply for many. At my present job (for a very small outfit) I've chosen to use staffing as the benchmark: if I have to hire more help, the solution is too complex.
Simplify. Reject ridiculous, complicated software. Build on things that work. Throw away things that don't. This ain't rocket science, and never was.
Software houses have been awfully busy for the past 30 years or so, and free software hasn't stood still either. If you need some package it's already out there. I would say software has become commoditized, but that's not really true, because even commodities have a manufacturing cost.
It's very rare nowadays that I come across a problem that hasn't already been solved somewhere, sometime, by someone. Writing more software seems wasteful to me.
What I do find useful is new ways to combine and use old software... sometimes that means new code, but usually it means modifying code... and BTW open source really helps there.
My customers have never asked me to write software, they ask everyday for solutions, because they don't have the expertise to use what they already own. Don't underestimate the potential of the service market there. It's not about a subscription model. Think of me as the Maytag man... when somebody has a need or problem they call. They're free to use the systems they own until eternity. The more complex the system, the more they call... and boy oh boy is software complex these days.
The shrinkwrapped market is almost gone... mostly games left, that I can see.
Fascinating. Not that it matters anymore, but I repeatedly had trouble with @Home's network. The people I called in support (and friends I asked) never figured it out. I had to disable DHCP to even operate. Here's what I did.
From time to time, I'd lose my Internet connection. A little investigation showed that I could see other customers on my local subnet, but couldn't reach the gateway. No response from ping, and/sbin/arp would just say "".
If I called tech support they would somehow connect to my modem to investigate the problem, and everything would start to work... until my arp cache expired, that is. After a few calls they assigned me to a new IP address on a different subnet. It worked for a while.
Resetting the modem, restarting the computer, etc. never helped, so I tried disabling DHCP and setting my gateway address to another customer's modem. That would work, so apparently the modems were willing to route arbitrary IP traffic.
This would go for weeks until the gateway address suddenly became reachable again.
Interesting that every tech support person I spoke to seemed to know less about networking than I did. One guy was impressed that I ran Linux, though... he gave me the company line about non-supports OSes but I managed to convince him that it was a better OS for network diagnostics (tcpdump, etc.)
(The modem installers didn't say a word about my Alpha/NT machine, though they were visibly confused when it refused to run their @Home CD software... heh.)
First of all, POWER4 is certainly not a derivative of PPC. There are significant differences between the two.
"PPC is the cleanest Risc architecture"
For whatever definition of "clean", the closest were probably research chips like the original MIPS or predecessor of SPARC. PPC has quite a bit of extra baggage, not a fatal flaw by any means but hardly merits your description.
"IBM's design expertise and manufacturing prowress guarantees it will stomp on the competition."
LOL. If that were any guarantee of anything, history would be very different (for one thing, Digital would probably still be a company, and Intel would've vanished years ago).
"VLIW in and of itself has not come into the stage where it is a good design concept it is not mature enough."
And it may never. VLIW seemed like a pretty good idea 10 or so years ago, when processor speeds were still under 100MHz. But things have changed, and there is a whole new set of problems VLIW isn't prepared to solve.
"...Intel is retarded for not just buying the Alpha processor cleaning up the instruction set..."
Alpha was probably the cleanest commercial RISC processor. It was certainly minimalistic, giving the compiler freedom to optimize code.
Intel on the other hand is not exactly known for clean instruction sets. So what exactly would you propose they do to Alpha?
(*sigh* why do people keep posting bs to/. when they have no idea what they are saying?)
Because there are better ways to use die space? SMP isn't all that beneficial for general-purpose use. At least not now that processor technology has greatly outrun memory technology.
There are of course applications that can greatly benefit from 4x and higher SMP, but they are comparatively few, and not a huge market to the likes of Intel. Compare that to the benefits of additional cache; almost everybody can use a larger, on-die L2 cache.
Consider that these are mass-market low-margin products and you have your answer. If you want massive SMP, there are other companies who'd love to help you.
In the pSeries 690, if you've got $500,000 or so to spend.
Although the Power architecture spawned the PowerPC I very much doubt that Apple will use them?
The Power4 will trickle down into smaller packages, though not necessarily one you or I can afford... though we'll surely see some major upgrades in the PowerPC series during 2002-2003.
Unfortunately, Apple does not seem serious about servers, nor are they giving any real indication of changing that attitude.
For servers, small RS6000 boxes running AIX or Linux are probably the best bet (at least in Power/PPC hardware).
SRM usually loads a secondary bootstrap loader, e.g. aboot, which understands ext2 filesystems. So this isn't a real limitation.
Reasons SRM is better than a PC BIOS:
1) It understands a serial console
2) It can boot over a network (using bootp/tftp)
3) SRM has no artificial limitations on memory size (as in x86 real mode).
I have a Alpha 164LX motherboard in a case with Ethernet and memory... no floppy, hard disk, video, keyboard or mouse. Still it can boot onto the network and run web servers, etc.
21164A (aka EV56) also added byte-word extensions.
The original Alpha had no instructions to read/write anything smaller than 32-bits to/from memory. That had some interesting consequences, like sparse addressing for video framebuffers, requiring far more virtual memory than other CPUs (note that VM isn't exactly free due to page table overhead and TLB misses).
RISC is absolutely not outdated; the principles behind RISC (pipelining, superscalar execution, etc.) have been embraced by nearly all CPU manufacturers, including IBM, HP, Sun, Compaq, AMD and Intel.
Only Intel's EPIC is a standout from a design standpoint... time will tell whether they made a mistake.
Almost all modern apps require x-86 extensions such as MMX, SSE, and 3dNow, which Alphas do not support.
Modern apps like Mozilla, GCC, Linux? Heck no. These run fine on Alpha.
These "extensions" are mostly workarounds for deficient floating-point in the x86. They are very specific to x86 and irrelevant to any other ISA. (There are also vector extensions, which are supported on Alpha EV6 and up as the MVI extension.)
X86 machines are sleek and smoothe like a Porche because they use brilliant engineering and specialised extensions like SSE.
Boy have you been brainwashed. x86 has a butt-ugly ISA dating from the 1970's that only its mother could love. Alpha, PPC and SPARC (to some extent) are all redesigns that cure a lot of the problems in x86.
Intel's 32-bit chips continue to thrive due to marketing, not technology.
The UltraSparc line brings lots to the table and even IA-64 has some redeeming qualities.
Sadly, the current US-III and Merced are no match for Alpha, yet. Look up SPEC if like. The POWER4 is currently the performance king; McKinley has a lot to prove.
It's not quite that simple. They've tweaked the inliner a bit, since g++ 3.0 compile times are sometimes hideously slow. Only the default is changed.
It doesn't necessarily produce slower code. Over-aggressive inlining can also be detrimental to execution time. The current limit is an attempt to compromise until better inliner heuristics are found.
The issue has been discussed at length in the GCC archives.
1) gzip (small but important)
2) bash (OK, ksh93 is an alternative)
3) emacs
4) autotools (autoconf/automake/libtool)
5) fileutils (yes there are other sources for these but when you get used to "cp -a" etc., well...)
...and so on. Believe me, I thought when I first tried to GNU-ify Solaris I'd only be porting a few packages.
Anyway, the Cygwin runtime really consists of both the Cygwin DLL and newlib. The latter isn't Red Hat software, nor is it GPL. The real role of Cygwin is to provide a POSIX interface, something that's done by Linux elsewhere.
Ah, yes, of course... I take that sort of thing for granted, since I often develop on Solaris. I have to install my fat GNU package before Solaris is useable at all (by then it is almost indistinguishable from GNU/Linux).
That said, I recently installed the full suite of Cygwin tools on my Win2K development machine, and it gave me a
slightly different perspective on the Linux vs. GNU/Linux debate.
How so? Are you referring to the similarities between Cygwin and GNU/Linux or something else?
In addition, I beleive that the Itanium CPU itself does no real optimization of the instructions, such as common
subexpression elimination, loop unrolling, etc. Instead it relies on the compiler to create highly optimized code.
CSE and loop unrolling are high-level optimizations left to the compiler. Show me any processor that can do these on chip.
Anyway, IA-64 and US-III have one thing in common, they are both in-order processors, so both are very sensitive to instruction scheduling in the compiler.
For all the web sites I've managed in my career, static page delivery has never been the chokepoint. Not even once. Even a sluggish web server can easily saturate a typical network connection serving just static content.
Besides, few web sites ever register that much traffic. Look at Apache's server status sometime. At the moment, it's pushing 1.2 MB/sec, and the CPU load isn't even close to the single digits.
As nifty and cool as Tux seems, I have a fear it wasn't created to solve real problems, but to win benchmarks.
Uhh... no. Windows (NT and 2000 -- I'm not even considering Win9x here) can actually be considered more secure than Linux (assuming both machines are properly setup by knowledgeable administrators), as it's more difficult to run code remotely on an NT box. As for the virus problem, the only reason it exists is because Windows is vastly more popular than pretty much anything else. As we've seen in the past few months, even Linux can have "virii" (well, worms, but still...).
As long as we're wandering off topic, I wish you hadn't said this because while most of the rest of your post is pretty coherent and reasonable, this paragraph is rubbish.
It's more difficult to run code remotely on NT? How so? Sure, NT ships with fewer services. It's about the same as if you install Red Hat with the workstation option... no inetd, so no telnetd, ftpd, etc. Surely any good admin will eliminate unwanted services anyway.
Anyway, buffer overruns are one form of remote execution, and NT has seen its share of those.
The virii problem largely has to do with two factors, neither related to the popularity of either system. First, Windows configurations are promiscuous by default. How many Windows users operate with the equivalent of Administrator privileges, so they can write to C:\WINNT, their boot sector, etc? Most of them, compared to Linux users, I'd bet. Second, Windows applications are notorious for macro viruses. That's not a defect of the OS per se but in reality the OS and major applications must be considered together. It's certainly likely that Linux apps can/will be vulnerable to the same, but they are less likely to do as much damage.
I'm not interested in the least just how secure Windows/Linux can be made with extensive customization, I'm more concerned with how they are installed in real life since that's how viruses spread: through the majority of users. And both Windows and Linux have achieved critical mass to propogate a worm or virus quickly, whenever a vulnerability becomes widely known.
However, I'm not in agreement that not being able to hold state with global variables is a negative feature of the language. That sounds like a really bad idea considering most app servers are load balanced, and I highly doubt Java can read the memory across machine boundaries.
Shared memory is generally useful regardless of load balancing. We operate sites that employ object-level persistence to read content published from a relational database. With a shared object cache we get rougly 100x the throughput than if each request must query the database.
You make some implicit claims that Java is faster than VB, yet I've never seen this backed up with benchmarks.
It's really impossible to make such a sweeping generalization. I think one could engineer benchmarks that "prove" that any one of Java, VB, Perl, PHP is "fastest". In truth it's hard to make any meaningful objective comparisons, since the programming environments are almost completely different, and the same application would be architected differently for Java or Microsoft runtimes. Doing it right would nearly double or engineering costs.
Slashdot Mirror
For whatever else you ahve to say about Intel, they do know how to write a good compiler.
A good x86 compiler, yes. They haven't proven they can repeat that success on anything else.
The compiler team that came over from Compaq may be able to help considerably though.
We stopped using CF because it was slow and fragile. 4.5 was a disaster, Allaire should never have released it. Doubtless MX is much better, but it's too late for us.
/incl/check_access.cfm then I can request http://somedomain.com/incl/check_access.cfm from a browser and see what happens... more often than not an error message will appear, but I've seen sites hacked that way. Templates that are not intended to be pages simply shouldn't be in the document root. (On any
Regarding the user directories, a problem inherent in CF (and ASP, PHP, JSP) is that included pages can be requested from a browser. That is, if login.cfm includes
You can get around that on ColdFusion by naming included files with an absolute path, and configuring the template path in CF administrator. But that doesn't completely solve your problem.
Well, something's gotta give... I've worked several places now where I've seen IT spending grow almost without bound over the past 5 years, both in terms of staff & technology.
I hold that this is ridiculous, the technology is supposed to reduce staffing costs, yet for all of the "progress" in this industry IT costs have risen sharply for many.
At my present job (for a very small outfit) I've chosen to use staffing as the benchmark: if I have to hire more help, the solution is too complex.
Simplify. Reject ridiculous, complicated software. Build on things that work. Throw away things that don't. This ain't rocket science, and never was.
Software houses have been awfully busy for the past 30 years or so, and free software hasn't stood still either. If you need some package it's already out there. I would say software has become commoditized, but that's not really true, because even commodities have a manufacturing cost.
It's very rare nowadays that I come across a problem that hasn't already been solved somewhere, sometime, by someone. Writing more software seems wasteful to me.
What I do find useful is new ways to combine and use old software... sometimes that means new code, but usually it means modifying code... and BTW open source really helps there.
My customers have never asked me to write software, they ask everyday for solutions, because they don't have the expertise to use what they already own. Don't underestimate the potential of the service market there. It's not about a subscription model. Think of me as the Maytag man... when somebody has a need or problem they call. They're free to use the systems they own until eternity. The more complex the system, the more they call... and boy oh boy is software complex these days.
The shrinkwrapped market is almost gone... mostly games left, that I can see.
Fascinating. Not that it matters anymore, but I repeatedly had trouble with @Home's network. The people I called in support (and friends I asked) never figured it out. I had to disable DHCP to even operate. Here's what I did.
/sbin/arp would just say "".
From time to time, I'd lose my Internet connection. A little investigation showed that I could see other customers on my local subnet, but couldn't reach the gateway. No response from ping, and
If I called tech support they would somehow connect to my modem to investigate the problem, and everything would start to work... until my arp cache expired, that is. After a few calls they assigned me to a new IP address on a different subnet. It worked for a while.
Resetting the modem, restarting the computer, etc. never helped, so I tried disabling DHCP and setting my gateway address to another customer's modem. That would work, so apparently the modems were willing to route arbitrary IP traffic.
This would go for weeks until the gateway address suddenly became reachable again.
Interesting that every tech support person I spoke to seemed to know less about networking than I did. One guy was impressed that I ran Linux, though... he gave me the company line about non-supports OSes but I managed to convince him that it was a better OS for network diagnostics (tcpdump, etc.)
(The modem installers didn't say a word about my Alpha/NT machine, though they were visibly confused when it refused to run their @Home CD software... heh.)
Good bye, @Home... I won't miss you.
First of all, POWER4 is certainly not a derivative of PPC. There are significant differences between the two.
/. when they have no idea what they are saying?)
"PPC is the cleanest Risc architecture"
For whatever definition of "clean", the closest were probably research chips like the original MIPS or predecessor of SPARC. PPC has quite a bit of extra baggage, not a fatal flaw by any means but hardly merits your description.
"IBM's design expertise and manufacturing prowress guarantees it will stomp on the competition."
LOL. If that were any guarantee of anything, history would be very different (for one thing, Digital would probably still be a company, and Intel would've vanished years ago).
"VLIW in and of itself has not come into the stage where it is a good design concept it is not mature enough."
And it may never. VLIW seemed like a pretty good idea 10 or so years ago, when processor speeds were still under 100MHz. But things have changed, and there is a whole new set of problems VLIW isn't prepared to solve.
"...Intel is retarded for not just buying the Alpha processor cleaning up the instruction set..."
Alpha was probably the cleanest commercial RISC processor. It was certainly minimalistic, giving the compiler freedom to optimize code.
Intel on the other hand is not exactly known for clean instruction sets. So what exactly would you propose they do to Alpha?
(*sigh* why do people keep posting bs to
Because there are better ways to use die space? SMP isn't all that beneficial for general-purpose use. At least not now that processor technology has greatly outrun memory technology.
There are of course applications that can greatly benefit from 4x and higher SMP, but they are comparatively few, and not a huge market to the likes of Intel. Compare that to the benefits of additional cache; almost everybody can use a larger, on-die L2 cache.
Consider that these are mass-market low-margin products and you have your answer. If you want massive SMP, there are other companies who'd love to help you.
Is the Power4 really available yet?
In the pSeries 690, if you've got $500,000 or so to spend.
Although the Power architecture spawned the PowerPC I very much doubt that Apple will use them?
The Power4 will trickle down into smaller packages, though not necessarily one you or I can afford... though we'll surely see some major upgrades in the PowerPC series during 2002-2003.
Unfortunately, Apple does not seem serious about servers, nor are they giving any real indication of changing that attitude.
For servers, small RS6000 boxes running AIX or Linux are probably the best bet (at least in Power/PPC hardware).
You're probably thinking of RDRAM.
SRM usually loads a secondary bootstrap loader, e.g. aboot, which understands ext2 filesystems. So this isn't a real limitation.
Reasons SRM is better than a PC BIOS:
1) It understands a serial console
2) It can boot over a network (using bootp/tftp)
3) SRM has no artificial limitations on memory size (as in x86 real mode).
I have a Alpha 164LX motherboard in a case with Ethernet and memory... no floppy, hard disk, video, keyboard or mouse. Still it can boot onto the network and run web servers, etc.
Of course Open Firmware can do the same...
21164A (aka EV56) also added byte-word extensions.
The original Alpha had no instructions to read/write anything smaller than 32-bits to/from memory. That had some interesting consequences, like sparse addressing for video framebuffers, requiring far more virtual memory than other CPUs (note that VM isn't exactly free due to page table overhead and TLB misses).
RISC is absolutely not outdated; the principles behind RISC (pipelining, superscalar execution, etc.) have been embraced by nearly all CPU manufacturers, including IBM, HP, Sun, Compaq, AMD and Intel.
Only Intel's EPIC is a standout from a design standpoint... time will tell whether they made a mistake.
Almost all modern apps require x-86 extensions such as MMX, SSE, and 3dNow, which Alphas do not support.
Modern apps like Mozilla, GCC, Linux? Heck no. These run fine on Alpha.
These "extensions" are mostly workarounds for deficient floating-point in the x86. They are very specific to x86 and irrelevant to any other ISA. (There are also vector extensions, which are supported on Alpha EV6 and up as the MVI extension.)
X86 machines are sleek and smoothe like a Porche because they use brilliant engineering and specialised extensions like SSE.
Boy have you been brainwashed. x86 has a butt-ugly ISA dating from the 1970's that only its mother could love. Alpha, PPC and SPARC (to some extent) are all redesigns that cure a lot of the problems in x86.
Intel's 32-bit chips continue to thrive due to marketing, not technology.
The UltraSparc line brings lots to the table and even IA-64 has some redeeming qualities.
Sadly, the current US-III and Merced are no match for Alpha, yet. Look up SPEC if like. The POWER4 is currently the performance king; McKinley has a lot to prove.
The UP1500 was developed long before the Compaq/Intel Alphacide... it is not clear whether Samsung has any intention of continuing to support Alpha.
gcj 3.0 implements a great deal of 1.2. It's lacking AWT/Swing and RMI. The latter will be in 3.1.
Absolutely correct. Sun is touting J2EE as the solution for everything. In fact it is vast overkill for the majority of web applications.
In fact I have yet to find the "killer application" for EJB.
It's not quite that simple. They've tweaked the inliner a bit, since g++ 3.0 compile times are sometimes hideously slow. Only the default is changed.
It doesn't necessarily produce slower code. Over-aggressive inlining can also be detrimental to execution time. The current limit is an attempt to compromise until better inliner heuristics are found.
The issue has been discussed at length in the GCC archives.
Did you forget:
1) gzip (small but important)
2) bash (OK, ksh93 is an alternative)
3) emacs
4) autotools (autoconf/automake/libtool)
5) fileutils (yes there are other sources for these but when you get used to "cp -a" etc., well...)
...and so on. Believe me, I thought when I first tried to GNU-ify Solaris I'd only be porting a few packages.
Anyway, the Cygwin runtime really consists of both the Cygwin DLL and newlib. The latter isn't Red Hat software, nor is it GPL. The real role of Cygwin is to provide a POSIX interface, something that's done by Linux elsewhere.
Ah, yes, of course... I take that sort of thing for granted, since I often develop on Solaris. I have to install my fat GNU package before Solaris is useable at all (by then it is almost indistinguishable from GNU/Linux).
That said, I recently installed the full suite of Cygwin tools on my Win2K development machine, and it gave me a slightly different perspective on the Linux vs. GNU/Linux debate.
How so? Are you referring to the similarities between Cygwin and GNU/Linux or something else?
In addition, I beleive that the Itanium CPU itself does no real optimization of the instructions, such as common subexpression elimination, loop unrolling, etc. Instead it relies on the compiler to create highly optimized code.
CSE and loop unrolling are high-level optimizations left to the compiler. Show me any processor that can do these on chip.
Anyway, IA-64 and US-III have one thing in common, they are both in-order processors, so both are very sensitive to instruction scheduling in the compiler.
For all the web sites I've managed in my career, static page delivery has never been the chokepoint. Not even once. Even a sluggish web server can easily saturate a typical network connection serving just static content.
Besides, few web sites ever register that much traffic. Look at Apache's server status sometime. At the moment, it's pushing 1.2 MB/sec, and the CPU load isn't even close to the single digits.
As nifty and cool as Tux seems, I have a fear it wasn't created to solve real problems, but to win benchmarks.
Uhh ... no. Windows (NT and 2000 -- I'm not even considering Win9x here) can actually be considered more secure than Linux (assuming both machines are properly setup by knowledgeable administrators), as it's more difficult to run code remotely on an NT box. As for the virus problem, the only reason it exists is because Windows is vastly more popular than pretty much anything else. As we've seen in the past few months, even Linux can have "virii" (well, worms, but still ...).
As long as we're wandering off topic, I wish you hadn't said this because while most of the rest of your post is pretty coherent and reasonable, this paragraph is rubbish.
It's more difficult to run code remotely on NT? How so? Sure, NT ships with fewer services. It's about the same as if you install Red Hat with the workstation option... no inetd, so no telnetd, ftpd, etc. Surely any good admin will eliminate unwanted services anyway.
Anyway, buffer overruns are one form of remote execution, and NT has seen its share of those.
The virii problem largely has to do with two factors, neither related to the popularity of either system. First, Windows configurations are promiscuous by default. How many Windows users operate with the equivalent of Administrator privileges, so they can write to C:\WINNT, their boot sector, etc? Most of them, compared to Linux users, I'd bet. Second, Windows applications are notorious for macro viruses. That's not a defect of the OS per se but in reality the OS and major applications must be considered together. It's certainly likely that Linux apps can/will be vulnerable to the same, but they are less likely to do as much damage.
I'm not interested in the least just how secure Windows/Linux can be made with extensive customization, I'm more concerned with how they are installed in real life since that's how viruses spread: through the majority of users. And both Windows and Linux have achieved critical mass to propogate a worm or virus quickly, whenever a vulnerability becomes widely known.
However, I'm not in agreement that not being able to hold state with global variables is a negative feature of the language. That sounds like a really bad idea considering most app servers are load balanced, and I highly doubt Java can read the memory across machine boundaries.
Shared memory is generally useful regardless of load balancing. We operate sites that employ object-level persistence to read content published from a relational database. With a shared object cache we get rougly 100x the throughput than if each request must query the database.
You make some implicit claims that Java is faster than VB, yet I've never seen this backed up with benchmarks.
It's really impossible to make such a sweeping generalization. I think one could engineer benchmarks that "prove" that any one of Java, VB, Perl, PHP is "fastest". In truth it's hard to make any meaningful objective comparisons, since the programming environments are almost completely different, and the same application would be architected differently for Java or Microsoft runtimes. Doing it right would nearly double or engineering costs.