And the main Multics systems known to still be operational is at my brother's "office," DND: Maritime Command, in Halifax, reportedly planned to be decommissioned next June.
VA may not be marketing low end machines; the increasing availability of USB hardware is nonetheless likely to start making some of the non-USB hardware get "a bit rarer."
It thus may not matter to them today, but might be of greater importance by late 2000. Note that I mentioned several companies that may not all feel they have an immediate stake in USB; they all do have an interest in increased adoption of Linux, and will ultimately be injured if availability of USB hardware gets widespread whilst Linux support remains limited.
Yes, it's evident that SuSE is supporting USB; hopefully we'll see better support come over time. I wouldn't mind seeing USB take off as an alternative to the hard-to-tie-down RS-232, and if it "takes out" ISA at the same time, I will not shed many tears.
It would be a shame if it didn't integrate well with XFree86 4.0; that would mean that any extras, whether DGA or other X extensions, would have to be developed and maintained by them.
The consideration that XFree86 4.0 is to be "more modular" will either encourage production of proprietary modules, or downright discourage it, if there need to be some reasonably intimate links between modules. My hope is on discourage.
Hopefully RAM prices will come back down; if XFree86/OpenGL support for some not-too-expensive 32MB cards comes along, I might consider one in the new year some time...
There's starting to be useful USB support; Linux USB lists various aspects of support that are coming along reasonably well now.
The Table of known working devices is growing, and the major classes of devices that aren't working yet are speakers. And it's not clear what's up with modems and NICs, which I'm seeing in stores, but no note of Linux support.
At any rate, from the recent groundswell of support, I expect that by the time the "reduced mobos" come out, there should be even better USB support than there is now. It's certainly in the interests of (SuSE|RHAT|VA-LINUX|Lineo|...) to make sure they get supported...
As has been noted by many over the last year, the lower that PC hardware prices go, the more this magnifies any fixed portions of the costs.
In particular, a $75 OEM Windows 98 license that looks like "fiscal noise" when the computer cost $1500 and sold for $2000 starts looking pretty hefty when the computer sells for $400.
Of course, if Microsoft tries to eliminate "Windows 9x" in favor of the Windows 2000 pricing, that looks rather more like buying Windows NT Server at full price, this makes the OS cost more than the computer.
It's no shock that manufacturers would start looking more seriously at license-fee-free things like Linux in these sorts of circumstances...
I suggested using a "subversive" document, to annoy would-be analysts.
Better still would be to use the Bible as the text onto which messages would be layered.
The Bible is a fairly long document, with lots of semi-repeated substrings, thus providing a lot of useful material for building a dictionary of substrings.
The material that you would get out of this would look more like a rambling Bible study than anything else.
The "Bad Guys" might think you're a religious crank; raving a bit, but harmless.
The Bible actually is a tremendously subsersive book. Many totalitarian regimes have considered it highly dangerous.
The Bible is widely available, and quoting bits of it, or things that look like bits of it, isn't particularly unusual.
This kind of amounts to a reverse form of Bible Codes analysis... There are cranks out there that think that God put special "codes" into the Bible that they can analyze; using the Bible in this way produces documents that are "Biblical" that actually do contain special codes.
If people post .signatures that contain "spooky" words, or have news header line like X-NSA-Fodder: guns cuba NSA president assassination This represents stuff that is pretty easy to filter out.
The same is true if some people send "terminologically-enhanced email" around in quantity; some analyst is reasonably likely to notice it, and find some way of filtering it to some degree.
What would be more likely to cause consternation would be to have larger quantities of encrypted traffic. If, for instance, CVS and FTP archives started using GPG to encrypt all file transfer information in transit, this would cause more traffic where it may make it hard to tell if it's suspicious or not.
The entertaining option would be to use something like unto stenography...
This would involve taking "raw" messages, compressing and encrypting them using something like Blowfish. And then transforming them into masses of "dangerous terminology," compressing and maybe again encrypting that, and then transmitting this.
Thus, if we start with message "M," we do: % cat M | gzip - | blowfish -e -k "tata, NSA" > N We now have a file, N, that's hopefully small, and reasonably encrypted.
Now, pass it through a transformation where we turn it into a sequence of "dangerous words." The simplest option looks like:
ASCII 0 maps to "NSA"
ASCII 1 maps to "President"
ASCII 3 maps to "Ortega"
ASCII 4 maps to "Semtex"
and so forth...
The obvious answer here is to pick the 256 best "dangerous words;" having only 64 would amount to a perverse equivalent to Base64 encoding; having 4000 words makes life more entertaining.
Another alternative would be not to pick words, but rather to pick phrases in some manner from some controversial essays/books, so that we're not merely getting random words, but rather sets of words that go together to appear to be in a vaguely meaningful sequence. Information Retrieval: Algorithms and Data Structures might have something to offer here. The idea is to pick from the ways that words were phrased in some text, so that the results at least vaguely look like something one might write.
You'll then get the original 500 byte message to expand out to something like 50K of "steganography." Fortunately, that 50K will be highly compressible English text. (Unless, of course, you picked some subversive book written in Russian as the "steganographic dictionary," in which case it'll be 50K of highly compressible Russian text.)
Compress again, encrypt into submission, and send that CVS patch over to the GnuCash archives...
terrorist Marxist FSF North Korea security South Africa nuclear DES Semtex KGB FBI Noriega colonel NSA SEAL Team 6 nuclear Ortega PLO supercomputer Treasury terrorist assassination Semtex [Hello to all my fans in domestic surveillance] Serbian fissionable FBI spy arrangements Kennedy Noriega cracking Nazi Ft. Meade Marxist Waco, Texas cryptographic genetic Cocaine jihad
In order for Linux, MIPS, Cray, and NVidia efforts to turn out, lots needs to happen:
SGI needs to actually get revenue streams from selling Linux-oriented hardware, or from selling training programs. On the training side, they seem to truly be putting in some real effort; the hardware side is far less clear.
It would be a cool idea to have cheap MIPS-based Linux boxes; I'd love to see a Linux for Nintendo 64 much like the IX "April Fools" article of 1997.
Unfortunately, this isn't a substantial profit centre for SGI, as they probably only make a few bucks per farmed-out MIPS CPU. To turn this into significant help, there need to be millions of CPUs being sold for this purpose, and I just don't see that happening.
What to do about Cray?
This looked like a useful synergy; Cray didn't have the quantity of sales to allow development of all the hardware they needed, and if SGI could use some of it in other product lines, that could make the costs more readily amortized, and even improve performance on SGI's "own" product lines.
I suspect Cray holds a bunch of critical patents on computer hardware for HPC; killer question is who's going to want to buy, when SGI couldn't make the synergies work...
NVidia looks a whole lot more like an organ donation than anything else; there's only just so much money SGI can get out of the deal, and if it makes NVidia hardware more competitive with SGI hardware, this can diminish the deployment of SGI's hardware. Looks dangerous to me.
Yes, that probably is a useful form of "Anonymous Coward."
If you look at one of the threads that my comments spawned, there's some opportunity for such... One AC commented on the Henry Spencer quote that I use as.signature, suggesting essentially that "Using UNIX, not Lisp" has set computing back ten years. I can play both sides of that one, to some extent, as I'm involved with writing Lisp code for GnuCash, and my "contribution of the week" has been to figure out how to make Guile hash tables Generally Useful. (Guile doesn't have a (hash-for-each FUNCTION TABLE) function; I wrote one that runs in reasonably-close-to-linear time, which probably ought to wander both to GnuCash as well as to the Guile developers...)
It surely would be difficult to contribute usefully to a discussion when playing multiple roles.
There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.
That may mean that a more valid claim would be more like
Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.
That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.
I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.
There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.
That may mean that a more valid claim would be more like
Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.
That still does not deny that what is in my .signature is what Henry Spencer said.
I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.
Unfortunately, when they're Anonymous Cowards, it gets a bit harder to tell if you've got:
Someone that is being honest, that has known biases
Someone that is being dishonest, with well-known biases
Someone that is being honest, but where you can only infer indirectly what their biases are, or
Someone that is being downright dishonest, and perhaps trying to hide their biases.
Unfortunately, as you head down this list, there is a tendancy for honesty to diminish, as well as the usefulness of the information.
The issue isn't new; it was pretty evident in some reviews of LinuxCAD, that there were "reviewers" that may not have been at arms length from the "producers." Another review notes, about the "testimonials," that:
Strangely, these testimonials used the same poor english expression as whoever wrote the LinuxCAD advertisement.
much (most?) of the software that the Debian team puts in the DebianBSD distribution would still be GPL, which means FastBuck Inc. would not be able to take DebianBSD as-is and apply a closed-source license.
Good call; that does indeed prevent someone from releasing a proprietary edition, as even if the kernel and libc use BSDL, the necessary GPLed content (notably dpkg and related Debian tools) deny the problems of concern.
This is better than the opposite observation that I was going to point out, which is that there are components of Debian, such as Perl, Python, and XFree86 that already use non-GPL-like licenses.
In other words, UNIX scares people because it's supposedly hard to use.
On the up side, that scares away the ludicrously incompetent
Also on the up side, the expectation of difficulty/complexity means that people expect there to be some difficulty in figuring things out.
When the situation (e.g. - independent of the OS in place) happens to be difficult/complex, this then doesn't phaze anybody, as they were prepared for there to be some difficulty.
In contrast, those that expect hugs and kisses and simplicity because they're deploying NT run into opposite problems:
Because it's supposed to be "easy to use," any idiot ought to be able to administer NT, and unfortunately, that sometimes gets taken literally, resulting in the disaster of an idiot trying to run a complex system.
Because NT is supposed to be "easy to use," true complexities in the system deployment may get glossed over, thus providing roadblocks later on.
As for the author's efforts at writing science fiction, it sounds like a case where you hope many of his neighbours are MSFT-critters, so that if his characters come for a meal, few will feel worried about it...
Having FreeBSD added to the set of OSes supported by Debian doesn't prevent support for Hurd from continuing. Indeed, the sets of people interested in Debian atop FreeBSD and Debian atop Hurd are likely to be virtually disjoint sets.
A significant merit to adding FreeBSD to the mix is that this makes Debian less and less kernel-dependent. In the long run, that makes it more and more possible for Debian to support more "UNIX variants."
Interesting, in the longer run, would be:
Something based on FluxOS
Something based on Fiasco/L4
The oft-discussed EROS
Perhaps MIT's XOS
Thus, support for FreeBSD tomorrow may help there to be support for more unusual OS selections a couple years from now.
It's possible; the more recent Windows stuff doesn't merely use the Win32 API, but rather use COM components, that may tie applications more tightly to needing Microsoft code there.
On the other hand, there is a sizable body of applications that need to be able to run on all of:
Windows 95
Windows 98
Windows NT 3.51
Windows NT 4.0
Windows 2000
...which all have slightly different variations on what forms of Win32 and COM that they support.
This actually makes it more possible to build a decent emulation; if Microsoft changes the APIs too much, particularly in the direction of "breaking if you're not doing things exactly the way we want you to today," this will break code that already needs to run on four (or more) distinct Microsoft platforms.
It wouldn't do to assume that this makes it necessarily easy to track MSFT changes, but it is certainly the case that it gets harder over time for MSFT to make changes.
The cool thing about WINE is that it potentially provides a way for some of that "bad old Windows code" to get redeployed using libWine to run natively on a UNIX. Obviously with some uncertainty as to the likelihood of that turning into billions of lines of UNIX-based apps...
Doesn't mention WINE, because it's not like WINE
on
Corel Dropping WINE?
·
· Score: 2
GraphOn's "Bridge" is not a Windows emulator.
It's a way of allowing one to display remotely Windows applications.
That means that in order to use it, you have to have two boxes:
An NT box, running a GraphOn "NT Service," which will run the application you want to run, and
A Linux/UNIX box, with a GraphOn "Display Server," that will display the output from the application that's running on the NT server.
This is not an emulation; you require an NT box on which to run the application. No emulation involved.
It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?
The article does not indicate anything about WINE being downright eliminated, only that the GraphOn software will get added in.
It is not self-evident that WINE becomes of no value; a major value to WINE to Corel should in permitting Win32 software to be recompiled using libwine so that they may be deployed as native Linux applications.
In contrast, the GraphOn Linux Client to Bridges software is not a tool to allow Windows software to run on Linux; it is merely a tool to allow Windows software to run on Windows NT, and then display on Linux.
The new Linux client runs Windows applications remotely
Essentially, this provides the same sort of functionality as the Citrix ICA protocol, or Microsoft's Hydra.
There are locals that will be quite trustworthy; there are locals with shifty eyes; ditto for mail order folk.
The part that is illegal is the vendor is making claims in advertising that are verifiably false. Unfortunately, they can write some fairly "sharp" things that are misleading, but not actually false.
The utility is definitely good for Intel, as it can provide them information that can allow them to pursue people that are overclocking or misreporting things. That can work for both good and for ill...
I certainly agree that it is immensely unlikely that magazines will go away altogether; after all, there is still continuing to be growth of them even now.
The prediction of their demise is premature, although not implausible; consider that newspapers have not been seeing big growth lately.
Magazines should, nonetheless, still remain for quite some time now.
The point to this thread is not that of when "magazines go away;" it is about:
What sorts of magazines can persist?
In the Linux realm, there are presently Linux Journal, Linux Magazine, and Maximum Linux. One good question is of which ones of these will still be around in a couple of years.
We've seen Byte Magazine go through "phases," including a period of "going out of business."
What sorts of magazines would it be nice to have?
Personally, I see little value to the Maximum Linuxes of this world. I look back with some longing to ancient byte of the '70s and early '80s. I look back with some regret at the failure of Micro Cornucopia. (Few will remember it.)
In the long run, magazines may be a "dead" concept, but as Lord Keynes said, "In the long run we're all dead." The point is to try to assess which magazines are likely to rise and fall between now and then, as well as which magazines we might like to see rise.
It looks quite possible that there was an actual fraud, namely a tax evasion scheme against the US government whereby UPS funnelled funds to Bermuda likely avoiding US taxation on such funds.
A Tax Court judge ruled that UPS set up a Bermuda-based corporation as an insurance company to avoid paying income taxes. The judge found that UPS must pay taxes on the money sent to the Bermuda company.
That means that the Tax Court considered that they owed the IRS some money.
The connection to the customers, on the other hand, seems rather more tenuous. Reading the article, it indicates that
the company was self-insured
The notion of "self-insurance" is quite common for extremely huge organizations where they figure that they have such a huge number of potential sources of claims that it makes sense to keep the insurance money and pay the costs of claims as they come up.
For instance, it is reasonably possible that IBM doesn't insure their buildings against fire damage. If they did, they might pay $100M per year for the insurance, and with the diversity of their real estate holdings, they might find that paying for fire repairs out of their own pockets would only cost $70M. Note, that means that it's cheaper for them to pay for repairs after some big fires.
Similarly, my own employer requires that if employees rent cars when travelling that we not pay LDW insurance; that costs $15-odd dollars per day, and with 120,000 of us, that can add up to Rather A Lot. It's cheaper for them to "self-insure," salting away some portion of the $15/day, and paying collision repairs directly on those occasions when accidents happen.
UPS appears to have been doing the same thing; they kept the "insurance" fees and paid for losses when losses were incurred.
It appears that once the case hit the tax court, lean and hungry lawyers noticed the case, and perhaps decided that they could probably confuse a jury into believing that self insurance is effectively a way lf "defrauding consumers."
Slashdot Mirror
And the main Multics systems known to still be operational is at my brother's "office," DND: Maritime Command, in Halifax, reportedly planned to be decommissioned next June.
It thus may not matter to them today, but might be of greater importance by late 2000. Note that I mentioned several companies that may not all feel they have an immediate stake in USB; they all do have an interest in increased adoption of Linux, and will ultimately be injured if availability of USB hardware gets widespread whilst Linux support remains limited.
Yes, it's evident that SuSE is supporting USB; hopefully we'll see better support come over time. I wouldn't mind seeing USB take off as an alternative to the hard-to-tie-down RS-232, and if it "takes out" ISA at the same time, I will not shed many tears.
The consideration that XFree86 4.0 is to be "more modular" will either encourage production of proprietary modules, or downright discourage it, if there need to be some reasonably intimate links between modules. My hope is on discourage.
Hopefully RAM prices will come back down; if XFree86/OpenGL support for some not-too-expensive 32MB cards comes along, I might consider one in the new year some time...
The Table of known working devices is growing, and the major classes of devices that aren't working yet are speakers. And it's not clear what's up with modems and NICs, which I'm seeing in stores, but no note of Linux support.
At any rate, from the recent groundswell of support, I expect that by the time the "reduced mobos" come out, there should be even better USB support than there is now. It's certainly in the interests of (SuSE|RHAT|VA-LINUX|Lineo|...) to make sure they get supported...
In particular, a $75 OEM Windows 98 license that looks like "fiscal noise" when the computer cost $1500 and sold for $2000 starts looking pretty hefty when the computer sells for $400.
Of course, if Microsoft tries to eliminate "Windows 9x" in favor of the Windows 2000 pricing, that looks rather more like buying Windows NT Server at full price, this makes the OS cost more than the computer.
It's no shock that manufacturers would start looking more seriously at license-fee-free things like Linux in these sorts of circumstances...
Better still would be to use the Bible as the text onto which messages would be layered.
The "Bad Guys" might think you're a religious crank; raving a bit, but harmless.
This kind of amounts to a reverse form of Bible Codes analysis... There are cranks out there that think that God put special "codes" into the Bible that they can analyze; using the Bible in this way produces documents that are "Biblical" that actually do contain special codes.
The same is true if some people send "terminologically-enhanced email" around in quantity; some analyst is reasonably likely to notice it, and find some way of filtering it to some degree.
What would be more likely to cause consternation would be to have larger quantities of encrypted traffic. If, for instance, CVS and FTP archives started using GPG to encrypt all file transfer information in transit, this would cause more traffic where it may make it hard to tell if it's suspicious or not.
The entertaining option would be to use something like unto stenography...
This would involve taking "raw" messages, compressing and encrypting them using something like Blowfish. And then transforming them into masses of "dangerous terminology," compressing and maybe again encrypting that, and then transmitting this.
Thus, if we start with message "M," we do: % cat M | gzip - | blowfish -e -k "tata, NSA" > N We now have a file, N, that's hopefully small, and reasonably encrypted.
Now, pass it through a transformation where we turn it into a sequence of "dangerous words." The simplest option looks like:
The obvious answer here is to pick the 256 best "dangerous words;" having only 64 would amount to a perverse equivalent to Base64 encoding; having 4000 words makes life more entertaining.
Another alternative would be not to pick words, but rather to pick phrases in some manner from some controversial essays/books, so that we're not merely getting random words, but rather sets of words that go together to appear to be in a vaguely meaningful sequence. Information Retrieval: Algorithms and Data Structures might have something to offer here. The idea is to pick from the ways that words were phrased in some text, so that the results at least vaguely look like something one might write.
You'll then get the original 500 byte message to expand out to something like 50K of "steganography." Fortunately, that 50K will be highly compressible English text. (Unless, of course, you picked some subversive book written in Russian as the "steganographic dictionary," in which case it'll be 50K of highly compressible Russian text.)
Compress again, encrypt into submission, and send that CVS patch over to the GnuCash archives...
terrorist Marxist FSF North Korea security South Africa nuclear DES Semtex KGB FBI Noriega colonel NSA SEAL Team 6 nuclear Ortega PLO supercomputer Treasury terrorist assassination Semtex [Hello to all my fans in domestic surveillance] Serbian fissionable FBI spy arrangements Kennedy Noriega cracking Nazi Ft. Meade Marxist Waco, Texas cryptographic genetic Cocaine jihad
Unfortunately, this isn't a substantial profit centre for SGI, as they probably only make a few bucks per farmed-out MIPS CPU. To turn this into significant help, there need to be millions of CPUs being sold for this purpose, and I just don't see that happening.
This looked like a useful synergy; Cray didn't have the quantity of sales to allow development of all the hardware they needed, and if SGI could use some of it in other product lines, that could make the costs more readily amortized, and even improve performance on SGI's "own" product lines.
I suspect Cray holds a bunch of critical patents on computer hardware for HPC; killer question is who's going to want to buy, when SGI couldn't make the synergies work...
If you look at one of the threads that my comments spawned, there's some opportunity for such... One AC commented on the Henry Spencer quote that I use as .signature, suggesting essentially that "Using UNIX, not Lisp" has set computing back ten years. I can play both sides of that one, to some extent, as I'm involved with writing Lisp code for GnuCash, and my "contribution of the week" has been to figure out how to make Guile hash tables Generally Useful. (Guile doesn't have a (hash-for-each FUNCTION TABLE) function; I wrote one that runs in reasonably-close-to-linear time, which probably ought to wander both to GnuCash as well as to the Guile developers...)
It surely would be difficult to contribute usefully to a discussion when playing multiple roles.
It's what Henry Spencer said.
It's widely known.
There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.
That may mean that a more valid claim would be more like
That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.
I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.
If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.
It's what Henry Spencer said.
It's widely known.
There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.
That may mean that a more valid claim would be more like
That still does not deny that what is in my .signature is what Henry Spencer said.
I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.
If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.
Unfortunately, when they're Anonymous Cowards, it gets a bit harder to tell if you've got:
Unfortunately, as you head down this list, there is a tendancy for honesty to diminish, as well as the usefulness of the information.
The issue isn't new; it was pretty evident in some reviews of LinuxCAD, that there were "reviewers" that may not have been at arms length from the "producers." Another review notes, about the "testimonials," that:
It was quite entertaining when Linux Gazette published an Official Reaction of Software Forge Inc. to "LinuxCAD Review"; I expressed in LG issue 42 that I appreciated their restraint in not using a spell-checker...
No, I haven't much use for Anonymous Cowards...
This is better than the opposite observation that I was going to point out, which is that there are components of Debian, such as Perl, Python, and XFree86 that already use non-GPL-like licenses.
- On the up side, that scares away the ludicrously incompetent
- Also on the up side, the expectation of difficulty/complexity means that people expect there to be some difficulty in figuring things out.
In contrast, those that expect hugs and kisses and simplicity because they're deploying NT run into opposite problems:When the situation (e.g. - independent of the OS in place) happens to be difficult/complex, this then doesn't phaze anybody, as they were prepared for there to be some difficulty.
As for the author's efforts at writing science fiction, it sounds like a case where you hope many of his neighbours are MSFT-critters, so that if his characters come for a meal, few will feel worried about it...
A significant merit to adding FreeBSD to the mix is that this makes Debian less and less kernel-dependent. In the long run, that makes it more and more possible for Debian to support more "UNIX variants."
Interesting, in the longer run, would be:
Thus, support for FreeBSD tomorrow may help there to be support for more unusual OS selections a couple years from now.
That seems to me to be a Good Thing.
I am familiar with TAO, and with ILU, and certainly know of MICO and omniORB. I suggest taking a look at the GnuPaghe Project; they went through an ORB selection process, and waffled back and forth between TAO and MICO, leaning back towards MICO because of compile time memory consumption. The finding on TAO was thus: Huge at compile time; I haven't done precise measures, yet it surely eats about 700 Mb while compiling it. This may be an exaggeration on the hugeness of TAO; there have certainly been similar reports on MICO. I've compiled some bits of ORBit code, and found it fairly appalling how 1K of IDL turned into compiled object code a hundred K or so in size; for C++-based stuff to be more lardly is not too much of a surprise. If it takes 128MB of memory to compile Hello, World! that can represent a significant barrier to the widespread adoption of CORBA.
On the other hand, there is a sizable body of applications that need to be able to run on all of:
This actually makes it more possible to build a decent emulation; if Microsoft changes the APIs too much, particularly in the direction of "breaking if you're not doing things exactly the way we want you to today," this will break code that already needs to run on four (or more) distinct Microsoft platforms.
It wouldn't do to assume that this makes it necessarily easy to track MSFT changes, but it is certainly the case that it gets harder over time for MSFT to make changes.
The cool thing about WINE is that it potentially provides a way for some of that "bad old Windows code" to get redeployed using libWine to run natively on a UNIX. Obviously with some uncertainty as to the likelihood of that turning into billions of lines of UNIX-based apps...
It's a way of allowing one to display remotely Windows applications.
That means that in order to use it, you have to have two boxes:
This is not an emulation; you require an NT box on which to run the application. No emulation involved.
That appears to be the Qt Way of handling printing.
It is interesting to contrast with other methods that have been used historically and recently:
It is not clear whether or not KDE is using the QtPainter facility, or whether there is need for something like GNOME Canvas...
It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?
What comes to mind are:
It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.
The article does not indicate anything about WINE being downright eliminated, only that the GraphOn software will get added in.
It is not self-evident that WINE becomes of no value; a major value to WINE to Corel should in permitting Win32 software to be recompiled using libwine so that they may be deployed as native Linux applications.
In contrast, the GraphOn Linux Client to Bridges software is not a tool to allow Windows software to run on Linux; it is merely a tool to allow Windows software to run on Windows NT, and then display on Linux.
Essentially, this provides the same sort of functionality as the Citrix ICA protocol, or Microsoft's Hydra.
What is particularly distressing is that this supports the GraphOn Patent for Remoting Windows Applications. But that does not appear to have anything to do with WINE...
The part that is illegal is the vendor is making claims in advertising that are verifiably false. Unfortunately, they can write some fairly "sharp" things that are misleading, but not actually false.
The utility is definitely good for Intel, as it can provide them information that can allow them to pursue people that are overclocking or misreporting things. That can work for both good and for ill...
The prediction of their demise is premature, although not implausible; consider that newspapers have not been seeing big growth lately.
Magazines should, nonetheless, still remain for quite some time now.
The point to this thread is not that of when "magazines go away;" it is about:
In the Linux realm, there are presently Linux Journal, Linux Magazine, and Maximum Linux. One good question is of which ones of these will still be around in a couple of years.
We've seen Byte Magazine go through "phases," including a period of "going out of business."
Personally, I see little value to the Maximum Linuxes of this world. I look back with some longing to ancient byte of the '70s and early '80s. I look back with some regret at the failure of Micro Cornucopia. (Few will remember it.)
In the long run, magazines may be a "dead" concept, but as Lord Keynes said, "In the long run we're all dead." The point is to try to assess which magazines are likely to rise and fall between now and then, as well as which magazines we might like to see rise.
The connection to the customers, on the other hand, seems rather more tenuous. Reading the article, it indicates that
The notion of "self-insurance" is quite common for extremely huge organizations where they figure that they have such a huge number of potential sources of claims that it makes sense to keep the insurance money and pay the costs of claims as they come up.
For instance, it is reasonably possible that IBM doesn't insure their buildings against fire damage. If they did, they might pay $100M per year for the insurance, and with the diversity of their real estate holdings, they might find that paying for fire repairs out of their own pockets would only cost $70M. Note, that means that it's cheaper for them to pay for repairs after some big fires.
Similarly, my own employer requires that if employees rent cars when travelling that we not pay LDW insurance; that costs $15-odd dollars per day, and with 120,000 of us, that can add up to Rather A Lot. It's cheaper for them to "self-insure," salting away some portion of the $15/day, and paying collision repairs directly on those occasions when accidents happen.
UPS appears to have been doing the same thing; they kept the "insurance" fees and paid for losses when losses were incurred.
It appears that once the case hit the tax court, lean and hungry lawyers noticed the case, and perhaps decided that they could probably confuse a jury into believing that self insurance is effectively a way lf "defrauding consumers."