The organization name is not important to HTTPS because it never gets compared against anything. If Verisign issued another cert with a CN of citibank.com to another company, then yeah, the system has broken down. If you get a self-issued cert, how do you know it's the right cert? Do they mail it to you pgp-encrypted? Read the fingerprint over the phone?
You're missing the point. I'll say it again: if my location bar says citibank.com and the cert is valid, I'm connecting to citibank.com.
What you're describing would involve a third party obtaining a cert with a CN of citibank.com. For all their faults, Verisign would not issue a cert with the same CN to two different organizations.
Now, if Verisign issued a cert to some scammer with a company with the same organization name "CitiBank" with the CN citi-bank.com and citlbank.com, or whatever, that's a different problem entirely. That's why you need to look at both the domain name and the validity of the cert. The KB article you linked to talked about a cert for "Microsoft Corporation". Maybe that breaks their shitty code signing because they're relying on the user to read the organization name, but it would not break HTTPS.
I seem to remember a green or blue bar when an https connection worked, and red when there were errors validating the certificate. Later versions made this less obvious, with the key in the status bar.
I don't think you understand the assurance a certificate gives you. You don't need to be worried about being tricked or DNS being compromised because that's exactly what a cert protects you against. Look for the following two things: A. Is the domain name on the address bar the one you want? (example: citibank.com) B. Did the page come up without any errors from the web browser?
If your DNS server was compromised, B will not be true. If you're taken to some site that may or may not have been issued a valid cert by Verisign, but is definitely NOT citibank.com, A will not be true.
If A and B are true, you have successfully connected to citibank.com over an encrypted channel, end of story. Whether you want to trust the company on the other end is totally up to you, but now you know for sure who you're dealing with.
Actually it seems it's going further away from what microcomputers were in the 80s. An integrated PCI controller is one step closer to a single-chip computer (imagine a board with PCI slots, DIMM slots, headers for things like power, ports on the back, and single chip in the centre).
In 80s home computers, you'd see dozens of chips on the board, but today, we see motherboards from companies like SiS with an all-in-one northbridge, video adapter, audio, modem, ethernet controller, etc., and CPUs with an integrated cache and floating-point processor.
If indeed you do jobs for companies in lots of states, then yes, they're saying that you should be paying taxes in a lot of states. But if you're in Washington and your employer is in Oregon and you ssh to servers in California and Nevada, no, you don't pay state income taxes in California or Nevada.
Almost everybody here in Wisconsin watches the local news and reads the local papers. They find out about stuff that's consequential to them (ie, parades, weather, local government) but don't really want to concern themselves with the REAL world. For the most part people prefer ignorance.
Think about that for a minute - the "REAL world" you're talking about is outside the scope of local news, government (at all levels - people want to hear about their state and federal govt too) and weather, and so it probably has no effect at all on your life.
It's heartbeaking to hear about an earthquake or a hurricane across the country or across the world, but it's not like you can do anything about it, or know anyone involved, so to most people it's just about as useful as entertainment news or sports. These people aren't stupid. They're just not news information junkies.
I was reading just today about laws in Iran. Sure, that's great knowledge to have, but I might just as well have been knitting a sweater or collecting stamps, for all the effect it has on my life.
Not knowing the usual way of doing things in PHP, I might be talking out of my ass here, but shouldn't that mail() function be doing the filtering/escaping? If I give it an email address with a newline in it, I want to send an email to an address with a newline in it (regardless if that's a valid RFC822 address), and not even be able to put something on the next line of the email headers. It should be sufficiently abstracted that I don't need to know enough about email headers to know what I need to filter out of an address.
Also, strange nobody mentioned that he's not checking the return value of mail(), unless there's exception handling in PHP and he's letting the error fall through to a default exception handler.
All they need to do is convince ISC and Microsoft to change the zone file they ship with their DNS server software. Every time a new DNS server is set up or upgraded, it will point at the new root servers.
I meant to say that consumer level hard drives are not a significant source of noise. The average cheap 200 GB SATA drives you would find in a computer store will probably be a fluid dynamic bearing or similar silent drive. The expensive 70GB Ultra320 15K RPM drives intended for the RAID array in the server room are still as noisy as ever.
Now that the motors on (consumer level) hard drives are nearly silent, the loudest source of noise from your computer is probably the processor fan, followed by any small peripheral fans such as those found on video cards and motherboard chipsets. The power supply fan is probably the quietest moving part in your PC.
Power supplies also make the least distracting sound (IMO) because the large, slow fans produce more of a whoosh than a whine. Try powering on your computer with your processor out and no drives plugged in to see what I mean.
As far as 90% of software development jobs go, learning CS at a University doesn't make you "well-rounded". It makes you a trade-school programmer with a bigger ego, and a better background on your resume. After 5 years, there will be no difference between you and the trade-school programmer, unless one of you is exceptionally bright or exceptionally stupid.
The only rows that would get sent back from the server are the ones you want; the temporary table exists server-side.
Yes, you could use a cursor instead, but to avoid problems if the table gets updated while your cursor is open, you'd either have to lock the table or deal with errors from the server.
If you want rows 10-50, try this (assumes that tablename has an ID column):
DECLARE @temp TABLE (ID INT IDENTITY (1,1), tableID INT) INSERT @temp(tableID) SELECT TOP 50 ID FROM tablename SELECT tablename.* FROM @temp, tablename WHERE @temp.tableID = tablename.ID AND @temp.ID > 10
In Unix, fork()ing is very efficient. It's just as fast or faster than creating a thread in Windows. The reason is that both processes use the same set of pages in memory - until one writes to memory, and then one gets a copy.
And if using shared memory or a Unix socket aren't fast enough for your IPC, then sure, use threads. Unix has them too.
Unix was designed for a large number of processes to be executing simultaneously - each command you set up in a pipleine starts executing immediately. The Unix way is to have lots of small programs that do one thing really well. That sounds like an ideal situation for a multi processor architecture.
I know this has no bearing on what you're saying, but you're wrong about the 512 characters. 1 byte for every 4 encoded characters would mean 2 bits are represented by each encoded character. That's pretty inefficient. Even using just the characters 0-9A-F (4 bits) as your encoding would result in an encoded length of 256.
128 bytes can be represented in base64 with 175 characters: $ dd if=/dev/random count=128 bs=1 | openssl base64 | wc -m 175
And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.
That's extremely unlikely, even with weak checksums. What you need to worry about is whether a server that will give you a fake binary will also give you a matching fake checksum.
Just post those hashes on trusted servers, and any file that matches both (or more) hashes must be your package.
By trusted you must mean SSL secured, like an https server. But then you have to store the private key somewhere (on the webserver, obviously, but someone needs to be responsible for it), and someone would have to contact a CA to get the keypair in the first place.
Not only that, but why wouldn't he notice that the computer he connected to had the same number of drives as him, and that the contents were familiar? Wouldn't he notice the disk activity?
Slashdot Mirror
The organization name is not important to HTTPS because it never gets compared against anything. If Verisign issued another cert with a CN of citibank.com to another company, then yeah, the system has broken down.
If you get a self-issued cert, how do you know it's the right cert? Do they mail it to you pgp-encrypted? Read the fingerprint over the phone?
You're missing the point. I'll say it again: if my location bar says citibank.com and the cert is valid, I'm connecting to citibank.com.
What you're describing would involve a third party obtaining a cert with a CN of citibank.com. For all their faults, Verisign would not issue a cert with the same CN to two different organizations.
Now, if Verisign issued a cert to some scammer with a company with the same organization name "CitiBank" with the CN citi-bank.com and citlbank.com, or whatever, that's a different problem entirely. That's why you need to look at both the domain name and the validity of the cert. The KB article you linked to talked about a cert for "Microsoft Corporation". Maybe that breaks their shitty code signing because they're relying on the user to read the organization name, but it would not break HTTPS.
I seem to remember a green or blue bar when an https connection worked, and red when there were errors validating the certificate.
Later versions made this less obvious, with the key in the status bar.
I don't think you understand the assurance a certificate gives you. You don't need to be worried about being tricked or DNS being compromised because that's exactly what a cert protects you against. Look for the following two things:
A. Is the domain name on the address bar the one you want? (example: citibank.com)
B. Did the page come up without any errors from the web browser?
If your DNS server was compromised, B will not be true. If you're taken to some site that may or may not have been issued a valid cert by Verisign, but is definitely NOT citibank.com, A will not be true.
If A and B are true, you have successfully connected to citibank.com over an encrypted channel, end of story. Whether you want to trust the company on the other end is totally up to you, but now you know for sure who you're dealing with.
javascript:location.href=location.protocol+'//'+lo cation.host+'.nyud.net:8090'+location.pathname+loc ation.search+location.hash
javascript:location.href=location.protocol+'//'+lo cation.host+'.nyud.net:8090'+location.pathname
Works in Firefox.
Actually it seems it's going further away from what microcomputers were in the 80s. An integrated PCI controller is one step closer to a single-chip computer (imagine a board with PCI slots, DIMM slots, headers for things like power, ports on the back, and single chip in the centre).
In 80s home computers, you'd see dozens of chips on the board, but today, we see motherboards from companies like SiS with an all-in-one northbridge, video adapter, audio, modem, ethernet controller, etc., and CPUs with an integrated cache and floating-point processor.
If indeed you do jobs for companies in lots of states, then yes, they're saying that you should be paying taxes in a lot of states. But if you're in Washington and your employer is in Oregon and you ssh to servers in California and Nevada, no, you don't pay state income taxes in California or Nevada.
Almost everybody here in Wisconsin watches the local news and reads the local papers. They find out about stuff that's consequential to them (ie, parades, weather, local government) but don't really want to concern themselves with the REAL world. For the most part people prefer ignorance.
Think about that for a minute - the "REAL world" you're talking about is outside the scope of local news, government (at all levels - people want to hear about their state and federal govt too) and weather, and so it probably has no effect at all on your life.
It's heartbeaking to hear about an earthquake or a hurricane across the country or across the world, but it's not like you can do anything about it, or know anyone involved, so to most people it's just about as useful as entertainment news or sports. These people aren't stupid. They're just not news information junkies.
I was reading just today about laws in Iran. Sure, that's great knowledge to have, but I might just as well have been knitting a sweater or collecting stamps, for all the effect it has on my life.
Not knowing the usual way of doing things in PHP, I might be talking out of my ass here, but shouldn't that mail() function be doing the filtering/escaping? If I give it an email address with a newline in it, I want to send an email to an address with a newline in it (regardless if that's a valid RFC822 address), and not even be able to put something on the next line of the email headers. It should be sufficiently abstracted that I don't need to know enough about email headers to know what I need to filter out of an address.
Also, strange nobody mentioned that he's not checking the return value of mail(), unless there's exception handling in PHP and he's letting the error fall through to a default exception handler.
All they need to do is convince ISC and Microsoft to change the zone file they ship with their DNS server software. Every time a new DNS server is set up or upgraded, it will point at the new root servers.
I meant to say that consumer level hard drives are not a significant source of noise. The average cheap 200 GB SATA drives you would find in a computer store will probably be a fluid dynamic bearing or similar silent drive. The expensive 70GB Ultra320 15K RPM drives intended for the RAID array in the server room are still as noisy as ever.
Now that the motors on (consumer level) hard drives are nearly silent, the loudest source of noise from your computer is probably the processor fan, followed by any small peripheral fans such as those found on video cards and motherboard chipsets. The power supply fan is probably the quietest moving part in your PC.
Power supplies also make the least distracting sound (IMO) because the large, slow fans produce more of a whoosh than a whine. Try powering on your computer with your processor out and no drives plugged in to see what I mean.
I guess Google must have been down if there was no way, other than bitching about it here, for you to know what an OQO was.
Or they could just ask for your credit card again...
As far as 90% of software development jobs go, learning CS at a University doesn't make you "well-rounded". It makes you a trade-school programmer with a bigger ego, and a better background on your resume. After 5 years, there will be no difference between you and the trade-school programmer, unless one of you is exceptionally bright or exceptionally stupid.
The only rows that would get sent back from the server are the ones you want; the temporary table exists server-side.
Yes, you could use a cursor instead, but to avoid problems if the table gets updated while your cursor is open, you'd either have to lock the table or deal with errors from the server.
If you want rows 10-50, try this (assumes that tablename has an ID column):
DECLARE @temp TABLE (ID INT IDENTITY (1,1), tableID INT)
INSERT @temp(tableID) SELECT TOP 50 ID FROM tablename
SELECT tablename.*
FROM @temp, tablename
WHERE @temp.tableID = tablename.ID
AND @temp.ID > 10
Nice troll. Ever hear of copy-on-write?
In Unix, fork()ing is very efficient. It's just as fast or faster than creating a thread in Windows. The reason is that both processes use the same set of pages in memory - until one writes to memory, and then one gets a copy.
And if using shared memory or a Unix socket aren't fast enough for your IPC, then sure, use threads. Unix has them too.
Unix was designed for a large number of processes to be executing simultaneously - each command you set up in a pipleine starts executing immediately. The Unix way is to have lots of small programs that do one thing really well. That sounds like an ideal situation for a multi processor architecture.
Buncha Wieners.
More information about "Evil twin": http://www.techworld.com/mobility/features/index.c fm?featureid=1147. Yes, basically it's a man-in-the-middle attack.
You're right that "Wireless fidelity" is cringe-inducing.
What's wrong with "AES encryption standard"? AES (Rijndael) is one of the ciphers you can use with WPA.
I know this has no bearing on what you're saying, but you're wrong about the 512 characters. 1 byte for every 4 encoded characters would mean 2 bits are represented by each encoded character. That's pretty inefficient. Even using just the characters 0-9A-F (4 bits) as your encoding would result in an encoded length of 256.
128 bytes can be represented in base64 with 175 characters:
$ dd if=/dev/random count=128 bs=1 | openssl base64 | wc -m
175
And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.
That's extremely unlikely, even with weak checksums. What you need to worry about is whether a server that will give you a fake binary will also give you a matching fake checksum.
Just post those hashes on trusted servers, and any file that matches both (or more) hashes must be your package.
By trusted you must mean SSL secured, like an https server. But then you have to store the private key somewhere (on the webserver, obviously, but someone needs to be responsible for it), and someone would have to contact a CA to get the keypair in the first place.
Not only that, but why wouldn't he notice that the computer he connected to had the same number of drives as him, and that the contents were familiar? Wouldn't he notice the disk activity?
I agree this is just some dumb joke.
No man can eat 50 eggs.