There are a couple of staff at VA Linux Systems that have been doing Matrox/XFree86 development for a goodly couple years now; the open question is where this leaves their efforts.
Hopefully there's some information sharing between Matrox, PI, and LNUX on this so that all their efforts can continue to prove useful.
It would be unfortunate if there was a fragmentation of efforts.
It mentions Rene Simard, and chortle! links to a pregnant seahorse...
It definitely plays the "pur laine Quebecois" versus "maudit francais" game.
To those from less French places, this is somewhat analagous to Australians playing up that they're transported convicts, treating the "theoretically better born" English as inferior.
It's definitely very politically incorrect, and will be quite offensive to anyone sensitive to terms like "wop" or "paki." It's too bad that it's so offensive, as it's otherwise quite funny. The only upside is that it's pretty much going to be offensive to everyone, including Quebecois.
I guess it's funny in a sort of "South Park" way...
They have two commodities that could be of some value:
A not terribly bad name, and
A stock ticker with a nicely Linux-related encoding.
That could be worth something to someone. Not necessarily a lot, and if the actions of the company sully the names, the names lose value.
But for someone wanting to start a Linux company, buying LINX out would represent an interesting way of getting onto the stock market, so long as their price wasn't too high.
I'd think a million dollars to be "too high," personally...
Last night's headline in Dallas was about how Kroger grocery stores have decided to cover over parts of the covers of Cosmopolitan magazine to hide both the generally cleavage-heavy outfits models wear as well as the lurid article titles.
That's easy enough to implement, when all it involves is taking a dozen 8"x8" piece of plastic and placing them in well-defined magazine rack locations.
The best that has been done thus far is that the seriously offensive stuff sits behind barriers that require a credit card validation to open up.
Your suggestion of determining what sites fall under a "general obscenity law" doesn't work, as the general result of such laws is not simply to "filter" such things, but rather to establish that the police ought to go over and outright close the site down.
What you're looking for is some sort of "in between;" stuff that is permitted "viewing" for adults, but forbidden for children. And that is decidedly not something that is well-defined.
One of the more interesting situations I have been in was a "debate" over this; a district attorney with experience in the matter in the Ontario jurisdiction discussed censorship in the context of a church youth group.
There were a surprising variety of opinions on the matter, and what was more surprising still was that even in the context of a group that you might expect to focus on it blindly (and there were a few people like that), it was quite clear that there could be no clear legislation to agree on.
Consider some examples of situations with varying levels of permissiveness/ambiguity:
You and I might agree that "extreme"/"hard core" publications like Hustler or Penthouse "leap over the line," and have often gotten censored and censured as a result of running afoul of obscenity laws.
Playboy and other clearly "soft core" publications may be "clearly" inappropriate for youngsters, but considering them to be obscenity is far less clear.
What of things that are merely "suggestive," such as swimsuit catalogues, the Victoria's Secret catalogue, Sports Illustrated Swimsuit edition and such?
What of the "nearly naked Africans" that appear in National Geographic?
What treatment should a medical anatomy text get?
Does it differ if purchased by a doctor, or by a hormonally-challenged teenager?
What if the teenager, despite hormonal challenges, truly is planning to study medicine?
What about an issue of a medical journal, Deviant Psychology, specifically dealing with the treatment of individuals with addictions to dramatically obscene materials, that has to excerpt from such in order to help doctors treat patients?
There would be considerable merit to establishing tools like this as options for the construction of "back office" applications, particularly providing alternatives to MSMQ/MTS.
Which is, for those who have never been in the gallery of a parliament, whether UK, Canada, or otherwise, is a misspelling of what parliamentarians actually say is:
Hear! Hear!
Methinks there will be a burning...
on
XFree86 Gets 25k
·
· Score: 2
If you're talking about the dev tools side of things, perhaps not, but I gather that the format of the XFree86Config file changes significantly, thus mandating creation of "fresh" configuration software.
Hopefully this is an opportunity to build something considerably friendlier/prettier than what they've had. Although I'm quite happy if they wait, oh, "half an hour or so" to implement it...
It appears that there may be some impropriety in the matter. Happily, the "exclusive supplier" in question, SuSE, operates in other places.
Supposing the Uruguayan supplier is acting improperly, it would be a perfectly reasonable idea for Linux folk to "have a chat" with the nice folks at SuSE.
If they are allowing suppliers to act improperly, then it might be proper to let SuSE know that this is not acceptable to people that aren't in Uruguay.
For instance, if the situation is as suggested, it's reasonably likely that the local LUG may send a respectful letter to SuSE explaining how we might encourage members not to use SuSE's products.
On the one hand, it looks somewhat serious. Certainly compared to some of the genuine net.kooks that I've had the fortune/misfortune of encountering.
On the other hand, the web site is using the same sort of vastly-over-fonted formatting that is characteristic of Tax Refusals and the likes.
The thesis of the Oh, No! The Japanese are bribing the US Patent Office Out of Existence site isn't terribly clear. When the argumentation isn't completely coherent, it can be tough to tell apart someone that's got a good idea, but can't quite spit it out right, and feels too strongly about the matter to be completely coherent, from someone that is a completely loony raving nutter.
As for the anti aliasing issue, I am increasingly coming to suspect that this will happen, not via changes to X itself, but rather via implementation of structures that manage this.
It's not merely 28MB when the system eats into swap to the tune of 50MB, after I've killed off other processes.
Yes, it's a problem to perfectly reconcile the amount of memory in use.
But when the system slows to a literal crawl, I can simultaneously hear the disk running continually, and swap space starts disappearing in large quantities, that's a clear sign of either memory leakage, or some other intense usage of RAM.
Not all of Mozilla was Netscape's to give away. Notably bits from Bitstream, RSA (now Network Associates), and GUI stuff from sundry vendors.
Even if Apple "open sources" all of their code, that doesn't imply that Adobe code is treated similarly.
And I frankly worry more about Adobe doing "evil proprietary stuff" than I do about Apple. DPS, Type 1, Postscript, and PDF are more pervasive than MacOS. Greater danger lies there.
What precisely is the "operating system?"
Much of the old "GNU/Linux" controversies come out of the quite legitimate issue of which parts are Linux, and which parts are "GNU."
Similarly, there has been much arguing over whether Internet Exploder is part of the "Windows Operating System."
And the ambiguity strikes again here; "the whole OS" could vary from merely being some bits of Mach to being inclusive of MS Office and OS-X development tools, WebObjects, and OPENSTEP.
I'm game to disbelieve anything claimed on Slashdot until there's code available via FTP/CVS...
Can it possibly have as many memory leaks as Mozilla?
I was running M12 last week, and whilst writing a Slashdot article, the process grew to 112MB in size. I only have 96MB of RAM, so you can imagine what happened to system performance.
Mozilla may be fairly featureful, but:
It's still quite buggy. Needs to be Purified or something of the sort.
It's getting faster, but is certainly not fast.
RAM pig. Big time.
Opera may only be at the "pre-alpha" stage, but they have code base out there to support the things that don't work yet on Linux, so it seems reasonable to expect this to come in time.
And it can't conceivably consume as much RAM as Mozilla. Urk...
This really ought to get directed to Ulrich Drepper; that could provide a straighter answer as to whether the problem represents:
A serious problem with GLIBC 2.1
A serious problem with an interaction between GLIBC 2.1 and Linux
A serious problem with the understanding that the developers have of POSIX and/or ANSI C that causes these "unexplainable anomalies" to be "unexplainable."
(In other words, they might be misusing file pointers or close() and the anomalies would thus be their fault.)
After the number of other misunderstandings that I've seen of versions of LIBC, I somewhat suspect the third option, although there's not enough evidence to strongly support any position. Best to contact Ulrich with a test case.
I agree that you want, at some point, to rerun the whole suite.
But if all you did was to patch the kernel a bit to fix a particular problem, it may be desirable to just run the tests that you figure are related to that change.
Rerunning the full suite overnight or on some other reasonable periodic basis to find problems that may have been introduced would be an obvious thing to do.
The real point is that if the test suite grows to 15MB of source code, and runs for 25 hours, you don't run the whole thing every time you make a little change. You run the parts that could conceivably be relevant. And run the whole thang once in a while.
Or perhaps have a daemon that grabs the latest kernel every time one is released, and runs it through regression.
That's not a concern until there's so many tests that they'll run for many hours...
Seeing as how I grew up in Ottawa, and my last opthalmologist's office is across the street from Corel HQ, I might be considered to have some bias in the matter:-).
If Corel couldn't "win" against MSFT in providing word processing software to the Federal government, despite having their offices thousands of miles nearer to the Ottawan decision-makers than Bill Gates in Seattle, it's going to be tough to dominate in places other than "home territory..."
They have the "bulk" of corporate resources to perhaps outdo RHAT and SuSE; we'll see what happens!
Apparently I forgot to use the HTML "SARCASM" tag around what I wrote.
Yes, indeed, a generic x86 box running Linux could do all the things described, for vastly less than $2000.
Glad to see that you noticed that...
(Hmmm... I wonder if I forgot to use the SARCASM tag on any of this message... Nah, I'm sure everyone's observant enough to know where it should have been applied...)
That's fair comment; it will be difficult to run all the tests in "the lab" if some of them are only for the Atari TT port, and the lab doesn't have an Atari TT.
That goes to suggest that the testing scheme needs to be highly distributed, so that it checks to see what hardware is there is on a particular box, and tests that hardware. And submits the results back to a central site that would collect the results of tests together.
I have the suspicion that "official" S/390 support may be more than a little ways off. Possibly privileged information, so I'll leave it at that...
I agree that it would be nice to have the various new FSes; I don't think Reiserfs will be quite ready, and it looks likewise for ext3, more be the pity. As for Procfs, if it's not there already, I have a hard time believing it'll get there soon. And you forgot NFS3, no?
As for ACLs, I don't think the rest of the world is ready for them. They're practically useless without fairly sweeping changes to things like:
LIBC
GNU Fileutils
RPM, dpkg
Anything else that might need to be aware of them.
I somewhat favor a rather different ACL model based on TOPS-10 FILDAE; 'tis unclear that we've got a clear model of how to configure security with ACLs, and it doesn't make sense to push it into the kernel until there are some clear ideas on how to implement the user-space ACL management.
This is not all that interesting work, in some ways, but certainly useful stuff.
The necessary methodology involves automating execution of QA tests. You don't want to have to run 'em all by hand...
Approach:
For each test, X, cd/usr/src/qa/tests/X
make clean; make test
This compiles a C program that exercises some facility of the system.
The program drops output into a local file in the directory, as well as to a central results DB in /usr/src/qa/results , where entries are keyed by test, by date, and by kernel version.
The notable result is a Pass or Fail value.
A script runs through all the directories, running each test.
It would be good if a "success" result caused the test program to create the file success, so that one could run through, after a patch, and "merely" use make success to rerun failed tests.
Every time you locate a bug, you create a test.
Every time you find behaviour that ought to be, you create a test.
This is more-or-less how one does regression testing with things like compilers. Tests that run with the kernel would be equally valuable.
If you build a reasonably intelligent infrastructure, and are accepting of regression tests, you'll come to know more about how the kernel works than you ever wanted to know...
Slashdot Mirror
Hopefully there's some information sharing between Matrox, PI, and LNUX on this so that all their efforts can continue to prove useful.
It would be unfortunate if there was a fragmentation of efforts.
To those from less French places, this is somewhat analagous to Australians playing up that they're transported convicts, treating the "theoretically better born" English as inferior.
It's definitely very politically incorrect, and will be quite offensive to anyone sensitive to terms like "wop" or "paki." It's too bad that it's so offensive, as it's otherwise quite funny. The only upside is that it's pretty much going to be offensive to everyone, including Quebecois.
I guess it's funny in a sort of "South Park" way...
That could be worth something to someone. Not necessarily a lot, and if the actions of the company sully the names, the names lose value.
But for someone wanting to start a Linux company, buying LINX out would represent an interesting way of getting onto the stock market, so long as their price wasn't too high.
I'd think a million dollars to be "too high," personally...
That's easy enough to implement, when all it involves is taking a dozen 8"x8" piece of plastic and placing them in well-defined magazine rack locations.
What people clearly don't understand is that Attempts to prevent the use of packet-switched communications networks such as the Internet to transmit information that could possibly offend are technically doomed to failure, because it's all just packets.
The best that has been done thus far is that the seriously offensive stuff sits behind barriers that require a credit card validation to open up.
Your suggestion of determining what sites fall under a "general obscenity law" doesn't work, as the general result of such laws is not simply to "filter" such things, but rather to establish that the police ought to go over and outright close the site down.
What you're looking for is some sort of "in between;" stuff that is permitted "viewing" for adults, but forbidden for children. And that is decidedly not something that is well-defined.
One of the more interesting situations I have been in was a "debate" over this; a district attorney with experience in the matter in the Ontario jurisdiction discussed censorship in the context of a church youth group.
There were a surprising variety of opinions on the matter, and what was more surprising still was that even in the context of a group that you might expect to focus on it blindly (and there were a few people like that), it was quite clear that there could be no clear legislation to agree on.
Consider some examples of situations with varying levels of permissiveness/ambiguity:
- You and I might agree that "extreme"/"hard core" publications like Hustler or Penthouse "leap over the line," and have often gotten censored and censured as a result of running afoul of obscenity laws.
- Playboy and other clearly "soft core" publications may be "clearly" inappropriate for youngsters, but considering them to be obscenity is far less clear.
- What of things that are merely "suggestive," such as swimsuit catalogues, the Victoria's Secret catalogue, Sports Illustrated Swimsuit edition and such?
- What of the "nearly naked Africans" that appear in National Geographic?
- What treatment should a medical anatomy text get?
- What about an issue of a medical journal, Deviant Psychology, specifically dealing with the treatment of individuals with addictions to dramatically obscene materials, that has to excerpt from such in order to help doctors treat patients?
- What about a documentary about pornography? There have been controversies over the documentary Not A Love Story.
The problem is that there's not adequate law to deal with the problem, and this nicely predates the Internet.Does it differ if purchased by a doctor, or by a hormonally-challenged teenager?
What if the teenager, despite hormonal challenges, truly is planning to study medicine?
Can you comment on possibilities for developments relating to transaction processing and database management systems?
"For instances" to make this clearer include:
- RHAT has apparently been putting work into the availability of raw partitions that the major DBMS vendors prefer to the use of native filesystems.
- TP monitors such as BEA Tuxedo as well as message queueing systems such as IBM MQSeries.
There would be considerable merit to establishing tools like this as options for the construction of "back office" applications, particularly providing alternatives to MSMQ/MTS.Ala SCT-RAW , raw i/o patches
There's one "libre" option, Isect
The deadly question is, how much time does a 3.3.x release consume that could have been spent making 4.x available sooner?
Don't misread that; I liked the Fifth Element; while the story may have been somewhat lame, the music and visuals more than made up for that.
But I don't want a computer made up in the colour of the Diva.
No, what the self respecting Linux nerd actually needs is a serious Rack Mount System.
Those that want cheaper options might want to Build A Rack Mount Case, and check out Rack Mount Hardware at eBay. Here may be the true ultimate case.
Hopefully this is an opportunity to build something considerably friendlier/prettier than what they've had. Although I'm quite happy if they wait, oh, "half an hour or so" to implement it...
Supposing the Uruguayan supplier is acting improperly, it would be a perfectly reasonable idea for Linux folk to "have a chat" with the nice folks at SuSE.
If they are allowing suppliers to act improperly, then it might be proper to let SuSE know that this is not acceptable to people that aren't in Uruguay.
For instance, if the situation is as suggested, it's reasonably likely that the local LUG may send a respectful letter to SuSE explaining how we might encourage members not to use SuSE's products.
The thesis of the Oh, No! The Japanese are bribing the US Patent Office Out of Existence site isn't terribly clear. When the argumentation isn't completely coherent, it can be tough to tell apart someone that's got a good idea, but can't quite spit it out right, and feels too strongly about the matter to be completely coherent, from someone that is a completely loony raving nutter.
Note:
Long and short is that it may be quite appropriate to have antialiasing managed within application libraries as opposed to directly in X.
Yes, it's a problem to perfectly reconcile the amount of memory in use.
But when the system slows to a literal crawl, I can simultaneously hear the disk running continually, and swap space starts disappearing in large quantities, that's a clear sign of either memory leakage, or some other intense usage of RAM.
They may not make a profit; that doesn't make them charitable from the IRS' perspective.
- As you say, which license would be picked is ambiguous, and has significant implications.
- Compare to Mozilla.
- What precisely is the "operating system?"
I'm game to disbelieve anything claimed on Slashdot until there's code available via FTP/CVS...Not all of Mozilla was Netscape's to give away. Notably bits from Bitstream, RSA (now Network Associates), and GUI stuff from sundry vendors.
Even if Apple "open sources" all of their code, that doesn't imply that Adobe code is treated similarly.
And I frankly worry more about Adobe doing "evil proprietary stuff" than I do about Apple. DPS, Type 1, Postscript, and PDF are more pervasive than MacOS. Greater danger lies there.
Much of the old "GNU/Linux" controversies come out of the quite legitimate issue of which parts are Linux, and which parts are "GNU."
Similarly, there has been much arguing over whether Internet Exploder is part of the "Windows Operating System."
And the ambiguity strikes again here; "the whole OS" could vary from merely being some bits of Mach to being inclusive of MS Office and OS-X development tools, WebObjects, and OPENSTEP.
I was running M12 last week, and whilst writing a Slashdot article, the process grew to 112MB in size. I only have 96MB of RAM, so you can imagine what happened to system performance.
Mozilla may be fairly featureful, but:
- It's still quite buggy. Needs to be Purified or something of the sort.
- It's getting faster, but is certainly not fast.
- RAM pig. Big time.
Opera may only be at the "pre-alpha" stage, but they have code base out there to support the things that don't work yet on Linux, so it seems reasonable to expect this to come in time.And it can't conceivably consume as much RAM as Mozilla. Urk...
This really ought to get directed to Ulrich Drepper; that could provide a straighter answer as to whether the problem represents:
- A serious problem with GLIBC 2.1
- A serious problem with an interaction between GLIBC 2.1 and Linux
- A serious problem with the understanding that the developers have of POSIX and/or ANSI C that causes these "unexplainable anomalies" to be "unexplainable."
After the number of other misunderstandings that I've seen of versions of LIBC, I somewhat suspect the third option, although there's not enough evidence to strongly support any position. Best to contact Ulrich with a test case.(In other words, they might be misusing file pointers or close() and the anomalies would thus be their fault.)
But if all you did was to patch the kernel a bit to fix a particular problem, it may be desirable to just run the tests that you figure are related to that change.
Rerunning the full suite overnight or on some other reasonable periodic basis to find problems that may have been introduced would be an obvious thing to do.
The real point is that if the test suite grows to 15MB of source code, and runs for 25 hours, you don't run the whole thing every time you make a little change. You run the parts that could conceivably be relevant. And run the whole thang once in a while.
Or perhaps have a daemon that grabs the latest kernel every time one is released, and runs it through regression.
That's not a concern until there's so many tests that they'll run for many hours...
If Corel couldn't "win" against MSFT in providing word processing software to the Federal government, despite having their offices thousands of miles nearer to the Ottawan decision-makers than Bill Gates in Seattle, it's going to be tough to dominate in places other than "home territory..."
They have the "bulk" of corporate resources to perhaps outdo RHAT and SuSE; we'll see what happens!
Yes, indeed, a generic x86 box running Linux could do all the things described, for vastly less than $2000.
Glad to see that you noticed that...
(Hmmm... I wonder if I forgot to use the SARCASM tag on any of this message... Nah, I'm sure everyone's observant enough to know where it should have been applied...)
That goes to suggest that the testing scheme needs to be highly distributed, so that it checks to see what hardware is there is on a particular box, and tests that hardware. And submits the results back to a central site that would collect the results of tests together.
Devfs has been available as a patch to the kernel for a long time now; if it's not in yet, I'm not sure why it would be expected to go in now...
- Multitasks
- Offers 3D graphics and lots of colours
- Is widely useful for many kinds of tasks
and costs less than $2000.Of course, you can get a Milan or Medusa for probably around that price...
I agree that it would be nice to have the various new FSes; I don't think Reiserfs will be quite ready, and it looks likewise for ext3, more be the pity. As for Procfs, if it's not there already, I have a hard time believing it'll get there soon. And you forgot NFS3, no?
As for ACLs, I don't think the rest of the world is ready for them. They're practically useless without fairly sweeping changes to things like:
I somewhat favor a rather different ACL model based on TOPS-10 FILDAE; 'tis unclear that we've got a clear model of how to configure security with ACLs, and it doesn't make sense to push it into the kernel until there are some clear ideas on how to implement the user-space ACL management.
The necessary methodology involves automating execution of QA tests. You don't want to have to run 'em all by hand...
Approach:
- For each test, X, cd
/usr/src/qa/tests/X - make clean; make test
- A script runs through all the directories, running each test.
- Every time you locate a bug, you create a test.
- Every time you find behaviour that ought to be, you create a test.
This is more-or-less how one does regression testing with things like compilers. Tests that run with the kernel would be equally valuable.This compiles a C program that exercises some facility of the system.
The program drops output into a local file in the directory, as well as to a central results DB in /usr/src/qa/results , where entries are keyed by test, by date, and by kernel version.
The notable result is a Pass or Fail value.
It would be good if a "success" result caused the test program to create the file success, so that one could run through, after a patch, and "merely" use make success to rerun failed tests.
If you build a reasonably intelligent infrastructure, and are accepting of regression tests, you'll come to know more about how the kernel works than you ever wanted to know...