Bram figured this out with BitTorrent- the server can instruct the client on when it should next check back.... and most clients ignore it completely. I've seen clients reannounce every 5 minutes even though the tracker says 30. Nice idea, but in the real world it doesn't work that way.
A telesync doesn't necessarily have to take audio directly from the mixer. Usually it's just someone sitting in the "assistive hearing" seat and recording from the audio jack.
Nor does a TS have to be in a closed theater. I've seen plenty with audience members present.
The only thing a telesync really denotes is that the video and audio were recorded seperately and synchronized together later.
Why in the world are "39.4" and "40" listed as incorrect? Hello, has anyone heard of rounding and significant digits? If you want to express it in three significant digits then 39.4 would be absolutely correct, as would 40 if you only had 2 significant figures.
That's because backup MXs are an anachronism of a time when sites weren't always connected to the net. If your primary MX goes down all legitimate senders will queue the message and keep trying for quite some time. There's no need for a redundant 3rd party MX on the modern internet. If you want extra assurance then run dual MXes on-site so if one must go down the other will handle the load. But the whole "external" MX idea is just outdated.
"my mail server HAS to accept the message first" -- not true at all
If you used exim/exiscan/spamassassin/clamav you could do all that scanning at delivery time and reject the message after the DATA phase with a 5xx code. My mailserver rejects spam and malware at the SMTP transaction time. I know there are similar schemes for other MTAs.
Good point. Conspicuously lacking in their list of things ISPs should do is "Provide ample staffing for your abuse desk, give them adequate power to shut down abusers, and respond quickly to abuse reports."
If every ISP had an Afterburner-esque person in charge of the abuse desk, then the amount of spam-support sites, trojaned zombies, and general malfeasance would go way down. To all you ISPs who redirect abuse@ mail to/dev/null: wake the hell up and start becoming part of the solution.
Re:I can't take a security sight seriously that...
on
PHP and SQL Security
·
· Score: 1
You are correct, even though you were being funny. This person has no idea what he's talking about. On a site that's supposed to be about PHP security, let's look at one of his examples in his "tutorials" (which are terrible):
Now let's see, in this simple example what do we have:
- Reliance on register_globals turned ON. The PHP developers made a huge mistake by leaving this the default as long as they did, but fortunately they changed it to OFF by default some time ago. It is an abomination, and a script that requires it is just asking for XSS or SQL injection vulerabilities. This above example both relies on $submit being automatically registered, as well as using its value without any kind of validation! That's simply inexcusable.
- But far worse, he outputs $name with absolutely no quoting! HELLO! at the very least run htmlspecialchars() over it, otherwise this script is totally open to abuse.
I cannot take seriously any site that is ostensibly about PHP security and has an example like this in their pathetic tutorials. Some of ther other tutorials include "the magic of the echo command". Wow, thanks for that. Let's leave the "Introduction to PHP basics" to the authors that are paid to write, okay?
In short, with CVS you check out files from the repository, work on them (edit, compile, test, whatever) and when they are in a suitable state you check them back in (commit) which causes the version number associated with each file to automatically increase. If your working dir is in a particularly interesting state, for example a release version, then you create a "tag" which saves that state, essentially remembering the version number of each file for the current configuration.
As far as automatically-generated files, the standard practice is to not keep them in CVS. So say you have foo.sh which creates bar.c and baz.c. You add code to your makefile so that it knows that if bar.c or baz.c need updating that foo.sh is to be run. foo.sh is kept in the repository and is versioned, but bar and baz are not, they are just regular files in the working directory. When you start with a fresh checkout they will not exist, but when you run make they will be generated. Typically each developer maintains his/her working directory so it's not like these files need to be created every time. Essentially, you don't keep autogenerated things in the repository because they can always be generated in your working dir. If the generation is not automated then you might choose to include them, however.
CVS is generally intended for text files, but it can also be used with binary files but it will be inefficient. Don't store large binaries in the repository, if possible.
If you, like me, tried to read the linked article and found out that it had absolutely nothing to do with the write-up, then you realized that the person that posted this used a link that was only valid while the feature was "current" on the site. Shame on you.
A permanent link, for the archives and anyone that reads this past the first week, is below.
Bullshit. The only thing that a telesync denotes is that the audio was recorded seperately from the video and then synced up later. Usually it's from the "assisted listening for those hard of hearing" jack, and by no means does the word imply that the camera was in the booth. I can't tell you how many telesync's I've seen filmed at awkward keystone off-center angles, with profiles of people walking in front of the camera, and so on.
There is no license in effect. It's pure copyright law. Copyright law dictates the right to copy, reproduce, perform publicly, make derivative works of, etc. Filming the screen is making a copy of a work, and thus the holder of the copyright can dictate the terms under which such copying is allowed. It's as simple as that. Don't drag out contracts or licenses into the discussion, they are completely irrelevant.
Thank you. I too am tired of seeing "You sent me a virus" messages on mailing lists. That's allmost a sure sign that some braindead software somewhere replied to the "From:" address and not the envelope-FROM address, which is where all automated delivery status messages are to go.
In my opinion, the very best thing is to do scanning at SMTP-time. This is very easy with Exim (with the exiscan-acl patch) and clamav, both 100% GPL. By scanning during the DATA phase of message delivery, you can reply with a 5xx code if it's malware. That way, the bounce is not your problem.
For those of you not familiar with the finer points of SMTP, as soon as you accept the message you are responsible for its delivery. That means if it's for a nonexistant user (as many of these malware floods are) or if it's otherwise determined to be undeliverable, you're reponsible for the bounce. Now, please don't take that as saying I think you should bounce malware, I'm just saying that per SMTP once you accept the message its your responsibility to deliver it, which leads to the quandary of "Do I generate a bounce or not?"
However, if you scan the message BEFOER accepting it (during the DATA phase) then you can reply to the other end that you are not accepting the message. This is sometimes called a hard bounce. It does two things: It ensures the end-to-end reliability that everyone wants out of email[1], and it means you don't have to make a "damned if I do, damned if I don't" decision about bounces.
The biggest downside of this is that it's more resource intensive as you must hold open the connection while you scan, so you tend to have more mail daemons waiting around in memory. It also doesn't work if you're running a "store and forward" front end... Although in that case you might argue that you NEVER want to accept malware, and so scanning at SMTP-time can be justified.
[1]I blame management and administrator-types who don't understand email for the current situation we're in. They came to depend on email so much that they want that end-to-end reliability guarantee. For example, "If we try to send an important document to a client we want to be notified if it wasn't able to be delivered." You know the kind of attitude. "We'd better err on the side of caution rather than risk our important emails being lost without either party realizing it." And so, because of this prevailing meme floating through management, all the AV stuff sends bounces, on the minor chance that it was something important. Mail admins setup their servers to bounce anything that can't be delivered, so that nothing is ever lost.
And so because of that, we're in the current mess. The solution is simple: Stop trying to bo so anal about email and realize that it was never designed to be reliable. Bouncing malware is NEVER a good idea, it just makes extra noise and bandwidth that someone else has to deal with. So either turn off bounces, or scan at SMTP time.
The solution is clear, we just need to sit down and talk some sense into all of these people that continue to flood our inboxes with false bounces.
I just want to reinforce the "make good decisions" mantra.
I do not use a Microsoft product to read email. I can click on anything I damn well please, I don't have to worry about any autoexecuting stuff, I don't even have to worry about loading spammers' webbugs or images. I have never once been infected with a single email worm/trojan/virus. In fact, I have never found a single virus on my system, ever, and I have been connected to the public internet since 1994. I do not use antivirus software, nor do I have any plans to start. It's all about what you choose to do, not what kind of software you run. If you are a slave to autoupdates and virus definitions, maybe you should consider NOT using a Microsoft product for email and NOT running things from odd websites. I do not follow the Windows reinstall treadmill. I do not blame my problems on viruses. I install windows every 3 or 4 years, based only on hardware upgrades and not "It doesn't work! I must reinstall!"
* And for those of you saying "How do you know you've never had a virus if you don't use AV software?" Well, I have occasionally used Trendmicro's online virusscan, out of curiousity. Not a single time have I ever run that program and found a virus.
Well the Apache contributors page seems to do a pretty good job of detailing the several dozen core developers. There's even a few pictures.
That said I think the reason you don't have a name to associate with Apache is that there is no one singular Guru/Creator/Architect Figure, as with Larry Wall or Linus Torvalds.
If you actually do this you're an asshole. You can never trust the From: line in spam. You're just clogging up some innocent person's inbox. Don't be a dick.
Totally. This is like the third or fourth "article" on slashdot in the last 6 months or so that's been based upon someone mistaking the NY Post for a "newspaper" and not a dead fish wrapping device. Could we PLEASE get a feature added to slashcode that automatically rejects any submission with a link to nypost.com in it? And calls the submitter names?
Arash Zeini (KDE Farsi) wrote an intresting article about FLOSS in Iran. His view: "It is not a secret anymore that FLOSS is gaining momentum all over the world. We witness an international move and acceptance of FLOSS in the private as well as in the public sector."
Yes, dentists the world over agree that the collective state of mouths in Iran and the world over has improved since this widespread adoption of FLOSS technology.
--
But seriously, some acronyms work and others don't. FLOSS never seemed like a very good one to me.
News Flash -- Impressive thing of the future fails to materialize as promised. Advocates of the flying car, personal nuclear generator, and personal rocket packs send their condolences to anyone holding out for hopes of an interplanetary network anytime soon.
Re:What if the escrow goes bust as well?
on
Source Code Escrow
·
· Score: 1
Nah, you just need an escrow service for your escrow service.
I would tend to think not. The physical geometry of the piezoelectric ceramic is what determines the voltage ratio. It might be possible to package several different configurations in one enclosure, but at its core it's a fixed ratio.
In contrast, the switch-mode powersuppy you're using now rectifies line AC and then switches it at a very high frequency (around 40kHz) and uses the duty cycle of this switching to regulate the output. Through a closed-loop controller it regulates the output to a constant level regardless of the input, which is why it can take such a large input range.
Slashdot Mirror
Bram figured this out with BitTorrent- the server can instruct the client on when it should next check back. ... and most clients ignore it completely. I've seen clients reannounce every 5 minutes even though the tracker says 30. Nice idea, but in the real world it doesn't work that way.
A telesync doesn't necessarily have to take audio directly from the mixer. Usually it's just someone sitting in the "assistive hearing" seat and recording from the audio jack.
Nor does a TS have to be in a closed theater. I've seen plenty with audience members present.
The only thing a telesync really denotes is that the video and audio were recorded seperately and synchronized together later.
Why in the world are "39.4" and "40" listed as incorrect? Hello, has anyone heard of rounding and significant digits? If you want to express it in three significant digits then 39.4 would be absolutely correct, as would 40 if you only had 2 significant figures.
That's because backup MXs are an anachronism of a time when sites weren't always connected to the net. If your primary MX goes down all legitimate senders will queue the message and keep trying for quite some time. There's no need for a redundant 3rd party MX on the modern internet. If you want extra assurance then run dual MXes on-site so if one must go down the other will handle the load. But the whole "external" MX idea is just outdated.
"my mail server HAS to accept the message first" -- not true at all
If you used exim/exiscan/spamassassin/clamav you could do all that scanning at delivery time and reject the message after the DATA phase with a 5xx code. My mailserver rejects spam and malware at the SMTP transaction time. I know there are similar schemes for other MTAs.
Good point. Conspicuously lacking in their list of things ISPs should do is "Provide ample staffing for your abuse desk, give them adequate power to shut down abusers, and respond quickly to abuse reports."
/dev/null: wake the hell up and start becoming part of the solution.
If every ISP had an Afterburner-esque person in charge of the abuse desk, then the amount of spam-support sites, trojaned zombies, and general malfeasance would go way down. To all you ISPs who redirect abuse@ mail to
- Reliance on register_globals turned ON. The PHP developers made a huge mistake by leaving this the default as long as they did, but fortunately they changed it to OFF by default some time ago. It is an abomination, and a script that requires it is just asking for XSS or SQL injection vulerabilities. This above example both relies on $submit being automatically registered, as well as using its value without any kind of validation! That's simply inexcusable.
- But far worse, he outputs $name with absolutely no quoting! HELLO! at the very least run htmlspecialchars() over it, otherwise this script is totally open to abuse.
I cannot take seriously any site that is ostensibly about PHP security and has an example like this in their pathetic tutorials. Some of ther other tutorials include "the magic of the echo command". Wow, thanks for that. Let's leave the "Introduction to PHP basics" to the authors that are paid to write, okay?
You should read the CVS book: http://cvsbook.red-bean.com/cvsbook.html
In short, with CVS you check out files from the repository, work on them (edit, compile, test, whatever) and when they are in a suitable state you check them back in (commit) which causes the version number associated with each file to automatically increase. If your working dir is in a particularly interesting state, for example a release version, then you create a "tag" which saves that state, essentially remembering the version number of each file for the current configuration.
As far as automatically-generated files, the standard practice is to not keep them in CVS. So say you have foo.sh which creates bar.c and baz.c. You add code to your makefile so that it knows that if bar.c or baz.c need updating that foo.sh is to be run. foo.sh is kept in the repository and is versioned, but bar and baz are not, they are just regular files in the working directory. When you start with a fresh checkout they will not exist, but when you run make they will be generated. Typically each developer maintains his/her working directory so it's not like these files need to be created every time. Essentially, you don't keep autogenerated things in the repository because they can always be generated in your working dir. If the generation is not automated then you might choose to include them, however.
CVS is generally intended for text files, but it can also be used with binary files but it will be inefficient. Don't store large binaries in the repository, if possible.
If you, like me, tried to read the linked article and found out that it had absolutely nothing to do with the write-up, then you realized that the person that posted this used a link that was only valid while the feature was "current" on the site. Shame on you.
A permanent link, for the archives and anyone that reads this past the first week, is below.
http://www.citypaper.com/2004-04-14/feature.html
Please, check your links before submitting.
Bullshit. The only thing that a telesync denotes is that the audio was recorded seperately from the video and then synced up later. Usually it's from the "assisted listening for those hard of hearing" jack, and by no means does the word imply that the camera was in the booth. I can't tell you how many telesync's I've seen filmed at awkward keystone off-center angles, with profiles of people walking in front of the camera, and so on.
Why does tripe like this get modded up?
There is no license in effect. It's pure copyright law. Copyright law dictates the right to copy, reproduce, perform publicly, make derivative works of, etc. Filming the screen is making a copy of a work, and thus the holder of the copyright can dictate the terms under which such copying is allowed. It's as simple as that. Don't drag out contracts or licenses into the discussion, they are completely irrelevant.
If it's impossible, then why don't you explain why I have dozens of lines like this in my mail log:
/var/spool/exim4/scan/1AyLgx-0005aY-3v/1AyLgx-0005 aY-3v.eml: Worm.Bagle.F-zippwd FOUND
Wed Mar 3 02:00:59 2004 ->
Thank you, clamav!
Thank you. I too am tired of seeing "You sent me a virus" messages on mailing lists. That's allmost a sure sign that some braindead software somewhere replied to the "From:" address and not the envelope-FROM address, which is where all automated delivery status messages are to go.
In my opinion, the very best thing is to do scanning at SMTP-time. This is very easy with Exim (with the exiscan-acl patch) and clamav, both 100% GPL. By scanning during the DATA phase of message delivery, you can reply with a 5xx code if it's malware. That way, the bounce is not your problem.
For those of you not familiar with the finer points of SMTP, as soon as you accept the message you are responsible for its delivery. That means if it's for a nonexistant user (as many of these malware floods are) or if it's otherwise determined to be undeliverable, you're reponsible for the bounce. Now, please don't take that as saying I think you should bounce malware, I'm just saying that per SMTP once you accept the message its your responsibility to deliver it, which leads to the quandary of "Do I generate a bounce or not?"
However, if you scan the message BEFOER accepting it (during the DATA phase) then you can reply to the other end that you are not accepting the message. This is sometimes called a hard bounce. It does two things: It ensures the end-to-end reliability that everyone wants out of email[1], and it means you don't have to make a "damned if I do, damned if I don't" decision about bounces.
The biggest downside of this is that it's more resource intensive as you must hold open the connection while you scan, so you tend to have more mail daemons waiting around in memory. It also doesn't work if you're running a "store and forward" front end... Although in that case you might argue that you NEVER want to accept malware, and so scanning at SMTP-time can be justified.
[1]I blame management and administrator-types who don't understand email for the current situation we're in. They came to depend on email so much that they want that end-to-end reliability guarantee. For example, "If we try to send an important document to a client we want to be notified if it wasn't able to be delivered." You know the kind of attitude. "We'd better err on the side of caution rather than risk our important emails being lost without either party realizing it." And so, because of this prevailing meme floating through management, all the AV stuff sends bounces, on the minor chance that it was something important. Mail admins setup their servers to bounce anything that can't be delivered, so that nothing is ever lost.
And so because of that, we're in the current mess. The solution is simple: Stop trying to bo so anal about email and realize that it was never designed to be reliable. Bouncing malware is NEVER a good idea, it just makes extra noise and bandwidth that someone else has to deal with. So either turn off bounces, or scan at SMTP time.
The solution is clear, we just need to sit down and talk some sense into all of these people that continue to flood our inboxes with false bounces.
I just want to reinforce the "make good decisions" mantra.
I do not use a Microsoft product to read email. I can click on anything I damn well please, I don't have to worry about any autoexecuting stuff, I don't even have to worry about loading spammers' webbugs or images. I have never once been infected with a single email worm/trojan/virus. In fact, I have never found a single virus on my system, ever, and I have been connected to the public internet since 1994. I do not use antivirus software, nor do I have any plans to start. It's all about what you choose to do, not what kind of software you run. If you are a slave to autoupdates and virus definitions, maybe you should consider NOT using a Microsoft product for email and NOT running things from odd websites. I do not follow the Windows reinstall treadmill. I do not blame my problems on viruses. I install windows every 3 or 4 years, based only on hardware upgrades and not "It doesn't work! I must reinstall!"
* And for those of you saying "How do you know you've never had a virus if you don't use AV software?" Well, I have occasionally used Trendmicro's online virusscan, out of curiousity. Not a single time have I ever run that program and found a virus.
Well, Sims or no, you'll always have furries to look down on, so I think you'll be fine.
Well the Apache contributors page seems to do a pretty good job of detailing the several dozen core developers. There's even a few pictures.
That said I think the reason you don't have a name to associate with Apache is that there is no one singular Guru/Creator/Architect Figure, as with Larry Wall or Linus Torvalds.
it's an effective, low-cost solution to combating mind-control...
If you actually do this you're an asshole. You can never trust the From: line in spam. You're just clogging up some innocent person's inbox. Don't be a dick.
Totally. This is like the third or fourth "article" on slashdot in the last 6 months or so that's been based upon someone mistaking the NY Post for a "newspaper" and not a dead fish wrapping device. Could we PLEASE get a feature added to slashcode that automatically rejects any submission with a link to nypost.com in it? And calls the submitter names?
This whole article/writeup is so much funnier if you imagine Comic Book Guy reading it aloud.
And why, pray tell, is this not under Ask Slashdot?
Lookee there, it's tubgirl. Guess who's moderating without checking links...
Arash Zeini (KDE Farsi) wrote an intresting article about FLOSS in Iran. His view: "It is not a secret anymore that FLOSS is gaining momentum all over the world. We witness an international move and acceptance of FLOSS in the private as well as in the public sector."
Yes, dentists the world over agree that the collective state of mouths in Iran and the world over has improved since this widespread adoption of FLOSS technology.
--
But seriously, some acronyms work and others don't. FLOSS never seemed like a very good one to me.
News Flash -- Impressive thing of the future fails to materialize as promised. Advocates of the flying car, personal nuclear generator, and personal rocket packs send their condolences to anyone holding out for hopes of an interplanetary network anytime soon.
Nah, you just need an escrow service for your escrow service.
I would tend to think not. The physical geometry of the piezoelectric ceramic is what determines the voltage ratio. It might be possible to package several different configurations in one enclosure, but at its core it's a fixed ratio.
In contrast, the switch-mode powersuppy you're using now rectifies line AC and then switches it at a very high frequency (around 40kHz) and uses the duty cycle of this switching to regulate the output. Through a closed-loop controller it regulates the output to a constant level regardless of the input, which is why it can take such a large input range.