2. Multiple sources - yes. And the OpenBSD software was written completely by a small team? Sounds more like an "argument" for closed source groups rather than promoting the OpenBSD auditing efforts. Fortunately, the findings of OpenBSD also benefit other freeware O/S.
3. How do you think Linux distributions are created? If you are so hot on having packages, you can get your packages only from one source (i.e. the distributor). Think of xBSD as one distributor who happens to maintain all the software he distributes. You really don't need to poke around ftp sites to get software for Linux. Really, you don't.
4. Linux isn't focussed on the desktop, even if many BSD people claim to be it so. Some distributors are out for the money of the masses and that happens to be the desktop. That's true. As a counter example, Caldere developed a whole suite of Netware software for Linux, software which is targeted at the server market.
More opinions of yours:
Because it is easier to install and maintain than Linux
"The Linux" doesn't exist. You seem to be confused about this point completely.
Its development is less chaotic, and I worry less about it.
Hu? If you are not worried about development, why do you care about it at all? You seem to refer to the core team, the king of kings (ah, committers), the elite, etc. Again, imagine how controlled development in Redmond is.
And then comes more blabla.
The final note (at least you didn't say Linux there) is also not that intelligent - see the ongoing thread about UIs and installations on freebsd-hackers and you will see what I mean.
NFS v3 is (to quote Alan Cox) "NFS done right." Unfortunately, it's still a long way until NFSv3 will be available in the free OSs.
There are some environments which need networked filesystems. If NFS is the only thing every OS in their environment supports, they have to live with it.
And how is this bad?
Where did I say that it's bad? I only said what you can do. Don't imply things you cannot prove.
NetBSD automatically detected and used UDMA. MAXUSERS was set to 64, the highest numbers possible.
But thanks for the sysctl:-) I'll try it the next time. I already wondered why NetBSD was trashing the disk, even as I had mounted the partition async.
For the curious, here is the config file. There are probably errors now that I've edited it under FreeBSD and didn't run it through config...
include "arch/i386/conf/std.i386" maxusers 64 # estimated number of users options I586_CPU options MATH_EMULATE # floating point emulation options USER_LDT # user-settable LDT; used by WINE options DUMMY_NOPS options XSERVER # X server support in console drivers options UCONSOLE # users can use TIOCCONS (for xconsole) options INSECURE # disable kernel security levels options RTC_OFFSET=0 # hardware clock is this many mins. west of GMT options NTP # NTP phase/frequency locked loop options KTRACE # system call tracing via ktrace(1) options SYSVMSG # System V-like message queues options SYSVSEM # System V-like semaphores options SYSVSHM # System V-like memory sharing options LKM # loadable kernel modules options DIAGNOSTIC # cheap kernel consistency checks options DDB # in-kernel debugger options COMPAT_12 # NetBSD 1.2, options COMPAT_13 # NetBSD 1.3, options COMPAT_386BSD_MBRPART # recognize old partition ID options COMPAT_SVR4 # binary compatibility with SVR4 options COMPAT_IBCS2 # binary compatibility with SCO and ISC options COMPAT_LINUX # binary compatibility with Linux options COMPAT_FREEBSD # binary compatibility with FreeBSD options EXEC_ELF32 # 32-bit ELF executables (SVR4, Linux) file-system FFS # UFS file-system EXT2FS # second extended file system (linux) file-system NFS # Network File System client file-system CD9660 # ISO 9660 + Rock Ridge file system file-system MSDOSFS # MS-DOS file system file-system FDESC #/dev/fd file-system KERNFS #/kern file-system NULLFS # loopback file system file-system PROCFS #/proc options QUOTA # UFS quotas options NFSSERVER # Network File System server # immutable) behave as system flags. options GATEWAY # packet forwarding options INET # IP + ICMP + TCP + UDP options ISO,TPIP # OSI options PCIVERBOSE # verbose PCI device autoconfig messages options WSEMUL_VT100 # VT100 / VT220 emulation options WS_KERNEL_FG=WSCOL_GREEN options WSDISPLAY_COMPAT_PCVT # emulate some ioctls options WSDISPLAY_COMPAT_SYSCONS # emulate some ioctls options WSDISPLAY_COMPAT_USL # VT handling options WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes options PCKBD_LAYOUT="(KB_DE | KB_NODEAD)" options WSDISPLAY_DEFAULTSCREENS=4 config netbsd root on ? type ? mainbus0 at root pci* at mainbus? bus ? pci* at pchb? bus ? pci* at ppb? bus ? pchb* at pci? dev ? function ? # PCI-Host bridges pcib* at pci? dev ? function ? # PCI-ISA bridges ppb* at pci? dev ? function ? # PCI-PCI bridges puc* at pci? dev ? function ? # PCI "universal" comm. cards isa* at mainbus?
isa* at pcib? isapnp0 at isa? pcic* at isapnp? npx0 at isa? port 0xf0 irq 13 # x86 math coprocessor options GERMAN_KBD pckbc0 at isa? # pc keyboard controller pckbd* at pckbc? # PC keyboard vga* at pci? wsdisplay* at vga? console ? wskbd* at pckbd? console ? pcppi0 at isa? sysbeep0 at pcppi? com* at isapnp? # Modems and serial boards com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports com1 at isa? port 0x2f8 irq 3 lpt* at puc? port ? # || ports on "universal" comm boards lpt0 at isa? port 0x378 irq 7 # standard PC parallel ports pciide* at pci ? dev ? function ? flags 0x0000 wdc* at isapnp? wdc0 at isa? port 0x1f0 irq 14 wdc1 at isa? port 0x170 irq 15 wd* at wdc? channel ? drive ? flags 0x0000 wd* at pciide? channel ? drive ? flags 0x0000 atapibus* at wdc? channel ? atapibus* at pciide? channel ? cd* at atapibus? drive ? flags 0x0000 # ATAPI CD-ROM drives fdc0 at isa? port 0x3f0 irq 6 drq 2 # standard PC floppy controllers fd* at fdc? drive ? # the drives themselves ne* at isapnp? # NE2000-compatible Ethernet sb0 at isa? port 0x220 irq 5 drq 1 drq2 5 # SoundBlaster opl* at sb? audio* at sb? midi* at sb? # SB MPU401 port pseudo-device ccd 4 # concatenated/striped disk devices pseudo-device md 1 # memory disk device (ramdisk) pseudo-device bpfilter 8 # Berkeley packet filter pseudo-device ipfilter # IP filter (firewall) and NAT pseudo-device loop # network loopback pseudo-device ppp 2 # Point-to-Point Protocol pseudo-device tun 2 # network tunneling over tty pseudo-device pty 64 # pseudo-terminals pseudo-device sequencer 1 # MIDI sequencer pseudo-device rnd #/dev/random and in-kernel generator options AVM_A1 isic0 at isa? port 0x340 irq 12 pseudo-device "i4b" pseudo-device "i4btrc" 2 pseudo-device "i4bctl" pseudo-device "i4brbch" 4 pseudo-device "i4btel" 2 options IPR_VJ # compile support for VJ compression pseudo-device "i4bipr" 2 pseudo-device "i4bisppp" 4
NT is theoretically a mini kernel. This means, the kernel provides only the minimal amount of services, everything else is done in subprocesses. This provides an easy way to scale on multiple processors without all these problems normal kernels have to cope with (fine grained locking).
SunOS isn't a mini kernel. But they have gone through the trouble of making their system actually scale better than NT currently does.
As a side note, this does apply only to some of the core team. There are exceptions - JKH comes to my mind. He seems to be more balanced than most other "hackers."
Being also on several Linux lists I haven't seen anyone trashing BSD in this form. Trashing Linux for non-reasons seems to be "cool" in BSD-land.
Show me the person who worked on the first TCP/IP stack and who is still on the FreeBSD core team.
FreeBSD has very old, clumsy code. Matthew Dillon (FreeBSD coder) put it so:
I like to call it "algorithmic rot". In otherwords, after a decade or two the kernel just isn't the squeeky clean implementation it could be. I get screamed at a lot when I try to clean the rot up, because half the time it involves not only documenting code but also rewriting routines that don't actually contain bugs in order to prevent future rot. Kinda like wood sealer. The KASSERT()s work that way too. You put them in to force out the bugs and to prevent new ones from entering.
And now show me any FreeBSD system which isn't vulnerable against DoS attacks. I hope, you don't run any email server.
In my experiance (I have a dual celeron at home) freebsd is as good, or perhaps better than linux when it comes to SMP.
There are some old land lords in the FreeBSD team who claim that the global kernel lock would be enough for superior SMP support.
Terry Lambert, old advocacy freak, once wrote that neither, Linux nor FreeBSD would ever support SMP as systems designed from the ground up.
Yeah, sure, Solaris will never beat NT.
Solaris scales up to 64 processors (in reality). NT, the New Technology OS, scales up to 16 processors (in marketing). Solaris is so much "worse," because it wasn't designed with SMP in mind.
The recent benchmarks have shown that the lack of a multithreaded network stack in Linux lead to a win for NT (no pun intended) when dealing with multiple NICs. That also obviously demonstrates that a global kernel lock cannot suffice.
Currently, Linux fine grained locking in 2.3 is superior than that of FreeBSD 4.0-current. Let's see whether FreeBSD will catch up.
I've posted on a previous thread about deficiences in the NetBSD scheduler/vm subsystem, but the whole thread has disappeared now - the main page shows "35 of 36 comments," even if I have set my threshhold to show -1 rated comments.
If you would know your way around Unix systems, you would know that at this very second Linux' knfsd is extended and debugged (see linux-kernel).
Note also that FreeBSD has some severe problems with NFS: Search on freebsd-hackers to find all the gory details (and that the main hacker working on it lost his commit rights due to personal differences with a core team member).
smbfs isn't supported on FreeBSD, that's right. But smbclient is, of course.
RAID is supported by both, each team claims to have better support, so I won't try to judge it. FreeBSD has a new SCSI subsystem which I always wanted to try (called CAM).
About the TCP/IP point: Yes, the Linux network code has been worse than FreeBSD's for some time. But it improved at a pace you wouldn't believe.
SysV-ish init system: That's a personal opinion. Search freebsd-questions and -hackers for this thread - it comes up almost every sunday.
There could be possibly a new distro based on FreeBSD. You could even sell it and not give away your source code, thanks to the BSD license.
What I dislike NetBSD for is the sluggish response time. I've tried the new NetBSD 1.4 with its new UVM system, but response-wise it looks like 1.3.
How to repeat: Start three compiling batches (you may even nice them to 5) and watch the response time (I tried console and ssh) drop off. I've never seen this behaviour on FreeBSD, Linux, and Solaris, systems I work with daily. A login takes several seconds at that time.
Anyone want to give me any hints? The system in question ran on a P200/96MB RAM, self-compiled kernel (tweaked GENERIC + i4b). Otherwise, I used only stock tools.
The system ran FreeBSD 2.2.x, 3.x and several Linux versions already, so I know that better response times are possible on exactly the same hardware.
PHP isn't limited to MySQL. In fact, it supports about 15 RDBMs, can talk via ODBC and access several non-relational databases. So, the question isn't about choosing a database.
Define 'real' programming language. PHP4, the successor to PHP3, is completely backwards compatible while increasing the speed of scripts and compiled binaries (not stand-alone) considerably. In fact, it's often magnitudes faster than the current PHP3.
There are discussions going on on the php developers list to make JNI accessible from within PHP. In effect, you could write your Java beans or whatever as usual and use them from PHP. That way you could take full advantage of the rapid prototyping capabilities of PHP.
If you don't want to mix up HTML and PHP, use FastTemplates. I've written some apps for clients using that thing, it completely seperates code from HTML. The average size of these apps is about 10000 lines (wc -l) of PHP code. Maintaining and enhancing it would be a nightmare, if I would have to deal with the designer's HTML stuff.
Slashdot Mirror
Not that this would be really important ...
OpenBSD was derived from NetBSD and still shares most of NetBSD's "artifacts."
Ever tried to login and do work on that machine when the load was higher than two? Could that feeling be described with "sluggish?"
2. Multiple sources - yes. And the OpenBSD software was written completely by a small team? Sounds more like an "argument" for closed source groups rather than promoting the OpenBSD auditing efforts. Fortunately, the findings of OpenBSD also benefit other freeware O/S.
3. How do you think Linux distributions are created? If you are so hot on having packages, you can get your packages only from one source (i.e. the distributor). Think of xBSD as one distributor who happens to maintain all the software he distributes. You really don't need to poke around ftp sites to get software for Linux. Really, you don't.
4. Linux isn't focussed on the desktop, even if many BSD people claim to be it so. Some distributors are out for the money of the masses and that happens to be the desktop. That's true. As a counter example, Caldere developed a whole suite of Netware software for Linux, software which is targeted at the server market.
More opinions of yours:
Because it is easier to install and maintain than Linux
"The Linux" doesn't exist. You seem to be confused about this point completely.
Its development is less chaotic, and I worry less about it.
Hu? If you are not worried about development, why do you care about it at all? You seem to refer to the core team, the king of kings (ah, committers), the elite, etc. Again, imagine how controlled development in Redmond is.
And then comes more blabla.
The final note (at least you didn't say Linux there) is also not that intelligent - see the ongoing thread about UIs and installations on freebsd-hackers and you will see what I mean.
NFS is an insecure and scary way of doing things.
NFS v3 is (to quote Alan Cox) "NFS done right." Unfortunately, it's still a long way until NFSv3 will be available in the free OSs.
There are some environments which need networked filesystems. If NFS is the only thing every OS in their environment supports, they have to live with it.
And how is this bad?
Where did I say that it's bad? I only said what you can do. Don't imply things you cannot prove.
No rc5des, no seti@home.
:-) I'll try it the next time. I already wondered why NetBSD was trashing the disk, even as I had mounted the partition async.
...
/dev/fd /kern /proc
/dev/random and in-kernel generator
NetBSD automatically detected and used UDMA. MAXUSERS was set to 64, the highest numbers possible.
But thanks for the sysctl
For the curious, here is the config file. There are probably errors now that I've edited it under FreeBSD and didn't run it through config
include "arch/i386/conf/std.i386"
maxusers 64 # estimated number of users
options I586_CPU
options MATH_EMULATE # floating point emulation
options USER_LDT # user-settable LDT; used by WINE
options DUMMY_NOPS
options XSERVER # X server support in console drivers
options UCONSOLE # users can use TIOCCONS (for xconsole)
options INSECURE # disable kernel security levels
options RTC_OFFSET=0 # hardware clock is this many mins. west of GMT
options NTP # NTP phase/frequency locked loop
options KTRACE # system call tracing via ktrace(1)
options SYSVMSG # System V-like message queues
options SYSVSEM # System V-like semaphores
options SYSVSHM # System V-like memory sharing
options LKM # loadable kernel modules
options DIAGNOSTIC # cheap kernel consistency checks
options DDB # in-kernel debugger
options COMPAT_12 # NetBSD 1.2,
options COMPAT_13 # NetBSD 1.3,
options COMPAT_386BSD_MBRPART # recognize old partition ID
options COMPAT_SVR4 # binary compatibility with SVR4
options COMPAT_IBCS2 # binary compatibility with SCO and ISC
options COMPAT_LINUX # binary compatibility with Linux
options COMPAT_FREEBSD # binary compatibility with FreeBSD
options EXEC_ELF32 # 32-bit ELF executables (SVR4, Linux)
file-system FFS # UFS
file-system EXT2FS # second extended file system (linux)
file-system NFS # Network File System client
file-system CD9660 # ISO 9660 + Rock Ridge file system
file-system MSDOSFS # MS-DOS file system
file-system FDESC #
file-system KERNFS #
file-system NULLFS # loopback file system
file-system PROCFS #
options QUOTA # UFS quotas
options NFSSERVER # Network File System server
# immutable) behave as system flags.
options GATEWAY # packet forwarding
options INET # IP + ICMP + TCP + UDP
options ISO,TPIP # OSI
options PCIVERBOSE # verbose PCI device autoconfig messages
options WSEMUL_VT100 # VT100 / VT220 emulation
options WS_KERNEL_FG=WSCOL_GREEN
options WSDISPLAY_COMPAT_PCVT # emulate some ioctls
options WSDISPLAY_COMPAT_SYSCONS # emulate some ioctls
options WSDISPLAY_COMPAT_USL # VT handling
options WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes
options PCKBD_LAYOUT="(KB_DE | KB_NODEAD)"
options WSDISPLAY_DEFAULTSCREENS=4
config netbsd root on ? type ?
mainbus0 at root
pci* at mainbus? bus ?
pci* at pchb? bus ?
pci* at ppb? bus ?
pchb* at pci? dev ? function ? # PCI-Host bridges
pcib* at pci? dev ? function ? # PCI-ISA bridges
ppb* at pci? dev ? function ? # PCI-PCI bridges
puc* at pci? dev ? function ? # PCI "universal" comm. cards
isa* at mainbus?
isa* at pcib?
isapnp0 at isa?
pcic* at isapnp?
npx0 at isa? port 0xf0 irq 13 # x86 math coprocessor
options GERMAN_KBD
pckbc0 at isa? # pc keyboard controller
pckbd* at pckbc? # PC keyboard
vga* at pci?
wsdisplay* at vga? console ?
wskbd* at pckbd? console ?
pcppi0 at isa?
sysbeep0 at pcppi?
com* at isapnp? # Modems and serial boards
com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports
com1 at isa? port 0x2f8 irq 3
lpt* at puc? port ? # || ports on "universal" comm boards
lpt0 at isa? port 0x378 irq 7 # standard PC parallel ports
pciide* at pci ? dev ? function ? flags 0x0000
wdc* at isapnp?
wdc0 at isa? port 0x1f0 irq 14
wdc1 at isa? port 0x170 irq 15
wd* at wdc? channel ? drive ? flags 0x0000
wd* at pciide? channel ? drive ? flags 0x0000
atapibus* at wdc? channel ?
atapibus* at pciide? channel ?
cd* at atapibus? drive ? flags 0x0000 # ATAPI CD-ROM drives
fdc0 at isa? port 0x3f0 irq 6 drq 2 # standard PC floppy controllers
fd* at fdc? drive ? # the drives themselves
ne* at isapnp? # NE2000-compatible Ethernet
sb0 at isa? port 0x220 irq 5 drq 1 drq2 5 # SoundBlaster
opl* at sb?
audio* at sb?
midi* at sb? # SB MPU401 port
pseudo-device ccd 4 # concatenated/striped disk devices
pseudo-device md 1 # memory disk device (ramdisk)
pseudo-device bpfilter 8 # Berkeley packet filter
pseudo-device ipfilter # IP filter (firewall) and NAT
pseudo-device loop # network loopback
pseudo-device ppp 2 # Point-to-Point Protocol
pseudo-device tun 2 # network tunneling over tty
pseudo-device pty 64 # pseudo-terminals
pseudo-device sequencer 1 # MIDI sequencer
pseudo-device rnd #
options AVM_A1
isic0 at isa? port 0x340 irq 12
pseudo-device "i4b"
pseudo-device "i4btrc" 2
pseudo-device "i4bctl"
pseudo-device "i4brbch" 4
pseudo-device "i4btel" 2
options IPR_VJ # compile support for VJ compression
pseudo-device "i4bipr" 2
pseudo-device "i4bisppp" 4
So, you want to dismiss Matthew Dillon's comment completely? He was the one who fixed FreeBSD's NFS problems.
Design != implementation. I think I mentioned this already.
I'll assume this to mean that FreeBSD should work with a System V init without any major problems (should someone wish to undertake such
:-)
a project)
Correct. But I never had problems with rc.conf
Nope, you misunderstood me.
NT is theoretically a mini kernel. This means, the kernel provides only the minimal amount of services, everything else is done in subprocesses.
This provides an easy way to scale on multiple processors without all these problems normal kernels have to cope with (fine grained locking).
SunOS isn't a mini kernel. But they have gone through the trouble of making their system actually scale better than NT currently does.
Do you see now what I've meant with "design?"
As a side note, this does apply only to some of the core team. There are exceptions - JKH comes to my mind. He seems to be more balanced than most other "hackers."
Being also on several Linux lists I haven't seen anyone trashing BSD in this form. Trashing Linux for non-reasons seems to be "cool" in BSD-land.
That's normal. I catched me three or four times hitting CTRL-C to not send rants to freebsd-hackers about their limited mind sets.
People who mention this are constantly flamed at by always the same people (no, I won't name any particular names).
If it would happen only on -advocacy, I wouldn't care. But if it's on a list dedicated to _technical_ issues, it just pisses me off.
Define "serving huge mission critical projects."
Show me the person who worked on the first TCP/IP stack and who is still on the FreeBSD core team.
FreeBSD has very old, clumsy code. Matthew Dillon (FreeBSD coder) put it so:
I like to call it "algorithmic rot". In otherwords, after a decade or
two the kernel just isn't the squeeky clean implementation it could be.
I get screamed at a lot when I try to clean the rot up, because half the
time it involves not only documenting code but also rewriting routines
that don't actually contain bugs in order to prevent future rot. Kinda
like wood sealer. The KASSERT()s work that way too. You put them in to
force out the bugs and to prevent new ones from entering.
And now show me any FreeBSD system which isn't vulnerable against DoS attacks. I hope, you don't run any email server.
-SMP: not so good
In my experiance (I have a dual celeron at home) freebsd is as good, or perhaps better than linux when it comes to SMP.
There are some old land lords in the FreeBSD team who claim that the global kernel lock would be enough for superior SMP support.
Terry Lambert, old advocacy freak, once wrote that neither, Linux nor FreeBSD would ever support SMP as systems designed from the ground up.
Yeah, sure, Solaris will never beat NT.
Solaris scales up to 64 processors (in reality). NT, the New Technology OS, scales up to 16 processors (in marketing). Solaris is so much "worse," because it wasn't designed with SMP in mind.
The recent benchmarks have shown that the lack of a multithreaded network stack in Linux lead to a win for NT (no pun intended) when dealing with multiple NICs. That also obviously demonstrates that a global kernel lock cannot suffice.
Currently, Linux fine grained locking in 2.3 is superior than that of FreeBSD 4.0-current. Let's see whether FreeBSD will catch up.
Any speed benchmarks? Sharity-light seems to be userland only. And we both know why NFS is mostly implemented in kernel-land.
I've posted on a previous thread about deficiences in the NetBSD scheduler/vm subsystem, but the whole thread has disappeared now - the main page shows "35 of 36 comments," even if I have set my threshhold to show -1 rated comments.
Hu?
If you would know your way around Unix systems, you would know that at this very second Linux' knfsd is extended and debugged (see linux-kernel).
Note also that FreeBSD has some severe problems with NFS: Search on freebsd-hackers to find all the gory details (and that the main hacker working on it lost his commit rights due to personal differences with a core team member).
smbfs isn't supported on FreeBSD, that's right. But smbclient is, of course.
RAID is supported by both, each team claims to have better support, so I won't try to judge it. FreeBSD has a new SCSI subsystem which I always wanted to try (called CAM).
About the TCP/IP point: Yes, the Linux network code has been worse than FreeBSD's for some time. But it improved at a pace you wouldn't believe.
SysV-ish init system: That's a personal opinion. Search freebsd-questions and -hackers for this thread - it comes up almost every sunday.
There could be possibly a new distro based on FreeBSD. You could even sell it and not give away your source code, thanks to the BSD license.
What I dislike NetBSD for is the sluggish response time. I've tried the new NetBSD 1.4 with its new UVM system, but response-wise it looks like 1.3.
How to repeat: Start three compiling batches (you may even nice them to 5) and watch the response time (I tried console and ssh) drop off. I've never seen this behaviour on FreeBSD, Linux, and Solaris, systems I work with daily. A login takes several seconds at that time.
Anyone want to give me any hints? The system in question ran on a P200/96MB RAM, self-compiled kernel (tweaked GENERIC + i4b). Otherwise, I used only stock tools.
The system ran FreeBSD 2.2.x, 3.x and several Linux versions already, so I know that better response times are possible on exactly the same hardware.
Try Zope.
Then try PHP.
You won't want to revert to Zope.
PHP isn't limited to MySQL. In fact, it supports about 15 RDBMs, can talk via ODBC and access several non-relational databases. So, the question isn't about choosing a database.
Define 'real' programming language. PHP4, the successor to PHP3, is completely backwards compatible while increasing the speed of scripts and compiled binaries (not stand-alone) considerably. In fact, it's often magnitudes faster than the current PHP3.
There are discussions going on on the php developers list to make JNI accessible from within PHP. In effect, you could write your Java beans or whatever as usual and use them from PHP. That way you could take full advantage of the rapid prototyping capabilities of PHP.
If you don't want to mix up HTML and PHP, use FastTemplates. I've written some apps for clients using that thing, it completely seperates code from HTML. The average size of these apps is about 10000 lines (wc -l) of PHP code. Maintaining and enhancing it would be a nightmare, if I would have to deal with the designer's HTML stuff.
FastTemplate Tutorial
And yes, of course, PHP is not the right tool for every job. The same is true for Java.