Someday when we all have extraordinarily fast computers, we'll simply be able to send somebody an MD5 sum and the computers will be able to "crack" it back into the original file.
Not familliar with hashes? You can't do it quite like that because an MD5 hash is the same for any number of datasets. Trying to un-do a hash is pretty idiotic at that level.
However, think about this scenario: Send the MD5, byte count and CRC64. Now rattle through all the possible combinations of "byte count" of data that generate the same MD5 and CRC64 and values as were sent. It's still not foolproof but you've reduced the dataset considerably. Of course, now you compare your new file to the GPG sig sent to ensure you got it right.
Perhaps as we approach quantum computing it will become more realistic to brute-force a many-hundred-megabyte file from a number of its hashes.
Maybe they have a better compression scheme? (Fractal based?) That would be news. Everything else is a distraction.
I remember back in the good old BBS days of a program called OWS which did "fractal compression"... In reality, it deleted the file and stored the sector information of the deleted blocks in the "compressed file" -- if you moved the.ows file off the disk, you'd get "decompression" errors.:-)
Meltzer recalled a job where the client had a 32-Mbit/second connection available but was getting a throughput of 0.5 Mbits/s. "It wasn't a question of mere bandwidth. They had too much turnaround," he said.
Um... if you're getting 500kbps on a 32Mbps connection your protocol stinks. 1/64th of your available bandwidth isn't FTP's fault, nor is it TCP's. Either there was a severe bottleneck somewhere between the endpoints, or the protocol was designed to minimize throughput.
More shit:
"FedEx is a hell of a lot more reliable than FTP when you're running 20 Mbytes," said Charlie Oppenheimer, vice president of marketing at Digital Fountain.
They may have better bandwidth but the latency sucks. Furthermore, I've never had FTP destroy my packets. It either made it or it didn't, and it makes it 100% of the time, barring connection failure.
Sorry. I don't buy it. Yeah sending over UDP gives you less hassle than TCP but now you have to take into account all the sequencing and data transfer checks. Not terribly difficult but no rocket science, either.
If you allow hackers to attack your network with nmap you've already lost the battle.
And out of curiousity, oh great net guru, how do you go about preventing/spoofing nmap attacks without bogging down your edge routers? Turning off spoofed packets is easy. Not responding to ICMP broadcasts is easy. Setting up ACLs for services is easy. What do you propose, rewriting the TCP/IP stacks or installing funky-do routers which mangle off-colour packets? How much time and energy do you have for this, and what exactly is the gain?
nmap just tells you the OS and what services you run; the information lets you tailor your attacks and scans but little else so long as you're up on your network security.
Doesn't work so well on a file that is accessed 24/7 (database files for example).
Very true. Fortunately all acid-compliant RDBMS will let you "take a pull" off the database to tape. Ferinstance in Postgres I can do a pg_dumpall | bzip2 -1 > backup.bz2 or >/dev/tape. All the data is guaranteed to be in a useful state.
The reason you want to run two coax drops is that if you get a dual-tuner sattelite decoder (like a DirectTV TiVo) you will need to lines going out to your dish or to your multiswitch (which splits the signal between >2 lines, so you can put receivers in multiple rooms).
Umm.. why not only run two pair from the dish (dual LNBF) to the control box?
From what I understand of Digital Satellite, you have the even transponders on one frequency and the odd ones on another. Your receiver selects the frequency by sending a DC voltage to the LNBF, since they are essentially just Gunn diodes. If you want two receivers to watch two channels which are potentially on different transponders, you need two LNBFs, or a single dual so each can select the frequency.
Now I've seen satellite control boxes which block the DC from all the receivers and "permanently" tune one LNBF to the odd transponders and the other LNBF to the even ones. Then it electronically connects the RF coming from the appropriate Gunnplexer to the receiver based on the voltage the reciever is sending. Large hotels and apartment buildings do this, IIRC.
What I'd love to do if I could keep the signal quality is to have a receiver which decodes all the channels I'm entitled to simultaneously and then remodulate them on to regular CATV frequencies so I could watch satellite TV from any TV in my house without another $#%!^*ing receiver and card to deal with.
Actually I think the ideal solution would be a cPCI backplane system which, at its core, was a satellite receiver/decoder/hard drive and any number of plug-in DSP/playback/remodulator/control units. The idea would be to plug your dual LNBF-dish into the thing and it would take care of your SINGLE card. The main unit has a large RAID array which takes the MPEG2 streams and directly saves them to HDD as requested by the control cards.
Now, for each TV, you plug in a control/decode card which takes the commands from your remote for channel change/record/menu/etc.. Now you can watch any channel, record it (pause live tv), watch pre-recorded shows, etc.
The backplane is only responsible for the connections and the system housekeeping. The control cards have the MPEG2 decoder and act as the cross-connect between the raw MPEG2 stream and the HDD (not physically, but logically) -- If you have an HDTV TV, you buy the HDTV control card with optical 5.1 audio and component video. cheap-ass 13" you bought for $5? Then you buy the cheap-ass RF modulator version of the control card.
And of course, you can run other inputs and select/control them from any TV. DVD/Laserdisc, VCRs, broadcast TV, door-Cam...
Damn... now where do I go to build this? I've got the engineering background, just not the connections into the DTV/satellite market. The last time I asked for specs on a satellite decoder chip I was told to go fuck myself in BusinessSpeak. Damn... I wonder if a Slashdot posting would count as Prior Art if someone tries to patent this and lock me out...
The IDE/ATAPI specification does not define a command to determine if a write cache is present or to explicitly flush the cache.
Perhaps not a direct command to flush the cache, no, but I do know that there is a drive reset command which would probably do the trick. I also know there is a way to disable the drive cache altogether which would likely flush any data in the cache before it was disabled. So there are two possibilities: send a drive reset before power down or toggle the drive cache enable before power down.
At any rate, I consider it a MS bug if I don't see the problem under any other OSes, which is exactly the case.
I can tell you the solution to my problem: flashing my VIA's BIOS to a more recent rev.
Hmmm... Mind telling me which VIA BIOS I should use on my Intel motherboard?!
Microsoft never released a fix for it because they never had a bug of their own to begin with;
Not a Microsoft problem? They never had a bug? So what is this KB article about? No this isn't for 2k but the problem exists with 2k as well and there's a patch from Microsoft was used that didn't work. Naturally I can't find the link on the KB but don't worry, that's just my revisionist history-writing in action.
Try 2000 and you won't have to worry about all those problems.
No, you'll just have problems with Win2k not flushing the write cache on IDE drives before powering off. The "bugfix" from Microsoft didn't fix it.
What did it cause us? Registry problems, incidentally. Win2k refuses to boot because the registry is corrupt. Not even safe mode. And having an ERD or using the backup registry doesn't help; every time you log in the registry changes and trying to roll it back to a recent (2 days ago) backup confuses the shit out of AutoDesk Inventor since they're paranoid about pirated software. Using an old registry also confuses Office 2000. So I ask again, what use is this proprietary, very undocumented, unreadable and practically unfixable single point of failure? Hell due to its very nature backups don't even work!
Give me separate ini files or give me a human-readable, fully documented registry. Ideally, give me all of that and a bugfix that actually works!
Win2k is a lot better than anything that came before. It is not, however, infallable. These problems are experienced on high-end (dual proc, 1G RAM) CAD workstations with mid-end (AutoDesk, Inc.) software. Who do you blame now? Microsoft, for creating a horrendous single point of failure, Microsoft, for not actually testing their bugfix, or AutoDesk for following Microsoft's reccomended programming practises and using the registry for everything and anything?
At least with my Grand Cherokee you could disable the alarm system by grounding a wire. Sure the alarm isn't enabled anymore, but the car will start and you still need a key in the ignition to drive it off.
Leaving a key in the car is a very very dumb idea. I wonder if your insurance company will cover theft in this case.
Regardless of whether the equipment actually wears out, Accounting principles dictate that it must be assigned a life span and depreciated. This book value of initial cost - depreciation is for accounting purposes the value of the equipment and the depreciation has to going into the loss. Resale value is irrelevant unless you're actually selling it.
I didn't say not to depreciate it. I said that when it's book value hits zero, it doesn't mean you have to buy new equipment. I didn't say anything about resale.
They never thought there would be so many slashdotters rubbing their minimum wage idiots' noses into the existence of their NetBSD on Mac IIcx Firewalls.
...None of which would have had any trouble had the network been set up correctly. The only time the free OS crowd gets into trouble with the "norms" is when they have to try and interface with the goddamned proprietary undocumented-for-your-protection bullshit protocols or procedures. Design your network with CLEAN implementations of TCP/IP and CLEAN POP3, IMAP, SMTP, HTTP, DNS, etc. etc. etc. services and you'll never ever hear from us! I guarantee it!
As soon as you try to muck things up in order to try and gain some edge over your users instead of using the procedures and protocols as defined you a) tip us off that something is up and b) get us curious enough to "fix" it, publishing the results and showing you off as the moron you are.
The rest of the money is probably spent on their internal data lines connecting POPs, devaluation of hardware, facilities costs, insurance, support/administrative/billing/sales staff wages and benefits, etc. It could add up to quite a bit.
Devaluation of equipment? Are you serious?
I do the network admin / deployment at a small (1600 user) ISP. We run around like crazy looking for "ancient" AS5200s because they just plain work. We get 47 lines out of each one (bastards made us use PRIs instead of DEAs so now we "retaliated" by asking for NFAS) and once configured, they just work.
I can't imagine cable being much different: You have your super-expensive head-end for each trunk, and once it is configured, you leave it be. Keep some parts around or, if you've got the cash, a hot spare and your equipment doesn't change. It doesn't devaluate in the sense that it wears out. Your bandwidth costs will be through the roof, yes, but that's what the economy of volume does for you. You have a 30MBit pipe for each trunk, a killer web cache and maybe 155MBit upstream. (I'm guessing here: Bell Canada's HSE (DSL) internet bandwidth overcommit rates being > 100:1, cable's can't be that far off)
The point is that yes the equipment is expensive and the bandwidth is expensive. But the equipment doesn't wear out. I'm sure you can get some pretty sweet deals on bandwidth when you tell your provider that you want enough feeds to service a nation. It had to have been mismanaged. This kind of story isn't new; this particular one just happens to have hit a hell of a lot of people at once.
Most people should wait a day or so to grab the latest kernel. As I'm finding (most of the US mirrors at least), 2.4.16 hasn't been mirrored to many of the mirrors yet:-)
I dunno; the Canadian mirror had 2.4.16 at 10AM (EST)
Actually they tried to preserve some rights in this draft left out any language dealing with racial hatred because they felt it would violate the first amendment.
Oh, what a relief.
I can say what I want about other races, but if I prove a security protocol fundamentally flawed, I'm incarcerated. So long as I can racially slur.
Please get a book on data structures and look up 'normalization'. You sound like an idiot.
If you would have read any of my other comments in this thread you would know by know that it is you who sounds like an idiot. My quoting the word "normalization" and then using "normal" in a different meaning in the next sentence only proves how easy it is to sidetrack anonymous cowards.
In the case of HDCP, the protocol must remain public, so there is no chance for security through obscurity. They must solely rely on the strength of the protocol to cracking, whereas DirectTV has the strong advantage that no one outside the company secrets knows how the cryptography works.
So, other than the bruising of egos and the computation expense, what is wrong with using RSA/DSA key cryptography instead of some cockamamie homebrew stuff? Those protocols are open (RSA's patent has expired IIRC) and seem to be holding up to cryptanalysis...
Why do people continue to think they can build a secure system designed to simultaneous distribute data publicly and prevent its distribution?
Maybe I'm missing something, but doesn't the DSS television broadcasting system do this already? I mean yes it's crackable now but I believe that by sacrificing some of the bandwidth for content and using it for security instead, it could be made a lot harder to crack than it is now.
Cloning is going to be next to impossible to fix, yes, but I wonder if you couldn't get around the "wait 6 months for your receiver's "stop" command to stop being sent" by throwing a lot of processing power at it and basically encrypting the stream to every (yes the entire subscribed population) system's public key. Perhaps cloning could be avoided by making the cards smarter and using techniques of self-destruction if the cards detect that they're being tampered.
I know I'm no cryptographer and it's late for me here, but the idea of having a secure system simultaneously distribute data publicly yet prevent distribution to unwanted systems doesn't seem impossible, just impractical at this point.
WRT your example - since there appears to be a one-one relationship of most of those items to "name", separate tables are unnecessary (unless you have to maintain histories). If you just need current address and current spouse, you include those in the employee table.
You're falling into the trap... Yes it's true that most times it is a one-to-one relationship. However to think that everyone in the world has just one address or one spouse is folly, and that is exactly what I was getting at: You must either keep damn near everything as a two-column table to allow for many-to-one and many-to-many mappings, or you must hardcode in limits. Neither is very palatable, but in a hierarchial database it's easy and fast, so long as you don't want to update the thing all the time. Directories are meant almost as a WORM technology (Write Once (in this case Occassionally), Read Many). And since namespace redesigns are painful in directories, you need to take a great deal of care when setting one up in order to meet the 99% of people's needs.
It's like I had stated in another response: There are places for both systems; I would even go as far as to say most times you want a relational database. But to completely rule out hierarchial databases isn't a wise thing to do.
But a bad driver will only send wrong signals, resluting in the modem not working. I don't see how this will cause any damage to the network?
v.90 is limited to 53k by the FCC/CRTC because the code patterns to hit 56k interefere too much on ajacent pairs in the trunk. k.56flex wasn't limited to this because the coding didn't have as high energy levels. Put the wrong signals out there and you can cause trouble for everyone on your trunk.
While the previous paragraph is true, I don't see how the software drivers are being certified at all; I can download the Wang-Fu driver from Taiwan and use it in North America without certifying it. I've been kind of wondering about this because our NASes are recording the odd incoming connection at 56k, even though it's not supposed to see anything higher than 53k due to the FCC/CRTC restrictions. I know the digital modem firmware is international though, so it must be non-certified analog modem drivers (or IOS bugs) doing it.
Yeah, just as unfair as the fact that you have to learn to read before you can read a book.
If I am interpreting the article correctly, he is demanding formal education in signal processing. I'm sorry, but that is unfair. I don't need a piece of paper to tell me I know what I'm doing. I design embedded industrial control systems for a living without that piece of paper, than you very much. If I'm interpreting the article correctly, this guy is demanding the pinkie ring engineer type. No thanks.
Slashdot Mirror
Someday when we all have extraordinarily fast computers, we'll simply be able to send somebody an MD5 sum and the computers will be able to "crack" it back into the original file.
Not familliar with hashes? You can't do it quite like that because an MD5 hash is the same for any number of datasets. Trying to un-do a hash is pretty idiotic at that level.
However, think about this scenario: Send the MD5, byte count and CRC64. Now rattle through all the possible combinations of "byte count" of data that generate the same MD5 and CRC64 and values as were sent. It's still not foolproof but you've reduced the dataset considerably. Of course, now you compare your new file to the GPG sig sent to ensure you got it right.
Perhaps as we approach quantum computing it will become more realistic to brute-force a many-hundred-megabyte file from a number of its hashes.
Maybe they have a better compression scheme? (Fractal based?) That would be news. Everything else is a distraction.
I remember back in the good old BBS days of a program called OWS which did "fractal compression"... In reality, it deleted the file and stored the sector information of the deleted blocks in the "compressed file" -- if you moved the .ows file off the disk, you'd get "decompression" errors. :-)
From the article:
Meltzer recalled a job where the client had a 32-Mbit/second connection available but was getting a throughput of 0.5 Mbits/s. "It wasn't a question of mere bandwidth. They had too much turnaround," he said.
Um... if you're getting 500kbps on a 32Mbps connection your protocol stinks. 1/64th of your available bandwidth isn't FTP's fault, nor is it TCP's. Either there was a severe bottleneck somewhere between the endpoints, or the protocol was designed to minimize throughput.
More shit:
"FedEx is a hell of a lot more reliable than FTP when you're running 20 Mbytes," said Charlie Oppenheimer, vice president of marketing at Digital Fountain.
They may have better bandwidth but the latency sucks. Furthermore, I've never had FTP destroy my packets. It either made it or it didn't, and it makes it 100% of the time, barring connection failure.
Sorry. I don't buy it. Yeah sending over UDP gives you less hassle than TCP but now you have to take into account all the sequencing and data transfer checks. Not terribly difficult but no rocket science, either.
If you allow hackers to attack your network with nmap you've already lost the battle.
And out of curiousity, oh great net guru, how do you go about preventing/spoofing nmap attacks without bogging down your edge routers? Turning off spoofed packets is easy. Not responding to ICMP broadcasts is easy. Setting up ACLs for services is easy. What do you propose, rewriting the TCP/IP stacks or installing funky-do routers which mangle off-colour packets? How much time and energy do you have for this, and what exactly is the gain?
nmap just tells you the OS and what services you run; the information lets you tailor your attacks and scans but little else so long as you're up on your network security.
Doesn't work so well on a file that is accessed 24/7 (database files for example).
Very true. Fortunately all acid-compliant RDBMS will let you "take a pull" off the database to tape. Ferinstance in Postgres I can do a pg_dumpall | bzip2 -1 > backup.bz2 or > /dev/tape. All the data is guaranteed to be in a useful state.
greasy underwear
Now that is a disgusting thought. I shuddered when the mental image of "greasy underwear" popped into my head... ewwwwwwwwwwwwwww
The reason you want to run two coax drops is that if you get a dual-tuner sattelite decoder (like a DirectTV TiVo) you will need to lines going out to your dish or to your multiswitch (which splits the signal between >2 lines, so you can put receivers in multiple rooms).
Umm.. why not only run two pair from the dish (dual LNBF) to the control box?
From what I understand of Digital Satellite, you have the even transponders on one frequency and the odd ones on another. Your receiver selects the frequency by sending a DC voltage to the LNBF, since they are essentially just Gunn diodes. If you want two receivers to watch two channels which are potentially on different transponders, you need two LNBFs, or a single dual so each can select the frequency.
Now I've seen satellite control boxes which block the DC from all the receivers and "permanently" tune one LNBF to the odd transponders and the other LNBF to the even ones. Then it electronically connects the RF coming from the appropriate Gunnplexer to the receiver based on the voltage the reciever is sending. Large hotels and apartment buildings do this, IIRC.
What I'd love to do if I could keep the signal quality is to have a receiver which decodes all the channels I'm entitled to simultaneously and then remodulate them on to regular CATV frequencies so I could watch satellite TV from any TV in my house without another $#%!^*ing receiver and card to deal with.
Actually I think the ideal solution would be a cPCI backplane system which, at its core, was a satellite receiver/decoder/hard drive and any number of plug-in DSP/playback/remodulator/control units. The idea would be to plug your dual LNBF-dish into the thing and it would take care of your SINGLE card. The main unit has a large RAID array which takes the MPEG2 streams and directly saves them to HDD as requested by the control cards.
Now, for each TV, you plug in a control/decode card which takes the commands from your remote for channel change/record/menu/etc.. Now you can watch any channel, record it (pause live tv), watch pre-recorded shows, etc.
The backplane is only responsible for the connections and the system housekeeping. The control cards have the MPEG2 decoder and act as the cross-connect between the raw MPEG2 stream and the HDD (not physically, but logically) -- If you have an HDTV TV, you buy the HDTV control card with optical 5.1 audio and component video. cheap-ass 13" you bought for $5? Then you buy the cheap-ass RF modulator version of the control card.
And of course, you can run other inputs and select/control them from any TV. DVD/Laserdisc, VCRs, broadcast TV, door-Cam...
Damn... now where do I go to build this? I've got the engineering background, just not the connections into the DTV/satellite market. The last time I asked for specs on a satellite decoder chip I was told to go fuck myself in BusinessSpeak. Damn... I wonder if a Slashdot posting would count as Prior Art if someone tries to patent this and lock me out...
The IDE/ATAPI specification does not define a command to determine if a write cache is present or to explicitly flush the cache.
Perhaps not a direct command to flush the cache, no, but I do know that there is a drive reset command which would probably do the trick. I also know there is a way to disable the drive cache altogether which would likely flush any data in the cache before it was disabled. So there are two possibilities: send a drive reset before power down or toggle the drive cache enable before power down.
At any rate, I consider it a MS bug if I don't see the problem under any other OSes, which is exactly the case.
I can tell you the solution to my problem: flashing my VIA's BIOS to a more recent rev.
Hmmm... Mind telling me which VIA BIOS I should use on my Intel motherboard?!
Microsoft never released a fix for it because they never had a bug of their own to begin with;
Not a Microsoft problem? They never had a bug? So what is this KB article about? No this isn't for 2k but the problem exists with 2k as well and there's a patch from Microsoft was used that didn't work. Naturally I can't find the link on the KB but don't worry, that's just my revisionist history-writing in action.
Try 2000 and you won't have to worry about all those problems.
No, you'll just have problems with Win2k not flushing the write cache on IDE drives before powering off. The "bugfix" from Microsoft didn't fix it.
What did it cause us? Registry problems, incidentally. Win2k refuses to boot because the registry is corrupt. Not even safe mode. And having an ERD or using the backup registry doesn't help; every time you log in the registry changes and trying to roll it back to a recent (2 days ago) backup confuses the shit out of AutoDesk Inventor since they're paranoid about pirated software. Using an old registry also confuses Office 2000. So I ask again, what use is this proprietary, very undocumented, unreadable and practically unfixable single point of failure? Hell due to its very nature backups don't even work!
Give me separate ini files or give me a human-readable, fully documented registry. Ideally, give me all of that and a bugfix that actually works!
Win2k is a lot better than anything that came before. It is not, however, infallable. These problems are experienced on high-end (dual proc, 1G RAM) CAD workstations with mid-end (AutoDesk, Inc.) software. Who do you blame now? Microsoft, for creating a horrendous single point of failure, Microsoft, for not actually testing their bugfix, or AutoDesk for following Microsoft's reccomended programming practises and using the registry for everything and anything?
What an assinine idea...
At least with my Grand Cherokee you could disable the alarm system by grounding a wire. Sure the alarm isn't enabled anymore, but the car will start and you still need a key in the ignition to drive it off.
Leaving a key in the car is a very very dumb idea. I wonder if your insurance company will cover theft in this case.
Regardless of whether the equipment actually wears out, Accounting principles dictate that it must be assigned a life span and depreciated. This book value of initial cost - depreciation is for accounting purposes the value of the equipment and the depreciation has to going into the loss. Resale value is irrelevant unless you're actually selling it.
I didn't say not to depreciate it. I said that when it's book value hits zero, it doesn't mean you have to buy new equipment. I didn't say anything about resale.
They never thought there would be so many slashdotters rubbing their minimum wage idiots' noses into the existence of their NetBSD on Mac IIcx Firewalls.
...None of which would have had any trouble had the network been set up correctly. The only time the free OS crowd gets into trouble with the "norms" is when they have to try and interface with the goddamned proprietary undocumented-for-your-protection bullshit protocols or procedures. Design your network with CLEAN implementations of TCP/IP and CLEAN POP3, IMAP, SMTP, HTTP, DNS, etc. etc. etc. services and you'll never ever hear from us! I guarantee it!
As soon as you try to muck things up in order to try and gain some edge over your users instead of using the procedures and protocols as defined you a) tip us off that something is up and b) get us curious enough to "fix" it, publishing the results and showing you off as the moron you are.
(you, being the ISP, not you personally.)
It is a fully dedicated digital circuit, and also is full-duplex, meaning you get 768 Kbps in both directions.
You must not have a full T1 then; I routinely get 1.5Mbps in both directions.
The rest of the money is probably spent on their internal data lines connecting POPs, devaluation of hardware, facilities costs, insurance, support /administrative /billing /sales staff wages and benefits, etc. It could add up to quite a bit.
Devaluation of equipment? Are you serious?
I do the network admin / deployment at a small (1600 user) ISP. We run around like crazy looking for "ancient" AS5200s because they just plain work. We get 47 lines out of each one (bastards made us use PRIs instead of DEAs so now we "retaliated" by asking for NFAS) and once configured, they just work.
I can't imagine cable being much different: You have your super-expensive head-end for each trunk, and once it is configured, you leave it be. Keep some parts around or, if you've got the cash, a hot spare and your equipment doesn't change. It doesn't devaluate in the sense that it wears out. Your bandwidth costs will be through the roof, yes, but that's what the economy of volume does for you. You have a 30MBit pipe for each trunk, a killer web cache and maybe 155MBit upstream. (I'm guessing here: Bell Canada's HSE (DSL) internet bandwidth overcommit rates being > 100:1, cable's can't be that far off)
The point is that yes the equipment is expensive and the bandwidth is expensive. But the equipment doesn't wear out. I'm sure you can get some pretty sweet deals on bandwidth when you tell your provider that you want enough feeds to service a nation. It had to have been mismanaged. This kind of story isn't new; this particular one just happens to have hit a hell of a lot of people at once.
Most people should wait a day or so to grab the latest kernel. As I'm finding (most of the US mirrors at least), 2.4.16 hasn't been mirrored to many of the mirrors yet :-)
I dunno; the Canadian mirror had 2.4.16 at 10AM (EST)
[ Reply to This | PareActually they tried to preserve some rights in this draft left out any language dealing with racial hatred because they felt it would violate the first amendment.
Oh, what a relief.
I can say what I want about other races, but if I prove a security protocol fundamentally flawed, I'm incarcerated. So long as I can racially slur.
Please get a book on data structures and look up 'normalization'. You sound like an idiot.
If you would have read any of my other comments in this thread you would know by know that it is you who sounds like an idiot. My quoting the word "normalization" and then using "normal" in a different meaning in the next sentence only proves how easy it is to sidetrack anonymous cowards.
So, I subscribe to DSS, wait for my box to decrypt the signal, then send the output of the box to my friend.
This is the fundamental problem -- crypto doesn't stop people who have the keys.
Of course it won't... at least not until people have the smartcard interface in the back of their head and tampering releases a neurotoxin.
I've been using The Brain, which treats documents, programs, shortcuts, program groups, etc as "thoughts" which you can link to any other thought.
I saw this ages ago and wanted a nice linux interface back then... or at least the algorithms for how they moved back and forth, very appealing.
In the case of HDCP, the protocol must remain public, so there is no chance for security through obscurity. They must solely rely on the strength of the protocol to cracking, whereas DirectTV has the strong advantage that no one outside the company secrets knows how the cryptography works.
So, other than the bruising of egos and the computation expense, what is wrong with using RSA/DSA key cryptography instead of some cockamamie homebrew stuff? Those protocols are open (RSA's patent has expired IIRC) and seem to be holding up to cryptanalysis...
Why do people continue to think they can build a secure system designed to simultaneous distribute data publicly and prevent its distribution?
Maybe I'm missing something, but doesn't the DSS television broadcasting system do this already? I mean yes it's crackable now but I believe that by sacrificing some of the bandwidth for content and using it for security instead, it could be made a lot harder to crack than it is now.
Cloning is going to be next to impossible to fix, yes, but I wonder if you couldn't get around the "wait 6 months for your receiver's "stop" command to stop being sent" by throwing a lot of processing power at it and basically encrypting the stream to every (yes the entire subscribed population) system's public key. Perhaps cloning could be avoided by making the cards smarter and using techniques of self-destruction if the cards detect that they're being tampered.
I know I'm no cryptographer and it's late for me here, but the idea of having a secure system simultaneously distribute data publicly yet prevent distribution to unwanted systems doesn't seem impossible, just impractical at this point.
WRT your example - since there appears to be a one-one relationship of most of those items to "name", separate tables are unnecessary (unless you have to maintain histories). If you just need current address and current spouse, you include those in the employee table.
You're falling into the trap... Yes it's true that most times it is a one-to-one relationship. However to think that everyone in the world has just one address or one spouse is folly, and that is exactly what I was getting at: You must either keep damn near everything as a two-column table to allow for many-to-one and many-to-many mappings, or you must hardcode in limits. Neither is very palatable, but in a hierarchial database it's easy and fast, so long as you don't want to update the thing all the time. Directories are meant almost as a WORM technology (Write Once (in this case Occassionally), Read Many). And since namespace redesigns are painful in directories, you need to take a great deal of care when setting one up in order to meet the 99% of people's needs.
It's like I had stated in another response: There are places for both systems; I would even go as far as to say most times you want a relational database. But to completely rule out hierarchial databases isn't a wise thing to do.
But a bad driver will only send wrong signals, resluting in the modem not working. I don't see how this will cause any damage to the network?
v.90 is limited to 53k by the FCC/CRTC because the code patterns to hit 56k interefere too much on ajacent pairs in the trunk. k.56flex wasn't limited to this because the coding didn't have as high energy levels. Put the wrong signals out there and you can cause trouble for everyone on your trunk.
While the previous paragraph is true, I don't see how the software drivers are being certified at all; I can download the Wang-Fu driver from Taiwan and use it in North America without certifying it. I've been kind of wondering about this because our NASes are recording the odd incoming connection at 56k, even though it's not supposed to see anything higher than 53k due to the FCC/CRTC restrictions. I know the digital modem firmware is international though, so it must be non-certified analog modem drivers (or IOS bugs) doing it.
Yeah, just as unfair as the fact that you have to learn to read before you can read a book.
If I am interpreting the article correctly, he is demanding formal education in signal processing. I'm sorry, but that is unfair. I don't need a piece of paper to tell me I know what I'm doing. I design embedded industrial control systems for a living without that piece of paper, than you very much. If I'm interpreting the article correctly, this guy is demanding the pinkie ring engineer type. No thanks.