The GNU GPL requires a enourmous FAQ just to lay the ground rules. I think many people sign up using the GNU GPL without thinking of the implications - it's less a license and more a social movement. There should be a question in that FAQ, "What will the world be like if all software is GNU GPL?" (which is the intent of the GNU GPL given it's virus-like design). And, anyone applying the GNU GPL to their code is implicity agreeing with the philosophy and conclusions of that question. A pervasive GNU GPL would affect our freedom of choice, freedom of expression, and privacy - and the conclusions may not be what you expect. So, at a minimum, users of the GNU GPL should at least think through those issues. And, most don't.
The BSD license, on the other hand, is just that, a license and not a forced social movement. It doesn't try to modify behavior. Because it has fewer overall social implications, it's easier to understand. Consequently, it requires only the most trivial FAQ.
It was a moment, Mr. Perry indicated, as significant as Alexander Graham Bell's first phone call to Thomas Watson.
But "this technology, I happen to think, will have an even greater effect on the citizens of the world than what Mr. Bell came up with," he said.
I am so entirely sick of this extreme chest-puffing and disrespect of actual culture-changing inventions. No, 3D video conferencing is not even close to the advent of the telephone. Acquire and apply some humility.
The telephone gave for the first time real-time two-way communication. 3D video conferencing adds nothing to that essence except a pretty picture. It's still real-time, and it's still communication. Being able to see the other party's postures and gestures is only a marginal improvement, not an earth-shattering achievement.
A. your code isn't unbreakable. With enough time something with so few of characters could be cracked by brute force methods alone.
Excuse me? Are we looking at the same C source code? Can you read C?
Because he just wrote over his message with zeros.
Do you maintain that given the message "000000000", you can determine that means "I'm cool!" instead of "You suck!" or any of the other, say, 1e18 possibilties?
And that's his point: it's nothing interesting and it's nothing new. If you can guarantee your stream of random numbers is truly random and only you and your recipient know those random numbers, then any one "decription" by an eavesdropper is no more likely than any other.
> I'd prefer to use the term "improbable" in that case
I would prefer the term "not unlikely" in that case. I work with computer vision. Given lighting (shading) and texture (warp and texel distribution) cues, a decent, estimated 3-dimensional model can be built from the image. That estimate can be further improved if some high-level information about the scene (human face, box, ball, etc.) is provided or assumed.
But it doesn't matter if you have two cameras if you're only looking at a single, two-dimensional picture. Given that, you, a human, can still draw a good estimate of the 3-dimensional structure of the depicted scene.
But the point being that in the current IRC topology there are specific, designated servers. By decentralized in the sense of GNUtella, every client acts as a relay server. So, there are no specific servers, there's no pressure point to apply a DDoS. To get on the chat network, then, you need to know the addy of any other client on the chat network. Granted, I'm no network, GNUtella, nor IRC guru, so feel free to correct any of those assertions.
A possible fix: decentralize IRC in the sense of GNUtella. If there aren't any primary server and what "toplevel" server there are aren't static, DDoS brings down at most a small portion of the service. It's time to evolve.
It doesn't matter. The object's second and third largest dimensions are 4 and 9 times the length of the smallest dimension, respectively - regardless of the particular units.
Meters are just as arbitrary as feet, anyway. For humans, meters are nice because the system of measurement they're commonly used in exploit powers of 10 (mega, kilo, milli, micro, etc). But, there's nothing to say that base-10 is intuitive to aliens, who probably don't have 10 fingers and toes.
Just invoking the word "bytecode" or compiling a language to bytecode doesn't suddenly make the virtual machine language independent.
Java bytecode, for instance, is significantly tied to the Java language specification. Go browse The Java VM Specification if you like -- classes fields, members, construction, interfaces, and garbage collection are built into the VM.
Admittedly, I am ignorant of Dis code, but when I see "Inferno applications are written in Limbo" in the Inferno FAQ, my confidence in a language independent Inferno VM is shaken.
Java, Inferno. It seems such a waste to design, construct, and optimize virtual machines, then only support a *single* language on that VM.
Image the same model for real processors: "The NEW Intel Crapanium!!! Executes C++!". What a joke.
Re:Crank up your tile cache, oh and RTFM
on
Grokking The Gimp
·
· Score: 1
I am neither a Gimp nor Photoshop guru -- an out-of-the comparision is appropriate and valid. For that test, Gimp failed.
I changed the Gimp "maximum image size" cache setting (there is no equivalent setting for Photoshop that needs to be tweaked/tuned) and it performed significantly better. But still, overall not nearly as well as Photoshop.
Don't take my word for it. Try both programs yourself. Here's an iDrive link to the image I was using:
Berkeley_aerial.jpg
.
> I can do my editing twice as fast with Gimp than I can with photoshop.
I pieced together a 6200x6200 pixel grayscale aerial photo of Berkeley, CA with images from Terraserver. There were brightness/contrast differences between tiles I wanted to manually tweak.
Editing that image sounds like a big job. But, representing each pixel with a byte (because it's grayscale), the image is 38.4MB. Since I have 128MB of RAM, I thought editing it in Gimp would be feasible. Nope, it just thrashed my swap space. Note, I had to go to a machine with 256MB of RAM just to merge the tiles using ImageMagick.
For the same file, Photoshop performed exceptionally well. For instance, it quickly loaded the image and allowed real-time arbitrary zooming and panning. Of course, I also fixed my brightness/contrast issues. If I took the time to figure out how to batch-append those tiles using Photoshop, I assume it would have been significantly faster than ImageMagick.
Kudos to the Gimp team for building something that is both usable and something people enjoy using. But, I'm getting tired of people proclaiming various open source projects as being superior applications than their commercial counterparts just because they're looking at them through Open Source Beer Goggles. Evaluate the application on its merits, not on its religion.
I suppose I'm peeing into the wind asserting something like this on Slashdot... c'est la vie.
Everyone here has been brainwashed by the idea of censorship. Moderation schemes are exactly backward, effectively letting others (the moderators) select who and what I read.
Let me be the only one who filters what I read. Let there be personal, dynamic, intelligent filtering instead of mob-based moderation.
That is, let my account record moderation that I and only I do to articles. Then, articles are rated (from my perspective only) based on how I've moderated similar aticles in the past. This can be done based on author, keyword matching, whatever -- and should be options in moderation: "I (dont) like this author", "I (dont) like this content", etc.
Done. The beauty? No text gets explicitly censored -- you read the content that you like, not some function of what the group likes. Of course, you should be able to threshold depending on your mood -- where articles are rated, say, 5=must-read to 0=unclassified to -5=dont-read.
It's more complicated to code and takes more server CPU, but all side-effects of the current point moderation systems (that everyone is trying to hack and patch around) are gone.
I agree. I found the presence of the inline comments so disturbing I went through and cut them out just so I could read the original, uninterrupted text. Here it is:
Digital:Convergence understands this Linux issue and the concerns expressed by the community. Had Digital:Convergence been approached by developers we would have been (and still will be) happy to work with them in a constructive direction. Instead, our products were reversed engineered and what has occurred is a public display of what is clearly our intellectual property. It is unfortunate the supporters of the open source community have taken steps to publicize intellectually property in-order to further their own goals and desires. Unfortunately, for us all, some of the people conducting these efforts would not voluntarily remove our IP, even after
being contacted.
In the strictest legal terms we had no choice but to proceed
protect our interests. By posting our IP to the Net the
Linux Community has forced us into a position of having to
legally defend our technology . Under IP law
if we don't PROTECT our IP, we loose any remedies under law
to PROTECT our IP. This IS NOT ABOUT stopping hackers, but
trying to get the "hackers" and such to WORK WITH US AND
NOT EXPOSE US and destroy over 5 years of hard work by a
group of "geeks, hackers and techno-whizzes" like each of you!
Any professional and serious developer will understand the following:.........Unfortunately the Linux Community could of
inadvertently created the WINDOW for the BIG companies to come in
and control and profit from this process we have created.
So if M$ or some other company decides to do what you are
doing *for profit" and DigitalConvergence allows the open
source group to continue with out proper licenses,
DigitalConvergence could loose its ability to effectively stop
them. The Linux Community would of
actually had a DIRECT HAND in creating what it stands most
vehemently against!
It is our hope the Linux community will help us in our efforts by
working with us to create a product to support your needs, and;
stop and remove illegal posting efforts, and;
encourage others in the Linux community to work with us
hand-in-hand to develop a various solutions and useful applications.
You too, can be part of this valuable tool and project!"
Digital:Convergence supports the Linux/Unix community
and plans to make a version of its software available for Linux available
in the near future. Also, licenses are available for any developers
wishing to work with any aspect of our technology. We welcome the
individuals of the community to contact us and use a more professional,
orderly and productive manner in adjusting our products to better
serve, in tact and based fully upon our various Patents and
Intellectual Property, your community, . Professional Licenses and
Development contracts are available to the Linux/Unix community
and we welcome your direct and professional contact.
And, by the way, the AT HOME - PERSONAL USE DEVELOPER
LICENSE is $20 USD! So please, HELP US PROTECT, what a group of
talented developers, have worked so very hard on for over the last
5 years!
J. Jovan Philyaw - Chairman & C.E.O. ceo@digitalconvergence.com
Doug Davis - President Technology Group ddavis@digitalconvergence.com
The assumption "the more volume, the more possible positions of particles in the computer" leading to the eventual conclusion of limits on storage capacity has already been invalidated by modern science.
Apparently, infinite information can be stored in a single atom -- no joke. Check out this this EETimes article -- link courtesy of ArsTechnica.
Summary: Philip Bucksbaum from the University of Michigan has stored and retrieved eight bits of information from the quantum-phase of a single cesium atom. Theoretically, there is no limit on capacity.
Ummm... yes you can. Easily. When was the last time you said, "Mississippi one, Mississippi two, Mississippi three"? Saying that at a moderate pace, each vocalized numeral occurs about once a second. So together, that's two words a second, or 120 WPS. A Mississippi is no small word!
With that brief anaylsis, for non-technical text, I'd say it's very reasonable to speak at a steady 200-250 WPS. Type that on your keyboard, then we can talk!:p
Of course, until someone develops a programming language specifically suited for voice recognition, I won't be coding via voice any time soon.
BTW, that last sentence was 22 words, if you can read it in 6 seconds, that's 220 WPM. Try it. Now say it at half the speed (whoah! that doesn't feel very fast at all) and that's 110 WPM, still above your asserted top typing speed.
Ah, but why do the usual thing?:) Just look at the whole file and make a good guess... If nothing else, since all config file formats support user comments, it's easy to make the rule that some unique identifier string must exist somewhere in the file, say "$Config file format: Foobbed 1.1$".
But we digress. The more interesting thing about the application is not the format of the config files but in the way they're used by the system... It'd be so nice to have all program data self contained in one directory structure: binaries, libraries, man pages, docs, and config files. And, to have a very simple, standard system component that allows a package to modify it's own config or inspect another package's config with minimal programming overhead. It would never become standard unless it's so easy to use, someone would be brain dead not to use it.
First and foremost is simplicity in every direction: simple installs, simple uninstalls, simple configuration maintenence, simple package relocation, and simple to implement within the program itself. Only after the simplicity guarantee and the proof of concept should bells, whistles, and other handy features be added.
So no, xml may not be ideal for every config, but it gets the job done. And I'm with Miguel 100% that a nice, standard GUI should be primary method of modifying various config files. In the case that a user needs to hand edit a config files 0.01% of the time, there's no real point in supporting multitudinous file formats. It'd just be a bit of icing on the cake of an elegant solution to a problem most people don't even realize exists...
While I agree that it would be nice to have the storage format of the configuration file configurable, I would schedule that feature for the second major release. There's a lot to be said for keeping the first version of an application functional but otherwise as simple as possible.
Later, it would be possible to add autodectection of a number of formats. A good example of the beauty of such a setup is UW's c-client mailbox interface, which transparently detects a number of diverse mailbox formats...
Miguel touches on the mess of configuring services. He proposes a solution for working with existing configuration files using a perl backend and GUI frontend. This is an admirable short term solution for a larger, significant problem.
The inherent problem is that standard unix/etc and/usr and/lib structure was spawned from the mind of a C programmer in which global data is deemed an acceptable solution./etc is a form of global data, which is fragile and inherently carries minimal context. It's fragile in that there's no standard interface to retrieve config properties - so that any program other than the parent of the config file cannot reliably expect to parse it. And, without context, it's unclear which programs depend on a particular config file.
In the spirit of the changes proposed by Miguel, I propose that applications and otherwise all packages be components even in the way they live in the system. Let every package have an arbirary, unique directory, and let everything owned by a package live only in that directory. Let there be a common system component that exposes packages and their configuration on request. Let all packages find and expose other packages only through this component. Let the system package component internally record at most where to find other packages. Further configuration is stored in the package's own directory.
There are a number of advantages to this model:
1. First order installation becomes trivial. Just dump everything into a directory. The system package component will automatically find it.
2. Complete uninstall becomes trivial. Just blow away the package's directory.
3. Exposing a package's configuration is standardized, stable, and protected through the system package component.
4. "Custom" packages and their configuration is trivially persistent across reinstalling the operating system.
This is a problem that has been clumsily attacked by both RPM's and the MS Window's reigstry. Both tried to solve the problem by making prodigious use of massive amounts of internal data - data that is subject to unneccesary and unwanted management and corruption. With the proposed system package component, the small amount of internal data is easily reconstructed by scanning the file system.
If you assert that packages access even their own configuration data through the system package component (much like the interface to a registry), then each package's configuration data can be stored in something standard and sane, like config.xml.
Now, you're just being angry to hear yourself scream.
Let's set some priorities. Oklahoma is hot. I know, I grew up and went to college there. I spent a summer at OSU for an NSF research. It's hot, and some of the dorms don't have air conditioning. And, you're screaming for ethernet access. Give the kids some AC, first.
Hindsight is 20/20, but I say the guys should have just made a friend who had access in their room and masqueraded out.
Also, this is too good to pass up. Through the course of your rant, I think you made yourself puke:
First you say, "... raking in the financial benefits of their talent."
Then you say, "If anyone tries to tell me that NCAA basketball generates much-needed revenue for the university, I think I'll puke."
Slashdot Mirror
I feel I'm raising a valid point.
The GNU GPL requires a enourmous FAQ just to lay the ground rules. I think many people sign up using the GNU GPL without thinking of the implications - it's less a license and more a social movement. There should be a question in that FAQ, "What will the world be like if all software is GNU GPL?" (which is the intent of the GNU GPL given it's virus-like design). And, anyone applying the GNU GPL to their code is implicity agreeing with the philosophy and conclusions of that question. A pervasive GNU GPL would affect our freedom of choice, freedom of expression, and privacy - and the conclusions may not be what you expect. So, at a minimum, users of the GNU GPL should at least think through those issues. And, most don't.
The BSD license, on the other hand, is just that, a license and not a forced social movement. It doesn't try to modify behavior. Because it has fewer overall social implications, it's easier to understand. Consequently, it requires only the most trivial FAQ.
Q1. Can I use the source code in any way I like?
A1. That's right.
Q2. Can I hold you responsible if it doesn't do what I expect it to do?
A2. Nope.
Q3. Fair enough, thanks.
A3. No problem.
--------
K.I.S.S.
Or put it in perspective for people that just use computers: 5ns is time between clock cycles on a 200 MHz machine.
I nominate this to be a Unix fortune.
I am so entirely sick of this extreme chest-puffing and disrespect of actual culture-changing inventions. No, 3D video conferencing is not even close to the advent of the telephone. Acquire and apply some humility.
The telephone gave for the first time real-time two-way communication. 3D video conferencing adds nothing to that essence except a pretty picture. It's still real-time, and it's still communication. Being able to see the other party's postures and gestures is only a marginal improvement, not an earth-shattering achievement.
Growl.
Excuse me? Are we looking at the same C source code? Can you read C?
Because he just wrote over his message with zeros.
Do you maintain that given the message "000000000", you can determine that means "I'm cool!" instead of "You suck!" or any of the other, say, 1e18 possibilties?
And that's his point: it's nothing interesting and it's nothing new. If you can guarantee your stream of random numbers is truly random and only you and your recipient know those random numbers, then any one "decription" by an eavesdropper is no more likely than any other.
I'm too lazy to say more.
I really liked the one in the 4th quarter where the guy sprayed honey all over his camping buddy to escape the bear.
> I'd prefer to use the term "improbable" in that case
I would prefer the term "not unlikely" in that case. I work with computer vision. Given lighting (shading) and texture (warp and texel distribution) cues, a decent, estimated 3-dimensional model can be built from the image. That estimate can be further improved if some high-level information about the scene (human face, box, ball, etc.) is provided or assumed.
But it doesn't matter if you have two cameras if you're only looking at a single, two-dimensional picture. Given that, you, a human, can still draw a good estimate of the 3-dimensional structure of the depicted scene.
Very good. Thank you for the clarification, elaboration, and caveats.
But the point being that in the current IRC topology there are specific, designated servers. By decentralized in the sense of GNUtella, every client acts as a relay server. So, there are no specific servers, there's no pressure point to apply a DDoS. To get on the chat network, then, you need to know the addy of any other client on the chat network. Granted, I'm no network, GNUtella, nor IRC guru, so feel free to correct any of those assertions.
A possible fix: decentralize IRC in the sense of GNUtella. If there aren't any primary server and what "toplevel" server there are aren't static, DDoS brings down at most a small portion of the service. It's time to evolve.
It doesn't matter. The object's second and third largest dimensions are 4 and 9 times the length of the smallest dimension, respectively - regardless of the particular units. Meters are just as arbitrary as feet, anyway. For humans, meters are nice because the system of measurement they're commonly used in exploit powers of 10 (mega, kilo, milli, micro, etc). But, there's nothing to say that base-10 is intuitive to aliens, who probably don't have 10 fingers and toes.
Just invoking the word "bytecode" or compiling a language to bytecode doesn't suddenly make the virtual machine language independent.
Java bytecode, for instance, is significantly tied to the Java language specification. Go browse The Java VM Specification if you like -- classes fields, members, construction, interfaces, and garbage collection are built into the VM.
Admittedly, I am ignorant of Dis code, but when I see "Inferno applications are written in Limbo" in the Inferno FAQ, my confidence in a language independent Inferno VM is shaken.
Java, Inferno. It seems such a waste to design, construct, and optimize virtual machines, then only support a *single* language on that VM. Image the same model for real processors: "The NEW Intel Crapanium!!! Executes C++!". What a joke.
I am neither a Gimp nor Photoshop guru -- an out-of-the comparision is appropriate and valid. For that test, Gimp failed. I changed the Gimp "maximum image size" cache setting (there is no equivalent setting for Photoshop that needs to be tweaked/tuned) and it performed significantly better. But still, overall not nearly as well as Photoshop. Don't take my word for it. Try both programs yourself. Here's an iDrive link to the image I was using: Berkeley_aerial.jpg .
> I can do my editing twice as fast with Gimp than I can with photoshop.
I pieced together a 6200x6200 pixel grayscale aerial photo of Berkeley, CA with images from Terraserver. There were brightness/contrast differences between tiles I wanted to manually tweak.
Editing that image sounds like a big job. But, representing each pixel with a byte (because it's grayscale), the image is 38.4MB. Since I have 128MB of RAM, I thought editing it in Gimp would be feasible. Nope, it just thrashed my swap space. Note, I had to go to a machine with 256MB of RAM just to merge the tiles using ImageMagick.
For the same file, Photoshop performed exceptionally well. For instance, it quickly loaded the image and allowed real-time arbitrary zooming and panning. Of course, I also fixed my brightness/contrast issues. If I took the time to figure out how to batch-append those tiles using Photoshop, I assume it would have been significantly faster than ImageMagick.
Kudos to the Gimp team for building something that is both usable and something people enjoy using. But, I'm getting tired of people proclaiming various open source projects as being superior applications than their commercial counterparts just because they're looking at them through Open Source Beer Goggles. Evaluate the application on its merits, not on its religion.
I suppose I'm peeing into the wind asserting something like this on Slashdot... c'est la vie.
Everyone here has been brainwashed by the idea of censorship. Moderation schemes are exactly backward, effectively letting others (the moderators) select who and what I read.
Let me be the only one who filters what I read. Let there be personal, dynamic, intelligent filtering instead of mob-based moderation.
That is, let my account record moderation that I and only I do to articles. Then, articles are rated (from my perspective only) based on how I've moderated similar aticles in the past. This can be done based on author, keyword matching, whatever -- and should be options in moderation: "I (dont) like this author", "I (dont) like this content", etc.
Done. The beauty? No text gets explicitly censored -- you read the content that you like, not some function of what the group likes. Of course, you should be able to threshold depending on your mood -- where articles are rated, say, 5=must-read to 0=unclassified to -5=dont-read.
It's more complicated to code and takes more server CPU, but all side-effects of the current point moderation systems (that everyone is trying to hack and patch around) are gone.
The assumption "the more volume, the more possible positions of particles in the computer" leading to the eventual conclusion of limits on storage capacity has already been invalidated by modern science.
Apparently, infinite information can be stored in a single atom -- no joke. Check out this this EETimes article -- link courtesy of ArsTechnica.
Summary: Philip Bucksbaum from the University of Michigan has stored and retrieved eight bits of information from the quantum-phase of a single cesium atom. Theoretically, there is no limit on capacity.
I can't talk 100WPM
:p
Ummm... yes you can. Easily. When was the last time you said, "Mississippi one, Mississippi two, Mississippi three"? Saying that at a moderate pace, each vocalized numeral occurs about once a second. So together, that's two words a second, or 120 WPS. A Mississippi is no small word!
With that brief anaylsis, for non-technical text, I'd say it's very reasonable to speak at a steady 200-250 WPS. Type that on your keyboard, then we can talk!
Of course, until someone develops a programming language specifically suited for voice recognition, I won't be coding via voice any time soon.
BTW, that last sentence was 22 words, if you can read it in 6 seconds, that's 220 WPM. Try it. Now say it at half the speed (whoah! that doesn't feel very fast at all) and that's 110 WPM, still above your asserted top typing speed.
- Cory
Ah, but why do the usual thing? :) Just look at the whole file and make a good guess... If nothing else, since all config file formats support user comments, it's easy to make the rule that some unique identifier string must exist somewhere in the file, say "$Config file format: Foobbed 1.1$".
But we digress. The more interesting thing about the application is not the format of the config files but in the way they're used by the system... It'd be so nice to have all program data self contained in one directory structure: binaries, libraries, man pages, docs, and config files. And, to have a very simple, standard system component that allows a package to modify it's own config or inspect another package's config with minimal programming overhead. It would never become standard unless it's so easy to use, someone would be brain dead not to use it.
First and foremost is simplicity in every direction: simple installs, simple uninstalls, simple configuration maintenence, simple package relocation, and simple to implement within the program itself. Only after the simplicity guarantee and the proof of concept should bells, whistles, and other handy features be added.
So no, xml may not be ideal for every config, but it gets the job done. And I'm with Miguel 100% that a nice, standard GUI should be primary method of modifying various config files. In the case that a user needs to hand edit a config files 0.01% of the time, there's no real point in supporting multitudinous file formats. It'd just be a bit of icing on the cake of an elegant solution to a problem most people don't even realize exists...
While I agree that it would be nice to have the storage format of the configuration file configurable, I would schedule that feature for the second major release. There's a lot to be said for keeping the first version of an application functional but otherwise as simple as possible.
Later, it would be possible to add autodectection of a number of formats. A good example of the beauty of such a setup is UW's c-client mailbox interface, which transparently detects a number of diverse mailbox formats...
/etc must die.
/etc and /usr and /lib structure was spawned from the mind of a C programmer in which global data is deemed an acceptable solution. /etc is a form of global data, which is fragile and inherently carries minimal context. It's fragile in that there's no standard interface to retrieve config properties - so that any program other than the parent of the config file cannot reliably expect to parse it. And, without context, it's unclear which programs depend on a particular config file.
/etc!
Miguel touches on the mess of configuring services. He proposes a solution for working with existing configuration files using a perl backend and GUI frontend. This is an admirable short term solution for a larger, significant problem.
The inherent problem is that standard unix
In the spirit of the changes proposed by Miguel, I propose that applications and otherwise all packages be components even in the way they live in the system. Let every package have an arbirary, unique directory, and let everything owned by a package live only in that directory. Let there be a common system component that exposes packages and their configuration on request. Let all packages find and expose other packages only through this component. Let the system package component internally record at most where to find other packages. Further configuration is stored in the package's own directory.
There are a number of advantages to this model:
1. First order installation becomes trivial. Just dump everything into a directory. The system package component will automatically find it.
2. Complete uninstall becomes trivial. Just blow away the package's directory.
3. Exposing a package's configuration is standardized, stable, and protected through the system package component.
4. "Custom" packages and their configuration is trivially persistent across reinstalling the operating system.
This is a problem that has been clumsily attacked by both RPM's and the MS Window's reigstry. Both tried to solve the problem by making prodigious use of massive amounts of internal data - data that is subject to unneccesary and unwanted management and corruption. With the proposed system package component, the small amount of internal data is easily reconstructed by scanning the file system. If you assert that packages access even their own configuration data through the system package component (much like the interface to a registry), then each package's configuration data can be stored in something standard and sane, like config.xml.
I code. If you want help, I'll give it.
Down with global data! Down with
- Cory
Now, you're just being angry to hear yourself scream.
Let's set some priorities. Oklahoma is hot. I know, I grew up and went to college there. I spent a summer at OSU for an NSF research. It's hot, and some of the dorms don't have air conditioning. And, you're screaming for ethernet access. Give the kids some AC, first.
Hindsight is 20/20, but I say the guys should have just made a friend who had access in their room and masqueraded out.
Also, this is too good to pass up. Through the course of your rant, I think you made yourself puke:
First you say, "... raking in the financial benefits of their talent."
Then you say, "If anyone tries to tell me that NCAA basketball generates much-needed revenue for the university, I think I'll puke."
Ehhehe. Baaarf.