The problem is that only some people will have the ability, technology, or money to change those characteristics. Sure, there are a few billionaires that dress like bums, but that doesn't stop society as a whole from evaluating people on how they look. It would take a lot of rich and poorly-dressed people to significantly change that outlook. So, you really only get away from grouping people at the point where it would be too difficult to group them anyway. Although I admire the sentiment, I just don't see that happening any time soon. If anything, the wealthy are getting wealthier at this point.
You'd be safer if you understood the risks and benefits of the network services you make available to the outside world. You can't just say "ports 25 and 80 OK, other ports bad" and have that be security. Insofar as SOAP tries to pretend that you don't have to understand security and at the same time makes more things available over port 80 than it was originally intended for, it is a security liability.
Menus on Mandrake are totally hosed - for one thing, if you customize your menus with kmenuedit, and then install a Mandrake package (not sure exactly what the trigger is) your menus are replaced with the default set. So I've started just backing up the menus whenever I change 'em, so that I can always fall back on a known good set.
For this (and a couple other reasons) I probably wouldn't install Mandrake on a new machine, unless it's for a new Linux user who won't be doing their own configuration.
Really, considering the quality of the playback, etc., from mplayer, I didn't find the installation to be too complicated. They told you exactly what to download from where, what to type, etc. to get it working. For a guy who claims not to speak English very well, the setup instructions were easier to follow than some I've read that were written by native English speakers:) And it does work and work well, even on a K6-2/350, sans a couple quibbles I have with their GUI. And I'm even using an old version - time to upgrade tonight.
Frankly, I don't care how spikey they are to work with, because the product works great for multimedia on Linux.
Re:Becuase of Stupidity of course
on
Web Services
·
· Score: 1
I don't have a problem with XML-RPC really - it's good to be able to do things remotely via a standardized protocol. But I think that the latest implementations of that idea are not well-thought-out from a security perspective.
Most firewall admins are lazy, and they don't like openning new ports. While you're trying to push
another port they are wary - and you loose time over a pointless argument that you're better to
avoid.
It's not a pointless argument at all. The whole point of a firewall administrator's job is to keep track of what's going in and out and the cost/benefit analysis of that traffic. A good firewall administrator doesn't mind opening new ports; he or she minds opening up to new risks. Sometimes (almost always, I would argue) putting a new service on a new and distinctive port makes it less of a risk than commingling it with the rest of your HTTP traffic. Running everything over port 80 makes it easier to get things past a bad firewall admin, but that's not really the point - you should get a better firewall admin in the first place, or else just admit that understanding your security exposure isn't what you're interested in.
I run ip-masq on my
firewall and it's able to speedily rewrite packets - the machine is a P120. SOAP packets are
clearly marked, and it would be of no effort to block them if the need ever rose. Also, firewalls
could efficiently block them.
It's one thing to rewrite packets on your personal firewall. It's another thing when it's the firewall/proxy for a large company, one that's possibly already overloaded, and may or may not even support rewriting depending on what sort of network appliance you've plugged in there.
Which is still missing the point, anyway - we have ports so that services can be more easily distinguished. It's nuts to say that we're now going to run everything over the same port just because we can't be bothered to make those distinctions, and then deal with analyzing and rewriting packets to make up for our failure to distinguish.
Re:FYI: SOAP is not transport/port specific
on
Web Services
·
· Score: 1
Actually, I'm aware of that, but look at how it is actually being implemented in the field and how it is being evangelized, especially by Microsoft. One of the prime selling points (picked up by many people in this article) is "you don't have to punch new holes in your firewall". As long as that is the popular perception of web services, then the security isn't going to be there.
Re:Because...
on
Web Services
·
· Score: 2, Insightful
Where i work, the only thing that the end user has on their desktop apart from the standard tools
for the job, is IE (no, we dont permit anyone to install Mozilla, basically because theres no point
and we wont support it).
If you're not part of the solution...
SO the more things we can pump over the standard http protocol to the
end user the better.
...you're part of the problem.
And we dont have PHBs here, all these decisions are made by
the people that have to implement them, and the people that use them.
I think you're missing the people that think about the consequences of those decisions - you know, things like "does running a service over port 80 magically make it secure?" and "hmmmm, so if we're going to do everything over port 80, what was the point of our firewall again?".
On the other hand, having no PHBs means that you can theoretically turn on a dime and start improving things almost immediately. Good for you!
Re:Becuase of Stupidity of course
on
Web Services
·
· Score: 5, Insightful
So, you think you know security, but anything that's tunneled through HTTP/HTTPS is OK with you? You really don't understand security.
SOAP et al are a mistaken implementation for exactly that reason, in a typical Microsoft fashion: by running everything over HTTP, we can get things working quickly without wondering whether they are secure. Later on, there will be a ton of SOAP security holes and information leaks, but we won't be able to plug the hole properly since we can't cut off HTTP without strangling our businesses. I love innovation without cogitation.
An absolute godsend to good firewall administrators would be to have specific services on specific ports so that you could easily audit the use of such services separately and have a better handle on what's going in and out of your 'net. You could, for example, inspect SOAP packets for a particular service without having to slow down all traffic through your HTTP proxy. But since you're a lazy bastard, I bet you don't care:)
News flash (from one who can remember this long-past mythical time): karma was instituted to encourage good posters to make more good posts. The whole point was to encourage actions of which karma is the (imperfect) measure. Are people supposed to be fixated on their karma? Of course not. But that doesn't make the current bizarre meme that "public accumulation of karma is evil" right either.
"Karma Whoring" is, if anything, a problem of the moderators at times; it is not a problem of the author of the post. Especially not in this case, where the posts were dated 3 minutes apart, and thus it would have been impossible for this poster to have seen the other post in time to not make his or her own redundant post.
So: be an AC if you for some reason don't want to post under your account name. But don't accuse people that do post under their account of being karma whores. Maybe they just like to own up to their own comments, good or bad. Unlike yourself.
Are you sure you didn't happen to moderate or meta-moderate on the Post of Doom? Apparently a lot of people saw their moderator and meta-moderator access silently whacked due to that. I think (although since moderation and meta-moderation records aren't available, and it was a while before I noticed the lack of meta-mod opportunities, I can't be sure) that that's what happened to me.
So, no matter how good a moderator and/or meta-moderator you are, just remember: one moderation or meta-moderation that the "editors" disagree with (not necessarily a bad moderation or meta-moderation, just one that is unpopular with a very small group of people), and all your past hard work and positive contributions to this site are for naught.
If you'd read the whole article, or informed yourself about the DMCA, you'd know that delisted sites can file a countercomplaint and be added back into the listing. The countercomplaint just says that the posting site (not Google) is legally responsible for the content. So there is a mechanism for the real protest sites like xenu.net to shoulder responsibility for their content, rather than letting Google shoulder it all.
This case is a little weird, since the site proprietor is saying that filing the counterclaim would put him under U.S. jurisdiction. I'm not sure if that's a legal interpretation, or if the DMCA says that, or what. I don't see how just affirming that the contents of your site do not infringe on the DMCA somehow automatically renders you liable to suit under U.S. law, but maybe that's just me.
Really, Google is showing a lot more spine than most ISPs/publishers/etc. - at least they are informing people about the DMCA and the complaints at the same time that they are following their legal responsibility to delist the items. Most publishers would just drop the whole thing without a trace and go on with their lives.
Hey, nobody ever said that the law had to make sense. Our only requirement is that it "protect the children" and sounds good in a 10-second sound bite on the evening news.
If all software developers worked for free, what would your job be? How would you put
food on the table?
But it's not particularly valid. The question isn't whether software developers should work for free, but whether the software itself should be free. And that's a very different discussion.
The majority of software is written and used deep within corporations; it never sees the light of day. It isn't sold to consumers or to businesses; it's as much a part of a business as the chairs in the cubicles. There will always be software developers getting paid to write this stuff, and to write custom software for embedded devices that have special needs. Software developers will never have to work for free.
But, if those developers are able to use software that is itself free as the basis for their work, then the costs to their employer are reduced. Where does this savings go? Into paying the developers better, more profit for the business, or better prices for the end user of the business' processes and/or embedded products that make use of the software.
I put plenty of money on the table working with free software right now, and if I had my druthers I'd be working with it entirely. It's easier to use, easier and more well-thought-out to configure, has fewer licensing and cost issues for management, and doesn't mind me tinkering with it. Right now, can my employer's business do everything with free software? No, not quite. But would the business, and the software developers that it employs, be better off if it could run on free software? Absolutely.
So yes, Red Hat et al should get their acts together, but let's face it - they're essentially always going to be fairly low-margin operations. The question is: with the amount of money that eMexico is putting up, could a small team of hackers (Miguel, even) have been hired to make Red Hat Linux more than usable for the goals of eMexico? Definitely - and with money left over, to boot. The goal is online access for millions of people; the point is not proprietary software. eMexico took the easy way out of that decision, not the smart way, and not the cheaper way.
P.S. - do you really think that the majority of the citizens of Mexico that are getting online with this initiative will want to pay $14 (or whatever) for Microsoft Office? Or, more exactly, do you think that the $14 is worth the difference between Microsoft Office and Open Office? When $14 might be a day's wage, or more?
Last time I checked, receiving spam wasn't something that I had a choice about. I suppose you could say that my ISP's mail server had the choice not to accept the message, but there's not really a standard for making that decision, at least in the same way that a web server can check referrers to make a decision about serving a page.
The thing with spam is that it often masquerades as a real message, so you pretty much have to download it to find out that it's spam. Or else just ignore mail from anyone you don't know, which isn't always a viable option. Spam uses fraud (often including forged headers and poorly-secured third-party servers) to work; essentially removing the choice of whether or not to get spam from the reach of most people. If the choice of whether or not to get spam were as simple as the choice whether or not to accept a collect call, don't you think most people would choose not to get spam?
I can't believe that none of you got the joke/irony here. Calling someone collect means that they get to choose whether to pay to talk to you. Requesting a page from a web server means that the web server gets to choose whether to give you the page (possibly based on your referrer, etc). It is exactly like calling collect - the choice is entirely up to the responder, not the requester.
Basically aozilla agrees with everyone else, he/she just didn't include the smiley so that you could get the joke. So here it is:
The Microsoft statement is that the preinstalled OS must remain with the machine throughout its lifetime. This is not true.
It is true that the OEM copy of the OS that came with the new machine is only licensed for use on that machine. Therefore, if someone donates you the machine, but not the OS, then you can't use the OS and neither can they. There is no requirement that the OS stay with the machine, though.
Microsoft is making false claims here in their efforts to simplify the matter.
Slashdot Mirror
So, when did you stop beating your wife?
Or backups, but no backup verification. Do you feel luck today?
That is exactly why I made that comment, thanks for catching on :)
...except you won't see them in airports, apparently :)
The problem is that only some people will have the ability, technology, or money to change those characteristics. Sure, there are a few billionaires that dress like bums, but that doesn't stop society as a whole from evaluating people on how they look. It would take a lot of rich and poorly-dressed people to significantly change that outlook. So, you really only get away from grouping people at the point where it would be too difficult to group them anyway. Although I admire the sentiment, I just don't see that happening any time soon. If anything, the wealthy are getting wealthier at this point.
Windows already overwrites your MBR if you reinstall on a dual-boot Linux system, doesn't it? So in a sense it already doesn't play well with others.
You'd be safer if you understood the risks and benefits of the network services you make available to the outside world. You can't just say "ports 25 and 80 OK, other ports bad" and have that be security. Insofar as SOAP tries to pretend that you don't have to understand security and at the same time makes more things available over port 80 than it was originally intended for, it is a security liability.
Menus on Mandrake are totally hosed - for one thing, if you customize your menus with kmenuedit, and then install a Mandrake package (not sure exactly what the trigger is) your menus are replaced with the default set. So I've started just backing up the menus whenever I change 'em, so that I can always fall back on a known good set.
For this (and a couple other reasons) I probably wouldn't install Mandrake on a new machine, unless it's for a new Linux user who won't be doing their own configuration.
Really, considering the quality of the playback, etc., from mplayer, I didn't find the installation to be too complicated. They told you exactly what to download from where, what to type, etc. to get it working. For a guy who claims not to speak English very well, the setup instructions were easier to follow than some I've read that were written by native English speakers :) And it does work and work well, even on a K6-2/350, sans a couple quibbles I have with their GUI. And I'm even using an old version - time to upgrade tonight.
Frankly, I don't care how spikey they are to work with, because the product works great for multimedia on Linux.
I don't have a problem with XML-RPC really - it's good to be able to do things remotely via a standardized protocol. But I think that the latest implementations of that idea are not well-thought-out from a security perspective.
It's not a pointless argument at all. The whole point of a firewall administrator's job is to keep track of what's going in and out and the cost/benefit analysis of that traffic. A good firewall administrator doesn't mind opening new ports; he or she minds opening up to new risks. Sometimes (almost always, I would argue) putting a new service on a new and distinctive port makes it less of a risk than commingling it with the rest of your HTTP traffic. Running everything over port 80 makes it easier to get things past a bad firewall admin, but that's not really the point - you should get a better firewall admin in the first place, or else just admit that understanding your security exposure isn't what you're interested in.
It's one thing to rewrite packets on your personal firewall. It's another thing when it's the firewall/proxy for a large company, one that's possibly already overloaded, and may or may not even support rewriting depending on what sort of network appliance you've plugged in there.
Which is still missing the point, anyway - we have ports so that services can be more easily distinguished. It's nuts to say that we're now going to run everything over the same port just because we can't be bothered to make those distinctions, and then deal with analyzing and rewriting packets to make up for our failure to distinguish.
Actually, I'm aware of that, but look at how it is actually being implemented in the field and how it is being evangelized, especially by Microsoft. One of the prime selling points (picked up by many people in this article) is "you don't have to punch new holes in your firewall". As long as that is the popular perception of web services, then the security isn't going to be there.
If you're not part of the solution...
...you're part of the problem.
I think you're missing the people that think about the consequences of those decisions - you know, things like "does running a service over port 80 magically make it secure?" and "hmmmm, so if we're going to do everything over port 80, what was the point of our firewall again?".
On the other hand, having no PHBs means that you can theoretically turn on a dime and start improving things almost immediately. Good for you!
So, you think you know security, but anything that's tunneled through HTTP/HTTPS is OK with you? You really don't understand security.
SOAP et al are a mistaken implementation for exactly that reason, in a typical Microsoft fashion: by running everything over HTTP, we can get things working quickly without wondering whether they are secure. Later on, there will be a ton of SOAP security holes and information leaks, but we won't be able to plug the hole properly since we can't cut off HTTP without strangling our businesses. I love innovation without cogitation.
An absolute godsend to good firewall administrators would be to have specific services on specific ports so that you could easily audit the use of such services separately and have a better handle on what's going in and out of your 'net. You could, for example, inspect SOAP packets for a particular service without having to slow down all traffic through your HTTP proxy. But since you're a lazy bastard, I bet you don't care :)
Oh No! Not Karma Whoring!
News flash (from one who can remember this long-past mythical time): karma was instituted to encourage good posters to make more good posts. The whole point was to encourage actions of which karma is the (imperfect) measure. Are people supposed to be fixated on their karma? Of course not. But that doesn't make the current bizarre meme that "public accumulation of karma is evil" right either.
"Karma Whoring" is, if anything, a problem of the moderators at times; it is not a problem of the author of the post. Especially not in this case, where the posts were dated 3 minutes apart, and thus it would have been impossible for this poster to have seen the other post in time to not make his or her own redundant post.
So: be an AC if you for some reason don't want to post under your account name. But don't accuse people that do post under their account of being karma whores. Maybe they just like to own up to their own comments, good or bad. Unlike yourself.
In case you don't get the joke (like I didn't at first) read: http://www.xenu.net/archive/footbullet/
Are you sure you didn't happen to moderate or meta-moderate on the Post of Doom? Apparently a lot of people saw their moderator and meta-moderator access silently whacked due to that. I think (although since moderation and meta-moderation records aren't available, and it was a while before I noticed the lack of meta-mod opportunities, I can't be sure) that that's what happened to me.
So, no matter how good a moderator and/or meta-moderator you are, just remember: one moderation or meta-moderation that the "editors" disagree with (not necessarily a bad moderation or meta-moderation, just one that is unpopular with a very small group of people), and all your past hard work and positive contributions to this site are for naught.
Why no, not bitter at all. Why do you ask?
If you'd read the whole article, or informed yourself about the DMCA, you'd know that delisted sites can file a countercomplaint and be added back into the listing. The countercomplaint just says that the posting site (not Google) is legally responsible for the content. So there is a mechanism for the real protest sites like xenu.net to shoulder responsibility for their content, rather than letting Google shoulder it all.
This case is a little weird, since the site proprietor is saying that filing the counterclaim would put him under U.S. jurisdiction. I'm not sure if that's a legal interpretation, or if the DMCA says that, or what. I don't see how just affirming that the contents of your site do not infringe on the DMCA somehow automatically renders you liable to suit under U.S. law, but maybe that's just me.
Really, Google is showing a lot more spine than most ISPs/publishers/etc. - at least they are informing people about the DMCA and the complaints at the same time that they are following their legal responsibility to delist the items. Most publishers would just drop the whole thing without a trace and go on with their lives.
Hey, nobody ever said that the law had to make sense. Our only requirement is that it "protect the children" and sounds good in a 10-second sound bite on the evening news.
I didn't think people actually said "you fool", at least other than in melodramatic movies. You must lead a swashbuckling life :)
Not if we have the Sonny Bono Patent Extension Act :)
That's a nice straw man:
But it's not particularly valid. The question isn't whether software developers should work for free, but whether the software itself should be free. And that's a very different discussion.
The majority of software is written and used deep within corporations; it never sees the light of day. It isn't sold to consumers or to businesses; it's as much a part of a business as the chairs in the cubicles. There will always be software developers getting paid to write this stuff, and to write custom software for embedded devices that have special needs. Software developers will never have to work for free.
But, if those developers are able to use software that is itself free as the basis for their work, then the costs to their employer are reduced. Where does this savings go? Into paying the developers better, more profit for the business, or better prices for the end user of the business' processes and/or embedded products that make use of the software.
I put plenty of money on the table working with free software right now, and if I had my druthers I'd be working with it entirely. It's easier to use, easier and more well-thought-out to configure, has fewer licensing and cost issues for management, and doesn't mind me tinkering with it. Right now, can my employer's business do everything with free software? No, not quite. But would the business, and the software developers that it employs, be better off if it could run on free software? Absolutely.
So yes, Red Hat et al should get their acts together, but let's face it - they're essentially always going to be fairly low-margin operations. The question is: with the amount of money that eMexico is putting up, could a small team of hackers (Miguel, even) have been hired to make Red Hat Linux more than usable for the goals of eMexico? Definitely - and with money left over, to boot. The goal is online access for millions of people; the point is not proprietary software. eMexico took the easy way out of that decision, not the smart way, and not the cheaper way.
P.S. - do you really think that the majority of the citizens of Mexico that are getting online with this initiative will want to pay $14 (or whatever) for Microsoft Office? Or, more exactly, do you think that the $14 is worth the difference between Microsoft Office and Open Office? When $14 might be a day's wage, or more?
Last time I checked, receiving spam wasn't something that I had a choice about. I suppose you could say that my ISP's mail server had the choice not to accept the message, but there's not really a standard for making that decision, at least in the same way that a web server can check referrers to make a decision about serving a page.
The thing with spam is that it often masquerades as a real message, so you pretty much have to download it to find out that it's spam. Or else just ignore mail from anyone you don't know, which isn't always a viable option. Spam uses fraud (often including forged headers and poorly-secured third-party servers) to work; essentially removing the choice of whether or not to get spam from the reach of most people. If the choice of whether or not to get spam were as simple as the choice whether or not to accept a collect call, don't you think most people would choose not to get spam?
I can't believe that none of you got the joke/irony here. Calling someone collect means that they get to choose whether to pay to talk to you. Requesting a page from a web server means that the web server gets to choose whether to give you the page (possibly based on your referrer, etc). It is exactly like calling collect - the choice is entirely up to the responder, not the requester.
Basically aozilla agrees with everyone else, he/she just didn't include the smiley so that you could get the joke. So here it is:
:)
The Microsoft statement is that the preinstalled OS must remain with the machine throughout its lifetime. This is not true.
It is true that the OEM copy of the OS that came with the new machine is only licensed for use on that machine. Therefore, if someone donates you the machine, but not the OS, then you can't use the OS and neither can they. There is no requirement that the OS stay with the machine, though.
Microsoft is making false claims here in their efforts to simplify the matter.