Evidently Corey Brook isn't a parent. Let me ask you this Corey, would you prefer that my babysitter call me on my silenced cell phone, or have the management use the PA system to get my attention when the kid throws up all over the place?
Of course that's what you see. That's what the US media wants you to see. If you talk to returning soldiers, they'll tell you a completely different story.
And we wonder why the rest of the world is starting to eat our lunch economically. We're quickly becoming the world idiot. This is *exactly* why I send my kids to private school.
I've been saying this for a couple of years now. I was one of the very early Linux adopters and loved it because it was lots cheaper than the Unix machines out there (I worked on Digital UNIX on the Alpha). Suddenly, I could have Unix at home!
Now, I write embedded code for a living, mostly on small devices like set-top boxes and mobile phones and the like. I do it all on the Mac. The toolchains that I use are all portable, and build nicely on the mac, so I can choose between Mac and Linux freely.
I choose the mac. Why? Because I need to get the work done, not fiddle with the OS. I don't have time to try to bang out a new xorg.conf to support that second monitor. On the mac, you plug it in, and poof, up it comes. Don't even need a reboot. I don't have time to find out why when I close the laptop, everything goes to hell in a handbasket. I don't want to spend a lot of time trying to get wireless working. I don't want to deal with the details needed to get a VPN working.
Sure, Linux is great, I code for it all the time. But when my personal productivity drops by using it, the love affair ends. I'm in the real world competing with other engineers, I don't have time to fix my tools.
The saddest part of this whole thing for me was that they filmed most of it in what was once SGI's fancy new campus at 1600 Amphitheater in Mountain View (where I used to work in the good old days), and which is now the home to Google.
They talk about the beautiful campus and cafeteria, etc., and to think that SGI used to be there makes me pretty sad. Those were the days....
There really is a philosophy to Unix and Linux, and you'll find that when the same philosophy's applied to things other than OS design, it results in some interesting and elegant ideas.
This book describes the philosophies embodied in Unix (and largely copied and expanded upon by Linux) very well, and in such a way as to not be religious about it. However, it may give "non-believers" some understanding of how Unix and Linux folks think, and therefore a better sense of why the OSs are the way they are, and hopefully, a respect for them.
So philosophy, ya, I think so. When applied to OS design, perhaps you can call them design principles, but I think that this book is able to abstract it better than that.
What Linus says only has a limited value at this
point. As soon as Linus used the GPL for his
kernel, he effectively gave up his rights to
interpret the license. Any trust-fund kid with
nothing better to do could go to court to argue
to open up anyone's closed source driver.
True, they couldn't get Linus to go along with
such a pursuit, but it would be left to the
court.
How much weight the court gives to the
intent of the original author is anyone's guess.
It'd be further complicated because there are many, many kernel devos whose contributions are
covered by that license. Does Linus speak for
all of them too? Again, that'd be the court's
decision.
It's a hairball. But I agree, if Linus says
so, it's OK. A court case to the contrary would
be hard to win.
UUIDs can be produced any way you want, as long as they're "guaranteed" to be unique. A lot of folks use the MAC address since they're supposedly unique, but then munge them in some way, such as munging them with the date the board was made, or something like that. But what if you don't have a MAC address?;-)
One of the design goals was for all this to work on an unmanaged network. If you rely on DNS, that sort of breaks one of the design goals, doesn't it?
From my view, it seems to be a pretty solid protocol. That's not to say that there aren't better ways to do things, but it's been a finished protocol for two years now, which is a lot further than it would have gotten had it been an academic exercise to keep up with the perfect-way-to-do-it-today.
For any problem, you'll always find a better solution of you look long enough!;-)
Jini's probably the #1 competitor to UPnP, but unfortunately, it's Java only, so it's hardly competition. If you don't do Java, you don't do Jini. This precludes it from the really low end (read: cheap) devices like lamps.
UPnP can be made really, really small and go on super cheap devices. Jini's architecture is cool, but it's got the darned Java albatross to carry around with it. Were it not for that, it may have had a chance.
We considered making Jini products, but gosh, it just didn't seem to scale down well enough.
By the way, don't use Intel's protocol stack as an example of how small UPnP can be. Size wasn't their primary concern, and it's as much as 10x as big as other stacks.
My company (Metro Link, Inc., www.metrolink.com) is a member of the UPnP forum, develops UPnP technology for Linux and other OSs that typically end in 'x', and was recently elected to the UPnP steering committee. You may remember us for our commercial X servers, Motif, OpenGL, etc. Most people who know us will tell you that we're pretty openminded, and contribute a lot to the open source universe (remember us when you X server magically loads up its modules instead of having to be compiled in). I'll try to lend some insight to help balance out religious arguments.
First, let me address UPnP and Microsoft. Yes, UPnP was originally conceived by MS, and MS has written themselves onto the steering committee forever. However, the UPnP membership agreement precludes any member from owning the technology outright, and says that anyone who offers technology to the forum must do so without encumberance. Even Microsoft. UPnP is NOT
proprietary to MS.
Second, the technology. Everything in UPnP can be had for free. We've developed (and are successfully selling) two UPnP protocol stacks, one in ANSI C and one in Java. This was all home-grown, and we didn't need to license anything from anyone except the UPnP forum.
As mentioned before to use the technology, you need to be a UPnP Forum member. Membership is free, and the only real restriction is that anything you suggest for inclusion be done so without encumberance. Anyone can join. If you join, and don't want to donate technology, then don't bring it up. It's as easy as that.
The underlying standards are either pre-existing standards or build by the UPnP Forum. A case in point is Auto-IP, which does the ad-hoc network configuration. It's based on an IETF draft (draft-ietf-ipv4-autoconfig-05), which was originally authored by someone at Apple. I wouldn't be too surprised if it's very similar to Auto-IP. It's too bad that Apple didn't get involved earlier, we'd only have one uniform way to do this, instead of two Again, this isn't a MS invention.
There are a lot of UPnP implementations available. Intel did indeed provide a GPL protocol stack that you can download from their site. It builds on Linux nicely, and give you sample apps, etc. We have our two stacks that will begin appearing in cheap applicances Real Soon Now (tm) thanks to our silicon-builder-friends.
Alternatives to UPnP? Not really, at least not in one place. Many folks who responded to this message address only the Auto-IP part, where the box gets its IP address (FYI, Auto-IP on a net with DHCP is pretty much just DHCP). What they're missing is the juice of UPnP, where there's a protocol for device discovery and control. All the control and discovery is without any a-priori knowlege or configuration! (N.b., UPnP and Plug&Play are entirely different beasts: UPnP is on a network, Plug&Play and Kudzu are a single box)
E.g., your UPnP PVR is on a net with your UPnP phone (they're both coming). They know about each other, thanks to UPnP. Phone rings, PVR pauses automatically and puts up caller ID. You pick up the phone, talk, hang up, PVR starts again. Your washing machine tells you it's time to switch the load over, not only on the TV, but on your UPnP Zaurus or iPaq (reality today), or perhaps your electronic picture frame. You want to listen to your MP3 library from your home server. Easy. Your iPaq, Zaurus, stereo receiver, anything, knows in advance how to search for media sources, get a list of titles available, and start spooling it down. Click and go.
Our demos are much, much cooler than that even, but I don't know how much I can say.
To answer your question, sure there are alternatives, but they're in many disjoint parts. I'd suggest getting Intel's kit, and playing with it, seeing what you can do with it. Whether you do that, or play with disjoint parts, you'll be experimenting, but UPnP will take off fairly soon now.
Slashdot Mirror
Evidently Corey Brook isn't a parent. Let me ask you this Corey, would you prefer that my babysitter call me on my silenced cell phone, or have the management use the PA system to get my attention when the kid throws up all over the place?
Of course that's what you see. That's what the US media wants you to see. If you talk to returning soldiers, they'll tell you a completely different story.
And we wonder why the rest of the world is starting to eat our lunch economically. We're quickly becoming the world idiot. This is *exactly* why I send my kids to private school.
You can be sued for anything. The question is whether or not you can afford to try to prevail.
Probably one of these:
http://www.picotux.com./ Good luck to them. :-)
I've been saying this for a couple of years now. I was one of the very early Linux adopters and loved it because it was lots cheaper than the Unix machines out there (I worked on Digital UNIX on the Alpha). Suddenly, I could have Unix at home!
Now, I write embedded code for a living, mostly on small devices like set-top boxes and mobile phones and the like. I do it all on the Mac. The toolchains that I use are all portable, and build nicely on the mac, so I can choose between Mac and Linux freely.
I choose the mac. Why? Because I need to get the work done, not fiddle with the OS. I don't have time to try to bang out a new xorg.conf to support that second monitor. On the mac, you plug it in, and poof, up it comes. Don't even need a reboot. I don't have time to find out why when I close the laptop, everything goes to hell in a handbasket. I don't want to spend a lot of time trying to get wireless working. I don't want to deal with the details needed to get a VPN working.
Sure, Linux is great, I code for it all the time. But when my personal productivity drops by using it, the love affair ends. I'm in the real world competing with other engineers, I don't have time to fix my tools.
They talk about the beautiful campus and cafeteria, etc., and to think that SGI used to be there makes me pretty sad. Those were the days....
Here's how *real* race car steering wheels are supposed to work:
http://www.speedracer.com/cars-mach5.htm
The next version of will be faster/more reliable/more efficient/more secure.
Ahh, then, you really should read the book.
There really is a philosophy to Unix and Linux,
and you'll find that when the same philosophy's
applied to things other than OS design, it
results in some interesting and elegant ideas.
This book describes the philosophies embodied in
Unix (and largely copied and expanded upon by
Linux) very well, and in such a way as to not
be religious about it. However, it may give
"non-believers" some understanding of how
Unix and Linux folks think, and therefore a
better sense of why the OSs are the way they are,
and hopefully, a respect for them.
So philosophy, ya, I think so. When applied to
OS design, perhaps you can call them design
principles, but I think that this book is able
to abstract it better than that.
True, they couldn't get Linus to go along with such a pursuit, but it would be left to the court.
How much weight the court gives to the intent of the original author is anyone's guess. It'd be further complicated because there are many, many kernel devos whose contributions are covered by that license. Does Linus speak for all of them too? Again, that'd be the court's decision.
It's a hairball. But I agree, if Linus says so, it's OK. A court case to the contrary would be hard to win.
UUIDs can be produced any way you want, as long ;-)
as they're "guaranteed" to be unique. A lot of
folks use the MAC address since they're supposedly
unique, but then munge them in some way, such as
munging them with the date the board was made,
or something like that. But what if you don't
have a MAC address?
One of the design goals was for all this to work
;-)
on an unmanaged network. If you rely on DNS, that
sort of breaks one of the design goals, doesn't it?
From my view, it seems to be a pretty solid
protocol. That's not to say that there aren't
better ways to do things, but it's been a finished
protocol for two years now, which is a lot further
than it would have gotten had it been an academic
exercise to keep up with the perfect-way-to-do-it-today.
For any problem, you'll always find a better solution of you look long enough!
Jini's probably the #1 competitor to UPnP, but unfortunately, it's Java only, so it's hardly competition. If you don't do Java, you don't do Jini. This precludes it from the really low end (read: cheap) devices like lamps.
UPnP can be made really, really small and go on super cheap devices. Jini's architecture is cool, but it's got the darned Java albatross to carry around with it. Were it not for that, it may have had a chance.
We considered making Jini products, but gosh, it just didn't seem to scale down well enough.
By the way, don't use Intel's protocol stack as an example of how small UPnP can be. Size wasn't their primary concern, and it's as much as 10x as big as other stacks.
First, let me address UPnP and Microsoft. Yes, UPnP was originally conceived by MS, and MS has written themselves onto the steering committee forever. However, the UPnP membership agreement precludes any member from owning the technology outright, and says that anyone who offers technology to the forum must do so without encumberance. Even Microsoft. UPnP is NOT proprietary to MS.
Second, the technology. Everything in UPnP can be had for free. We've developed (and are successfully selling) two UPnP protocol stacks, one in ANSI C and one in Java. This was all home-grown, and we didn't need to license anything from anyone except the UPnP forum.
As mentioned before to use the technology, you need to be a UPnP Forum member. Membership is free, and the only real restriction is that anything you suggest for inclusion be done so without encumberance. Anyone can join. If you join, and don't want to donate technology, then don't bring it up. It's as easy as that.
The underlying standards are either pre-existing standards or build by the UPnP Forum. A case in point is Auto-IP, which does the ad-hoc network configuration. It's based on an IETF draft (draft-ietf-ipv4-autoconfig-05), which was originally authored by someone at Apple. I wouldn't be too surprised if it's very similar to Auto-IP. It's too bad that Apple didn't get involved earlier, we'd only have one uniform way to do this, instead of two Again, this isn't a MS invention.
There are a lot of UPnP implementations available. Intel did indeed provide a GPL protocol stack that you can download from their site. It builds on Linux nicely, and give you sample apps, etc. We have our two stacks that will begin appearing in cheap applicances Real Soon Now (tm) thanks to our silicon-builder-friends.
Alternatives to UPnP? Not really, at least not in one place. Many folks who responded to this message address only the Auto-IP part, where the box gets its IP address (FYI, Auto-IP on a net with DHCP is pretty much just DHCP). What they're missing is the juice of UPnP, where there's a protocol for device discovery and control. All the control and discovery is without any a-priori knowlege or configuration! (N.b., UPnP and Plug&Play are entirely different beasts: UPnP is on a network, Plug&Play and Kudzu are a single box)
E.g., your UPnP PVR is on a net with your UPnP phone (they're both coming). They know about each other, thanks to UPnP. Phone rings, PVR pauses automatically and puts up caller ID. You pick up the phone, talk, hang up, PVR starts again. Your washing machine tells you it's time to switch the load over, not only on the TV, but on your UPnP Zaurus or iPaq (reality today), or perhaps your electronic picture frame. You want to listen to your MP3 library from your home server. Easy. Your iPaq, Zaurus, stereo receiver, anything, knows in advance how to search for media sources, get a list of titles available, and start spooling it down. Click and go.
Our demos are much, much cooler than that even, but I don't know how much I can say.
To answer your question, sure there are alternatives, but they're in many disjoint parts. I'd suggest getting Intel's kit, and playing with it, seeing what you can do with it. Whether you do that, or play with disjoint parts, you'll be experimenting, but UPnP will take off fairly soon now.