Maybe it's just me, but I think E.S.R. simply started out in a UNIX environment. He probably started coding on a TTY connected terminal to a UNIX mainframe. As he learned more and began doing professional programming he became paradigm locked. This is when the information you possess becomes so important to you that you will fight to keep it viable. Many of us have this same trait. Surely, we don't want years of work and training going down the drain, especially so that some young pimple faced 16 year old can just trump anything we've done?
E.S.R knows all the UNIX commands and how to use them. He knows to use forward slashes for pathnames and that the UNIX filesystem is case sensitive by default. He knows that UNIX text files don't contain CR/LF's. And, while he might have resisted the GUI initially, he's now comfortable with it because he can have many CLI's open at once when working on a project that still compiles using make. He's probably fully versed in all the GNU tools. He's probably compiled UNIX kernels many times, adding features for his own personal use. He's created many daemon processes that service both network and interprocess communication.
In short, E.S.R. can't imagine living in any other world except UNIX. It would require some effort to learn Microsoft Visual Studio.NET. It would require some twitching to remmember that the filesystem is case sensitive and that pathnames contain backslashes under Microsoft. He'd have to learn how to recreate daemons as services under the Windows environment. He'd very likely have to understand some COM stuff. He'd have to learn many new things, ways of doing things, and a whole slew of new CLI commands.
When you learn things your brain is rewired. Learning requires energy. It takes work to learn new things and it is expensive. It is much easier to support what you know. It is like balancing a large pole on the end of your hand, it takes work to get it up, but once it's up, it takes very little input to keep it there.
E.S.R is just fighting against the mainstream becuase he started out in a whirlpool. I don't fault him for that. I do however think that we should all do more to learn everything we can. Knowledge is power.
I myself have been accused of worshipping Microsoft, that I think they produce superior products. This is far from the truth, but isn't entirely incorrect. This is for the same reasons of paradigm lock as above. All my early programming years were under 68xx, 68xxx, Z80, x86, Assembler, Basic, C, under DOS, Win31, then Win95, 98, NT4.0, Win2k, Now XP. I've got a whole buttload of knowledge under my belt that I don't want to give up. I might have to give it up, I might not. I don't however like Microsoft all that much. I really have a distaste for what they have been doing in the past few years. I like Open Source Software very much. I don't however like the idea of Free Software. Once something is free, you've reached the bottom of the barrel. You end up giving it away simply because you couldn't sell it otherwise, or you are trying to undercut someone who you don't like...Microsoft gives IE away, sound familiar? However, there are valid reasons for wanting to give something away for free. In the case of Linux, I see a well made OS that is getting better every year. It is a good thing that it is free. It gives me incentive for trying it out. But, again this requires work on my part to re-learn new ways of doing things. If I throw away one command set for another that ends up doing about exactly the same thing just what have I gained or lost?
UNIX runs processes, Windows runs processes. UNIX has commands, Windows has commands. UNIX has CLI and GUI, Windows has CLI and GUI. UNIX has networking, Windows has networking. What is my justification for switching to UNIX? For a child this is a no-brainer. Just learn one, then stick with it. To excel at anything at all in this world you really need to specialize. Of course to be a good sysadmin you need to be a little bit of a jack-of-all-trades, but the point is to not be so loose that you loose track of the vision. That is the problem with most people who have A.D.D. they can't seem to concentrate enough on one thing to get anything accomplished. The other extreme is characterized by the Rain Main syndrome autistism. You don't want to be so focused that you can't move otherwise you might be side-swipped by a moving technology. Is E.S.R too much like a person with A.D.D. or is he being autistic, or is he a very level headed individual?
There is absoulutely nothing wrong with this. You have just described a "namespace" based lookup.
Heirachial file systems are essentially namespaces. If you replace a namespace based system with a sarchable database system then there was probably something wrong with the organization of the namespace in the first place. You certainly wouldn't want to program by changing your namespace based objects into searchable objects...that would be a sheer nightmare! But, there are very good reasons that searchable database systems are preferable to namespaces. Due to the sheer amount of general information to properly organize into namespaces it always isn't practicle to do so. Basically, namespace based systems are at a higher level than searchable databases.
Documents, like Word, or PowerPoint, are chock full of general non-uniform information, so it is a plus to be able to search on this information via a database type system. Don't believe me? Just ask Google!
This is so true. Using Cygwin under Windows is about as intelligent as using Microsoft command shell batch files on UNIX.
Most UNIX'en who have never tried Windows 2k/XP command shell programming are really missing out. Many of the command shell commands are designed to handle the way you do things in the Microsoft world. The way you deal with drive letters, parsing, environment variables, NTFS ACL's, stdio and such. Using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.
Some people do have some valid points about the command shell being too incomplete. Well, I'd have to agree, but I also think this has been a good thing for me. I'm the type of programmer that see's when shell scripting is at its end and jumps to coding a c binary to do something I need speed or complexity for. I don't use scripting for advanced programming. Using shell scripting for real programming is like using Perl to write a database. It's just silly, and I think a waste of time.
Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format. This is so funny to me. It just goes to show why some people (like E.S.R) don't get change. Its almost like they're funtionally illiterate or something. They just learned a few words, then decided that the rest of the vocabulary wasn't needed.
Get with the program, when changing OS's use the native tools! When in Rome?
Yes, but there are at least four kinds of cost that I can think of right now...Money, time, work, and space. Money is simply an invention by man as a stand-in for any one, or a combination of the others.
The "hash cash" system is equivalent to a work system. Your micropayment system is about money. A time/space/work based system could also be used to make it prohibitive for a user to send you mail.
Basically the time/space/work based system prevents the sender from sending without a token, but with an added incentive. The tokens are valid per-user future times in which the sender can transact the send. The tokens are free from the mail server, but change randomly every few seconds. The sender has to request a token then the mail server prevents the sender from sending at that moment, the sender must wait until the token becomes valid. There could be a maximum valid time. This is equivalent to the statement..."you cannot send me mail until I tell you a time when you can". This has the benefit of slowing a spammers sending way way down until you make it uneconomical for them to do the sends. For your friends and business partners, this would not be a problem. The idea only prevents mass-mailers from operating. Of course, this idea is not perfect. You might want to also institute a secondary system that would allow users to assign special access get-in-now tokens for privileged users. These tokens would be handed out by the users themselves for friends, family, mailing-lists, and business partners.
This was a fictional story. I'm sure Carl didn't really think that any signature existed in that sequence. You might not recall, but he was heavily influenced by his wife at the time. You know how irrational women can be.
You are right. The entire bible and koran could be spelled out in the sequence, but so can the ingredients on cereal boxes.
I don't think you are correct. There are no other possible "kind(s) of nature". There are only those that are logically consistent. There are no black white things. There are no infinitely heavy stones that can be lifted by an infinite power. Only those things which are logical are possible. The universe is seen as a giant quantum mechanical machine that is working out every conceivably possible logical outcome. Whenever the possiblity exists that there can be two outcomes of a situation, the universe bifurcates and continues to follow both logical paths. Math is universal because it is based on logic even if it is only a tool. All thinking beings that logically exist will observe the same quantity of PI no matter what base. Beings that don't logically exist, like tall short people don't think.
Yes, but, it is an interesting exercise nonetheless.
Take a 1x1 grid (pixel) with 1 bit color depth. Choose whether you want the pixel on or off. Once you have made your choice, allow a random source generator to randomly flash that pixel on an off at a given rate. What is the likelyhood in a given time period that the pixel will equal your choice? Pretty darn good for a 1x1.
Now change to a 2x2 grid (pixels). Still a 1 bit color depth. Of the four pixels choose which ones you want on and which ones you want off. This is the same as saying...choose a pattern of pixels in the grid that you want enabled. Once you have made your choice, allow a random source generator to randomly flash those pixels on an off at a given rate. What is the likelyhood in a given time period that the pixel will equal your choice? Hmm, this gets to be a little longer, but still reasonable. Within a short period the random generator chooses a pattern that matches yours.
Now keep expanding on this idea for larger and larger grids of pixels. If you choose for example an 8x8 grid, with the letter "A" as your pattern, the likelyhood that the image will be chosen randomly is very poor. It is almost as if it would be easier to choose a random pattern to match up to a random source than to choose something with regularity like the letter "A".
This is very similar to brute force crypto. It is inconceivable that an 800x800 image with 32 bit depth would ever be randomly selected. But, it nonetheless remains possible. As the rate of choosing randomly generated possibilites goes to infinity, the time required to find such a pattern in a given time period goes to zero.
What does this have to do with us? I suppose not much. The universe is not working itself out using random numbers. The universe is working itself out logically. Whenever a possiblity happens that may have an opposite, the universe splits into two. The universe is working out every logically possible state of existance. Only those things which are totally illogical will not happen. For example, if I have a desk with a coffee cup on it at a given location it is certainly possible that the cup could also be at another location on the desk that might contain the cup. The cup can spontaneously vanish and then reappear at the new location. But this is not very likely within a given time period. It is more likely that the cup will remain ever so close to where its current location is. This is the pixel problem referred to above. Ie, it is randomly easier for the universe to choose an alternate logical choice that is quantumly closer to its current state. This is unless we can provide excess energy to boost the rate at which these choices are made.
This is the connection of E=mc2 to quantum mechanics. Adding energy increases the rate at which quantum processes can randomly choose alternate logical possibilities. Given enough energy, all logically possible states are possible within very very short time frames. At the big bang, every conceivably possible logical state was being worked out quantum mechanically.
Of course there is more to this story that includes black holes, light, Beckenstien bound, and unit circles, but that is a subject for another time.
Have fun!:)
Re:MetaVerse - For Real
on
Virtual Simerica
·
· Score: 3, Insightful
I've played a good many video games involving a 3D first person perspective. From Doom, to Quake, to Tribes, to Ultima, to Exile, etc. I am an explorer. Much like Lewis and Clark, I like the experience of travel and discovery. What is over the next ridge? What might I discover in new lands? These days, reality is very limiting. Most of the world has been explored, and travel costs money or time, and extracts its own hardships. I have used video games as an outlet and escape so that I might explore worlds generated in peoples heads.
I have become somewhat disappointed lately. Most companies are churning out junk food video games that do nothing more than give you a headache when you play them. I remember back to when I first ran Doom and how really cool it was to explore all those places in the game. At first, game creators genuinely put there hearts into it. Even add on mods were cool in the old days. I remmember how long I was looking forward to the Wheel of Time. That was a lot of work.
What I've been looking for these days is not some stupid fantasy/magic like game, or Sims type world, but just a place to explore. What would be really cool would be a free universal "world" server engine that allowed each individual to create their own worlds. Each world could be linked together much like web pages are. What would be even more cool would be something like the windows into those other worlds, just like the Quake portal windows in Rocket Arena. You know, the ones you look through before you enter the areanas. You should be able to walk from server to server freely. None of this logging on stuff. A world admin would simply define a portal tag that pointed to another server, just like web pages. Each world would be the creators own expression. I could literally walk around for days through server after server discovering new pages (worlds).
To make things fast and efficient you could do lots of local caching, build the world up as you travelled through it, and have pre-defined objects like tables, chairs, etc. You could order your first DVDRom full of world 3D objects, or download them in real-time. Texture maps should all be local for speed. About the only thing that should travel over the comm channel would be 3D coordinate data, compressed if neccessary.
How about if I see a Mountain in the distance I just walk up to it and start climbing? Tribes was cool because you could walk around the terrain, but it was a bit limited as to what you could do. I have a love and hate relationship with Quake. I like the detail in Quake, but hate not being able to "go outside". For psychological reasons it is very important for th mind to wrap itself around a setting, a location via visual ques. This is what was so cool about Doom the first time I played it. Even though I couldn't "go outside", their were mountains in the background image that game me a comfortable locational feeling.
Ideally, anyone could run these world servers. They wouldn't be vendor specific. The protocol would be open and would become the defacto standard for 3D exploration, just like the web has for document browsing. I'd love to start this project myself and do a master's thesis on it, but I believe it would take someone of Carmack's level to do it right. And, most importantly, the service should be free. Only the client should cost money, a one-time-cost of around 20 bucks. Upgrades would just give you compatibility with the latest protocol extensions while giving you better graphics. This would be similar to a SMTP system.
That is what I'm looking for. I'm really looking forward to Myst Online, but I'm afraid it will cost too much money to be useful to me. I like the ID/Quake model of supply and demand...sell the client, and let the users play for free.
Anybody else know why the gaming industry keeps putting out junk?
There are at least two known technical ways to stop spam that would absoulutely work. The first is to make mail sending a cost to the senders by charging for the SMTP connection. This would be a charge to a credit account. I'm sure credit card companies would love this because they would get a kick-back for every email sent. The second method is to make sending email a time prohibitive cost. Here's how the second method would work...
Add an addendum to the SMTP protocol RFC that would require all senders to first request an authorization code from the mail server before they can submit mail to the recipient. The sender requests the authorization code, which changes maybe hourly, or daily, depending on the SMTP configuration, then the SMTP server delays by a known period of time the result of that request. So, for each user that the spammer mails, the mail server effectively delays the spammer from sending by a small amount of time.
No longer will email addresses be global drop boxes. The power of the net will be returned to the hands of the people. In the future, you should need an authorization code to drop mail in my box, otherwise the mail is bounced.
Extending this idea, the authorization codes could be per-server, per-user, per-group, or all. Each user could also have his or her authorization codes. You could provide global authorization codes for each of your service providers to get through instantly, or alternatively, post your authorization codes on your personal web sites.
As soon as these authorization codes have become known as the defacto email protocol. Spamming should dissapear as we know it. To start the process rolling, each organization would adopt authorization codes on a as-need basis.
This needs to be implemented. Quick, someone write up an RFC extension to SMTP before this spamming gets even more out of hand!
"If I corrupt my registry, or alter a key in such a way that the system cannot boot..."
Ummm, strange. Look at it this way, you...don't have access to modify the registry files directly, the OS has a lock on the registry HIVES, so you can't modify them without going through the API's. If you go through the API's you can't do anything strange to muck them up because the interface rules are enforced. The only way the registry can become "corrupted" is if the file system becomes corrupted. If your file system has become corrupted you are having a much larger issue to deal with.
If you manage to change an important registry value using the API's correctly so that "system cannot boot" well that is no different than using any text editor under *nix to change your config file values. And...
"...MS doesn't include a console-based editor..."...so, what you are saying is...you can't boot your OS at all (because you mucked it up), and you are going to edit the registry at the recovery console? Maybe. How about your mom? Ok, I agree here, for techies maybe this would be cool. But, as a techie, I can already mount a bad machine's registry by removing its hard disk, and popping it into another working machine.
"...*should* have an embedded format number..."
Another strange one. The registry is chock full of typed values and format numbers for applications.
"The MacOS has preferences files *with* (optionally) a structured format (resources)."
Yea, I know about the MAC, and how Apple stores their application data using alternate file streams. You can do the same thing under Windows but very few programmers use that feature. Alternate file streams are standard under NTFS 5.0...go to google and search on...
"NTFS alternate streams"
(no quotes)
In theory, a Windows application could simply store a sub-registry hive for its config settings into the alternate data stream, then mount the thing into the OS registry, and whooosh, you've got an app where it's config settings follow the EXE around. I've never seen this done, but the principle is sound.
"...vastly more sophisticated in format than the simple three datatypes that the registry can handle."
What? You just a casual Windows user then? Not a programmer eh? Yea, I know your type, you probably just run regedit and think that is all there is to the registry. No, there are many more datatypes unseen. Microsoft only provides three in the simple regedit tool. Applications have access to many more through the real registry API. See...
I won't even comment on ascii text config files being "sophisticated", but, they are spread rather randomly, haphazardly throughout the *nix, hierarchical filesystem. The mess of user home directories is ridiculous.
"...software thinking it can modify other software's registry entries, and thereby causing all sorts of problems."
This is no different than any other OS that uses file system based config files. Again, look at a *nix user's home directory! I did say that the registry was ACL enforced.
For all those who never understood what the true nature of the Windows registry is about...
The Registry was created for the purpose of storing and retrieving local OS and application configuration data in a convienient and highly organized way. In this manner the registry is simply seen as a local database that the OS has direct access to. An operating system process database so to speak.
On the list of registry requirements is speed. The registry is optimized for extremely high speed reads as well as writes. It was discovered early on that storing small amounts of information such as Bytes, Words, Strings, and such directly on the file system in separate files was a problem. Opening, reading, and closing files requires many I/O operations which eats up CPU, and can be taxing on the hardware subsystems. Hard drive caching and file caching can prevent some of the problems caused but do not really provide an adequate solution.
Another issue is that small data elements don't make effective use of the allocated disk space. Especially in the early days with small hard drives this was a BIG issue. You certainly don't want to open a file, save a byte, and close the file. You might end up using a whole sector. Depending on which filesystem type you used, you could lose almost half your disk just by storing small files. With text files the problem is even worse. You end up opening the file, parsing out the data with routines, then converting it to the data type you need. By nature, text representations of the data values will be larger, wasting valuable disk space.
As we have seen with network database access, a database access protocol optimized for high speed reads is important. The LDAP specification addresses some of these concerns. As well with the registry, we need the ability to store and retrieve data fast with minimal space cost. Microsoft decided to create a set of files called HIVEs that are essentially open from the moment the OS boots. The OS caches these HIVEs in memory. The OS as well as applications have access to the HIVEs through a special set of high speed access APIs. All the APIs need for access to a HIVE is its global handle value.
The HIVEs are organized hierarchically similar to a file system. This makes a registry HIVE exactly like a "file system on top of a file system". In this case since a HIVE is stored on the real file system as a single contiguous block and always open, it makes disk space efficient and I/O fast. Its just a specialized mini file system database for configuration data.
Key names in the HIVEs are folders. The keys contain registry values which contain the actual data. The values are typed so as to also maximize speed. There are user, software, and system data HIVEs. HIVEs can be mounted or unmounted, and symlinks can be created from one key to another. Registry keys can be protected with the same ACL protection mechanism that NTFS uses.
If you want to see how fast the registry is in action just download the regmon.exe probe from www.sysinternals.com and watch what happens when you do anything in Windows. The amazing dependencies that make themselves apparent by watching regmon can easily show you that doing I/O out to disk would cause everything to slow to a crawl, as well as put more pressure on your already loaded disk I/O system.
Registry key values are NOT made to store large amounts of data. You aren't supposed to store entire files as value data. Indeed, that would make what the registry was made for pointless. One of the problems is that many application programmers either don't understand how to use the registry correctly, or just use it for the wrong purpose. The current registry is BIG. The information stored in the registry has gotten out of hand. Even Microsoft can't stop storing useless information in there. It is easy to say that the registry might become corrupted, but this also happens with file systems themselves. You do occasionally have to run a file system check. Ever lost a binary database file before?
Data in the registy can be easily back'ed up using the regedit tool that comes with the OS. You simply export what you need to a text file. The text file can then be re-imported later when needed. If you want to backup a whole HIVE file such as SOFTWARE you can do that too. Many backup utilities will do exactly that. It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS). I really don't see the problem with registry backups. And hey, in the end, the registy is just a simple set of files stored on the filesystem just like any other files in *nix.
Since the registry API is in effect and abstraction layer, Microsoft could re-write the back-end completely. What about a network registry? We could relocate the files out onto a network server and the applications wouldn't know. Microsoft could encrypt the data, compress it, whatever. I don't know what Microsoft's future plans are for the registry interface. Any of these things would make access slower so I expect that the design will stay the way it is for now.
We all have fast and big hard drives these days so the registry does seem kind of pointless. But if we were all using slow small drives we would really appreciate the technical merits of the registry. Even more so, users of a registry can now enjoy that their data is being store both effectively and efficiently. Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like. But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
I am not so sure we are that close. The problem is similar to the Grand Unified Theory of physics. No one yet has figured out the link between the quantum world and gravity. And so in AI, no one, that I know of has worked out the theory and algoritmic design for a machine that does pattern recognition, and reflects on those patterns to store, think, and learn.
A simple example of the inability of a machine to do simple work is listening to a stream of audio, then asking it to pick out sections of the stream that it has heard before. When we see a commercial for example, we usually decide in a few seconds whether we have seen or heard it before.
Maybe the problem is we just need to throw more horsepower at it, but somehow I doubt it.
I am optimistic we will find a solution. Someone just needs to think a little harder about the problem.
Evolution is a bit more deep than your overgeneralization. It turns out having too many children in a generation can be just as detrimental as too few. Evolution is self-correcting, so that a whole population of a given species can't win. The concept known as the Evolutionary Stable Strategy, or ESS, is pretty cool. It's a mathematical way of assigning a cost-benefit analysis to the evolution game. In some cases even the Prisoners Delimma fits in somewhere. You probably need to read Richard Dawkin's "The Selfish Gene". Once you 'get' evolution, it's beauty and simple effectiveness can still astound you.
For all those who never understood what the true nature of the Windows registry is about this thread emphasizes the point.
The Registry was created for the purpose of storing and retrieving local OS and application configuration data in a convienient and highly organized way. In this manner the registry is simply seen as a local database that the OS has direct access to. An operating system process database so to speak.
On the list of registry requirements is speed. The registry is optimized for extremely high speed reads as well as writes. It was discovered early on that storing small amounts of information such as Bytes, Words, Strings, and such directly on the file system in separate files was a problem. Opening, reading, and closing files requires many I/O operations which eats up CPU, and can be taxing on the hardware subsystems. Hard drive caching and file caching can prevent some of the problems caused but do not really provide an adequate solution.
Another issue is that small data elements don't make effective use of the allocated disk space. Especially in the early days with small hard drives this was a BIG issue. You certainly don't want to open a file, save a byte, and close the file. You might end up using a whole sector. Depending on which filesystem type you used, you could lose almost half your disk just by storing small files. With text files the problem is even worse. You end up opening the file, parsing out the data with routines, then converting it to the data type you need. By nature, text representations of the data values will be larger, wasting valuable disk space.
As we have seen with network database access, a database access protocol optimized for high speed reads is important. The LDAP specification addresses some of these concerns. As well with the registry, we need the ability to store and retrieve data fast with minimal space cost. Microsoft decided to create a set of files called HIVEs that are essentially open from the moment the OS boots. The OS caches these HIVEs in memory. The OS as well as applications have access to the HIVEs through a special set of high speed access APIs. All the APIs need for access to a HIVE is its global handle value.
The HIVEs are organized hierarchically similar to a file system. This makes a registry HIVE exactly like a "file system on top of a file system". In this case since a HIVE is stored on the real file system as a single contiguous block and always open, it makes disk space efficient and I/O fast. Its just a specialized mini file system database for configuration data.
Key names in the HIVEs are folders. The keys contain registry values which contain the actual data. The values are typed so as to also maximize speed. There are user, software, and system data HIVEs. HIVEs can be mounted or unmounted, and symlinks can be created from one key to another. Registry keys can be protected with the same ACL protection mechanism that NTFS uses.
If you want to see how fast the registry is in action just download the regmon.exe probe from www.sysinternals.com and watch what happens when you do anything in Windows. The amazing dependencies that make themselves apparent by watching regmon can easily show you that doing I/O out to disk would cause everything to slow to a crawl, as well as put more pressure on your already loaded disk I/O system.
Registry key values are NOT made to store large amounts of data. You aren't supposed to store entire files as value data. Indeed, that would make what the registry was made for pointless. One of the problems is that many application programmers either don't understand how to use the registry correctly, or just use it for the wrong purpose. The current registry is BIG. The information stored in the registry has gotten out of hand. Even Microsoft can't stop storing useless information in there. It is easy to say that the registry might become corrupted, but this also happens with file systems themselves. You do occasionally have to run a file system check. Ever lost a binary database file before?
Data in the registy can be easily back'ed up using the regedit tool that comes with the OS. You simply export what you need to a text file. The text file can then be re-imported later when needed. If you want to backup a whole HIVE file such as SOFTWARE you can do that too. Many backup utilities will do exactly that. It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS). I really don't see the problem with registry backups. And hey, in the end, the registy is just a simple set of files stored on the filesystem just like any other files in *nix.
Since the registry API is in effect and abstraction layer, Microsoft could re-write the back-end completely. What about a network registry? We could relocate the files out onto a network server and the applications wouldn't know. Microsoft could encrypt the data, compress it, whatever. I don't know what Microsoft's future plans are for the registry interface. Any of these things would make access slower so I expect that the design will stay the way it is for now.
We all have fast and big hard drives these days so the registry does seem kind of pointless. But if we were all using slow small drives we would really appreciate the technical merits of the registry. Even more so, users of a registry can now enjoy that their data is being store both effectively and efficiently. Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like. But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
"Tube power amps sound just a little bit better than their solid-state counterparts."
Here's a perfect example of...cave men clinging to the flat earth idea, creationists bashing evolution, and as P. T. Barnum said "There's a sucker born every minute".
These tube mobo's are made for people by marketing types who know there's a market out there of suckers to be sold to. A little electrical engineering and testing will show you that tube amps add distortion, filtering, and noise to any signal that needs to be reproduced by amplification. Here is the critical point...SIGNAL CREATION IS NOT SIGNAL REPRODUCTION.
Yes, tube amps are cool with guitar and other sound generating devices to add color and effect to the signal for the point of getting that nice sound. But, as soon as you've got the sound you want to chisel in stone, you don't want it trashed by some bad reproduction equipment. The art of reproducing sound is the art of not adding or changing anything about the original signal at all!
This is why tubes should never ever be used in mobo's or other stereo equipment where you want to reproduce the original recorded sound perfectly. A pure audiophile never ever drives their amps into the clipping region, that colors and adds distortion to the sound. Signal in, should be amplified signal out, that is all. There should be no noise, no harmonic distortion, no phase changing, etc. Everything should be 1:1 except for the gain.
I'm sure you may be right that tube amps just "sound a little better", but that's only if you are playing "Motley Crue" overdriven into a 1000 watt stack while the signal disappears into just square waves clipped at the peaks. Why don't you just convert the signal into square waves and put some muffs into you ears, that would probably sound a little sweeter too.
If you continue to use the same OTP over and over, you risk the possibility that the pad will be found-out by other methods. If the message has been decrypted as plaintext and stored, then your store was broken into, you could use the plaintext message to discover the continuous use pad. This is the idea, that changing the pads prevents this kind of crack. Once the message has been decrypted, you throw away the pad that was used to encrypt it forever.
This should be fine for Internet packet based communication. IP packets are less than 64K in size due to router constraints. So the maximum OTP you would ever need would be 64K. Is there something here that I'm missing?
The standard disclaimer is that yes, a OTP -is- unbreakable. So the obvious solution is to create a secured connection with the OTP, then rotate in new pads through the transmission channel, replacing the pads at every transaction. You also need to make the pad sizes randomly variable. This should work, but you'd better have good ack/nak or once the pads get out of sync, you are hosed. Of course you could then create an algorithm for dropping-back to previously used pads until your clients regain sync, but that would be risky.
You also need to make sure your clients have good random number generators on each end. So you might create USB keychain drives with random number electronics that monitor weather conditions, magnetic direction, sound, etc, plus a user selected user input XOR seed.
The upshot of all this work would be that your session would slow considerably. The methods of securing connections are inversely proportional to the bandwidth required.
...many Europeans still don't believe people have actually landed on the North American continent!
Many believe that life on other continents is just to absurd an idea to take seriously. Or, if life is there, the ocean is just too big a distance to cross, so we will never know.
In fact there is an European internet project called SATI@home, or Search for American Territories Intelligence, that is listening for intelligent life in North America. This project may fail though. If there is life in North America, it is likely that Europeans would never be able to decode the meaning of any of the messages or culture.
Many Europeans think its all just political mumbo jumbo anyway.;)
"The concept most foreign in all religions is that of a universe existing forever. Beginnings and endings are a fools dream." -Anonymous
I manage the computer network for another UNC system campus. We've been Internet connected since at least '90. We saw this bandwidth problem coming early on. Setting up the dorms on campus to our existing infrastructure was found to be too costly. We instead opted to contract Time Warner RoadRunner service for the dorms and let them handle the traffic. This has turned out ok so far, and it keeps our legitimate university traffic low. This lets us manage or own lab, faculty, staff, server systems without having to bother with student connectivity issues. Universities supplying students with what amounts to 'free' bandwidth are just asking for it. I used to be a student so I know!
We are also connected to NCREN so getting to campus from Time Warner RoadRunner can require as many as 18 hops with an average ping of 60-70ms.
Back in early '96 I used to run a couple of Quake servers on campus for fun. I miss those Internet frontier days.
What i'd really like to know is, which version will it be? The original, which air'ed in Sept-Nov 80 on PBS was great. Turner bought the rights to sell the series later and trashed it. The music is changed and various selections have been modified. How do I know? I've got the originals and I've compared to Turners version. Its a damn shame I tell ya. A damn shame!
Rod
Slashdot Mirror
Yea, but VB had these features 10 years ago.
Come back down and live with us.
Maybe it's just me, but I think E.S.R. simply started out in a UNIX environment. He probably started coding on a TTY connected terminal to a UNIX mainframe. As he learned more and began doing professional programming he became paradigm locked. This is when the information you possess becomes so important to you that you will fight to keep it viable. Many of us have this same trait. Surely, we don't want years of work and training going down the drain, especially so that some young pimple faced 16 year old can just trump anything we've done?
.NET. It would require some twitching to remmember that the filesystem is case sensitive and that pathnames contain backslashes under Microsoft. He'd have to learn how to recreate daemons as services under the Windows environment. He'd very likely have to understand some COM stuff. He'd have to learn many new things, ways of doing things, and a whole slew of new CLI commands.
E.S.R knows all the UNIX commands and how to use them. He knows to use forward slashes for pathnames and that the UNIX filesystem is case sensitive by default. He knows that UNIX text files don't contain CR/LF's. And, while he might have resisted the GUI initially, he's now comfortable with it because he can have many CLI's open at once when working on a project that still compiles using make. He's probably fully versed in all the GNU tools. He's probably compiled UNIX kernels many times, adding features for his own personal use. He's created many daemon processes that service both network and interprocess communication.
In short, E.S.R. can't imagine living in any other world except UNIX. It would require some effort to learn Microsoft Visual Studio
When you learn things your brain is rewired. Learning requires energy. It takes work to learn new things and it is expensive. It is much easier to support what you know. It is like balancing a large pole on the end of your hand, it takes work to get it up, but once it's up, it takes very little input to keep it there.
E.S.R is just fighting against the mainstream becuase he started out in a whirlpool. I don't fault him for that. I do however think that we should all do more to learn everything we can. Knowledge is power.
I myself have been accused of worshipping Microsoft, that I think they produce superior products. This is far from the truth, but isn't entirely incorrect. This is for the same reasons of paradigm lock as above. All my early programming years were under 68xx, 68xxx, Z80, x86, Assembler, Basic, C, under DOS, Win31, then Win95, 98, NT4.0, Win2k, Now XP. I've got a whole buttload of knowledge under my belt that I don't want to give up. I might have to give it up, I might not. I don't however like Microsoft all that much. I really have a distaste for what they have been doing in the past few years. I like Open Source Software very much. I don't however like the idea of Free Software. Once something is free, you've reached the bottom of the barrel. You end up giving it away simply because you couldn't sell it otherwise, or you are trying to undercut someone who you don't like...Microsoft gives IE away, sound familiar? However, there are valid reasons for wanting to give something away for free. In the case of Linux, I see a well made OS that is getting better every year. It is a good thing that it is free. It gives me incentive for trying it out. But, again this requires work on my part to re-learn new ways of doing things. If I throw away one command set for another that ends up doing about exactly the same thing just what have I gained or lost?
UNIX runs processes, Windows runs processes. UNIX has commands, Windows has commands. UNIX has CLI and GUI, Windows has CLI and GUI. UNIX has networking, Windows has networking. What is my justification for switching to UNIX? For a child this is a no-brainer. Just learn one, then stick with it. To excel at anything at all in this world you really need to specialize. Of course to be a good sysadmin you need to be a little bit of a jack-of-all-trades, but the point is to not be so loose that you loose track of the vision. That is the problem with most people who have A.D.D. they can't seem to concentrate enough on one thing to get anything accomplished. The other extreme is characterized by the Rain Main syndrome autistism. You don't want to be so focused that you can't move otherwise you might be side-swipped by a moving technology. Is E.S.R too much like a person with A.D.D. or is he being autistic, or is he a very level headed individual?
Keep the peace. Troll - Off topic.
rmd
There is absoulutely nothing wrong with this. You have just described a "namespace" based lookup.
Heirachial file systems are essentially namespaces. If you replace a namespace based system with a sarchable database system then there was probably something wrong with the organization of the namespace in the first place. You certainly wouldn't want to program by changing your namespace based objects into searchable objects...that would be a sheer nightmare! But, there are very good reasons that searchable database systems are preferable to namespaces. Due to the sheer amount of general information to properly organize into namespaces it always isn't practicle to do so. Basically, namespace based systems are at a higher level than searchable databases.
Documents, like Word, or PowerPoint, are chock full of general non-uniform information, so it is a plus to be able to search on this information via a database type system. Don't believe me? Just ask Google!
This is so true. Using Cygwin under Windows is about as intelligent as using Microsoft command shell batch files on UNIX.
Most UNIX'en who have never tried Windows 2k/XP command shell programming are really missing out. Many of the command shell commands are designed to handle the way you do things in the Microsoft world. The way you deal with drive letters, parsing, environment variables, NTFS ACL's, stdio and such. Using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.
Some people do have some valid points about the command shell being too incomplete. Well, I'd have to agree, but I also think this has been a good thing for me. I'm the type of programmer that see's when shell scripting is at its end and jumps to coding a c binary to do something I need speed or complexity for. I don't use scripting for advanced programming. Using shell scripting for real programming is like using Perl to write a database. It's just silly, and I think a waste of time.
Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format. This is so funny to me. It just goes to show why some people (like E.S.R) don't get change. Its almost like they're funtionally illiterate or something. They just learned a few words, then decided that the rest of the vocabulary wasn't needed.
Get with the program, when changing OS's use the native tools! When in Rome?
Yes, but there are at least four kinds of cost that I can think of right now...Money, time, work, and space. Money is simply an invention by man as a stand-in for any one, or a combination of the others.
The "hash cash" system is equivalent to a work system. Your micropayment system is about money. A time/space/work based system could also be used to make it prohibitive for a user to send you mail.
Basically the time/space/work based system prevents the sender from sending without a token, but with an added incentive. The tokens are valid per-user future times in which the sender can transact the send. The tokens are free from the mail server, but change randomly every few seconds. The sender has to request a token then the mail server prevents the sender from sending at that moment, the sender must wait until the token becomes valid. There could be a maximum valid time. This is equivalent to the statement..."you cannot send me mail until I tell you a time when you can". This has the benefit of slowing a spammers sending way way down until you make it uneconomical for them to do the sends. For your friends and business partners, this would not be a problem. The idea only prevents mass-mailers from operating. Of course, this idea is not perfect. You might want to also institute a secondary system that would allow users to assign special access get-in-now tokens for privileged users. These tokens would be handed out by the users themselves for friends, family, mailing-lists, and business partners.
Oh well, just a thought.
This was a fictional story. I'm sure Carl didn't really think that any signature existed in that sequence. You might not recall, but he was heavily influenced by his wife at the time. You know how irrational women can be.
You are right. The entire bible and koran could be spelled out in the sequence, but so can the ingredients on cereal boxes.
I don't think you are correct. There are no other possible "kind(s) of nature". There are only those that are logically consistent. There are no black white things. There are no infinitely heavy stones that can be lifted by an infinite power. Only those things which are logical are possible. The universe is seen as a giant quantum mechanical machine that is working out every conceivably possible logical outcome. Whenever the possiblity exists that there can be two outcomes of a situation, the universe bifurcates and continues to follow both logical paths. Math is universal because it is based on logic even if it is only a tool. All thinking beings that logically exist will observe the same quantity of PI no matter what base. Beings that don't logically exist, like tall short people don't think.
More than 'nuff said.
Yes, but, it is an interesting exercise nonetheless.
:)
Take a 1x1 grid (pixel) with 1 bit color depth. Choose whether you want the pixel on or off. Once you have made your choice, allow a random source generator to randomly flash that pixel on an off at a given rate. What is the likelyhood in a given time period that the pixel will equal your choice? Pretty darn good for a 1x1.
Now change to a 2x2 grid (pixels). Still a 1 bit color depth. Of the four pixels choose which ones you want on and which ones you want off. This is the same as saying...choose a pattern of pixels in the grid that you want enabled. Once you have made your choice, allow a random source generator to randomly flash those pixels on an off at a given rate. What is the likelyhood in a given time period that the pixel will equal your choice? Hmm, this gets to be a little longer, but still reasonable. Within a short period the random generator chooses a pattern that matches yours.
Now keep expanding on this idea for larger and larger grids of pixels. If you choose for example an 8x8 grid, with the letter "A" as your pattern, the likelyhood that the image will be chosen randomly is very poor. It is almost as if it would be easier to choose a random pattern to match up to a random source than to choose something with regularity like the letter "A".
This is very similar to brute force crypto. It is inconceivable that an 800x800 image with 32 bit depth would ever be randomly selected. But, it nonetheless remains possible. As the rate of choosing randomly generated possibilites goes to infinity, the time required to find such a pattern in a given time period goes to zero.
What does this have to do with us? I suppose not much. The universe is not working itself out using random numbers. The universe is working itself out logically. Whenever a possiblity happens that may have an opposite, the universe splits into two. The universe is working out every logically possible state of existance. Only those things which are totally illogical will not happen. For example, if I have a desk with a coffee cup on it at a given location it is certainly possible that the cup could also be at another location on the desk that might contain the cup. The cup can spontaneously vanish and then reappear at the new location. But this is not very likely within a given time period. It is more likely that the cup will remain ever so close to where its current location is. This is the pixel problem referred to above. Ie, it is randomly easier for the universe to choose an alternate logical choice that is quantumly closer to its current state. This is unless we can provide excess energy to boost the rate at which these choices are made.
This is the connection of E=mc2 to quantum mechanics. Adding energy increases the rate at which quantum processes can randomly choose alternate logical possibilities. Given enough energy, all logically possible states are possible within very very short time frames. At the big bang, every conceivably possible logical state was being worked out quantum mechanically.
Of course there is more to this story that includes black holes, light, Beckenstien bound, and unit circles, but that is a subject for another time.
Have fun!
I've played a good many video games involving a 3D first person perspective. From Doom, to Quake, to Tribes, to Ultima, to Exile, etc. I am an explorer. Much like Lewis and Clark, I like the experience of travel and discovery. What is over the next ridge? What might I discover in new lands? These days, reality is very limiting. Most of the world has been explored, and travel costs money or time, and extracts its own hardships. I have used video games as an outlet and escape so that I might explore worlds generated in peoples heads.
I have become somewhat disappointed lately. Most companies are churning out junk food video games that do nothing more than give you a headache when you play them. I remember back to when I first ran Doom and how really cool it was to explore all those places in the game. At first, game creators genuinely put there hearts into it. Even add on mods were cool in the old days. I remmember how long I was looking forward to the Wheel of Time. That was a lot of work.
What I've been looking for these days is not some stupid fantasy/magic like game, or Sims type world, but just a place to explore. What would be really cool would be a free universal "world" server engine that allowed each individual to create their own worlds. Each world could be linked together much like web pages are. What would be even more cool would be something like the windows into those other worlds, just like the Quake portal windows in Rocket Arena. You know, the ones you look through before you enter the areanas. You should be able to walk from server to server freely. None of this logging on stuff. A world admin would simply define a portal tag that pointed to another server, just like web pages. Each world would be the creators own expression. I could literally walk around for days through server after server discovering new pages (worlds).
To make things fast and efficient you could do lots of local caching, build the world up as you travelled through it, and have pre-defined objects like tables, chairs, etc. You could order your first DVDRom full of world 3D objects, or download them in real-time. Texture maps should all be local for speed. About the only thing that should travel over the comm channel would be 3D coordinate data, compressed if neccessary.
How about if I see a Mountain in the distance I just walk up to it and start climbing? Tribes was cool because you could walk around the terrain, but it was a bit limited as to what you could do. I have a love and hate relationship with Quake. I like the detail in Quake, but hate not being able to "go outside". For psychological reasons it is very important for th mind to wrap itself around a setting, a location via visual ques. This is what was so cool about Doom the first time I played it. Even though I couldn't "go outside", their were mountains in the background image that game me a comfortable locational feeling.
Ideally, anyone could run these world servers. They wouldn't be vendor specific. The protocol would be open and would become the defacto standard for 3D exploration, just like the web has for document browsing. I'd love to start this project myself and do a master's thesis on it, but I believe it would take someone of Carmack's level to do it right. And, most importantly, the service should be free. Only the client should cost money, a one-time-cost of around 20 bucks. Upgrades would just give you compatibility with the latest protocol extensions while giving you better graphics. This would be similar to a SMTP system.
That is what I'm looking for. I'm really looking forward to Myst Online, but I'm afraid it will cost too much money to be useful to me. I like the ID/Quake model of supply and demand...sell the client, and let the users play for free.
Anybody else know why the gaming industry keeps putting out junk?
How To Stop EMail SPAM 101
:)
There are at least two known technical ways to stop spam that would absoulutely work. The first is to make mail sending a cost to the senders by charging for the SMTP connection. This would be a charge to a credit account. I'm sure credit card companies would love this because they would get a kick-back for every email sent. The second method is to make sending email a time prohibitive cost. Here's how the second method would work...
Add an addendum to the SMTP protocol RFC that would require all senders to first request an authorization code from the mail server before they can submit mail to the recipient. The sender requests the authorization code, which changes maybe hourly, or daily, depending on the SMTP configuration, then the SMTP server delays by a known period of time the result of that request. So, for each user that the spammer mails, the mail server effectively delays the spammer from sending by a small amount of time.
No longer will email addresses be global drop boxes. The power of the net will be returned to the hands of the people. In the future, you should need an authorization code to drop mail in my box, otherwise the mail is bounced.
Extending this idea, the authorization codes could be per-server, per-user, per-group, or all. Each user could also have his or her authorization codes. You could provide global authorization codes for each of your service providers to get through instantly, or alternatively, post your authorization codes on your personal web sites.
As soon as these authorization codes have become known as the defacto email protocol. Spamming should dissapear as we know it. To start the process rolling, each organization would adopt authorization codes on a as-need basis.
This needs to be implemented. Quick, someone write up an RFC extension to SMTP before this spamming gets even more out of hand!
Thanks for your time.
"If I corrupt my registry, or alter a key in such a way that the system cannot boot..."
...so, what you are saying is...you can't boot your OS at all (because you mucked it up), and you are going to edit the registry at the recovery console? Maybe. How about your mom? Ok, I agree here, for techies maybe this would be cool. But, as a techie, I can already mount a bad machine's registry by removing its hard disk, and popping it into another working machine.
r l= /library/en-us/sysinfo/base/registry_value_types.a sp
;)
Ummm, strange. Look at it this way, you...don't have access to modify the registry files directly, the OS has a lock on the registry HIVES, so you can't modify them without going through the API's. If you go through the API's you can't do anything strange to muck them up because the interface rules are enforced. The only way the registry can become "corrupted" is if the file system becomes corrupted. If your file system has become corrupted you are having a much larger issue to deal with.
If you manage to change an important registry value using the API's correctly so that "system cannot boot" well that is no different than using any text editor under *nix to change your config file values. And...
"...MS doesn't include a console-based editor..."
"...*should* have an embedded format number..."
Another strange one. The registry is chock full of typed values and format numbers for applications.
"The MacOS has preferences files *with* (optionally) a structured format (resources)."
Yea, I know about the MAC, and how Apple stores their application data using alternate file streams. You can do the same thing under Windows but very few programmers use that feature. Alternate file streams are standard under NTFS 5.0...go to google and search on...
"NTFS alternate streams"
(no quotes)
In theory, a Windows application could simply store a sub-registry hive for its config settings into the alternate data stream, then mount the thing into the OS registry, and whooosh, you've got an app where it's config settings follow the EXE around. I've never seen this done, but the principle is sound.
"...vastly more sophisticated in format than the simple three datatypes that the registry can handle."
What? You just a casual Windows user then? Not a programmer eh? Yea, I know your type, you probably just run regedit and think that is all there is to the registry. No, there are many more datatypes unseen. Microsoft only provides three in the simple regedit tool. Applications have access to many more through the real registry API. See...
http://msdn.microsoft.com/library/default.asp?u
I won't even comment on ascii text config files being "sophisticated", but, they are spread rather randomly, haphazardly throughout the *nix, hierarchical filesystem. The mess of user home directories is ridiculous.
"...software thinking it can modify other software's registry entries, and thereby causing all sorts of problems."
This is no different than any other OS that uses file system based config files. Again, look at a *nix user's home directory! I did say that the registry was ACL enforced.
"You ever seen an XPM?"
Yea, X Window pixmap format...lol!
For all those who never understood what the true nature of the Windows registry is about...
The Registry was created for the purpose of storing and retrieving local OS and application configuration data in a convienient and highly organized way. In this manner the registry is simply seen as a local database that the OS has direct access to. An operating system process database so to speak.
On the list of registry requirements is speed. The registry is optimized for extremely high speed reads as well as writes. It was discovered early on that storing small amounts of information such as Bytes, Words, Strings, and such directly on the file system in separate files was a problem. Opening, reading, and closing files requires many I/O operations which eats up CPU, and can be taxing on the hardware subsystems. Hard drive caching and file caching can prevent some of the problems caused but do not really provide an adequate solution.
Another issue is that small data elements don't make effective use of the allocated disk space. Especially in the early days with small hard drives this was a BIG issue. You certainly don't want to open a file, save a byte, and close the file. You might end up using a whole sector. Depending on which filesystem type you used, you could lose almost half your disk just by storing small files. With text files the problem is even worse. You end up opening the file, parsing out the data with routines, then converting it to the data type you need. By nature, text representations of the data values will be larger, wasting valuable disk space.
As we have seen with network database access, a database access protocol optimized for high speed reads is important. The LDAP specification addresses some of these concerns. As well with the registry, we need the ability to store and retrieve data fast with minimal space cost. Microsoft decided to create a set of files called HIVEs that are essentially open from the moment the OS boots. The OS caches these HIVEs in memory. The OS as well as applications have access to the HIVEs through a special set of high speed access APIs. All the APIs need for access to a HIVE is its global handle value.
The HIVEs are organized hierarchically similar to a file system. This makes a registry HIVE exactly like a "file system on top of a file system". In this case since a HIVE is stored on the real file system as a single contiguous block and always open, it makes disk space efficient and I/O fast. Its just a specialized mini file system database for configuration data.
Key names in the HIVEs are folders. The keys contain registry values which contain the actual data. The values are typed so as to also maximize speed. There are user, software, and system data HIVEs. HIVEs can be mounted or unmounted, and symlinks can be created from one key to another. Registry keys can be protected with the same ACL protection mechanism that NTFS uses.
If you want to see how fast the registry is in action just download the regmon.exe probe from www.sysinternals.com and watch what happens when you do anything in Windows. The amazing dependencies that make themselves apparent by watching regmon can easily show you that doing I/O out to disk would cause everything to slow to a crawl, as well as put more pressure on your already loaded disk I/O system.
Registry key values are NOT made to store large amounts of data. You aren't supposed to store entire files as value data. Indeed, that would make what the registry was made for pointless. One of the problems is that many application programmers either don't understand how to use the registry correctly, or just use it for the wrong purpose. The current registry is BIG. The information stored in the registry has gotten out of hand. Even Microsoft can't stop storing useless information in there. It is easy to say that the registry might become corrupted, but this also happens with file systems themselves. You do occasionally have to run a file system check. Ever lost a binary database file before?
Data in the registy can be easily back'ed up using the regedit tool that comes with the OS. You simply export what you need to a text file. The text file can then be re-imported later when needed. If you want to backup a whole HIVE file such as SOFTWARE you can do that too. Many backup utilities will do exactly that. It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS). I really don't see the problem with registry backups. And hey, in the end, the registy is just a simple set of files stored on the filesystem just like any other files in *nix.
Since the registry API is in effect and abstraction layer, Microsoft could re-write the back-end completely. What about a network registry? We could relocate the files out onto a network server and the applications wouldn't know. Microsoft could encrypt the data, compress it, whatever. I don't know what Microsoft's future plans are for the registry interface. Any of these things would make access slower so I expect that the design will stay the way it is for now.
We all have fast and big hard drives these days so the registry does seem kind of pointless. But if we were all using slow small drives we would really appreciate the technical merits of the registry. Even more so, users of a registry can now enjoy that their data is being store both effectively and efficiently. Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like. But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
I am not so sure we are that close. The problem is similar to the Grand Unified Theory of physics. No one yet has figured out the link between the quantum world and gravity. And so in AI, no one, that I know of has worked out the theory and algoritmic design for a machine that does pattern recognition, and reflects on those patterns to store, think, and learn.
A simple example of the inability of a machine to do simple work is listening to a stream of audio, then asking it to pick out sections of the stream that it has heard before. When we see a commercial for example, we usually decide in a few seconds whether we have seen or heard it before.
Maybe the problem is we just need to throw more horsepower at it, but somehow I doubt it.
I am optimistic we will find a solution. Someone just needs to think a little harder about the problem.
Evolution is a bit more deep than your overgeneralization. It turns out having too many children in a generation can be just as detrimental as too few. Evolution is self-correcting, so that a whole population of a given species can't win. The concept known as the Evolutionary Stable Strategy, or ESS, is pretty cool. It's a mathematical way of assigning a cost-benefit analysis to the evolution game. In some cases even the Prisoners Delimma fits in somewhere. You probably need to read Richard Dawkin's "The Selfish Gene". Once you 'get' evolution, it's beauty and simple effectiveness can still astound you.
For all those who never understood what the true nature of the Windows registry is about this thread emphasizes the point.
The Registry was created for the purpose of storing and retrieving local OS and application configuration data in a convienient and highly organized way. In this manner the registry is simply seen as a local database that the OS has direct access to. An operating system process database so to speak.
On the list of registry requirements is speed. The registry is optimized for extremely high speed reads as well as writes. It was discovered early on that storing small amounts of information such as Bytes, Words, Strings, and such directly on the file system in separate files was a problem. Opening, reading, and closing files requires many I/O operations which eats up CPU, and can be taxing on the hardware subsystems. Hard drive caching and file caching can prevent some of the problems caused but do not really provide an adequate solution.
Another issue is that small data elements don't make effective use of the allocated disk space. Especially in the early days with small hard drives this was a BIG issue. You certainly don't want to open a file, save a byte, and close the file. You might end up using a whole sector. Depending on which filesystem type you used, you could lose almost half your disk just by storing small files. With text files the problem is even worse. You end up opening the file, parsing out the data with routines, then converting it to the data type you need. By nature, text representations of the data values will be larger, wasting valuable disk space.
As we have seen with network database access, a database access protocol optimized for high speed reads is important. The LDAP specification addresses some of these concerns. As well with the registry, we need the ability to store and retrieve data fast with minimal space cost. Microsoft decided to create a set of files called HIVEs that are essentially open from the moment the OS boots. The OS caches these HIVEs in memory. The OS as well as applications have access to the HIVEs through a special set of high speed access APIs. All the APIs need for access to a HIVE is its global handle value.
The HIVEs are organized hierarchically similar to a file system. This makes a registry HIVE exactly like a "file system on top of a file system". In this case since a HIVE is stored on the real file system as a single contiguous block and always open, it makes disk space efficient and I/O fast. Its just a specialized mini file system database for configuration data.
Key names in the HIVEs are folders. The keys contain registry values which contain the actual data. The values are typed so as to also maximize speed. There are user, software, and system data HIVEs. HIVEs can be mounted or unmounted, and symlinks can be created from one key to another. Registry keys can be protected with the same ACL protection mechanism that NTFS uses.
If you want to see how fast the registry is in action just download the regmon.exe probe from www.sysinternals.com and watch what happens when you do anything in Windows. The amazing dependencies that make themselves apparent by watching regmon can easily show you that doing I/O out to disk would cause everything to slow to a crawl, as well as put more pressure on your already loaded disk I/O system.
Registry key values are NOT made to store large amounts of data. You aren't supposed to store entire files as value data. Indeed, that would make what the registry was made for pointless. One of the problems is that many application programmers either don't understand how to use the registry correctly, or just use it for the wrong purpose. The current registry is BIG. The information stored in the registry has gotten out of hand. Even Microsoft can't stop storing useless information in there. It is easy to say that the registry might become corrupted, but this also happens with file systems themselves. You do occasionally have to run a file system check. Ever lost a binary database file before?
Data in the registy can be easily back'ed up using the regedit tool that comes with the OS. You simply export what you need to a text file. The text file can then be re-imported later when needed. If you want to backup a whole HIVE file such as SOFTWARE you can do that too. Many backup utilities will do exactly that. It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS). I really don't see the problem with registry backups. And hey, in the end, the registy is just a simple set of files stored on the filesystem just like any other files in *nix.
Since the registry API is in effect and abstraction layer, Microsoft could re-write the back-end completely. What about a network registry? We could relocate the files out onto a network server and the applications wouldn't know. Microsoft could encrypt the data, compress it, whatever. I don't know what Microsoft's future plans are for the registry interface. Any of these things would make access slower so I expect that the design will stay the way it is for now.
We all have fast and big hard drives these days so the registry does seem kind of pointless. But if we were all using slow small drives we would really appreciate the technical merits of the registry. Even more so, users of a registry can now enjoy that their data is being store both effectively and efficiently. Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like. But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
"Tube power amps sound just a little bit better than their solid-state counterparts."
Here's a perfect example of...cave men clinging to the flat earth idea, creationists bashing evolution, and as P. T. Barnum said "There's a sucker born every minute".
These tube mobo's are made for people by marketing types who know there's a market out there of suckers to be sold to. A little electrical engineering and testing will show you that tube amps add distortion, filtering, and noise to any signal that needs to be reproduced by amplification. Here is the critical point...SIGNAL CREATION IS NOT SIGNAL REPRODUCTION.
Yes, tube amps are cool with guitar and other sound generating devices to add color and effect to the signal for the point of getting that nice sound. But, as soon as you've got the sound you want to chisel in stone, you don't want it trashed by some bad reproduction equipment. The art of reproducing sound is the art of not adding or changing anything about the original signal at all!
This is why tubes should never ever be used in mobo's or other stereo equipment where you want to reproduce the original recorded sound perfectly. A pure audiophile never ever drives their amps into the clipping region, that colors and adds distortion to the sound. Signal in, should be amplified signal out, that is all. There should be no noise, no harmonic distortion, no phase changing, etc. Everything should be 1:1 except for the gain.
I'm sure you may be right that tube amps just "sound a little better", but that's only if you are playing "Motley Crue" overdriven into a 1000 watt stack while the signal disappears into just square waves clipped at the peaks. Why don't you just convert the signal into square waves and put some muffs into you ears, that would probably sound a little sweeter too.
Get real.
Hmmm...
If you continue to use the same OTP over and over, you risk the possibility that the pad will be found-out by other methods. If the message has been decrypted as plaintext and stored, then your store was broken into, you could use the plaintext message to discover the continuous use pad. This is the idea, that changing the pads prevents this kind of crack. Once the message has been decrypted, you throw away the pad that was used to encrypt it forever.
Am I missing anything else?
Rod
This should be fine for Internet packet based communication. IP packets are less than 64K in size due to router constraints. So the maximum OTP you would ever need would be 64K. Is there something here that I'm missing?
Rod
Hmmm...
The standard disclaimer is that yes, a OTP -is- unbreakable. So the obvious solution is to create a secured connection with the OTP, then rotate in new pads through the transmission channel, replacing the pads at every transaction. You also need to make the pad sizes randomly variable. This should work, but you'd better have good ack/nak or once the pads get out of sync, you are hosed. Of course you could then create an algorithm for dropping-back to previously used pads until your clients regain sync, but that would be risky.
You also need to make sure your clients have good random number generators on each end. So you might create USB keychain drives with random number electronics that monitor weather conditions, magnetic direction, sound, etc, plus a user selected user input XOR seed.
The upshot of all this work would be that your session would slow considerably. The methods of securing connections are inversely proportional to the bandwidth required.
Rod
...many Europeans still don't believe people have actually landed on the North American continent!
;)
Many believe that life on other continents is just to absurd an idea to take seriously. Or, if life is there, the ocean is just too big a distance to cross, so we will never know.
In fact there is an European internet project called SATI@home, or Search for American Territories Intelligence, that is listening for intelligent life in North America. This project may fail though. If there is life in North America, it is likely that Europeans would never be able to decode the meaning of any of the messages or culture.
Many Europeans think its all just political mumbo jumbo anyway.
"The concept most foreign in all religions is that of a universe existing forever. Beginnings and endings are a fools dream."
-Anonymous
I manage the computer network for another UNC system campus. We've been Internet connected since at least '90. We saw this bandwidth problem coming early on. Setting up the dorms on campus to our existing infrastructure was found to be too costly. We instead opted to contract Time Warner RoadRunner service for the dorms and let them handle the traffic. This has turned out ok so far, and it keeps our legitimate university traffic low. This lets us manage or own lab, faculty, staff, server systems without having to bother with student connectivity issues. Universities supplying students with what amounts to 'free' bandwidth are just asking for it. I used to be a student so I know!
We are also connected to NCREN so getting to campus from Time Warner RoadRunner can require as many as 18 hops with an average ping of 60-70ms.
Back in early '96 I used to run a couple of Quake servers on campus for fun. I miss those Internet frontier days.
Is there any software that allows you to firewall outgoing packets as well as incomming?
What i'd really like to know is, which version will it be? The original, which air'ed in Sept-Nov 80 on PBS was great. Turner bought the rights to sell the series later and trashed it. The music is changed and various selections have been modified. How do I know? I've got the originals and I've compared to Turners version. Its a damn shame I tell ya. A damn shame! Rod