My limited experience with Windows (2k/XP pro mostly) seems to be that as long as you reboot daily (say, close it before going to bed, and start again next morning) everything is fine (for the first 6-12 months, after which things start falling apart and one needs a reinstallation).
My experience with Linux is that it is MUCH more common to need a reboot because of hardware changes than see it crash, and that doesn't mean I change hardware often, although I admit I sometimes also boot in order to install a newer kernel.
Actually, while I agree on the main point, I must disagree to a certain degree, because my empirical experience suggests something different: If something looks complicated, there's a good chance that by trying to write it in a more clear/straightforward (so as to make it easier to understand) will also result in more efficient machine code (as benchmarked).
As such, I'd say: if something is too slow, benchmark it, then try to write a more simple version and benchmark that. Many times the result will be faster (and rest of the time you probably need a better algorithm).
As funny as it sounds, because compilers do fancy optimizations, writing code to "explain the logic to the compiler" might well enable optimizations that a compiler couldn't use on "more optimized" code. One obvious (and simple) example is the "const"-modifier in C, which helps clarify extent of usage to both other programmers AND the compiler; the result in performance can be quite dramatic in truly CPU-bound code.
While I'd argue that global variables are usually a bad idea, I don't see a reason agaist file-scope variables. The rationale goes like this:
In OOP you use Singletons when you only need a single variable of a given type. You do it, because while the Singleton gives you global access to the single variable, it still acts as an encapsulation method. This eliminates one of the problems of global variables: unpredicatable modifications, by allowing the Singleton to define what is allowed and what is not.
Class variables can do the same, since only the method of the class can touch the variables (provided they are private).
But file-scope (static) variables have the same property; the only thing different is that access is restricted not by a class, but by the compilation unit. You still get the same encapsulation.
Another question is whether Singletons should be avoided too. Most of the time I like writing code in such a way, that you can run two (separated) instances of the program within the same process by simply create two objects of the main application class. Unfortunately Singletons are often needed to cope with libraries and APIs that assume there's only client within a process.
IMHO Singletons (and class variables and methods) are to OOP what IO-monads are to functional programming: they are "hacks" that try to work around the limitations of a given programming model, and trying to minimize the damage caused.
Last time I used VS, I had to disable the oh-so-great helper tooltip that shows you the available functions (or attributes or methods or whatever) when you type and then function prototypes so you see the parameters. Why? Because VS insisted on crashing every time it tried to show the stupid tooltip. And yes, it was a clean install. No, patching it didn't help. Yes, it did work flawlessly in an almost identical box.
Not that I actually needed the functionality anyway, as I'd use the whole thing just as a compiler and debugger, editing my sources in ViM instead, thank you very much. =)
Personally I think I've capped my writing speed with QWERTY already. In fact, the problem with my typing has nothing to do with the speed of hitting keys. If we measure the number of characters one can type while manually copying text, then yeah, you get speedups by training more and more, and here you can get some benefit by trying to find a faster layout.
But I already write faster when copying than I write new text. I'm not even a fast typer, just about average (although I can write code heavy on symbols almost as fast as regular text, which probably isn't average except here). So my hypothesis is that the true limit of my writing speed isn't in my ability to handle the keyboard. Instead, I find it much more likely that the true limit is the following pipeline:
Think of what you are going to write.
Convert the idea into words.
Convert the words into series of letters.
Convert the letters into series of positions.
Really, only after you have a series of positions, is it up to fingers to move there, and that part doesn't take much time. In fact, even converting the series of letters into positions isn't bad. I believe it's the first three that take most of the time.
Besides, look at your keyboard. Like somebody quoted above, QWERTY isn't really as slow as most people seem to think.
Actually, I used to have my CV as HTML. Then I had a makefile that run's "lynx -dump" on it (with a few more switches) and then I'd usually send both the HTML and the "plain text" version if no specific requirements were given.
Whether this was good or bad for getting a job, I don't know. But what I do know is that there always was a strong correlation between the preferred document format and the job function. Almost every time any technical people would have the plain text versions printed, while any non-technical people would have the HTML versions printed.
Actually, the consoles not enough, you need the box itself. And even then, while you can then have the hardware, you can't necessarily have the data. It's possible to encrypt everything after the bootloader, and if you need a password in the bootloader to decrypt the main decryption key used to decrypt rest of the system, you are pretty much back to password guessing.
Now, the only way you can hack into such a box is get unrestricted read access to physical memory without rebooting. That allows you to get the decryption key. If you reboot, then you need someone that knows the password (or one of them) to get the decryption key. Ofcourse your console should always be locked or in login prompt when you can't see it.
This is how you should protect a laptop. It's bad enough that somebody steals your laptop, but at least they can't get your data then.
Sure, you still can install a keyboard logger, modify the bootloader or something similar. But at this point it's not enough to have physical access anymore; you need to have physical access and THEN have someone use it. It might not be that hard, but at least you can't simply steal a box anymore.
Since local login applications aren't usually the easiest way to get a shell on a computer without knowing passwords, you probably have a better chance of simply using a remote exploit to get your shell, and then a local exploit to get r00t and whatever you might want to do.
I agree. GIMP's (especially Gimp2's) UI is just fine, and with a good window manager can actually beat any Photoshop style GUI in many cases.
Personally, I'd mostly like better layer system, better beziers (Gimp2 even made them worse still), and a proper brush system with editable, vectorized, speed/pressure/direction sensitive shapes.
I though anyone that found their way to/. should at least know what "echo" does. Anyway, "ls" (in Unix) does basicly the same as "dir" does on windows (or dos), that is, it lists files in the current working directory. Pretty basic stuff.
As for echo, it does basicly the same thing on windows too (IIRC, it's been a while since I really used windows for anything), so maybe lauch cmd.exe and type in "help echo"?
Ofcourse, as always hope springs eternal - but that would also make markets a whole lot deterministic and bring about some serious differences in the way business is done.
But hey, that'd immediately change the markets, so you'd probably need a new model.
I don't believe that predicting the markets on the big scale is ever possible, simply because the predictions affect the system. You would have to predict how your predictions affect the system, and if that was public, then how the predictions on effects of predictions... and so on..
Except the stock scam is pre-arranged. You distribute your predictions evenly, so as to have exactly 10 people with each possible series of predictions (obviously you need 10,240 people for this though, but that's irrelevant).
On the other hand, if you take 32768 random (and independent) things, for each of them you have 32767/32768 chance that it didn't predict correctly. So the chance of none of them predicting the outcome correctly is (32767/32768)^32768 because they are independent. This, in terms of percents is only ~36.8% which means you have ~63.2% chance that (at least) one of them actually happens to predict correctly.
If you are happy with 50% chance you only need to look at 22713 series of events, but if you want 90% certainty, you need to look at about 75450 series. So saying "all but assured" (63.2%) does not give that impressive picture of your statistic ability. For 99% chance you need 150900. Obviously you can't reach full certainty.
That said, you are definitely right in that looking at enough independent actions will (very likely) cause a "correlation" to be found somewhere at some point.
Could you imagine if you're enjoying a 45 days holiday in Europe [...] and when back home find out your phone doesn't work anymore because of this kind of policy?
No, because I don't have a phone anyway you insensitive clod. What good is a wired phone anyway, when one can just use a mobile instead?
My Gentoo build (measured subjectively by using the browser normally) seems to run about as fast as the official Windows build on my girlfriends machine.
What? Not a scientific benchmark? Well, my computer is 800 Duron and my GF's is 1.4 or 1.6 or something Duron or Athlon (can't remember), so I guess the Gentoo build at least here seems to beat Windows build.
Except... well.. I think the bottle-neck is the network connection after all.. How many have network connections so fast that browser performance is an issue? And even then, might it be that the Flash-ads are what eat most of the CPU after all.
As for X-chat, every individual who has contributed code needs to step up and demand the code be removed. The rest of us should remove the program, cease any participation in the development thereof, and make clear to the developer that we cannot accept his interpretation of the GPL, and that no OSS project can survive in an environment of apathy, which his current actions are virtually guaranteed to create.
Nah, we should fork the project instead.. X-Chat is too good to be killed. It is a very good, clean, usable client you can teach anyone to use in a few minutes. I personally want to be able to contact people by IRC, and I want to be able to provide them with a good, clean, easy-to-use client with a decent graphical interface. And of the clients available, X-Chat is IMHO far better than the rest.
Indeed. If you do that, everybody starts breaking builds just to turn the damn lamp on. Better make it so that when a build breaks, the lamp get's turned OFF so people get angry from not being able to watch it. That way nobody dares to break the build, and somebody does, other people might even come to help fix it, so they can continue their trip^H^H^H^Hwork with proper lighting..
I like to use a basic wooden chair instead of some ultra-modern hyper-ergonomic shit. Why? Because that way that way there's only one way (or two) to sit in it comfortably. Everything else is painful. And it happens that the good way to sit in such a chair is usually good best for my back anyway.
Another thing with not-overly-comfortable chair is that it's easier to remember to stand-up once in a while, and walk around and such. Moving around every once in a while is very good for your back.
Zmodem and even Smodem have been available on Linux as long as I can remember. I think at least Zmodem is probably easily ported to OSX. Whether there's source code for Smodem I do not now (or remember).
Personally, I think I am not old enough to not remember what it was like to be a teenager. And yes, I definitely was into computers bigtime. But apart from that, I found out that never ever should one bother to read a technical book, unless you've learned at least a few things before getting beyond the preface. Why?
If it won't get you any pussy or booze, it should at least teach you enough interesting stuff to make you forget about sex, drugs and rock'n'roll for a minute. If it can't do that, why bother?
I claim, that while middle-aged housewifes won't understand what the mouse is for, almost any teenager, including those that claim not to understand anything about computers, are capable of learning stuff on need-to-know basis. The problem is that most simply won't care a shit.
"You should use a firewall and virus scanner on that." "Why?" "Because otherwise hackers, worms and other malware/troublemakers can use your computer to do things like send spam, track you, spread futher and such. In worst case, even to use your computer for serious hacking. Besides, even otherwise harmless malware can cause your computer to work very badly." "Why would they [virus writers, spammers, hackers, whatever] want my computer?" "They just want any computers they can get." "Oh, well, if they want it so badly, let them have it. There isn't important data on it." "What if they made it look like it was you?" "Me? Well, nobody would believe I could do something like that, and besides I'm under-aged anyway."...
Yes.. give use HD-DVD's or whatever, so that the movies are so big, that they need so fast drives, that unless you put your player in a different room, you can't hear the soundtrack from all the "GHHHRHRHHHRHH" of the DVD drive. That's great.
Then we have to compress the movies to something that can be stored on our hard drives just to avoid the noise caused by HD-DVD drives overheating by trying to read all the data.
This is nothing new. There was a drop in PC-games piracy when CDROM's came, before CD-R drives where commonplace, because copying a full CD without something equally big was much bigger operation than just throwing the game to 20 floppies..
too bad it doesn't work with content that can be compressed with "good enough" lossy compression.
Microsoft is known to be profient in designing new toolbars, so how about adding a button into the IE7 default toolbar to "install Firefox now". Would save those ~40 keypresses and a couple of mouse clicks.
The reason why it's good idea to still keep stuff in 80 columns, is that while you CAN fit much more on modern terminals, you might not WANT to.
Specifically, I DO format to 80 columns, because that's about as much as fits to my standard ViM window. My resolution is 1280x1024, and I'm using a 8pt font in 96dpi. Oh, and my ViM is fullscreen...
The catch is, when the code is split to 80 columns, I can view TWO source files side by side. This also goes with terminals: having two (actually four, one in each "corner") is very nice. So yes, I think that 80 columns per row IS still a good rule.
except the whole point was that almost any filebrowser allows "open in new window" while "open in new tab" would be about 10 times more easy to get things done =)
Slashdot Mirror
My experience with Linux is that it is MUCH more common to need a reboot because of hardware changes than see it crash, and that doesn't mean I change hardware often, although I admit I sometimes also boot in order to install a newer kernel.
As such, I'd say: if something is too slow, benchmark it, then try to write a more simple version and benchmark that. Many times the result will be faster (and rest of the time you probably need a better algorithm).
As funny as it sounds, because compilers do fancy optimizations, writing code to "explain the logic to the compiler" might well enable optimizations that a compiler couldn't use on "more optimized" code. One obvious (and simple) example is the "const"-modifier in C, which helps clarify extent of usage to both other programmers AND the compiler; the result in performance can be quite dramatic in truly CPU-bound code.
While I'd argue that global variables are usually a bad idea, I don't see a reason agaist file-scope variables. The rationale goes like this: In OOP you use Singletons when you only need a single variable of a given type. You do it, because while the Singleton gives you global access to the single variable, it still acts as an encapsulation method. This eliminates one of the problems of global variables: unpredicatable modifications, by allowing the Singleton to define what is allowed and what is not. Class variables can do the same, since only the method of the class can touch the variables (provided they are private). But file-scope (static) variables have the same property; the only thing different is that access is restricted not by a class, but by the compilation unit. You still get the same encapsulation. Another question is whether Singletons should be avoided too. Most of the time I like writing code in such a way, that you can run two (separated) instances of the program within the same process by simply create two objects of the main application class. Unfortunately Singletons are often needed to cope with libraries and APIs that assume there's only client within a process. IMHO Singletons (and class variables and methods) are to OOP what IO-monads are to functional programming: they are "hacks" that try to work around the limitations of a given programming model, and trying to minimize the damage caused.
Not that I actually needed the functionality anyway, as I'd use the whole thing just as a compiler and debugger, editing my sources in ViM instead, thank you very much. =)
But I already write faster when copying than I write new text. I'm not even a fast typer, just about average (although I can write code heavy on symbols almost as fast as regular text, which probably isn't average except here). So my hypothesis is that the true limit of my writing speed isn't in my ability to handle the keyboard. Instead, I find it much more likely that the true limit is the following pipeline:
Really, only after you have a series of positions, is it up to fingers to move there, and that part doesn't take much time. In fact, even converting the series of letters into positions isn't bad. I believe it's the first three that take most of the time.
Besides, look at your keyboard. Like somebody quoted above, QWERTY isn't really as slow as most people seem to think.
Whether this was good or bad for getting a job, I don't know. But what I do know is that there always was a strong correlation between the preferred document format and the job function. Almost every time any technical people would have the plain text versions printed, while any non-technical people would have the HTML versions printed.
Now, the only way you can hack into such a box is get unrestricted read access to physical memory without rebooting. That allows you to get the decryption key. If you reboot, then you need someone that knows the password (or one of them) to get the decryption key. Ofcourse your console should always be locked or in login prompt when you can't see it.
This is how you should protect a laptop. It's bad enough that somebody steals your laptop, but at least they can't get your data then.
Sure, you still can install a keyboard logger, modify the bootloader or something similar. But at this point it's not enough to have physical access anymore; you need to have physical access and THEN have someone use it. It might not be that hard, but at least you can't simply steal a box anymore.
Since local login applications aren't usually the easiest way to get a shell on a computer without knowing passwords, you probably have a better chance of simply using a remote exploit to get your shell, and then a local exploit to get r00t and whatever you might want to do.
Personally, I'd mostly like better layer system, better beziers (Gimp2 even made them worse still), and a proper brush system with editable, vectorized, speed/pressure/direction sensitive shapes.
As for echo, it does basicly the same thing on windows too (IIRC, it's been a while since I really used windows for anything), so maybe lauch cmd.exe and type in "help echo"?
Minimalistic systems don't run zone alarm. In fact, in a minimalistic system you don't install 'ls' as you could do with 'echo *' just as well.
But hey, that'd immediately change the markets, so you'd probably need a new model.
I don't believe that predicting the markets on the big scale is ever possible, simply because the predictions affect the system. You would have to predict how your predictions affect the system, and if that was public, then how the predictions on effects of predictions... and so on..
On the other hand, if you take 32768 random (and independent) things, for each of them you have 32767/32768 chance that it didn't predict correctly. So the chance of none of them predicting the outcome correctly is (32767/32768)^32768 because they are independent. This, in terms of percents is only ~36.8% which means you have ~63.2% chance that (at least) one of them actually happens to predict correctly.
If you are happy with 50% chance you only need to look at 22713 series of events, but if you want 90% certainty, you need to look at about 75450 series. So saying "all but assured" (63.2%) does not give that impressive picture of your statistic ability. For 99% chance you need 150900. Obviously you can't reach full certainty.
That said, you are definitely right in that looking at enough independent actions will (very likely) cause a "correlation" to be found somewhere at some point.
No, because I don't have a phone anyway you insensitive clod. What good is a wired phone anyway, when one can just use a mobile instead?
What? Not a scientific benchmark? Well, my computer is 800 Duron and my GF's is 1.4 or 1.6 or something Duron or Athlon (can't remember), so I guess the Gentoo build at least here seems to beat Windows build.
Except... well.. I think the bottle-neck is the network connection after all.. How many have network connections so fast that browser performance is an issue? And even then, might it be that the Flash-ads are what eat most of the CPU after all.
Nah, we should fork the project instead.. X-Chat is too good to be killed. It is a very good, clean, usable client you can teach anyone to use in a few minutes. I personally want to be able to contact people by IRC, and I want to be able to provide them with a good, clean, easy-to-use client with a decent graphical interface. And of the clients available, X-Chat is IMHO far better than the rest.
Indeed. If you do that, everybody starts breaking builds just to turn the damn lamp on. Better make it so that when a build breaks, the lamp get's turned OFF so people get angry from not being able to watch it. That way nobody dares to break the build, and somebody does, other people might even come to help fix it, so they can continue their trip^H^H^H^Hwork with proper lighting..
Another thing with not-overly-comfortable chair is that it's easier to remember to stand-up once in a while, and walk around and such. Moving around every once in a while is very good for your back.
Zmodem and even Smodem have been available on Linux as long as I can remember. I think at least Zmodem is probably easily ported to OSX. Whether there's source code for Smodem I do not now (or remember).
If it won't get you any pussy or booze, it should at least teach you enough interesting stuff to make you forget about sex, drugs and rock'n'roll for a minute. If it can't do that, why bother?
I claim, that while middle-aged housewifes won't understand what the mouse is for, almost any teenager, including those that claim not to understand anything about computers, are capable of learning stuff on need-to-know basis. The problem is that most simply won't care a shit.
"You should use a firewall and virus scanner on that." "Why?" "Because otherwise hackers, worms and other malware/troublemakers can use your computer to do things like send spam, track you, spread futher and such. In worst case, even to use your computer for serious hacking. Besides, even otherwise harmless malware can cause your computer to work very badly." "Why would they [virus writers, spammers, hackers, whatever] want my computer?" "They just want any computers they can get." "Oh, well, if they want it so badly, let them have it. There isn't important data on it." "What if they made it look like it was you?" "Me? Well, nobody would believe I could do something like that, and besides I'm under-aged anyway." ...
Then we have to compress the movies to something that can be stored on our hard drives just to avoid the noise caused by HD-DVD drives overheating by trying to read all the data.
This is nothing new. There was a drop in PC-games piracy when CDROM's came, before CD-R drives where commonplace, because copying a full CD without something equally big was much bigger operation than just throwing the game to 20 floppies.. too bad it doesn't work with content that can be compressed with "good enough" lossy compression.
Microsoft is known to be profient in designing new toolbars, so how about adding a button into the IE7 default toolbar to "install Firefox now". Would save those ~40 keypresses and a couple of mouse clicks.
The reason why it's good idea to still keep stuff in 80 columns, is that while you CAN fit much more on modern terminals, you might not WANT to. Specifically, I DO format to 80 columns, because that's about as much as fits to my standard ViM window. My resolution is 1280x1024, and I'm using a 8pt font in 96dpi. Oh, and my ViM is fullscreen... The catch is, when the code is split to 80 columns, I can view TWO source files side by side. This also goes with terminals: having two (actually four, one in each "corner") is very nice. So yes, I think that 80 columns per row IS still a good rule.
WTF is "negative messages" anyway??
No, the real question is "SHOULD" GNU ever be a Unix. The whole POINT of GNU is that it's not Unix, it's (or aims to be) something better!
except the whole point was that almost any filebrowser allows "open in new window" while "open in new tab" would be about 10 times more easy to get things done =)