As a matter of fact, I am running e2compr, the transparent compression module for ext2 (the Linux filesystem). I have been for over a year. It cheerfully handles compression with far more fine-grained control than most Windows programs (eg, you can choose individually whether to compress a file or not) and performs, so far as I can tell, flawlessly. That is, it has never corrupted data or caused bugs in other programs, and has never crashed the system even under heavy load. There was one crashing problem (that I never triggered) which was recently discovered and fixed; I don't think there are any other known outstanding issues.
So yes, transparent compression can work just fine. The case of running out of space is a problem, but no program should blindly assume that the amount of disk space remaining is reliable unless it's running on a single-process system, and even then it's shaky. What if, while the program that needs X disk space is running, I download and unpack a file? Worse, what if another user does it on a multi-user system? Programs that break in this way are broken already, period.
My summer employer, a scientific research group, wants to set up Linux on a bunch of PCs for use as a workstation. The distribution they chose: RedHat.
Now, I'm very familiar with Debian GNU/Linux. If I were left to choose, I'd have potato running on all these systems. However, this group relies, unfortunately, on some non-free software. The vendors of this software can only guarantee that it will run on RedHat, and the people in the lab are scared that things won't work properly on any other distribution. The result? I'm going to spend the next few months cursing RPM.
And you think fragmentation isn't a problem at all? [1]
Daniel
[1] of course, it mostly affects proprietary programs, so may not be particularly relevant unless you're unfortunate enough to have wedded yourself to one.
I dunno, I've never had any problems with games on Linux.
But then, these companies he talks about..Id? Did they port NetHack to Windows or something? And those Epic people..what'd they ever do? (looks at computer) No NetHack derivatives. Can't be that important.
-- Daniel, who has heard rumors that there are games besides NetHack and refuses to believe them.
-> fbcons doesn't work with my video card, which predates VESA2.0; -> besides, fbcons gives me a headache on VESA2.0 cards (60Hz refresh rate..) -> I happen to be running stuff inside X a majority of the time and I'm too lazy to switch VTs -> svgalib (if Allegro supports it) needs root permissions, something I'm not going to give to a binary download of a beta library, and tends to lock the console and do other weird things if the program using it crashes
I care about CPU usage because I sometimes want to run other things in the background, and not only are they impacted, but Allegro-based games (--in the version I tried--) don't deal at all well with anything else getting CPU time; they get horribly jerky whenever, eg, fetchmail wakes up and delivers the mail that's arrived in the last 10 minutes to me.
The GNU port of Allegro is in a rather bad state right now. I downloaded it to play a nifty game called "Liquid War", and straight off discovered that I had to install the binary version because it would not compile from source. (it looked like a syntax error, as I recall, but I wasn't in a mood to hunt the bug down) Once installed, it worked -- except for several very annoying efficiency problems: among other things:
-> it appears to not block at all, even when the program is doing nothing but waiting for input with an unchanging display. I suspect it just spins to handle timing instead of sleeping (I haven't tried to verify this) -> Drawing seems to be insanely inefficient. I don't know whether it's using shared memory (I suspect it isn't), but I've seen games of much less visual complexity work with much less CPU usage. Some button-pushing popped up what looked like a meter of time used, showing that almost all the time was going into drawing routines rather than game logic. -> For some reason, Allegro insists on using its own special mouse cursor instead of X's.
The upshot of this is that displaying a static title screen takes 100% of my CPU time. Not so good.
Of course, this is really still a beta version of the port and I'm sure it'll get better..unless these problems (eg, assumptions of 100% CPU access) are present in the API as well. I haven't looked to see, perhaps you can tell me.
I've been picking up a little bit of OpenGL, and it seems to me to be an exceedingly well-thought-out, clean, and consistent API. Certainly better than the small amount of Win16/32, and the rather larger amount of DOS, programming I did. Admittedly, I haven't done any DirectX programming; maybe Microsoft has designed an uncharacteristically decent interface, but anyway:
What is wrong with GL?
Daniel
Re:All things considered...
on
Solving Chess?
·
· Score: 2
I still have to disagree. Most RTS games follow a very simple pattern: build lots of buildings, then build lots of units, then send the units to go fight the enemy. IMO, War2 is actually particularly *bad* in this respect. And yes, accomplishing those goals is more a function of how fast you can hit the buttons that of any great strategical insight.
Daniel
Re:All things considered...
on
Solving Chess?
·
· Score: 3
Chess is a good game of logic and strategy, but it is hardly the epitome of either. I prefer RTS games like Red Alert or Warcraft - the AI stinks but when you play against a human there is no comparison.
I'm sorry, but that's just blasphemy. Comparing the clickfest that is your average RTS to the intellectual exercise of chess? The only thing that could explain such a gross misapprehension is that you have never studied chess more deeply than the Parker Bros. rulebook. I don't think I can enlighten you in this space, but get a couple of good chess books and read them -- it's far deeper than anything to come out of the computer game companies (not that those games aren't fun anyway:) ) Even Civilization has to take second place, IMO. (although that's a far better comparison)
Also, since you mentioned stalemate--it's generally agreed that chess has to have one of two outcomes if played perfectly: either White wins or it's a draw. (Black could win, but most chess-players would eat their hats (metaphorically) if that turned out to be the case) Note that one of these *has* to be true: if there's ever a position where a player has two moves, one of them inevitably leading to a better end for him, he'll take the better one, and this can be extrapolated back up the game tree.
What makes chess still interesting is that even if it were solved, no human would be able to memorize all the intricacies of every line of play. (learning one line of play would be feasible, but all your opponent has to do is to play a line that you don't know, even if it's slightly worse) Given this, we have to fall back on general pattern-recognition and short-term calculation, which makes it still a game of skill and justifies comments like "slightly better" when a 'perfect' game only has three, very discrete valuations of positions.
Transmitting anything except passive data -- that is, using a network like this to download programs, source, or even files you're editing in Emacs -- sounds like a really good way to get the trojan of the week faster than you ever could before..
Catastrophic loss of life? No, not unless you count the bajillions of species we've killed deliberately and inadvertantly (seen any American chestnuts or bison lately? They're the lucky ones; they're still around, if barely.)
Does anyone know what the state of e2compr support in 2.4 will be? I read in Kernel Traffic that it's not ready for the official kernels, but that someone finally explained to the e2compr maintainer how to port it to the new buffer-cache system..but I haven't heard anything that indicates that such porting is actually occuring. I'm starting to think that I may have to decompress my whole hard drive to try this..which may be difficult given that I'm operating close to capacity;-)
I was under the impression that COM/DCOM was some sort of an object-oriented system for remote procedure calls (I guess if you're using objects that should be 'remote method calls'..) CORBA and RPC don't need kernel support. (well, aside from requiring some sort of network layer, but the kernel doesn't have to know about them) What's special about COM that requires it to go in the kernel? Why not put an NFS server and an httpd in the kernel while you're at it..er, nevermind..
What I know is that Solaris manages its actual threads in userspace, and can map any number of 'threads' onto any number of 'processes', where a process is an object the kernel knows about and schedules. (They're usually called "user threads" and "kernel threads", but that can get a bit confusin:) ) Of course, a UNIX process can consist of several of these 'processes'.
What I've heard is that this gives you: -> Flexibility, since you can decide whether to do threading entirely in userspace, entirely in the kernel, or both, and -> Speed, since threading constructs (eg, mutexes) CAN be handled entirely in user code (but, I assume, not always)
A related issue is that the Solaris scheduler is supposedly better than Linux's for large numbers of processes; I have heard (I haven't bothered to check myself as it doesn't impact me, since I run relatively few processes; this may be outdated) that Linux's scheduler runs in O(n) (or maybe worse?) time in the number of processes, while the Solaris scheduler is more efficient. (I believe Solaris uses a table-driven mechanism to schedule processes)
Unfortunately, I don't know how true this is for current versions of Linux (and Solaris, but they haven't released anything big I know of since I got this info)
I'm not sure, but I/think/ that pthreads actually handles thread-specific data by having a (shared) table indexed (or maybe hashed) by the thread ID. This works but is somewhat inefficient. As I recall, the debate in question (which I happened to read on Kernel Traffic through a freak accident:) ) revolved around using VM magic to make some pages of an address space private to the thread and others shared between processes. Or something like that. This would be more efficient, but I guess it was decided that it would add to much bookeeping and cruft to the kernel.
Huh? I'm a little confused; when I've run Mozilla it looked like it was running single-threaded. Where does SMP come in? (also, a well-written threaded program shouldn't encounter bugs only when running with SMP..these probably bite non-SMP users occasionally, but SMP just exacerbates them..for example, from the bug logs, the problem seems to be that the internal Mozilla memory-allocation/refcounting system wasn't thread-safe! This is a big no-no, and I'm not surprised it was causing problems..) Daniel
It's generally (IMO) a good idea to keep your own accounts so you can double-check the bank's. Even banks make mistakes from time to time, for various reasons. Not often perhaps, but noticing when they do is a Good Thing:) Not that I do it, but that's partly because I don't have a good accounting program (Quicken doesn't count for a number of reasons, including the fact that I'd have to reboot to use it, which makes it horrendously inconvenient) Daniel
If I could I'd clean up every piece of messy code I could get my hands on. Heck, I'd rewrite the entire system from scratch.
The fact is, though, that I do not have an infinite amount of time in which to work, and that therefore, I rely on other people to fix things I don't have time to get to. Does this make sense? I'm not sure it makes sense to me:)
In any event, E is way too broken on a fundamental level to be fixed. I switched to Sawmill and never looked back; I predict that E will either eventually become an entire operating system (possibly even incorporating a kernel:) ) -- the logical extension of its current development path -- or collapse under its own weight. Or possibly both.
Actually, there was a thread on debian-devel the other day that indicated that the memory (actually, X pixmap) leaking may not, in fact, be fixed. People were reporting that their X server was using over a hundred megabytes of memory if left running overnight; the only commonality was that they were running Gnome and using various imlib-based things (pixmap themes, transparent Eterms, etc)
This is actually worse than your average memory leak, as the only way to recover the memory is to restart X.
Yes, I might. Let me look at it again. They say Gnome 2.0 will be based on GTK+ 1.4. Fine. They also say Gnome 2.0 will release 'around fall 2000'. Ok. So you *could* infer that GTK+ 1.4 will be released around fall 2000
However, the Gnome folks don't speak for the GTK+ folks, and the GTK+ 1.4 release could be scheduled for any time prior to or after the Gnome 2.0 release, which is already pointed at a rather vague target. I'd like to hear from someone who knows something about GTK+ developement when I can start using the new version:)
Slashdot Mirror
FreeCiv, NiL, Pingus, XPilot, NetHack, Crystal Space, GFingerPoken, Koules, Liquid War, XConq, WorldForge, SpellCast. To name the tip of the iceberg; I don't have time to do this all day :)
Or, in other words: The one who says it cannot be done should never interrupt the one who is doing it.
Cheers,
Daniel
As a matter of fact, I am running e2compr, the transparent compression module for ext2 (the Linux filesystem). I have been for over a year. It cheerfully handles compression with far more fine-grained control than most Windows programs (eg, you can choose individually whether to compress a file or not) and performs, so far as I can tell, flawlessly. That is, it has never corrupted data or caused bugs in other programs, and has never crashed the system even under heavy load. There was one crashing problem (that I never triggered) which was recently discovered and fixed; I don't think there are any other known outstanding issues.
So yes, transparent compression can work just fine. The case of running out of space is a problem, but no program should blindly assume that the amount of disk space remaining is reliable unless it's running on a single-process system, and even then it's shaky. What if, while the program that needs X disk space is running, I download and unpack a file? Worse, what if another user does it on a multi-user system? Programs that break in this way are broken already, period.
Daniel
I think you're overlooking rubber-hose cryptoanalysis here.
Daniel
My summer employer, a scientific research group, wants to set up Linux on a bunch of PCs for use as a workstation.
The distribution they chose: RedHat.
Now, I'm very familiar with Debian GNU/Linux. If I were left to choose, I'd have potato running on all these systems. However, this group relies, unfortunately, on some non-free software. The vendors of this software can only guarantee that it will run on RedHat, and the people in the lab are scared that things won't work properly on any other distribution. The result? I'm going to spend the next few months cursing RPM.
And you think fragmentation isn't a problem at all? [1]
Daniel
[1] of course, it mostly affects proprietary programs, so may not be particularly relevant unless you're unfortunate enough to have wedded yourself to one.
I dunno, I've never had any problems with games on Linux.
But then, these companies he talks about..Id? Did they port NetHack to Windows or something? And those Epic people..what'd they ever do? (looks at computer) No NetHack derivatives. Can't be that important.
-- Daniel, who has heard rumors that there are games besides NetHack and refuses to believe them.
(it's funny. Laugh)
I just thought I should let you know that I picked up on the satire, even if some other people didn't..
Daniel
Well, I'm running it on the X server because:
;-)
-> fbcons doesn't work with my video card, which predates VESA2.0;
-> besides, fbcons gives me a headache on VESA2.0 cards (60Hz refresh rate..)
-> I happen to be running stuff inside X a majority of the time and I'm too lazy to switch VTs
-> svgalib (if Allegro supports it) needs root permissions, something I'm not going to give to a binary download of a beta library, and tends to lock the console and do other weird things if the program using it crashes
I care about CPU usage because I sometimes want to run other things in the background, and not only are they impacted, but Allegro-based games (--in the version I tried--) don't deal at all well with anything else getting CPU time; they get horribly jerky whenever, eg, fetchmail wakes up and delivers the mail that's arrived in the last 10 minutes to me.
and finally: Nethack doesn't have this problem
Daniel
Eh, that's true, but..
The GNU port of Allegro is in a rather bad state right now. I downloaded it to play a nifty game called "Liquid War", and straight off discovered that I had to install the binary version because it would not compile from source. (it looked like a syntax error, as I recall, but I wasn't in a mood to hunt the bug down) Once installed, it worked -- except for several very annoying efficiency problems: among other things:
-> it appears to not block at all, even when the program is doing nothing but waiting for input with an unchanging display. I suspect it just spins to handle timing instead of sleeping (I haven't tried to verify this)
-> Drawing seems to be insanely inefficient. I don't know whether it's using shared memory (I suspect it isn't), but I've seen games of much less visual complexity work with much less CPU usage. Some button-pushing popped up what looked like a meter of time used, showing that almost all the time was going into drawing routines rather than game logic.
-> For some reason, Allegro insists on using its own special mouse cursor instead of X's.
The upshot of this is that displaying a static title screen takes 100% of my CPU time. Not so good.
Of course, this is really still a beta version of the port and I'm sure it'll get better..unless these problems (eg, assumptions of 100% CPU access) are present in the API as well. I haven't looked to see, perhaps you can tell me.
Daniel
I've been picking up a little bit of OpenGL, and it seems to me to be an exceedingly well-thought-out, clean, and consistent API. Certainly better than the small amount of Win16/32, and the rather larger amount of DOS, programming I did. Admittedly, I haven't done any DirectX programming; maybe Microsoft has designed an uncharacteristically decent interface, but anyway:
What is wrong with GL?
Daniel
I still have to disagree. Most RTS games follow a very simple pattern: build lots of buildings, then build lots of units, then send the units to go fight the enemy. IMO, War2 is actually particularly *bad* in this respect. And yes, accomplishing those goals is more a function of how fast you can hit the buttons that of any great strategical insight.
Daniel
Chess is a good game of logic and strategy, but it is hardly the epitome of either. I prefer RTS games like Red Alert or Warcraft - the AI stinks but when you play against a human there is no comparison.
:) ) Even Civilization has to take second place, IMO. (although that's a far better comparison)
I'm sorry, but that's just blasphemy. Comparing the clickfest that is your average RTS to the intellectual exercise of chess? The only thing that could explain such a gross misapprehension is that you have never studied chess more deeply than the Parker Bros. rulebook. I don't think I can enlighten you in this space, but get a couple of good chess books and read them -- it's far deeper than anything to come out of the computer game companies (not that those games aren't fun anyway
Also, since you mentioned stalemate--it's generally agreed that chess has to have one of two outcomes if played perfectly: either White wins or it's a draw. (Black could win, but most chess-players would eat their hats (metaphorically) if that turned out to be the case) Note that one of these *has* to be true: if there's ever a position where a player has two moves, one of them inevitably leading to a better end for him, he'll take the better one, and this can be extrapolated back up the game tree.
What makes chess still interesting is that even if it were solved, no human would be able to memorize all the intricacies of every line of play. (learning one line of play would be feasible, but all your opponent has to do is to play a line that you don't know, even if it's slightly worse) Given this, we have to fall back on general pattern-recognition and short-term calculation, which makes it still a game of skill and justifies comments like "slightly better" when a 'perfect' game only has three, very discrete valuations of positions.
Daniel
Transmitting anything except passive data -- that is, using a network like this to download programs, source, or even files you're editing in Emacs -- sounds like a really good way to get the trojan of the week faster than you ever could before..
Daniel
That post should probably be attached one level up; my web browser doesn't mark italicized text and I didn't realize that those words were a quote..
Daniel
Catastrophic loss of life? No, not unless you count the bajillions of species we've killed deliberately and inadvertantly (seen any American chestnuts or bison lately? They're the lucky ones; they're still around, if barely.)
Daniel
Does anyone know what the state of e2compr support in 2.4 will be? I read in Kernel Traffic that it's not ready for the official kernels, but that someone finally explained to the e2compr maintainer how to port it to the new buffer-cache system..but I haven't heard anything that indicates that such porting is actually occuring. I'm starting to think that I may have to decompress my whole hard drive to try this..which may be difficult given that I'm operating close to capacity ;-)
Daniel
I was under the impression that COM/DCOM was some sort of an object-oriented system for remote procedure calls (I guess if you're using objects that should be 'remote method calls'..)
CORBA and RPC don't need kernel support. (well, aside from requiring some sort of network layer, but the kernel doesn't have to know about them) What's special about COM that requires it to go in the kernel? Why not put an NFS server and an httpd in the kernel while you're at it..er, nevermind..
Daniel
What I know is that Solaris manages its actual threads in userspace, and can map any number of 'threads' onto any number of 'processes', where a process is an object the kernel knows about and schedules. (They're usually called "user threads" and "kernel threads", but that can get a bit confusin :) ) Of course, a UNIX process can consist of several of these 'processes'.
What I've heard is that this gives you:
-> Flexibility, since you can decide whether to do threading entirely in userspace, entirely in the kernel, or both, and
-> Speed, since threading constructs (eg, mutexes) CAN be handled entirely in user code (but, I assume, not always)
A related issue is that the Solaris scheduler is supposedly better than Linux's for large numbers of processes; I have heard (I haven't bothered to check myself as it doesn't impact me, since I run relatively few processes; this may be outdated) that Linux's scheduler runs in O(n) (or maybe worse?) time in the number of processes, while the Solaris scheduler is more efficient. (I believe Solaris uses a table-driven mechanism to schedule processes)
Unfortunately, I don't know how true this is for current versions of Linux (and Solaris, but they haven't released anything big I know of since I got this info)
Daniel
I'm not sure, but I /think/ that pthreads actually handles thread-specific data by having a (shared) table indexed (or maybe hashed) by the thread ID. This works but is somewhat inefficient. As I recall, the debate in question (which I happened to read on Kernel Traffic through a freak accident :) ) revolved around using VM magic to make some pages of an address space private to the thread and others shared between processes. Or something like that. This would be more efficient, but I guess it was decided that it would add to much bookeeping and cruft to the kernel.
Daniel
In that case, I have to conclude that it's possible to create an RPM by staring at the screen and willing it into existence.
Daniel
Huh? I'm a little confused; when I've run Mozilla it looked like it was running single-threaded. Where does SMP come in? (also, a well-written threaded program shouldn't encounter bugs only when running with SMP..these probably bite non-SMP users occasionally, but SMP just exacerbates them..for example, from the bug logs, the problem seems to be that the internal Mozilla memory-allocation/refcounting system wasn't thread-safe! This is a big no-no, and I'm not surprised it was causing problems..) Daniel
It's generally (IMO) a good idea to keep your own accounts so you can double-check the bank's. Even banks make mistakes from time to time, for various reasons. Not often perhaps, but noticing when they do is a Good Thing :) Not that I do it, but that's partly because I don't have a good accounting program (Quicken doesn't count for a number of reasons, including the fact that I'd have to reboot to use it, which makes it horrendously inconvenient) Daniel
If I could I'd clean up every piece of messy code I could get my hands on. Heck, I'd rewrite the entire system from scratch.
:)
:) ) -- the logical extension of its current development path -- or collapse under its own weight. Or possibly both.
The fact is, though, that I do not have an infinite amount of time in which to work, and that therefore, I rely on other people to fix things I don't have time to get to. Does this make sense? I'm not sure it makes sense to me
In any event, E is way too broken on a fundamental level to be fixed. I switched to Sawmill and never looked back; I predict that E will either eventually become an entire operating system (possibly even incorporating a kernel
Daniel
Actually, there was a thread on debian-devel the other day that indicated that the memory (actually, X pixmap) leaking may not, in fact, be fixed. People were reporting that their X server was using over a hundred megabytes of memory if left running overnight; the only commonality was that they were running Gnome and using various imlib-based things (pixmap themes, transparent Eterms, etc)
This is actually worse than your average memory leak, as the only way to recover the memory is to restart X.
Daniel
Yes, I might. Let me look at it again. They say Gnome 2.0 will be based on GTK+ 1.4. Fine. They also say Gnome 2.0 will release 'around fall 2000'. Ok. So you *could* infer that GTK+ 1.4 will be released around fall 2000
:)
However, the Gnome folks don't speak for the GTK+ folks, and the GTK+ 1.4 release could be scheduled for any time prior to or after the Gnome 2.0 release, which is already pointed at a rather vague target. I'd like to hear from someone who knows something about GTK+ developement when I can start using the new version
Daniel
Oops. Correct.
Daniel