No, if you reject during the SMTP session, you don't send an NDR at all, you send a 5xx SMTP response code. (It doesn't matter if the reason for rejecting is SPF-related or not). It is then up to the sending server to inform the sender with an NDR, and the sending server should only be sending on behalf of authorized/authenticated users, or be a permitted relay for such a server.
Anything detected as junk after the SMTP session is over should be marked as junk in some way so it can be stored in a junk folder. If an NDR is written then, it could be sending backscatter. If it's simply discarded, neither the sender or receiver will know when false positives are occurring.
What's that game where you push the balls into the wall? If someone knows, I would like to play it again. It was in the Slackware packages back in the old days... used SVGAlib.
Sounds like you're talking about Koules.
You can run it in X also.
Yes, I have heard of both safe_mode and open_basedir.
They have a few problems. The first being that they basically only advise PHP to double check uids, path names, and disabling a number php functions. They don't stop one from snooping around with mod_perl, SSI, or whatever else is available on the server. (Many servers default to all files being readable by everyone anyway, so you don't even have to piggyback on the webserver to look around). Secondly, most shared hosting providers I've encountered don't enable these directives in the first place.
safe_mode and open_basedir are band-aid solutions that don't address the root of the problem. The perchild MPM does... err, will.:)
Apache 1.x has a big problem when it comes to dynamic/updating data in shared hosting environments: security, or lack thereof.
All php, mod_perl, (and pretty much anything except suexec cgi) based pages are run as the same uid/gid as the apache server. Everything your scripts have read/write access to, so does everyone else on the same machine.
So, for instance, if your database passwords are in a php script, or a file that a your php script reads, the webserver must have read access to that data in order for it to work. Since everyone else's scripts also run with the webserver uid/gid, they also have read access to your database username/password info, and can therefore connect to your database, and do all the damage they want.
To address this problem, Apache 2 has the perchild MPM which allows a virtual host to have it's own process fork, uid/gid, and thread pool.
Unfortunately, the perchild MPM is not presently stable.
With that being unstable, and php and mod_perl also being "experimental", Apache 2 doesn't really offer an advantage over 1.3 yet....But don't be so certain that Apache 1.x "ain't broken".
Re:You'll need more to bring about OpenGL support.
on
Doom3 and OpenGL2.0
·
· Score: 4, Interesting
Just because DoomIII uses OpenGL I don't believe card manufactures will race out to upgrade their OpenGL support.
New game engines from id are Big Deals in the game industry. These are what most people benchmark on, these are what people can't wait to get their hands on, these outsell anything claiming to be competition. It's make-or-break for video card companies. If their cards are shown to be poor performers compared to the brands that did race to upgrade GL support, their sales will plumit while the others escalate.
If a dozen or so games do, that's another story
A new game engine from id does not mean just one game. They license their game engines out to many companies, and from there many games are made....Maybe even "a dozen or so", enough to make any video card makers that handn't already... take notice.
I used to work at a company that brought in a bunch of SunRays for most of the staff. When the SunRay server freezes/goes-down (and it does) it means everyone (except the sys admins) got a surprise coffee break. It was quite refreshing.:)
...But to add to the negatives list, there were CPU problems, and they usually fell into one of two categories. 1) run-away netscape (4.x) processes consuming more and more resources bringing the system to a crawl, and 2) At any given time there were a number of stations running screensavers, slowing down the system for the rest of us trying to work.
Now, that was at a time when Mozilla could be described as slow and buggy, and Netscape 4.x was what everyone was using on the SunRays....Which is why most people kept their pre-SunRay PC w/ Windows, so they could use Office & IE... which is why so many SunRays sat there doing nothing but running screensavers. With Mozilla and StarOffice 6 to offer, it might not be so bad anymore.
Speaking of games, does anyone know if there is anything at all going on with joystick/gamepad support? Ever since I've been on a 2.4 kernel, I've had no luck getting anything to work. Any info I can find seems to pertain either to 2.0 or 2.2 kernels, or plans for the "upcoming" 2.4 kernel series.
The Screen Savers talk about it now and then, along with BSD, Mac OS X, etc. I get the feeling they'd like to talk more about alternative OSes than they do, they've all but said so, but they also state that by far the majority of their viewers are (take a guess...) Windows users. But, they usually mention linux at least once per show. They have tux items all over their set too.
The show that i liked the most, Silicon Spin, they moved it somehow in some weird hours and i can not watch it anymore. Hey TECH TV PEOPLE: I want Silicon Spin back at 9:30pm or 10:00 pm and make it longer than 30 minutes.
I hate to be the bearer of bad news, but... Silicon Spin was cancelled. It's not running at some weird hours, it's not running at all. If it makes you feel any better, the last show was about linux on the desktop.
Read the first paragraph of that EULA a few times over before reading the rest.
"Software" is governed by that EULA, and is Sony's proprietary software.
"Third Party Software", as in what Sony doesn't own, as in Linux, GNU utilities, etc, are "subject to the terms set out in the applicable DVD -Rom and any accompanying documentation", as in GPL, BSD, MIT, Apache, or other such licenses.
Now read the EULA again, taking note of the capitalization of the term Software, as defined in paragraph one. That EULA does not violate the GPL.
Disclaimer: I am not a lawyer, but I have seen one portrayed on television.
I think very few unix gui applications these days are written to be X specific. APIs like GTK, Qt, SDL, etc, aren't tied specifically to X.
Likewise, Cocoa is not tied specifically to OS X. Cocoa is just an API, like GTK or Qt, and can be implemented on different windowing systems, just like GTK and Qt.
If you need further convincing, I recommend you actually look at the GNUstep project, as mentioned earlier.
GNUstep, like Cocoa, is based on the OpenStep API.
And GNUstep aims to be OS X compatible.
If the mouse is 10 pixels from the left edge and you translate to the center of the screen, you'll never be able to move the mouse farther left than 10 pixels from center.
Ok... assuming you actually have a good reason to move the mouse cursor like that, and that it can't be done in a standard API...
Hide the system mouse cursor
Instead of "moving" the mouse cursor, keep x and y offsets from the actual mouse position to a new "translated" mouse position.
Use these translation offsets when reading mouse coordinates, and for drawing a mouse cursor on screen (wrap that in functions or macros and never have to think about it again)
Most games draw their own mouse cursors anyway, so the hard part is already done.
That was so easy... I'm pleasantly surprised, just like you said.
Re:Remote Display can be put into something New!
on
X Windows Must Die!
·
· Score: 1
So what do you want? An X with smaller footprint? Or one with a lot of k00l widgets built into it (increasing its resource footprint). You're contradicting yourself.
I hardly think so. That footprint would only be bigger if X was loaded but no widget libraries were loaded. As soon as I run something, it's going to load libwidgetdujour.so, and with the plethora of X widget libraries, memory usage piles up.
...X widgets are so low level across the network, "Draw a line, Draw a line, Draw another line, and yes, Draw this line, and here are some pixels for you too".
I think it would be much nicer if the app-client could just say to the display server "Draw a button, draw a checkbox" if it were using common widgets, and it could adjust the geometry properties if it wanted. And don't worry, drawing lines and pixels and so on could still be supported, just less often used. Faster remote display, tada. Faster local display too I'd bet.
Slashdot Mirror
No, if you reject during the SMTP session, you don't send an NDR at all, you send a 5xx SMTP response code. (It doesn't matter if the reason for rejecting is SPF-related or not). It is then up to the sending server to inform the sender with an NDR, and the sending server should only be sending on behalf of authorized/authenticated users, or be a permitted relay for such a server.
Anything detected as junk after the SMTP session is over should be marked as junk in some way so it can be stored in a junk folder. If an NDR is written then, it could be sending backscatter. If it's simply discarded, neither the sender or receiver will know when false positives are occurring.
Sounds like you're talking about Koules. You can run it in X also.
Ever heard of safe_mode or open_basedir in php?
Yes, I have heard of both safe_mode and open_basedir. They have a few problems. The first being that they basically only advise PHP to double check uids, path names, and disabling a number php functions. They don't stop one from snooping around with mod_perl, SSI, or whatever else is available on the server. (Many servers default to all files being readable by everyone anyway, so you don't even have to piggyback on the webserver to look around). Secondly, most shared hosting providers I've encountered don't enable these directives in the first place.
safe_mode and open_basedir are band-aid solutions that don't address the root of the problem. The perchild MPM does... err, will. :)
Apache 1.x has a big problem when it comes to dynamic/updating data in shared hosting environments: security, or lack thereof.
All php, mod_perl, (and pretty much anything except suexec cgi) based pages are run as the same uid/gid as the apache server. Everything your scripts have read/write access to, so does everyone else on the same machine.
So, for instance, if your database passwords are in a php script, or a file that a your php script reads, the webserver must have read access to that data in order for it to work. Since everyone else's scripts also run with the webserver uid/gid, they also have read access to your database username/password info, and can therefore connect to your database, and do all the damage they want.
To address this problem, Apache 2 has the perchild MPM which allows a virtual host to have it's own process fork, uid/gid, and thread pool. Unfortunately, the perchild MPM is not presently stable.
With that being unstable, and php and mod_perl also being "experimental", Apache 2 doesn't really offer an advantage over 1.3 yet. ...But don't be so certain that Apache 1.x "ain't broken".
New game engines from id are Big Deals in the game industry. These are what most people benchmark on, these are what people can't wait to get their hands on, these outsell anything claiming to be competition. It's make-or-break for video card companies. If their cards are shown to be poor performers compared to the brands that did race to upgrade GL support, their sales will plumit while the others escalate.
A new game engine from id does not mean just one game. They license their game engines out to many companies, and from there many games are made. ...Maybe even "a dozen or so", enough to make any video card makers that handn't already... take notice.
I used to work at a company that brought in a bunch of SunRays for most of the staff. When the SunRay server freezes/goes-down (and it does) it means everyone (except the sys admins) got a surprise coffee break. It was quite refreshing. :)
...Which is why most people kept their pre-SunRay PC w/ Windows, so they could use Office & IE... which is why so many SunRays sat there doing nothing but running screensavers. With Mozilla and StarOffice 6 to offer, it might not be so bad anymore.
...But to add to the negatives list, there were CPU problems, and they usually fell into one of two categories. 1) run-away netscape (4.x) processes consuming more and more resources bringing the system to a crawl, and 2) At any given time there were a number of stations running screensavers, slowing down the system for the rest of us trying to work.
Now, that was at a time when Mozilla could be described as slow and buggy, and Netscape 4.x was what everyone was using on the SunRays.
Speaking of games, does anyone know if there is anything at all going on with joystick/gamepad support? Ever since I've been on a 2.4 kernel, I've had no luck getting anything to work. Any info I can find seems to pertain either to 2.0 or 2.2 kernels, or plans for the "upcoming" 2.4 kernel series.
The Screen Savers talk about it now and then, along with BSD, Mac OS X, etc. I get the feeling they'd like to talk more about alternative OSes than they do, they've all but said so, but they also state that by far the majority of their viewers are (take a guess...) Windows users. But, they usually mention linux at least once per show. They have tux items all over their set too.
I hate to be the bearer of bad news, but...
Silicon Spin was cancelled. It's not running at some weird hours, it's not running at all. If it makes you feel any better, the last show was about linux on the desktop.
I haven't used this, but it seems to do the trick.
mp3stego, (Windows command line app, with source)
something.wav + secret.data + password = something_secret.mp3
Read the first paragraph of that EULA a few times over before reading the rest.
"Software" is governed by that EULA, and is Sony's proprietary software. "Third Party Software", as in what Sony doesn't own, as in Linux, GNU utilities, etc, are "subject to the terms set out in the applicable DVD -Rom and any accompanying documentation", as in GPL, BSD, MIT, Apache, or other such licenses.
Now read the EULA again, taking note of the capitalization of the term Software, as defined in paragraph one. That EULA does not violate the GPL.
Disclaimer: I am not a lawyer, but I have seen one portrayed on television.
I think very few unix gui applications these days are written to be X specific. APIs like GTK, Qt, SDL, etc, aren't tied specifically to X.
Likewise, Cocoa is not tied specifically to OS X. Cocoa is just an API, like GTK or Qt, and can be implemented on different windowing systems, just like GTK and Qt.
If you need further convincing, I recommend you actually look at the GNUstep project, as mentioned earlier.
GNUstep, like Cocoa, is based on the OpenStep API. And GNUstep aims to be OS X compatible.
I don't suppose "rm /dev/cdrom" from the command line will also eject a CD?
...I take it all back. That won't work. :)
If the mouse is 10 pixels from the left edge and you translate to the center of the screen, you'll never be able to move the mouse farther left than 10 pixels from center.
- Hide the system mouse cursor
- Instead of "moving" the mouse cursor, keep x and y offsets from the actual mouse position to a new "translated" mouse position.
- Use these translation offsets when reading mouse coordinates, and for drawing a mouse cursor on screen (wrap that in functions or macros and never have to think about it again)
Most games draw their own mouse cursors anyway, so the hard part is already done.That was so easy... I'm pleasantly surprised, just like you said.
I hardly think so. That footprint would only be bigger if X was loaded but no widget libraries were loaded. As soon as I run something, it's going to load libwidgetdujour.so, and with the plethora of X widget libraries, memory usage piles up.
...X widgets are so low level across the network, "Draw a line, Draw a line, Draw another line, and yes, Draw this line, and here are some pixels for you too".
I think it would be much nicer if the app-client could just say to the display server "Draw a button, draw a checkbox" if it were using common widgets, and it could adjust the geometry properties if it wanted. And don't worry, drawing lines and pixels and so on could still be supported, just less often used. Faster remote display, tada. Faster local display too I'd bet.