What is the fundamental reason select/poll should be that much faster anyway? Well, you win the context switch-times, if you can handle many clients in a tick. But on the other hand it does affect the way you need to design the code, and doing some stuff that neveer stalls withouot threads might be tricky.
Just imagine a situation where a thread might need to calculate something, or initialize a big array. Now, if it's run under a select-loop, you need to do that in parts to avoid starving the server. With threads, you just do the trick and don't care about the rest of the world which keeps serving the clinets, no matter how long youo stay in the functino.
But you could detect one of the two beams while you pass it (or its reflection). I imagine such detectors could be placed to public parks or other such places, if deemed necessary..
I was thinking of this problem too, but I see that your solution is perfect.
What prevents RIAA from lying the hashcode? You can only verify it after downloading.
I was thinking of a solution, where it would be possible to request hashes of parts of the file. The operation would be like this: you see a file, you start downloading it, but every now and then you request a partial hash from another server that also stores the file and claims their file's hash is the same. Preferably from different servers. Of course, this scheme breaks down too if RIAA has lots and lots of servers around.. (I guess technically it'd be possible for one server to be like, thousand servers.)
Just block queries that have offending (non-nrp) references-field. Simple as that. I've seen sites that do it. No need to go through all that legal mumble jumble.
Let's say I'll use XOR as the encryption algorithm with one time pad. I shall choose a random secret key, and encrypt a message with it. Here is the secret message encrypted:
AAAAAAAAAAAAAAAA
Now, if you don't know my key, how on earth are you going to decrypt this out of it:
Hello world!PADP
You might figure out with the mighty forumlas or propability that it -might- contain that message, but OTOH, it might contain any other message just as propably. The minimum length of the message is the only thing the encrypted text is revealing.
My secret key happened to be 9:36:45:45:46:97:54:46:51:45:37:96:17:0:5:17. Had it been an actually randomly selected series of bytes _without_ correlation to the plaintext, the situation would still be the same: the encrypted data does not tell anything about the original data, without the key.
..and I'm not talking about free software. If the programs were actually developed with the scrutiny required to develope secure software, it'd take a lot longer to actually produce anything, hence increasing the costs. (And it still wouldn't guarantee there'd be no bugs.) There's always the license: I would refuse to give or sell software to someone who'll sue my ass off in case of problems. If that's not OK for the client, he can go off and get the software from another source. I'm not sure how this maps to free software though. Basically the way to secure software is peer review, and not just the releases but also the changes. I imagine the kernel diffs are being looked by other than just Linus 'n co, but how about other important software? Or even less important: it only takes one hole in the right place to attack. A remotely exploitable bug in mutt, pine, sendmail, procmail, slrn, apache or ssh would be quite bad - are they all being peer reviewed systematically, every change by atleast two persons? I don't think so. For the security problems in the past and in the future.. Live with it. I see the only way to fix these is to have a more secure environment, that is, the kernel should be able to limit the capabilities of the programs in higher precision. The other approach would be to use languages that have better built-in checks, but there's lots of old code around and there might be other reasons why for example Java or Python isn't suitable for a project. Also not all security bugs are stack/heap-overflows, but many if not most are.
Step 1: Client retrieves a random byte sequence from Battle.net Step 2: Client encrypts the key with his private key Step 3: Server has every client's public key (the client's don't), thus it can check whether the message can be decrypted properly Step 4: If so, the client is validated.
I don't see how this is any better than just sending any user-written key via an encrypted channel (like https) to the server though. The server identification key would be in the client, so you cannot fake the server.
..as if it's patented, I don't it would be thought to be fair to have a law forcing your OS to comply with the system (and pay royalties for doing it):-).
But what happens, when you want to create a 'smart' interface? Say I want a class Nameable, that can carry a name. But as it is a pain in the ass to recreate the trivial naming code in every class that wants to have a name, you decide: "Hm, wouldn't it be handy, if the constructor could take the name as an argument, and the getName-method just serves that?"
Well, guess what (which I guess you already knew but just somehow avoided to mention): you can't do that. Interface cannot have code. Of course, you can inherit from the interface the common implementation, but then you can't MI anymore.
You can see this 'feature' in action in some Java runtime library classes too.
There is one (but only one IMO) nice feat in Java interfaces: they provide better documentation for the reader. You read the file, and see 'ha, interface!', but with C++ you just have a class that might not even have abstract methods. This you must then combat with commenting.
Commenting in itself is not bad, of course, and is encouragable, but I see programming languages not only as a way to tell the computer what you want to do, but also tell other programmers. Commenting is not as good as (clean) code, as the comments and the code tends to go out of sync some time. Of course, if you only have an interface, how good it ever might be, there'd better be some comments:). Not much code there..
But what I'm wondering, who is forcing you to use GNU-utilities. And moreover, what -is- the real problem with them. Pick two unix-utilities, a GNU-one and a 'traditional' one, and most probably the GNU-one is the working one and with the most features.
One argument I've been hearing is that GNU-software is 'bloated'. Well, that might be true. I don't care, though. They still aren't that large, they are infact quite efficient in what they do.
And auto* is a bit horrible, but I don't see a better alternative lurking around.
But that stuff about 'info' is right on:-). Or actually the fact that the GNU-people are abandoning manual-pages or just converting the info-pages to manual-pages, creating really unuseful manual-pages. Fortunately Debian-people are building the pages back to the packages:-).
I can't understand how an OS, other than Linux (or other free OS) could just sneak in. OSes cost money, someone has to approve the investment. Surely workers don't pay for the software they need to use at the job themselves? And not paying would be piracy. So there.
And if the company has a policy that only IT certified (blahblah) software can be used in the network, well, if Linux isn't on the list then there's no problem removing it. Otherwise, who cares, it is propably doing its job just fine.
grep-dctrl non-free status | grep-dctrl -v not-installed | less | grep Package | sort | wc -l
says 58 to me. Well, I would mind a bit not having non-free. Of course, if they removed non-free now, I'd still have the software, it'd affect only newly installed machines..
Highlights: communicator, giflib3g, gimp1.1-nonfree (gif, tiff), gsfonts-other, jdk1.1, povray, quake-lib, ucbmpeg, xanim, xmame. Actually, I would only notice the loss of communicator, but I believe the other packages have their users too.
MySQL reliable? I don't think so!
on
Why Not MySQL?
·
· Score: 1
Just look at/. . You've seen it, you know what I mean. I mean, there cannot be any other explanation for the seemingly random moderations, except database corruption. Why else would a comment presenting misinformation or even lies be operated up, and a witful comment down (Camel rules)?
You've seen wrong. There are users (and groups) in Postgres, and you need to specifically grant access to the tables you create. However, I've not been able to limit the capability of creating new databases.. Kinda sucks, one can't give anonymous access to the table.
Now, as you've been answered, that isn't a problem. A real problem is that you cannot delete a column from a table.. Who designs the tables with the 'right' technique (plannin etc) anyway, it's more fun to do it in command line:).
Actually PostgreSQL 7.0 (of which atleast Release Candidate 2 is out) supports foreign keys.. Of course, earlier it was possible to emulate them with triggers, which you cannot do with mySQL.
Of course, no reason. That is, if you don't mind that your software crashes. I don't think this is here to make buffer overflows just 'go away' silently - they just get killed as they ought to - with a syslog-message to make it easier to catch it.
Also, for those who say that this is obsolete for opensource.. Well, how is it that there ARE many (compared to zero) buffer overflow-bugs?
I can see no reason why this piece of software shouldn't exist. In fact, I think it's great. I expect it to get into Woody some day..
Well duh! If you're going to need the schematics next week, why don't you Ask Slashdot today, to make sure the schematics get on time?
What is the fundamental reason select/poll should be that much faster anyway? Well, you win the context switch-times, if you can handle many clients in a tick. But on the other hand it does affect the way you need to design the code, and doing some stuff that neveer stalls withouot threads might be tricky.
Just imagine a situation where a thread might need to calculate something, or initialize a big array. Now, if it's run under a select-loop, you need to do that in parts to avoid starving the server. With threads, you just do the trick and don't care about the rest of the world which keeps serving the clinets, no matter how long youo stay in the functino.
Well, there is atleast one difference: it's done professionally. Which means for profit.
But you could detect one of the two beams while you pass it (or its reflection). I imagine such detectors could be placed to public parks or other such places, if deemed necessary..
And what does this actually prevent? Just make your own program that allows you to modify it! Sheesh..
I was thinking of this problem too, but I see that your solution is perfect.
What prevents RIAA from lying the hashcode? You can only verify it after downloading.
I was thinking of a solution, where it would be possible to request hashes of parts of the file. The operation would be like this: you see a file, you start downloading it, but every now and then you request a partial hash from another server that also stores the file and claims their file's hash is the same. Preferably from different servers. Of course, this scheme breaks down too if RIAA has lots and lots of servers around.. (I guess technically it'd be possible for one server to be like, thousand servers.)
Just block queries that have offending (non-nrp) references-field. Simple as that. I've seen sites that do it. No need to go through all that legal mumble jumble.
Let's say I'll use XOR as the encryption algorithm with one time pad. I shall choose a random secret key, and encrypt a message with it. Here is the secret message encrypted:
AAAAAAAAAAAAAAAA
Now, if you don't know my key, how on earth are you going to decrypt this out of it:
Hello world!PADP
You might figure out with the mighty forumlas or propability that it -might- contain that message, but OTOH, it might contain any other message just as propably. The minimum length of the message is the only thing the encrypted text is revealing.
My secret key happened to be 9:36:45:45:46:97:54:46:51:45:37:96:17:0:5:17. Had it been an actually randomly selected series of bytes _without_ correlation to the plaintext, the situation would still be the same: the encrypted data does not tell anything about the original data, without the key.
..and I'm not talking about free software. If the programs were actually developed with the scrutiny required to develope secure software, it'd take a lot longer to actually produce anything, hence increasing the costs. (And it still wouldn't guarantee there'd be no bugs.) There's always the license: I would refuse to give or sell software to someone who'll sue my ass off in case of problems. If that's not OK for the client, he can go off and get the software from another source.
I'm not sure how this maps to free software though. Basically the way to secure software is peer review, and not just the releases but also the changes. I imagine the kernel diffs are being looked by other than just Linus 'n co, but how about other important software? Or even less important: it only takes one hole in the right place to attack. A remotely exploitable bug in mutt, pine, sendmail, procmail, slrn, apache or ssh would be quite bad - are they all being peer reviewed systematically, every change by atleast two persons? I don't think so.
For the security problems in the past and in the future.. Live with it. I see the only way to fix these is to have a more secure environment, that is, the kernel should be able to limit the capabilities of the programs in higher precision. The other approach would be to use languages that have better built-in checks, but there's lots of old code around and there might be other reasons why for example Java or Python isn't suitable for a project. Also not all security bugs are stack/heap-overflows, but many if not most are.
Step 1: Client retrieves a random byte sequence from Battle.net
Step 2: Client encrypts the key with his private key
Step 3: Server has every client's public key (the client's don't), thus it can check whether the message can be decrypted properly
Step 4: If so, the client is validated.
I don't see how this is any better than just sending any user-written key via an encrypted channel (like https) to the server though. The server identification key would be in the client, so you cannot fake the server.
..as if it's patented, I don't it would be thought to be fair to have a law forcing your OS to comply with the system (and pay royalties for doing it) :-).
This might not have been what people have expected, though.. And it misses some other expected features too.
Yes, they are used for interfaces.
:). Not much code there..
But what happens, when you want to create a 'smart' interface? Say I want a class Nameable, that can carry a name. But as it is a pain in the ass to recreate the trivial naming code in every class that wants to have a name, you decide: "Hm, wouldn't it be handy, if the constructor could take the name as an argument, and the getName-method just serves that?"
Well, guess what (which I guess you already knew but just somehow avoided to mention): you can't do that. Interface cannot have code. Of course, you can inherit from the interface the common implementation, but then you can't MI anymore.
You can see this 'feature' in action in some Java runtime library classes too.
There is one (but only one IMO) nice feat in Java interfaces: they provide better documentation for the reader. You read the file, and see 'ha, interface!', but with C++ you just have a class that might not even have abstract methods. This you must then combat with commenting.
Commenting in itself is not bad, of course, and is encouragable, but I see programming languages not only as a way to tell the computer what you want to do, but also tell other programmers. Commenting is not as good as (clean) code, as the comments and the code tends to go out of sync some time. Of course, if you only have an interface, how good it ever might be, there'd better be some comments
OTOH, it makes perfect sense to have shutdown and reboot behind a 'foot' symbol.
2.4.0-kernel boots just fine in my laptop, from a ext2-filesystem. (I have the reiser-support in kernel, but switching is such a pita.)
Just use Vorbis :-).
This works just as far as it doesn't get too popular..
I've been hearing this stuff a bit lately.
:-). Or actually the fact that the GNU-people are abandoning manual-pages or just converting the info-pages to manual-pages, creating really unuseful manual-pages. Fortunately Debian-people are building the pages back to the packages :-).
But what I'm wondering, who is forcing you to use GNU-utilities. And moreover, what -is- the real problem with them. Pick two unix-utilities, a GNU-one and a 'traditional' one, and most probably the GNU-one is the working one and with the most features.
One argument I've been hearing is that GNU-software is 'bloated'. Well, that might be true. I don't care, though. They still aren't that large, they are infact quite efficient in what they do.
And auto* is a bit horrible, but I don't see a better alternative lurking around.
But that stuff about 'info' is right on
I can't understand how an OS, other than Linux (or other free OS) could just sneak in. OSes cost money, someone has to approve the investment. Surely workers don't pay for the software they need to use at the job themselves? And not paying would be piracy. So there.
And if the company has a policy that only IT certified (blahblah) software can be used in the network, well, if Linux isn't on the list then there's no problem removing it. Otherwise, who cares, it is propably doing its job just fine.
Don't know about your dvd-drive, but mine reads cdr's just fine. It's a Pioneer drive.
says 58 to me. Well, I would mind a bit not having non-free. Of course, if they removed non-free now, I'd still have the software, it'd affect only newly installed machines..
Highlights: communicator, giflib3g, gimp1.1-nonfree (gif, tiff), gsfonts-other, jdk1.1, povray, quake-lib, ucbmpeg, xanim, xmame. Actually, I would only notice the loss of communicator, but I believe the other packages have their users too.
Just look at /. . You've seen it, you know what I mean. I mean, there cannot be any other explanation for the seemingly random moderations, except database corruption. Why else would a comment presenting misinformation or even lies be operated up, and a witful comment down (Camel rules)?
You've seen wrong. There are users (and groups) in Postgres, and you need to specifically grant access to the tables you create. However, I've not been able to limit the capability of creating new databases.. Kinda sucks, one can't give anonymous access to the table.
Now, as you've been answered, that isn't a problem. A real problem is that you cannot delete a column from a table.. Who designs the tables with the 'right' technique (plannin etc) anyway, it's more fun to do it in command line :).
Actually PostgreSQL 7.0 (of which atleast Release Candidate 2 is out) supports foreign keys.. Of course, earlier it was possible to emulate them with triggers, which you cannot do with mySQL.
Of course, no reason. That is, if you don't mind that your software crashes. I don't think this is here to make buffer overflows just 'go away' silently - they just get killed as they ought to - with a syslog-message to make it easier to catch it. Also, for those who say that this is obsolete for opensource.. Well, how is it that there ARE many (compared to zero) buffer overflow-bugs? I can see no reason why this piece of software shouldn't exist. In fact, I think it's great. I expect it to get into Woody some day..