Why all this obsession with identification? A National ID card, showing ID, blah blah blah. I'd like to figure out a way of preventing hijacking no matter who's on the flight. Our focus has been on this pusillanimous identity B.S., and it should be on real security measures like remote seatbelt locking, armed sky marshals, reinforced doors and the like.
hills - I'm sure. You can't receive your $10/mo. $200 radio when you're around hills. Why would anyone pay for that? Sure I pay to receive commercial-laden basic cable channels, but at least I can receive them in spite of my hill.
If a majority of the particular gaming community doesn't want you there (for whatever reason--you're cheating, you're an asshole, you unbalance their game with your "superhuman skill") you should be out. I think voting is an excellent idea actually.
The problem is not one of unpopular players being voted out "unfairly"--but of cheating the election!
This seems like a secure solution for a small shop, where the boxes are physically located in the same working place as the administrators.
This is why I would prefer a pass phrase rather than a key stored on removable media. That way the administrators do not have to physically be located near the machines.
When servers go down and then come back up, you can't have your site inoperable because the console is stuck at some password prompt, waiting for human intervention. I say this from experience: just last night one of our backend Solaris machines had some kind of trouble and rebooted itself.
Yes, depending on how the application needs to be supported and its uptime requirements, it may not be possible. I suppose it's a balance between uptime requirements, how much you want to pay for support staff, and how important it is to reduce the likelihood of compromising that private data.
Honestly, I don't know the best solution to the original question, but my experience says that it's better to automate and be able to shut down quickly when there is suspicious activity rather than relying on human intervention for routine activities such as starting up services/applications.
Well, actually I don't think what I suggest affects the ability to shut down quickly.
It's a good point. I suppose I was thinking more in terms of the persistence of the disk storage. Is your point that it isn't helpful to use encrypted swap or mlock()? Or that requiring the decryption key on server startup is no better than storing it in a file?
I've done something similar before (though it was passwords, not credit card data) and the trick is to not store the secret key anywhere, especially on the server that stores the data.
I coded a server component that could decide whether a requester could view an encrypted datum (for example, if the requester authenticated correctly) and decrypt it using a key stored only in memory, that had to be entered by a human being to start the server. The humans who could administer the server memorized the key. A small enough amount of data was stored that changing the key was feasible.
This server was in perl, but the encryption/decryption code was in C; I used blowfish (libblowfish) and also stored the key in a C buffer pointed to by a perl scalar, and used the mlock() system call to prevent the key from being swapped--an alternative might be to use OpenBSD where it is possible to encrypt the swap area.
Anyway, I hope that gives you some ideas. Any form of storing or recording the decryption key reduces to storing the credit card numbers in plaintext, so you should avoid that.
It doesn't really matter in the human experience whether life is general in the universe, or even in our galaxy. What matters is what we can find, and that restricts our neighborhood rather severely. Okay, so life we can understand can only exist in narrow bands of hospitality. Great--we're in one! What better place to look for other life?
You've both got it wrong. Salary should be determined by what the employee is willing to work for and what the employer is willing to pay.
At one time the H1-B situation was highly unfair because for the H1-B worker, leaving the job was tantamount to leaving the country, due to the way the visa worked (the fact that you could start work until the visa process was complete). However, now such workers are much more transferable, as they can start working while their visas are not yet done.
I don't want any company making a decision on *my* salary based on anything but what I demand. If I think an employer has offered to pay me too little, why would I accept that position? If labor market forces mean that an employer can get the same productivity out of someone else for less, then they should choose that option, and I might need to adjust my value, and the salary I demand, accordingly. That's just the way a market, including a labor market, works.
But an EULA isn't exactly equivalent to copyright. The EULA defines restrictions on use that go beyond what you can't do with copyrighted material.
I think it's okay if RadLight wants to bundle required advertising software in with their stuff so they can afford to {maintain servers,program full-time,hire hookers}. The problem here is the method. After all, I don't think anyone would be that upset if RadLight refused to start if it's accompanying advertising/marketing software wasn't still there. Or if RadLight refused to install in the presence of Adaware. They've just gotten their method backwards.
I think you have some (common) misconceptions about the nature of free software, and since you were very polite and articulate in making your points I hope the respondents will be in return.
First, you are correct in thinking the focus of the GPL is not on your firm's ability to maximize profit, but to maximize users' rights; although you may bemoan these provisions when you are on the programming side of your relationship with your client, you will welcome them when dealing with the software you use.
Your client benefits from having the source code to your modifications--you may not like it, but it means your client's staff or other consulting companies that offer them a better deal in the future can understand what's going on. If you had used a non-free OS like Windows, and Microsoft decided to change their OS in a backwards incompatible way, your client would be screwed. Do you want your client to be screwed after dealing with you? How would you feel if the situation were reversed?
In the particular relationship you describe, you are the vendor and your client (not you) is benefitted by using free software. But in many other relationships, you are the client and will benefit because you've used free software.
Another misconception that you have is that anything touched by GPL tools must be released under the GPL. This runs counter to practice and although IANAL (I am not a lawyer) I don't think it's true. Your company could probably benefit from bringing your issues to the Free Software Foundation and asking them for help in complying with the GPL. In particular, I don't think every program compiled with gcc must be released under the GPL, or every script using the Perl interpreter, and so on. In fact, *BSD uses gcc so I dont' think it could be GPL.
Thirdly, you seem to be under the impression that Linux has a controlling force, like a company, that determines its direction, and that the main focus of Linux is to "compete" with Windows. The focus of a free OS is to provide a free and functional alternative to non-free OSes for those that want it. This is an alternative that would not otherwise exist, and it makes the world a better place by empowering the users of software, who otherwise have very little in the way of rights for the software they use.
Lastly, there are other open-source OSes that may have licenses you prefer. In particular it sounds like the BSD variants, which can be used to produce non-free products, may fit your needs better. However, I would still encourage you to consider using free (not just open-source) software.
Although it takes a little getting used to, and is sometimes hard to conceive, free software has many benefits for you and your clients. I hope you keep an open mind, make an effort to learn about free software a little, and consider using it in the future.
Yeah, Scott Bakula is a poor choice. The perfect
choice for a starship captain would be Eamonn Walker, who plays Kareem Said on Oz; but I think the Star Trek folks figured they already had a black guy, and a woman, so they could go back to white guy captains.
Look at it if you will, but we haven't liked it.
It's actually kind of complicated for non-technical types (as opposed to lightly technical types which can usually grok it). I found it silly that we had to have *classes* for most people to use it, and yes, it's very much geared toward building websites, use of the browser and it has a cumbersome workspace and locking scheme. My company uses teamsite, my group tried it for a while, didn't like it, and went to CVS + Apache + cron.
Yeah, me too. I kept thinking "no way!"
and then thinking, "but what if?" until
I got to the sample code above. It really
is the most hilarious part of the whole prank
in its understated way ("dollar_underscore"?
"continue_next"--hilarious but not as funny
as the ":" "}" pairing, which is inspired).
The sad thing is, when I get to work (a python
shop in which I'm a rare Perler) people will
be mailing this link around in all seriousness.
I was running bind 8 in a chroot jail and when
I built bind 9 it barfed a little, but all I
really needed to do was make the/var/run
under the chroot directory world writable. And
bind 9 complained about not having a $TTL
directive in my zone files. Once I fixed those
things, I was up and running without having to
change named.conf.
I found the following things helpful:
named -g -u <user> -t <chroot_dir>
this runs named in the foreground without
writing to log files and lets you see what's
going on with it for troubleshooting. I
also used ktrace to good effect: use truss
on Solaris, strace on Linux and ktrace on
BSDs and you'll see what named is trying to
do (in particular, which files it's trying to
open).
When my local paper reviewed the X-Men, it made an excellent point--namely, light shows are cheesy. It doesn't really matter how computer-generated they are, they just are.
And another thing that's cheesy? Live-action people flying around. You can make that look cool in the comix, but Ian McKellen levitation around the screen brings Baron Harkonnen from Lynch's Dune more to mind than menace.
I agree. I was going to post a message with this Subject: but jfrisby beat me to it.
And, to bring things to a more concrete level, the kinds of features in a trusted system, like Trusted Oracle or Trusted HP-UX, are simply missing from any open source OS, secure though they may be. For example, trusted HP-UX provides the rich auditing facility and DAC (discretionary access control) required by TCSEC level C2, OpenBSD has none of these.
No ISP has tried this in the past? Are you joking? Every ISP does this with at least its own content, and usually that of several "partners" (think of AOL).
Back to the original poster--"the company that is for open access..."; is he high? E@H has never been for open access, they've been fighting it tooth and nail.
Well, I don't think the interview was dumb. It's unfortunate that Lars didn't answer the questions in writing, frankly, because a transcript of a phone conversation does sound pretty stupid, although I also think that helped convince people that Metallica, not the record label, was behind the lawsuit.
But Lars really doesn't get it--he says his beef is not with fans or individual napster users; but it is! He doesn't understand peer-to-peer file sharing--he thinks people are downloading pirated Metallica mp3s from napster.com. He thinks the same kind of central "company" organization is happening with Gnutella and so forth.
His beef isn't with Napster any more than with ISPs or the phone company, all three of which provide the medium for exchanging musing, it's with the end users themselves. And that's ugly, although I think it's within Metallica's right.
This is absolutely true, as many people have explained on this thread. And yet RMS continues to trumpet the position that copyright is bad--this shows that Stallman is not motivated by morality but by self-interest. That is, he would like music for free (as in beer) and so he decries copyright, but would like software for free (as in speech) and uses copyright to ensure it. That's hypocrisy.
I am also an Oracle DBA working in silicon valley and would basically second everything the poster says. That said, many people are very attached to the idea of automated failover, and we will probably be implementing some form of cluster software in addition to the described standby database solution.
Well, perl hands you whatever it got in its struct tm, which is the number of years since 1900 (point being it isn't perl-specific, this is a feature of standard unix date-handling routines). So it's not necessarily a perl script.
Slashdot Mirror
by Bruce Schneier. The book is enjoyable and has saved me from several gaffes when using crypto for applications.
Hear hear.
Why all this obsession with identification? A National ID card, showing ID, blah blah blah. I'd like to figure out a way of preventing hijacking no matter who's on the flight. Our focus has been on this pusillanimous identity B.S., and it should be on real security measures like remote seatbelt locking, armed sky marshals, reinforced doors and the like.
hills - I'm sure. You can't receive your $10/mo. $200 radio when you're around hills. Why would anyone pay for that? Sure I pay to receive commercial-laden basic cable channels, but at least I can receive them in spite of my hill.
Hear hear.
If a majority of the particular gaming community doesn't want you there (for whatever reason--you're cheating, you're an asshole, you unbalance their game with your "superhuman skill") you should be out. I think voting is an excellent idea actually.
The problem is not one of unpopular players being voted out "unfairly"--but of cheating the election!
This seems like a secure solution for a small shop, where the boxes are physically located in the same working place as the administrators.
This is why I would prefer a pass phrase rather than a key stored on removable media. That way the administrators do not have to physically be located near the machines.
When servers go down and then come back up, you can't have your site inoperable because the console is stuck at some password prompt, waiting for human intervention. I say this from experience: just last night one of our backend Solaris machines had some kind of trouble and rebooted itself.
Yes, depending on how the application needs to be supported and its uptime requirements, it may not be possible. I suppose it's a balance between uptime requirements, how much you want to pay for support staff, and how important it is to reduce the likelihood of compromising that private data.
Honestly, I don't know the best solution to the original question, but my experience says that it's better to automate and be able to shut down quickly when there is suspicious activity rather than relying on human intervention for routine activities such as starting up services/applications.
Well, actually I don't think what I suggest affects the ability to shut down quickly.
Thanks for your thoughts.
It's a good point. I suppose I was thinking more in terms of the persistence of the disk storage. Is your point that it isn't helpful to use encrypted swap or mlock()? Or that requiring the decryption key on server startup is no better than storing it in a file?
I've done something similar before (though it was passwords, not credit card data) and the trick is to not store the secret key anywhere, especially on the server that stores the data.
I coded a server component that could decide whether a requester could view an encrypted datum (for example, if the requester authenticated correctly) and decrypt it using a key stored only in memory, that had to be entered by a human being to start the server. The humans who could administer the server memorized the key. A small enough amount of data was stored that changing the key was feasible.
This server was in perl, but the encryption/decryption code was in C; I used blowfish (libblowfish) and also stored the key in a C buffer pointed to by a perl scalar, and used the mlock() system call to prevent the key from being swapped--an alternative might be to use OpenBSD where it is possible to encrypt the swap area.
Anyway, I hope that gives you some ideas. Any form of storing or recording the decryption key reduces to storing the credit card numbers in plaintext, so you should avoid that.
It doesn't really matter in the human experience whether life is general in the universe, or even in our galaxy. What matters is what we can find, and that restricts our neighborhood rather severely. Okay, so life we can understand can only exist in narrow bands of hospitality. Great--we're in one! What better place to look for other life?
You've both got it wrong. Salary should be determined by what the employee is willing to work for and what the employer is willing to pay.
At one time the H1-B situation was highly unfair because for the H1-B worker, leaving the job was tantamount to leaving the country, due to the way the visa worked (the fact that you could start work until the visa process was complete). However, now such workers are much more transferable, as they can start working while their visas are not yet done.
I don't want any company making a decision on *my* salary based on anything but what I demand. If I think an employer has offered to pay me too little, why would I accept that position? If labor market forces mean that an employer can get the same productivity out of someone else for less, then they should choose that option, and I might need to adjust my value, and the salary I demand, accordingly. That's just the way a market, including a labor market, works.
I agree. Isn't a technical solution a lot easier than cease-and-desist notices and bad press?
But an EULA isn't exactly equivalent to copyright. The EULA defines restrictions on use that go beyond what you can't do with copyrighted material.
I think it's okay if RadLight wants to bundle required advertising software in with their stuff so they can afford to {maintain servers,program full-time,hire hookers}. The problem here is the method. After all, I don't think anyone would be that upset if RadLight refused to start if it's accompanying advertising/marketing software wasn't still there. Or if RadLight refused to install in the presence of Adaware. They've just gotten their method backwards.
I think you have some (common) misconceptions about the nature of free software, and since you were very polite and articulate in making your points I hope the respondents will be in return.
First, you are correct in thinking the focus of the GPL is not on your firm's ability to maximize profit, but to maximize users' rights; although you may bemoan these provisions when you are on the programming side of your relationship with your client, you will welcome them when dealing with the software you use.
Your client benefits from having the source code to your modifications--you may not like it, but it means your client's staff or other consulting companies that offer them a better deal in the future can understand what's going on. If you had used a non-free OS like Windows, and Microsoft decided to change their OS in a backwards incompatible way, your client would be screwed. Do you want your client to be screwed after dealing with you? How would you feel if the situation were reversed?
In the particular relationship you describe, you are the vendor and your client (not you) is benefitted by using free software. But in many other relationships, you are the client and will benefit because you've used free software.
Another misconception that you have is that anything touched by GPL tools must be released under the GPL. This runs counter to practice and although IANAL (I am not a lawyer) I don't think it's true. Your company could probably benefit from bringing your issues to the Free Software Foundation and asking them for help in complying with the GPL. In particular, I don't think every program compiled with gcc must be released under the GPL, or every script using the Perl interpreter, and so on. In fact, *BSD uses gcc so I dont' think it could be GPL.
Thirdly, you seem to be under the impression that Linux has a controlling force, like a company, that determines its direction, and that the main focus of Linux is to "compete" with Windows. The focus of a free OS is to provide a free and functional alternative to non-free OSes for those that want it. This is an alternative that would not otherwise exist, and it makes the world a better place by empowering the users of software, who otherwise have very little in the way of rights for the software they use.
Lastly, there are other open-source OSes that may have licenses you prefer. In particular it sounds like the BSD variants, which can be used to produce non-free products, may fit your needs better. However, I would still encourage you to consider using free (not just open-source) software.
Although it takes a little getting used to, and is sometimes hard to conceive, free software has many benefits for you and your clients. I hope you keep an open mind, make an effort to learn about free software a little, and consider using it in the future.
Yeah, Scott Bakula is a poor choice. The perfect
choice for a starship captain would be Eamonn Walker, who plays Kareem Said on Oz; but I think the Star Trek folks figured they already had a black guy, and a woman, so they could go back to white guy captains.
Look at it if you will, but we haven't liked it.
It's actually kind of complicated for non-technical types (as opposed to lightly technical types which can usually grok it). I found it silly that we had to have *classes* for most people to use it, and yes, it's very much geared toward building websites, use of the browser and it has a cumbersome workspace and locking scheme. My company uses teamsite, my group tried it for a while, didn't like it, and went to CVS + Apache + cron.
Yeah, me too. I kept thinking "no way!"
and then thinking, "but what if?" until
I got to the sample code above. It really
is the most hilarious part of the whole prank
in its understated way ("dollar_underscore"?
"continue_next"--hilarious but not as funny
as the ":" "}" pairing, which is inspired).
The sad thing is, when I get to work (a python
shop in which I'm a rare Perler) people will
be mailing this link around in all seriousness.
I was running bind 8 in a chroot jail and when /var/run
I built bind 9 it barfed a little, but all I
really needed to do was make the
under the chroot directory world writable. And
bind 9 complained about not having a $TTL
directive in my zone files. Once I fixed those
things, I was up and running without having to
change named.conf.
I found the following things helpful:
named -g -u <user> -t <chroot_dir>
this runs named in the foreground without
writing to log files and lets you see what's
going on with it for troubleshooting. I
also used ktrace to good effect: use truss
on Solaris, strace on Linux and ktrace on
BSDs and you'll see what named is trying to
do (in particular, which files it's trying to
open).
I'm running OpenBSD and (now) BIND 9.1
When my local paper reviewed the X-Men, it made an excellent point--namely, light shows are cheesy. It doesn't really matter how computer-generated they are, they just are.
And another thing that's cheesy? Live-action
people flying around. You can make that look cool in the comix, but Ian McKellen levitation around the screen brings Baron Harkonnen from Lynch's Dune more to mind than menace.
I agree. I was going to post a message with this Subject: but jfrisby beat me to it.
And, to bring things to a more concrete level,
the kinds of features in a trusted system, like Trusted Oracle or Trusted HP-UX, are simply missing from any open source OS, secure though they may be. For example, trusted HP-UX provides the rich auditing facility and DAC (discretionary access control) required by TCSEC level C2, OpenBSD has none of these.
No ISP has tried this in the past? Are you joking? Every ISP does this with at least its own content, and usually that of several "partners" (think of AOL).
Back to the original poster--"the company that is for open access..."; is he high? E@H has never been for open access, they've been fighting it tooth and nail.
Well, I don't think the interview was dumb. It's unfortunate that Lars didn't answer the questions in writing, frankly, because a transcript of a phone conversation does sound pretty stupid, although I also think that helped convince people that Metallica, not the record label, was behind the lawsuit.
But Lars really doesn't get it--he says his beef is not with fans or individual napster users; but it is! He doesn't understand peer-to-peer file sharing--he thinks people are downloading pirated Metallica mp3s from napster.com. He thinks the same kind of central "company" organization is happening with Gnutella and so forth.
His beef isn't with Napster any more than with ISPs or the phone company, all three of which provide the medium for exchanging musing, it's with the end users themselves. And that's ugly, although I think it's within Metallica's right.
This is absolutely true, as many people have explained on this thread. And yet RMS continues to trumpet the position that copyright is bad--this shows that Stallman is not motivated by morality but by self-interest. That is, he would like music for free (as in beer) and so he decries copyright, but would like software for free (as in speech) and uses copyright to ensure it. That's hypocrisy.
I am also an Oracle DBA working in silicon valley and would basically second everything the poster says. That said, many people are very attached to the idea of automated failover, and we will probably be implementing some form of cluster software in addition to the described standby database solution.
Well, perl hands you whatever it got in its
struct tm, which is the number of years since 1900
(point being it isn't perl-specific, this is a
feature of standard unix date-handling routines). So it's not necessarily a perl script.
There are three plots to choose from for TNG:
* Evil Data
* Stuck on Holodeck
* Q
Sometimes you can mix them, and have evil data on
the holodeck.
Just scan HR's mailboxes, and carefully. Heck, put them on some porn spam lists and allow them to see the folly of their ways.