Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
Documentation is built in -- man perlpod. As I mentioned in another reply, you can write unreadable or unmaintainable code in any language. Developers who do so should not be holding down jobs. The problem with PHP is that it encourages unmaintainable code by purposefully omitting certain features that would go a long way towards improving code quality. They aren't omitted because they are unnecessary; rather they are omitted because they get in the way. That's a poor approach to language design in my book.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
Does PHP enforce declaration of variables? No. Does PHP enforce scope? No. Does PHP.. oh never mind. The point is that the parent made a snide comment insinuating that the only reason anyone prefers Perl and dog on PHP is because it makes them feel 'leeter'. There are probably a vocal minority that feel that way, but on the whole, there are numerous and important practical reasons to prefer Perl (or any other language for that matter) over PHP.
Whether those reasons matter to any particular developer/project or not is not the issue. The fact is that they exist, and that means that people like the parent can stuff their snide digs that Perl users are nothing more than elitists.
Your final comment about businesses avoiding Perl 'scripters' like the plague is telling that your experiences have most likely been limited to the script kiddie types. Perl code written by professionals is developed with, at a minimum, strict, taint checking, and warnings, has the components split up into packages with only public interfaces exported, has POD documentation for all public methods in packages, uses eval blocks to catch exceptions, has global variables confined to a single package with all other variables lexically scoped, uses references extensively, and uses as verbose of a syntax as necessary to make clear the intent of a particular section of code, including but not limited to regular expression patterns. Anything less makes an unmaintainable mess, and I wouldn't want to touch it any more than I want to touch your PHP code.
But the point is, Perl gives you all the tools to not only develop quality code, but also to prevent yourself from making mistakes; it is only a matter of learning how to use them. I'd really like to see someone make a list of PHP features that contribute towards code quality, because obviously I'm missing something somewhere if it really has such features.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
A cut & paste troll? Yeah; cut & pasted straight from my own experiences with both languages. Rebut, or shut up. Don't mod down opinions you disagree with.
If you are deploying Perl code which was developed without 'use strict', you should be taken out back and shot. BTW, someone with something to prove can write unreadable code in any language they wish to discredit. Including PHP.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
error_reporting would be more useful if it would actually throw an exception when the program fails (similar to how 'use strict' causes a Perl program to invoke the 'die' method when the programmer does something stupid). Having program structure problems hidden away in a web server log instead of smacking the programmer in the face during testing doesn't seem to contribute much towards code quality.
We are talking about a company who would be GPL'ing its own code. The statement that the GPL doesn't give them enough freedom to do whatever they want with the code is ridiculous, because the copyright holder is not bound by the terms of the GPL.
Check the power supply. Sounds like it isn't giving enough juice under load.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
Man, posting on a PHP story is like posting on a BSD story: you'd best be toeing the party line, or they send some mods after you to break your legs.
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 4, Insightful
Nice troll. The problem is more like that with PHP you can "right" programs that work with a minimum of effort. That sounds great, but the issue shows up when that code is handed to someone else. Debugging someone else's code in a language that enforces structured programming pragmas as little as possible is a nightmare. I know this because I do it on a regular basis.
PHP is like MySQL, and it appeals to the same group of people. It works, most of the time. When it's not sure what to do, it does _something_ rather than annoy the programmer, which might even be the wrong thing. When it does something that might be the wrong thing, it does it silently whenever possible so there is no "squeaking" on the outside. The result is that PHP programs work most of the time, like MySQL. That sounds great, but they also have a tendency to fail in unexpected murky ways.
BTW, there is no need to be a "guru" to write Perl programs. An understanding of the syntax, as well as basic structured programming/OO principles is all that is necessary to create fast, reusable, and reliable Perl code. The problem is that frequently people lack the latter, so they jump on a language like PHP which lets them get away with not having to know such things. Such people view PHP as superior and Perl programmers as pretentious language snobs because they can do in 5 minutes in PHP what would have taken them an hour to learn how to do in Perl. That in no way invalidates the viewpoint of the Perl snob. PHP is a half-ass hack of a language that happens to be preferred by the majority of half-ass hacks of programmers out there.
Note, this is not a flame at PHP developers. I know some really good ones. I'm flaming people who suggest that PHP is a better language because it doesn't make you learn anything about software design principles. That's precisely the reason I avoid other people's PHP code whenever possible and don't recommend its use in a business environment where software infrastructure quality counts towards the bottom line.
Novel Nonobvious
Adequately described or enabled (for one of ordinary skill in the art to make and use the invention)
Claimed by the inventor in clear and definite terms
The same people who don't patch their windows machines won't patch their linux machines.
I don't think that's a good generalization to make. I used to not patch my windows machine because something annoying always ended up breaking after the update. Granted, this usually happened after upgrading a driver from Windows Update, but occasionally I had to reinstall a piece of software after an OS update, which made me wonder if I had just neutralized the update. Now that I use Debian fulltime, I don't even think about it - cron-apt installs available patches from security.debian.org every 12 hours on all my machines.
If I cared enough to be more vigilant (or was being paid to do so) I would, but I can't be bothered when there are more important things to do than keep miscreants off my network. Automated security updates for Debian work for me and haven't broken a thing compared to Microsoft updates.
The reasoning for why the new license sucks has absolutely nothing to do with the GPL, despite the uninformed ramblings of the Slashdot crowd.
The new license is GPL-incompatible. Applying it to the client-side libraries has been "deferred" according to the Project. To me, that sounds like future plans are in store for applying it to client-side libraries. Once that happens, anybody who distributes a GPL application linked to Xlib without obtaining extra permissions from the application's copyright holders (similar to the OpenSSL exception) will be violating the GPL.
Of course, the problems the license change introduced were not the sole problems. libGL was under an SGI source license which is not GPL compatible. Anyone who was distributing a GPL application linked to the GLX library for XFree86 was also in violation of the GPL already. There are a few other examples of GPL problems related to the variety of licenses that XFree86 finds acceptable to include in their codebase.
The new license is impractical because it requires that attribution to be given to the XFree86 developers wherever any other attribution is given to another party.
Alternately, this acknowledgment may appear in the software itself, in the same form and location as other such third-party acknowledgments.
That alternate stipulation waters down the doomsday scenario you propose. The "corruption" is limited to the software itself.
There's also potential for the license to "spread" as people lift code, resulting a wide variety of apps with hundreds if not thousands of authors that have this incredibly stupid licensing stipulation.
The potential for the license to "spread" is exactly the same as the potential for the GPL to spread. In this case, only an attribution requirement (which can be trivially satisfied in an "About" box or in a startup message on the console) is being spread, rather than the stipulation that you must provide all of your software under a GPL-compatible license, in the case that you reused some GPL software. Putting it in perspective, it's really not all that bad. It's not nearly as bad as the advertising clause in the original BSD license, for example.
Remember that the intent of this license is to prevent proprietary developers (such as those of other commercial X servers) from using XFree86 code without giving credit to the project. It was not intended to inconvenience open source developers, and it hasn't yet been made clear to me exactly how the new license is the problem with XFree86. To me, it looks like the real problem is that developers are jumping ship due to the glacial pace of development and resistance to new ideas.
If one is looking for a conservative and stable open source X server, they will find it in XFree86. However, it is being made clear that a significant number of users prefer an X server with regular feature additions and a shorter development cycle. It is unfortunately impossible to satisfy that demand within the XFree86 Project, so new options have opened up, largely thanks to people whose needs differ from XFree86 and who are willing to put in the work to improve choice in the open source world.
I'm still not seeing how tracking a stable release of FreeBSD is any different from tracking a stable release of Debian, or the same for unstable releases. If you need a controlled environment for producting, Debian stable or FreeBSD 4.x are equivalent. If you need an up to date environment for hacking or for personal use, then Debian unstable or FreeBSD 5.x are equivalent. Is there something I'm missing in that picture?
Re:Replace it with a key labelled [help]
on
Is Caps Lock Dead?
·
· Score: 1
It's not a matter of having trouble responding to the interrupts. (You'd be in big trouble if you were getting more interrupts than you could process). The problem is that the ratio of time spent in the kernel versus time running your program is increased in the case of USB input devices, which has a deleterious effect on responsivity of the program if the program (such as a game) is aggressive enough with CPU usage to contend with the kernel for CPU time.
Re:Replace it with a key labelled [help]
on
Is Caps Lock Dead?
·
· Score: 1
Even if your input devices are not competing for USB bus bandwidth, the protocol still takes more CPU time to handle and interrupt level sharing is frequently an issue. When the system gets loaded, this translates to dropped samples on a USB input device where the simpler PS/2 device is still responsive, because it takes hardly any CPU time to service compared to a USB event.
Re:Replace it with a key labelled [help]
on
Is Caps Lock Dead?
·
· Score: 5, Informative
Oh yeah... did I mention that it has a USB hub in it? Why the hell are we still shipping PCs with 12-year-old PS/2 technology?
Easy. Because USB is not a perfect replacement for PS/2 input devices.
There is a large amount of latency on the USB bus as well as software latency incurred due to processing the USB packets. There is practically no wire latency with PS/2 and the protocol is dead simple to parse. You can create a little microcontroller project to interface almost any simple device to a PS/2 port. With USB, you need a separate ASIC to even begin to get anything done.
USB controllers typically share interrupt levels with other PCI devices. On systems without an IO-APIC, this translates into increased software overhead on every interrupt, because the interrupt handler for every device sitting on that interrupt is invoked. Whereas with PS/2 devices, you have an IRQ reserved for the keyboard and an IRQ reserved for the mouse. Since they are edge triggered ISA interrupt lines, there is no possible way for them to be shared even if you wanted to. Therefore the correct interrupt handler (and ONLY the correct one) is invoked in response to a PS/2 event.
In short, there is no possible way on any but the fastest of current machines for a USB mouse to approximate the responsivity of a PS/2 port mouse being sampled at 200Hz (the maximum rate the port will tolerate).
Can you try removing the gpm package (and rebooting if necessary)? This might also require changing the mouse device in the XFree86 configuration to/dev/input/mice or something similar.
GPM has always given me sporadic problems, and if you're not using the mouse on the Linux console, you don't need it at all. I think most distributions (even GUI-oriented ones) install it by default anyway for some reason.
3 external supplies? What were they? My STe's internal supply recently started acting up, so I replaced a bunch of dried up capacitors and it's fine now. But the wall cord plugs straight into the power supply on mine, no externals needed.
Something I forgot to mention is that I don't see this happening anytime soon. It is a strong parallel to people developing open source alternatives to Microsoft software. The reason that is happening is because people have become angry with Microsoft's monopoly and lack of innovation, so they decided to take things into their own hands.
NV and ATI, otoh, are still innovating and each product cycle is better than the last in some easily measurable way. I don't see things coming to the point that they did for open source software to gain a foothold for a while now.
I think once either NV or ATI goes out of business or drops out of the 3D race, and the remaining player continues selling the old products for the same prices, might we see people start to take matters into their own hands. By then, more powerful FPGAs and VHDL simulators will be available, not to mention more people with the requisite knowledge. For now, we sit and wait and let the market mature to the point where community-based hardware development can take over.
Slashdot Mirror
Whether those reasons matter to any particular developer/project or not is not the issue. The fact is that they exist, and that means that people like the parent can stuff their snide digs that Perl users are nothing more than elitists.
Your final comment about businesses avoiding Perl 'scripters' like the plague is telling that your experiences have most likely been limited to the script kiddie types. Perl code written by professionals is developed with, at a minimum, strict, taint checking, and warnings, has the components split up into packages with only public interfaces exported, has POD documentation for all public methods in packages, uses eval blocks to catch exceptions, has global variables confined to a single package with all other variables lexically scoped, uses references extensively, and uses as verbose of a syntax as necessary to make clear the intent of a particular section of code, including but not limited to regular expression patterns. Anything less makes an unmaintainable mess, and I wouldn't want to touch it any more than I want to touch your PHP code.
But the point is, Perl gives you all the tools to not only develop quality code, but also to prevent yourself from making mistakes; it is only a matter of learning how to use them. I'd really like to see someone make a list of PHP features that contribute towards code quality, because obviously I'm missing something somewhere if it really has such features.
PHP is like MySQL, and it appeals to the same group of people. It works, most of the time. When it's not sure what to do, it does _something_ rather than annoy the programmer, which might even be the wrong thing. When it does something that might be the wrong thing, it does it silently whenever possible so there is no "squeaking" on the outside. The result is that PHP programs work most of the time, like MySQL. That sounds great, but they also have a tendency to fail in unexpected murky ways.
BTW, there is no need to be a "guru" to write Perl programs. An understanding of the syntax, as well as basic structured programming/OO principles is all that is necessary to create fast, reusable, and reliable Perl code. The problem is that frequently people lack the latter, so they jump on a language like PHP which lets them get away with not having to know such things. Such people view PHP as superior and Perl programmers as pretentious language snobs because they can do in 5 minutes in PHP what would have taken them an hour to learn how to do in Perl. That in no way invalidates the viewpoint of the Perl snob. PHP is a half-ass hack of a language that happens to be preferred by the majority of half-ass hacks of programmers out there.
Note, this is not a flame at PHP developers. I know some really good ones. I'm flaming people who suggest that PHP is a better language because it doesn't make you learn anything about software design principles. That's precisely the reason I avoid other people's PHP code whenever possible and don't recommend its use in a business environment where software infrastructure quality counts towards the bottom line.
with the USPTO
If I cared enough to be more vigilant (or was being paid to do so) I would, but I can't be bothered when there are more important things to do than keep miscreants off my network. Automated security updates for Debian work for me and haven't broken a thing compared to Microsoft updates.
Of course, the problems the license change introduced were not the sole problems. libGL was under an SGI source license which is not GPL compatible. Anyone who was distributing a GPL application linked to the GLX library for XFree86 was also in violation of the GPL already. There are a few other examples of GPL problems related to the variety of licenses that XFree86 finds acceptable to include in their codebase.
Alternately, this acknowledgment may appear in the software itself, in the same form and location as other such third-party acknowledgments.That alternate stipulation waters down the doomsday scenario you propose. The "corruption" is limited to the software itself.
The potential for the license to "spread" is exactly the same as the potential for the GPL to spread. In this case, only an attribution requirement (which can be trivially satisfied in an "About" box or in a startup message on the console) is being spread, rather than the stipulation that you must provide all of your software under a GPL-compatible license, in the case that you reused some GPL software. Putting it in perspective, it's really not all that bad. It's not nearly as bad as the advertising clause in the original BSD license, for example.Remember that the intent of this license is to prevent proprietary developers (such as those of other commercial X servers) from using XFree86 code without giving credit to the project. It was not intended to inconvenience open source developers, and it hasn't yet been made clear to me exactly how the new license is the problem with XFree86. To me, it looks like the real problem is that developers are jumping ship due to the glacial pace of development and resistance to new ideas.
If one is looking for a conservative and stable open source X server, they will find it in XFree86. However, it is being made clear that a significant number of users prefer an X server with regular feature additions and a shorter development cycle. It is unfortunately impossible to satisfy that demand within the XFree86 Project, so new options have opened up, largely thanks to people whose needs differ from XFree86 and who are willing to put in the work to improve choice in the open source world.
In short, there is no possible way on any but the fastest of current machines for a USB mouse to approximate the responsivity of a PS/2 port mouse being sampled at 200Hz (the maximum rate the port will tolerate).
GPM has always given me sporadic problems, and if you're not using the mouse on the Linux console, you don't need it at all. I think most distributions (even GUI-oriented ones) install it by default anyway for some reason.
NV and ATI, otoh, are still innovating and each product cycle is better than the last in some easily measurable way. I don't see things coming to the point that they did for open source software to gain a foothold for a while now.
I think once either NV or ATI goes out of business or drops out of the 3D race, and the remaining player continues selling the old products for the same prices, might we see people start to take matters into their own hands. By then, more powerful FPGAs and VHDL simulators will be available, not to mention more people with the requisite knowledge. For now, we sit and wait and let the market mature to the point where community-based hardware development can take over.