You may open an account here free of charge, and you may do whatever you like with your money; however, when you leave, make sure to take your money with you because we get rid of all the money when we close at night.
I don't do these things with my cell phone, and if I did, I think that it could be done with voice recognition.
Are you saying you would be comfortable saying, for example, your bank account number and pin out loud? Or that you expect all these places that have services to check your accounts by phone to implement voice pattern recognition to identify the person speaking, and do so 100% reliably, so that you wouldn't be able to capture someone else's voice with a tape recorder and play it back to the voice recognition?
Neither option is feasible. What works for you won't work for a lot of people, and if your idea can't be used by people who actually use these features (which I would imagine is closer to the majority of 'heavy' cell phone users), no company in its right mind would want to produce it, at least not without some extremely slick marketing. I doubt even Apple has a clever enough staff to pull it off.
One day Little Sally got her "monthly bleeding" for the first time in her life. Having failed to understand what was going on and being really frightened, she decided to share her trouble with little Joey.
When she found Joey she told him what was happeing, but he didn't quite understand so she showed him what her problem was.
Joey's face got very serious and he said, "You know, I'm no doctor, but it looks like someone ripped your balls off!"
Personally I would like to see programs "correct" that stuff into proper English. Granted, it wouldn't be as useful in Word as, say, IRC and message boards, but anywhere I don't have to read ten lines of (R4p L1|<3 7h15 would be an improvement.
Now, if it autocorrects to leetspeak, then yes, I will be scared as well.
I think it's fashionable to talk like this. When I open my mouth, I sound like a modem. The most interesting part of the conversation is the handshake.
anything you miss from Linux is available (although possibly with a bit of effort) for the Mac.... with the exception of anything written in x86 assembly. ZSNES certainly wouldn't work on a Mac, and I wouldn't want to give it up.
(And yes, I know about Snes9x, and I don't really like it.)
xCode is a programming environment. You're talking about scripting.
So you can't write a program in Python? I suppose none of these projects exist, then. Would you call Quark a script? How about Yahoo Maps? Or Google for that matter?
It is a bit unfortunate that Nutch hasn't received as much attention as it really should, but writing a search engine from scratch is a pretty complex task, especially one that's capable of competing with something like Google.
Think about this: to be effective, a search engine needs to download, basically, the entire Internet. This implies a need for an enormous amount of bandwidth, which translates to lots and lots of money. Where will a little open-source search engine get all this money for all this bandwidth? That's an issue that needs to be addressed before anything like Nutch can work.
Another issue that has to be resolved before an open-source search engine can take off: the development model just doesn't sync up with the way search engines work. You have to keep a big central database somewhere of all the pages the robot has indexed. J. Random Hacker can't just download the source code, hack at it, build it, and try it out at home without access to this database. (Okay, technically he could, but it wouldn't be able to do anything useful.)
you'd curse the day you were performing a critical system update and some jackass decided to form-bomb your system for the fun of it.
And who would that be -- me? If you're doing critical system updates with other untrusted people logged in, perhaps you have larger problems than fork bombs.
FWIW, I have tried to break my system with for(;;)fork();. It didn't work; I could still log in through another tty and kill -9 -1 (though it took a couple seconds as the kernel sorted everything out and got a shell running). It seems like the 2.6 kernel has improved the process management quite a bit, as a few years ago the same fork-bomb brought my system down to the point where there was a noticeable delay between, say, hitting numlock and the LED on the keyboard changing. I don't know; I'm not a kernel hacker.
I don't have such limits set for myself simply because I don't see any reason to do so. In the worst case, I might have to reboot, and when that happens, then I'll bother setting a process limit.
Whining? Excuse me? I was stating a mere fact that a hundred-process limit simply is not enough for all cases.
Since I'm generally the only person using my computer, ps aux|grep $USER|wc -l is still in the range of about 80-90, and can still easily top 100 if I also start up a couple different web browsers (e.g. Konqueror and MSIE in QEMU) to test a page for cross-browser compatibility.
My point is that there is no single limit that can work in all cases. It's an administrative decision that should be based on what the system is going to be used for (multi-user shell account? single user GUI? program development?) and not some arbitrary number that someone picked because it "works for them". It simply won't work for everyone. If you set it to 256, you'll find someone who wants to run 257 processes; if you set it to 512, you'll (eventually) find someone who wants to run 513.
If I limited my system to 100 processes, I wouldn't be able to leave all my programs running on different desktops so that I can switch to something without waiting for it to start up.
As I said here, it might act like Debian, but Debian it's not.
A notable problem with using "spinoff" distributions is package compatibility. Can I install any.deb package on Ubuntu without possibly causing binary version problems? Similarly, can I build a package on Ubuntu, give it to a Debian user, and be sure that it'll work properly on their system?
This is a problem with rpm-based distributions; I don't know if apt handles it in a smarter way than rpm, but I've been burned by it and I'm hesitant to try and see. While on the surface everything may seem to function properly, you never know when doing something seemingly innocent like installing or upgrading a package can open up a huge can of worms. I know; I tried installing some packages from my Mandrake 8.2 CDs on a Red Hat system. The first couple worked without any problems, but I tried installing another package that happened to mess with some other file that was already on the system, and it broke several other seemingly unrelated programs.
This is one of the reasons I'm not using Debian now. It might be stable, have a brilliant program that handles all the installation stuff automagically, and have a great community, but the big problem with it that turned me away is exactly that mindset. The last time I had the inclination to try out something different, I was looking for a non-commercial distro that had recent versions of Gnome and KDE and decent non-annoying package support. Debian had two out of three, but if I got it, it would have been mostly a downgrade for me.
Another really important advantage of releasing more often is that releases attract attention. A new version of something is often enough to get people to try it out, and it could turn out to be very good for Debian. Plus, that's the general mentality anyway -- "release early and often" -- of open-source, and Debian is perhaps the most adherent of the well-known Linux distros to the whole open-source philosophy.
If Debian starts releasing a new version every couple months, I'll be sure to give it a try, and I would imagine many other people feel the same way.
Slashdot Mirror
Welcome to Bank of Knoppix!
You may open an account here free of charge, and you may do whatever you like with your money; however, when you leave, make sure to take your money with you because we get rid of all the money when we close at night.
I don't do these things with my cell phone, and if I did, I think that it could be done with voice recognition.
Are you saying you would be comfortable saying, for example, your bank account number and pin out loud? Or that you expect all these places that have services to check your accounts by phone to implement voice pattern recognition to identify the person speaking, and do so 100% reliably, so that you wouldn't be able to capture someone else's voice with a tape recorder and play it back to the voice recognition?
Neither option is feasible. What works for you won't work for a lot of people, and if your idea can't be used by people who actually use these features (which I would imagine is closer to the majority of 'heavy' cell phone users), no company in its right mind would want to produce it, at least not without some extremely slick marketing. I doubt even Apple has a clever enough staff to pull it off.
http://www.jokes.com/results/detail.asp?id=69
You're editing several 2gb video files with 512 megs of memory? I'd say that's the joke.
For most people, 512 is plenty enough, but if you're doing resource-intensive processing like that, of course you're going to need more memory.
It was recently on the Simpsons.
Personally I would like to see programs "correct" that stuff into proper English. Granted, it wouldn't be as useful in Word as, say, IRC and message boards, but anywhere I don't have to read ten lines of (R4p L1|<3 7h15 would be an improvement.
Now, if it autocorrects to leetspeak, then yes, I will be scared as well.
I think it's fashionable to talk like this. When I open my mouth, I sound like a modem. The most interesting part of the conversation is the handshake.
Quite true.
Gopher will never come back. Doesn't have a catchy enough name.
Something like "Gooooooooopher", on the other hand...
IIRC, you can make Tetris clones all you want as long as you don't use the word "Tetris".
anything you miss from Linux is available (although possibly with a bit of effort) for the Mac. ... with the exception of anything written in x86 assembly. ZSNES certainly wouldn't work on a Mac, and I wouldn't want to give it up.
(And yes, I know about Snes9x, and I don't really like it.)
xCode is a programming environment. You're talking about scripting.
So you can't write a program in Python?
I suppose none of these projects exist, then. Would you call Quark a script? How about Yahoo Maps? Or Google for that matter?
What exactly does a dog without a nose smell like?
No, that'd just cause a duper-nova.
Oh, sorry, try this.
It is a bit unfortunate that Nutch hasn't received as much attention as it really should, but writing a search engine from scratch is a pretty complex task, especially one that's capable of competing with something like Google.
Think about this: to be effective, a search engine needs to download, basically, the entire Internet. This implies a need for an enormous amount of bandwidth, which translates to lots and lots of money. Where will a little open-source search engine get all this money for all this bandwidth? That's an issue that needs to be addressed before anything like Nutch can work.
Another issue that has to be resolved before an open-source search engine can take off: the development model just doesn't sync up with the way search engines work. You have to keep a big central database somewhere of all the pages the robot has indexed. J. Random Hacker can't just download the source code, hack at it, build it, and try it out at home without access to this database. (Okay, technically he could, but it wouldn't be able to do anything useful.)
you'd curse the day you were performing a critical system update and some jackass decided to form-bomb your system for the fun of it.
And who would that be -- me?
If you're doing critical system updates with other untrusted people logged in, perhaps you have larger problems than fork bombs.
FWIW, I have tried to break my system with for(;;)fork();. It didn't work; I could still log in through another tty and kill -9 -1 (though it took a couple seconds as the kernel sorted everything out and got a shell running). It seems like the 2.6 kernel has improved the process management quite a bit, as a few years ago the same fork-bomb brought my system down to the point where there was a noticeable delay between, say, hitting numlock and the LED on the keyboard changing. I don't know; I'm not a kernel hacker.
I don't have such limits set for myself simply because I don't see any reason to do so. In the worst case, I might have to reboot, and when that happens, then I'll bother setting a process limit.
Whining? Excuse me? I was stating a mere fact that a hundred-process limit simply is not enough for all cases.
Since I'm generally the only person using my computer, ps aux|grep $USER|wc -l is still in the range of about 80-90, and can still easily top 100 if I also start up a couple different web browsers (e.g. Konqueror and MSIE in QEMU) to test a page for cross-browser compatibility.
My point is that there is no single limit that can work in all cases. It's an administrative decision that should be based on what the system is going to be used for (multi-user shell account? single user GUI? program development?) and not some arbitrary number that someone picked because it "works for them". It simply won't work for everyone. If you set it to 256, you'll find someone who wants to run 257 processes; if you set it to 512, you'll (eventually) find someone who wants to run 513.
Ow! My irony gland just exploded.
Strange...
The first result for w3c css table-cell is w3schools, whereas it's not even above the fold in the results for css table-cell.
Maybe we want/need a Linux type competitor to Google where quality is the driver? If only....
What, like Nutch?
As I said here, it might act like Debian, but Debian it's not.
.deb package on Ubuntu without possibly causing binary version problems? Similarly, can I build a package on Ubuntu, give it to a Debian user, and be sure that it'll work properly on their system?
A notable problem with using "spinoff" distributions is package compatibility. Can I install any
This is a problem with rpm-based distributions; I don't know if apt handles it in a smarter way than rpm, but I've been burned by it and I'm hesitant to try and see. While on the surface everything may seem to function properly, you never know when doing something seemingly innocent like installing or upgrading a package can open up a huge can of worms. I know; I tried installing some packages from my Mandrake 8.2 CDs on a Red Hat system. The first couple worked without any problems, but I tried installing another package that happened to mess with some other file that was already on the system, and it broke several other seemingly unrelated programs.
This is one of the reasons I'm not using Debian now. It might be stable, have a brilliant program that handles all the installation stuff automagically, and have a great community, but the big problem with it that turned me away is exactly that mindset. The last time I had the inclination to try out something different, I was looking for a non-commercial distro that had recent versions of Gnome and KDE and decent non-annoying package support. Debian had two out of three, but if I got it, it would have been mostly a downgrade for me.
Another really important advantage of releasing more often is that releases attract attention. A new version of something is often enough to get people to try it out, and it could turn out to be very good for Debian. Plus, that's the general mentality anyway -- "release early and often" -- of open-source, and Debian is perhaps the most adherent of the well-known Linux distros to the whole open-source philosophy.
If Debian starts releasing a new version every couple months, I'll be sure to give it a try, and I would imagine many other people feel the same way.
That's not Debian, that's just Debian-like.
Well, for one, that's not the gmail signup page.
Ubuntu uses apt too, doesn't it?