This provides an "it's all Unix devices" approach that is quite entirely different from X.
It's a fascinating approach, that I expect people don't believe could possible work acceptably well.
It's very unfortunate that building a windowing system is so much work that there hasn't been more experimentation with approaches like that with Plan 9...
The system has been functioning perfectly well with the non-existent (in comparison!) bandwidth of Plain Old Telephone Modems; there's no reason for the product they're selling to need Firewire.
Doubtless the MPAA and related folks would be aghast at the thought of having fast interfacing to disk; that's just "piracy" asking to happen.
If they can get USB cheaply on the motherboard, and that allows hooking up a number of cheap USB devices, that's quite enough enhancement for now.
As for Ethernet, I agree that it would be pretty slick to throw that in. It would seem to me that dropping an Ethernet chip onto the motherboard and a port out the back would be a pretty good way to go, and would offer the merit that folks with ADSL or "cable modems" could then get their TV guide updates faster without needing the ISP service. (That saves TiVO some Actual Dollars, no doubt!)
However, there are some technical hurdles to get thru in supporting the Ethernet-to-Some-ISP-connection strategy; it means:
Users of this have to have a router and/or hub;
Users of this have to have a bunch of spare Ethernet cabling (or wireless Ethernet; that's more expensive!!!;
Users that think of this as an appliance will need considerable handholding in the process of Integrating EtherTiVO into The Home Network Architecture
I'd be comfortable with all this, but then, I've got a hub, firewall, and have my own 10BaseT cable-building equipment. I'm hardly the "appliance user" they're mostly selling to.
Colour me unsurprised that they didn't want to just leap into that...
Arguably it is more of a "generic Unix" thing; and actually is pretty usable on a wider set of systems than that.
It's intended to store directory information that would be useful for all sorts of things in terms of system administration on Linux and similar systems; the poster certainly did mention tools widely used on Linux like useradd , userdel, usermod, passwd.
He derives from good stuff too.
on
The Forever War
·
· Score: 2
To a great extent, The Forever War is a reaction against what Haldeman probably considered "unrestrained jingoism" of Starship Troopers. (Of course, for truly unrestrained jingoism, you have to look to the movie. The makers of the movie have commented that they did a parody of the story, picking "fascist tendancies" whenver they could, but that's another story...)
I'd argue Heinlein was exploring some ideas, as opposed to "prescribing how things ought to be," so it's perfectly fair for Haldeman to have explored a different direction, and he did it well, generating an interesting read.
I'm afraid I don't heartily recommend the later books; if "Forever War" derived some greatness from deriving from some neat ideas, well, the later ones didn't.
Forever Peace started well enough, but it was really irritating when it headed into the same sort of giant military conspiracy theory "MacGuffin" that turned the movie Outbreak from good to very bad.
Lord of the Rings did "conspiracy" much better by almost not showing us the malevolence of Sauron...
I'd put Forever War on the "good shelf," but dunno about the others...
How much is it going to cost to get the unit to do that stuff?
I'd argue that while the machine (and its near competitors) are "overpowered" for doing the things a Palm does, they're underpowered with regard to the new sorts of applications such as music playing and wireless.
How much will it cost to get it "up to scratch?"
A couple hundred dollars for 802.11b is OK for use maybe at home and at the office; how mobile it is elsewhere is another question...
How much is the GB of disk?
GPS has got to cost a couple hundred...
It would be unsurprising if making the unit "useful" pushes the price up well over $1K. That is rather pricey...
I keep being amused (and a little disgruntled!) that the 225MHz StrongARM of about three years ago is still the same "205 MHz StrongARM" that they keep deploying on these little critters.
I realize that the 16 MHz DragonBall chips are still pretty sufficient for coping with storing addresses, notes, and the likes; it's just irritating that it's stayed at the same speed for so long.
On the up-side, it moves from having a mere 16MB of RAM to having 64MB of RAM.
That's probably enough to start moving towards doing some "real" work, although if you want more than 15 minutes worth of MP3s, you'll still have to wait for the 256MB model.
I don't think these get to be truly better "mousetraps" until they have a pretty serious amount of storage space.
The "StrongARM-based" PDAs have been around for a while, and the ones that you'd actually want always cost about $600 USD, which is a whopping lot more than a not-quite-disposable Whichever-Palm-has Gotten Cheap .
A year ago, it made sense that the iPAQ was expensive as an 'early-adopter" product; the continuing-to-be-hefty price is not particularly attractive.
Woo-hoo! It runs Linux!
I think it's pretty cool and all that IBM has built a wrist-watch that runs Linux; that doesn't forcibly grip me as being fundamentally important.
PalmOS is old enough that it may be getting "old in the tooth;" it's still pretty much useful enough. (Except for playing MP3s, but it's cheaper to get a recent Diamond Rio for that...)
A new model from another maker may be News for Nerds, but I have to wonder if it's really Stuff that matters.
It appears that it uses some form of generic disk storage protocol.
In recent Linux releases, there is a USB_STORAGE driver that can be included in the kernel; I would presume that's what they're referring to, at least vis-a-vis Linux support.
It's entirely likely that three years ago, W98 didn't include drivers for disk storage devices, thus meaning that if you want to use the device with W98, you need such a "generic driver."
Similarly, Windows NT 4 is getting pretty old; it likely didn't include support for USB storage devices either.
In a sense, this may be regarded kind of like having SCSI support. You do need a SCSI driver to access SCSI devices, but once you've got that, there's no special driver for Seagate drives as compared to Quantum or IBM...
I've not tried installing NOLA, but keep SQL-Ledger around. I'd say you're bang-on in assessing that it's important to have the technology be readily installed.
A prime problem with GnuCash vis-a-vis trying to get the "bleeding edge" functionality is that it is an absolute pain to get compiled. The functionality may be worth it, but if it's daunting to build, that's a problem.
In exactly the same manner, there are all sorts of projects out there to build some really cool JavaEnterprize-Foo-Beans- Coffee-Espresso-Transactional- EE goodness; if it takes someone who's an expert in all of:
Apache;
Some Server Extension;
Some Java Framework Atop a Server Extension;
Some Application Framework that doesn't do squat until all the above pieces are running perfectly along with an interface to an RDBMS
Excuse me if I don't jump up and down cheering at the vast complexity of this.
In contrast, SQL-Ledger is indeed quite straightforward to set up. A bit more manually-involved than I'd like, but certainly not badly so.
I've pointed it out several times, and apparently those that decide what stories are "interesting" consisidered it not to be of any interest.
The one problem with SAP-DB at this point, from the "can we make it ubiquitous" perspective, is that it's a real pain to compile.
It was coded on mainframes, and the suite of compilation tools are based on that approach. Thus the code base (and compile process) is "cryptic upper-case 8 character names everywhere."
It's a desparate pain to try to compile it, so it has not quickly moved towards being ubiquitously available. Red Hat doesn't include it in trivially-installable manner in the manner of MySQL or PostgreSQL. Debian folk can't do apt-get install sapdb .
Give it some more time, and get some more public input, and it'll get more attention.
Of course, that would merely bring us to the point where it would start being an interesting "data storage" substrate for an accounting application. Then comes the 'real" work of determining what tables, fields, relationships, and such exist, and how to manage UIs...
Waxing Biblical, for a moment, there have been wars and rumours of wars for literally thousands of years.
For human society to so dramatically transform in 40 years for there to be "no more war" would make any of the changes of the 20th century appear tiny and irrelevant.
It is interesting to observe that despite the technical progress, the 21st century has been marked by conflicts that would have been quite well recognized hundreds of years ago. In the late 1800s, there was fighting in South Africa in the Boer Wars; the last century has been marked by, if anything, more, and more vigorous wars than the 18th and 17th centuries.
The notion that war will be no more in 2041 is foolishly wishful thinking.
The crucial difference between the "free" BSD systems and Linux is that OpenBSD/FreeBSD/NetBSD define as their "base OS" something rather larger than Linux does.
In effect, all Linux proper is is an OS kernel. Everything on top of the kernel is something that is bolted on independently of any kernel development. Thus Slackware is the Linux kernel plus "all sorts of stuff Patrick Volkerding added;" Red Hat Linux is the kernel plus "all sorts of stuff they added;" ditto for SuSE, Debian, Mandrake, ad infinitum.
With the BSDs, there's quite a lot of additional "environment" that is tightly tied to kernel development so that you've got a "base system" that is defacto-standardized that is capable of, for instance, recompiling itself.
With Linux, you've got to add in whatever that is needed that isn't in the kernel in order to do that yourself.
With that larger basis of "stuff" surrounding the kernel, a whole lot of the arguments "Red Hat puts the files here; Debian puts them there" just plain go away. The "Linux Standard Base" effort where they're trying to standardize where a bunch of the basic stuff goes and what it does is an effort that would be ludicrously irrelevant amongst the BSD folk; they started off by standardizing the user space stuff that LSB is fighting over.
Then there's Ports. Ports is sort of the BSD equivalent to Debian's apt-get or perhaps the Red Hat-oriented autoRPM . Except with a difference: With Ports, the approach is not to download binary packages, it is rather to download the sources, pull in any patches needed for Ports integration, and then compile it all.
That's got the demerit that it's a lot more work for your poor, overworked CPU.
However, it has the merit that if you compile libraries and packages, together, on your system, with the same compiler, the sorts of "DLL Hell" that people suffer from when they grab RPM files from here and there just can't happen. The libraries will necessarily be compatible with the applications because the applications were compiled with and for the precise set of libraries you have on your system.
This means that if there are any challenges in getting programs to compile, you'll hit them. That being said, since the folks collecting and maintaining the Ports will indeed hit those issues, they're likely to have patches in place so that by the time you see the code, it should compile cleanly.
In effect, the crucial concept involved in all of this is that the BSD packaging paradigm is that everything should be readily compilable and recompilable, from the ground up. The classic "make world" will compile all the base tools, the kernel, all the kings horses, and all the kings men, and what you get at the end is that every single component in the "world" (which is the base system; the stuff below Ports ) has been rebuilt locally.
It's all using Makefiles, and can be downloaded using CVS, so the details are all visible. None of the controversies of "well, the Red Hat kernel compiles include some special patches, and getting at them is a bit challenging...."
Both systems can try various ideas, and see which turn out to be valuable.
Those that are, are likely to get implemented by the other system, perhaps even more cleanly. Both environments, for instance, seem to have burgeoning efforts surrounding the IETF calendaring and address standards; they may even become interoperable by virtue of there being IETF standards:-).
Those ideas that turn out to be horrid can be learned from and avoided.
After all, it's not as if throwing all the people onto one project would necessarily lead to higher productivity. Double the team sizes, and communications costs diminish productivity:-(.
There are doubtless some jibes back and forth, here and there, but if they were spending 80% of their time flaming one another, they wouldn't get much code written...
Miles doesn't strike me as an anti- hero; just as an unconventional hero.
He tends towards all sorts of derring-do
But hasn't the body to accomplish it all. Part of his brain thinks he ought to be a strapping big fellow six feet tall, which is what he'd have grown up to, save for his "difficulties."
He wants to rescue prisoners, and save fair maidens
... Some of those fair maidens being 7 feet tall, with fangs and fur. And some of his troops being of, um, "somewhat unconventional sexual interests."
He wants to mean well.
But runs into the dilemma that he works for a pretty "imperial" intelligence service that sometimes has some dirty work that must be done.
And runs into the problem that his family has been "doing politics" for generations, and the given is that political situations always get pretty dirty.
There's a whole lot of "necessary evil" there.
Frankly, the only sort-of-antihero part is the bit of "realism" that gets thrown in concerning the dirt of politics and the messiness of real life.
I seem to recall the Greeks concluding that there were really only something around 7 or 8 archetypal "plots" for stories; that fits not too badly with your characterization of "good fantasy" having an archtypal set of plot elements.
To the extent to which plots are archetypal, you're certainly going to see the same archetypal elements over and over, because they're inherent to the medium.
It's fair to say that there can only be a very few "best works;" if you run though vast numbers of sub-par fantasy books, it seems unremarkable that this could get tiresome. LOTR is certainly one of the best, and readily arguable to be the best. (It's the only fantasy book I have in hardcover, on acid-free paper. Interpret that as you will.:-).)
Availability in Hardcover Not A Sneaky Trick...
on
The Curse of Chalion
·
· Score: 2
I'm not sure I'm going to buy it in "first run," but it's nice to see a release in hardcover form of much of this material.
I suppose it might be "sneaky" if you headed to Amazon, saw it was a new title, failed to bother to check the reviews, which conspicuously mention that it's a "retread," and just bought it on virtue of title and author making no attempt to see what's inside.
Yes, that's "The Spirit Ring" not "The Smoke Ring"
on
The Curse of Chalion
·
· Score: 2
I guess that must have been too much LDS back in the '60s..."
You might want to look at the history of Ghostscript, which has, for years, taken exactly the approach I describe.
More pointedly, I would direct you to an Interview with L. Peter Deutsch which addresses the precise issues surrounding copyright assignment that you seem to think so daunting.
Ghostscript has been not finding them to be a problem for a lot of years now.
Releasing it under the GPL would mean that there would be a set of "hacker types" interested in deploying it amongst a group that is technically knowledgeable.
That's helpful in getting it known, which is worth rather a lot.
The codec would not in that form be usable outside of the context of freely-redistributable software. Someone who wants to integrate it into their cool, but proprietary viewer would find that they can't, at least not with the GPL-licensed version.
That can't represents the place where they can look for their revenues.
It's not obvious that there can possibly be interest in it without there being some sort of release; the company hasn't money to spend on renting Times Square to show the world they've got a K001 Product.
Releasing under something like the GPL may be the only way to get it into use, and to get any return from it.
The typical reason for "open source" software projects to be viable is not that the people involved expect to see lots of licensing and royalty fees to roll in, but rather that they expect the results to be useful.
This stuff could become useful, in a business setting, for instance, by allowing employees to wander around with laptops with wireless network hardware, and have a self-assembling network. Within that sort of setting, the notion of "paid subscription" is ridiculous silliness. Money wouldn't be "made;" money would be saved over alternative ways of setting up networks.
There's actually a set of downloads of code available at www.Jxta.org.
They provide considerably more details, to wit:
The Project JXTA platform initially defines the following protocols:
NetPeerGroup Protocol
Peer Discovery Protocol
PeerGroup Discovery Protocol
Peer Information and Management Protocol
PeerGroup Membership Protocol
PeerGroup Resolver Protocol
PeerGroup Sharing Protocol
This kind of corresponds to some of the traditional Unix services like Bind, and such, or with CORBA services like Naming, Trading, and such, albeit with the explicit intent that the respective "registries" of hosts and host information be Rather Dynamic.
This seems a lot more likely to "go somewhere" than Jini, seeing as how it's a lot more "platform-independent." See the Protocol Specs
Slashdot Mirror
It's a fascinating approach, that I expect people don't believe could possible work acceptably well.
It's very unfortunate that building a windowing system is so much work that there hasn't been more experimentation with approaches like that with Plan 9...
As for finding tapes, I'm sure that some will continue to come up in bargain bins if you search hard enough...
Presumably Henry Spencer (or others at utzoo or elsewhere) could use something like this to bundle up tapes of somewhat more modern provenance...
The system has been functioning perfectly well with the non-existent (in comparison!) bandwidth of Plain Old Telephone Modems; there's no reason for the product they're selling to need Firewire.
Doubtless the MPAA and related folks would be aghast at the thought of having fast interfacing to disk; that's just "piracy" asking to happen.
If they can get USB cheaply on the motherboard, and that allows hooking up a number of cheap USB devices, that's quite enough enhancement for now.
As for Ethernet, I agree that it would be pretty slick to throw that in. It would seem to me that dropping an Ethernet chip onto the motherboard and a port out the back would be a pretty good way to go, and would offer the merit that folks with ADSL or "cable modems" could then get their TV guide updates faster without needing the ISP service. (That saves TiVO some Actual Dollars, no doubt!)
However, there are some technical hurdles to get thru in supporting the Ethernet-to-Some-ISP-connection strategy; it means:
I'd be comfortable with all this, but then, I've got a hub, firewall, and have my own 10BaseT cable-building equipment. I'm hardly the "appliance user" they're mostly selling to.
Colour me unsurprised that they didn't want to just leap into that...
Arguably it is more of a "generic Unix" thing; and actually is pretty usable on a wider set of systems than that.
It's intended to store directory information that would be useful for all sorts of things in terms of system administration on Linux and similar systems; the poster certainly did mention tools widely used on Linux like useradd , userdel, usermod, passwd.
I'd argue Heinlein was exploring some ideas, as opposed to "prescribing how things ought to be," so it's perfectly fair for Haldeman to have explored a different direction, and he did it well, generating an interesting read.
I'm afraid I don't heartily recommend the later books; if "Forever War" derived some greatness from deriving from some neat ideas, well, the later ones didn't.
Forever Peace started well enough, but it was really irritating when it headed into the same sort of giant military conspiracy theory "MacGuffin" that turned the movie Outbreak from good to very bad.
Lord of the Rings did "conspiracy" much better by almost not showing us the malevolence of Sauron...
I'd put Forever War on the "good shelf," but dunno about the others...
I'd argue that while the machine (and its near competitors) are "overpowered" for doing the things a Palm does, they're underpowered with regard to the new sorts of applications such as music playing and wireless.
How much will it cost to get it "up to scratch?"
It would be unsurprising if making the unit "useful" pushes the price up well over $1K. That is rather pricey...
I realize that the 16 MHz DragonBall chips are still pretty sufficient for coping with storing addresses, notes, and the likes; it's just irritating that it's stayed at the same speed for so long.
That's probably enough to start moving towards doing some "real" work, although if you want more than 15 minutes worth of MP3s, you'll still have to wait for the 256MB model.
I don't think these get to be truly better "mousetraps" until they have a pretty serious amount of storage space.
A year ago, it made sense that the iPAQ was expensive as an 'early-adopter" product; the continuing-to-be-hefty price is not particularly attractive.
I think it's pretty cool and all that IBM has built a wrist-watch that runs Linux; that doesn't forcibly grip me as being fundamentally important.
PalmOS is old enough that it may be getting "old in the tooth;" it's still pretty much useful enough. (Except for playing MP3s, but it's cheaper to get a recent Diamond Rio for that...)
A new model from another maker may be News for Nerds, but I have to wonder if it's really Stuff that matters.
In recent Linux releases, there is a USB_STORAGE driver that can be included in the kernel; I would presume that's what they're referring to, at least vis-a-vis Linux support.
It's entirely likely that three years ago, W98 didn't include drivers for disk storage devices, thus meaning that if you want to use the device with W98, you need such a "generic driver."
Similarly, Windows NT 4 is getting pretty old; it likely didn't include support for USB storage devices either.
In a sense, this may be regarded kind of like having SCSI support. You do need a SCSI driver to access SCSI devices, but once you've got that, there's no special driver for Seagate drives as compared to Quantum or IBM...
A prime problem with GnuCash vis-a-vis trying to get the "bleeding edge" functionality is that it is an absolute pain to get compiled. The functionality may be worth it, but if it's daunting to build, that's a problem.
In exactly the same manner, there are all sorts of projects out there to build some really cool JavaEnterprize-Foo-Beans- Coffee-Espresso-Transactional- EE goodness; if it takes someone who's an expert in all of:
Excuse me if I don't jump up and down cheering at the vast complexity of this.
In contrast, SQL-Ledger is indeed quite straightforward to set up. A bit more manually-involved than I'd like, but certainly not badly so.
The one problem with SAP-DB at this point, from the "can we make it ubiquitous" perspective, is that it's a real pain to compile.
It was coded on mainframes, and the suite of compilation tools are based on that approach. Thus the code base (and compile process) is "cryptic upper-case 8 character names everywhere."
It's a desparate pain to try to compile it, so it has not quickly moved towards being ubiquitously available. Red Hat doesn't include it in trivially-installable manner in the manner of MySQL or PostgreSQL. Debian folk can't do apt-get install sapdb .
Give it some more time, and get some more public input, and it'll get more attention.
Of course, that would merely bring us to the point where it would start being an interesting "data storage" substrate for an accounting application. Then comes the 'real" work of determining what tables, fields, relationships, and such exist, and how to manage UIs...
For human society to so dramatically transform in 40 years for there to be "no more war" would make any of the changes of the 20th century appear tiny and irrelevant.
It is interesting to observe that despite the technical progress, the 21st century has been marked by conflicts that would have been quite well recognized hundreds of years ago. In the late 1800s, there was fighting in South Africa in the Boer Wars; the last century has been marked by, if anything, more, and more vigorous wars than the 18th and 17th centuries.
The notion that war will be no more in 2041 is foolishly wishful thinking.
In effect, all Linux proper is is an OS kernel. Everything on top of the kernel is something that is bolted on independently of any kernel development. Thus Slackware is the Linux kernel plus "all sorts of stuff Patrick Volkerding added;" Red Hat Linux is the kernel plus "all sorts of stuff they added;" ditto for SuSE, Debian, Mandrake, ad infinitum.
With the BSDs, there's quite a lot of additional "environment" that is tightly tied to kernel development so that you've got a "base system" that is defacto-standardized that is capable of, for instance, recompiling itself.
With Linux, you've got to add in whatever that is needed that isn't in the kernel in order to do that yourself.
With that larger basis of "stuff" surrounding the kernel, a whole lot of the arguments "Red Hat puts the files here; Debian puts them there" just plain go away. The "Linux Standard Base" effort where they're trying to standardize where a bunch of the basic stuff goes and what it does is an effort that would be ludicrously irrelevant amongst the BSD folk; they started off by standardizing the user space stuff that LSB is fighting over.
Then there's Ports. Ports is sort of the BSD equivalent to Debian's apt-get or perhaps the Red Hat-oriented autoRPM . Except with a difference: With Ports, the approach is not to download binary packages, it is rather to download the sources, pull in any patches needed for Ports integration, and then compile it all.
That's got the demerit that it's a lot more work for your poor, overworked CPU.
However, it has the merit that if you compile libraries and packages, together, on your system, with the same compiler, the sorts of "DLL Hell" that people suffer from when they grab RPM files from here and there just can't happen. The libraries will necessarily be compatible with the applications because the applications were compiled with and for the precise set of libraries you have on your system.
This means that if there are any challenges in getting programs to compile, you'll hit them. That being said, since the folks collecting and maintaining the Ports will indeed hit those issues, they're likely to have patches in place so that by the time you see the code, it should compile cleanly.
In effect, the crucial concept involved in all of this is that the BSD packaging paradigm is that everything should be readily compilable and recompilable, from the ground up. The classic "make world" will compile all the base tools, the kernel, all the kings horses, and all the kings men, and what you get at the end is that every single component in the "world" (which is the base system; the stuff below Ports ) has been rebuilt locally.
It's all using Makefiles, and can be downloaded using CVS, so the details are all visible. None of the controversies of "well, the Red Hat kernel compiles include some special patches, and getting at them is a bit challenging...."
Big-time learning opportunity.
Those that are, are likely to get implemented by the other system, perhaps even more cleanly. Both environments, for instance, seem to have burgeoning efforts surrounding the IETF calendaring and address standards; they may even become interoperable by virtue of there being IETF standards :-).
Those ideas that turn out to be horrid can be learned from and avoided.
After all, it's not as if throwing all the people onto one project would necessarily lead to higher productivity. Double the team sizes, and communications costs diminish productivity :-(.
There are doubtless some jibes back and forth, here and there, but if they were spending 80% of their time flaming one another, they wouldn't get much code written...
But hasn't the body to accomplish it all. Part of his brain thinks he ought to be a strapping big fellow six feet tall, which is what he'd have grown up to, save for his "difficulties."
But runs into the dilemma that he works for a pretty "imperial" intelligence service that sometimes has some dirty work that must be done.
And runs into the problem that his family has been "doing politics" for generations, and the given is that political situations always get pretty dirty.
There's a whole lot of "necessary evil" there.
Frankly, the only sort-of-antihero part is the bit of "realism" that gets thrown in concerning the dirt of politics and the messiness of real life.
To the extent to which plots are archetypal, you're certainly going to see the same archetypal elements over and over, because they're inherent to the medium.
It's fair to say that there can only be a very few "best works;" if you run though vast numbers of sub-par fantasy books, it seems unremarkable that this could get tiresome. LOTR is certainly one of the best, and readily arguable to be the best. (It's the only fantasy book I have in hardcover, on acid-free paper. Interpret that as you will. :-).)
I suppose it might be "sneaky" if you headed to Amazon, saw it was a new title, failed to bother to check the reviews, which conspicuously mention that it's a "retread," and just bought it on virtue of title and author making no attempt to see what's inside.
The URL's right, though!
I suppose that it is her "first" fantasy novel, if you choose to ignore her other first fantasy novel, The Smoke Ring, first published in about 1992.
More pointedly, I would direct you to an Interview with L. Peter Deutsch which addresses the precise issues surrounding copyright assignment that you seem to think so daunting.
Ghostscript has been not finding them to be a problem for a lot of years now.
That's helpful in getting it known, which is worth rather a lot.
The codec would not in that form be usable outside of the context of freely-redistributable software. Someone who wants to integrate it into their cool, but proprietary viewer would find that they can't, at least not with the GPL-licensed version.
That can't represents the place where they can look for their revenues.
It's not obvious that there can possibly be interest in it without there being some sort of release; the company hasn't money to spend on renting Times Square to show the world they've got a K001 Product.
Releasing under something like the GPL may be the only way to get it into use, and to get any return from it.
They then find the power of 2 that is just larger than that. That's Y which is equal to 2 ^ N
They then take a ruler, 1 foot long, and record on it two pieces of information:
Insert ruler into padded envelope, and mail...
Or was this just from some old science fiction story???
This stuff could become useful, in a business setting, for instance, by allowing employees to wander around with laptops with wireless network hardware, and have a self-assembling network. Within that sort of setting, the notion of "paid subscription" is ridiculous silliness. Money wouldn't be "made;" money would be saved over alternative ways of setting up networks.
They provide considerably more details, to wit:
The Project JXTA platform initially defines the following protocols:
This kind of corresponds to some of the traditional Unix services like Bind, and such, or with CORBA services like Naming, Trading, and such, albeit with the explicit intent that the respective "registries" of hosts and host information be Rather Dynamic.
This seems a lot more likely to "go somewhere" than Jini, seeing as how it's a lot more "platform-independent." See the Protocol Specs