There is a tendancy to use UTC in space applications; if people start dispersing to the moon, this provides some time delay issues in communications that would result in sync issues; heading further afield to Mars would be similarly disruptive to synchronization of activities.
It's possible that one might get meaningful information out of a GPS unit from the moon, albeit with extremely screwy coordinates as they'd be relative to the earth. (Mind you, it is probable that consumer units would shut down as you'd be moving more than 999mph relative to earth's surface...)
Determining time/location will provide opportunities for new fields in vCards and for a bunch of new RFCs. I thought there was one on this, but in querying the archives, I seem to be mistaken...
I would be concerned about the customization if it prevented me from compiling my own kernel and using that instead.
I've not done a fresh install of RHL since 5.1, so "perhaps they've gotten tremendously more proprietary since," but I rather doubt that.
The concern with TurboLinux customizations is if this makes TurboLinux kernels not interoperable with other kernels.
This will only matter if people adopt TurboLinux in droves; if they do their thing, producing a bad, scary forked kernel, and nobody uses it, this won't matter. It's not like the "tree in the forest;" if nobody is there using TurboLinux, nobody cares about a disused fork.
There's not much question but that there are some significant demerits to code forks. The plethora of mutually-incompatible patches to GCC that resulted from people supporting forks for:
Pentium optimization
Trying to support C++
FORTRAN
Pascal
Ada
Special forms of optimizations (IBM Haifa stuff, for instance)
The net result of the forks were that you could have a compiler that covers one purpose, but not necessarily more than one.
I do support of some R/3 code where our local group has "forked" from the standard stuff SAP AG provides; it is a bear of a job to just handle the parallel changes when we do minor "Legal Change Patch" upgrades. We've got a sizable project team in support of a major version number upgrade; the stuff that we have forked will represent a big chunk of the grief that results in that year long project.
I would consider a substantial fork of the Linux kernel to be a significantly Bad Thing.
Note that if it forks, the Turbo version may have a hard time supporting code written for the non-Turbo version. Major things that are likely forthcoming include:
New filesystem support, including LVMs, ext3, Reiserfs, SGI's XFS
New devices such as network cards, SCSI host adaptors, USB devices
Further support for 64 bit architectures, and support for 64 bit structures on 32 bit architectures ( e.g. - solving such issues as the 2038 Problem and the 2GB File Size Limit Problem and the 2GB Process Size Limit and such)
Deployment of such facilities would be substantially hampered by a kernel fork.
The problem with using HTML FORMS is that it's just not expressive enough to do the sorts of things that people want to do in applications. The things FORM does are useful; just not enough. More critically, they aren't extensible.
At the opposite end of the spectrum, the X protocol provides infinite control, but requires that you layer lots of stuff on top of it in order to do anything.
It may be worth looking at the PalmPilot; it represents, above all else, a useful set of compromises.
What is probably needed is some such useful set of compromises, a reasonably powerful widget set like one of
Tk
Gtk
Qt
that has:
A protocol that allows some reasonably high-level information to be passed across and processed by the client, and
Some way of extending the protocol by pushing some "extended widgets" out to the client that weren't originally supported.
Your idea of transmitting XML interpretable by a GLADE "server" on the client is certainly not outrageous; I would suggest the thought that it might be worthwile to have a protocol that passes across pre-parsed XML so as to cut down on the amount of network traffic.
The thing that libGlade does not (yet?) seem to admit is that of extensibility. In order to support that it would probably be necessary to have some form of interpreter on the client that can run (bytecompiled?) code to either provide additional widgets or to provide some further local processing.
Not being terribly "graphically oriented," I'll leave it to others to characterize what sorts of functionality forcibly need to sit on the front end. I'm skeptical that Java is quite there yet; AWT is, on the one hand, quite Lowest Common Denominator in nature, and ugly as such, whilst Swing looks like it's anything but "thin."
What may be helpful, on the other hand, is to make sure there are ways of splitting applications into modular pieces so that you can have pieces on hosts here and there, and thereby keep the graphical pieces fairly thin.
To that end, I would commend the consideration of message-oriented middleware systems; there are expensive ones like Tuxedo or MQSeries, and "libre" ones like Isect.
Keep in mind that you can't keep the client thin unless you have already split the application cleanly into pieces that allow the client to stay thin...
Coming up with an alternative to Lotus Notes seems to be one of the classic "failed projects;" several attempts have come and gone where groups have brainstormed and not been able to come up with a clear definition of something they could actually implement.
Several are listed at Text Management Projects for Linux, including Gather (aka PINN, aka Sumatra, aka Mediator), Yoga, Citadel, Casbah. Zope is probably somewhat comparable. Some of these are downright failed; others are merely somewhat late.
The problem is that Lotus Notes can be looked at in several ways:
As a glorified email/news messaging system, which knows how to replicate messages from server to server, and filter using ACLs and strong crypto.
As a database application platform integrating a DB engine and scripting tools.
As a distributed replicating non-relational database management system.
As a distributed document management system.
These are all useful perspectives; unfortunately people see it different ways, and when you put together enough people to have a project team, there are enough perspectives to make the project definition so vague as to be a non-starter.
There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.
Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.
Is anybody near to deploying a complete "libre" Java for Linux?
Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.
Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?
Testing/Standards
There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.
There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.
... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.
And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.
But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.
We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.
Question: What are you doing to help contribute to the public body of test suite code?
The reasoning for using encryption is indeed "all of the above."
Making copies "is piracy."
Using a copy in a jurisdiction in which it has not been licensed to be used "is piracy."
The consideration that using crypto, and patented crypto, at that, permits constructing protocols similar to Circuit City's (now cancelled) DIVX scheme is gravy...
Of course, I stand more in the pedantic camp that prefer to use words in the ways they were designed. Thomas Bushnell wrote it well:
The word ``piracy'' refers to seizing ships on the high seas, where normal social mechanisms of common defense are unavailable, and killing or kidnapping the sailors on board, and then stealing the ships and the goods they carry.
Piracy is an act a fair bit worse than robbing banks - more is stolen and many more people die.
Incurring civil penalties for copying software is nowhere near as bad as all that, and using the word ``piracy'' attempts to stir people up into a frenzy of horror.
This, I think, is a bad thing to do
In short, it seems to me that the SPA has "hijacked" (hee, hee) the use of the word piracy in much the same way that the term hacker gets used and abused in the media.
Vancouver Quadra, BC (AP) - Former Prime Minister Kim Campbell returns from retirement to announce a new protest movement against the continued attacks against western sovereignty.
In a surprise move, both First Nations and Inuit representatives came to agreement that they should share tax funding from receipts from gambling-related Internet sites.
Intel steps things up on the number-of-megahertz side of things, which is good for marketing.
(Of course, anyone that should be considering these high-end processors should be competent enough to know that performance is only positively correlated with the number of MHz. They don't run lock-step...)
Coppermine comes better prepared for laptop configurations
(Of course, there aren't many really-high-powered laptops; there was only ever one Alpha-based laptop, few SPARC-based, and such... I agree with others that availability of faster AMD chips in the K6 series is more important at this time...)
It's probably more important news that engineering-quantities of Itanium chips are starting to be released.
(I half-expect to see a report from VA-Linux Systems some time soon...)
Several announcements have been made lately about ciphers being assortedly vulnerable/invulnerable against Quantum cryptography.
Quantum physics seems to be the "magical" form of physics, and its application to cryptography even more magical. I don't think I properly understand "quantum cryptography," and I don't think that most of the people that have made public comment on it understand it terribly well either.
Could you comment on the present state of Quantum cryptography, and its probable relevance in public matters short term (which appears nonexistent), medium term (where the research of today may be in 5-10 years), and longer term?
The AES process to provide a new cipher has been ongoing for a while now...
How is this process going?
What ciphers have been eliminated due to successful, critical attacks? (Successfully attacking a couple rounds worth of a Feistel-like cipher obviously being less critical than providing cryptanalysis for "all 16"...)
There are some forms of publicity that are not good.
Not long ago, a senior officer of one of the "web tools" companies was arrested as a result of a sting operation that essentially ascertained that he was a pedophile.
That was decidedly not good news for the company.
Last year, there was a story going around about one of the managers at Red Hat "spending quality time" with what would probably be termed a "Linux groupie."
This caused mud to be thrown in all sorts of directions, making both he, RHAT, and the woman, all look bad.
I don't know the truth of the matter; regaling the world with tales of sexual escapades that are distinctly Not Politically Correct is decidedly Not Good Publicity.
Considering that the vast majority of the visible portions of the Linux community is made up of white males, not only is some "Male Dominance" likely, but also some "White Dominance."
If a story comes out this year about, assortedly, such things as:
Linux-related businesses that are making racist hiring decisions;
Lists of racist jokes going around at some Linux business;
This will again represent something that would not be reasonably seen as "good publicity."
I don't think that the Linux community is rife with "Neo-Nazi Militias," but I'm reasonably sure that there's enough of this to cause distress.
My local Linux Users Group has been doing considerable business (relatively speaking to any individual, at least) with LinuxCentral; I rather hope that the change in organization doesn't have any substantial impact on the way they operate their business.
One of the merits of dealing with a small company is that they don't feel the need to, before saying "yes" to things, say:
Sorry, we're going to have to ask the legal department for sign-off before we can proceed.
I'm not sure this goes along with the Marketing Department's sales strategy.
If extra levels of management get in the way of getting things done, this might not be such a good thing.
GNUS approach vs SLRN approach
on
Mutt Hits 1.0
·
· Score: 2
I've got a couple of Emacs instances running here and there at any given time; I've several times started with GNUS, not gotten not across the learning curve, and returned to the more spartan but still usable SLRN.
MH-E doesn't provide anything substantially better for transferring messages from folder to folder than the shell bindings you can get for zsh. EXMH provides a potent way of doing this that I've not seen in any other system; quite a lot better than the XMH front end.
Back to the point of the thread, Mutt and Slrn strongly parallel one another; they have highly similar user interfaces which partially comes from using the same text UI library, SLANG, which happens also to buy them a 'full' programming language that, not unlike with Elisp, allows "no end" to the customization. It's definitely different from Elisp, but that does not deny that these systems are quite extensible.
Support of many mailbox formats is nice
on
Mutt Hits 1.0
·
· Score: 2
Mail tends to accrete in a number of forms, and the fact that Mutt supports Maildir (of Qmail fame) as well as the MH format is certainly a good thing.
Mutt seems to me to have the nicest of the text interfaces; it is somewhat unfortunate that it doesn't have huge support for the multiplicity of folders that a MH user grows to. (I've got 350 mail folders and 179MB of archived email, for instance.) For managing that, the user interface of EXMH combined with a variety of shell scripts are pretty much necessary.
Mutt is still the nicest way of reading mail on a console...
Back then, Microsoft had decided that they were going to force the solution to all problems to be Windows NT.
They had to create tools to try to make NT fit the problems people try to solve using computers.
If they had looked at things the way you are, they should have concluded:
"Oh, NT isn't really the right solution. No point to even bothering to try to "make it fit."
That's obviously not what has happened. Instead, NT is being billed as the ideal solution to all sorts of problems, with attempts made to make problems fit NT.
If that isn't sad, then, by he very same argument, it is silly to regard attempts to make Linux useful as "sad."
If it is sad to try to make Linux and/or problems fit one another, then it is vastly more sad that Microsoft has wasted billions of dollars doing precisely the same thing.
The thing about the "pretty tools" (moving on up to things as sophisticated as ERWIN) is that they permit you to do the data modelling without writing any code. No Java needed. No Perl needed. Nothing needed.
I have no problem agreeing that there will be a point in time at which it will prove necessary to start coding; the point is that there are portions of the system where it is downright invaluable to have purely declarative definitions, which means that you've got a set of code on which you can unleash analysis tools that don't need to worry about the Turing-completeness of a full-scale language like Perl, PL/SQL, or Java.
It would be, for instance, a very interesting idea to compose ER diagrams using a diagramming tool like Dia. Dia generates output in the form of XML.
The really cool next step would be to take that XML and use it to generate the DDL code to generate the relevant tables, so that the diagrams represent not only instructive diagrams for communicating information about the design, but actually the code to define the declarative parts of the system.
(Note: ERWIN has the ability to do this sort of thing, permitting one to both generate table definition code from the diagram as well as to generate a diagram based on SQL DDL code...)
The suggestions concerning making sure that there's documented proof that you produced design material as at a particular date seem wise; whether this involves using a notary public, submitting sealed copy with lawyer, getting a copy postmarked, or going through some formal legal bureau responsible for such is something that you should ask your lawyer about. Safer is obviously better than probably safe enough.
The CEO of Digital Creations, the Zope people, did a talk at the Atlanta Linux Showcase pretty much describing this sort of thing. They looked for a venture capital firm that they felt they could trust; surprisingly, it was actually the VC people that suggested releasing Zope as free software.
The big point here is that it would be wise to contact a company that produces free software that has IPOed, and see what firms they have dealt with. Such firms are likely somewhat better choices to deal with than firms that haven't done VC work with "free software" companies.
In the case of Digital Creations, the VC firm was the Verticality Investment Group.
In the beginning, there are obviously not many VC firms that "grok" free software; those few firms that do, and get extra business as a result, will doubtless be noticed by those that are "later adopters."
As you say, there are not a lot of ways, at present, for a PalmOS unit to consume such vast quantities of storage.
MP3's are one application that would chew up lots of space fairly quickly; another would be geographical maps, which would tie nicely in to a GPS card. A third "neat idea" would be to have a wireless network connection (and I'm not thinking cellular/PalmVII here).
Unfortunately, many of the things that would make such extra storage capacity useful represent peripherals that would require a "slot," and which thus might not fit in simultaneously with the disk drive.
And I shudder at the rate of battery supply depletion that would result...
Methinks these applications will remain "niched" for a while yet.
It's pretty typical for the CPU not to be the main bottleneck on a computer system, at least these days.
Sun's SPARC provides nice evidence of this; they are selling lots of systems for high end database and web applications not because the SPARC architecture is vastly superior to its competitors, but because the rest of the system is fast.
On a PC, the real "critical component" is the motherboard, as that tends to be a determinant of such things as:
The speed of the memory bus, and how much RAM can be added to the system;
IDE/SCSI controller(s), and their quality/speed;
In the old days, how many bytes of buffer you had on your UART was pretty significant; RS-232 has pretty much gotten maxxed out since then...
The move from ISA and EISA and (less so) VESA to PCI was as much a signal of better performance in and of itself than the move from 80486 to Pentium...
I can't decide if AGP is actually a good thing; it makes it harder to build multiheaded systems...
These days, graphics cards have more RAM, and presumably more processing power, than one used to have on a 486 box for the main CPU. (These days, I have more cache on my CPU than I had disk space on my Atari 400... That's the most frightening ratio to compare...)
On the one hand, the announcement might cause one to expect that ATI would start affixing Penguin logos on boxes to indicate "Linux Compatibility."
On the other hand, based on the schedules quoted, it is still reasonably likely that with the rapid deployment of video cards these days, cards can go from "initial release" to "retirement" before XFree86 supports the card.
On the gripping hand, at least the graphics cards should eventually be supported, which is the important thing...
Take a look at the LinuxCE site; this site is exploring the notion of supporting Linux on WinCE palmtop computers.
Love it or hate it, the fairly hefty memory requirements of WinCE over PalmOS have the merit that the machines are more powerful than the PalmComputing brethren. This makes it vastly more likely that WinCE computers might be able to run Linux and actually have storage space left to hold utilities.
Supporting X, or even NanoGUI, would be rather challenging; it would be more feasible to try to provide the basic "Text Mode Console."
It wouldn't be something to run ApplixWare on, but it could be a nice way of Coding On The Road...
You're missing the point that since "Linux is hot" they're actually starting to consider it as an option.
For a long, long, time, they have denigrated free software because the (rather incestuous) relationships where consultants and vendors of both software and hardware is beneficial to all.
Something like a "Free R/3" might be somewhat tempting insofar as it would allow consultants and hardware vendors to have bigger shares of the "pie."
On the other hand, this would require that they actually become "technology" consulting firms, which seems rather unlikely.
Your assumption that RHAT gets a big chunk of the change seems quite questionable.
If that box gets sold at a store, then (guesstimate) RHAT probably only gets about $10-$12 of the $30, and they have to pay manufacturing and shipping costs on that.
I would expect that the potential profit on that represents $3, and sending $1 of that to the FSF actually is reasonably generous.
If RHAT is selling the box directly, they still are likely selling it through a fulfillment house, and certainly aren't getting the whole $30.
The notion that they're changing anything that has been established for the last 30 years is pretty silly; there has been evolution of locations chosen to "put stuff" throughout the history of UNIX.
The usual criticisms of this come from the perspective that RHAT tends to use SysV-isms as opposed to BSD-isms.
And criticizing RHAT for not following HOWTOs that are not likely being maintained and which probably also don't match the other distributions seems to me to be a cheap shot. HOWTOs tended to be written for Slackware, and many are quite horribly out of date. Feel free to criticize the HOWTO Trainwreck; that would be an interesting Slashdot thread...
Slashdot Mirror
There is a tendancy to use UTC in space applications; if people start dispersing to the moon, this provides some time delay issues in communications that would result in sync issues; heading further afield to Mars would be similarly disruptive to synchronization of activities.
It's possible that one might get meaningful information out of a GPS unit from the moon, albeit with extremely screwy coordinates as they'd be relative to the earth. (Mind you, it is probable that consumer units would shut down as you'd be moving more than 999mph relative to earth's surface...)
Determining time/location will provide opportunities for new fields in vCards and for a bunch of new RFCs. I thought there was one on this, but in querying the archives, I seem to be mistaken...
I've not done a fresh install of RHL since 5.1, so "perhaps they've gotten tremendously more proprietary since," but I rather doubt that.
The concern with TurboLinux customizations is if this makes TurboLinux kernels not interoperable with other kernels.
This will only matter if people adopt TurboLinux in droves; if they do their thing, producing a bad, scary forked kernel, and nobody uses it, this won't matter. It's not like the "tree in the forest;" if nobody is there using TurboLinux, nobody cares about a disused fork.
The net result of the forks were that you could have a compiler that covers one purpose, but not necessarily more than one.
I do support of some R/3 code where our local group has "forked" from the standard stuff SAP AG provides; it is a bear of a job to just handle the parallel changes when we do minor "Legal Change Patch" upgrades. We've got a sizable project team in support of a major version number upgrade; the stuff that we have forked will represent a big chunk of the grief that results in that year long project.
I would consider a substantial fork of the Linux kernel to be a significantly Bad Thing.
Note that if it forks, the Turbo version may have a hard time supporting code written for the non-Turbo version. Major things that are likely forthcoming include:
- New filesystem support, including LVMs, ext3, Reiserfs, SGI's XFS
- New devices such as network cards, SCSI host adaptors, USB devices
- Further support for 64 bit architectures, and support for 64 bit structures on 32 bit architectures ( e.g. - solving such issues as the 2038 Problem and the 2GB File Size Limit Problem and the 2GB Process Size Limit and such)
Deployment of such facilities would be substantially hampered by a kernel fork.At the opposite end of the spectrum, the X protocol provides infinite control, but requires that you layer lots of stuff on top of it in order to do anything.
It may be worth looking at the PalmPilot; it represents, above all else, a useful set of compromises.
What is probably needed is some such useful set of compromises, a reasonably powerful widget set like one of
- Tk
- Gtk
- Qt
that has:Your idea of transmitting XML interpretable by a GLADE "server" on the client is certainly not outrageous; I would suggest the thought that it might be worthwile to have a protocol that passes across pre-parsed XML so as to cut down on the amount of network traffic.
The thing that libGlade does not (yet?) seem to admit is that of extensibility. In order to support that it would probably be necessary to have some form of interpreter on the client that can run (bytecompiled?) code to either provide additional widgets or to provide some further local processing.
What may be helpful, on the other hand, is to make sure there are ways of splitting applications into modular pieces so that you can have pieces on hosts here and there, and thereby keep the graphical pieces fairly thin.
To that end, I would commend the consideration of message-oriented middleware systems; there are expensive ones like Tuxedo or MQSeries, and "libre" ones like Isect.
Keep in mind that you can't keep the client thin unless you have already split the application cleanly into pieces that allow the client to stay thin...
Coming up with an alternative to Lotus Notes seems to be one of the classic "failed projects;" several attempts have come and gone where groups have brainstormed and not been able to come up with a clear definition of something they could actually implement.
Several are listed at Text Management Projects for Linux, including Gather (aka PINN, aka Sumatra, aka Mediator), Yoga, Citadel, Casbah. Zope is probably somewhat comparable. Some of these are downright failed; others are merely somewhat late.
The problem is that Lotus Notes can be looked at in several ways:
These are all useful perspectives; unfortunately people see it different ways, and when you put together enough people to have a project team, there are enough perspectives to make the project definition so vague as to be a non-starter.
There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.
Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.
Is anybody near to deploying a complete "libre" Java for Linux?
There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.
Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.
Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?
There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.
There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.
And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.
But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.
We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.
Question: What are you doing to help contribute to the public body of test suite code?
The consideration that using crypto, and patented crypto, at that, permits constructing protocols similar to Circuit City's (now cancelled) DIVX scheme is gravy...
Of course, I stand more in the pedantic camp that prefer to use words in the ways they were designed. Thomas Bushnell wrote it well:
In short, it seems to me that the SPA has "hijacked" (hee, hee) the use of the word piracy in much the same way that the term hacker gets used and abused in the media.
In a surprise move, both First Nations and Inuit representatives came to agreement that they should share tax funding from receipts from gambling-related Internet sites.
(Of course, anyone that should be considering these high-end processors should be competent enough to know that performance is only positively correlated with the number of MHz. They don't run lock-step...)
(Of course, there aren't many really-high-powered laptops; there was only ever one Alpha-based laptop, few SPARC-based, and such... I agree with others that availability of faster AMD chips in the K6 series is more important at this time...)
(I half-expect to see a report from VA-Linux Systems some time soon...)
Quantum physics seems to be the "magical" form of physics, and its application to cryptography even more magical. I don't think I properly understand "quantum cryptography," and I don't think that most of the people that have made public comment on it understand it terribly well either.
Could you comment on the present state of Quantum cryptography, and its probable relevance in public matters short term (which appears nonexistent), medium term (where the research of today may be in 5-10 years), and longer term?
How is this process going?
What ciphers have been eliminated due to successful, critical attacks? (Successfully attacking a couple rounds worth of a Feistel-like cipher obviously being less critical than providing cryptanalysis for "all 16"...)
That was decidedly not good news for the company.
This caused mud to be thrown in all sorts of directions, making both he, RHAT, and the woman, all look bad.
I don't know the truth of the matter; regaling the world with tales of sexual escapades that are distinctly Not Politically Correct is decidedly Not Good Publicity.
If a story comes out this year about, assortedly, such things as:
- Linux-related businesses that are making racist hiring decisions;
- Lists of racist jokes going around at some Linux business;
This will again represent something that would not be reasonably seen as "good publicity."I don't think that the Linux community is rife with "Neo-Nazi Militias," but I'm reasonably sure that there's enough of this to cause distress.
One of the merits of dealing with a small company is that they don't feel the need to, before saying "yes" to things, say:
- Sorry, we're going to have to ask the legal department for sign-off before we can proceed.
- I'm not sure this goes along with the Marketing Department's sales strategy.
If extra levels of management get in the way of getting things done, this might not be such a good thing.MH-E doesn't provide anything substantially better for transferring messages from folder to folder than the shell bindings you can get for zsh. EXMH provides a potent way of doing this that I've not seen in any other system; quite a lot better than the XMH front end.
Back to the point of the thread, Mutt and Slrn strongly parallel one another; they have highly similar user interfaces which partially comes from using the same text UI library, SLANG, which happens also to buy them a 'full' programming language that, not unlike with Elisp, allows "no end" to the customization. It's definitely different from Elisp, but that does not deny that these systems are quite extensible.
Mutt seems to me to have the nicest of the text interfaces; it is somewhat unfortunate that it doesn't have huge support for the multiplicity of folders that a MH user grows to. (I've got 350 mail folders and 179MB of archived email, for instance.) For managing that, the user interface of EXMH combined with a variety of shell scripts are pretty much necessary.
Mutt is still the nicest way of reading mail on a console...
Back then, Microsoft had decided that they were going to force the solution to all problems to be Windows NT.
They had to create tools to try to make NT fit the problems people try to solve using computers.
If they had looked at things the way you are, they should have concluded:
That's obviously not what has happened. Instead, NT is being billed as the ideal solution to all sorts of problems, with attempts made to make problems fit NT.
If that isn't sad, then, by he very same argument, it is silly to regard attempts to make Linux useful as "sad."
If it is sad to try to make Linux and/or problems fit one another, then it is vastly more sad that Microsoft has wasted billions of dollars doing precisely the same thing.
I have no problem agreeing that there will be a point in time at which it will prove necessary to start coding; the point is that there are portions of the system where it is downright invaluable to have purely declarative definitions, which means that you've got a set of code on which you can unleash analysis tools that don't need to worry about the Turing-completeness of a full-scale language like Perl, PL/SQL, or Java.
It would be, for instance, a very interesting idea to compose ER diagrams using a diagramming tool like Dia. Dia generates output in the form of XML.
The really cool next step would be to take that XML and use it to generate the DDL code to generate the relevant tables, so that the diagrams represent not only instructive diagrams for communicating information about the design, but actually the code to define the declarative parts of the system.
(Note: ERWIN has the ability to do this sort of thing, permitting one to both generate table definition code from the diagram as well as to generate a diagram based on SQL DDL code...)
The CEO of Digital Creations, the Zope people, did a talk at the Atlanta Linux Showcase pretty much describing this sort of thing. They looked for a venture capital firm that they felt they could trust; surprisingly, it was actually the VC people that suggested releasing Zope as free software.
The big point here is that it would be wise to contact a company that produces free software that has IPOed, and see what firms they have dealt with. Such firms are likely somewhat better choices to deal with than firms that haven't done VC work with "free software" companies.
In the case of Digital Creations, the VC firm was the Verticality Investment Group.
In the beginning, there are obviously not many VC firms that "grok" free software; those few firms that do, and get extra business as a result, will doubtless be noticed by those that are "later adopters."
MP3's are one application that would chew up lots of space fairly quickly; another would be geographical maps, which would tie nicely in to a GPS card. A third "neat idea" would be to have a wireless network connection (and I'm not thinking cellular/PalmVII here).
Unfortunately, many of the things that would make such extra storage capacity useful represent peripherals that would require a "slot," and which thus might not fit in simultaneously with the disk drive.
And I shudder at the rate of battery supply depletion that would result...
Methinks these applications will remain "niched" for a while yet.
Sun's SPARC provides nice evidence of this; they are selling lots of systems for high end database and web applications not because the SPARC architecture is vastly superior to its competitors, but because the rest of the system is fast.
On a PC, the real "critical component" is the motherboard, as that tends to be a determinant of such things as:
On the other hand, based on the schedules quoted, it is still reasonably likely that with the rapid deployment of video cards these days, cards can go from "initial release" to "retirement" before XFree86 supports the card.
On the gripping hand, at least the graphics cards should eventually be supported, which is the important thing...
Love it or hate it, the fairly hefty memory requirements of WinCE over PalmOS have the merit that the machines are more powerful than the PalmComputing brethren. This makes it vastly more likely that WinCE computers might be able to run Linux and actually have storage space left to hold utilities.
Supporting X, or even NanoGUI, would be rather challenging; it would be more feasible to try to provide the basic "Text Mode Console."
It wouldn't be something to run ApplixWare on, but it could be a nice way of Coding On The Road...
For a long, long, time, they have denigrated free software because the (rather incestuous) relationships where consultants and vendors of both software and hardware is beneficial to all.
Something like a "Free R/3" might be somewhat tempting insofar as it would allow consultants and hardware vendors to have bigger shares of the "pie."
On the other hand, this would require that they actually become "technology" consulting firms, which seems rather unlikely.
I would expect that the potential profit on that represents $3, and sending $1 of that to the FSF actually is reasonably generous.
The notion that they're changing anything that has been established for the last 30 years is pretty silly; there has been evolution of locations chosen to "put stuff" throughout the history of UNIX.
The usual criticisms of this come from the perspective that RHAT tends to use SysV-isms as opposed to BSD-isms.
And criticizing RHAT for not following HOWTOs that are not likely being maintained and which probably also don't match the other distributions seems to me to be a cheap shot. HOWTOs tended to be written for Slackware, and many are quite horribly out of date. Feel free to criticize the HOWTO Trainwreck; that would be an interesting Slashdot thread...