Linux was once the same way. People doing stuff like this (imho) is what pushes the computing world further. There may not be a real good production use for it now, but who knows what will happen in the future. 10 years from now we might be talking about another hobby OS and asking what benefits it would offer over SkyOS?:)
The reason it gets so much attention is that people are now convinced that hobby OSs can actually become more.
They should have pay docked by the minute if they're late. Of course if they're a early that time doesn't count, and of course if at the end of the day it takes them longer to finish than the hours you are paying them for, them that must be their fault so they shouldn't be paid for that either.
Ummm, the article (you DID RTFA right?) was talking about wage payroll people, so yes, this applies. I don't know what kind of insane point you are trying to make here with the "not paying them for the time they put in" nonsense but every wage job I have ever had involved signing in and out so they knew how much to pay you. If you were scheduled for 8 hours and you show up a half hour late? guess what you don't get paid for that half hour (the horror!). On the same token, if you were asked to stay later and agreed, you got paid for the hours you put it over what you were scheduled for. This is the same concept that has been used since the stone age when quarry workers used sheet-rock for time cards and had them punched by sarcastic birds. Our technology has come a long way since the Flintstones era, but the way hourly wages work is still the same.
Fair enough. The Napster deploy was going to happen regardless how the registration was handled. I like to think of my only contribution as at least preventing a situation where we give a corporate entity a ton of personal information (which really is the only other alternative, restricting by IP address is not feasible).
At the end of the day, like anyone else I'm going to do what my employer wants me to do (within reason, if PSU ever initiates a plan to break the legs of small puppies, you can bet I'll be leaving).
And there are plenty of people who do NOT consider DRM to be evil, it is not like that is a universal opinion. I would assume the vast majority of consumers do not even care, until DRM bites them. For most people that is pretty rare. Furthermore, as long as the technology exists, people will use it. DRM technology is generally nothing more than x.509 PKI stuff, which like portscanners can be good or evil. It is up to the market and the governments to decide if DRM is acceptable or not. The jury is still pretty much out on that in general.
The funny thing is, you are one of the only posters here whoom I recognize by handle, and whose posts I used to respect...
Oh now that just hurts:)
I'm not saying I don't have my opinions on the politics of this, the DRM, and the "right or wrong" arguments, just that I wanted to post something informative amidst all the debate without getting dragged down into that.
And besides, as an employee of PSU (who's bosses know I post here as "finkployd") I probably shouldn't go off on a "DRM is evil" rant when we are using it. (despite the fact that DRM is, in fact, evil:) )
One piece of this that is not getting much attention right now (that would probably be of interest to/. readers) is the registration system. I'm not getting into the politics of this, the DRM or the "right or wrong" arguments.
In this initial rollout PSU and Napster decided to limit the service to students living in the residence halls. It does not matter which of the 21 campuses you are on, just that you live in a res hall.
We also needed to ACTIVELY protect the privacy of the students, not just to comply with FERPA but because we are not in the business of providing marketing data to private institutions.
The way we went about this was to use the Internet2 Middleware Initiative's Shibboleth software. Similar to Liberty in that it is a federated single sign on system that uses SAML, it is one of the unsung heros in this.
Without getting into TOO much low level detail of how Shib works (which is available at the above link for those interested), here is a quick overview of what we are doing:
Basically PSU students are redirected to Napster's shibboleth protected registration webpage (this shib component is an Apache auth module) which sends them back to a PSU server to do the actual authentication. The student authenticates to the web server (kerberos backended userid and password). This server is also a component of Shib and it redirects the user (actually an http post) back to the Napster reg system along with a SAML authentication assertion.
The SAML authentication assertion is a blob of XML data that contains an opaque handle for the user (used in the next step) and a URI back to the last piece of Shibboleth at PSU called the Attribute Authority. This assertion is also digitally signed with an x.509 cert (w3c's XML-Signature spec) so that Napster knows it can trust this (not tampered with, generated from a rogue "man in the middle" server, etc).
The last step is when Napster makes an SSL wrapped call to the Attribute Authority requesting attributes about the student who is trying to get in. Remember up to this point all they know is his opaque handle (long string of numbers which uniquely identifies the user, but provides no information). The Attribute Authority looks as the cert of the requesting server, sees that it is Napster and queries LDAP for the data about the user that it is allowed to release. This is configurable to be anything we have, name, email, address, department, semester standing, etc. HOWEVER we only pass TWO things to Napster. (1) an entitlement string that identifies whether or not that user is allowed to get this service, and (2) a persistent opaque handle, which is basically the userID encrypted with the name of the target site and a secret seed value.
The entitlement string is generated at PSU and is populated in the user's LDAP entry based on the criteria that was set (res hall students only for now) and the persistent opaque handle gives Napster something to look at to make sure each students only registers once, but they still have no idea who that user is or anything about them other than that they are a student at PSU in a res hall.
Now if the student chooses to use their PSU email address when creating their Napster account, or gives them their CC number because they want to purchase songs that is their decision. The doubleplus good factor here is that PSU does not give that data up. We merely assert on the user's behalf that they are allowed to sign up under this agreement.
This Shibboleth stuff is running on Linux at both places and with the exception of requiring Java at the Origin end (PSU), is entirely comprised of open source software. The Napster guys we worked with were also very clueful and were definitely down with Linux, using it except where Windows was necessary (WMA streaming)
This "trial rollout" is only available to students who live in the residence halls (for now). That brings the total population who can use this service down to around 15k
My main case is PKI. Java crypto functions run painfully slow. And when you scale that up it really starts to suck.
Generally we use Power chips or Sparc64, so processor issues are not really a problem.
There are plenty of reasons to complain about Java, but general performance isn't really one of them, especially with people having 3Ghz processors when a 500Mhz would run every app they have just fine.
Very true, and I am all for Java applets, I think that is a really cool use of the technology to serve a need. Now servlets are a totally different story.... Suddenly that 3Ghz is not nearly enough to support a servlet that needs to scale to a large population and do things that Java is horrible at (like crypto).
Well, anyone writing servers as opposed to applications....
I've never not been on a project where speed and performance were so important that C ended up being used (despite its shortcomings as compared to higher level languages). Granted I tend to do primarily security stuff for a large university, which is not really that common. But everyone's particular needs vary, and no language is ideal for everything.
I like java for some things, and the performance has even improved a bit lately. However if I am doing ANYTHING that has to scale and perform well under heavy load that uses cryptographic functions (especially public key encipherment), there is no way I can even seriously consider Java.
Someone (meaning anyone other than me) should do a benchmark of THAT, I'm sure it would be quite telling.
Not always though, I think the thing people neglect to consider is that there are times when performance and scale are important enough that the benefits of Java do NOT outweigh C, and vice versa.
I feel sad for someone who only has enough room in their world for one computer language.
Well, for performance it does. For cross platform compilation it rocks the house. If you really want performance you need to be using something like Intel's C compiler (which oddly was not tested)
I don't know, I tend to flip back and forth between Fox and CNN and while Fox certainly does throw a conservative slant into their reporting (moreso with their "talk shows" than with the actual news reporting), they do tend to be very accurate with the facts. And they generally seem to beat CNN to a lot of stories to boot.
That's a bit of an odd requirement, but a fair enough one I suppose.
Cross institution, higher education application.
Bouncy Castle is only one example of free crypto libs. I've personally been more impressed by its ability to do just about anything vs. performance.
BouncyCastle does what we need it to do, but is still orders of magnitude slower than openssl or even NSS (which thankfully does have a JCE interface but unfortunatly does not do java keystores)
Probably your best bet for an Open Source J2EE server would be JBoss.
That, and NSS are probably the directions we are going in. what we are talking about here is not a j2ee application, but just a simple servlet to do federated authentication/authorization with SAML. Either way though, I've heard a lot of good about JBoss.
One other thing you need to consider in an enterprise environment that many developers miss: If you're spending time hand optimizing code or troubleshooting server wide crashes caused by memory leaks or illegal memory access, you're wasting your employer's money.
Not to launch into "marketing brag mode here", but my university has become exceedingly good at developing in house solutions in C and avoiding these problems. When none of the existing webmail packages would scale well enough for our environment, we wrote out own. Same thing with our portal framework. It always amuses us when companies try to sell us solutions without understanding how large we actually are. Microsoft wanted us to use Exchange for our email system, until we pointed out our size (100,000 users, generally 3-4 million emails a day). We do that with 6 nodes in a few SP clusters (AIX and Sendmail), while Microsoft used some 100 servers for a population 1/4 of our size. Our experience has long been that we can develop better in house solutions (generally using C) than we can buy for most infrastructure applications.
A decent developer costs between $85-$130K per year.
Not in higher ed:( I make about half that and I maintain that I am a decent developer. However the benefits are nice: 24 vacation days a year, 75% tuition discount, freedom to play with some really cool tech, and job security, baby:)
While those are good points, one of the requirements for the software in question is that it is open source, and needs to involve only open source or at least free (like java) technologies. So I guess maybe my problem with java is that there are no decent free or open servlet containers, crypto libs, etc that can scale well and perform under a heavy load. Hence our preference for C.
I'm not trying to cut down Java, I have spent a long time working with it and I like it. But working in a huge enterprise setting was a big eye opener for me.
In one case, it was digitally signing signing XML. Java absolutly sucks as anything involving cryptography in my experience. One of the developers was able to get a decent speed boost using Mozilla's NSS library instead.
Another problem is servlet containers (like Tomcat). Frankly they just suck under any kind of heavy load.
Once you start talking about striping out the pieces that perform poorly in Java, it just makes more sense (in our situation anyway) to just write the whole thing in in C or another compiled language.
Odd. I wouldn't have thought you'd need to do that these days anyway.
If you think java scales and performs well, then you do not deal with the scale and performance requirements that I do. Congratulations. I understand I am really in the minority, but just because something works for someone, doesn't mean it works for everyone.
In the large enterprise setting where I work (100000 or so very active users) we have pretty much ruled out java for anything production that needs high availability. Java is nice for applets or client applications, but for server side stuff it just makes no sense at all for us (unless we decide we want to throw TONS of hardware at it).
Java is simply is not as fast as a compiled language (specifically C, which the majority of our stuff is done in). More importantly than that though, it does not scale nearly as well.
I value cellphones (hell, I carry two), but I also understand that I do not have to have it with me (or at least powered on) at all times. It is not an all or nothing approach. You are never going to convince me that people need cellphones turned on in movie theaters. Yes I know they can be silenced (mine is always on vibrate mode, I don't even know what my ring tone is) but 90% of the population seems to be unable to do that.
Do you need total privacy at all times? I don't care if the 911 people can track me while I am at the grocery store. I don't care if they can track me while I'm sitting at work. However maybe I'm visiting an AIDS clinic and do not want ANYONE know be able to find out I am there, so I leave the cell phone at home. Or I just turn it off while I am there.
Look, there is clearly some benefit to having trackable cellphones, it is not a horrible evil, 1984ish idea with no positive side effects. The article mentions that it can be turned off for everyone except 911 through the menu interface (should this be the default setting? I don't know I suppose that is a manufacturing issue).
My only reason for the arguably negative tone was there seemed to be a flood of people equating this to some tracking chip implanted in their skin, and enforced by law. Carrying a powered on cell phone is still a voluntary act. It is not like there is no option to ever escape the tracking.
Same here, but I would contend that AIX really shines in huge enterprise settings, which most people have never come in contact with and do not really see the benefits of it.
Slashdot Mirror
Linux was once the same way. People doing stuff like this (imho) is what pushes the computing world further. There may not be a real good production use for it now, but who knows what will happen in the future. 10 years from now we might be talking about another hobby OS and asking what benefits it would offer over SkyOS? :)
The reason it gets so much attention is that people are now convinced that hobby OSs can actually become more.
Finkployd
They should have pay docked by the minute if they're late. Of course if they're a early that time doesn't count, and of course if at the end of the day it takes them longer to finish than the hours you are paying them for, them that must be their fault so they shouldn't be paid for that either.
Ummm, the article (you DID RTFA right?) was talking about wage payroll people, so yes, this applies. I don't know what kind of insane point you are trying to make here with the "not paying them for the time they put in" nonsense but every wage job I have ever had involved signing in and out so they knew how much to pay you. If you were scheduled for 8 hours and you show up a half hour late? guess what you don't get paid for that half hour (the horror!). On the same token, if you were asked to stay later and agreed, you got paid for the hours you put it over what you were scheduled for. This is the same concept that has been used since the stone age when quarry workers used sheet-rock for time cards and had them punched by sarcastic birds. Our technology has come a long way since the Flintstones era, but the way hourly wages work is still the same.
Finkployd
Fair enough. The Napster deploy was going to happen regardless how the registration was handled. I like to think of my only contribution as at least preventing a situation where we give a corporate entity a ton of personal information (which really is the only other alternative, restricting by IP address is not feasible).
At the end of the day, like anyone else I'm going to do what my employer wants me to do (within reason, if PSU ever initiates a plan to break the legs of small puppies, you can bet I'll be leaving).
And there are plenty of people who do NOT consider DRM to be evil, it is not like that is a universal opinion. I would assume the vast majority of consumers do not even care, until DRM bites them. For most people that is pretty rare. Furthermore, as long as the technology exists, people will use it. DRM technology is generally nothing more than x.509 PKI stuff, which like portscanners can be good or evil. It is up to the market and the governments to decide if DRM is acceptable or not. The jury is still pretty much out on that in general.
Finkployd
The funny thing is, you are one of the only posters here whoom I recognize by handle, and whose posts I used to respect...
:)
:) )
Oh now that just hurts
I'm not saying I don't have my opinions on the politics of this, the DRM, and the "right or wrong" arguments, just that I wanted to post something informative amidst all the debate without getting dragged down into that.
And besides, as an employee of PSU (who's bosses know I post here as "finkployd") I probably shouldn't go off on a "DRM is evil" rant when we are using it. (despite the fact that DRM is, in fact, evil
Finkployd
One piece of this that is not getting much attention right now (that would probably be of interest to /. readers) is the registration system. I'm not getting into the politics of this, the DRM or the "right or wrong" arguments.
In this initial rollout PSU and Napster decided to limit the service to students living in the residence halls. It does not matter which of the 21 campuses you are on, just that you live in a res hall.
We also needed to ACTIVELY protect the privacy of the students, not just to comply with FERPA but because we are not in the business of providing marketing data to private institutions.
The way we went about this was to use the Internet2 Middleware Initiative's Shibboleth software. Similar to Liberty in that it is a federated single sign on system that uses SAML, it is one of the unsung heros in this.
Without getting into TOO much low level detail of how Shib works (which is available at the above link for those interested), here is a quick overview of what we are doing:
Basically PSU students are redirected to Napster's shibboleth protected registration webpage (this shib component is an Apache auth module) which sends them back to a PSU server to do the actual authentication. The student authenticates to the web server (kerberos backended userid and password). This server is also a component of Shib and it redirects the user (actually an http post) back to the Napster reg system along with a SAML authentication assertion.
The SAML authentication assertion is a blob of XML data that contains an opaque handle for the user (used in the next step) and a URI back to the last piece of Shibboleth at PSU called the Attribute Authority. This assertion is also digitally signed with an x.509 cert (w3c's XML-Signature spec) so that Napster knows it can trust this (not tampered with, generated from a rogue "man in the middle" server, etc).
The last step is when Napster makes an SSL wrapped call to the Attribute Authority requesting attributes about the student who is trying to get in. Remember up to this point all they know is his opaque handle (long string of numbers which uniquely identifies the user, but provides no information). The Attribute Authority looks as the cert of the requesting server, sees that it is Napster and queries LDAP for the data about the user that it is allowed to release. This is configurable to be anything we have, name, email, address, department, semester standing, etc. HOWEVER we only pass TWO things to Napster. (1) an entitlement string that identifies whether or not that user is allowed to get this service, and (2) a persistent opaque handle, which is basically the userID encrypted with the name of the target site and a secret seed value.
The entitlement string is generated at PSU and is populated in the user's LDAP entry based on the criteria that was set (res hall students only for now) and the persistent opaque handle gives Napster something to look at to make sure each students only registers once, but they still have no idea who that user is or anything about them other than that they are a student at PSU in a res hall.
Now if the student chooses to use their PSU email address when creating their Napster account, or gives them their CC number because they want to purchase songs that is their decision. The doubleplus good factor here is that PSU does not give that data up. We merely assert on the user's behalf that they are allowed to sign up under this agreement.
This Shibboleth stuff is running on Linux at both places and with the exception of requiring Java at the Origin end (PSU), is entirely comprised of open source software. The Napster guys we worked with were also very clueful and were definitely down with Linux, using it except where Windows was necessary (WMA streaming)
So I are very pleased at what
This "trial rollout" is only available to students who live in the residence halls (for now). That brings the total population who can use this service down to around 15k
Finkployd
If you couldn't file a lawsuit until you had an airtight case against the defendant, not many lawsuits would be filed.
And boy, wouldn't THAT be terrible.
Finkployd
AAC is an open standard. Protected AAC is AAC with DRM added which is an Apple owned format and has not been licensed to anyone else.
Finkployd
My main case is PKI. Java crypto functions run painfully slow. And when you scale that up it really starts to suck.
Generally we use Power chips or Sparc64, so processor issues are not really a problem.
There are plenty of reasons to complain about Java, but general performance isn't really one of them, especially with people having 3Ghz processors when a 500Mhz would run every app they have just fine.
Very true, and I am all for Java applets, I think that is a really cool use of the technology to serve a need. Now servlets are a totally different story.... Suddenly that 3Ghz is not nearly enough to support a servlet that needs to scale to a large population and do things that Java is horrible at (like crypto).
Finkployd
Not true, WMA9 (the DRM'd wma format which your legal online music stores besides ITMS use) is only playable on a handful of brand new devices.
Finkployd
I don't think AAC belongs to Apple. My understanding is that it is an "open" DRM music file specification. Or at least one that they do not control.
Finkployd
Well, anyone writing servers as opposed to applications....
I've never not been on a project where speed and performance were so important that C ended up being used (despite its shortcomings as compared to higher level languages). Granted I tend to do primarily security stuff for a large university, which is not really that common. But everyone's particular needs vary, and no language is ideal for everything.
Finkployd
I like java for some things, and the performance has even improved a bit lately. However if I am doing ANYTHING that has to scale and perform well under heavy load that uses cryptographic functions (especially public key encipherment), there is no way I can even seriously consider Java.
Someone (meaning anyone other than me) should do a benchmark of THAT, I'm sure it would be quite telling.
Finkployd
Not always though, I think the thing people neglect to consider is that there are times when performance and scale are important enough that the benefits of Java do NOT outweigh C, and vice versa.
I feel sad for someone who only has enough room in their world for one computer language.
Finkployd
Well, for performance it does. For cross platform compilation it rocks the house. If you really want performance you need to be using something like Intel's C compiler (which oddly was not tested)
Finkployd
A new epoch is about to begin.
:)
Bring it on. This current epoch is getting old.
Finkployd
I don't know, I tend to flip back and forth between Fox and CNN and while Fox certainly does throw a conservative slant into their reporting (moreso with their "talk shows" than with the actual news reporting), they do tend to be very accurate with the facts. And they generally seem to beat CNN to a lot of stories to boot.
Finkployd
Yeah, I just had to use one to get money out to buy some tasty TCBY yogurt.
:)
Oh well, back to work. I'm working on a PKI infrastructure these days
Finkployd
That's a bit of an odd requirement, but a fair enough one I suppose.
:( I make about half that and I maintain that I am a decent developer. :)
Cross institution, higher education application.
Bouncy Castle is only one example of free crypto libs. I've personally been more impressed by its ability to do just about anything vs. performance.
BouncyCastle does what we need it to do, but is still orders of magnitude slower than openssl or even NSS (which thankfully does have a JCE interface but unfortunatly does not do java keystores)
Probably your best bet for an Open Source J2EE server would be JBoss.
That, and NSS are probably the directions we are going in. what we are talking about here is not a j2ee application, but just a simple servlet to do federated authentication/authorization with SAML. Either way though, I've heard a lot of good about JBoss.
One other thing you need to consider in an enterprise environment that many developers miss: If you're spending time hand optimizing code or troubleshooting server wide crashes caused by memory leaks or illegal memory access, you're wasting your employer's money.
Not to launch into "marketing brag mode here", but my university has become exceedingly good at developing in house solutions in C and avoiding these problems. When none of the existing webmail packages would scale well enough for our environment, we wrote out own. Same thing with our portal framework. It always amuses us when companies try to sell us solutions without understanding how large we actually are. Microsoft wanted us to use Exchange for our email system, until we pointed out our size (100,000 users, generally 3-4 million emails a day). We do that with 6 nodes in a few SP clusters (AIX and Sendmail), while Microsoft used some 100 servers for a population 1/4 of our size. Our experience has long been that we can develop better in house solutions (generally using C) than we can buy for most infrastructure applications.
A decent developer costs between $85-$130K per year.
Not in higher ed
However the benefits are nice: 24 vacation days a year, 75% tuition discount, freedom to play with some really cool tech, and job security, baby
Finkployd
While those are good points, one of the requirements for the software in question is that it is open source, and needs to involve only open source or at least free (like java) technologies. So I guess maybe my problem with java is that there are no decent free or open servlet containers, crypto libs, etc that can scale well and perform under a heavy load. Hence our preference for C.
I'm not trying to cut down Java, I have spent a long time working with it and I like it. But working in a huge enterprise setting was a big eye opener for me.
Finkployd
In one case, it was digitally signing signing XML. Java absolutly sucks as anything involving cryptography in my experience. One of the developers was able to get a decent speed boost using Mozilla's NSS library instead.
Another problem is servlet containers (like Tomcat). Frankly they just suck under any kind of heavy load.
Once you start talking about striping out the pieces that perform poorly in Java, it just makes more sense (in our situation anyway) to just write the whole thing in in C or another compiled language.
Finkployd
Odd. I wouldn't have thought you'd need to do that these days anyway.
If you think java scales and performs well, then you do not deal with the scale and performance requirements that I do. Congratulations. I understand I am really in the minority, but just because something works for someone, doesn't mean it works for everyone.
Finkployd
In the large enterprise setting where I work (100000 or so very active users) we have pretty much ruled out java for anything production that needs high availability. Java is nice for applets or client applications, but for server side stuff it just makes no sense at all for us (unless we decide we want to throw TONS of hardware at it).
Java is simply is not as fast as a compiled language (specifically C, which the majority of our stuff is done in). More importantly than that though, it does not scale nearly as well.
Finkployd
I value cellphones (hell, I carry two), but I also understand that I do not have to have it with me (or at least powered on) at all times. It is not an all or nothing approach. You are never going to convince me that people need cellphones turned on in movie theaters. Yes I know they can be silenced (mine is always on vibrate mode, I don't even know what my ring tone is) but 90% of the population seems to be unable to do that.
Do you need total privacy at all times? I don't care if the 911 people can track me while I am at the grocery store. I don't care if they can track me while I'm sitting at work. However maybe I'm visiting an AIDS clinic and do not want ANYONE know be able to find out I am there, so I leave the cell phone at home. Or I just turn it off while I am there.
Look, there is clearly some benefit to having trackable cellphones, it is not a horrible evil, 1984ish idea with no positive side effects. The article mentions that it can be turned off for everyone except 911 through the menu interface (should this be the default setting? I don't know I suppose that is a manufacturing issue).
My only reason for the arguably negative tone was there seemed to be a flood of people equating this to some tracking chip implanted in their skin, and enforced by law. Carrying a powered on cell phone is still a voluntary act. It is not like there is no option to ever escape the tracking.
Finkployd
Same here, but I would contend that AIX really shines in huge enterprise settings, which most people have never come in contact with and do not really see the benefits of it.
Finkployd