I thought it was, RHEL == RedHat Support, Fedora == Community Support. Fedora might have some bleeding edge stuff in it, if you upgrade often, but it seems about as stable as the corresponding RHEL release. The difference is the support you can count on.
I thought that too, but I was wrong, and it bit me in the ass. Fedora is NOT appropriate for a production environment, period. Fedora drops all support 13 months after release, which means they stop issuing security patches, period. In a production environment where you're likely to have 13 month uptimes, that would mean a reinstall every time you reboot the machine.
If you want a RedHat-based distro with long-term community support, the one you're looking for is CentOS, or so I'm told. For your desktop that you're likely to reinstall every year or so anyway, go ahead and run Fedora.
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
Perl will let you do that, although the warnings pragma will remind you "Use of uninitialized value in numeric eq (==)". But in Perl, you test whether or not something is defined with defined(), or whether a hash key exists with exists(), so you don't need a crazy === operator.
Of course you're right, and you've hit upon a very important point as well: if they hadn't done it in Perl (or VB or Access), they wouldn't have done it at all. At a certain point, this kind of kludge needs to be replaced... but a Perl kludge could be replaced with properly designed Perl, rather than switching to some other language. Sometimes it might be a better option, since some of the bits of the old code that actually work 100% of the time could be directly reused instead of ported. Sometimes it might not be a good option, particularly if most of the old Perl developers have since left the company and their successors are more familiar with another language.
Pick one of the 5 methods, not all of them. Although I guess I'm ok with #5 since it is mimicking sh scripting behavior.
Funny, that's the first one I'd avoid.
You're right that there are at least five different ways to do this, but it should be fairly obvious which way makes the most sense in a given situation. For starters, since it looks like $debug is going to be a boolean value, you don't have to compare it to 1 or 0 at all, so that eliminates two of your options (the ones that compare to 0). Writing a conditional that doesn't look like a conditional is probably not a great idea, so we can scratch #5. That leaves is with only two options:
if($debug) { print "foo\n"; }
print "foo\n" if $debug;
So which of these is the best? Well, syntax #1 is designed for multi-line blocks, while syntax #2 only allows single statements. If you're only going to be using single statements this way, #2 might be best; if you're going to be putting multiple print lines in your conditional block, then it's probably best to use #1 every time, even when you use a single-line block (in which case you should probably NOT write the whole thing on one line like this example, but go ahead and put the print statement indented on the next line).
The other consideration is, syntax #1 puts the emphasis on the condition: if we're in debug mode then stop and take a break from the normal flow of our code so we can step off to the side and print "foo" before getting back to what we were doing. Syntax #2 puts the emphasis on the print statement (which may be mixed with several other print statements), with the conditional added as an afterthought.
Some coders will pick option #2 every time, simply because it requires typing slightly fewer characters. I've been guilty of this myself, but if the idea you're trying to express doesn't lend itself to that syntax, it's better not to use it.
Perl is about the expression of ideas in code. What's the best way to express your ideas? There are many different ways to express an idea when talking to someone, but with practice we learn how to choose the way that will help us communicate most clearly. Perl isn't much different.
Many of us are simply ignoring Perl 6, therefore it can't be the problem. Perl 5 works perfectly well.
Re:Sometimes the correct answer is the simplest
on
Why Corporates Hate Perl
·
· Score: 2, Insightful
Fact that there is to much f*cked up perl code, shows that it is an inferior language.
I'd say it shows that there is a lot of perl code out there. There was a time when Perl was one of the only scripting languages that people wrote crappy code in, but now people are free to choose from Python, Ruby, PHP, Java, or other languages to write crappy code in. However, since Perl is older, more crappy code has been written for it.
I challenge you to take a random sampling of code written in the last five years, in different languages. When you exclude code written more than five years ago, you might find that Perl fares rather better, comparatively.
As many others have pointed out, you can write bad code in any language. Perl makes it very easy to write terrible code, just as Perl makes it very easy to write just about anything else. There are other languages that place obstacles between you and the bad code you're trying to write - for example, Python won't let you not indent correctly, and Java won't let you not use OOP.
When coding large applications, it is critical that certain coding standards are followed. Everybody has to play by the rules, and do things in a standardized way. Perl doesn't impose any of these rules for you automatically. If you choose not to self-impose any rules, your code will wind up being an unmaintainable mess. But no language can save you from that - if you write terrible code in Python, it's guaranteed to be nicely indented, but that doesn't mean it'll be maintainable. And, if you want to self-impose some rules to help keep your code clean, Perl Best Practices will point you in the right direction.
I highly recommend The Daily WTF?. Perl does NOT get a disproportionally large representation there.
Personally, I don't see the need for a church to have a license to sing a song, even if they make copies to hand out. We should make Christmas carolers pay a fee. And that guy with the hat on the sidewalk downtown.
Fine, except that some people professionally compose songs to be sung in church, and they do a good enough job that the songs they've written are actually sung in a lot of churches. These people deserve to be compensated for their work, based on its merit, as determined by how often worship leaders choose to include a particular song in a church service.
How else do you suggest that the composers could be paid?
Most Christmas carols sung by carolers are old enough to be in the public domain.
Remember the Excite@Home merger? Huge cable modem ISP (offering service through many different local cable companies) thought to themselves, hey, Excite runs a search engine and provides content on the Internet; we could merge with them and provide their content to our customers! And somehow our customers will want to pay us for it!
Well to be fair, and I don't remember which browsers Implement which, but the extra comma is currently invalid.
Yes, but you said "that's already there" referring to consistency across browsers. The situation is vastly better, but we're not out of the woods yet - JavaScript itself doesn't behave the same way across multiple browsers that are currently in common use (partly because there are some older browsers that are still being used).
On top of that, we have serious inconsistencies in the DOM - things like, if you put a TR inside a TABLE, Internet Explorer will silently insert a TBODY for you (because surely that must have been what you meant, right?) which means the TR isn't a child of the TABLE (it's a child of the TBODY, which is a child of the TABLE). You're right that ECMA doesn't cover this, but somebody needs to!
So is it just me, or is this just crazy theoretical stuff made up by mathematicians, with absolutely zero empirical evidence to support any of it?
He finds that stars are stable entities in roughly one-fourth of the universes he considered.
Come on. Now I know he's just making stuff up. He thought up some imaginary universes, and discovered that a quarter of them can have stars. Despite being printed in Science News, this isn't science. Maybe it's interesting math, but that's all.
Most implementations of JavaScript allow an extra comma at the end of a list. It's very handy when you've got a long list of stuff that you're rearranging periodically. But once you've finished development and everything works... then you discover that in some browsers, your page doesn't work, because in those browsers, an extra comma at the end of a list is illegal.
I think Internet Explorer and Opera were the two I had trouble with, while Firefox and Safari worked fine.
Maybe you could forward some spam from, say, a gmail account to your address in question. If it doesn't make it through to your server then you have a definitive record to confront your ISP with. Or, if they do get through, maybe you should buy a lottery ticket because your the luckiest admin on slashdot!
Sorry, this is a stupid idea.
Most of my spam filtering rules completely ignore the content of the message itself, and focus entirely on where it came from and how it was sent. If you forward spam to me from a legitimate account, it probably won't be blocked. This is by design. There's a chance it might still be blocked if it triggers enough content rules, but most spammers are pretty adept at working around the content filters.
Not only that, but each spammer has their own list of victims. Two different addresses may receive completely different spam, because they're not both on the same lists. This can account for one server seeing a drop in spam volume while another server doesn't: users on the first server are on the list of a spammer who took a vacation; users on the second server aren't on that spammer's list.
Yeah, something like that. Think VNC server with PS/2 and VGA cables on the other end. As far as your server is concerned, it looks like a keyboard/mouse/monitor are connected (just like a regular KVM switch), but you can connect to it remotely. You can go into BIOS setup, you can look at the settings for your RAID controller at boot time, choose a kernel from your lilo/grub menu, view the message on screen during a kernel panic, etc.
I've never actually used one, because I don't know anyone who can afford them.
Here's a tip: if you have a very large filesystem that is NOT your root filesystem, e.g. something only used for SMB or NFS sharing, kill the processes that need to access it, unmount it, and run fsck before you reboot the box. Those services will be offline for awhile, but they would have been anyway while fsck was running at boot time. This way, you get to see the progress (and any errors that come up), and the rest of the box doesn't have to remain offline for an hour or two after reboot.
It's not a bad idea to do this at regular intervals anyway. An hour of planned downtime after business hours every three months is significantly less annoying than waiting for fsck to scan your file server after an unplanned reboot (UPS failure, hardware replacement, etc.).
(BTW, why the fuck is the comment box ~35 characters wide?)
Safari allows textarea boxes, including Slashdot comment boxes, to be arbitrarily resized by the user. But I've always thought the default size seemed pretty reasonable to me.
I disagree. Remember that when the iPod was originally introduced, it was Mac-only. Windows compatibility wasn't even offered; this was a Macintosh accessory targeted at Mac users. Apple was filling a niche: most other portable MP3 players were not Mac compatible. Apple had recently released iTunes (which they'd bought from another company and rebranded) and wanted a portable MP3 player that could integrate with it, taking "Rip, Mix, Burn" to the next level.
It was precisely the Apple branding that allowed the iPod to become successful in this market. With Apple's name on it, Mac users could be assured that the product would work well for them; with any other name on it, most Mac users would naturally assume the opposite. Apple's brand carried with it the reputation for designing elegant and intuitive user interfaces; many people who had seen the clunky interfaces of competing devices were willing to try the iPod because they felt the brand name virtually guaranteed that the interface would far outshine the competition.
The next step was to introduce Windows compatibility (by working with MusicMatch to add support to that company's Jukebox application). By this time, the iPod was already successful, but Windows compatibility opened it up to a much larger market. Finally, a year and a half after the iPod was introduced, Apple released iTunes for Windows.
1. They don't know everything about your browsing habits.
3. They don't know what products you prefer to buy, how much you are willing to pay for them (if you are using google checkout)
Your local TV station doesn't have this information about you individually, and maybe they didn't acquire it themselves through technical means, but you can be DAMN sure they have a pretty good idea what their viewing audience is up to collectively.
No, they don't know who e-mails you... but Google doesn't know who e-mails me either, because I choose not to use GMail, even though I do use several of their other services.
There are a few interesting points in your post: It all hinges on the "reasonable expectation of privacy".
If I'm walking down a public road, and I look around and don't see anyone nearby, do I have a "reasonable expectation of privacy"?
Is there legal distinction between short term privacy and long term privacy? e.g. Is my expectation that people will not follow me around for any significant period of time "reasonable" under the US constitution?
You've hit the nail on the head here. I don't consider attaching a GPS tracker to my car to be "reasonable". The police (or anyone else) are free to watch me while I move around in public, but I understand that it costs them significant resources to do so, so unless they have a damn good reason it's just not worth their time. Of course, if they suspect me of a crime, that's probably a good reason, so yeah, they might follow me around.
So here's my take on it: if the police don't have probable cause to suspect me of a crime, then it is not reasonable for them to track my movements. If I haven't done anything to give them probable cause, then I can reasonably expect that they aren't following me.
Slashdot Mirror
I thought it was, RHEL == RedHat Support, Fedora == Community Support. Fedora might have some bleeding edge stuff in it, if you upgrade often, but it seems about as stable as the corresponding RHEL release. The difference is the support you can count on.
I thought that too, but I was wrong, and it bit me in the ass. Fedora is NOT appropriate for a production environment, period. Fedora drops all support 13 months after release, which means they stop issuing security patches, period. In a production environment where you're likely to have 13 month uptimes, that would mean a reinstall every time you reboot the machine.
If you want a RedHat-based distro with long-term community support, the one you're looking for is CentOS, or so I'm told. For your desktop that you're likely to reinstall every year or so anyway, go ahead and run Fedora.
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
Perl will let you do that, although the warnings pragma will remind you "Use of uninitialized value in numeric eq (==)". But in Perl, you test whether or not something is defined with defined(), or whether a hash key exists with exists(), so you don't need a crazy === operator.
I don't think he meant "you" personally, but was referring to the large number of people who don't understand how to use JavaScript properly.
Of course you're right, and you've hit upon a very important point as well: if they hadn't done it in Perl (or VB or Access), they wouldn't have done it at all. At a certain point, this kind of kludge needs to be replaced... but a Perl kludge could be replaced with properly designed Perl, rather than switching to some other language. Sometimes it might be a better option, since some of the bits of the old code that actually work 100% of the time could be directly reused instead of ported. Sometimes it might not be a good option, particularly if most of the old Perl developers have since left the company and their successors are more familiar with another language.
Pick one of the 5 methods, not all of them. Although I guess I'm ok with #5 since it is mimicking sh scripting behavior.
Funny, that's the first one I'd avoid.
You're right that there are at least five different ways to do this, but it should be fairly obvious which way makes the most sense in a given situation. For starters, since it looks like $debug is going to be a boolean value, you don't have to compare it to 1 or 0 at all, so that eliminates two of your options (the ones that compare to 0). Writing a conditional that doesn't look like a conditional is probably not a great idea, so we can scratch #5. That leaves is with only two options:
So which of these is the best? Well, syntax #1 is designed for multi-line blocks, while syntax #2 only allows single statements. If you're only going to be using single statements this way, #2 might be best; if you're going to be putting multiple print lines in your conditional block, then it's probably best to use #1 every time, even when you use a single-line block (in which case you should probably NOT write the whole thing on one line like this example, but go ahead and put the print statement indented on the next line).
The other consideration is, syntax #1 puts the emphasis on the condition: if we're in debug mode then stop and take a break from the normal flow of our code so we can step off to the side and print "foo" before getting back to what we were doing. Syntax #2 puts the emphasis on the print statement (which may be mixed with several other print statements), with the conditional added as an afterthought.
Some coders will pick option #2 every time, simply because it requires typing slightly fewer characters. I've been guilty of this myself, but if the idea you're trying to express doesn't lend itself to that syntax, it's better not to use it.
Perl is about the expression of ideas in code. What's the best way to express your ideas? There are many different ways to express an idea when talking to someone, but with practice we learn how to choose the way that will help us communicate most clearly. Perl isn't much different.
Many of us are simply ignoring Perl 6, therefore it can't be the problem. Perl 5 works perfectly well.
Fact that there is to much f*cked up perl code, shows that it is an inferior language.
I'd say it shows that there is a lot of perl code out there. There was a time when Perl was one of the only scripting languages that people wrote crappy code in, but now people are free to choose from Python, Ruby, PHP, Java, or other languages to write crappy code in. However, since Perl is older, more crappy code has been written for it.
I challenge you to take a random sampling of code written in the last five years, in different languages. When you exclude code written more than five years ago, you might find that Perl fares rather better, comparatively.
As many others have pointed out, you can write bad code in any language. Perl makes it very easy to write terrible code, just as Perl makes it very easy to write just about anything else. There are other languages that place obstacles between you and the bad code you're trying to write - for example, Python won't let you not indent correctly, and Java won't let you not use OOP.
When coding large applications, it is critical that certain coding standards are followed. Everybody has to play by the rules, and do things in a standardized way. Perl doesn't impose any of these rules for you automatically. If you choose not to self-impose any rules, your code will wind up being an unmaintainable mess. But no language can save you from that - if you write terrible code in Python, it's guaranteed to be nicely indented, but that doesn't mean it'll be maintainable. And, if you want to self-impose some rules to help keep your code clean, Perl Best Practices will point you in the right direction.
I highly recommend The Daily WTF?. Perl does NOT get a disproportionally large representation there.
Personally, I don't see the need for a church to have a license to sing a song, even if they make copies to hand out. We should make Christmas carolers pay a fee. And that guy with the hat on the sidewalk downtown.
Fine, except that some people professionally compose songs to be sung in church, and they do a good enough job that the songs they've written are actually sung in a lot of churches. These people deserve to be compensated for their work, based on its merit, as determined by how often worship leaders choose to include a particular song in a church service.
How else do you suggest that the composers could be paid?
Most Christmas carols sung by carolers are old enough to be in the public domain.
Remember the Excite@Home merger? Huge cable modem ISP (offering service through many different local cable companies) thought to themselves, hey, Excite runs a search engine and provides content on the Internet; we could merge with them and provide their content to our customers! And somehow our customers will want to pay us for it!
A couple years later the whole company was gone.
Obligatory xkcd
Well to be fair, and I don't remember which browsers Implement which, but the extra comma is currently invalid.
Yes, but you said "that's already there" referring to consistency across browsers. The situation is vastly better, but we're not out of the woods yet - JavaScript itself doesn't behave the same way across multiple browsers that are currently in common use (partly because there are some older browsers that are still being used).
On top of that, we have serious inconsistencies in the DOM - things like, if you put a TR inside a TABLE, Internet Explorer will silently insert a TBODY for you (because surely that must have been what you meant, right?) which means the TR isn't a child of the TABLE (it's a child of the TBODY, which is a child of the TABLE). You're right that ECMA doesn't cover this, but somebody needs to!
So is it just me, or is this just crazy theoretical stuff made up by mathematicians, with absolutely zero empirical evidence to support any of it?
He finds that stars are stable entities in roughly one-fourth of the universes he considered.
Come on. Now I know he's just making stuff up. He thought up some imaginary universes, and discovered that a quarter of them can have stars. Despite being printed in Science News, this isn't science. Maybe it's interesting math, but that's all.
And you people think Creationists are nuts...
Most implementations of JavaScript allow an extra comma at the end of a list. It's very handy when you've got a long list of stuff that you're rearranging periodically. But once you've finished development and everything works... then you discover that in some browsers, your page doesn't work, because in those browsers, an extra comma at the end of a list is illegal.
I think Internet Explorer and Opera were the two I had trouble with, while Firefox and Safari worked fine.
Maybe you could forward some spam from, say, a gmail account to your address in question. If it doesn't make it through to your server then you have a definitive record to confront your ISP with. Or, if they do get through, maybe you should buy a lottery ticket because your the luckiest admin on slashdot!
Sorry, this is a stupid idea.
Most of my spam filtering rules completely ignore the content of the message itself, and focus entirely on where it came from and how it was sent. If you forward spam to me from a legitimate account, it probably won't be blocked. This is by design. There's a chance it might still be blocked if it triggers enough content rules, but most spammers are pretty adept at working around the content filters.
Not only that, but each spammer has their own list of victims. Two different addresses may receive completely different spam, because they're not both on the same lists. This can account for one server seeing a drop in spam volume while another server doesn't: users on the first server are on the list of a spammer who took a vacation; users on the second server aren't on that spammer's list.
Yeah, something like that. Think VNC server with PS/2 and VGA cables on the other end. As far as your server is concerned, it looks like a keyboard/mouse/monitor are connected (just like a regular KVM switch), but you can connect to it remotely. You can go into BIOS setup, you can look at the settings for your RAID controller at boot time, choose a kernel from your lilo/grub menu, view the message on screen during a kernel panic, etc.
I've never actually used one, because I don't know anyone who can afford them.
Here's a tip: if you have a very large filesystem that is NOT your root filesystem, e.g. something only used for SMB or NFS sharing, kill the processes that need to access it, unmount it, and run fsck before you reboot the box. Those services will be offline for awhile, but they would have been anyway while fsck was running at boot time. This way, you get to see the progress (and any errors that come up), and the rest of the box doesn't have to remain offline for an hour or two after reboot.
It's not a bad idea to do this at regular intervals anyway. An hour of planned downtime after business hours every three months is significantly less annoying than waiting for fsck to scan your file server after an unplanned reboot (UPS failure, hardware replacement, etc.).
(BTW, why the fuck is the comment box ~35 characters wide?)
Safari allows textarea boxes, including Slashdot comment boxes, to be arbitrarily resized by the user. But I've always thought the default size seemed pretty reasonable to me.
Except that this particular article was on the front page - that's where I saw it.
The branding of Apple hurt iPod sales in 2001
I disagree. Remember that when the iPod was originally introduced, it was Mac-only. Windows compatibility wasn't even offered; this was a Macintosh accessory targeted at Mac users. Apple was filling a niche: most other portable MP3 players were not Mac compatible. Apple had recently released iTunes (which they'd bought from another company and rebranded) and wanted a portable MP3 player that could integrate with it, taking "Rip, Mix, Burn" to the next level.
It was precisely the Apple branding that allowed the iPod to become successful in this market. With Apple's name on it, Mac users could be assured that the product would work well for them; with any other name on it, most Mac users would naturally assume the opposite. Apple's brand carried with it the reputation for designing elegant and intuitive user interfaces; many people who had seen the clunky interfaces of competing devices were willing to try the iPod because they felt the brand name virtually guaranteed that the interface would far outshine the competition.
The next step was to introduce Windows compatibility (by working with MusicMatch to add support to that company's Jukebox application). By this time, the iPod was already successful, but Windows compatibility opened it up to a much larger market. Finally, a year and a half after the iPod was introduced, Apple released iTunes for Windows.
1. They don't know everything about your browsing habits.
3. They don't know what products you prefer to buy, how much you are willing to pay for them (if you are using google checkout)
Your local TV station doesn't have this information about you individually, and maybe they didn't acquire it themselves through technical means, but you can be DAMN sure they have a pretty good idea what their viewing audience is up to collectively.
No, they don't know who e-mails you... but Google doesn't know who e-mails me either, because I choose not to use GMail, even though I do use several of their other services.
There are a few interesting points in your post: It all hinges on the "reasonable expectation of privacy".
If I'm walking down a public road, and I look around and don't see anyone nearby, do I have a "reasonable expectation of privacy"?
Is there legal distinction between short term privacy and long term privacy? e.g. Is my expectation that people will not follow me around for any significant period of time "reasonable" under the US constitution?
You've hit the nail on the head here. I don't consider attaching a GPS tracker to my car to be "reasonable". The police (or anyone else) are free to watch me while I move around in public, but I understand that it costs them significant resources to do so, so unless they have a damn good reason it's just not worth their time. Of course, if they suspect me of a crime, that's probably a good reason, so yeah, they might follow me around.
So here's my take on it: if the police don't have probable cause to suspect me of a crime, then it is not reasonable for them to track my movements. If I haven't done anything to give them probable cause, then I can reasonably expect that they aren't following me.
Problem is that you have to retrieve it somehow or the cops will certainly know they've been had as soon as they try to recover their bug.
Um, why wouldn't you want them to know?
Here's the article about that incident: Rubbish!