Maintainability vs. Extensibility
on
Perl Medic
·
· Score: 0
As explained above, many perl programs are no longer maintainable because of the extensibility of the language. As some perl modules rise in popularity, some fall - an example is the old LDAP library mentioned above that is no longer usable on new perl versions.
For quick hacks, if it can be done with awk, I will do so. If it requires date processing, I will use gawk. I am not above shelling out to ldapsearch from awk because I will have to maintain fewer complex package installations.
I will only fall back to perl when I need access to system calls or other facilities that the more primitive UNIX tools do not provide (and I am not willing to write the utility in C).
I do this because I like easy portability. Perl's extensibility precludes this approach.
Properly typing in a 50+ character alphanumeric key is stressful. Managing a collection of dozens or hundreds of these keys is also very stressful. With BSD/GPL software, I can throw the keys away.
I have lots of Oracle 7/8 databases. Oracle would like me to upgrade right now (and send them a big check). If I was on an old release of Postgres or MySQL, I would have the option of contracting out maintenance of the code to a 3rd party. I have no options for code updates to Oracle 7 (apart from writing a potentially much bigger check to Oracle).
For these reasons (and others), I'm beginning to believe that friends don't let friends use proprietary software.
This way the accidentally blacklisted server has several days to straighten things out while the really spammy server gets overloaded with huge mail queue.
Most spam engines don't use a mail queue, which is why greylisting works so well.
Capitalism when unchecked tends to devolve to monopoly/oligarchy/facism. Since governmental regulation of M$ has failed (Pensfield-Jackson's breakup order was shelved), the GPL is the only tool available to the market to blunt the monopoly power of M$.
Even devoid of monopoly conditions, there is still ample justification for GPL/BSD software. All of us have invested time in proprietary systems that vendors have desupported or withdrawn. Free software liberates your career from these conditions. Proprietary software will always die regardless of users; free software only dies when abandoned by users.
...start a "contributed hardware driver" website. This should allow anyone to contribute a driver (or changes to the driver) with documentation of what it supports or what it fixes.
The website should have a radiobutton for the license chosen by the author (BSD, SCSL or whatever Sun is using, etc.).
Members who have contributed drivers should be able to "mod up/down" other drivers. Sun engineers should then act as "moderators" and include portions of these drivers in the base distribution. dmesg output should list the (outside) authors of active drivers in the kernel.
Actually, they ought to open up the whole OS to this sort of public contribution. Give credit, as this could boost someone's career. (Just being in the AIX faq is occasionally something that raises an eyebrow in a job interview.)
The 386 introduced a 32-bit addressing mode and MMU capabilities which are required by modern, preemptively multitasking OSes.
Intel has been very careful to copy all of AMD64's 64-bit extensions into EM64T. There is no benefit, from a processor instruction set perspective, of AMD to Intel (assuming that Intel has MX).
The issue is not as critical as the Deskpro/386 was to the PS2. AFAIK, IBM hesitated on the 386 from fear that it threatened their other lowend/midrange systems (the s36/as400, for example).
I just strongly disagree that Apple is anywhere NEAR the RIAA.
They're not suing their customers. They're suing to get information. The RIAA is extorting money from its customers. BIG DIFFERENCE.
iTunes (loss to Apple) drives iPod sales (profit to Apple)
iPod sales are now supposed to drive Mini Mac sales
When this entire plan is enacted, it seems that a substantial percentage of Apple hardware sales will flow from the RIAA association with iTunes
Both Apple and the RIAA are lawsuit-happy - Apple hits jobless college students, so does the RIAA
Apple did exactly what you wanted and the answer was no way. Now what do you do? Sue? Walk away? What?
Oh, I think that Steve Jobs has sufficient resources at his disposal to cajole names out of these people.
For heaven's sake, these are fan sites. If Jobs was willing to share the stage with DePlume for the introduction of imac v27, the name would probably be quickly forthcoming (especially with a promise of no retaliation).
This was Apple's mistake, and Apple will pay for it one way or another. Writing a big check and energizing your fans is the smart way to do it. Getting the EFF upset with you is not so smart.
...politely invite the journalists to my office (paying their expenses).
I would then politely ask to communicate with the leaker. I would promise no penalties in exchange for this.
Is it more important for Apple to punish or to understand and improve the process that failed to keep their secrets? The leak was not Apple's fault, but the process was.
In all things in life, just because you can do something doesn't mean that you should. Corporate titans that trample individuals who cross them at every opportunity all end up paying in the end. All companies die, but some can do so very quickly.
I think that a few quarters of heavy losses would be an excellent way to get Apple's attention for their legal but reprehensible behavior.
Apple chose the RIAA as a bedfellow, and has adopted their tactics.
If news of new technology leaked about an IBM or Intel technology, I doubt that we'd see lawsuits. Apple is very quick on this trigger, and the news media might just be able to convince the judiciary to see it this way.
I don't really understand Apple's rabid lust for secrecy. It is my earnest hope that their product lines suffer until they get out of the business of suing their customers.
Some forms of Human Papilloma Virus are classed as STDs (and some are highly carcinogenic). Perhaps somebody at the office was doing something interesting in the course of obtaining them?
In any case, encourage all the women around you to stay current on their PAP smears - HPV is especially risky for them.
Rather than strapping our country into a PSTN that was never designed for DSL data rates, we should have a free-for-all on wifi, where anyone with the dollars can set up a subscription network.
Land-line broadband is hopelessly bundled with services that I don't want (cable tv, POTS). wifi is the only hope for unbundled broadband.
It is tempting to let municipalities do wifi - they would do it well, but the phone companies will always be at their throats with the legislative process.
I'd rather see the FCC set aside much more wifi bandwidth, and have my pick of 50 providers. I probably won't get that either, since everyone in government is bought and paid for.
I can see why a developer would take a previously existant ftp implementation and rework it, it saves time not having to recode parts that can be used over.
I am assuming that vsftp's developer did not do so because he thought that BSD ftpd's design was flawed, as previously indicated.
I was more saying this to point out that while you said it wrong to not use vsftpd since they are already there they had done just as you speak against previously.
But chroot/privsep is a trend that has been moving through OpenBSD userland for some time. vsftpd has not only taken this message to heart, but they have also added TLS encryption.
Now OpenBSD is in the strange position of ignoring code that follows their own "architectural spirit" because of the GPL (and working to propigate the unsafe FTP protocol when such time is more productively spent elsewhere).
Yes, you can see the flaws in my logic. Can you see the flaws in theirs?
The funnny thing with saying why make a new one, beyond that you support making another CVS, is that the BSD ftpd was around first, so why did the vsftpd makers not just improve the BSD ftpd?
I support OpenCVS because the current CVS code is a mess and has suffered several security problems. Effort is obviously needed there.
As to the BSD ftp daemon's previous existence, why patch a broken design? I am not a developer, so I'm just going to quote vsftpd's website:
vsftpd was designed and implemented from the ground up with security it mind. It fixes fundamental design flaws present in most installations of wu-ftpd, proftpd and even bsd-ftpd by not over-using the dangerous root user.
I don't know about "less safe", but in 3.7 they will have a privelege separated version of ftpd.
Why not audit/adopt an existing solution, rather than develop a new one? vsftpd also (optionally) implements TLS, which is currently beyond BSD's ftpd.
ftp.usa.openbsd.org runs OpenBSD 3.6 apparently, but it runs ftpd 6.6 (The one with privsep, 6.5 is in 3.6). It seems to be doing fine.
So you're telling me that running beta code on a production server is a good security practice? Is this the message that OpenBSD should be sending? Granted, the code may have been through the audit process, but it is not in STABLE AFAIK.
Why? Both license and security are very important. I'd think that license is just as important as security.
FTP is (or should be) a non-critical protocol - saavy admins should deploy it with great reluctance for production use and should thoroughly contain it. As such, it is not worth the development effort for OpenBSD to retrofit these features onto the BSD ftpd. A GPL version might even be better to prevent further spread. vsftpd should have been used instead. (I'd rather see developers concentrating on OpenCVS.)
But then again, it is not my place to be critical of this (phyrric) victory, and I myself use OpenBSD's ftpd (for convenience reasons).
Like most of the GPLed software people miss in the BSDs, vsftpd can be installed from ports very easily.
Yes, but the base system should be trusted. vsftpd is superior, both from a functionality and a security perspective. The license is then my first suspicion explaining its lack in base.
vsftpd does seem to (over)rely on PAM, which might have further bearing.
vsftpd is much safer than ftpd because it doesn't work as root so much.
Without a doubt, OpenBSD is giving us a less safe piece of software (because they don't want to include GPL code). Even OpenBSD's servers use vsftpd (in preferance to BSD ftpd) because of security and performance reasons.
It would be interesting to see a distribution that insisted on secure code, without fretting about licensing.
Slashdot Mirror
As explained above, many perl programs are no longer maintainable because of the extensibility of the language. As some perl modules rise in popularity, some fall - an example is the old LDAP library mentioned above that is no longer usable on new perl versions.
For quick hacks, if it can be done with awk, I will do so. If it requires date processing, I will use gawk. I am not above shelling out to ldapsearch from awk because I will have to maintain fewer complex package installations.
I will only fall back to perl when I need access to system calls or other facilities that the more primitive UNIX tools do not provide (and I am not willing to write the utility in C).
I do this because I like easy portability. Perl's extensibility precludes this approach.
Properly typing in a 50+ character alphanumeric key is stressful. Managing a collection of dozens or hundreds of these keys is also very stressful. With BSD/GPL software, I can throw the keys away.
I have lots of Oracle 7/8 databases. Oracle would like me to upgrade right now (and send them a big check). If I was on an old release of Postgres or MySQL, I would have the option of contracting out maintenance of the code to a 3rd party. I have no options for code updates to Oracle 7 (apart from writing a potentially much bigger check to Oracle).
For these reasons (and others), I'm beginning to believe that friends don't let friends use proprietary software.
Most spam engines don't use a mail queue, which is why greylisting works so well.
Capitalism when unchecked tends to devolve to monopoly/oligarchy/facism. Since governmental regulation of M$ has failed (Pensfield-Jackson's breakup order was shelved), the GPL is the only tool available to the market to blunt the monopoly power of M$.
Even devoid of monopoly conditions, there is still ample justification for GPL/BSD software. All of us have invested time in proprietary systems that vendors have desupported or withdrawn. Free software liberates your career from these conditions. Proprietary software will always die regardless of users; free software only dies when abandoned by users.
Proprietary software is crippleware.
...start a "contributed hardware driver" website. This should allow anyone to contribute a driver (or changes to the driver) with documentation of what it supports or what it fixes.
The website should have a radiobutton for the license chosen by the author (BSD, SCSL or whatever Sun is using, etc.).
Members who have contributed drivers should be able to "mod up/down" other drivers. Sun engineers should then act as "moderators" and include portions of these drivers in the base distribution. dmesg output should list the (outside) authors of active drivers in the kernel.
Actually, they ought to open up the whole OS to this sort of public contribution. Give credit, as this could boost someone's career. (Just being in the AIX faq is occasionally something that raises an eyebrow in a job interview.)
The 386 introduced a 32-bit addressing mode and MMU capabilities which are required by modern, preemptively multitasking OSes.
Intel has been very careful to copy all of AMD64's 64-bit extensions into EM64T. There is no benefit, from a processor instruction set perspective, of AMD to Intel (assuming that Intel has MX).
The issue is not as critical as the Deskpro/386 was to the PS2. AFAIK, IBM hesitated on the 386 from fear that it threatened their other lowend/midrange systems (the s36/as400, for example).
If it walks like a duck...
It is neither you nor I who will determine who is right or wrong. Two forces will do this: the judiciary and the market.
The judiciary will try to find some enforcable logic that is fair to all.
The market is much less concered with "fair" - people are fickle, and, like me, take high offense at the slightest of provocations.
Apple has tied itself to the RIAA, which is going to die sooner or later. They'd best not step too close.
Well, everyone has to pick a side. As I type this into my beige g3[4], I'm comfortable that I haven't picked yours.
Oh, I think that Steve Jobs has sufficient resources at his disposal to cajole names out of these people.
For heaven's sake, these are fan sites. If Jobs was willing to share the stage with DePlume for the introduction of imac v27, the name would probably be quickly forthcoming (especially with a promise of no retaliation).
This was Apple's mistake, and Apple will pay for it one way or another. Writing a big check and energizing your fans is the smart way to do it. Getting the EFF upset with you is not so smart.
...politely invite the journalists to my office (paying their expenses).
I would then politely ask to communicate with the leaker. I would promise no penalties in exchange for this.
Is it more important for Apple to punish or to understand and improve the process that failed to keep their secrets? The leak was not Apple's fault, but the process was.
In all things in life, just because you can do something doesn't mean that you should. Corporate titans that trample individuals who cross them at every opportunity all end up paying in the end. All companies die, but some can do so very quickly.
I think that a few quarters of heavy losses would be an excellent way to get Apple's attention for their legal but reprehensible behavior.
Apple chose the RIAA as a bedfellow, and has adopted their tactics.
If news of new technology leaked about an IBM or Intel technology, I doubt that we'd see lawsuits. Apple is very quick on this trigger, and the news media might just be able to convince the judiciary to see it this way.
I don't really understand Apple's rabid lust for secrecy. It is my earnest hope that their product lines suffer until they get out of the business of suing their customers.
They can keep their Tiger, thanks.
Some forms of Human Papilloma Virus are classed as STDs (and some are highly carcinogenic). Perhaps somebody at the office was doing something interesting in the course of obtaining them?
In any case, encourage all the women around you to stay current on their PAP smears - HPV is especially risky for them.
Rather than strapping our country into a PSTN that was never designed for DSL data rates, we should have a free-for-all on wifi, where anyone with the dollars can set up a subscription network.
Land-line broadband is hopelessly bundled with services that I don't want (cable tv, POTS). wifi is the only hope for unbundled broadband.
It is tempting to let municipalities do wifi - they would do it well, but the phone companies will always be at their throats with the legislative process.
I'd rather see the FCC set aside much more wifi bandwidth, and have my pick of 50 providers. I probably won't get that either, since everyone in government is bought and paid for.
A little too close for comfort.
drivel - To slobber; drool. To flow like spittle or saliva. To talk stupidly or childishly.
trivia - Something of small importance.
...doesn't Debian have more exposure to running on alternative kernels? (i.e. Debian/NetBSD, Debian/HURD)
...Because you're not going to get it.
A financial settlement with a fresh college grad? You ought to be ashamed of yourselves.
Not even Microsoft is this obnoxious.
I am assuming that vsftp's developer did not do so because he thought that BSD ftpd's design was flawed, as previously indicated.
But chroot/privsep is a trend that has been moving through OpenBSD userland for some time. vsftpd has not only taken this message to heart, but they have also added TLS encryption.
Now OpenBSD is in the strange position of ignoring code that follows their own "architectural spirit" because of the GPL (and working to propigate the unsafe FTP protocol when such time is more productively spent elsewhere).
Yes, you can see the flaws in my logic. Can you see the flaws in theirs?
I support OpenCVS because the current CVS code is a mess and has suffered several security problems. Effort is obviously needed there.
As to the BSD ftp daemon's previous existence, why patch a broken design? I am not a developer, so I'm just going to quote vsftpd's website:
vsftpd was designed and implemented from the ground up with security it mind. It fixes fundamental design flaws present in most installations of wu-ftpd, proftpd and even bsd-ftpd by not over-using the dangerous root user.
From the vsftpd website...
IBM recommend vsftpd in their paper "Securing Linux Servers for Service Providers". It is top in a section entitled "Recommended FTP servers".
Why not audit/adopt an existing solution, rather than develop a new one? vsftpd also (optionally) implements TLS, which is currently beyond BSD's ftpd.
So you're telling me that running beta code on a production server is a good security practice? Is this the message that OpenBSD should be sending? Granted, the code may have been through the audit process, but it is not in STABLE AFAIK.
FTP is (or should be) a non-critical protocol - saavy admins should deploy it with great reluctance for production use and should thoroughly contain it. As such, it is not worth the development effort for OpenBSD to retrofit these features onto the BSD ftpd. A GPL version might even be better to prevent further spread. vsftpd should have been used instead. (I'd rather see developers concentrating on OpenCVS.)
But then again, it is not my place to be critical of this (phyrric) victory, and I myself use OpenBSD's ftpd (for convenience reasons).
Yes, but the base system should be trusted. vsftpd is superior, both from a functionality and a security perspective. The license is then my first suspicion explaining its lack in base.
vsftpd does seem to (over)rely on PAM, which might have further bearing.
vsftpd is much safer than ftpd because it doesn't work as root so much.
Without a doubt, OpenBSD is giving us a less safe piece of software (because they don't want to include GPL code). Even OpenBSD's servers use vsftpd (in preferance to BSD ftpd) because of security and performance reasons.
It would be interesting to see a distribution that insisted on secure code, without fretting about licensing.
...but I want to see some of my old favorites, via a Bittorrent download (so I can watch when I want). I'll agree to some DRM. Which ones?
I'd also like to check out a few that I've missed.
Just browsing the BBC's library would be a real trip. How about comments section on each episode and a user-ratings system?
Just imagine, I might never watch a major US network again! (Not that I watch much now.)
...that the Mozilla suite code is of higher security than Firefox, then I will dump Firefox like a hot potato and never look back.
For the same reason that I use OpenBSD, I would avoid a risky browser.
I was not aware of the difference in auditing between the two applications. What should I know?