I have also played White Wolf games and other RPGs for many years. Perhaps your ire is more of an inability to look at what you do in a wider context. I have had the same thoughts that Katz has, looking at the games and their storylines.
Shadowrun is about the rise of corporatism. The Whitewolf games tend to be about alienation from society. Mage, in particular, has a lot to say about media manufactured reality.
Why do you think role-playing games are so vehemently denounced by certain segments of our society, and almost always recieve shoddy treatment at the hands of Hollywood. It certainly isn't because they're tales told by an idiot, full of sound and fury, signifying nothing. If you want that, watch your average Hollywood action movie.
I'm not some deconstructionist literary geek with my head stuck in my navel (or some other part of my anatomy). He has something interesting and important to say. Listen to it. Maybe you'll learn something.
My question is, how long before this is incorporated into GPG? Of course, the obvious answer is 'as quickly as you can write it yourself':-).
As far as I know, RSA is more secure than both El Gamal, and DSA, the algorithms currently used for encryption and signing in GPG. In fact, I believe El Gamal becomes horribly insecure if the same random number is used twice when running the algorithm. Also, RSA supports longer key lengths than DSA.
I want to create myself a big, 4-8k bit RSA root signing key scheduled to expire in 10 years, and then at 2 year intervals replace my main signing and encryption keys with new ones signed by the big RSA root key.
I know how RSA works, but not how to generate the large random primes that are required for a big key.
I don't use it, and won't use it. Their liscensing is too restrictive. I'd much rather use the German produced GnuPG. Better liscensing, more standards compliant, and they don't put stupid features like ADK in to satisfy Big Brotherish commercial interests.
Not one of his replies really addressed the issue you were trying to bring up. I don't understand how people could be so blind to the fundamental reality of what you're saying.
I also don't get what intellectual property they're trying to protect. Once a trade secret is out, it's out, and has no more protection. I think this is even true if someone under an NDA leaks it. That's how they work. The only concievable thing I think they could claim for intellectual property is if they had patented the idea of scanning a barcode encoded URL and automatically sending you to the website.
Upon reading this article, I also realized that there really wasn't a conspiracy. But, I've actually built my own build of egcs in the past year or so, and noticed the 'Cygnus tree' phenomenon, and was kind of wondering what was up. It's interesting to get an internal glimpse of the organization of a project with which I'm unfamiliar.
I'm trying to build an open source project that has more contributors than myself right now, and it's interesting to see how other projects happen.
If you know, understand, and like C and Unix, then Perl will be a joy. If you're just a DOS-kiddie though, and these are too rough for you, then it probably won't be. The number of Python bigots who are also anti-Unix bigots is astounding.
*shrug* I've been using Unix for over 12 years now, and have been an avid C programmer for even longer. I tend to use C++ nowadays, but C is still fine with me. This is an ad hominem attack that I hesitate to dignify with a response, and only do so out of a desire to prevent this from being a factor in your mind when you read what I have to say.
That's because Python, being anti-Unix, wasn't designed with regexes in mind; it just has them bolted on to the side, way late in the game. They aren't integrated into the language, since they're latecomers. It's pretty clumsy compared to using them in a language that was
designed with regular expressions as a central language primitive, and embarrassing to see them compared.
It isn't so much that they're an afterthought as they are just not an integral part of the language.
Apparently you never learned about the qr/.../ construct. See the new Camel, or the perlop(1) manpage.
No, I haven't learned about that construct. As you point out, it seems to be relatively new. I've known and used perl since before 4.035. It will be nice if this solves my annoyance.
I tend towards the academic mindset. I suspect that people who would rather solve their problem than think about it too hard would vastly prefer perl.
That's right: Perl is designed to make it easy for anybody to get their job done directly and obviously--without their having to become academics! Perl lets you program the way you think, not vice versa. That's why it will always be dissed by the poofy academics, but incredibly useful in the real world. Python, however, expects you to conform to One True Way, which may not be the way you think, in which case you're out of luck.
My comment was meant to point out the disadvantages of both sides. Doing things without thinking about them first yields programs that do stuff, but become crufty and hard to maintain over time. The perl I've seen being used in the field or downloaded from CPAN fits this description well. Often such programs written in languages other than perl become cleaner as time and programmers wear away the rough edges. I don't believe perl has the necessary support for allowing this to happen.
Python does let you get things done quickly. I wrote a program to connect to an IMAP server and filter out all the ILOVEYOU messages in about 0.5 hours. But when you have something big (or has become bigger than expected) that you have to plan, the tools are there to do that too.
perl and Python are in competition for a few reasons:
As someone else said, they are both high level interpreted languages
They both rely heavily on outside services and libraries to make them truly useful.
Now, if they were both the same, there would be no point in them competing. perl and Python differ in several important ways:
Python uses whitespace as a block delimeter. This does force code to have some marginal level of readability, which is nice. The loss of freedom this entails is very occasionally annoying.
Python was designed from the beginning to have modules, and an eye towards object orientation. The namespace rules in Python are consequently much more regular and easier to understand.
Perl was designed as a replacement for complex shell scripting, and if your habits come from this kind of background, it fits much more easily into how you work than Python.
Python has simply amazing (reminiscent of lisp) reflection capabilities. Perl has them, but they are arcane and difficult to use and understand.
Python regular expressions are now as powerful as perl's, but still not quite so convenient to use. A compiled regular expression is a first class object in Python, so you have a lot more control over when and where an expression is recompiled. This lack in perl is a major annoyance of mine.
I actually see Python as a viable (and desirable) replacement for perl in most instances. Of course, I tend towards the academic mindset. I suspect that people who would rather solve their problem than think about it too hard would vastly prefer perl.
Half life is the average amount of time for half of the atoms in sample of an isotope to decay. Any individual atom in this sample will have a set probability of undergoing decay during a certain period of time.
Say you have a sample with 6.02*10^23 atoms of Uranium 238 (about 238 grams of U238), and you notice that in 30 minutes, you only have 6*10^23 U238 atoms left. This means, you lost 2*10^21 atoms in 30 minutes.
This means you lost about 0.3322259% of your sample in 30 minutes. Decay is exponential. In 30 minutes, (100 - 0.3322259)% of the U238 is left. In another 30 minutes, 0.3322259% of the U238 will be lost, or (100 - 0.3322259)%^2 of the original total will be left.
To compute how long it will be before only 50% of the original total, do this:
30 minutes * ln(0.5) / ln(1 - 0.003322259) = 6240 minutes.
This means that in 6240 minutes, or 104 hours half of the U238 will be converted, meaning that U238 has a half-life of 104 hours. Of course, these figures are fictitious. U238's half life is lots longer than 104 hours or there wouldn't be any left on the planet, but the principle still holds.
Seems to me that most game programmers adopted Direct X because they had to. John Carmack, in particular, did not accept Direct X, and still doesn't. He, almost singlehandedly, is the reason that 3D card manufacturers make OpenGL drivers for their cards.
Also, the point of a HAL is to abstract the hardware away, not to provide a way for you to stick 50,000 case statements in your code in case some particular feature is supported or not. That's a stupid way to design an API. Fits with the rest of Microsoft's APIs just fine though. What a load of garbage that OS is.
I'm willing to wait that long. It's so nice to play games on my Linux box and run a talker, and a web server, and host shell accounts, and a DNS server, and...
I only play games under Linux now, and it's going to remain that way for the foreseeable future. I'm tired of the flakiness that comes from playing them under Windows. Heck, I can even do things like switch to a spreadsheet or something for games with a lot of trading. I've never been able to do that before with a game on any platform besides Linux.
Don't most sites switch to SSL after an initial login screen? Why would people care if the site went to some strange subdirectory after they first access the site?
As for the caching problem...
Design your web pages so most of the heavy content is pulled from the http server. Most of that content doesn't need to be protected by the encryption of an SSL connection. Of course, you then have the problem of 'sideband' data. An attacker may be able to determine something about a persons movements on the website from observing the unecrypted traffic stream, but I think that issue is minor.
The tests showing that it performs better under heavy loads are for very specific kinds of heavy load that are unlikely to be enountered in real-world situations, and certainly not by the sites mentioned. Most places serve up dynamic pages, and I'm guessing that a reasonable benchmark of that capability would show that Linux consistently outperforms Windows NT, even on a 2.2 series kernel without a kernel module web server.
The hotmail story in particular has been independently verified by many sources.
In that case, it's time to punish them for their disregard for consumers by not buying their products.
All this bottom line garbage is stupid. We're moral creatures because that's what works. If it didn't, we wouldn't be here. It's time companies were held to the same standards.
Oh, come off it, there are many ways to be conservative without exceeding specs. For example, bus timings for memory access, or bus timings for other kinds of accesses.
I don't blame him one bit for his actions or his biases. Around the time of the floating point bug, Intel threatened to sue him over the things he said about the problems (which all happened to be true). They don't deserve any consideration by him.
IMHO, his review is the only thing that made this happen. Intel still hasn't learned.
As the previous two people who replied didn't bother to read what you wrote and tried to slam you for complaining, I'll step in and tell you what X is.
Under Unix, the display for a GUI is handled by a user level process. This program is called the 'X server'. It runs on the small box on your desk, and so it seems unintuitive for it to be a server, but that's what it is. It serves up access to your display to the various programs that want to use it.
One major defining feature of X is that it uses a stream protocol that can go over a network. This means the program that displays stuff doesn't have to be running on the same computer that displays it.
Another defining feature is that X is all about 'mechanism not policy'. It provides a way for programs to put up windows on your screen and things but doesn't say much about how they should act or look. Some people like this, some people don't. I fall in the first camp. It means that there isn't a 'standard desktop environment' for Unix, but it also means that we're free to switch desktop environments without breaking all of our programs.
It's because as software gets older and more popular, there are fewer changes requiring a complete rearchitecting of the system. This is because such changes become harder both because the software is bigger and more complex, and because such changes usually introduce compatibility problems which a larger user base won't tolerate. It's a natural thing IMHO.
It's not PGP that has to have the alternate commercial use, it's the technique of adding ADKs to an existing key unbeknownst to the original issuer of the key or anybody recieving the key.
The claim he's making is actually reasonable from the perspective of the DMCA as I understand it. That technique really has no viable commercial use. It can only be used to do underhanded things. Breaking encryption on something for the purpose of violating the copyright is one of those things.
From what I understand, it still is. I think there are command queuing issues and such that are well handled by SCSI host adapters. I'm kinda fuzzy on this, so I might be wrong.
Finally, single-threaded, event-driven programming should not be counted out. It turns out to be the most appropriate, for a surprisingly large number of problems. In some cases, you're better off running several copies of a single-threaded server (say, one per CPU), than a multi-threaded one.
Hear here! If you want a system that encourages writing servers that operate like this, see my StreamModule system.
I believe this very strongly. Multi-threaded programming is just plain hard, no matter how you slice it. Locking only becomes about as second nature as remembering to free all your mallocs, with even more disastrous and insidious consequences for forgetting. Worse yet, under Windows NT, every locking operation becomes a system call with a potential CPU context switch that is expensive in terms of cache misses.
As far as CPU time slice is concerned...
I think 50 milliseconds is fine. The general Unix model is to have most processes spend most of their time waiting for something to happen. Usually when a process has something to do (like if it has to respond to input) no other process has anything to do, and it gets the CPU right away.
If you want to see a stupid design descision, look at NT's virtual memory manager. It's a FIFO memory manager because the system architects decided that attempting to implement any approximation of LRU was 'too expensive'. Therefore, implementing a paging scheme that's guaranteed to eventually kick out high hit pages is a much better idea. NOT!
Of course FIFO is fine if your working set fits in RAM, which is maybe why people throw so much memory at NT boxes.
The only silly thing in this article is the whole rant about GNOME being *gasp* commercialized. As long as it stays largely GPLed, I don't care.
On a side note...
I remember casually evaluating GUI libraries several years ago, and thinking to myself 'xforms, this is stupid, positional geometry instead of contraints based is clearly the wrong thing', and 'QT, this looks nice, but I don't like the liscensing, why is anybody basing anything 'Free' off this toolkit?', and 'GTK, hmm, why on earth did they do this in C? And this signal thing seems hokey. The Gimp sure seems nice though.'. This was completely independent of any of the debates on the Net as I wasn't even aware of them.
Slashdot Mirror
I have also played White Wolf games and other RPGs for many years. Perhaps your ire is more of an inability to look at what you do in a wider context. I have had the same thoughts that Katz has, looking at the games and their storylines.
Shadowrun is about the rise of corporatism. The Whitewolf games tend to be about alienation from society. Mage, in particular, has a lot to say about media manufactured reality.
Why do you think role-playing games are so vehemently denounced by certain segments of our society, and almost always recieve shoddy treatment at the hands of Hollywood. It certainly isn't because they're tales told by an idiot, full of sound and fury, signifying nothing. If you want that, watch your average Hollywood action movie.
I'm not some deconstructionist literary geek with my head stuck in my navel (or some other part of my anatomy). He has something interesting and important to say. Listen to it. Maybe you'll learn something.
What about EL Gamal's problem with choosing the same 'k' twice?
My question is, how long before this is incorporated into GPG? Of course, the obvious answer is 'as quickly as you can write it yourself' :-).
As far as I know, RSA is more secure than both El Gamal, and DSA, the algorithms currently used for encryption and signing in GPG. In fact, I believe El Gamal becomes horribly insecure if the same random number is used twice when running the algorithm. Also, RSA supports longer key lengths than DSA.
I want to create myself a big, 4-8k bit RSA root signing key scheduled to expire in 10 years, and then at 2 year intervals replace my main signing and encryption keys with new ones signed by the big RSA root key.
I know how RSA works, but not how to generate the large random primes that are required for a big key.
I don't use it, and won't use it. Their liscensing is too restrictive. I'd much rather use the German produced GnuPG. Better liscensing, more standards compliant, and they don't put stupid features like ADK in to satisfy Big Brotherish commercial interests.
Not one of his replies really addressed the issue you were trying to bring up. I don't understand how people could be so blind to the fundamental reality of what you're saying.
I also don't get what intellectual property they're trying to protect. Once a trade secret is out, it's out, and has no more protection. I think this is even true if someone under an NDA leaks it. That's how they work. The only concievable thing I think they could claim for intellectual property is if they had patented the idea of scanning a barcode encoded URL and automatically sending you to the website.
Upon reading this article, I also realized that there really wasn't a conspiracy. But, I've actually built my own build of egcs in the past year or so, and noticed the 'Cygnus tree' phenomenon, and was kind of wondering what was up. It's interesting to get an internal glimpse of the organization of a project with which I'm unfamiliar.
I'm trying to build an open source project that has more contributors than myself right now, and it's interesting to see how other projects happen.
*shrug* I've been using Unix for over 12 years now, and have been an avid C programmer for even longer. I tend to use C++ nowadays, but C is still fine with me. This is an ad hominem attack that I hesitate to dignify with a response, and only do so out of a desire to prevent this from being a factor in your mind when you read what I have to say.
It isn't so much that they're an afterthought as they are just not an integral part of the language.
No, I haven't learned about that construct. As you point out, it seems to be relatively new. I've known and used perl since before 4.035. It will be nice if this solves my annoyance.
perl and Python are in competition for a few reasons:
Now, if they were both the same, there would be no point in them competing. perl and Python differ in several important ways:
Python regular expressions are now as powerful as perl's, but still not quite so convenient to use. A compiled regular expression is a first class object in Python, so you have a lot more control over when and where an expression is recompiled. This lack in perl is a major annoyance of mine.
I actually see Python as a viable (and desirable) replacement for perl in most instances. Of course, I tend towards the academic mindset. I suspect that people who would rather solve their problem than think about it too hard would vastly prefer perl.
This is easy.
Half life is the average amount of time for half of the atoms in sample of an isotope to decay. Any individual atom in this sample will have a set probability of undergoing decay during a certain period of time.
Say you have a sample with 6.02*10^23 atoms of Uranium 238 (about 238 grams of U238), and you notice that in 30 minutes, you only have 6*10^23 U238 atoms left. This means, you lost 2*10^21 atoms in 30 minutes.
This means you lost about 0.3322259% of your sample in 30 minutes. Decay is exponential. In 30 minutes, (100 - 0.3322259)% of the U238 is left. In another 30 minutes, 0.3322259% of the U238 will be lost, or (100 - 0.3322259)%^2 of the original total will be left.
To compute how long it will be before only 50% of the original total, do this:
30 minutes * ln(0.5) / ln(1 - 0.003322259) = 6240 minutes.
This means that in 6240 minutes, or 104 hours half of the U238 will be converted, meaning that U238 has a half-life of 104 hours. Of course, these figures are fictitious. U238's half life is lots longer than 104 hours or there wouldn't be any left on the planet, but the principle still holds.
Seems to me that most game programmers adopted Direct X because they had to. John Carmack, in particular, did not accept Direct X, and still doesn't. He, almost singlehandedly, is the reason that 3D card manufacturers make OpenGL drivers for their cards.
Also, the point of a HAL is to abstract the hardware away, not to provide a way for you to stick 50,000 case statements in your code in case some particular feature is supported or not. That's a stupid way to design an API. Fits with the rest of Microsoft's APIs just fine though. What a load of garbage that OS is.
I'm willing to wait that long. It's so nice to play games on my Linux box and run a talker, and a web server, and host shell accounts, and a DNS server, and...
I only play games under Linux now, and it's going to remain that way for the foreseeable future. I'm tired of the flakiness that comes from playing them under Windows. Heck, I can even do things like switch to a spreadsheet or something for games with a lot of trading. I've never been able to do that before with a game on any platform besides Linux.
Don't most sites switch to SSL after an initial login screen? Why would people care if the site went to some strange subdirectory after they first access the site?
As for the caching problem...
Design your web pages so most of the heavy content is pulled from the http server. Most of that content doesn't need to be protected by the encryption of an SSL connection. Of course, you then have the problem of 'sideband' data. An attacker may be able to determine something about a persons movements on the website from observing the unecrypted traffic stream, but I think that issue is minor.
The tests showing that it performs better under heavy loads are for very specific kinds of heavy load that are unlikely to be enountered in real-world situations, and certainly not by the sites mentioned. Most places serve up dynamic pages, and I'm guessing that a reasonable benchmark of that capability would show that Linux consistently outperforms Windows NT, even on a 2.2 series kernel without a kernel module web server.
The hotmail story in particular has been independently verified by many sources.
Yeah, higher than mine, and I don't consider mine to be all that low. :-)
In that case, it's time to punish them for their disregard for consumers by not buying their products.
All this bottom line garbage is stupid. We're moral creatures because that's what works. If it didn't, we wouldn't be here. It's time companies were held to the same standards.
Oh, come off it, there are many ways to be conservative without exceeding specs. For example, bus timings for memory access, or bus timings for other kinds of accesses.
I don't blame him one bit for his actions or his biases. Around the time of the floating point bug, Intel threatened to sue him over the things he said about the problems (which all happened to be true). They don't deserve any consideration by him.
IMHO, his review is the only thing that made this happen. Intel still hasn't learned.
i.e. Getting moderated up and mentioning your low User # in the same post.
As the previous two people who replied didn't bother to read what you wrote and tried to slam you for complaining, I'll step in and tell you what X is.
Under Unix, the display for a GUI is handled by a user level process. This program is called the 'X server'. It runs on the small box on your desk, and so it seems unintuitive for it to be a server, but that's what it is. It serves up access to your display to the various programs that want to use it.
One major defining feature of X is that it uses a stream protocol that can go over a network. This means the program that displays stuff doesn't have to be running on the same computer that displays it.
Another defining feature is that X is all about 'mechanism not policy'. It provides a way for programs to put up windows on your screen and things but doesn't say much about how they should act or look. Some people like this, some people don't. I fall in the first camp. It means that there isn't a 'standard desktop environment' for Unix, but it also means that we're free to switch desktop environments without breaking all of our programs.
It's because as software gets older and more popular, there are fewer changes requiring a complete rearchitecting of the system. This is because such changes become harder both because the software is bigger and more complex, and because such changes usually introduce compatibility problems which a larger user base won't tolerate. It's a natural thing IMHO.
It's not PGP that has to have the alternate commercial use, it's the technique of adding ADKs to an existing key unbeknownst to the original issuer of the key or anybody recieving the key.
The claim he's making is actually reasonable from the perspective of the DMCA as I understand it. That technique really has no viable commercial use. It can only be used to do underhanded things. Breaking encryption on something for the purpose of violating the copyright is one of those things.
From what I understand, it still is. I think there are command queuing issues and such that are well handled by SCSI host adapters. I'm kinda fuzzy on this, so I might be wrong.
Hear here! If you want a system that encourages writing servers that operate like this, see my StreamModule system.
I believe this very strongly. Multi-threaded programming is just plain hard, no matter how you slice it. Locking only becomes about as second nature as remembering to free all your mallocs, with even more disastrous and insidious consequences for forgetting. Worse yet, under Windows NT, every locking operation becomes a system call with a potential CPU context switch that is expensive in terms of cache misses.
As far as CPU time slice is concerned...
I think 50 milliseconds is fine. The general Unix model is to have most processes spend most of their time waiting for something to happen. Usually when a process has something to do (like if it has to respond to input) no other process has anything to do, and it gets the CPU right away.
If you want to see a stupid design descision, look at NT's virtual memory manager. It's a FIFO memory manager because the system architects decided that attempting to implement any approximation of LRU was 'too expensive'. Therefore, implementing a paging scheme that's guaranteed to eventually kick out high hit pages is a much better idea. NOT!
Of course FIFO is fine if your working set fits in RAM, which is maybe why people throw so much memory at NT boxes.
*grin* If they have a Voodoo card, it'll be pretty easy. If they don't, it'll be a huge pain. That's my experience anyway.
The only silly thing in this article is the whole rant about GNOME being *gasp* commercialized. As long as it stays largely GPLed, I don't care.
On a side note...
I remember casually evaluating GUI libraries several years ago, and thinking to myself 'xforms, this is stupid, positional geometry instead of contraints based is clearly the wrong thing', and 'QT, this looks nice, but I don't like the liscensing, why is anybody basing anything 'Free' off this toolkit?', and 'GTK, hmm, why on earth did they do this in C? And this signal thing seems hokey. The Gimp sure seems nice though.'. This was completely independent of any of the debates on the Net as I wasn't even aware of them.
Just my two cents.