Cg is useful right now. Some people will use it. If graphics hardware evolves into more general purpose CPU's, then people will use "something else". "Vector C" might be that "something else", although it is hard to predict the future.
I'd rather put my eggs in the "works right now"-basket then gamble on how the future will be. It is too early to standardize on something that doesn't even exist (or only exists for the PS2), so "Vector C" will not replace Cg anytime soon. Give it 5-10 years, and we will see what happens. In the meantime, if Cg is useful to you, go ahead and make use of it.
And please don't worry about standardization just yet. Before we can standardize, we need to find out which features are useful, and that will take several years of experimentation and competition in the marketplace. In the meantime, Cg could come in handy.
You are right, I didn't know that. I do intend to learn more about CPS sometime;-)
Of course, not all functional languages are implemented using CPS (e.g. Ocaml). But smlnj is (I think), so all the more power to your original example.
Thanks for your correction, which quickly led me to some interesting websurfing on the topic;-)
Well, but Christopher Alexanders books are not about patterns, they are about describing patterns, something which is completely orthogonal to the (slowly fading) pattern movement in OO programming.
Whereas GoF's "design patterns" list some design patterns, Alexander describes a "pattern language" useful for expressing such patterns (although in architecture, not programming).
And also, whether you codify your "design patterns" in a reusable library, or rewrite it in your favourite but limited OO language any time you need it, you would still need a good description of it, so I don't think neither approach is completely useless.
Well, but if you also had learnt your lesson, you should have written it tail-recursive:
fun fact n = fact' n 1; fun fact' 0 res = res | fact' n res = fact' (n-1) (n*res);
In this case it becomes as fast as a typical loop. This of course makes the code slightly more complex, and explains why most programming languages have loops.
I've noticed a lot of C++ heads saying this. But in practice, it is often the best solution. Often you want to use other compilers than the latest and greates gcc, or something based on EDG's frontend. And often you have 10 year old code that you want to continue using without changing everything. (At least we have, we can't even compile it using recent compilers, but it's definitely on the to-do list, because the workarounds for missing new features are really starting to bite us in the ass (and the availability of old enough compilers on new Sun hardware is also starting to make things difficult)).
Secondly, I've never heard about a case where "using namespace std;" has really created more problems than it "solved". I guess I agree in principle, but in practice, it just makes life too fucking difficult, we have some real problems to solve as well, and can't constantly keep bickering with the everchanging C++ recommendations.
Sometimes it pays off to be a little bit pragmatic, and collisition with stuff in namespace "std" are really rare (anyone designing a C++ library knows better than to name something global "read", "cout", "vector", or "remove_duplicates". And if that wasn't the case, and we had to use the library anyway, we would know better than to import that library's namespace into the global one. But if even that wasn't true, we might get into trouble. At this end of the probability scale I worry more about proper error checking/handling of system calls, thread synchronization, signal handling, interprocess communication and networking, etc.
On the other hand, if you are writing new C++ libraries, there is no excuse for not managing your namespace properly.
Anyone can suggest a book, and anyone can give a book a vote. Max 3 votes per registered user per category.
I suspect somebody suggested Schildt just to see if someone would vote it up. Nobody did (that's a pretty strong non-recommendation in my eyes). A date on when the book was suggested and a last vote could be helpful in understanding these things. As could reading the FAQ I guess.
For Perl, I wouldn't bother with any kind of reference. Just find scripts that roughly do what you want and hack them; it's blind groping around, but that's the way Perl works.
And people are wondering why Perl code is read-only? Well, if you never take the time to learn the language, use constructs you don't understand, and rely solely on cookbook approaches instead of understanding and thinking, that is going to be the result.
I am certainly not a Perl bigot (well, I guess I am a SML bigot if I had to be called a bigot), but have used Perl for many really small tasks (i.e less than 10 lines), and at least one semi-large (ca 6000 lines of parser and code-generator). And I will tell you, in both cases (the large project as well), Perl was the perfect language for the job. And if you insist upon slapping things together, just because it is Perl, you loose the benefit of knowing how to slap something good together really fast, and actually maintenable, because that's where Perl shines.
I find it quite curious that people in the SML community think they have the perfect module system (while in reality it's just too complex for most people to exploit). And people in the scheme community can't even agree on a module system. And that the language most frowned upon in both camps (Perl), has a module-system that works so well that CPAN is actually useful.
You have to be pragmatic about when to use Perl. But if you haven't learned it, you can't be that.
I would disagree strongly with that. If what you need is "practical", then you are already a programmer and should buy K&R. I've actually read Oualline's book, and there was nothing of interest there.
On the other hand, Deitel and Deitels book may not be perfect, but they are pretty good for a typical first-year "introduction to programming" course. I'm sure there are plenty of alternatives out there, but Deitel and Deitel really aren't that bad (of course, I can't comment on the C version, as I've only read the Visual Basic version (because I had to teach it, I wouldn't normally read such a book otherwise), which by the way struck me as perhaps the only decent VB book out there).
Why can't the fucking virus writers understand that they need to be portable across platforms? It seems most virus writers these days are targetting Microsoft products without so much as a thought about portability. What about users running MacOS, Linux, Solaris, *BSD or any other operating system? What about users who don't even have a modem? And what about users in other countries where the emergency number is different from that in the US? This virus is buggy as hell, I wouldn't want it if my life depended on it! (pun intended).
Anyone know anything more about this?
on
Triangle Boy Lives
·
· Score: 4, Interesting
How does it work? What does "stealth" mean in this context? Why wouldn't it be blocked by people having firewalls explicitly for the purpose of locking someone in?
According to this article it works by spoofing the the source address. I know at least my firewall would block that.
And furthermore, it needs to contact a server somewhere (that is, another PC running triangle boy). Now, unless they rely on word-of-mouth to tell people where those servers are, they would have to have one or more (easily blockable) servers to hand out IP-addresses and port numbers to connect to.
I don't know what's the most frightening part. That administrators think they must block users instead of simply having strict but reasonable rules that people will understand and follow? That windows let users install programs like triangle-boy without administrator privileges (or that administrators regularly give users administrator privileges). That most commercial firewalls don't block spoofed addresses? That administrators who for some reason want to lock users in don't know about Triangle boy?
But there are several perfectly acceptable solutions to this. The first one is to have more read/write heads. I don't know how many it's realistic to squeeze in, but I would be surprised if it wasn't possible to squeeze in at least 50 (it might be too expensive though).
The second, and not so obvious solution is to spin the player in the opposite direction of the cd. Then both can rotate at their maximum angular speed, and the effective angular speed will be the sum of the CD-speed and the player speed. I'm not sure how fast you can spin a cd-player before moving the heads precisely will become a problem, but if you throw enough money at it, I'm sure it's probably close to the speed you can spin a CD at.
On the other hand, I'm relatively happy with my 40x burner. 2-3 minutes for burning a full CD is about as tolerable as floppies used to be. If I want something more from CDs now, it must be safety (never loose data), storage capacity, and being able to use them as a real read-write medium, not something that needs to be "blanked".
I think we need a new system. Credits for donations are of course useful, but most people just don't like to donate. And as several posters have mentioned, few people have the resources to pay for new features alone. The Perl people have done pretty good with their schemes to keep people like Damian occupied. And I think something like that is needed. You need to pay for something you see the benefit of.
Personally, I don't like the word "donate", as it basically means giving away money, and not caring how it is used. If you pay for Damian to work on Perl, you more or less know what you get (well, not really, but you know it's going to be really cool stuff). If someone put up a similar project to pay for some gcc überhacker, I might be interested. On the other hand, just donating my windows tax to the gcc project without knowing how it will be spent seems a little silly.
And more over, if people aren't interested enough in the same feature I want, I don't want my money to be used for other things (I guess most people organizing this sort of thing are pretty ethical, and try to use the money for something similar, but I still don't like the idea of random donations.
We need a safe scheme for both parties (donators and developers) to raise money from the public, where the developers only get the money if it is enough to keep them occupied on the project it is supposed to help, and otherwise, nobody looses anything. I'm not sure how something like this would work, trust is hard to establish across economic and legal borders.
It seems to me that we need some trusted financial entity (third-party) to organize the fundraising, that is acceptable to both developers and donators. I guess the ideal entity would be a bank, put your donations into the banks account, and unless the minimum amount of money is reached (after some agreed-upon date) the bank promises to pay everybody back (minus some fees of course). Anybody knows if this is a realistic option?
They probably can run it as an application. On the other hand, if they need real realtime features, it's possible that they will need to run in kernel space, and that might be a problem with the GPL (although there does seem to exist binary drivers for linux, hmmm...)
The fact that you appear to make a distinction between "deterministic" and "non-deterministic" finite state-machines makes me think that you have absolutely no idea how Perl regexps differ from the regular expressions we all learned about in CS class.
Well, I guess your professor also told you that regular expressions could be used for pattern matching in computers (not just generating strings that were members of a language L). And in this case, that there were two alternatives for implementation, either as a deterministic of non-deterministic automata. And since non-deterministic automata can be converted to a deterministic one by some simple rules, that leaves only one reasonable alternative for implementation of regular expression pattern matchers on computers: the deterministic one.
There are two problems with this: First of all, the conversion from deterministic to nondeterministic automata can lead to a state-explosion, and second, you might want to add new features to a regexp engine making it recognize more than just what can be described by a regular expression, and this can be easier to do, if your implementation does not use the classical deterministic finite state machine as implementation. Some implementations (Perl) choose to say the use non-deterministic regexp engines, and while that might be formally meaningless, it gives a pretty good idea of how it works informally.
Re:Regular Expressions Haven't Changed
on
Next Generation Regexp
·
· Score: 3, Interesting
Well, that's true because regular expressions is nothing but a compact way to describe a deterministic finite state-machine. On the other hand, regexps are not. Regexps has nothing at all to do with deterministic finite state machines, except for the fact that the syntax is inspired by them.
PS: Note the difference between "regular expression" which is what they teach you about in CS classes, and "regexps", which is what programmers actually use in Perl and many other languages.
Maybe, but I think many people would watch dubbed movies. The problem is of course that the people who actually like movies enough to pay for a movie-ticket does not. And then it's a matter of economy again.
And there's also the problem of having enough good actors to use for dubbing. There isn't that many obvious candidates to choose from, and people might get a bit annoyed about the same person having the voice of three different persons in the same film (in a low-budget dubbing).
That's true, but try to sell a wordprocessor that doesn't do proper spelling and grammar checking in both Bokmål and Nynorsk to norwegian government. Or a spreadsheet program that insists on displaying currency in dollars. That will not go well. On the other hand, whether the file-menu is called "File" or "Fil" probably doesn't matter much.
Interesting how here on/., when discussing an alternative to MS, the first (and usually only) alternative to be discussed is Linux.
With mucho reason in this case!
[snip]
Becooooze, not only would they be moving from one proprietary sh*t to another, but they would have to replace all their fsking hardware!
But what you are not considering is that for the machines they already have got, they already have the fucking licenses for MS products. If they are going to choose competitive products, it will be at a time when they can save some fucking money on it, not just to avoid using the products they've already paid for.
So Macs, in this case makes a lot of sense.
Continue using w2k/xp also makes a lot of sense.
Linux on the desktop still doesn't make much sense from a total cost of ownership point of view (which includes training, support, and remotely intelligent admins).
Replacing office with some cheaper or free software suite makes a lot of sense (as long as you can have reasonable import filters).
Using linux servers with samba instead of NT Server or 2k Server also makes a lot of sense. (Especially if you can get a specialized distribution covering those needs well, i.e. not a generic server, but one geared towards samba domain master/fileserver that is easy to administrate for beginners, i.e. webmin, swat, etc preconfigured).
But you will not see anyone removing w2k from all the machines in an office-building just to replace it without linux, unless it is some really twisted secretaries working there...
Probably, but I don't see much of a reason for it. There are two operations: "apt-get update" and "apt-get upgrade". Having a GUI would mostly be like Windows (press Next to continue, Next, Next, "I agree", Next, Next, Next, Next, Next, Next, Next, Next, Finish). I never saw much of a point in that. If I could type "install -yes" in windows, I would do that as well.
Why does it have to come down to a distro war? I use Redhat, i am comfortable with it but i am truthful enuff to admit that dependencies are still a problem with it, especially with library versioning.
It's not a distro war. It's just a suggestion. RedHat does have problems with dependencies. Debian does not have problems with dependencies. Debian just works, and keeps on working, no matter how much you upgrade it. apt-get update; apt-get upgrade have never given me troubles. And it has saved me a lot of time, compared to earlier times when RedHat, Mandrake or Slackware forced me to do a reinstall every 6 months (if I wanted something new to play with). I realize that there are other reasons to like RedHat (such as commercial support (nah, probably not), or that it's the preferred target of most commercial application vendors (yes, that's really a good reason). But if solving the dependency problems are more important to you, then Debian is the way to go.
I find many of the things he describes quite useful ideas. But item #6 really perplexes me.
when in X, WM should keep track of processes and the windows they are attached to. When an app has no windows open (or the main window is not open), the WM should attempt to kill them (first normally, then with -9).
This is a completely useless idea. First, the window-manager has no knowledge of pid's (or user-names, remote machine ip-address) etc, for the windows it manages. And even if it is possible to find it in many cases, that doesn't mean it should need to.
Consider an xterm. It is certainly intended to run lot's of programs not opening windows. I do not want my window-manager to kill those (nor do I want it to kill the sessions of other users, daemons running on the machine, or any process running on remote machines).
Ok. so we can fix this by excluding applications that never opened a window (or other kind of connection to the X-server). But that would mean that any kind of deamon (such as e.g. a winpopup daemon aka the one for windows SMB messages), or other background programs monitoring stuff and popping up warnings or error messages would be killed. And there are lot's of other useful X11 utilities that doesn't need their own window. One common example is a screensaver (well at one point it will need a window, but the whole point of a screensaver is to stay out of the way except when you are out of the way). Another would be a program for changing the background image, programs that do session management, menus on the root window, responds to various hotkeys in weird ways, etc...
Randomly killing stuff is seldom a good idea. Randomly killing stuff with -9 is an even worse idea, and if anyone ever tries to do that to me (whether as a result of me running their program, or they just being friendly) it will surely inspire me to experiment with completely new and extremely painful methods of torture on their bodies.
I'm curious, what happens if you answer yes?
Does it really "format" it?
Re:Now I remember why school sucked...
on
Pet Bugs?
·
· Score: 2
This is quite common with older games. Typically they will time a delay loop at initialization. (If the computer is very fast, the time taken will be zero.) Then a large number is divided by the time, to get a reasonable length for a delay loop inside the game. Have a fast computer? Expect division by zero!
Re:GCC 2.x and 3.x compiler
on
Pet Bugs?
·
· Score: 2
Actually, that's what a static program analyzer is supposed to do. A compiler is supposed to take source code and translate it to native code (or some other format such as java byte codes, or some other computer language). (But yes, most people like the compilers they use to do some code-checking as well.)
It's impossible to tell what's wrong in your case, since all you've said so far is akin to "we find lot's of errors, should we test less?"
And the answer to that is of course: "No, you should test more, and fix the bugs". And of course, looking over your development model to see why you have so many errors might be a good idea (such as formalizing who can commit code, if you've got lot's of programmer at various skill-levels).
But in real-life, many bugs are not that important, and time-to-market and development cost is more important.
So unless you provide us with more data, such as...
development process, type of product, size of product, complexity of product, severity of bugs, age of most bugs found, bug-review process, testing schedule, testing process, how you manage your version control tree, whether you are on or behind schedule (and if behind, how much), how management deals with the problem, etc...
...I don't think anyone will be able to give any good advice either.
Slashdot Mirror
I'd rather put my eggs in the "works right now"-basket then gamble on how the future will be. It is too early to standardize on something that doesn't even exist (or only exists for the PS2), so "Vector C" will not replace Cg anytime soon. Give it 5-10 years, and we will see what happens. In the meantime, if Cg is useful to you, go ahead and make use of it.
And please don't worry about standardization just yet. Before we can standardize, we need to find out which features are useful, and that will take several years of experimentation and competition in the marketplace. In the meantime, Cg could come in handy.
Of course, not all functional languages are implemented using CPS (e.g. Ocaml). But smlnj is (I think), so all the more power to your original example.
Thanks for your correction, which quickly led me to some interesting websurfing on the topic ;-)
Whereas GoF's "design patterns" list some design patterns, Alexander describes a "pattern language" useful for expressing such patterns (although in architecture, not programming).
And also, whether you codify your "design patterns" in a reusable library, or rewrite it in your favourite but limited OO language any time you need it, you would still need a good description of it, so I don't think neither approach is completely useless.
fun fact n = fact' n 1;
fun fact' 0 res = res |
fact' n res = fact' (n-1) (n*res);
In this case it becomes as fast as a typical loop. This of course makes the code slightly more complex, and explains why most programming languages have loops.
I've noticed a lot of C++ heads saying this. But in practice, it is often the best solution. Often you want to use other compilers than the latest and greates gcc, or something based on EDG's frontend. And often you have 10 year old code that you want to continue using without changing everything. (At least we have, we can't even compile it using recent compilers, but it's definitely on the to-do list, because the workarounds for missing new features are really starting to bite us in the ass (and the availability of old enough compilers on new Sun hardware is also starting to make things difficult)).
Secondly, I've never heard about a case where "using namespace std;" has really created more problems than it "solved". I guess I agree in principle, but in practice, it just makes life too fucking difficult, we have some real problems to solve as well, and can't constantly keep bickering with the everchanging C++ recommendations.
Sometimes it pays off to be a little bit pragmatic, and collisition with stuff in namespace "std" are really rare (anyone designing a C++ library knows better than to name something global "read", "cout", "vector", or "remove_duplicates". And if that wasn't the case, and we had to use the library anyway, we would know better than to import that library's namespace into the global one. But if even that wasn't true, we might get into trouble. At this end of the probability scale I worry more about proper error checking/handling of system calls, thread synchronization, signal handling, interprocess communication and networking, etc.
On the other hand, if you are writing new C++ libraries, there is no excuse for not managing your namespace properly.
I suspect somebody suggested Schildt just to see if someone would vote it up. Nobody did (that's a pretty strong non-recommendation in my eyes). A date on when the book was suggested and a last vote could be helpful in understanding these things. As could reading the FAQ I guess.
And people are wondering why Perl code is read-only? Well, if you never take the time to learn the language, use constructs you don't understand, and rely solely on cookbook approaches instead of understanding and thinking, that is going to be the result.
I am certainly not a Perl bigot (well, I guess I am a SML bigot if I had to be called a bigot), but have used Perl for many really small tasks (i.e less than 10 lines), and at least one semi-large (ca 6000 lines of parser and code-generator). And I will tell you, in both cases (the large project as well), Perl was the perfect language for the job. And if you insist upon slapping things together, just because it is Perl, you loose the benefit of knowing how to slap something good together really fast, and actually maintenable, because that's where Perl shines.
I find it quite curious that people in the SML community think they have the perfect module system (while in reality it's just too complex for most people to exploit). And people in the scheme community can't even agree on a module system. And that the language most frowned upon in both camps (Perl), has a module-system that works so well that CPAN is actually useful.
You have to be pragmatic about when to use Perl. But if you haven't learned it, you can't be that.
On the other hand, Deitel and Deitels book may not be perfect, but they are pretty good for a typical first-year "introduction to programming" course. I'm sure there are plenty of alternatives out there, but Deitel and Deitel really aren't that bad (of course, I can't comment on the C version, as I've only read the Visual Basic version (because I had to teach it, I wouldn't normally read such a book otherwise), which by the way struck me as perhaps the only decent VB book out there).
Why can't the fucking virus writers understand that they need to be portable across platforms? It seems most virus writers these days are targetting Microsoft products without so much as a thought about portability. What about users running MacOS, Linux, Solaris, *BSD or any other operating system? What about users who don't even have a modem? And what about users in other countries where the emergency number is different from that in the US? This virus is buggy as hell, I wouldn't want it if my life depended on it! (pun intended).
According to this article it works by spoofing the the source address. I know at least my firewall would block that.
And furthermore, it needs to contact a server somewhere (that is, another PC running triangle boy). Now, unless they rely on word-of-mouth to tell people where those servers are, they would have to have one or more (easily blockable) servers to hand out IP-addresses and port numbers to connect to.
I don't know what's the most frightening part. That administrators think they must block users instead of simply having strict but reasonable rules that people will understand and follow? That windows let users install programs like triangle-boy without administrator privileges (or that administrators regularly give users administrator privileges). That most commercial firewalls don't block spoofed addresses? That administrators who for some reason want to lock users in don't know about Triangle boy?
The second, and not so obvious solution is to spin the player in the opposite direction of the cd. Then both can rotate at their maximum angular speed, and the effective angular speed will be the sum of the CD-speed and the player speed. I'm not sure how fast you can spin a cd-player before moving the heads precisely will become a problem, but if you throw enough money at it, I'm sure it's probably close to the speed you can spin a CD at.
On the other hand, I'm relatively happy with my 40x burner. 2-3 minutes for burning a full CD is about as tolerable as floppies used to be. If I want something more from CDs now, it must be safety (never loose data), storage capacity, and being able to use them as a real read-write medium, not something that needs to be "blanked".
Personally, I don't like the word "donate", as it basically means giving away money, and not caring how it is used. If you pay for Damian to work on Perl, you more or less know what you get (well, not really, but you know it's going to be really cool stuff). If someone put up a similar project to pay for some gcc überhacker, I might be interested. On the other hand, just donating my windows tax to the gcc project without knowing how it will be spent seems a little silly.
And more over, if people aren't interested enough in the same feature I want, I don't want my money to be used for other things (I guess most people organizing this sort of thing are pretty ethical, and try to use the money for something similar, but I still don't like the idea of random donations.
We need a safe scheme for both parties (donators and developers) to raise money from the public, where the developers only get the money if it is enough to keep them occupied on the project it is supposed to help, and otherwise, nobody looses anything. I'm not sure how something like this would work, trust is hard to establish across economic and legal borders.
It seems to me that we need some trusted financial entity (third-party) to organize the fundraising, that is acceptable to both developers and donators. I guess the ideal entity would be a bank, put your donations into the banks account, and unless the minimum amount of money is reached (after some agreed-upon date) the bank promises to pay everybody back (minus some fees of course). Anybody knows if this is a realistic option?
They probably can run it as an application. On the other hand, if they need real realtime features, it's possible that they will need to run in kernel space, and that might be a problem with the GPL (although there does seem to exist binary drivers for linux, hmmm...)
Well, I guess your professor also told you that regular expressions could be used for pattern matching in computers (not just generating strings that were members of a language L). And in this case, that there were two alternatives for implementation, either as a deterministic of non-deterministic automata. And since non-deterministic automata can be converted to a deterministic one by some simple rules, that leaves only one reasonable alternative for implementation of regular expression pattern matchers on computers: the deterministic one.
There are two problems with this: First of all, the conversion from deterministic to nondeterministic automata can lead to a state-explosion, and second, you might want to add new features to a regexp engine making it recognize more than just what can be described by a regular expression, and this can be easier to do, if your implementation does not use the classical deterministic finite state machine as implementation. Some implementations (Perl) choose to say the use non-deterministic regexp engines, and while that might be formally meaningless, it gives a pretty good idea of how it works informally.
PS: Note the difference between "regular expression" which is what they teach you about in CS classes, and "regexps", which is what programmers actually use in Perl and many other languages.
And there's also the problem of having enough good actors to use for dubbing. There isn't that many obvious candidates to choose from, and people might get a bit annoyed about the same person having the voice of three different persons in the same film (in a low-budget dubbing).
That's true, but try to sell a wordprocessor that doesn't do proper spelling and grammar checking in both Bokmål and Nynorsk to norwegian government. Or a spreadsheet program that insists on displaying currency in dollars. That will not go well. On the other hand, whether the file-menu is called "File" or "Fil" probably doesn't matter much.
With mucho reason in this case!
[snip]
Becooooze, not only would they be moving from one proprietary sh*t to another, but they would have to replace all their fsking hardware!
But what you are not considering is that for the machines they already have got, they already have the fucking licenses for MS products. If they are going to choose competitive products, it will be at a time when they can save some fucking money on it, not just to avoid using the products they've already paid for.
So Macs, in this case makes a lot of sense.
Continue using w2k/xp also makes a lot of sense.
Linux on the desktop still doesn't make much sense from a total cost of ownership point of view (which includes training, support, and remotely intelligent admins).
Replacing office with some cheaper or free software suite makes a lot of sense (as long as you can have reasonable import filters).
Using linux servers with samba instead of NT Server or 2k Server also makes a lot of sense. (Especially if you can get a specialized distribution covering those needs well, i.e. not a generic server, but one geared towards samba domain master/fileserver that is easy to administrate for beginners, i.e. webmin, swat, etc preconfigured).
But you will not see anyone removing w2k from all the machines in an office-building just to replace it without linux, unless it is some really twisted secretaries working there...
Probably, but I don't see much of a reason for it. There are two operations: "apt-get update" and "apt-get upgrade". Having a GUI would mostly be like Windows (press Next to continue, Next, Next, "I agree", Next, Next, Next, Next, Next, Next, Next, Next, Finish). I never saw much of a point in that. If I could type "install -yes" in windows, I would do that as well.
It's not a distro war. It's just a suggestion. RedHat does have problems with dependencies. Debian does not have problems with dependencies. Debian just works, and keeps on working, no matter how much you upgrade it. apt-get update; apt-get upgrade have never given me troubles. And it has saved me a lot of time, compared to earlier times when RedHat, Mandrake or Slackware forced me to do a reinstall every 6 months (if I wanted something new to play with). I realize that there are other reasons to like RedHat (such as commercial support (nah, probably not), or that it's the preferred target of most commercial application vendors (yes, that's really a good reason). But if solving the dependency problems are more important to you, then Debian is the way to go.
when in X, WM should keep track of processes and the windows they are attached to. When an app has no windows open (or the main window is not open), the WM should attempt to kill them (first normally, then with -9).
This is a completely useless idea. First, the window-manager has no knowledge of pid's (or user-names, remote machine ip-address) etc, for the windows it manages. And even if it is possible to find it in many cases, that doesn't mean it should need to.
Consider an xterm. It is certainly intended to run lot's of programs not opening windows. I do not want my window-manager to kill those (nor do I want it to kill the sessions of other users, daemons running on the machine, or any process running on remote machines).
Ok. so we can fix this by excluding applications that never opened a window (or other kind of connection to the X-server). But that would mean that any kind of deamon (such as e.g. a winpopup daemon aka the one for windows SMB messages), or other background programs monitoring stuff and popping up warnings or error messages would be killed. And there are lot's of other useful X11 utilities that doesn't need their own window. One common example is a screensaver (well at one point it will need a window, but the whole point of a screensaver is to stay out of the way except when you are out of the way). Another would be a program for changing the background image, programs that do session management, menus on the root window, responds to various hotkeys in weird ways, etc...
Randomly killing stuff is seldom a good idea. Randomly killing stuff with -9 is an even worse idea, and if anyone ever tries to do that to me (whether as a result of me running their program, or they just being friendly) it will surely inspire me to experiment with completely new and extremely painful methods of torture on their bodies.
I'm curious, what happens if you answer yes? Does it really "format" it?
This is quite common with older games. Typically they will time a delay loop at initialization. (If the computer is very fast, the time taken will be zero.) Then a large number is divided by the time, to get a reasonable length for a delay loop inside the game. Have a fast computer? Expect division by zero!
Actually, that's what a static program analyzer is supposed to do. A compiler is supposed to take source code and translate it to native code (or some other format such as java byte codes, or some other computer language). (But yes, most people like the compilers they use to do some code-checking as well.)
And the answer to that is of course: "No, you should test more, and fix the bugs". And of course, looking over your development model to see why you have so many errors might be a good idea (such as formalizing who can commit code, if you've got lot's of programmer at various skill-levels).
But in real-life, many bugs are not that important, and time-to-market and development cost is more important.
So unless you provide us with more data, such as ...
...I don't think anyone will be able to give any good advice either.