I guess the message was clear enough that you feel the need to correct its grammar. But I'm not shure, since I'm agnostic. I'm just not into perpetuating misinterpretations and lies.
Every language can be hard to learn - it depends where you're coming from. I'm a portuguese native speaker (an irregular language with lots of subtle variations and even some adapted foreign terms), so learning spanish (a similar, but somewhat phonetically simpler language) is easy. So it is english or french. German not so much (phrase construction and algutination of terms seems somewhat "unnatural"). Russian seems phonetically similar, but with a different alphabet. And it is a lot easier for a russian or an ucranian to learn portuguese than an englishmen or a dutchmen.
I'd much prefer, say, German over English (but then of course I'm also biased in favor of Indo-European group).
I wouldn't, and I bet a lot of people are with me on this one. Even some germans.
that's Pax Americana, so that language is English, unfortunately
American English. But yeah, you're right on the money.
I sure hope Chinese are not going to be the next to run the world, because their writing system is so crappy English looks like Esperanto in comparison.
Can you explain why (traditional/simplified) chinese is that bad?
You're not going to add a multi-cycle div instruction
You are hilarious. Let's say 15 years is moderately modern - every single x86 chip released in the last 15 years (at least) implements a single-cycle, pairable div instruction, so it's not rocket science. And while they *do* have a complex CISC instruction set, they are all internally decoded to RISC-like operations.
If you can't handle inserting a 13 line macro you shouldn't be writing assembler,
Actually, it is called "assembly", and some *very popular* RISC processors DO implement the instruction (ARMv7, POWER, PowerPC, SH4, etc). Oh, and OpenSPARC? You even have multiple versions of it. We are not in 1990 any more.
if it's not going to buy you anything to put it in the CPU
I did not say that, but the opposite. Having a div instruction (specially if it is a high-performance one, such as the one available since the Pentium line in x86) greatly simplifies software development, and often performs faster than subroutine-based divs. That doesn't stop you from applying the usual tricks and optimizations for the special cases that will benefit from them.
plus that leaves opportunity for optimization in cases where you can make certain assumptions about the numbers you're working with
but the availability of a div instruction doesn't stop you from using whatever optimizations you see fit, as most compilers already do in architectures that do have a div instruction.
I had no experience with Xenix, but given that there was an earlier version for 8086/8088, it probably didn't implement memory protection in the 286 either.
I still have a 8MHz 286 with a couple of 20MB RLL drives.
Windows 3 would even run on the 286, anything that didn't require Win32S usually ran fine.
When Windows 3 was released, high-end i386 workstations were already common. Windows 3 did not use any memory protection features wth 286 (it runned on "real" or "standard" mode). To take advantage of actual memory protection features, you needed a 32 bit processor ("enhanced" mode).
The 68000 wasn't a direct competitor of 8086. It was an high-end cpu, and reached the general public in 1980 (8086 was introduced in 1977). By then, you also had eg, Z8000, that addressed upto 8Mb of Ram, and support for 64-bit registers.
The 68020 processor was released less than a year before than i386, and you could also run 8086/8088/286 code on it. Intel could have easily beated Motorola if they had stopped playing with the i432 architecture, and instead concentrated on x86.
Hyperthreading, an Intel tech, significantly increases speed
It doesn't, at least on earlier processors, where the pipelines are shared between threads. And while an "Intel" trademark, it isn't really new or Intel tech.
There's also a concept of pipelining that allows multiple instructions from a single thread to run staggered as long as they won't collide in their use of a particular component within the CPU
Every x86-compatible CPU designed in the past 10 years has multiple pipelines. It is hardly an Intel concept. And those multiple pipelines are really a RISC core.
Also the icore series can predict the next instruction before it is even loaded
That is a decade-old trick (badly) done in P4, because it led to costly cache invalidations. It's not like "trying to guess", but more like having the predictable execution paths already in cache,
The problem is, a quad-core i5 probably consumes less per core than a dual-core atom consumes per core, but will have much better performance per core. If you increase cache and clockspeed, you will also need more power. That's why Intel is investing heavily in increasing density (reducing consumption) instead of going after the GHz advantage.
hen they didn't stick to that model for the floating point instructions, going with a stack for that. And remember they split the CPU into 2 parts. If you wanted the floating point instructions, you had to get a very expensive matching x87 chip.
... The same as Motorola.(http://en.wikipedia.org/wiki/Motorola_68881). They began to integrate an FPU about the same time (68040/486DX).
Another major bit of ugliness was the segment. Rather than a true 32bit architecture, they used this segmented architecture scheme, then buggered it up even more by having different modes.
You mean, having a 16-bit cpu support a FULL MEGABYTE instead of the usual 64Kb of Ram? In 1979? Pure evil.
In some modes, the segment and address were simply concatenated for a 32bit address space, and in others 12 bits overlapped to give only a 20bit address space. Then you had all this switching and XMS and EMS to access memory above 1M. Nasty.
You do know that XMS memory is just linear memory above real memory, right? And that EMS whas just a PC-compatible paging memory layout, right? Because you seem to lack basic understanding of the architecture.
Few platform segregation points? Maybe, but one price is lots of legacy garbage. x86 still has to support those ancient segmented modes.
Thank god. I can still run FreeDOS.
They're hopelessly obsolete. We have much better algorithms for string search than that.
While the instructions you mentioned are used for string comparison, that's not their sole purpose. They compare bytes. not strings.
We have much better algorithms for string search than that.
Please do tell. Because null detection in a couple of opcodes isn't something easy to come by.
They also screwed up the instructions intended for OS support on the 286.
If you are talking about MMU, they dind't screw up. Nobody cared about 16-bit support.
That's one reason why the lowest common denominator is i386 and not i286. 286 is also only 16bit.
Nobody cared about i386 MMU either, upto Windows 3.0. That's why early versions of 386 were buggy as hell (such as skipping the first GDT entry - yup. it's a 386 bug, not a feature).
Someone mentioned CISC, as if that beat out RISC? It didn't. Under the hood, modern x86 CPUs actually translate each x86 instruction to several RISC instructions. So why not just use the actual RISC instruction set directly? One argument in favor of the x86 instruction set is that it is denser. Takes fewer bytes than the equivalent action in RISC instructions. Perhaps, but that's accidental. If that is such a valuable property, ought to create a new instruction set that is optimized for code density
That is the first thing on your comment that is right on the spot.
Then, as if x86 wasn't CISC enough, they rolled out the MMX, SSE, SSE2, SSE3, SSE4 additions.
...And then you lose it. Vector instructions were a FPU feature (the 487 ITT had it), and Intel also had a peek with their RISC cpus, i860/i960. With the advent of DSPs, this kind of technology came even more common.
That makes a powerful argument in favor of open source. Could drop all the older SSE versions if only all programs could be easily recompiled.
Older programs will run faster on new CPUs. In many cases, they won't take advantage of SSE at all if both the algorithm and the compiler aren't optimized for the use of those instructions.
Superior to x86? Sure there is. x86 is a mish mash of instructions many of which hardly anyone uses except for backwards compatibility, but that still cost real estate on the CPU die
CISC instructions don't take "cpu die" at least since a decade ago. Modern processors translate whatever the opcodes are to "micro-ops" that are executed on the multi-lane, out-of-order (except Atom) RISC pipeline.
The x86 has four general purpose registers. No one in their right mind would design a chip like that today.
Not even Intel. Intel RISC processors have a lot more registers, and while you can also poke holes in their technology, they were the basis of modern Intel processors.The register limitation is more of a backward-compatible move than anything else.
In a modern computer, RAM is significantly slower than registers, so having more registers can give you a large performance boost
Yes and no. RAM is probably a magnitude slower than registers, but it is where your code (the one messing around with registers) lie; Modern processors also have a shorter pipeline than those pesky P4, so they usually have a smaller instruction cache. It all boils down do L1/L2 cache, and some schedulers go to great extent not to trash it, and have your code right there when the processor needs it.
The question isn't whether it's well documented, the question is how well it performs in power/performance.
The question is,can you have a baseline performance index for your product, given an arbitrary vendor. You can't. Not only there is a lot less fragmentation if everything comes from the same provider, but you can only provide consistency if the vendor is the same,
Intel deserves a lot of credit in proving just how far CISC design can go.
Intel also deserves credit for some RISC processors, namely the i860 and the i960. A lot of the effort of the RISC division was later packported to their mainstream CPUs.
I don't know why you keep insisting that I'm not aware of mathematical induction (or any other proof system), but it seems you are not aware of the pitfalls and limitations of TDD.
Well, it seems you already have your mind made, so it's pointless for me to continue to try explaining you again what I already said. I understand where you are coming from (changing from C# to PHP is like going from a ferrari to a trycicle), but don't waste your time calling me "unexperienced". I've been developing software for the past 18 years, ranging from x86 assembly to C#, passing by C, Pascal/Delphi, COBOL/Object Cobol, VB, and even a bit of Java, have worked with somewhat large codebases (the biggest one at my sole responsability were around 300Mb of source), so I do know a thing or two about software development and application lifecycle management. But this is not a pissing contest. If you want to dismiss my opinion or my arguments just because I use PHP and have a poor opinion about both TDD and OOP as the holy grail, it's up to you.
From what I've read (diagonally) from the article, the fork was started by OpenBSD developers. I guess they decided to fork something they already have good knowledge of. FreeBSD internals are quite different, and while NetBSD has some similarities, they have come a long way since the OpenBSD fork.
It has been a while since I tried it, but with X/Xorg you can copy/paste text without an issue and you can copy/paste some kind of specific data (such as images) between applications that use the same toolkit. Everything else (formatted text, vector drawings, files) is a PITA.
Also, I just bought a 15" dell monitor off craigslist yesterday and running stock Debian 6 on a Thinkpad T60, plugged it in and it did mirroring 100% correctly.
So, just because it works for you, it must work for everybody? I had issues with older versions of Ubuntu on a Asus EE900, and with stock gnome you couldn't even click on the "ok" button of the display settings because it went offscreen (1024x600). It is somewhat easy to fix, but not very "user friendly".
Tell MythTV users sound doesn't work reliably.
The other day there was a rant one mile long regarding PulseAudio defects and how it killed low-latency audio in Linux. Many complainers were Linux users.
Five guis are a mess?
There is a consistent lack of consistency, yes. Partially because there is a multitude of toolkits available, and there is no single standard for almost everything. You gain choice, but you lose consistency.
If I apt-get source foobar I can build any debian package on my server and install it on my desktop
Yes, if they are roughly the same version. If they have eg. different glibc versions, you may have problems. And compilation flags in many linux distros can also interfere (try building an i7-optimized binary and run it on a p4), but that may also happen in other operating systems. AFAIK, both PC-BSD and MacOS have a somewhat elegant solution for it.
Documentation is worthless?
Yeah, it is. It is not that rare to find outdated manpages, features that lack documentation, or translation errors. You may not notice it, but if you are used to BSD-style manpages, you will have a shock.
The GNU Emacs Reference manual is like 1000+ pages.
Since Emacs isn't really part of the "base system", the manpages for Emacs are the same regardless of the operating system. I'm not familiarized with it, but size isn't really a quality metric.
Any package which lacks a man page is a bug in Debian.
Please have a look at the manpages of the base system of any BSD. Usually documentation maintainers are very strict, and "having a page" often isn't enough.
Getting help online a problem? No one *owes* you help.
I do prefer the BSD community (obviously), but we also have a bunch of arrogant bastards that will tell people to read the source. I'd say linux atracts a kind of "fanatism" BSD (usually) doesn't, but there are very nice and helpful people regardless of the operating system, so I wouln't expect getting online help for Linux or BSD to be a problem.
Well, if you ensure your requirements are that strict and eliminate the alternatives then yes, you wont find anything other than PHP.
My requirements aren't strict. I prefer to use a single stack for development (ranging from something that can be used on an embedded system to a very busy webserver), and that relies on pieces of software that are easy to maintain (such as nginx, apache, etc). As I said before, there are valid reasons to use PHP.
If you're building bad tests sure, but you shouldn't need to test the full range of variables, if you have even a basic understanding of the concept of mathematical induction it should be trivial to build a fairly safe test case that covers the most important, often small set of inputs required to give a good degree of trust in code.
If you believe this, then you have no idea how computers work. And trust isn't a variable, its a property - you either have it, or you don't. If you cannot guarantee that a given test gives you 100% coverage of all use cases, then they cannot be used to assert quality or reliability of the code.
It's also worth noting that TDD isn't going to be much help if you just ignore the test results and ship anyway without fixing problems, even when your code doesn't pass it's own tests, which is precisely what the PHP folks did - shipped code that failed to pass it's own unit tests.
Agreed, but when I was talking about TDD, i was talking about PHP applications and fameworks with TDD, not PHP itself.
If you're aware of them, which 99% of PHP developers aren't.
You keep on assuming that PHP programmers aren't talented just because they use PHP.
You can say the same about desktop software(...)
I can run most Windows software from a decade ago in my current computer without any kind of modification whatsoever (heck, this news is precisely about that). The same goes for many unix programs. Just because there are new versions of programs, doesn't mean that old ones stopped working. Shure, sometimes some issues arise, but most web applications just don't work.
You know most of the big sites in the world have at least some Java behind them?
The same could be said for ASP.NET (Microsoft, Hotmail), or Ruby (Twitter), or PHP (Facebook), Haskell (xkcd.com), Perl (slashdot.org) or any other language you can think of. For each "pure java" site, you probably have 10 made with other tecnology. And you seem to have misread what I said - i never said java isn't popular or ubiquous (it is) - not as a web platform, but as a backend tecnology. Google relies heavily on Java for eg. big data. But hey, facebook too. And Yahoo. And a bunch of other big-ass companies. The "web" part? AFAIK Google relies on a mix of C++ and Python, Facebook relies (mostly) on PHP, and I have no idea what Yahoo uses these days.
Python/RoR are currently the next best thing that fits PHP's niche
Maybe in the future, but not today. And RoR isn't even in the same league.
PHP bills itself as being easy to use, which means it's going to be used more by amateurs
I don't really care about what "other" people use and their degree of expertise. I do care about what I use, and I couldn't care less if it's not trendy.
yet it makes it easy to make a completely incoherent mess, that follows no real design paradigm at all
What is so good about delimited paradigms? In the end, it all gets translated to ones an zeros. For some problems, OOP is nice and neat, for other problems, a procedural approach is leaner and faster. Why should I care about dogmas? You can do OOP in almost every C-level language and macros, yet it is a procedural language.
The reason Java has been so prominent in universities for so many years is because it forces OOP,
Slashdot Mirror
I guess the message was clear enough that you feel the need to correct its grammar. But I'm not shure, since I'm agnostic. I'm just not into perpetuating misinterpretations and lies.
A language that can't be used for bible translations is a win in my book (pun intended).
English can be hard to learn
Every language can be hard to learn - it depends where you're coming from. I'm a portuguese native speaker (an irregular language with lots of subtle variations and even some adapted foreign terms), so learning spanish (a similar, but somewhat phonetically simpler language) is easy. So it is english or french. German not so much (phrase construction and algutination of terms seems somewhat "unnatural"). Russian seems phonetically similar, but with a different alphabet. And it is a lot easier for a russian or an ucranian to learn portuguese than an englishmen or a dutchmen.
I'd much prefer, say, German over English (but then of course I'm also biased in favor of Indo-European group).
I wouldn't, and I bet a lot of people are with me on this one. Even some germans.
that's Pax Americana, so that language is English, unfortunately
American English. But yeah, you're right on the money.
I sure hope Chinese are not going to be the next to run the world, because their writing system is so crappy English looks like Esperanto in comparison.
Can you explain why (traditional/simplified) chinese is that bad?
You're not going to add a multi-cycle div instruction
You are hilarious. Let's say 15 years is moderately modern - every single x86 chip released in the last 15 years (at least) implements a single-cycle, pairable div instruction, so it's not rocket science. And while they *do* have a complex CISC instruction set, they are all internally decoded to RISC-like operations.
If you can't handle inserting a 13 line macro you shouldn't be writing assembler,
Actually, it is called "assembly", and some *very popular* RISC processors DO implement the instruction (ARMv7, POWER, PowerPC, SH4, etc). Oh, and OpenSPARC? You even have multiple versions of it. We are not in 1990 any more.
if it's not going to buy you anything to put it in the CPU
I did not say that, but the opposite. Having a div instruction (specially if it is a high-performance one, such as the one available since the Pentium line in x86) greatly simplifies software development, and often performs faster than subroutine-based divs. That doesn't stop you from applying the usual tricks and optimizations for the special cases that will benefit from them.
plus that leaves opportunity for optimization in cases where you can make certain assumptions about the numbers you're working with
but the availability of a div instruction doesn't stop you from using whatever optimizations you see fit, as most compilers already do in architectures that do have a div instruction.
Windows 3 would even run on the 286, anything that didn't require Win32S usually ran fine.
When Windows 3 was released, high-end i386 workstations were already common. Windows 3 did not use any memory protection features wth 286 (it runned on "real" or "standard" mode). To take advantage of actual memory protection features, you needed a 32 bit processor ("enhanced" mode).
The 68000 wasn't a direct competitor of 8086. It was an high-end cpu, and reached the general public in 1980 (8086 was introduced in 1977). By then, you also had eg, Z8000, that addressed upto 8Mb of Ram, and support for 64-bit registers.
:)
The 68020 processor was released less than a year before than i386, and you could also run 8086/8088/286 code on it. Intel could have easily beated Motorola if they had stopped playing with the i432 architecture, and instead concentrated on x86.
But yeah, the 68000 family is awesome
I'm far from being an expert in ARM (or RISC), but according to Wikipedia, integer divide is only present in ARM since v7.
Hyperthreading, an Intel tech, significantly increases speed
It doesn't, at least on earlier processors, where the pipelines are shared between threads. And while an "Intel" trademark, it isn't really new or Intel tech.
There's also a concept of pipelining that allows multiple instructions from a single thread to run staggered as long as they won't collide in their use of a particular component within the CPU
Every x86-compatible CPU designed in the past 10 years has multiple pipelines. It is hardly an Intel concept. And those multiple pipelines are really a RISC core.
Also the icore series can predict the next instruction before it is even loaded
That is a decade-old trick (badly) done in P4, because it led to costly cache invalidations. It's not like "trying to guess", but more like having the predictable execution paths already in cache,
The problem is, a quad-core i5 probably consumes less per core than a dual-core atom consumes per core, but will have much better performance per core. If you increase cache and clockspeed, you will also need more power. That's why Intel is investing heavily in increasing density (reducing consumption) instead of going after the GHz advantage.
hen they didn't stick to that model for the floating point instructions, going with a stack for that. And remember they split the CPU into 2 parts. If you wanted the floating point instructions, you had to get a very expensive matching x87 chip.
... The same as Motorola.(http://en.wikipedia.org/wiki/Motorola_68881). They began to integrate an FPU about the same time (68040/486DX).
Another major bit of ugliness was the segment. Rather than a true 32bit architecture, they used this segmented architecture scheme, then buggered it up even more by having different modes.
You mean, having a 16-bit cpu support a FULL MEGABYTE instead of the usual 64Kb of Ram? In 1979? Pure evil.
In some modes, the segment and address were simply concatenated for a 32bit address space, and in others 12 bits overlapped to give only a 20bit address space. Then you had all this switching and XMS and EMS to access memory above 1M. Nasty.
You do know that XMS memory is just linear memory above real memory, right? And that EMS whas just a PC-compatible paging memory layout, right? Because you seem to lack basic understanding of the architecture.
Few platform segregation points? Maybe, but one price is lots of legacy garbage. x86 still has to support those ancient segmented modes.
Thank god. I can still run FreeDOS.
They're hopelessly obsolete. We have much better algorithms for string search than that.
While the instructions you mentioned are used for string comparison, that's not their sole purpose. They compare bytes. not strings.
We have much better algorithms for string search than that.
Please do tell. Because null detection in a couple of opcodes isn't something easy to come by.
They also screwed up the instructions intended for OS support on the 286.
If you are talking about MMU, they dind't screw up. Nobody cared about 16-bit support.
That's one reason why the lowest common denominator is i386 and not i286. 286 is also only 16bit.
Nobody cared about i386 MMU either, upto Windows 3.0. That's why early versions of 386 were buggy as hell (such as skipping the first GDT entry - yup. it's a 386 bug, not a feature).
Someone mentioned CISC, as if that beat out RISC? It didn't. Under the hood, modern x86 CPUs actually translate each x86 instruction to several RISC instructions. So why not just use the actual RISC instruction set directly? One argument in favor of the x86 instruction set is that it is denser. Takes fewer bytes than the equivalent action in RISC instructions. Perhaps, but that's accidental. If that is such a valuable property, ought to create a new instruction set that is optimized for code density
That is the first thing on your comment that is right on the spot.
Then, as if x86 wasn't CISC enough, they rolled out the MMX, SSE, SSE2, SSE3, SSE4 additions.
...And then you lose it. Vector instructions were a FPU feature (the 487 ITT had it), and Intel also had a peek with their RISC cpus, i860/i960. With the advent of DSPs, this kind of technology came even more common.
That makes a powerful argument in favor of open source. Could drop all the older SSE versions if only all programs could be easily recompiled.
Older programs will run faster on new CPUs. In many cases, they won't take advantage of SSE at all if both the algorithm and the compiler aren't optimized for the use of those instructions.
Superior to x86? Sure there is. x86 is a mish mash of instructions many of which hardly anyone uses except for backwards compatibility, but that still cost real estate on the CPU die
CISC instructions don't take "cpu die" at least since a decade ago. Modern processors translate whatever the opcodes are to "micro-ops" that are executed on the multi-lane, out-of-order (except Atom) RISC pipeline.
The x86 has four general purpose registers. No one in their right mind would design a chip like that today.
Not even Intel. Intel RISC processors have a lot more registers, and while you can also poke holes in their technology, they were the basis of modern Intel processors.The register limitation is more of a backward-compatible move than anything else.
In a modern computer, RAM is significantly slower than registers, so having more registers can give you a large performance boost
Yes and no. RAM is probably a magnitude slower than registers, but it is where your code (the one messing around with registers) lie; Modern processors also have a shorter pipeline than those pesky P4, so they usually have a smaller instruction cache. It all boils down do L1/L2 cache, and some schedulers go to great extent not to trash it, and have your code right there when the processor needs it.
The question isn't whether it's well documented, the question is how well it performs in power/performance.
The question is,can you have a baseline performance index for your product, given an arbitrary vendor. You can't. Not only there is a lot less fragmentation if everything comes from the same provider, but you can only provide consistency if the vendor is the same,
But no div instruction for all? Since the early nineties even microcontrollers have a div instruction...
Intel deserves a lot of credit in proving just how far CISC design can go.
Intel also deserves credit for some RISC processors, namely the i860 and the i960. A lot of the effort of the RISC division was later packported to their mainstream CPUs.
I don't know why you keep insisting that I'm not aware of mathematical induction (or any other proof system), but it seems you are not aware of the pitfalls and limitations of TDD.
Well, it seems you already have your mind made, so it's pointless for me to continue to try explaining you again what I already said. I understand where you are coming from (changing from C# to PHP is like going from a ferrari to a trycicle), but don't waste your time calling me "unexperienced". I've been developing software for the past 18 years, ranging from x86 assembly to C#, passing by C, Pascal/Delphi, COBOL/Object Cobol, VB, and even a bit of Java, have worked with somewhat large codebases (the biggest one at my sole responsability were around 300Mb of source), so I do know a thing or two about software development and application lifecycle management. But this is not a pissing contest. If you want to dismiss my opinion or my arguments just because I use PHP and have a poor opinion about both TDD and OOP as the holy grail, it's up to you.
From what I've read (diagonally) from the article, the fork was started by OpenBSD developers. I guess they decided to fork something they already have good knowledge of. FreeBSD internals are quite different, and while NetBSD has some similarities, they have come a long way since the OpenBSD fork.
DragonFly BSD is HUGELY underrated. It is an aswesome project, and I'd love to see HAMMER in both FreeBSD and OpenBSD.
While I'm a big fan/heavy user of FreeBSD, I've only seen reports of FreeBSD SMP machines upto 32 cores.
Cut and paste doesn't work?
It has been a while since I tried it, but with X/Xorg you can copy/paste text without an issue and you can copy/paste some kind of specific data (such as images) between applications that use the same toolkit. Everything else (formatted text, vector drawings, files) is a PITA.
Also, I just bought a 15" dell monitor off craigslist yesterday and running stock Debian 6 on a Thinkpad T60, plugged it in and it did mirroring 100% correctly.
So, just because it works for you, it must work for everybody? I had issues with older versions of Ubuntu on a Asus EE900, and with stock gnome you couldn't even click on the "ok" button of the display settings because it went offscreen (1024x600). It is somewhat easy to fix, but not very "user friendly".
Tell MythTV users sound doesn't work reliably.
The other day there was a rant one mile long regarding PulseAudio defects and how it killed low-latency audio in Linux. Many complainers were Linux users.
Five guis are a mess?
There is a consistent lack of consistency, yes. Partially because there is a multitude of toolkits available, and there is no single standard for almost everything. You gain choice, but you lose consistency.
If I apt-get source foobar I can build any debian package on my server and install it on my desktop
Yes, if they are roughly the same version. If they have eg. different glibc versions, you may have problems. And compilation flags in many linux distros can also interfere (try building an i7-optimized binary and run it on a p4), but that may also happen in other operating systems. AFAIK, both PC-BSD and MacOS have a somewhat elegant solution for it.
Documentation is worthless?
Yeah, it is. It is not that rare to find outdated manpages, features that lack documentation, or translation errors. You may not notice it, but if you are used to BSD-style manpages, you will have a shock.
The GNU Emacs Reference manual is like 1000+ pages.
Since Emacs isn't really part of the "base system", the manpages for Emacs are the same regardless of the operating system. I'm not familiarized with it, but size isn't really a quality metric.
Any package which lacks a man page is a bug in Debian.
Please have a look at the manpages of the base system of any BSD. Usually documentation maintainers are very strict, and "having a page" often isn't enough.
Getting help online a problem? No one *owes* you help.
I do prefer the BSD community (obviously), but we also have a bunch of arrogant bastards that will tell people to read the source. I'd say linux atracts a kind of "fanatism" BSD (usually) doesn't, but there are very nice and helpful people regardless of the operating system, so I wouln't expect getting online help for Linux or BSD to be a problem.
Does your employer get free Windows tech support?
Yeah, we actually do.
Well, if you ensure your requirements are that strict and eliminate the alternatives then yes, you wont find anything other than PHP.
My requirements aren't strict. I prefer to use a single stack for development (ranging from something that can be used on an embedded system to a very busy webserver), and that relies on pieces of software that are easy to maintain (such as nginx, apache, etc). As I said before, there are valid reasons to use PHP.
If you're building bad tests sure, but you shouldn't need to test the full range of variables, if you have even a basic understanding of the concept of mathematical induction it should be trivial to build a fairly safe test case that covers the most important, often small set of inputs required to give a good degree of trust in code.
If you believe this, then you have no idea how computers work. And trust isn't a variable, its a property - you either have it, or you don't. If you cannot guarantee that a given test gives you 100% coverage of all use cases, then they cannot be used to assert quality or reliability of the code.
It's also worth noting that TDD isn't going to be much help if you just ignore the test results and ship anyway without fixing problems, even when your code doesn't pass it's own tests, which is precisely what the PHP folks did - shipped code that failed to pass it's own unit tests.
Agreed, but when I was talking about TDD, i was talking about PHP applications and fameworks with TDD, not PHP itself.
If you're aware of them, which 99% of PHP developers aren't.
You keep on assuming that PHP programmers aren't talented just because they use PHP.
You can say the same about desktop software(...)
I can run most Windows software from a decade ago in my current computer without any kind of modification whatsoever (heck, this news is precisely about that). The same goes for many unix programs. Just because there are new versions of programs, doesn't mean that old ones stopped working. Shure, sometimes some issues arise, but most web applications just don't work.
You know most of the big sites in the world have at least some Java behind them?
The same could be said for ASP.NET (Microsoft, Hotmail), or Ruby (Twitter), or PHP (Facebook), Haskell (xkcd.com), Perl (slashdot.org) or any other language you can think of. For each "pure java" site, you probably have 10 made with other tecnology. And you seem to have misread what I said - i never said java isn't popular or ubiquous (it is) - not as a web platform, but as a backend tecnology. Google relies heavily on Java for eg. big data. But hey, facebook too. And Yahoo. And a bunch of other big-ass companies. The "web" part? AFAIK Google relies on a mix of C++ and Python, Facebook relies (mostly) on PHP, and I have no idea what Yahoo uses these days.
Python/RoR are currently the next best thing that fits PHP's niche
Maybe in the future, but not today. And RoR isn't even in the same league.
PHP bills itself as being easy to use, which means it's going to be used more by amateurs
I don't really care about what "other" people use and their degree of expertise. I do care about what I use, and I couldn't care less if it's not trendy.
yet it makes it easy to make a completely incoherent mess, that follows no real design paradigm at all
What is so good about delimited paradigms? In the end, it all gets translated to ones an zeros. For some problems, OOP is nice and neat, for other problems, a procedural approach is leaner and faster. Why should I care about dogmas? You can do OOP in almost every C-level language and macros, yet it is a procedural language.
The reason Java has been so prominent in universities for so many years is because it forces OOP,