Re:Web services ARE client/server
on
Shirky On P2P
·
· Score: 1
Any transaction can be thought of as "client/server". The difference here is that client and server are changing roles as needed.
Your letter, if we talk about email, provides a good example. Take a look at the headers of your next message. It has been handled by a series of cooperating hosts completely unknown to you. The route your letter takes can change according to various circumstances. You may always hand your mail off to the same host initially, but where it goes after that is not up to you. The network decides the "cheapest" route and gets it to the receiver without any input from your end.
In that way, peer to peer is not really new or even that exciting-- the underlying internet protocols have used similar concepts to provide reliable end to end communication through an ill-defined swarm of hosts for a long time.
We can always reach the host we want, but not always through the same path. Likewise, once we have standardized some interfaces, we may always be able to retrieve the data we want, but not necessarily always from the same host. We're just moving an old, good idea further up the protocol stack.
So what happens when we want to store something that no one cares about except us? It's one thing to have multiple independent sources of something everyone wants, but how many machines are interested in warehousing some guy's letter to his girlfriend? (Not a good letter-- a mushy boring letter.)
I think a grace period makes sense, perhaps even one with a sliding release date, (i.e. we won't release the information as long as we are convinced you are dedicating appropriate resources to a fix), but in the end (once the patch is out) there has to be full disclosure, right down to example exploits.
Full disclosure drags mistakes out into the light where the entire programming community can have the benefit of learning from them. Otherwise, each vendor has to independently learn these hard lessons.
If examples of buffer overflows or other more subtle code weaknesses are documented and explained in a public forum, then companies can benefit by being able to hire programmers who have learned from these cases without having to be bitten by them.
I understand companies like/need to hoard their intellectual capital, but in today's always-connected environment some things should be too important to keep to yourself.
The thing that comes to mind for me (other than not wanting to reinvent the wheel, which you have already pointed out) is that employing a generic framework like this will help us avoid namespace pollution and various one-off client/server packages that conflict with each other when released in the wild. If the main goal is to make sure that all these things can play well together without misinterpreting each other's messages, then you would want the infrastructure to be as light and vague as possible while still meeting these requirements so that it doesn't get in the way of anyone's plans for it (thereby forcing them to come up with their own protocol).
It looks like some effort has been made to do just that, even going so far as to risk not quite specifying enough for fear of specifying too much. I don't claim to know whether the specification will be viable in the long term, but I am hopeful. It could evaporate or explode, the community will determine its fate.
Although the article says "This isn't just Jini without the close java ties" it would be exciting to me even if it were.
Who exactly does "own" this technology? Is this something they can take back from the community once it builds momentum?
Nice neat compression algorithm. Lossless. People liked it. Poularity hit critical mass. Lawsuit was filed. Now you can't create a GIF unless you license the tech. Think about that next time you imagine MP3 sounds all that much better. Do you really want ogg to be at PNG-status when the lawsuit is filed? Let's hope not.
Hope this isn't redundant, as I haven't followed this issue that closely. Then again, it seems like it doesn't sink in until repetition 367 or so around here some times.
The sad truth is, I've noticed that a lot of MCSE's are not all that familiar with Win32 systems, much less with other alternatives.
It seems like getting an MCSE cert has been a springboard for a lot of people with less than a year or two of experience as a computer user (much less as a system administrator) to get one of those snazzy "IT Jobs". When I read some of the course material, I was surprised at some of what I saw. A lot of it seemed like marketing spin wrapped around some "Click here to add a user" stuff. It was disturbing enough to me that I elected to forego testing in this area. I'm sure it never hurts to add another certification, but I can't see paying to support superficial training in lieu of documentation. I hope (and believe) that employers will deemphasize the importance of these certs in favor of the right combination of aptitude and experience. If that leaves me unemployed, so be it-- I'll go back to bartending.
But this doesn't mean the MCSE's you kow and work with can't become valuable. The beauty of Linux for me has always been that the docs are out there and none of the implementation details are hidden to either a. protect me from myself or b. protect profit margins.
Unix (and Linux) has the advantage of following a design philosophy for appications and documentation that is fairly consistent. Once you acquire a certain "critical mass" of knowledge, it becomes much easier to build on that foundation.
Set up a box in a corner, give all your MCSE's accounts, sit them down and point them at the docs and HOWTO's, and then look in on them in a week or two. Once some time goes by it should be easy to separate the learners from the "you-build-it-i'll-click-it" types. Of course, I wouldn't expect the answers to surprise you-- the ones who have endeavored to dig a little deeper with the Win32 configurations will be pleased with how much there is to explore in a unix environment, and if you are working with them you probably already know who they are.
I got involved with the 1.2 series kernels and have never looked back. The ratio of things that make sense to things that don't make sense is the inverse of what I deal with supporting our Win32 systems. It seems like these days I spend a lot of time grumbling over corrupt DLL's and mangled registries. These kinds of problems don't have analogs in the unix world-- yet. Hopefully things won't devolve to that point. I would love to see the benefits of unix trickle down to smaller companies like the one I work for. We (plural form used for responsibility diffusion, one person "IT Department") have migrated most services to Linux, and one day I hope the desktop will be ready. If someone would bring AutoDesk around, that would be the go-ahead for us here.
You can bet that this will happen. Unfortunately, We already have a strong negative precedent for privacy rights in the workplace. (Other sysadmins feel free to chime in here.)
Given how much time we spend at work, going to work, coming from work, recovering from work, and getting ready for work, our rights in the workplace should contrast more favorably with our Constitutionally guaranteed rights.
We need to push the issue before the monitoring techniques become *too* efficient. It's already scary enough, depending on what kind of management culture is installed in your office.
Of course, the "make work more fun and relaxing" lobby doesn't have the resources of the ruling class behind it.
After reading people extoll the virtues of Direct X as an API and bemoan the limitations of OpenGL, and given the fact that none of the cross-platform direct hardware access API's seem to have gathered much support yet, would it make sense to attempt implementing an open source Direct X compatible API to make it easier for game writers to port their code?
I am not familiar enough with Direct X to say whether it suffers from the same tight Win32 integration (read dependence) that other Microsoft API's do.
Would it even be legal to attempt this? You might even have better luck getting manufacturers to release specs if you could leverage some of the Direct X name recognition.
Someone could even come up with one of those snazzy recursive acronyms for the project.
Please be merciful if something like this is already in the works and I failed to see it in my cursory Google scan. In return I promise to go drink some caffeine to fight the after-lunch dull wittedness.
To continue with the popular "burger and fries" comparison, this is analogous to when Coke pays Burger King to be their "exclusive" drink choice and Pepsi pays Taco Bell to do the same. So what Microsoft is telling these folks is "You can't make exclusive advertising arrangements with ISP's if you buy our operating system."
This is the same kind of anti-competitive stuff Microsoft has always done. These tactics got them where they are, and they are never going to stop without intervention.
The question for me is, how much right do the computer manufacturers have to make changes to the "operating system" and still call it "Microsoft Windows". Can they delete IE and install some other browser? What if they have a TCP/IP stack or print spooler they feel performs better or is more reliable? Where is the line between operating system compnents and non-critical add-ons to be drawn?
It seems clear that MSN is in no way essential for the operating system, but can we count on the judges, juries, et al to understand the difference when Bill's legal types stand in front of them and cry foul? It seems like we aren't having much luck explaining technical things to the non-techical people who legislate and litigate. Maybe/. should sponsor "abduct and indoctrinate" weekends in isolated mountain cabins with Linux boxen?
I keep seeing people point out that this is no different from having a police officer standing on the corner comparing faces to a mug shot.
Well, it is different, in a very significant way: This technology enables them to (eventually) have a police officer on every corner of every street. This police officer is never going to exercise his/her personal judgement and decide to "let one slide". Picture that scenario in your mind the next time you go for a walk. If that doesn't bother you, then you are already gone. You're not the droid they are looking for.
Slashdot Mirror
Any transaction can be thought of as "client/server". The difference here is that client and server are changing roles as needed.
Your letter, if we talk about email, provides a good example. Take a look at the headers of your next message. It has been handled by a series of cooperating hosts completely unknown to you. The route your letter takes can change according to various circumstances. You may always hand your mail off to the same host initially, but where it goes after that is not up to you. The network decides the "cheapest" route and gets it to the receiver without any input from your end.
In that way, peer to peer is not really new or even that exciting-- the underlying internet protocols have used similar concepts to provide reliable end to end communication through an ill-defined swarm of hosts for a long time.
We can always reach the host we want, but not always through the same path. Likewise, once we have standardized some interfaces, we may always be able to retrieve the data we want, but not necessarily always from the same host. We're just moving an old, good idea further up the protocol stack.
So what happens when we want to store something that no one cares about except us? It's one thing to have multiple independent sources of something everyone wants, but how many machines are interested in warehousing some guy's letter to his girlfriend? (Not a good letter-- a mushy boring letter.)
I think a grace period makes sense, perhaps even one with a sliding release date, (i.e. we won't release the information as long as we are convinced you are dedicating appropriate resources to a fix), but in the end (once the patch is out) there has to be full disclosure, right down to example exploits.
Full disclosure drags mistakes out into the light where the entire programming community can have the benefit of learning from them. Otherwise, each vendor has to independently learn these hard lessons.
If examples of buffer overflows or other more subtle code weaknesses are documented and explained in a public forum, then companies can benefit by being able to hire programmers who have learned from these cases without having to be bitten by them.
I understand companies like/need to hoard their intellectual capital, but in today's always-connected environment some things should be too important to keep to yourself.
The thing that comes to mind for me (other than not wanting to reinvent the wheel, which you have already pointed out) is that employing a generic framework like this will help us avoid namespace pollution and various one-off client/server packages that conflict with each other when released in the wild. If the main goal is to make sure that all these things can play well together without misinterpreting each other's messages, then you would want the infrastructure to be as light and vague as possible while still meeting these requirements so that it doesn't get in the way of anyone's plans for it (thereby forcing them to come up with their own protocol).
It looks like some effort has been made to do just that, even going so far as to risk not quite specifying enough for fear of specifying too much. I don't claim to know whether the specification will be viable in the long term, but I am hopeful. It could evaporate or explode, the community will determine its fate.
Although the article says "This isn't just Jini without the close java ties" it would be exciting to me even if it were.
Who exactly does "own" this technology? Is this something they can take back from the community once it builds momentum?
UniSys, GIF, Patent
Nice neat compression algorithm. Lossless. People liked it. Poularity hit critical mass. Lawsuit was filed. Now you can't create a GIF unless you license the tech. Think about that next time you imagine MP3 sounds all that much better. Do you really want ogg to be at PNG-status when the lawsuit is filed? Let's hope not.
Hope this isn't redundant, as I haven't followed this issue that closely. Then again, it seems like it doesn't sink in until repetition 367 or so around here some times.
The sad truth is, I've noticed that a lot of MCSE's are not all that familiar with Win32 systems, much less with other alternatives.
It seems like getting an MCSE cert has been a springboard for a lot of people with less than a year or two of experience as a computer user (much less as a system administrator) to get one of those snazzy "IT Jobs". When I read some of the course material, I was surprised at some of what I saw. A lot of it seemed like marketing spin wrapped around some "Click here to add a user" stuff. It was disturbing enough to me that I elected to forego testing in this area. I'm sure it never hurts to add another certification, but I can't see paying to support superficial training in lieu of documentation. I hope (and believe) that employers will deemphasize the importance of these certs in favor of the right combination of aptitude and experience. If that leaves me unemployed, so be it-- I'll go back to bartending.
But this doesn't mean the MCSE's you kow and work with can't become valuable. The beauty of Linux for me has always been that the docs are out there and none of the implementation details are hidden to either a. protect me from myself or b. protect profit margins.
Unix (and Linux) has the advantage of following a design philosophy for appications and documentation that is fairly consistent. Once you acquire a certain "critical mass" of knowledge, it becomes much easier to build on that foundation.
Set up a box in a corner, give all your MCSE's accounts, sit them down and point them at the docs and HOWTO's, and then look in on them in a week or two. Once some time goes by it should be easy to separate the learners from the "you-build-it-i'll-click-it" types. Of course, I wouldn't expect the answers to surprise you-- the ones who have endeavored to dig a little deeper with the Win32 configurations will be pleased with how much there is to explore in a unix environment, and if you are working with them you probably already know who they are.
I got involved with the 1.2 series kernels and have never looked back. The ratio of things that make sense to things that don't make sense is the inverse of what I deal with supporting our Win32 systems. It seems like these days I spend a lot of time grumbling over corrupt DLL's and mangled registries. These kinds of problems don't have analogs in the unix world-- yet. Hopefully things won't devolve to that point. I would love to see the benefits of unix trickle down to smaller companies like the one I work for. We (plural form used for responsibility diffusion, one person "IT Department") have migrated most services to Linux, and one day I hope the desktop will be ready. If someone would bring AutoDesk around, that would be the go-ahead for us here.
You can bet that this will happen. Unfortunately, We already have a strong negative precedent for privacy rights in the workplace. (Other sysadmins feel free to chime in here.)
Given how much time we spend at work, going to work, coming from work, recovering from work, and getting ready for work, our rights in the workplace should contrast more favorably with our Constitutionally guaranteed rights.
We need to push the issue before the monitoring techniques become *too* efficient. It's already scary enough, depending on what kind of management culture is installed in your office.
Of course, the "make work more fun and relaxing" lobby doesn't have the resources of the ruling class behind it.
After reading people extoll the virtues of Direct X as an API and bemoan the limitations of OpenGL, and given the fact that none of the cross-platform direct hardware access API's seem to have gathered much support yet, would it make sense to attempt implementing an open source Direct X compatible API to make it easier for game writers to port their code?
I am not familiar enough with Direct X to say whether it suffers from the same tight Win32 integration (read dependence) that other Microsoft API's do.
Would it even be legal to attempt this? You might even have better luck getting manufacturers to release specs if you could leverage some of the Direct X name recognition.
Someone could even come up with one of those snazzy recursive acronyms for the project.
Please be merciful if something like this is already in the works and I failed to see it in my cursory Google scan. In return I promise to go drink some caffeine to fight the after-lunch dull wittedness.
To continue with the popular "burger and fries" comparison, this is analogous to when Coke pays Burger King to be their "exclusive" drink choice and Pepsi pays Taco Bell to do the same. So what Microsoft is telling these folks is "You can't make exclusive advertising arrangements with ISP's if you buy our operating system."
/. should sponsor "abduct and indoctrinate" weekends in isolated mountain cabins with Linux boxen?
This is the same kind of anti-competitive stuff Microsoft has always done. These tactics got them where they are, and they are never going to stop without intervention.
The question for me is, how much right do the computer manufacturers have to make changes to the "operating system" and still call it "Microsoft Windows". Can they delete IE and install some other browser? What if they have a TCP/IP stack or print spooler they feel performs better or is more reliable? Where is the line between operating system compnents and non-critical add-ons to be drawn?
It seems clear that MSN is in no way essential for the operating system, but can we count on the judges, juries, et al to understand the difference when Bill's legal types stand in front of them and cry foul? It seems like we aren't having much luck explaining technical things to the non-techical people who legislate and litigate. Maybe
I keep seeing people point out that this is no different from having a police officer standing on the corner comparing faces to a mug shot. Well, it is different, in a very significant way: This technology enables them to (eventually) have a police officer on every corner of every street. This police officer is never going to exercise his/her personal judgement and decide to "let one slide". Picture that scenario in your mind the next time you go for a walk. If that doesn't bother you, then you are already gone. You're not the droid they are looking for.