Slackware has traditionally had somewhat closer ties to BSD than the other Linux distributions, and it has long eschewed the notion of producing "binary packages" that were any more sophisticated than being basic tarballs of the binaries.
Hooking up Ports to Slackware would have the merits that:
While it means there's "something more than just zcat whatever | (cd / ; tar xvf -) " to install new software, it is still very much "in the traditional command-line Unix philosophy"
It would mean that things like the long-standing Metafont bug in the TeX installation might get fixed in the central CVS repository, perhaps by someone not the slightest bit associated with Slackware.
It could make it a lot easier to get a bunch of additional software installed on Slackware; no need to install it all by hand.
Note that this doesn't contribute to "cleaning up" any of the "mess of incompatible package management systems;" that is something that is not going to be changed quickly, if ever.
By the way, for "flip side," there was a proposal at one point to build a FreeBSD kernel with a Debian user space... Definitely different strokes!
The Ports tools would need to use the same license, namely the BSD license.
This is no big deal, as this is very likely the case already for the differing versions for the differing BSD variations.
Individual packages would retain whatever license they already have.
Note that there are Ports for all sorts of GPLed software and such.
The point here is that what licensing is crucial is that of the package tool, and not anything more than that.
By the way, it is eminently likely, and should be blatantly obvious to anyone that does a modicum of research that the system proposed is to be based on the BSD Ports system, which is neither particularly like RPM nor is it greatly like dpkg. (Although the differences betwixt Ports and dpkg are a bit less dramatic, as the Debian project has a similar interest in having "somewhat centralized public access to the source code tree."
Ports involves a "central" Makefile that knows how to look up source code for individual packages. It is essentially based on the philosophy of pulling sources for software, wrapping around it a Makefile and any patches needed to resolve differences between pristine sources and the code that is needed to make it compile and run on the system in question.
The way it interfaces, it pretends to be a keyboard, which means that the "nasty" parts of producing a driver have already been done.
What needs to be written is the "user space" side of things, which essentially amounts to an interface that takes ISBN numbers read using the scanner and then "does something useful."
That's not "device driver" work; that's application work. Feel free to be inspired to work on apps or drivers; don't assume that the info here provides any guidance on dealing with device drivers.
I pulled the fairly short Perl version, and immediately concluded that it could be shortened and speeded up immensely by suitable use of associative arrays.
The same principle will hold true for just about any language offering easy access to hash tables; the program can be made data-driven, and be both minscule and incredibly fast.
I'll probably do up Scheme and Lisp versions over the long weekend; it would probably be an interesting exercise to do it in OCAML, as an exercise in pattern matching.
Betcha most of them fit into under a page, and well within the constraints of a./ message...
The issue here has nothing to do with GNUisms, and everything to do with ABI.
Do you run parts of KDE that were compiled using G++, and other parts that were built using Sun's C++ compiler?
I think not; there is no ABI standard, whether "official" or "defacto," and thus you cannot reasonably expect to link code compiled using one compiler to code compiled using another compiler.
The same is not true for C; there is a reasonable expectation that you can link code compiled with GCC to other code compiled using Someone Else's Compiler.
I've got an Alpha box where the CPU runs "pretty hot," and it didn't need any "one point heat sink."
This situation sounds rather like a blast back into the past when a VAX 11/780 produced enough heat to keep your house warm.
And there are other perspectives from which it doesn't make sense, particularly the "IA-64" perspective. I thought that Intel was trying to start off a migration process to the New And Improved 64 bit IA-64 platform. Releasing Still More Pentiums doesn't seem terribly
sensible.
On the other hand, people may react to this properly, thus:
A
one pound heatsink?!? What kind of crack are they smoking???
and conclude that they should look to the "kinder, gentler, lighter-heat-sinked" IA-64 systems.
It is fair to say that the Transmeta "hype" overstates the importance of the decreases in power consumption, from several perspectives:
The approach taken with Crusoe is not the only possible approach.
Intel and AMD are likely to take other approaches, and improve power consumption. Perhaps they will not get as favorable results, but "close enough" is good here, much as with horseshoes and nuclear hand grenades.
The CPU is not the only thing that "burns power" on a laptop.
Having a CPU that consumes ten times less power is of limited value if the hard drive and LCD display still suck (power).
When Transmeta pushes that the CPU consumes vastly less power just makes Toshiba look bad if Toshiba can't make all the other components consume less power.
"Politically," this is probably what they're pushing back at...
It is unfortunate that it requires some proprietary components in order to function.
This means that if the compiler is to be of any continuing interest as other than a "bare husk" from which GCC might "mine" some useful techniques, there will need to be a project to create a set of tools basically corresponding to Binutils and perhaps some portion of CygWin so that there is some "base" set of tools and libraries that can be used to recreate themselves.
The fact that there are existing GNU tools to that purpose ought to ease the task somewhat...
Way back when, some of the Atari and Amiga folk at UW were lobbying Don Cowan to get Watcom to release a 68K version.
There was an "unofficial tradition" that some of the internal folk had created a 68K code generator, but it never got released publicly.
It is not at all obvious that the compilers are of vast continuing use; they have been strongly tied to the IA-32 platform for so long that it may well be that the onset of IA-64, combined with, as you say, the "latest COM stuff," meant that a big-time redesign would be necessary for Watcom C to be useful for Windows deployment next year.
The availability of source code may nonetheless be useful to glean useful optimization techniques that may be redeployed with GCC. I'd heard at CSC talks in the late '80s that there was a lot of "slick" static analysis that would be generally applicable to any architecture; as you observe, architectural differences between Watcom C and GCC might make it difficult to make them applicable. Hopefully some of the peephole optimization techniques would be useful for the IA-32 architecture, and by the time the "analogies" would be made to make them applicable, it might become possible to apply "analagous" optimizations to other architectures.
Seeing as how the company's Partners includes Novell, the Canopus Group, and Caldera, it seems reasonably likely that the enterprise comes with the "blessing" both of Ray Noorda and of Novell.
I'm sure the lawyers have "already talked," and were perhaps even involved with the initial establishment of Timpanogas...
If they are doing this with Novell's "general approval," then there is no problem.
If they do this without Novell's approval, then, well, "I'll have my lawyers talk with your lawyers." They're likely to get snarled up in legal wranglings regardless of the precise correctness of their actions.
There is a Port
of DCOM to Linux, but if you look closely, you'll notice that you
can cannot get any support for it, even if you pay money for this.
"Microsoft Israel" (where they put together their clone of IBM's
MQSeries, which is a pretty successful product) may be
doing "a port," but that is a far cry from Putting Boxes On Store
Shelves.
It may be that Microsoft is leaking this stuff so as to diminish
peoples' committments to the "more nearly native" alternatives of
StarOffice, ApplixWare, WordPerfect, and such.
People that decide to wait for whatever Microsoft might
release are obviously not buying what the other guys have
today. This is how IBM marketed the IBM 360 back in the 1960s, to
the great detriment of many other computer manufacturers.
IBM finally did release OS 360 and related hardware,
albeit late, expensive, bloated, and buggy.
The parallels should be obvious:-).
Furthermore, the DCOM comments really are important; "modern"
MS-Office software depends heavily on COM and COM+
components, which means that the first step to getting MS Office
running on Linux would indeed be the port of COM/DCOM/COM+.
And we don't know if this "announcement" represents a product that
will actually become available, or whether it is a "vaprous"
experiment, intended to use Fear, Uncertainty, and Doubt to discourage
sales of the competing products...
The problem which these guys have all huddled around without actually saying is that there's No Fair Benchmark.
If you visit TPC.org , you will find that they don't have one benchmark, but rather about four, with substantially different purposes:
TPC-C is intended to determine throughput of a transaction processing system in creating transactions;
TPC-H measures performance on what is intended to be an "ad-hoc DSS environment."
TPC-R measures performance on "business reporting," intended to be more like "typical DSS reports."
TPC-W measures performance on a "web transaction" workload.
These are all substantially different kinds of workloads. Just as MySQL and PostgreSQL are substantially different kinds of database systems.
The notion that there can be a comparable benchmark between the databases is something of which people should disabuse themselves.
If you need to have high performance transactional behaviour, I would point out that ODBC is NOT the issue; regardless of whether the SQL-CLI drivers suck, the important point is that neither database fully supports the industry standard SQL/XA or X/Open DTP and XA standards.
Serious transaction systems commonly use transaction monitors like BEA Tuxedo or Encina, interfacing via XA to a relational database (like Oracle, Sybase, DB/2, Sleepycat DB, TimesTen,...). From that perspective, MySQL and PostgreSQL are both still "toys," although SDTP - A Multilevel-Secure Distributed Transaction Processing System outlines how an XA interface to PostgreSQL was constructed in Common Lisp for use in a set of applications running on FreeBSD.
If you build a benchmark based on an application exercising the strengths of MySQL, it will probably perform badly when used with PostgreSQL, and vice-versa.
Take these systems seriously when they start supporting things like XA, and when BEA makes Tuxedo available for use with them.
Corel Linux doesn't include all the development tools.
... And prevents you from adding them precisely how?
I installed Corel Linux on a laptop and added in all sorts of development tools from "Debian most-modern."
Corel has released "evil, proprietary" software like WordPerfect, CorelDraw, and Paradox that run on top of Corel Linux, as well as atop Debian.
... And if you can see the "violation" in this, you should probably see this as being a "violation" of the FSF rather than of Debian...
But none of these seem particularly convincing.
Presumably the person that contributed the story can elaborate on this by augmenting such a list with a real and true violation of Debian that Corel is responsible for?
The really cool thing is that this will "force" everyone else to improve their graphics cards, which means that in another year's time, by the time that XFree86 4.x drivers are available:
There may actually be general availability of XFree86 4.x;
There may be reasonably-well-tested accelerated GLX / DRI support in XFree86;
There will be all sorts of other graphics cards with ludicrous amounts of RAM, relatively competitive with GeForce
The "only somewhat ludicrously powerful" graphics cards with 32MB of RAM will be, at that point, "obsolete," and thus, dirt cheap.
The one thing I'd be concerned about, a year from now, is that you might be buying graphics cards with 256MB of RAM, which is more than the amount of "regular RAM."
(I can remember the "good 'ol days" when we upgraded an Alpha 4600 system to 256MB of RAM to help it to better support 40 online users with the ludicrously-wasteful SAP R/3 ERP system. I can now imagine someone putting that much RAM on a video card, for use by one user. Unbelievable...)
My thesis does happen to be available through this service.
Mind you, if someone asked, I'd be reasonably willing to pass on a copy. This has happened, exactly once.
If I were relucant to do so, or someone interested in the MCNF problem couldn't find me, then it might well be worth $30 to them to get a copy of the thesis.
I would consider that price fairly outrageous, at around $0.21 per page, but while the price is fairly high, it's not likely to be a spectacular "profit centre" that I'd expect personally to rake in money over.
If I "went into business" selling copies of theses, printed as one-offs, $30 per thesis isn't an outrageous rate; I expect it would cost $15 a pop to search the microfilms and set it up for printing.
It's undoubtedly legal; it's not a "Napster-like" situation. And if my thesis proved to be a "best seller," I do have copyright so that I could sell it for a price undercutting UMI's pricing.
The hardware appears to have inherited a lot of characteristics directly from the Itsy, so it comes as no surprise that Jim Gettys and crew could proceed fairly quickly to having Linux and X working on the iPAQ.
Note that the TRG card was not solely providing 8MB of RAM, but also supplied some flashable ROM capabilities; I'm not sure which part was critical to letting Linux boot.
If you look at the uClinux web site, it really seems quite directed to use in embedded applications, and part of the documentation there suggests that many apps won't even need multitasking, which isn't terribly compatible with this being a "generally" useful platform.
I don't think you'll be running a uClinux PDA any time soon, suffice it to say...
You might want also to look at the TRGpro, which combines PalmOS, 8MB of RAM, and a standard CompactFlash slot that lets you use ordinary CF devices. You want 340MB of storage on your "Palm"? It's pretty expensive, but you can use the 340MB hard drive.
It actually represents one of the "better" of the ways of running Linux on a handheld; TRG describes this... The original way of booting Linux on a PalmPilot required that you have a TRG memory board in your PalmPilot.
The more important overreaching point here, to stay on topic with this being an alternative to iPAQ, is that I don't yet see that there is a set of PIM software to make the "Linux-running" palm-held machines useful.
For instance, the iPAQ appears to require that you hook it up to something that pretends to be a "dumb terminal," or that you can control everything using pre-programmed apps that use the onboard buttons. In other words, if an application needs a keyboard, you're left "grasping" for that.
There isn't perfectly suitable Linux software to run on PDAs for the PIM needs of:
Assuming the account is true (which is an assumption; if untrue, a whopping lot of illustration is stripped away), this situation demonstrates nicely that there is a conflict between:
Attempts to maintain "public safety," and
The set of rights set down by various and sundry US constitutional law.
Assuming, for the moment, that the account was accurate, the police acted with questionable propriety, in a manner more resembling the former police states of Eastern Europe than that of a "free" country.
Unless there is reasonable cause, you are not expected to identify yourself to police on demand.
That most certainly is one of the "negative features" of the world's Police States. You walk down the street, and may be confronted at any time with the demand: "Passport, please."
Similar is true for showing off what is in one's possession.
If there was a desire to change the rules on a temporary basis in such a sensitive area, there is a well-known way to do so. It is commonly called martial law, and allows for the suspension of many of the rights usually provided for by the legal system.
I am by no means "pro" the protesters. And I agree that the result was essentially what he "asked for."
But I see significant danger in suspending the rule of law outside the specific frameworks permitted in the law. That road leads towards Police State.
It would be a terrible shame if the Berlin Wall and the Iron Curtain fell in Eastern Europe only for the United States to throw itself into a paroxysm of despotism, having "won the war against tyranny" only to leap into tyranny itself.
Tiny Modern Hardware Is Good
on
Linux In A Box
·
· Score: 2
The "paperweight" idea may be cheap, but has the demerit that the resulting machine isn't small.
Furthermore, it is not at all unlikely that something of 80386 vintage will seriously suck both for the purposes of servicing the LAN as well as for servicing a modem.
On my newer (long retired) 80486 box, the UART couldn't cope well with a 28K modem; getting hardware for that now is liable to be a chore. Similar will be true for Ethernet; being limited to 10Base2 wouldn't kill me, as I use it to hook up my laptop, but a slow ISA card may actually hurt throughput.
I don't think this combo would work out terribly well to service a DSL or Cable Modem connection...
The really powerful way of doing this would be to harness an 'expert system' like cfengine.
In good "MVC" manner, things would be quite clearly separated out between "front end" versus "server." (That oversimplifies MVC; so sue me...)
With cfengine, the "back end" is a configuration management engine that does things like renaming files, mounting partitions, running network config utilities, and such. The thing that is nice about it over, say, Perl, is that it directly contains abstractions made for doing "config stuff." It's not a hive of Turing-complete bits of code that could be doing anything; if you want to shut off certain services, you might use:
Then, when you run the GUIed tool, it doesn't simply run some Perl code that does the system configuration for you, this time; it instead generates a cfengine script, which may assortedly be:
Run immediately, to have the desired effect;
Logged, so that a "system audit" has something to work with;
Read by the gentle user, as a route to Greater Understanding;
Added into the regular system configuration regime, so that every once in a while, the system makes sure that the change you put in place continues to be there.
I've used this property of cfengine to help in configuring new systems. If I have cfengine scripts set up that properly configure the local network topology, it's rather slick to drop them on a floppy, put that in the new box, run them, and suddenly have that new box linked up nicely, complete with NFS mounts and security fixes.
It's possible that cfengine isn't the perfect answer; the point is that by providing a "language for system configuration," it is a whopping lot more suited to large scale use for this task than, say, some set of Perl scripts that someone hacked up.
It costs $25 to have Tivo's high-paid engineers prepare an ISO image and put it onto a CD.
This issue was hashed over repetitively a year ago; head to the Deja site and read through the blathering about "how that price is too high" if you find that a useful use of your time.
If they really wanted to do something moderately innovative, Microsoft might try building something more like a successor for Pascal, perhaps more like Eiffel or Modula3 rather than slavishly replicating yet another stepchild to Simula and BCPL
Of course, for a more radically "innovative" approach, Microsoft already hired Simon Peyton-Jones, of some "fame" in the world of Functional Programming, and furthermore, he already had C--, Still Another "BCPL stepchild."
There are probably a whole pile of "cool things" that have been deployed internally that might actually be good things that will never see the light of day because, as Matt Welsh observes,
What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water.
That can apply as well to languages as to OSes...
Hashed to death on gnu.misc.discuss
on
More Tivo Hacking
·
· Score: 2
The most relevant bit of this discussion was a post from one of the Tivo engineers:
All our source modifications are available on CD.
You may acquire a CD by sending $24.95 to:
TiVo, Inc.
Attn: Richard Bullwinkle
894 Ross Drive
Sunnyvale, CA 94089
We state so in our manual, as required by the GNU
Public License.
Slashdot Mirror
Hooking up Ports to Slackware would have the merits that:
Note that this doesn't contribute to "cleaning up" any of the "mess of incompatible package management systems;" that is something that is not going to be changed quickly, if ever.
By the way, for "flip side," there was a proposal at one point to build a FreeBSD kernel with a Debian user space... Definitely different strokes!
This is no big deal, as this is very likely the case already for the differing versions for the differing BSD variations.
Note that there are Ports for all sorts of GPLed software and such.
The point here is that what licensing is crucial is that of the package tool, and not anything more than that.
By the way, it is eminently likely, and should be blatantly obvious to anyone that does a modicum of research that the system proposed is to be based on the BSD Ports system, which is neither particularly like RPM nor is it greatly like dpkg. (Although the differences betwixt Ports and dpkg are a bit less dramatic, as the Debian project has a similar interest in having "somewhat centralized public access to the source code tree."
Ports involves a "central" Makefile that knows how to look up source code for individual packages. It is essentially based on the philosophy of pulling sources for software, wrapping around it a Makefile and any patches needed to resolve differences between pristine sources and the code that is needed to make it compile and run on the system in question.
What needs to be written is the "user space" side of things, which essentially amounts to an interface that takes ISBN numbers read using the scanner and then "does something useful."
That's not "device driver" work; that's application work. Feel free to be inspired to work on apps or drivers; don't assume that the info here provides any guidance on dealing with device drivers.
The same principle will hold true for just about any language offering easy access to hash tables; the program can be made data-driven, and be both minscule and incredibly fast.
Betcha most of them fit into under a page, and well within the constraints of a ./ message...
The issue here has nothing to do with GNUisms, and everything to do with ABI.
Do you run parts of KDE that were compiled using G++, and other parts that were built using Sun's C++ compiler?
I think not; there is no ABI standard, whether "official" or "defacto," and thus you cannot reasonably expect to link code compiled using one compiler to code compiled using another compiler.
The same is not true for C; there is a reasonable expectation that you can link code compiled with GCC to other code compiled using Someone Else's Compiler.
This situation sounds rather like a blast back into the past when a VAX 11/780 produced enough heat to keep your house warm.
And there are other perspectives from which it doesn't make sense, particularly the "IA-64" perspective. I thought that Intel was trying to start off a migration process to the New And Improved 64 bit IA-64 platform. Releasing Still More Pentiums doesn't seem terribly sensible.
On the other hand, people may react to this properly, thus:
and conclude that they should look to the "kinder, gentler, lighter-heat-sinked" IA-64 systems.Intel and AMD are likely to take other approaches, and improve power consumption. Perhaps they will not get as favorable results, but "close enough" is good here, much as with horseshoes and nuclear hand grenades.
Having a CPU that consumes ten times less power is of limited value if the hard drive and LCD display still suck (power).
When Transmeta pushes that the CPU consumes vastly less power just makes Toshiba look bad if Toshiba can't make all the other components consume less power.
"Politically," this is probably what they're pushing back at...
This means that if the compiler is to be of any continuing interest as other than a "bare husk" from which GCC might "mine" some useful techniques, there will need to be a project to create a set of tools basically corresponding to Binutils and perhaps some portion of CygWin so that there is some "base" set of tools and libraries that can be used to recreate themselves.
The fact that there are existing GNU tools to that purpose ought to ease the task somewhat...
There was an "unofficial tradition" that some of the internal folk had created a 68K code generator, but it never got released publicly.
It is not at all obvious that the compilers are of vast continuing use; they have been strongly tied to the IA-32 platform for so long that it may well be that the onset of IA-64, combined with, as you say, the "latest COM stuff," meant that a big-time redesign would be necessary for Watcom C to be useful for Windows deployment next year.
The availability of source code may nonetheless be useful to glean useful optimization techniques that may be redeployed with GCC. I'd heard at CSC talks in the late '80s that there was a lot of "slick" static analysis that would be generally applicable to any architecture; as you observe, architectural differences between Watcom C and GCC might make it difficult to make them applicable. Hopefully some of the peephole optimization techniques would be useful for the IA-32 architecture, and by the time the "analogies" would be made to make them applicable, it might become possible to apply "analagous" optimizations to other architectures.
Seeing as how the company's Partners includes Novell, the Canopus Group, and Caldera, it seems reasonably likely that the enterprise comes with the "blessing" both of Ray Noorda and of Novell.
I'm sure the lawyers have "already talked," and were perhaps even involved with the initial establishment of Timpanogas...
If they do this without Novell's approval, then, well, "I'll have my lawyers talk with your lawyers." They're likely to get snarled up in legal wranglings regardless of the precise correctness of their actions.
"Microsoft Israel" (where they put together their clone of IBM's MQSeries, which is a pretty successful product) may be doing "a port," but that is a far cry from Putting Boxes On Store Shelves.
It may be that Microsoft is leaking this stuff so as to diminish peoples' committments to the "more nearly native" alternatives of StarOffice, ApplixWare, WordPerfect, and such.
People that decide to wait for whatever Microsoft might release are obviously not buying what the other guys have today. This is how IBM marketed the IBM 360 back in the 1960s, to the great detriment of many other computer manufacturers.
IBM finally did release OS 360 and related hardware, albeit late, expensive, bloated, and buggy.
The parallels should be obvious :-).
Furthermore, the DCOM comments really are important; "modern" MS-Office software depends heavily on COM and COM+ components, which means that the first step to getting MS Office running on Linux would indeed be the port of COM/DCOM/COM+.
And we don't know if this "announcement" represents a product that will actually become available, or whether it is a "vaprous" experiment, intended to use Fear, Uncertainty, and Doubt to discourage sales of the competing products...
If you visit TPC.org , you will find that they don't have one benchmark, but rather about four, with substantially different purposes:
- TPC-C is intended to determine throughput of a transaction processing system in creating transactions;
- TPC-H measures performance on what is intended to be an "ad-hoc DSS environment."
- TPC-R measures performance on "business reporting," intended to be more like "typical DSS reports."
- TPC-W measures performance on a "web transaction" workload.
These are all substantially different kinds of workloads. Just as MySQL and PostgreSQL are substantially different kinds of database systems.The notion that there can be a comparable benchmark between the databases is something of which people should disabuse themselves.
If you need to have high performance transactional behaviour, I would point out that ODBC is NOT the issue; regardless of whether the SQL-CLI drivers suck, the important point is that neither database fully supports the industry standard SQL/XA or X/Open DTP and XA standards.
Serious transaction systems commonly use transaction monitors like BEA Tuxedo or Encina, interfacing via XA to a relational database (like Oracle, Sybase, DB/2, Sleepycat DB, TimesTen, ...). From that perspective, MySQL and PostgreSQL are both still "toys," although SDTP - A Multilevel-Secure Distributed Transaction Processing System outlines how an XA interface to PostgreSQL was constructed in Common Lisp for use in a set of applications running on FreeBSD.
If you build a benchmark based on an application exercising the strengths of MySQL, it will probably perform badly when used with PostgreSQL, and vice-versa.
Take these systems seriously when they start supporting things like XA, and when BEA makes Tuxedo available for use with them.
There are several possibilities that come to mind as faintly plausible alternatives:
Mind you, the KDE/Debian Packaging Project disproves that that is the case...
I installed Corel Linux on a laptop and added in all sorts of development tools from "Debian most-modern."
But none of these seem particularly convincing.
Presumably the person that contributed the story can elaborate on this by augmenting such a list with a real and true violation of Debian that Corel is responsible for?
The really cool thing is that this will "force" everyone else to improve their graphics cards, which means that in another year's time, by the time that XFree86 4.x drivers are available:
The one thing I'd be concerned about, a year from now, is that you might be buying graphics cards with 256MB of RAM, which is more than the amount of "regular RAM."
(I can remember the "good 'ol days" when we upgraded an Alpha 4600 system to 256MB of RAM to help it to better support 40 online users with the ludicrously-wasteful SAP R/3 ERP system. I can now imagine someone putting that much RAM on a video card, for use by one user. Unbelievable...)
Mind you, if someone asked, I'd be reasonably willing to pass on a copy. This has happened, exactly once.
If I were relucant to do so, or someone interested in the MCNF problem couldn't find me, then it might well be worth $30 to them to get a copy of the thesis.
I would consider that price fairly outrageous, at around $0.21 per page, but while the price is fairly high, it's not likely to be a spectacular "profit centre" that I'd expect personally to rake in money over.
If I "went into business" selling copies of theses, printed as one-offs, $30 per thesis isn't an outrageous rate; I expect it would cost $15 a pop to search the microfilms and set it up for printing.
It's undoubtedly legal; it's not a "Napster-like" situation. And if my thesis proved to be a "best seller," I do have copyright so that I could sell it for a price undercutting UMI's pricing.
Note that the TRG card was not solely providing 8MB of RAM, but also supplied some flashable ROM capabilities; I'm not sure which part was critical to letting Linux boot.
If you look at the uClinux web site, it really seems quite directed to use in embedded applications, and part of the documentation there suggests that many apps won't even need multitasking, which isn't terribly compatible with this being a "generally" useful platform.
I don't think you'll be running a uClinux PDA any time soon, suffice it to say...
It actually represents one of the "better" of the ways of running Linux on a handheld; TRG describes this... The original way of booting Linux on a PalmPilot required that you have a TRG memory board in your PalmPilot.
The more important overreaching point here, to stay on topic with this being an alternative to iPAQ, is that I don't yet see that there is a set of PIM software to make the "Linux-running" palm-held machines useful.
For instance, the iPAQ appears to require that you hook it up to something that pretends to be a "dumb terminal," or that you can control everything using pre-programmed apps that use the onboard buttons. In other words, if an application needs a keyboard, you're left "grasping" for that.
There isn't perfectly suitable Linux software to run on PDAs for the PIM needs of:
Assuming, for the moment, that the account was accurate, the police acted with questionable propriety, in a manner more resembling the former police states of Eastern Europe than that of a "free" country.
That most certainly is one of the "negative features" of the world's Police States. You walk down the street, and may be confronted at any time with the demand: "Passport, please."
If there was a desire to change the rules on a temporary basis in such a sensitive area, there is a well-known way to do so. It is commonly called martial law, and allows for the suspension of many of the rights usually provided for by the legal system.
I am by no means "pro" the protesters. And I agree that the result was essentially what he "asked for."
But I see significant danger in suspending the rule of law outside the specific frameworks permitted in the law. That road leads towards Police State.
It would be a terrible shame if the Berlin Wall and the Iron Curtain fell in Eastern Europe only for the United States to throw itself into a paroxysm of despotism, having "won the war against tyranny" only to leap into tyranny itself.
Furthermore, it is not at all unlikely that something of 80386 vintage will seriously suck both for the purposes of servicing the LAN as well as for servicing a modem. On my newer (long retired) 80486 box, the UART couldn't cope well with a 28K modem; getting hardware for that now is liable to be a chore. Similar will be true for Ethernet; being limited to 10Base2 wouldn't kill me, as I use it to hook up my laptop, but a slow ISA card may actually hurt throughput.
I don't think this combo would work out terribly well to service a DSL or Cable Modem connection...
In good "MVC" manner, things would be quite clearly separated out between "front end" versus "server." (That oversimplifies MVC; so sue me...)
With cfengine, the "back end" is a configuration management engine that does things like renaming files, mounting partitions, running network config utilities, and such. The thing that is nice about it over, say, Perl, is that it directly contains abstractions made for doing "config stuff." It's not a hive of Turing-complete bits of code that could be doing anything; if you want to shut off certain services, you might use:
editfiles: /etc/inetd.conf
{
HashCommentLinesContaining "telnet"
HashCommentLinesContaining "finger"
HashCommentLinesContaining "tftp"
}
Then, when you run the GUIed tool, it doesn't simply run some Perl code that does the system configuration for you, this time; it instead generates a cfengine script, which may assortedly be:
I've used this property of cfengine to help in configuring new systems. If I have cfengine scripts set up that properly configure the local network topology, it's rather slick to drop them on a floppy, put that in the new box, run them, and suddenly have that new box linked up nicely, complete with NFS mounts and security fixes.
It's possible that cfengine isn't the perfect answer; the point is that by providing a "language for system configuration," it is a whopping lot more suited to large scale use for this task than, say, some set of Perl scripts that someone hacked up.
This issue was hashed over repetitively a year ago; head to the Deja site and read through the blathering about "how that price is too high" if you find that a useful use of your time.
Of course, for a more radically "innovative" approach, Microsoft already hired Simon Peyton-Jones, of some "fame" in the world of Functional Programming, and furthermore, he already had C--, Still Another "BCPL stepchild."
There are probably a whole pile of "cool things" that have been deployed internally that might actually be good things that will never see the light of day because, as Matt Welsh observes,
That can apply as well to languages as to OSes...
The most relevant bit of this discussion was a post from one of the Tivo engineers: All our source modifications are available on CD. You may acquire a CD by sending $24.95 to: TiVo, Inc. Attn: Richard Bullwinkle 894 Ross Drive Sunnyvale, CA 94089 We state so in our manual, as required by the GNU Public License.