At $500, these would likely fly out like hotcakes. (And probably sell at a loss, unfortunately.)
At $1000, they would be a pretty good value.
At $2500, Californians care about the power consumption this week, although if things stabilize in a month, they may not care so much.
For the rest of us, such pricing is daunting unless there's a really compelling application that needs the exact form factor provided.
This is highly unlikely to result in all sorts of people going out and buying these sorts of machines; it's just not economical unless there's a compelling need that justifies paying a couple grand for a pretty small server.
I'm sure that Microsoft is more than happy to see Corel leaping into dependency on .Net, but it is by no means obvious that Corel ever had a really viable way of making substantial profits from their Linux-related business.
I would point the "death of the dream" back not to anything particularly recent, but rather to the failure of "Corel Computers," where they had the intent to sell (and help support!) hordes of computers. Selling fairly proprietary StrongARM-based hardware is a natural route to creating massive cash flow streams, what with sales, software, and ongoing servicing.
My suspicion is that what went wrong was more "behind the scenes" than it was visible; the core strength of WordPerfect and Corel licensing fee streams was with the Canadian government, negotiated years ago.
The "encroachment" of MS Office on all sides led to trying to come up with a strategy, and selling a "SideWinder" complete with web integration, a need for some proprietary assistance, and Corel Office had, at least theoretically, the ability to hit the mark.
The "WINE" strategy could have been meaningful in pulling additional applications to the table; that's not going to buy huge licensing contracts, but if it gets some SideWinder Sales, that suffices. There was also a "deal" having to do with other ways of "remote running" of Windows apps via something not unlike VNC; again, that doesn't lead to huge licensing fees, but if it sells computers, that's a win.
The WINE situation should be paralleled with the Caldera-related enterprise, Willows, that produced a Win16 emulator called TWIN. They eventually GPLed the product because there just wasn't enough market in selling the library to developers.
Thus, I think Corel was "dead" when the computer experiment fell through. Everything else was the icing that would have attracted people to the "cake" that was to be SideWinder. Today? They're just quibbling over the pieces...
This would be an option if you could get cheap PPC-based motherboards.
If there were cheap PPC motherboards, I'm sure a whole lot more people would run Linux on PPC just out of this being an interesting alternative to Intel and AMD.
But the fact is, there aren't cheap PPC motherboards. You have a choice of buying pretty pricey hardware from Apple, or buying ludicrously pricey hardware from IBM or Motorola.
Selling cheap motherboards isn't a primary business for any of these companies; what's needed is to attract companies like ASUS, GigaByte, Shuttle,...
And they will only seek to sell cheap motherboards if they are quite certain that they can amortize development costs across gazillions of sales.
That only happens if there are VARs and wholesalers prepared to purchase gazillions of cheap PPC motherboards and sell them pretty cheaply. Which requires having a bunch of system vendors.
I seem to remember there being some; Apple basically drove them out of business, thus leaving only the high priced vendors of PPC systems to drive the market for PPC-related hardware.
Note that I never said a word about electricity in any of the above; the only time when vendors start trying to sell people on "power efficient" is when they haven't any more compelling argument to make. I knew Corel Computers was in trouble when they spent much of their marketing material selling the fact that their machines were cheaper to run due to low power consumption.
...is that protecting the company isn't necessarily the best answer for those "non-morons."
If the company is virtually ready to go under, the loss of one person can cause that, and company management is "so competent" that they're not already acting to avert the outcome, this is a real dangerous place to be already.
The best kind of "loyalty" that is available is liable to be the "loyalty" that results in giving good recommendations to those "non-morons" so that when the company gets seriously injured, the people to which you feel loyal are somewhat buffered.
Methinks it's pretty important for there to be "packaged" versions of this deployed in form readily usable with the "desktop" Linux variations.
After all, if the applications happen to be usable on a small screen, they ought to also be pretty good stuff with bigger screen, mouse, and keyboard.
With the bonus that the fact that desktop/server machines have heftier hardware and I/O devices are good places for people to actually do bits of development...
The questions were quite good; the answers were exceptionally good.
This reflects well on all involved, and if it leads to greater interest in TrustedBSD, that's well-deserved!
FreeBSD seems to have a propensity to be more widely used at ISPs where they have networking loads that start getting "challenging."
Those are certainly in a minority as compared to the hordes of "I turned a PC in the back office into a web server" where just about anything more stable than Windows 3.1 represents an improvement.
I like david parson's comment that
"In the free software world, a rising tide DOES lift all boats, and
once the user has tasted Unix it's easy for them to switch between
Unices."
If someone is excitedly moving from watching Blue Screens of Death to Linux, they're likely to be vigorously noisy about that. In contrast, the "excitement" about a move between Linux and *BSD is likely to be far less visible, as the switch is much easier and more nearly transparent. Which doesn't mean that conversions don't take place; just that they're not as loud.
Full-body-gold-plating on an original Cray might, economically, be worth more than the computing power that the machine provides.
If I had a warehouse in which to hold such a thing, and didn't have to pay shipping, it might be feasible to have such a Cray. My Alpha 433 box is probably more powerful, mind you.
It's pretty valid to be a bit schizophrenic about it: On the one hand, that Cray may have cost $10M to build way back when, and it's a shame to waste that; on the other hand, if I can get a machine that's more powerful for $5K today, then I'd stupid to offer more than $5K for the Cray, unless I felt some special sentimentality.
I feel no sentimentality for some Acer set top boxes, so I'm certainly not inclined to overvalue them.
In contrast, I feel a little sentimental towards my Digital Multia; the case engineering is so nice that I keep it around even though it doesn't work anymore. It probably cost $5K to build, and people have literally been giving them away of late.
There's some sort of balance between economic rationality and sentimentality; it's easy to bash it by heading to one extreme or another. Of course, we're talking about Acer set top boxes here, so I doubt sentimentality enters in heavily...
Um, the world isn't quite so simple.
on
PDP-10 Revival
·
· Score: 5
There are, after all, other OSes out there.
The Unix-Haters largely come out of the community of users of Lisp machines, with a few "X haters" that preferred NeXTstep and NeWS;
You probably don't work with mainframe folk; they are pretty desparaging of Unix-like stuff as being "toyish;"
VMS users are a similarly proud (albeit seemingly fading) group that generally aren't big fans of Linux
It's certainly a cool enough "hack" for someone to deploy Linux on one of these machines. It's slightly less challenging, due to the pedestrian choice of x86 family CPU, than, say, running Linux on Sega DreamCast.
The flip side of it is that this is pretty old hardware. I would not pay $100 for one of these units; if it's an AMD K5-133, as seems to be the case, this is basically like a Pentium 75 with 8MB of RAM and no disk.
It's not going to make a great MP3 player; it's certainly not going to provide the CPU horsepower needed to build "something like TiVO."
The iOpener represents more "modern" hardware; ditto for the ThinkNIC. I've actually thrown away newer hardware than this, and I'm hardly near to having 1GHz Athlon boxes going to waste...
The fact that MySQL doesn't have all those funky "relational features" like foreign keys, triggers, rules, and stored procedures means that this sort of "view" is just about perfect.
All those complications that MySQL eschews are the sorts of things that would muss up the idea of viewing "database as FS hierarchy."
And as for the "locking" and "transactional" issues, the point is not terribly different. Filesystems generally don't provide ACID properties; neither does MySQL; that fits together well.
Mind you, it's quite possible that there's a much bigger controversy concerning stability; based on the MySQLFS web page, it appears that they're passing a CORBA IOR into the kernel. What can that possibly mean other than that they're assuming the presence of the "kORBit" implementation in the kernel? The flaming that surrounded "Why don't we try putting an ORB in the Linux kernel?" was much more vigorous than any flaming about MySQL lacking some ACID features!:-).
They're "duals" of one another
on
MySQL FS
·
· Score: 2
In some senses. But they're not exactly isomorphic.
ReiserFS provides a way that you should be able to efficiently build a DB hierarchically as a set of directories and files, where files are the "leaf nodes" that contain field data, and where you might use symbolic links to represent secondary indices.
It would provide pretty "weak typing" of a sort of TCLish style where "everything is a string, sort-of."
In contrast, MySQL provides a way of representing "structured data," with "strongly typed fields." And the filesystem view provides a convenient way of looking at that data.
In effect the ReiserFS approach is to provide a way of building "weakly-typed" hierarchical databases; MySQLFS provides a way of putting a conveniently-browsable hierarchy on top of a strongly-typed relational database.
There are probably a lot of useful applications out there that wouldn't care much about the distinctions. That probably parallels the way that a lot of applications out there don't really care that MySQL does not satisfy the ACID properties or offer triggers, foreign keys, or other such things.
It also might be regarded as parallelling the way that Lisp-like languages have "strongly-typed data" with dynamic typing, which is a bit the way ReiserFS might be used, whilst "MySQLFS" looks a bit more like the "static strong typing" of ML/Haskell. Which is a rather weaker analogy...
In any case, the distinctions between ReiserFS-as-DB and MySQLFS are fairly strong. MySQLFS looks a lot, by the way, like the NameSpace concept in Casbah.
A fair chunk of the "namespace" stuff represents wishful thinking moreso than any realistically expected reality.
The more usual literature on "namespaces" can be found discussed with The Use of Name Spaces in Plan 9. That's actually a quite useful/relevant thing that would represent a really cool thing to add to Linux in the future.
The critical extension is that rather than mount being associated with a "global" filesystem space, where all mounted FSes are associated with /etc/mtab it is associated with a particular hierarchy of processes.
Thus, my user ID might mount a DBM file via something analagous to mount -t dbm/home/cbbrowne/data/something.dbm/n/something ; that presents the DBM file in some sort of filesystem mode under /n/something . Unlike traditional mounting:
It's a "private" mount, visible only to the process that did the mounting and its children;
The mount doesn't require root access.
Alex Viro has occasionally commented on this being a potential neat thing to add to Linux; that's what would make "namespaces" really cool and useful; I don't see it happening 'til Linux 2.7, and it absolutely should not have anything to do with a particular filesystem implementation.
The fact that "blades" are liable to be "dangerously sharp" is a pretty welcome bit of analogy. If you don't know what you're doing, it's easy to chop up things you didn't plan to chop up. "Oops, I really wanted to keep that hand!"
In the 'real world' we see that there aren't a whole vastly lot of manufacturers of knives; while there are a bunch, it doesn't tend to be something that just everyone does. I don't make knives; I buy them.
Heading the point towards ReiserFS, it seems unlikely to me that everyone will be writing "plugins" for ReiserFS. In practice, there will be a few important plugins that will get looked at pretty carefully before deployment:
Something to support more efficient Squid HTTP Cache operations is an almost certain example;
Something to support ATIME-less operations (as is helpful, if memory serves, with news servers) would be a likely example;
I wouldn't be surprised to see someone implement a "plugin" to support building a simple DBMS system (perhaps analagous to DBM) atop ReiserFS.
In much the way that writing kernel code is less convenient than writing user space code, due to the lack of many of the Standard C Library services that people expect to find, writing ReiserFS plugins is likely to be sufficiently "inconvenient" as to discourage "just any moron" from widespread deployment of oddball plugins.
If this was to go into a
STABLE Kernel, shouldn't it have been introduced into the DEVELOPMENT kernels first?
The ReiserFS developers had been tracking 2.3.x kernels for quite a while; they were in the process of auditing the interfaces to the VFS layer at the time that 2.3.x got "frozen" in preparation for release of 2.4.
The fact that this took place rather a long time ago and that there were a serious lot of "pre-2.4.0" versions is a conspicuous fact.
As for the "fighting," it was resolved in two directions:
The first conclusion was that "it's not going into 2.3.frozen-for-2.4"
The second conclusion was that the serious flaming between Alex Viro and Hans Reiser resulted in the ReiserFS team doing a lot of work on interfacing their code "more appropriately" to the Linux VFS layer which has changed significantly in preparation for 2.4.
It should be noted that "vigorous flaming" does not necessarily indicate personal acrimony; there are rather a lot of "spirited words" said around the kernel lists that really are technical comments. If someone thinks that some particular code is severely braindamaged, there is no fear of saying so. If the author, or someone else, fixes it, that's well and fine and may result in the inclusion of what used to be "braindamaged."
The complexity of the sizable and steadily growing group of "competing interests" in the Linux kernel is certainly making it more difficult over time to do major releases. If the process gets much more difficult, that's the sort of thing that is liable to result either in fragmentation or in people deciding to jump over to one of the BSDs or perhaps even to Hurd. Not that that those directions are likely tremendously relevant to the deployment of ReiserFS...
I have been an Egghead customer, and recently saw, and reported, one transaction that appeared to be fraudulent.
It is by no means obvious that the transaction that I saw was, in fact, a result of the Egghead "information emission." It could be the result of something else. The questionable transaction is probably not amongst the 7500 that Egghead reported, so it may be that 7500 is a low figure.
If I were to claim that the "evil transaction" (involving some Moscow-based "telecom" company) was a result of Egghead's emission, that represents a potential falsehood. I cannot be certain that there was any relationship. What is certain is that due to the Egghead report, I scrutinized transactions more carefully than usual, and one appeared prominent as a likely fraudulent transaction.
I don't have direct access to the set of binding and press equipment to produce a nice book. (I haven't been to Kinko's lately; perhaps that is no longer true!)
The thing that the Internet provides is the potential for new, "more direct" ways to sell things.
For instance, if I had a book ready to sell, I could set up an "auction" at EBay, or some such thing, set up an account on PayPal to accept payment, and thereby be fairly readily able to sell 50 copies of something that I might get printed by a "vanity press."
The fact of this making it easier to get access to "obscure titles" means that while there are doubtless losses to people simply "publishing on the 'net," there can be gains where things that would never otherwise have any market can attain one.
The author of Successful Lisp: How to Understand and Use Common Lisp apparently did not succeed at getting a "dead trees" publisher; it would surprise me not at all if he could get a couple hundred copies (of something of a more complete edition of the material) sold out of using a "vanity press." For $30, I'd almost certainly buy a copy, if only to encourage there to be continuance of such literature.
A unified "Ports" tree would almost certainly be helpful to FreeBSD and NetBSD in diminishing duplicated efforts.
On the other hand, for OpenBSD and TrustedBSD, the "fuzzyness" of sharing the code base may make it more difficult to "warrant" the security of packages.
Would it be sensible/preferable to have a "fork" whereby there might be a set of Trusted Ports that would represent a (perhaps limited) set of software that undergoes more comprehensive code auditing, as well as the Unified Ports containing software that hasn't undergone such testing?
In three layer garments the outer shell, GoreTex layer and a fine net lining are all laminated together.
Thus, assuming you have the heavier duty "three layer" version, and it's still breaking down, that seems to me to not be the fault of the GoreTex layer, and not something that replacing GoreTex with something else would solve.
Perhaps they should be using Kevlar or Nomex (well, that's more for fire resistance!) for the outer shell; the point is that it is not likely GoreTex's fault that your clothing breaks down, and replacing it with something "better" without looking at the outer shell isn't going to gain you anything.
The fly in the ointment is that in order for the value to be valid, it should correspond to an income that they are declaring for tax purposes.
Thus:
If they contribute software that they are claiming is worth $10,000, they will have the transaction:
Sale of Software Credit $10,000
Donation Expense Debit $10,000
Which means that while they got a deduction of $10,000, it is irrelevant, as they had to correspondingly have an income of $10,000.
Those are the critical additions to the financial records; the costs already having been borne and deducted.
If they decided to value the software at $1M, then what happens is:
Sale of Software Credit $1M
Donation Expense Debit $1M
Where the impact on taxation is again, nothing, because the $1M donation deduction is balanced by the $1M sale.
In accounting, the debits and credits have to balance. They can play all sorts of games, pushing the incomes and expenses hither and thither, and they still have to have them balance, which means that if they declare the value of the donation to be "too high," some sort of income in that "too high" amount has to come in somewhere.
Note that we could change the numbers again, valuing the donation at $1:
Sale of Software Credit $1
Donation Expense Debit $1
and the impact for tax purposes, due to the balancing out of sale-versus-deduction, is again $0.
In effect, the value they choose should be irrelevant from a tax perspective.
The good reason to inflate the value is to get the potlatch ego boost of being able to claim to have given away gifts of Immense Value.
Unless the IRS provides a way to "double-count" donations, in which case the bigger the number the better...
... But don't they need to declare the income from the "sale" before they give the product away?
I'm not real familiar with IRS rulings; I'm more in tune with the Canadian Income Tax Act. There, the accounting for such a "gift" would have to involve:
Declaring the donation "in kind;"
Declaring an equal and opposite INCOME .
The net result is that no matter how much the donation was, there had to be a corresponding sale that got treated as a donation.
There are still nice opportunities for "benefits" via:
Giving away something where the costs are minimal to nothing, as with giving away last year's version of something where the boxes, docs, and media got expensed last year and where the alternative was likely to "dumpster" it;
Getting the "goodwill" from seeming to do something nice;
Giving away a gift that will keep giving back.
As with software where the charity will have to buy a bunch of licenses two years from now, or risk SPA attacks...
But the point is that "writing off more than the cost of making the contribution" seems unlikely to wash well unless they're actually going to lie to the tax authorities. I expect that the three "secondary benefits" are quite enough to encourage the contributions of software, mind you...
Where's the real advantage, though? Again, good question. As the computer
world changes, and no third party desktop PPC boxes appear, it's getter
harder to answer. I think the real problem here is that there are no real
third-party alternatives for PPC hardware. And that needs to change. Should
IBM's POP board see the light of day, ask me again, and I'll have a different
answer for ya. As I said above, it needs to happen.
Without the third party stuff, without the "cheap motherboards," the PPC stuff is going to continue to get "eaten" by the continually-getting-souped-up IA-32 hardware.
Altivec may be cool stuff; StrongARM and MIPS have their own bits of "coolness," but all are suffering from the "no cheap motherboards" problem. In order to deploy these for substantial applications, you need either to:
Commit to paying for a whole pile of hardware, which means you need to have deep pockets and have Vulture Capitalists willing to trust Motorola and Apple (apparently the case for TiVo), or
Run the risk that the hardware will be obsolete, with no upgrade path.
Which is why Cobalt's newer hardware was using IA-32 rather than MIPS, and why "Rebel Computing" isn't doing too well.
I'd love to see the POP motherboards come out; I'd love to see the F-CPU project get to generating actual silicon, and if they actually produced a board and CPU, I'd almost certainly buy one of those even if it was just a fraction as fast as the latest "Pentium 4." Unfortunately, considerable skepticism is necessary.
The hard thing about SMP is the issue of memory access. You assortedly have:
The need to have buses that allow multiple processors to access the same memory;
The need to have buses to just plain allow access to a bunch of memory to a bunch of processors ;
The need for synchronization logic so the processors don't step on one another.
The latter "bit" is no small matter, and the potential of having a bunch of CPUs on one chip doesn't make these issues go away.
These issues are essentially why AMD (and Cyrix and others) haven't had SMP systems; it's costly to construct the logic necessary to let multiple CPUs play on the same set of memory buses without trampling on one another, and the tradition of AMD/Cyrix being "low end" was just not compatible with spending the money to build that.
I'm still skeptical that there will be any massive movement by AMD towards SMP. And the introduction of some "cool code morphing" from Transmeta doesn't do anything to simplify or otherwise resolve this.
I would think that there could be some pretty slick results from an AMD/Transmeta technology transfer; it's just that SMP doesn't seem high on the list of "obvious cool things."
What this does is to impose significant danger to those that would be cavalier about pretending to ignore the license.
Note that the Linux kernel is a somewhat pathological case in that it has a quite entirely huge number of independent contributors. Which has the implication that if someone takes the cavalier action of ignoring its license, they're not offending one person, but hundreds.
A more logical scenario is for a software package with somewhat fewer contributors.
Let's say GnuCash, where the major contributors amount to maybe a dozen people, some in a role of agent of the "Gnumatic" company. If someone grabbed the sources, and started selling a thinly veiled version, the license arrangement that I outlined might result in the "grabber" being assessed direct damages of maybe a couple hundred thousand dollars, trebled to something under $1M. Plus something for the number of copies of the software sold:-).
That seems to me to be a not unreasonable sort of "damage" to have associated with misuse. It seems reasonable to me to have an "economic stick" associated with this in addition to the "legal stick."
A company may not wish to release their modified version under the GPL; it seems not unreasonable to me for them to be able to, for a significant price, do so.
If Intuit grabbed GnuCash code (not a likely thing to have happen, mind you), I don't think a judge would have any problem with imposing a judgement of a few million dollars.
It may appear to you that a $1B judgement for "ripping off" the Linux kernel seems high; I would
suggest the rather contrary position that with the amount of money NASDAQ investors saw fit to drop into Linux-related enterprises in the last couple years that $1B is not necessarily the slightest bit outrageous.
Supposing Microsoft ripped off OS software from, oh, say, Digital Equipment Corporation, would you find it "outrageous" for there to be a settlement amounting to hundreds of millions of dollars of value? There are some entertaining theories out there surrounding just that sort of scenario that happen not to involve any legal judgements but rather some interesting "negotiated settlements."
In short, most projects wouldn't result in $Billion judgements, and for those that would, such large sums do not seem desparately ludicrous...
Slashdot Mirror
At $1000, they would be a pretty good value.
At $2500, Californians care about the power consumption this week, although if things stabilize in a month, they may not care so much.
For the rest of us, such pricing is daunting unless there's a really compelling application that needs the exact form factor provided.
This is highly unlikely to result in all sorts of people going out and buying these sorts of machines; it's just not economical unless there's a compelling need that justifies paying a couple grand for a pretty small server.
I would point the "death of the dream" back not to anything particularly recent, but rather to the failure of "Corel Computers," where they had the intent to sell (and help support!) hordes of computers. Selling fairly proprietary StrongARM-based hardware is a natural route to creating massive cash flow streams, what with sales, software, and ongoing servicing.
My suspicion is that what went wrong was more "behind the scenes" than it was visible; the core strength of WordPerfect and Corel licensing fee streams was with the Canadian government, negotiated years ago.
The "encroachment" of MS Office on all sides led to trying to come up with a strategy, and selling a "SideWinder" complete with web integration, a need for some proprietary assistance, and Corel Office had, at least theoretically, the ability to hit the mark.
The "WINE" strategy could have been meaningful in pulling additional applications to the table; that's not going to buy huge licensing contracts, but if it gets some SideWinder Sales, that suffices. There was also a "deal" having to do with other ways of "remote running" of Windows apps via something not unlike VNC; again, that doesn't lead to huge licensing fees, but if it sells computers, that's a win.
The WINE situation should be paralleled with the Caldera-related enterprise, Willows, that produced a Win16 emulator called TWIN. They eventually GPLed the product because there just wasn't enough market in selling the library to developers.
Thus, I think Corel was "dead" when the computer experiment fell through. Everything else was the icing that would have attracted people to the "cake" that was to be SideWinder. Today? They're just quibbling over the pieces...
If there were cheap PPC motherboards, I'm sure a whole lot more people would run Linux on PPC just out of this being an interesting alternative to Intel and AMD.
But the fact is, there aren't cheap PPC motherboards. You have a choice of buying pretty pricey hardware from Apple, or buying ludicrously pricey hardware from IBM or Motorola.
Selling cheap motherboards isn't a primary business for any of these companies; what's needed is to attract companies like ASUS, GigaByte, Shuttle, ...
And they will only seek to sell cheap motherboards if they are quite certain that they can amortize development costs across gazillions of sales.
That only happens if there are VARs and wholesalers prepared to purchase gazillions of cheap PPC motherboards and sell them pretty cheaply. Which requires having a bunch of system vendors.
I seem to remember there being some; Apple basically drove them out of business, thus leaving only the high priced vendors of PPC systems to drive the market for PPC-related hardware.
Note that I never said a word about electricity in any of the above; the only time when vendors start trying to sell people on "power efficient" is when they haven't any more compelling argument to make. I knew Corel Computers was in trouble when they spent much of their marketing material selling the fact that their machines were cheaper to run due to low power consumption.
If the company is virtually ready to go under, the loss of one person can cause that, and company management is "so competent" that they're not already acting to avert the outcome, this is a real dangerous place to be already.
The best kind of "loyalty" that is available is liable to be the "loyalty" that results in giving good recommendations to those "non-morons" so that when the company gets seriously injured, the people to which you feel loyal are somewhat buffered.
After all, if the applications happen to be usable on a small screen, they ought to also be pretty good stuff with bigger screen, mouse, and keyboard.
With the bonus that the fact that desktop/server machines have heftier hardware and I/O devices are good places for people to actually do bits of development...
This reflects well on all involved, and if it leads to greater interest in TrustedBSD, that's well-deserved!
FreeBSD seems to have a propensity to be more widely used at ISPs where they have networking loads that start getting "challenging."
Those are certainly in a minority as compared to the hordes of "I turned a PC in the back office into a web server" where just about anything more stable than Windows 3.1 represents an improvement.
I like david parson's comment that
If someone is excitedly moving from watching Blue Screens of Death to Linux, they're likely to be vigorously noisy about that. In contrast, the "excitement" about a move between Linux and *BSD is likely to be far less visible, as the switch is much easier and more nearly transparent. Which doesn't mean that conversions don't take place; just that they're not as loud.If I had a warehouse in which to hold such a thing, and didn't have to pay shipping, it might be feasible to have such a Cray. My Alpha 433 box is probably more powerful, mind you.
It's pretty valid to be a bit schizophrenic about it: On the one hand, that Cray may have cost $10M to build way back when, and it's a shame to waste that; on the other hand, if I can get a machine that's more powerful for $5K today, then I'd stupid to offer more than $5K for the Cray, unless I felt some special sentimentality.
I feel no sentimentality for some Acer set top boxes, so I'm certainly not inclined to overvalue them.
In contrast, I feel a little sentimental towards my Digital Multia; the case engineering is so nice that I keep it around even though it doesn't work anymore. It probably cost $5K to build, and people have literally been giving them away of late.
There's some sort of balance between economic rationality and sentimentality; it's easy to bash it by heading to one extreme or another. Of course, we're talking about Acer set top boxes here, so I doubt sentimentality enters in heavily...
The flip side of it is that this is pretty old hardware. I would not pay $100 for one of these units; if it's an AMD K5-133, as seems to be the case, this is basically like a Pentium 75 with 8MB of RAM and no disk.
It's not going to make a great MP3 player; it's certainly not going to provide the CPU horsepower needed to build "something like TiVO."
The iOpener represents more "modern" hardware; ditto for the ThinkNIC. I've actually thrown away newer hardware than this, and I'm hardly near to having 1GHz Athlon boxes going to waste...
All those complications that MySQL eschews are the sorts of things that would muss up the idea of viewing "database as FS hierarchy."
And as for the "locking" and "transactional" issues, the point is not terribly different. Filesystems generally don't provide ACID properties; neither does MySQL; that fits together well.
Mind you, it's quite possible that there's a much bigger controversy concerning stability; based on the MySQLFS web page, it appears that they're passing a CORBA IOR into the kernel. What can that possibly mean other than that they're assuming the presence of the "kORBit" implementation in the kernel? The flaming that surrounded "Why don't we try putting an ORB in the Linux kernel?" was much more vigorous than any flaming about MySQL lacking some ACID features! :-).
- ReiserFS provides a way that you should be able to efficiently build a DB hierarchically as a set of directories and files, where files are the "leaf nodes" that contain field data, and where you might use symbolic links to represent secondary indices.
- In contrast, MySQL provides a way of representing "structured data," with "strongly typed fields." And the filesystem view provides a convenient way of looking at that data.
In effect the ReiserFS approach is to provide a way of building "weakly-typed" hierarchical databases; MySQLFS provides a way of putting a conveniently-browsable hierarchy on top of a strongly-typed relational database.It would provide pretty "weak typing" of a sort of TCLish style where "everything is a string, sort-of."
There are probably a lot of useful applications out there that wouldn't care much about the distinctions. That probably parallels the way that a lot of applications out there don't really care that MySQL does not satisfy the ACID properties or offer triggers, foreign keys, or other such things.
It also might be regarded as parallelling the way that Lisp-like languages have "strongly-typed data" with dynamic typing, which is a bit the way ReiserFS might be used, whilst "MySQLFS" looks a bit more like the "static strong typing" of ML/Haskell. Which is a rather weaker analogy...
In any case, the distinctions between ReiserFS-as-DB and MySQLFS are fairly strong. MySQLFS looks a lot, by the way, like the NameSpace concept in Casbah.
The more usual literature on "namespaces" can be found discussed with The Use of Name Spaces in Plan 9. That's actually a quite useful/relevant thing that would represent a really cool thing to add to Linux in the future.
The critical extension is that rather than mount being associated with a "global" filesystem space, where all mounted FSes are associated with /etc/mtab it is associated with a particular hierarchy of processes.
Thus, my user ID might mount a DBM file via something analagous to mount -t dbm /home/cbbrowne/data/something.dbm /n/something ; that presents the DBM file in some sort of filesystem mode under /n/something . Unlike traditional mounting:
Alex Viro has occasionally commented on this being a potential neat thing to add to Linux; that's what would make "namespaces" really cool and useful; I don't see it happening 'til Linux 2.7, and it absolutely should not have anything to do with a particular filesystem implementation.
In the 'real world' we see that there aren't a whole vastly lot of manufacturers of knives; while there are a bunch, it doesn't tend to be something that just everyone does. I don't make knives; I buy them.
Heading the point towards ReiserFS, it seems unlikely to me that everyone will be writing "plugins" for ReiserFS. In practice, there will be a few important plugins that will get looked at pretty carefully before deployment:
In much the way that writing kernel code is less convenient than writing user space code, due to the lack of many of the Standard C Library services that people expect to find, writing ReiserFS plugins is likely to be sufficiently "inconvenient" as to discourage "just any moron" from widespread deployment of oddball plugins.
The ReiserFS developers had been tracking 2.3.x kernels for quite a while; they were in the process of auditing the interfaces to the VFS layer at the time that 2.3.x got "frozen" in preparation for release of 2.4.
The fact that this took place rather a long time ago and that there were a serious lot of "pre-2.4.0" versions is a conspicuous fact.
As for the "fighting," it was resolved in two directions:
It should be noted that "vigorous flaming" does not necessarily indicate personal acrimony; there are rather a lot of "spirited words" said around the kernel lists that really are technical comments. If someone thinks that some particular code is severely braindamaged, there is no fear of saying so. If the author, or someone else, fixes it, that's well and fine and may result in the inclusion of what used to be "braindamaged."
The complexity of the sizable and steadily growing group of "competing interests" in the Linux kernel is certainly making it more difficult over time to do major releases. If the process gets much more difficult, that's the sort of thing that is liable to result either in fragmentation or in people deciding to jump over to one of the BSDs or perhaps even to Hurd. Not that that those directions are likely tremendously relevant to the deployment of ReiserFS...
It is by no means obvious that the transaction that I saw was, in fact, a result of the Egghead "information emission." It could be the result of something else. The questionable transaction is probably not amongst the 7500 that Egghead reported, so it may be that 7500 is a low figure.
If I were to claim that the "evil transaction" (involving some Moscow-based "telecom" company) was a result of Egghead's emission, that represents a potential falsehood. I cannot be certain that there was any relationship. What is certain is that due to the Egghead report, I scrutinized transactions more carefully than usual, and one appeared prominent as a likely fraudulent transaction.
The thing that the Internet provides is the potential for new, "more direct" ways to sell things.
For instance, if I had a book ready to sell, I could set up an "auction" at EBay, or some such thing, set up an account on PayPal to accept payment, and thereby be fairly readily able to sell 50 copies of something that I might get printed by a "vanity press."
The fact of this making it easier to get access to "obscure titles" means that while there are doubtless losses to people simply "publishing on the 'net," there can be gains where things that would never otherwise have any market can attain one.
The author of Successful Lisp: How to Understand and Use Common Lisp apparently did not succeed at getting a "dead trees" publisher; it would surprise me not at all if he could get a couple hundred copies (of something of a more complete edition of the material) sold out of using a "vanity press." For $30, I'd almost certainly buy a copy, if only to encourage there to be continuance of such literature.
On the other hand, for OpenBSD and TrustedBSD, the "fuzzyness" of sharing the code base may make it more difficult to "warrant" the security of packages.
Would it be sensible/preferable to have a "fork" whereby there might be a set of Trusted Ports that would represent a (perhaps limited) set of software that undergoes more comprehensive code auditing, as well as the Unified Ports containing software that hasn't undergone such testing?
I should file as a co-plaintiff, and maybe "make my millions" of this case???
See Gear Views;
Thus, assuming you have the heavier duty "three layer" version, and it's still breaking down, that seems to me to not be the fault of the GoreTex layer, and not something that replacing GoreTex with something else would solve.
Perhaps they should be using Kevlar or Nomex (well, that's more for fire resistance!) for the outer shell; the point is that it is not likely GoreTex's fault that your clothing breaks down, and replacing it with something "better" without looking at the outer shell isn't going to gain you anything.
Thus: If they contribute software that they are claiming is worth $10,000, they will have the transaction:
Sale of Software Credit $10,000
Donation Expense Debit $10,000
Which means that while they got a deduction of $10,000, it is irrelevant, as they had to correspondingly have an income of $10,000.
Those are the critical additions to the financial records; the costs already having been borne and deducted.
If they decided to value the software at $1M, then what happens is:
Sale of Software Credit $1M
Donation Expense Debit $1M
Where the impact on taxation is again, nothing, because the $1M donation deduction is balanced by the $1M sale.
In accounting, the debits and credits have to balance. They can play all sorts of games, pushing the incomes and expenses hither and thither, and they still have to have them balance, which means that if they declare the value of the donation to be "too high," some sort of income in that "too high" amount has to come in somewhere.
Note that we could change the numbers again, valuing the donation at $1:
Sale of Software Credit $1
Donation Expense Debit $1
and the impact for tax purposes, due to the balancing out of sale-versus-deduction, is again $0.
In effect, the value they choose should be irrelevant from a tax perspective.
The good reason to inflate the value is to get the potlatch ego boost of being able to claim to have given away gifts of Immense Value.
Unless the IRS provides a way to "double-count" donations, in which case the bigger the number the better...
I'm not real familiar with IRS rulings; I'm more in tune with the Canadian Income Tax Act. There, the accounting for such a "gift" would have to involve:
- Declaring the donation "in kind;"
- Declaring an equal and opposite INCOME .
The net result is that no matter how much the donation was, there had to be a corresponding sale that got treated as a donation.There are still nice opportunities for "benefits" via:
- Giving away something where the costs are minimal to nothing, as with giving away last year's version of something where the boxes, docs, and media got expensed last year and where the alternative was likely to "dumpster" it;
- Getting the "goodwill" from seeming to do something nice;
- Giving away a gift that will keep giving back.
But the point is that "writing off more than the cost of making the contribution" seems unlikely to wash well unless they're actually going to lie to the tax authorities. I expect that the three "secondary benefits" are quite enough to encourage the contributions of software, mind you...As with software where the charity will have to buy a bunch of licenses two years from now, or risk SPA attacks...
Altivec may be cool stuff; StrongARM and MIPS have their own bits of "coolness," but all are suffering from the "no cheap motherboards" problem. In order to deploy these for substantial applications, you need either to:
- Commit to paying for a whole pile of hardware, which means you need to have deep pockets and have Vulture Capitalists willing to trust Motorola and Apple (apparently the case for TiVo), or
- Run the risk that the hardware will be obsolete, with no upgrade path.
I'd love to see the POP motherboards come out; I'd love to see the F-CPU project get to generating actual silicon, and if they actually produced a board and CPU, I'd almost certainly buy one of those even if it was just a fraction as fast as the latest "Pentium 4." Unfortunately, considerable skepticism is necessary.Which is why Cobalt's newer hardware was using IA-32 rather than MIPS, and why "Rebel Computing" isn't doing too well.
And yes, I think this would be a really good idea.
The latter "bit" is no small matter, and the potential of having a bunch of CPUs on one chip doesn't make these issues go away.
These issues are essentially why AMD (and Cyrix and others) haven't had SMP systems; it's costly to construct the logic necessary to let multiple CPUs play on the same set of memory buses without trampling on one another, and the tradition of AMD/Cyrix being "low end" was just not compatible with spending the money to build that.
I'm still skeptical that there will be any massive movement by AMD towards SMP. And the introduction of some "cool code morphing" from Transmeta doesn't do anything to simplify or otherwise resolve this.
I would think that there could be some pretty slick results from an AMD/Transmeta technology transfer; it's just that SMP doesn't seem high on the list of "obvious cool things."
Note that the Linux kernel is a somewhat pathological case in that it has a quite entirely huge number of independent contributors. Which has the implication that if someone takes the cavalier action of ignoring its license, they're not offending one person, but hundreds.
A more logical scenario is for a software package with somewhat fewer contributors.
Let's say GnuCash, where the major contributors amount to maybe a dozen people, some in a role of agent of the "Gnumatic" company. If someone grabbed the sources, and started selling a thinly veiled version, the license arrangement that I outlined might result in the "grabber" being assessed direct damages of maybe a couple hundred thousand dollars, trebled to something under $1M. Plus something for the number of copies of the software sold :-).
That seems to me to be a not unreasonable sort of "damage" to have associated with misuse. It seems reasonable to me to have an "economic stick" associated with this in addition to the "legal stick."
A company may not wish to release their modified version under the GPL; it seems not unreasonable to me for them to be able to, for a significant price, do so.
If Intuit grabbed GnuCash code (not a likely thing to have happen, mind you), I don't think a judge would have any problem with imposing a judgement of a few million dollars.
It may appear to you that a $1B judgement for "ripping off" the Linux kernel seems high; I would suggest the rather contrary position that with the amount of money NASDAQ investors saw fit to drop into Linux-related enterprises in the last couple years that $1B is not necessarily the slightest bit outrageous.
Supposing Microsoft ripped off OS software from, oh, say, Digital Equipment Corporation, would you find it "outrageous" for there to be a settlement amounting to hundreds of millions of dollars of value? There are some entertaining theories out there surrounding just that sort of scenario that happen not to involve any legal judgements but rather some interesting "negotiated settlements."
In short, most projects wouldn't result in $Billion judgements, and for those that would, such large sums do not seem desparately ludicrous...