So what? Software reverse engineering is even easier.
Says who? Software reverse engineering _can_ be easier, it doesn't mean it always is. Many many hardware devices are made with "off the shelf parts", and last time I've checked most microcontrolers and embedded systems don't have any kind of code protection. There are some exceptions, but comparatively much more expensive and probably less flexible for multiple i/o applications.
OK - so you are blaming ME for a problem fixed by unticking a box that says "enable IPv6"?
You did transpose my previous response as some sort of accusation. In fact, there is no "shoot the messenger", because you never stated your IPv6 problems in the 3rd person. But, given that english isn't my first language, my choice of words probably wasn't the happiest one, so I apologize for any unintended assault.
I buy a lot of ebooks and often the deadtree version costs 2-3x more. There are some reference books I prefer to have on paper, but for some others it is actually cheaper to print a copy on my laser printer than buying the paper version.
I obviously don't know the specifics of the application you talked about earlier, and it may happen that PHP isn't the best language for the job (and probably isn't). I understand your "frustration" with frameworks, and the motives you mentioned are the same that kept me away from them for years. But, truth be told, frameworks like Zend Framework (that doesn't impose themselves on the programmer) allows me to spend more time in solving the aplicational problem, and less worrying about structural issues such as database connections, authentication or character encoding.
Hardware can be reverse engineered, and is actually common practice. Most "custom hardware" I've seen (both from small and international companies) is neither that revolutionary or that complex. Imagine if only one company could make TVs by following the spec sheet of the broadcast.
It was the late 90's. You'd scream "somewhat novel computer agorithm or gizmo" and money would pour from the sky, carried by finantial advisors and business investors. Need 50 million for that bycicle horn business? Is it internet related? yes? no problem! You'll have it by tomorrow!
It means that when they'll be out of a job because someone with deeper pockets saw the pontential in the business and implemented it better, but with the same algorithms in software, they won't need to learn a new API because the one they developed will be pretty much standard.
Sun did it (OpenOffice, Java, OpenSolaris to name a few), IBM did it (JFS? NUMA?), MySQL Did it, Zend did it, RedHat did it, Yahoo did it (Hadoop), Google did it (Hbase) and probably many more. The question is - is the business model based solely on the product, or on related services?
No, I'm blaming you for being unable to diagnose a routing or dns problem. In fact, I'm also blaming many MCEs that can't understand the basics of tcp/ip networking, and aren't able to read the documentation. Disabling IPv6 isn't "problem fixed", is "problem postponed". I know many times we don't have the time or sightness to be able to try all the magic fixes that are applied to the many windows hiccups, but that is one that is usually caused by ignorance of the administrator and not the operating system itself. If, by chance, you are a unix administrator and cannot correctly configure a dns server and networking routing, you'd be a lousy - and possibly out of a job - administrator. In windows, it's "welcome to the domain".
It is funny how our source of energy is based on available stuff - ranging from trees and coal to uranium and hydrogen. You'd think those silly aliens are doomed because our planet is so rich in those energy elements and theirs isn't.
You use what you have available. Different planets may have completely different life forms, and completely different energy sources. Talking about energy sources (specially finite) in a universe where every atom of matter is bounded by energy is - at least - laughable.
Truth be told, aliens could have landed here 2500 years ago and we'd know as much about them as we know today. While this sounds like many sci-fi scripts, it stands to reason that advanced entities probably would be considered gods. If they are far away, 2500 years between visits probably isn't that much.
I've seen those kind of problems and usually aren't exclusivelly IPv6 related. The most usual case I can think of is poor internet "performance" in domain setups - the machines have their name resolution pointing to the domain controller, but the domain controller isn't configured to forward requests to the internet (or the router). From what I've seen, this is actually a big issue, because DC promotion doesn't require a correct DNS configuration as a proxy to work - only the local entries for the domain controller. If, in contrast, your machine has a different DNS server than the domain controller pool, you'd get horrible SMB/authentication performance unless you enable Netbios and have a correctly configured WINS server.
In short, it's usually the administrator fault, not windows. Nothing new here.
NAT killed the concept that evey host is accessible via routing. That is not a bad thing, as some "troublesome" protocols are deprecated or somewhat rewritten to work around NAT. Someone mentioned SIP, an abortion that should never be routed without encryption on a public network. Almost the same as FTP.
Actually, I would consider Ubuntu to be bug-ridden, just compare it to FreeBSD 8.0. And you're comparing less than 5Mb of actual code with an entire operating system.
Why would you use a 3rd party bug-ridden application, when you can use the only slightly crappy MySQL Workbench, from the same guys that bring you MySQL?
A developer that would need to use phpMyAdmin should already know enough SQL to use the CLI interface. There are plenty of graphical mysql administration tools that can easily work with a tunneled ssh connection. In the cases that is not feasible, the alternative should never be to upload a 3rd party tool, with a rich history of known vulnerabilities, to a production server.
Last time I checked many (most?) sysadmins don't know exactly what they're doing, and that's why graphical and wizard-based configuration tools are so popular. And no, I'm not talking about windows. There's nothing wrong with that, in most cases. Critical or public facing infrastructure should be the exception, though.
Patterns are about applying the same design pattern to the same problem, not every problem. I agree that the pattern frenzy is not good, and specially in PHP often leads to over-engineered bloated code, but not always.
Regarding Zend Framework, most modules aren't intimally tied with the mvc implementation. That means you can use the authentication library, the form library and the validation library without needing to use the recommended folder tree or any mvc features at all. I often find Zend_Mail, for example, in many 3rd party apps that do not use any other module. They work a bit like the PEAR libraries, but with a better quality control and a well defined implementation specification.
Regarding optimization, in my experience, it is not that hard to increase the performance of an application not designed with performance in mind. I've made old joomla installations (v1.1) scale to several thousand simultaneous users on a very old machine, in less than a day. In fact, Zend even has a module that may be a big help - Zend_Cache. In other cases, it's not obvious that a C/Java/whatever will be faster, because usually the problem lies with database operations, poor I/O or plain old bad design decisions - that also happen in other languages.
Theoretically, you can build your own http server in PHP and have most of the advantages of the persistent resources and stateful behaviour. In fact, you can even run PHP in a JVM (Quercus) and reap some of those benefits without re-inventing the existing technology.
AFAIK you can't have one Zend_Db adapter connecting to two different hosts. You can, however, use two Zend_Db adapters, but you'd lose the "magic" parsing of
read operations - it won't be transparent to the application, unless you also create the glue code.
What is a highly scalable application? An application that can scale horizontally? An application that can handle more requests/s than the other? Saying PHP isn't the "right technology" is a bit generalist, given that you actually have plenty of examples in the contrary. And even the metric is flawed - in many applications you'll have database problems long before your CGI-based "wrong tecnology" is actually a problem, and that applies to PHP, Perl (mod_perl or as CGI), Python (mod_python or as CGI), etc. I'm not saying you should use any of those languages instead of Java or C# - in fact, often are plenty of reasons to use Java or C# instead of those languages - but scalability isn't one of them. Your application either is designed to scale or isn't.
I don't know enough about facebook architecture to say you're right. I do know they created a PHP "compiler" to decrease the load on the servers, and not because PHP couldn't scale. It's about doing more with less. I don't think their application suddenly stops working at 10 000 servers or something like that. Maybe they have legacy design issues that compromise the scaling of their applications to the current size. I don't see them running away from php or mysql.
The two big problems with Zend Framework is that performance is not that stellar when using the default MVC approach (in part because of the complexity of the front dispatch controller and the view structure - it's being reworked on 2.0 AFAIK), and more often than not, the documentation is absolute crap. Oh, and there is the issue of Zend_Db not supporting multiple database connections - you know, when you have to load-balance you app to a backend or having a faster read-only db node just for reading.
That given, you can easily override the base components so they do what you want - once again, the only downside is documentation. I've been working with Zend Framework since v1.2, and it has grown to a full-fledged, feature-rich library, and even if you don't like some design options, you are able to easily re-implement them yourself (plugin support and Zend_View comes to mind). The only thing I find missing is an event dispatcher, but the newer version (currently in beta) already has an implementation.
Given that the story was about web frameworks, most of the hybrid frameworks that I've seen are useful, even when cooking simple or specific applications.
There are designs that work well for well-known problems - they're called "patterns". Not that I'm a big pattern fan, but it stands to reason that most of what you're trying to do, many people have done it before, and may have a clear and concise solution.
Learning "a tool" is not as smart as it sounds - Apache is completely different from Nginx, for example. From a web developer point of view, there's little difference. SQL is a must, but only until you start to use stored procedures or triggers. Most dialects aren't portable, and even with plain ol' SQL, a specific query can have completely different performance results in different SGBDs - It is not a "generic" knowledge, it is a specific one. In many cases, the use of stored procedures for web applications is a very bad idea - while they offer the advantage of pre-parsed logic, they're not easily versionable, debuggable or cacheable.
You can have your specific app and still use Zend_Mail for sending email without re-implementing the whole thing. Or Zend_Validate, even if you don't use the touted MVC approach. Or Zend_Locale, and benefit from the thread-aware gettext implementation. The thing is, hybrid frameworks are not really frameworks, in the sense they work like libraries.
Why don't you program everything in C and compile it as a php module so you can tweak/postprocess the output? Its much more efficient (performance-wise and application domain-wise) than using plain ol'PHP directly.
Browsing thumbnails of RAW photos with Lightroom is painfully slow, even with a SSD disk. It's somewhat strange, given that most RAW formats have a TIFF/JPG low-res thumbnail embedded.
There are several advantages in using frameworks - you usually end up using tried-and-true methods to solving common problems, you may be "forced" to use some methodology that may turn you into a better programmer, and you are using code tested and debugged by thousands of other people.
Using a framework doesn't mean you need to drink the cool-aid or use ORM - in fact, if you choose a hybrid framework, you can pick the components you need, and still use your legacy/custom code for the rest.
Slashdot Mirror
So what? Software reverse engineering is even easier.
Says who? Software reverse engineering _can_ be easier, it doesn't mean it always is. Many many hardware devices are made with "off the shelf parts", and last time I've checked most microcontrolers and embedded systems don't have any kind of code protection. There are some exceptions, but comparatively much more expensive and probably less flexible for multiple i/o applications.
OK - so you are blaming ME for a problem fixed by unticking a box that says "enable IPv6"?
You did transpose my previous response as some sort of accusation. In fact, there is no "shoot the messenger", because you never stated your IPv6 problems in the 3rd person. But, given that english isn't my first language, my choice of words probably wasn't the happiest one, so I apologize for any unintended assault.
I buy a lot of ebooks and often the deadtree version costs 2-3x more. There are some reference books I prefer to have on paper, but for some others it is actually cheaper to print a copy on my laser printer than buying the paper version.
I obviously don't know the specifics of the application you talked about earlier, and it may happen that PHP isn't the best language for the job (and probably isn't). I understand your "frustration" with frameworks, and the motives you mentioned are the same that kept me away from them for years. But, truth be told, frameworks like Zend Framework (that doesn't impose themselves on the programmer) allows me to spend more time in solving the aplicational problem, and less worrying about structural issues such as database connections, authentication or character encoding.
Hardware can be reverse engineered, and is actually common practice. Most "custom hardware" I've seen (both from small and international companies) is neither that revolutionary or that complex. Imagine if only one company could make TVs by following the spec sheet of the broadcast.
It was the late 90's. You'd scream "somewhat novel computer agorithm or gizmo" and money would pour from the sky, carried by finantial advisors and business investors. Need 50 million for that bycicle horn business? Is it internet related? yes? no problem! You'll have it by tomorrow!
It means that when they'll be out of a job because someone with deeper pockets saw the pontential in the business and implemented it better, but with the same algorithms in software, they won't need to learn a new API because the one they developed will be pretty much standard.
Sun did it (OpenOffice, Java, OpenSolaris to name a few), IBM did it (JFS? NUMA?), MySQL Did it, Zend did it, RedHat did it, Yahoo did it (Hadoop), Google did it (Hbase) and probably many more. The question is - is the business model based solely on the product, or on related services?
No, I'm blaming you for being unable to diagnose a routing or dns problem. In fact, I'm also blaming many MCEs that can't understand the basics of tcp/ip networking, and aren't able to read the documentation. Disabling IPv6 isn't "problem fixed", is "problem postponed". I know many times we don't have the time or sightness to be able to try all the magic fixes that are applied to the many windows hiccups, but that is one that is usually caused by ignorance of the administrator and not the operating system itself. If, by chance, you are a unix administrator and cannot correctly configure a dns server and networking routing, you'd be a lousy - and possibly out of a job - administrator. In windows, it's "welcome to the domain".
It is funny how our source of energy is based on available stuff - ranging from trees and coal to uranium and hydrogen. You'd think those silly aliens are doomed because our planet is so rich in those energy elements and theirs isn't.
You use what you have available. Different planets may have completely different life forms, and completely different energy sources. Talking about energy sources (specially finite) in a universe where every atom of matter is bounded by energy is - at least - laughable.
Truth be told, aliens could have landed here 2500 years ago and we'd know as much about them as we know today. While this sounds like many sci-fi scripts, it stands to reason that advanced entities probably would be considered gods. If they are far away, 2500 years between visits probably isn't that much.
So, did you waste 6 minutes of your short life, or of your long, prosperous, religious bible bashing life? :D
I've seen those kind of problems and usually aren't exclusivelly IPv6 related. The most usual case I can think of is poor internet "performance" in domain setups - the machines have their name resolution pointing to the domain controller, but the domain controller isn't configured to forward requests to the internet (or the router). From what I've seen, this is actually a big issue, because DC promotion doesn't require a correct DNS configuration as a proxy to work - only the local entries for the domain controller. If, in contrast, your machine has a different DNS server than the domain controller pool, you'd get horrible SMB/authentication performance unless you enable Netbios and have a correctly configured WINS server.
In short, it's usually the administrator fault, not windows. Nothing new here.
NAT killed the concept that evey host is accessible via routing. That is not a bad thing, as some "troublesome" protocols are deprecated or somewhat rewritten to work around NAT. Someone mentioned SIP, an abortion that should never be routed without encryption on a public network. Almost the same as FTP.
Actually, I would consider Ubuntu to be bug-ridden, just compare it to FreeBSD 8.0. And you're comparing less than 5Mb of actual code with an entire operating system.
Secunia says the phpMyAdmin 3.x branch has had 20 advisories and 54 (patched) vulnerabilities. The older 2.x has more.
Why would you use a 3rd party bug-ridden application, when you can use the only slightly crappy MySQL Workbench, from the same guys that bring you MySQL?
A developer that would need to use phpMyAdmin should already know enough SQL to use the CLI interface. There are plenty of graphical mysql administration tools that can easily work with a tunneled ssh connection. In the cases that is not feasible, the alternative should never be to upload a 3rd party tool, with a rich history of known vulnerabilities, to a production server.
Last time I checked many (most?) sysadmins don't know exactly what they're doing, and that's why graphical and wizard-based configuration tools are so popular. And no, I'm not talking about windows. There's nothing wrong with that, in most cases. Critical or public facing infrastructure should be the exception, though.
Patterns are about applying the same design pattern to the same problem, not every problem. I agree that the pattern frenzy is not good, and specially in PHP often leads to over-engineered bloated code, but not always.
Regarding Zend Framework, most modules aren't intimally tied with the mvc implementation. That means you can use the authentication library, the form library and the validation library without needing to use the recommended folder tree or any mvc features at all. I often find Zend_Mail, for example, in many 3rd party apps that do not use any other module. They work a bit like the PEAR libraries, but with a better quality control and a well defined implementation specification.
Regarding optimization, in my experience, it is not that hard to increase the performance of an application not designed with performance in mind. I've made old joomla installations (v1.1) scale to several thousand simultaneous users on a very old machine, in less than a day. In fact, Zend even has a module that may be a big help - Zend_Cache. In other cases, it's not obvious that a C/Java/whatever will be faster, because usually the problem lies with database operations, poor I/O or plain old bad design decisions - that also happen in other languages.
Theoretically, you can build your own http server in PHP and have most of the advantages of the persistent resources and stateful behaviour. In fact, you can even run PHP in a JVM (Quercus) and reap some of those benefits without re-inventing the existing technology.
AFAIK you can't have one Zend_Db adapter connecting to two different hosts. You can, however, use two Zend_Db adapters, but you'd lose the "magic" parsing of read operations - it won't be transparent to the application, unless you also create the glue code.
What is a highly scalable application? An application that can scale horizontally? An application that can handle more requests/s than the other? Saying PHP isn't the "right technology" is a bit generalist, given that you actually have plenty of examples in the contrary. And even the metric is flawed - in many applications you'll have database problems long before your CGI-based "wrong tecnology" is actually a problem, and that applies to PHP, Perl (mod_perl or as CGI), Python (mod_python or as CGI), etc.
I'm not saying you should use any of those languages instead of Java or C# - in fact, often are plenty of reasons to use Java or C# instead of those languages - but scalability isn't one of them. Your application either is designed to scale or isn't.
I don't know enough about facebook architecture to say you're right. I do know they created a PHP "compiler" to decrease the load on the servers, and not because PHP couldn't scale. It's about doing more with less. I don't think their application suddenly stops working at 10 000 servers or something like that. Maybe they have legacy design issues that compromise the scaling of their applications to the current size. I don't see them running away from php or mysql.
The two big problems with Zend Framework is that performance is not that stellar when using the default MVC approach (in part because of the complexity of the front dispatch controller and the view structure - it's being reworked on 2.0 AFAIK), and more often than not, the documentation is absolute crap. Oh, and there is the issue of Zend_Db not supporting multiple database connections - you know, when you have to load-balance you app to a backend or having a faster read-only db node just for reading.
That given, you can easily override the base components so they do what you want - once again, the only downside is documentation. I've been working with Zend Framework since v1.2, and it has grown to a full-fledged, feature-rich library, and even if you don't like some design options, you are able to easily re-implement them yourself (plugin support and Zend_View comes to mind). The only thing I find missing is an event dispatcher, but the newer version (currently in beta) already has an implementation.
Given that the story was about web frameworks, most of the hybrid frameworks that I've seen are useful, even when cooking simple or specific applications.
There are designs that work well for well-known problems - they're called "patterns". Not that I'm a big pattern fan, but it stands to reason that most of what you're trying to do, many people have done it before, and may have a clear and concise solution.
Learning "a tool" is not as smart as it sounds - Apache is completely different from Nginx, for example. From a web developer point of view, there's little difference. SQL is a must, but only until you start to use stored procedures or triggers. Most dialects aren't portable, and even with plain ol' SQL, a specific query can have completely different performance results in different SGBDs - It is not a "generic" knowledge, it is a specific one. In many cases, the use of stored procedures for web applications is a very bad idea - while they offer the advantage of pre-parsed logic, they're not easily versionable, debuggable or cacheable.
You can have your specific app and still use Zend_Mail for sending email without re-implementing the whole thing. Or Zend_Validate, even if you don't use the touted MVC approach. Or Zend_Locale, and benefit from the thread-aware gettext implementation. The thing is, hybrid frameworks are not really frameworks, in the sense they work like libraries.
Why don't you program everything in C and compile it as a php module so you can tweak/postprocess the output? Its much more efficient (performance-wise and application domain-wise) than using plain ol'PHP directly.
Browsing thumbnails of RAW photos with Lightroom is painfully slow, even with a SSD disk. It's somewhat strange, given that most RAW formats have a TIFF/JPG low-res thumbnail embedded.
There are several advantages in using frameworks - you usually end up using tried-and-true methods to solving common problems, you may be "forced" to use some methodology that may turn you into a better programmer, and you are using code tested and debugged by thousands of other people.
Using a framework doesn't mean you need to drink the cool-aid or use ORM - in fact, if you choose a hybrid framework, you can pick the components you need, and still use your legacy/custom code for the rest.