Come on people, when laying out a page, don't hardcode the width of the [frames|table columns] - just because you run at 800x600 doesn't mean some of us don't run at 1600x1200, and vice-versa. I'd expect this from a Windows site (Window motto - "Everyone MUST do things just like I do!"), but from a site targeting OSS/FS?
What you are doing is similar to efforts to reduce the mosquito population by releasing large numbers of sterile individuals - by distracting the fertile individuals they reduce the overall population next generation (the same approach is being used for moths, cats, etc.)
It only works when either a) the individuals involve only breed (spam) once, or b) when the number of sterile individuals is a large fraction of the population.
I don't deny the use of honeypots, spamtraps, etc. in catching the spammers, but since spammers don't meet criterion a) (they spam multiple times), you will reduce the overall spam count only if the number of bogus relays is close to the number of fake relays. Otherwise, a spammer will simply send his spewage through multiple relays.
Now, IF the ISPs would use this information to terminate spammers immediately, then you WOULD satisfy criterion a) - a spammer would spam once, then be terminated.
However, this is ALSO true if ISPs would heed spam reports in general. Specifically, if ISPs would simply set up appropriate liasons with Spamcop, they would get the effect of your honeypots (the IDs of the spammers) in a fashion that the spammers could not simply avoid - to stretch my analogy, the hosts the mosquitos feed upon would become poisonous.
I'm glad you feel you are having some degree of success. I don't deny you are having some impact on the system, probably more than I have by reporting spam, LARTing Verio every chance I get, and encouraging others to do the same in public fora like this. However, just as releasing five sterile mosquitos will not have much effect on the disease-ridden little bloodsuckers, I doubt a few honeypot relays will have any effect on the disease-ridden little bloodsuckers.
If at all possible, don't drop their connection - just slow down to accepting a packet a second.
This ties up the offending mail server, and keeps it from spamming others.
If you don't like this, then configure your server to send back a NAK message ("Spam not allowed" or some such) at one character per TCP packet, one packet a second.
Why, then, do UUNET, Verio, and those like them refuse to accept reports from SpamCop? Why, then, to they always ask for the email address of the reporter, when the fact the message was spam is clear from the message? Why do they not post their "kills" in a public place, that others may learn from them? Why, then, are spammers like Torpedomail, Jobsonline, PreferredShopper, etc. still online, dispite overwhelming evidence as to their status?
Sorry, but these ISPs do only as much as is needed to avoid being blacklisted, no more.
And to those who work for these scum - if you are so sure you are in the right, put your work email on your replies, or at least own up for which spam freindly ISP you work for. I cannot help but notice that in every case of them responding in a forum like this, they are heavily anonymized.
Several ISPs, such as Verio, UUNET, Qwest, etc. host many spammers, and are willfully ignorant WRT the activities of the spammers - they do a fine Sgt. Schultz "I know NOTHING, NOTHING" when confronted with the evidence.
First, I suggest EVERYBODY use Spamcop or a similar reporting service when the get SPAM (disclaimer - I am in no way associated with SC other than using their free reporting service).
Second, if you get a spam from a server hosted by one of these ISPs, you use www.bitch-list.net to turn the crapflood back on the ISP - make it cost them more in support calls than the spammer is paying them.
Third, if any of you HAVE servers hosted by these ISPs and you ever get shut down for TOS violations, you sue the ISP, claiming discrimination - "They didn't TOS these spammers, why are the TOSing me?"
Make it cost the ISPs more to host the spammers than the spammers pay, and they will drop the spammers. Remember, both Verio and Worldcom/UUNET are hurting for money right now - pink contracts must look pretty good to them ("See, the spammers will pay DOUBLE for bandwidth!"). Turn the pink contracts into red ink, and they will cease.
I might point out that the US started building its cell network before the rest of the world did - as such, the rest of the world got to learn from our mistakes and benefit from our discoveries, while we got to live with our mistakes and make our discoveries.
Hence, the rest of the world had an advantage in being able to build with newer, better tech than the US.
I'm not knocking Hammer, but why does everyone act like the Itanium and Hammer versions of Linux are the first 64 bit versions? I was running 64 bit Linux several years ago on my Multia!
Once you have GCC that will compile for the target arch, and you have the needed changes to Linux to support that arch, why is it more than bunch of builds to get a 64 bit version? Many (perhaps even most) apps are now 64 bit clean (unlike certain other criminal OS's).
Why does everyone ignore the MIPS and Alpha versions?
(and OT: When will a MIPS version of Linux with full support for the extra hardware in an Indy come out?)
If you do archive your pictures, take some time and write a description of each picture. Your children will thank you.
I had to go through my mother's estate a while back, and she had pictures from her mother. My maternal grandmother was born in 1900 - many of these pictures had no detail as to WHO these people were, or WHY they were important enough to photograph. It was really heartbreaking to look at these pictures and not know it they were important to anybody else in the family.
No matter how you archive your photos, do those who come after a favor - write date, place, and a description on the pictures. Be that in magic marker on the back of the print, laserprint in the album, an HTML file on the CDR, or a comment tag embedded in the PNG, do something to capture that context!
Personnally, I wish that my cameras could embed the GPS location on the print, in addition to the date and time as they do now - even better would be to have a flux-gate compass to get bearing data.
OK, so I may be a bit obsessive (I've spent over $300 in film and developing costs for a 2 day trip!).
And I concur with others - if you are serious, get a film scanner. I use a Minolta Dimage Scan Dual II, which is a USB device and is supported by Vuescan under Linux. Then I Gimp the pics to clean them up, and save them as 3600x2400 24bpp PNGs.
Slashdot could learn from this as well
on
Built For Use
·
· Score: 2
... Considering that nowhere under the user preferences are there links to the Friend/Foe/Fan/Freaks links - you can get to them using http://slashdot.org/~/friend and so on, but there are no links to that.
(Pantomimes flipping visor down, catching keys) "Are we learning yet?"
Also, you do realize the above insult is a "freebe" - given out of order. I'm still working through the <V'hhrg character not available in your charset>'s, so I won't be getting to you soon.
As for steppers - hey, when you are controlling twenty of them with a single Z80 and no hardware assistance, you take what you can get.
I've done that sort of work myself, so I know whereof I speak as well (what I always hated was when the damn steppers would cog, and I'd lose track of where I was - I didn't have the luxury of an encoder back then...)
But the more important part of this isn't just knowing where the robot is, but knowing where the NON-ROBOT objects are - sure, if we use IPv6 and assign every object in the universe an IP address and position tracking, we could solve that. But I think that would get a little expensive....
You misinterpreted the meaning of "global" - they did not mean co-ordinate data, rather they meant the state of "the world".
In a game, the gameserver knows where everything is. In robotics, the control program doesn't know for certain that the blue cube is at 0.1x3.5y99.1z - it has to get that information by looking at what the sensors on the robots say, and those sensors lie. So the control program has to take all the data from all the robots and try to fuse it into something meaningful, all the while keeping in mind that "things are not what they seem".
That is why controlling a real-world robot is MUCH harder than controlling a player in a video game.
I have three related stories about the absence of good diagnostic information, both showing WHY the auto manufacturers should open the protocols.
First story. I was on vacation at the Grand Canyon's South rim, and the plan was to head to the North Rim. While that is only a few miles as the neutrino flies, it's about 150 miles by road. Furthurmore, the South Rim is pretty damn far from anything else. So, I get into my car (a 1997 Grand Marquis that had just had its 100kMile service) and lo and behold, the "Overdrive OFF" indicator starts flashing - a fault has been detected in the automatic transmission. Between having the "Check Engine" light come on or this, I'll pick the "Check Engine" light any day - you can troubleshoot an engine in the field, and generally most engine failures are "limp home" failures. A tranny failure tends to be a "walk home" moment.
After poking, prodding, and checking, the light goes out. No explaination. So, we head off for the North Rim. 80 miles from anywhere the tranny goes "thump", the light flashes, and I curse. I managed to get to civilization, rent a UHaul truck and car trailer, and tow my car home. The dealership tells me the ATF had started to break down - they flushed it and changed the filter.
Now, BECAUSE the South Rim is so far from anywhere, and because so many vehicles go there, there is a service shop there. Had the car been able to tell me "Clutch #2 slippage detected - possible fluid breakdown" I could have gone to the shop at the South Rim, had the fluid changed, and gone on without having my plans screwed up. Instead, I paid US$900 to tow my car home, and US$200 for the service.
Second story: A couple of months later, I was going to work. I turned the key, and the "Check Engine" light stayed on. I checked the oil, listens for strange noises, and said "Emissions problem, not serious, call the dealer." Sure enough, the dealership read the codes, and said "Transient failure to pull a vacuum on the fuel tank vapor recovery - It's not showing now. Keep an eye on it. And damn guy, but according to this you've hit the rev limiter on this thing! How fast were you GOING?" Cost: $150. Had I been able to read the codes, I could have cleared it and kept an eye on it.
Third story: A few weeks later, I was heading home, pulled out from a stop, and the tranny said "bang" and the "Overdrive OFF" indicator began to blink. It turns out the fluid had gone bad BECAUSE the #2 clutch had failed. US$1300 later, I have a rebuild in place. I took the car to a tranny shop nearby, rather than the dealership. As I was demonstrating the failure to the mechanic (at that point, it was still intermittant) I commented "Yeah, I know how hard it is to troubleshoot intermittant failures - I am a software engineer". His immediate response: "Maybe you could write some software for us that would work on all of these cars!"
Conclusion: There is a clear harm to the consumer by the practices of the auto manufacturers, who together are acting in an anti-competitive and monopolistic fashion. I hope we CAN make them play nice (imagine a nice GTK front-end for diagnostics....)
What the XMMS folks need to do is make XMMS into a client/server setup - the "server" which plays the MP3s, and a client that talks to the server via a socket for control.
Visualizations and video formats would be handled by the client telling the server where to display - obviously the server can use XShm, DRI or Xv if it is displaying locally.
Right now, my MP3 server is running in the basement, feeding into the house sound system. But to make that work, I had to set up VNC so that I can display XMMS remotely whichever computer I am on. This sucks, since VNC isn't cheap from a resource standpoint.
Despite what so many hypotrolls here on/. say, seperation of UI and backend by a network transparent layer is IMPORTANT - it is one of the things that enables *nix to be "anywhere, any keyboard, any account". The computer IS the network....
My computer lives inside the desk, where its fans are muffled by the enclosure (with a large, low speed high volume QUIET fan ventilating the desk). I couldn't see an LCD on the computer.
How about an LCD panel on a USB, so that I could mount the LCD up where I could see it?
Or better still, how about just running more than one monitor - and having screen real estate I can use for ANYTHING?
No he didn't - he made the three laws to show they WOULDN'T WORK, as he demonstrated in several stories.
For example, consider the first law. I don't exercise as much as I should. Since that will lead to ill health and death, a robot would be compelled to compell ME to exercise. No countermanding order would be accepted, since orders are Second Law.
Eat a cheeseburger? No, lots of "empty" calories and fat, little nutrition. That will cause harm - I must stop you.
Second law has its problems too, as Asimov pointed out. Bored punk kid runs around ordering robots to battle to their destruction for his amusement. Basically, every robot had to be given orders to ignore orders of self-destructive nature from anybody other than the owners, Universal Robots employees, and law enforcement.
Eventually, Asimov had to state that the three laws as stated were "fuzzy" - weighted by circumstances. Saving two convicted criminals is less important than saving one saint, obeying a foolish order less important than doing your job, etc.
Even that brought about problems - the incident when Hyperdrive was invented, for example.
Sorry, but should we ever create AIs, the most likely way we will be able to instill limits into their behavior will be the same as we do with people - years of training in "morality" and "ethics". Let us hope we get it right.
The single best thing all of us who know how to run traceroute and whois can do is LART THE ISPS THAT HOST SPAMMERS!
I've been forwarding every spam I get that come from a Verio hosted site, or spamvertises a site hosted on Verio to Verio and their parent company, NTT. I'm using bitch-list.net to do so, since they have a bazillion email addresses for Verio. I make sure the email has the spam attached, and since Verio has claimed the cannot read attachments (***cough***BULLSHIT****cough***) I also paste the mail headers into the message, along with a WHOIS and traceroute showing it to be a Verio customer. When they complain, I tell them "MY message isn't spam - your customer contacted me, so a prior business relationship exists. You want it stopped, stop the spammer."
I won't say it is working, but if 10% of everybody who got these spams did as I do, then Verio's help desks would be so clogged that they couldn't HELP but see the damage on the bottom line.
When I was an undergrad, one of the out-of-major classes I took was archery (I needed a PE credit, and I was interested in it). In archery (and in any other kind of marksmenship) the trick is
Be consistent
Measure your error
Identify the cause of the error
corrent the cause
repeat
Programming is the same way. What kinds of bugs are you finding? Are they just stupid bugs, like buffer overflows or off-by-ones (good design, bad implementation), or are they unhandled errors, or are they API mis-matches or faulty algorithms (bad design)?
Have you made any effort to go back and say "Gee, we are getting a lot of off-by-one errors. OK folks, we need to think about our loops."?
And when you find one type of bug, do you go back and identify anyplace else a similar bug may exist?
If you are hitting high and right, and you never adjust your sights, you will NEVER hit the target consistently. If you never feed back the CAUSE of the bugs, you will never eliminate them.
You do know that you could configure SSH to forward port 8080 on your local machine to port 80 on the remote Unix box?
You do know that you could configure Squid or Apache on the Unix box to act as a proxy?
You do know you could then use whatever browser you want on the local machine, proxying through the remote?
Re:The problem with ANY packaging system....
on
Is RPM Doomed?
·
· Score: 2
Sorry, but you are wrong - RPM depends primarily on packages. File dependancies, while possible, are rare.
I suggest you go over to rpmfind.net and look at the listings on several random RPMs. You will see that in most cases, the RPMs depend upon other packages - rarely do they depend upon specific files.
And by "screw things up" I don't mean "cause the system to become unusable", I mean "cause invalid dependancies that make installing packages needlessly difficult". As I had said in several previous messages, that does not happen, even on Debian unstable, more due to the work of the Debian maintainers than to any inherent superiority of.deb over.rpm.
Hence why I mentioned the Beast in one of my earlier posts.
The reason I keep making this point every time it comes up is that I don't want to see people trying to solve the wrong problem the wrong way for the wrong reasons, and then wonder why things aren't any better.
The "all in one Setup.exe" solution someone proposed above, the "Ditch RPM, use.DEB" crowd, the "Just Build From Source" - they all miss the point that the problem is the fact that package maintainers DON'T! They DON'T maintain binary compatability until the next major rev, they don't make their dependancies correctly, they don't keep their files neatly organized.
I'm just afraid that somebody will bring out some new, shinier, bluer package system that "solves the problem" and everybody will leap upon it with glad cries until they realize that the problems are the same, because we didn't solve them in the first place!
On LKML, Linus raked the DRI developers over the coals for not maintaining backward compatibility with the various version of the DRI. The DRI guys, in their (understandable) rush to make things stronger, faster, better didn't understand the importance of keeping compatibility. It took a BOFH to LART them into realizing the importance of that.
I just home somebody will serve as that BOFH for all the package creators out there - be that BOFH the Debian crew, RedHat, IBM, or even The Dark One Himself.
Slashdot Mirror
Would you happen to know the name of this sequel? I'd be interested in reading it...
Dide
anyone
else
get
the
page
laid
out
lik
this?
Come on people, when laying out a page, don't hardcode the width of the [frames|table columns] - just because you run at 800x600 doesn't mean some of us don't run at 1600x1200, and vice-versa. I'd expect this from a Windows site (Window motto - "Everyone MUST do things just like I do!"), but from a site targeting OSS/FS?
What you are doing is similar to efforts to reduce the mosquito population by releasing large numbers of sterile individuals - by distracting the fertile individuals they reduce the overall population next generation (the same approach is being used for moths, cats, etc.)
It only works when either a) the individuals involve only breed (spam) once, or b) when the number of sterile individuals is a large fraction of the population.
I don't deny the use of honeypots, spamtraps, etc. in catching the spammers, but since spammers don't meet criterion a) (they spam multiple times), you will reduce the overall spam count only if the number of bogus relays is close to the number of fake relays. Otherwise, a spammer will simply send his spewage through multiple relays.
Now, IF the ISPs would use this information to terminate spammers immediately, then you WOULD satisfy criterion a) - a spammer would spam once, then be terminated.
However, this is ALSO true if ISPs would heed spam reports in general. Specifically, if ISPs would simply set up appropriate liasons with Spamcop, they would get the effect of your honeypots (the IDs of the spammers) in a fashion that the spammers could not simply avoid - to stretch my analogy, the hosts the mosquitos feed upon would become poisonous.
I'm glad you feel you are having some degree of success. I don't deny you are having some impact on the system, probably more than I have by reporting spam, LARTing Verio every chance I get, and encouraging others to do the same in public fora like this. However, just as releasing five sterile mosquitos will not have much effect on the disease-ridden little bloodsuckers, I doubt a few honeypot relays will have any effect on the disease-ridden little bloodsuckers.
If at all possible, don't drop their connection - just slow down to accepting a packet a second.
This ties up the offending mail server, and keeps it from spamming others.
If you don't like this, then configure your server to send back a NAK message ("Spam not allowed" or some such) at one character per TCP packet, one packet a second.
Why, then, do UUNET, Verio, and those like them refuse to accept reports from SpamCop? Why, then, to they always ask for the email address of the reporter, when the fact the message was spam is clear from the message? Why do they not post their "kills" in a public place, that others may learn from them? Why, then, are spammers like Torpedomail, Jobsonline, PreferredShopper, etc. still online, dispite overwhelming evidence as to their status?
Sorry, but these ISPs do only as much as is needed to avoid being blacklisted, no more.
And to those who work for these scum - if you are so sure you are in the right, put your work email on your replies, or at least own up for which spam freindly ISP you work for. I cannot help but notice that in every case of them responding in a forum like this, they are heavily anonymized.
Am I the only one who felt a qualm about using this package because of the name?
BitchX - "I 0NZ0R J00, B1TCH!"
Several ISPs, such as Verio, UUNET, Qwest, etc. host many spammers, and are willfully ignorant WRT the activities of the spammers - they do a fine Sgt. Schultz "I know NOTHING, NOTHING" when confronted with the evidence.
First, I suggest EVERYBODY use Spamcop or a similar reporting service when the get SPAM (disclaimer - I am in no way associated with SC other than using their free reporting service).
Second, if you get a spam from a server hosted by one of these ISPs, you use www.bitch-list.net to turn the crapflood back on the ISP - make it cost them more in support calls than the spammer is paying them.
Third, if any of you HAVE servers hosted by these ISPs and you ever get shut down for TOS violations, you sue the ISP, claiming discrimination - "They didn't TOS these spammers, why are the TOSing me?"
Make it cost the ISPs more to host the spammers than the spammers pay, and they will drop the spammers. Remember, both Verio and Worldcom/UUNET are hurting for money right now - pink contracts must look pretty good to them ("See, the spammers will pay DOUBLE for bandwidth!"). Turn the pink contracts into red ink, and they will cease.
Every *nix distro is in violation of this copyright, since they all ship with a copy of this work.
/dev/zero
It's called
I might point out that the US started building its cell network before the rest of the world did - as such, the rest of the world got to learn from our mistakes and benefit from our discoveries, while we got to live with our mistakes and make our discoveries.
Hence, the rest of the world had an advantage in being able to build with newer, better tech than the US.
I'm not knocking Hammer, but why does everyone act like the Itanium and Hammer versions of Linux are the first 64 bit versions? I was running 64 bit Linux several years ago on my Multia!
Once you have GCC that will compile for the target arch, and you have the needed changes to Linux to support that arch, why is it more than bunch of builds to get a 64 bit version? Many (perhaps even most) apps are now 64 bit clean (unlike certain other criminal OS's).
Why does everyone ignore the MIPS and Alpha versions?
(and OT: When will a MIPS version of Linux with full support for the extra hardware in an Indy come out?)
If you do archive your pictures, take some time and write a description of each picture. Your children will thank you.
I had to go through my mother's estate a while back, and she had pictures from her mother. My maternal grandmother was born in 1900 - many of these pictures had no detail as to WHO these people were, or WHY they were important enough to photograph. It was really heartbreaking to look at these pictures and not know it they were important to anybody else in the family.
No matter how you archive your photos, do those who come after a favor - write date, place, and a description on the pictures. Be that in magic marker on the back of the print, laserprint in the album, an HTML file on the CDR, or a comment tag embedded in the PNG, do something to capture that context!
Personnally, I wish that my cameras could embed the GPS location on the print, in addition to the date and time as they do now - even better would be to have a flux-gate compass to get bearing data.
OK, so I may be a bit obsessive (I've spent over $300 in film and developing costs for a 2 day trip!).
And I concur with others - if you are serious, get a film scanner. I use a Minolta Dimage Scan Dual II, which is a USB device and is supported by Vuescan under Linux. Then I Gimp the pics to clean them up, and save them as 3600x2400 24bpp PNGs.
... Considering that nowhere under the user preferences are there links to the Friend/Foe/Fan/Freaks links - you can get to them using http://slashdot.org/~/friend and so on, but there are no links to that.
(Pantomimes flipping visor down, catching keys) "Are we learning yet?"
No offense taken - I figured as much.
Also, you do realize the above insult is a "freebe" - given out of order. I'm still working through the <V'hhrg character not available in your charset>'s, so I won't be getting to you soon.
As for steppers - hey, when you are controlling twenty of them with a single Z80 and no hardware assistance, you take what you can get.
That's WOWBAGGER, you bag-licking kneebiter ;)
I've done that sort of work myself, so I know whereof I speak as well (what I always hated was when the damn steppers would cog, and I'd lose track of where I was - I didn't have the luxury of an encoder back then...)
But the more important part of this isn't just knowing where the robot is, but knowing where the NON-ROBOT objects are - sure, if we use IPv6 and assign every object in the universe an IP address and position tracking, we could solve that. But I think that would get a little expensive....
You misinterpreted the meaning of "global" - they did not mean co-ordinate data, rather they meant the state of "the world".
In a game, the gameserver knows where everything is. In robotics, the control program doesn't know for certain that the blue cube is at 0.1x3.5y99.1z - it has to get that information by looking at what the sensors on the robots say, and those sensors lie. So the control program has to take all the data from all the robots and try to fuse it into something meaningful, all the while keeping in mind that "things are not what they seem".
That is why controlling a real-world robot is MUCH harder than controlling a player in a video game.
I have three related stories about the absence of good diagnostic information, both showing WHY the auto manufacturers should open the protocols.
First story. I was on vacation at the Grand Canyon's South rim, and the plan was to head to the North Rim. While that is only a few miles as the neutrino flies, it's about 150 miles by road. Furthurmore, the South Rim is pretty damn far from anything else. So, I get into my car (a 1997 Grand Marquis that had just had its 100kMile service) and lo and behold, the "Overdrive OFF" indicator starts flashing - a fault has been detected in the automatic transmission. Between having the "Check Engine" light come on or this, I'll pick the "Check Engine" light any day - you can troubleshoot an engine in the field, and generally most engine failures are "limp home" failures. A tranny failure tends to be a "walk home" moment.
After poking, prodding, and checking, the light goes out. No explaination. So, we head off for the North Rim. 80 miles from anywhere the tranny goes "thump", the light flashes, and I curse. I managed to get to civilization, rent a UHaul truck and car trailer, and tow my car home. The dealership tells me the ATF had started to break down - they flushed it and changed the filter.
Now, BECAUSE the South Rim is so far from anywhere, and because so many vehicles go there, there is a service shop there. Had the car been able to tell me "Clutch #2 slippage detected - possible fluid breakdown" I could have gone to the shop at the South Rim, had the fluid changed, and gone on without having my plans screwed up. Instead, I paid US$900 to tow my car home, and US$200 for the service.
Second story: A couple of months later, I was going to work. I turned the key, and the "Check Engine" light stayed on. I checked the oil, listens for strange noises, and said "Emissions problem, not serious, call the dealer." Sure enough, the dealership read the codes, and said "Transient failure to pull a vacuum on the fuel tank vapor recovery - It's not showing now. Keep an eye on it. And damn guy, but according to this you've hit the rev limiter on this thing! How fast were you GOING?" Cost: $150. Had I been able to read the codes, I could have cleared it and kept an eye on it.
Third story: A few weeks later, I was heading home, pulled out from a stop, and the tranny said "bang" and the "Overdrive OFF" indicator began to blink. It turns out the fluid had gone bad BECAUSE the #2 clutch had failed. US$1300 later, I have a rebuild in place. I took the car to a tranny shop nearby, rather than the dealership. As I was demonstrating the failure to the mechanic (at that point, it was still intermittant) I commented "Yeah, I know how hard it is to troubleshoot intermittant failures - I am a software engineer". His immediate response: "Maybe you could write some software for us that would work on all of these cars!"
Conclusion: There is a clear harm to the consumer by the practices of the auto manufacturers, who together are acting in an anti-competitive and monopolistic fashion. I hope we CAN make them play nice (imagine a nice GTK front-end for diagnostics....)
What the XMMS folks need to do is make XMMS into a client/server setup - the "server" which plays the MP3s, and a client that talks to the server via a socket for control.
/. say, seperation of UI and backend by a network transparent layer is IMPORTANT - it is one of the things that enables *nix to be "anywhere, any keyboard, any account". The computer IS the network....
Visualizations and video formats would be handled by the client telling the server where to display - obviously the server can use XShm, DRI or Xv if it is displaying locally.
Right now, my MP3 server is running in the basement, feeding into the house sound system. But to make that work, I had to set up VNC so that I can display XMMS remotely whichever computer I am on. This sucks, since VNC isn't cheap from a resource standpoint.
Despite what so many hypotrolls here on
My computer lives inside the desk, where its fans are muffled by the enclosure (with a large, low speed high volume QUIET fan ventilating the desk). I couldn't see an LCD on the computer.
How about an LCD panel on a USB, so that I could mount the LCD up where I could see it?
Or better still, how about just running more than one monitor - and having screen real estate I can use for ANYTHING?
No he didn't - he made the three laws to show they WOULDN'T WORK, as he demonstrated in several stories.
For example, consider the first law. I don't exercise as much as I should. Since that will lead to ill health and death, a robot would be compelled to compell ME to exercise. No countermanding order would be accepted, since orders are Second Law.
Eat a cheeseburger? No, lots of "empty" calories and fat, little nutrition. That will cause harm - I must stop you.
Second law has its problems too, as Asimov pointed out. Bored punk kid runs around ordering robots to battle to their destruction for his amusement. Basically, every robot had to be given orders to ignore orders of self-destructive nature from anybody other than the owners, Universal Robots employees, and law enforcement.
Eventually, Asimov had to state that the three laws as stated were "fuzzy" - weighted by circumstances. Saving two convicted criminals is less important than saving one saint, obeying a foolish order less important than doing your job, etc.
Even that brought about problems - the incident when Hyperdrive was invented, for example.
Sorry, but should we ever create AIs, the most likely way we will be able to instill limits into their behavior will be the same as we do with people - years of training in "morality" and "ethics". Let us hope we get it right.
The single best thing all of us who know how to run traceroute and whois can do is LART THE ISPS THAT HOST SPAMMERS!
I've been forwarding every spam I get that come from a Verio hosted site, or spamvertises a site hosted on Verio to Verio and their parent company, NTT. I'm using bitch-list.net to do so, since they have a bazillion email addresses for Verio. I make sure the email has the spam attached, and since Verio has claimed the cannot read attachments (***cough***BULLSHIT****cough***) I also paste the mail headers into the message, along with a WHOIS and traceroute showing it to be a Verio customer. When they complain, I tell them "MY message isn't spam - your customer contacted me, so a prior business relationship exists. You want it stopped, stop the spammer."
I won't say it is working, but if 10% of everybody who got these spams did as I do, then Verio's help desks would be so clogged that they couldn't HELP but see the damage on the bottom line.
Programming is the same way. What kinds of bugs are you finding? Are they just stupid bugs, like buffer overflows or off-by-ones (good design, bad implementation), or are they unhandled errors, or are they API mis-matches or faulty algorithms (bad design)?
Have you made any effort to go back and say "Gee, we are getting a lot of off-by-one errors. OK folks, we need to think about our loops."?
And when you find one type of bug, do you go back and identify anyplace else a similar bug may exist?
If you are hitting high and right, and you never adjust your sights, you will NEVER hit the target consistently. If you never feed back the CAUSE of the bugs, you will never eliminate them.
Leave a fake grenade, with the pin pulled and the spoon held down by the outside of the case in the computer.
Identify intrusion by the stain on the floor.
For bonus points, replace the fake grenade with a real one.
You do know that you could configure SSH to forward port 8080 on your local machine to port 80 on the remote Unix box?
You do know that you could configure Squid or Apache on the Unix box to act as a proxy?
You do know you could then use whatever browser you want on the local machine, proxying through the remote?
Sorry, but you are wrong - RPM depends primarily on packages. File dependancies, while possible, are rare.
.deb over .rpm.
I suggest you go over to rpmfind.net and look at the listings on several random RPMs. You will see that in most cases, the RPMs depend upon other packages - rarely do they depend upon specific files.
And by "screw things up" I don't mean "cause the system to become unusable", I mean "cause invalid dependancies that make installing packages needlessly difficult". As I had said in several previous messages, that does not happen, even on Debian unstable, more due to the work of the Debian maintainers than to any inherent superiority of
Hence why I mentioned the Beast in one of my earlier posts.
.DEB" crowd, the "Just Build From Source" - they all miss the point that the problem is the fact that package maintainers DON'T! They DON'T maintain binary compatability until the next major rev, they don't make their dependancies correctly, they don't keep their files neatly organized.
The reason I keep making this point every time it comes up is that I don't want to see people trying to solve the wrong problem the wrong way for the wrong reasons, and then wonder why things aren't any better.
The "all in one Setup.exe" solution someone proposed above, the "Ditch RPM, use
I'm just afraid that somebody will bring out some new, shinier, bluer package system that "solves the problem" and everybody will leap upon it with glad cries until they realize that the problems are the same, because we didn't solve them in the first place!
On LKML, Linus raked the DRI developers over the coals for not maintaining backward compatibility with the various version of the DRI. The DRI guys, in their (understandable) rush to make things stronger, faster, better didn't understand the importance of keeping compatibility. It took a BOFH to LART them into realizing the importance of that.
I just home somebody will serve as that BOFH for all the package creators out there - be that BOFH the Debian crew, RedHat, IBM, or even The Dark One Himself.