MOTU, M-Audio, Digidesign, and many other companies make audio interfaces capable of 24 bit 96 Khz audio encoding and decoding, which is well above the 16 bit 44.1 Khz that CDs use. Any of them should do.
Exactly.
Want good sound....buy pro gear.
Consumer stuff you get at Best Buy is crap made for people who don't know what they're buying and "audiophile" stuff is snake oil. Pro audio gear from a respectable manufacturer (Mackie for example) will be much better and actually includes enough specs so that you can make informed buying desisions.
The nice thing is that pro gear really isn't that expensive any more. Sites like Musician's Friend give you a place to by gear that will might just last the rest of your life at very low prices.
Pro gear has better interfaces, better connectors, more honest specs, higher reliability and is targeted at people who have actual money riding on their audio system.
I would hope that they'd be reading this thread, but since you don't have any positive moderation here yet the only way to call attention to it (given my lack of mod points) is to reply. Anyway there is no need to have stable and unstable branches of Wikipedia really, just of individual articles. Ideally there would be four views between which you could switch rapidly: stable, unstable, side by side, and differential with the changes included on a different background color. With proper in-application caching and browser cache settings, this should add relatively little overhead and would allow a useful examination of both the information in the stable, verified article, and the potentially more complete unstable version.
All great ideas, but I, personally, would love to see wikipedia periodically archived somewhere in completely "frozen" version (like published editions of a book). This would make things a lot less of a headache if you wanted to cite something in an academic paper.
Right now a lot of the credibility problems wikipedia has stem not just from its constant state of flux, but also the relectancy of academics to accept that style of information in general.
Straight-up snapshots would give someone like me something to point to and say "See, it's just like editions of a book. Twenty years from now you'll still be able to go to that exact page, and all the line numbers will still match up. Just go to Wikipedia-stable-2004-rev2."
I guess what could be done is a combination of the two:
Take periodic snapshots that are reviewed and revised for correctnees.
At the same time, put a checkbox on the unstable page that will give you a "diff" of the current stable version and the current unstable version. (I imagine this woul also make moderators jobs easier.)
.the assumption that there will be two distinct sources of reference information in the future - the Wikipedia style on-line "texts", which may contain far greater detail than the Encyclopedia in your library on modern day topics, recent developments, and the short but almost 100% factually correct entry in that reference book from your library.
Actualy, what I would expect to see is "stable" and "unstable" branches of wikipedia, much like the linux kernel.
Periodically, the wikipedia database could have a snapshot taken and any undates to this snapshot except for "bug fixes" would be prohibited, meanwhile the "development" wikipedia branch would couldtinue to be updated, providing upto the minute information.
People would generally use the "stable" branch to get information about things like George Washington's birthday, but they would still be able to get up to-the-minute information on other subject from the "unstable" branch.
Perhaps I should email the wikipedia maintianers with this idea....
Microsoft is under no obligation to support updates to applications that are not running under the operating system listed on that magical little section on the side of the box that says "System Requirements."
I would LOVE to see you try to find an actual LAW that supports that position.
I can write anything I want on the side of a retail box. Unless the customer actually signs a contract, they are free to ignore it.
Meanwhile, consumer protection laws exist that make it illegal to do something like write "office suite" on the outside of the box, and put something inside that is not a functional office suite. Either the customer gets their money back, or the manufacturer has to fix it.
Furthermore, anti-trust laws exist that specfically forbid monopolies from engaging in this sort of behavior. (Using their monopoly position with one product to deliberatly break functionaly of a competitior's product in another market, so that they may expand their monopoly.)
When a person explicitly claims that they are recalling the last time they tried to install an operating system,....
Not when they use the word "unsupported". It's one thing to not be able to get the drivers to work, it's a totally different thing to say they don't even exist.
Oh, and since you've posted that you had this stuff working 3 years ago, it's abundantly clear that not only are you a flamer with no class at all, you're also a liar and a shit disturber. I went looking at Hercules' website and checked the ALSA pages the last time I tried to get the thing working, and it sure as hell wasn't 3 years ago.
What's funny is that nothing you're saying here show's that I'm a liar. All the things I said I had working, I really did have working and you're not providing any evidence to the contrary. This is because you won't be able to, you can go to archive.org and actually see that this stuff did exist 3 years ago.
What's mildly interesting here is your total unwillingness to back off from your original position. You posted a bunch of statements about linux driver support that are blatantly and provably wrong, yet you continue to defend it.
As another poster put it: "It's the eternal question: is the parent poster a Microsoft astroturfer, or just a damned idiot?"
A reasonable person might come to the realization that they should not have made a post claiming linux's lack of driver support for things that actually are supported and whose drivers have been part of the standard linux kernel for a while now. They might also see that if they had actually done a five second google search, they might have made that stuff work.
Furthermore, they might refrain from making these statements in the future until they are at least marginally competent. If you don't want to improve your knowedge of the subject that's fine, just please refrain from making any more bullshit statements about linux driver support until you do.
Glad to see things have been coming along, perhaps I'll give it another go.
This isn't stuff that's new. It had this stuff I had working about 3 years ago.
Hopefully someone else will correct any errors in my post.
Hopefully next time you won't run around claiming thing don't work when very obviously haven't even done a basic search to check.
If you had done even the FIRST step of typing "promise raid linux" into google, or running "grep -R promise/usr/src/linux/*" you would have seen that your RAID is supported. AFAIK Promise even hosts some raid drivers on their own site.
You deserve to be flamed because you DIDN'T EVEN CHECK before you started calling things "unsupported".
1) A7V133 motherboard with onboard Promise IDE RAID.
Promise RAID unsupported. Half my hard drives gone.
My promise raid works fine.
2) Asus V7100 Geforce2 MX with TV input/output.
TV Input unsupported. TV Output unsupported. Guess I'll have to buy a DVD player and throw my DivX collection away
I have a Gainward geforce 2 ti with VIVO. Both video input AND video output work.
3) S3 Virge PCI running secondary monitor.
Supposedly it's supported, but I never managed to get it to work, and I spent almost a week working on it nightly. No more multi-monitor support.
I'm sorry dude, but you suck at linux.
There's not really a nicer way to say it. You're listing shit that I *KNOW* is supported and saying that it doesn't work. That gives you ZERO credibility.
Here are some links proving that so of this hardware ACTUALLY IS SUPPORTED:
If you were actually being honest and saying that you simply couldn't get these things to work, I wouldn't be so harsh, but it's pretty damned obvious that you didn't even try, and that things you're calling that "unsupported" ACTUALLY DO WORK.
As a result, your cluelessness is misleading people as to the capabilities of my favorite operating system. The issue here really is your inablity to use google and read directions, not Linux's lack of driver support.
I'm sure I could find more links to get some of his other hardware working, but my aim here is to prove that this guy is incompetent and should not attempt to speak authoritatively on linux driver support.
Let me state this again and very clearly:
I'm not flaming this guy because he couldn't get his hardware to work, that can be a hard thing to do sometimes. I'm flaming this guy because, by stating that something is "unsupported" he is implying that NOBODY has made his hardware work. This is really obviously false, and denies the existence of the hard work of some very nice people. If you can't be bothered to install the right drivers and edit the right config files.... fine, JUST DO GO AROUND IMPLYING THAT OTHER PEOPLE'S HARD WORK DOESN'T ACTUALLY EXIST.
How about a buttered toast Sphere? The buttered side would be inside the sphere, and non buttered out.
Using this as the base, a hovering vehicle could be only days away!
Except that this sphere could be in a state of continual freefall without violating and laws, it would just never hit the ground.
It would probably exhibit some annoying behavior like falling half the distance to the ground each second. If would never actually crash, but in a manner of minutes you may as well be walking.
As of January 1, 2000, the Federal Communications Commission (FCC) required all new television sets 13 inches or larger to contain the V-chip technology
You really missed the point.
If the FCC is going to have expanded powers, they have to be given them by congress.
If congress passed a law requiring all TVs to be broadcast flag compliant, then the FCC would have a mandate to enforce it. The FCC cannot, on their own, decide to place arbitrary requirements on electronic devices.
who mandates closed captioning in all tv's over 13" screensize and the lovely v-chip?
Congress, at least for the v-chip, probably for closed-captioning too.
If the FCC's power's are going to be expanded, then congress must pass a law doing so, otherwise it's like to post office suddenly deciding to liscense people to use the wireless spectrum, they simply don't have the authority to do so.
what about all those rules re; radio interferance and cell phone & wifi antenna/design registrations.
is that not
dictate how electronic devices must be made
NO IT"S NOT.
The FCC (generally) only has the authority to dictate the use of the electromagnetic spectrum.
THEY DON'T TELL MANUFACTURERS HOW TO BUILD THINGS.
They don't tell them how to build Xboxes, cellphones, etc.
They tell they that you device must be designed in such a way that it will meet with their regulations on the EM spectrum.
This is all they are allowed to do, BY LAW.
If "the people" (a term I use very loosely...believe me) decide that the FCC should actually be able to tell manufactures to respect the broadcast flag, the a law must be passed saying they have the authority to do so.
This is what the cellphone industry pushed through for scanners and thing is what the television industry will have to do:
Buy a law.
Isn't democracy grand?
I KNOW I would be able to tell the difference between my turntable and my CD player.
I didn't ask you that.
Right now your system got Turntable=>Amp & Speakers. I am suggesting turntable=>CD=> Amp & speakers.
A lot of people who talk about the sound "quality" of one thing over another have actually never tested it. The thing this test could prove would be that you like the sound "coloration" provided by your CD player, not the "superior quality".
I can't hear above 22KHz, yet vinyl still sound superior to me.
You *like* the sound of vinyl.
Some people like the sound of 8-tracks.
You are not a calibrated laboratory instrument.
People still have these discussions because they *feel* a certain way. This does not mean those feelings are at all based on reality.
Do you honestly think you would be able to tell if I recorded the output of your turntable to a CD and played it again through the same amplifier and speakers you're using now? Do you think you could pass a double blind test?
This is only true for lossless codecs. This won't work for any lossy codec. You can't go from MP3->WAV->MP3 for example without quality loss.
Not true.
You loose information when you change algorithms, or when you run up against specfic algorithms with specfic glitches, but there's no reason you can't have a "lossy" codec that will go Codec=>WAV=>codec and give you the EXACT same bits as you had before.
I can't speak for any of the major audio codecs, but to say that this is a problem for ALL lossly codes is simply just not true.
In general, if you know enough about the system that did the coding, you could make a copy of a DRMed audio file via a WAV output with zero quality loss. The caveat will be that you're such using the EXACT same algorithm they did.
The only way this would not be true was if random number generators we somehow involved.
Let:
the original.wav file = X
Encoding algorithm = f(x)
Decoding algorithm = g(x)
Re-encoding algorithm = h(x)
The studio creates Y = f(x). You want to get Y (it's the best you can do).
You play it back to a.wav file to get Z = g(Y) = g(f(X))
You know Y. You know g(x). You create h(x) such that h(Z) = Y. This is the inverse function of g(x).
The caveat here is that h(x) may of may not be the same as f(x), so while you may be able to go from MP3=>WAV=>MP3 without losing any data, the function you use at the second step may be a different one than the one originally used to encode the file.
Note:
It might not be possible to generate an inverse function for MP3, WMA, etc. I doubt this as we're talking about file formats that we designed for playback, not secure hashing functions.
In the weird event where an obvious algorithm is not available, at a bare minimum it is still possible to conduct a brute force search for Y by trying different input values to g(x) and comparing the output to Z.
Perhaps someone more versed than I in audio compression algorithms can comment on the availibilty of inverse functions for the popular decompression algorithms.
i don't think you got my point. you won't be running windows, you'll be running whatever it is that's on that CD and the thing won't be able to just run itself and it'll find it and get rid of it. that's why it checks it from the system itself and then boots off the cd and checks again. any discrepencies are obviously indicators of what files were affected.
I don't think you get my point.
This program works by looking for files that look different under the control of a virus than when you're running a trusted piece of software.
The thing is, it's pretty much trivial to get around if you let the virus decide where to look, which is what you're doing if you do anything but scan raw devices.
Even after you reboot and you're running you're trusted software, the virus is still deciding where you look because it has previously had the ability to alter filesystems, partition tables, etc.
from what i've read, it sounds like the tool would be used to check while the machine is running and then you boot to the cd, which, obviously, the rootkit cannot infect. and then it checks again. and since it's running off the cd, the rootkit will not be running.
Sure, but unless you check every single bit (NOT EVERY FILE) of persitent storage on the system, the virus can just shuffle itself around.
For example:
A virus makes a copy of foo.exe and bar.exe.
It stores them in unallocated space or slack space (either works).
Then replaces foo.exe and bar.exe with itself.
When you check foo.exe, it copies back the real file. When you check bar.exe it replace foo.exe with the virus again and then copies back the real bar.exe
In this situation, all your files will hash to the correct values, AND they will hash to the same values when you reboot.
The only way to beat this is to hash every bit. If you do not do that, the virus will always be able to play a shell game with you.
In order to fool GhostBuster, the rootkit must 1) detect that such a checking program is running and either not lie to it or change the output as it's written to disk (in the limit this becomes the halting problem for the rootkit designer), 2) integrate into the BIOS rather than the
Although it's a clever idea, there are lots of ways to get around it.
The program could simply pull itself off that part of the hard disk and sit in RAM any time you try and read it, even if you try to trick it, it can intercept the ACPI power off command and write itself to the disk at the last second. Since it already owns the computer, it doesn't have to tell you that it's in RAM. (The program can tie itself to whatever calls it wants to that happen right before you shut the computer down.)
Probably an even better way to thwart this is to just jump around to different places on the hard disk. When you read section A, it stores itself to section B. When you read B, it goes back to A.
Still, the idea IS clever. The right way to do it would be to do a hash of all the drives in the system, and this is very important... it would have to be below the filesystem level. You would have to hash the raw device.
Anything less than hashing every single bit of persistent storage on the system could be fairly easily hidden from.
As someone else pointed out - it is just a matter of how much computing power do you want to put behind your attempt to break an encryption.
NO IT'S NOT.
Moore's law applies to encryption as well as decryption. Sure we can crack keys faster than we ever could before, but we can also use longer key lengths.
Furthermore, Moore's law is understood to be a fact of life at this point so it's pretty easy to plan for future increases in computing power.
Even more importantly, a linear increase in key length results in and exponential increase in difficulty.
We basically are building our own nightmare.
Chill dude.... the sky is not falling. Cryptography does not become irrelevant just because you've got a "fast" computer.
Good crypto, not-broken-at-the-algorithm-level relies on some frickin hard math problems. Things you wouldn't be able to solve in your lifetime if you turned every atom on the planet into a transistor.
I do see your point, but remember that you could argue the RSA is useless because if I did it over a 32 bit address space it's easy to prime-factorize any number and therefore increasing it to a 2048 bit space is "just avoiding the problem".
You are comparing apples to oranges. We're talking about a mathematical breakthrough, not the release of the newest processor.
This problem isn't arising because we have faster processors, it's arising because someone has discovered a fundamental flaw in the algorithm. Sure you can take your chances and hope that this work won't beget more research which shows that SHA-1 can be comprimised even easier than we think now, but that would just make me think you weren't paying attention during the whole MD5 situation.
Maybe somebody won't be able to take this finding any further, but I think it definately hasn't been out there long enough to be able to say that yet. Worry that someone else will be able to take this reseach and the newfound insight into the algorithm that it provides to show that SHA-1 is even less ecure than we think now.
Why not use two hashes? It's exponentially harder to find a collision that fits for two hashes, isn't it?
Two reasons:
The first is implementation specfic. Say you're using this hash function for a typical/etc/passwd file. By using two hashes you've just made yourself even weaker than if you had only used one hash. (It's like having two doors with one lock each, not two locks on one door.)
Note that there are circumstances where you don't care about this, because the original data is public and you just want to be sure it wasn't fiddled with.
The second lies in that fact that yes, you are making it hard to tamper with a file by using two algorithms, but unless you have two algorithms that are exactly equally secure, you would be better off just applying those extra bits to make the hash from the stronger algorithm longer.
It seems like the way to fix the problem (make the encrypted data difficult enough to decode using brute force methods) is to move up to stronger algorithms. This happens continuously, it doesnt mean that the old alogorithm was initially flawed, but rather it has become obsolete due to increasing computing power.
Actually, in this case the algorithm IS flawed.
The issue here is not that we have more computing power, it's that someone has found a mathematical method to "beat" SHA1.
The entire point of a secure hashing algorithm is to have no better means of finding a collision than simple brute force.
Since that is no longer true for SHA1, the algorithm is indeed broken. The break isn't a total worst case scenario, nor as bad as the recent MD5 break, but this hash is indeed broken.
Sure you can take a chance and up your hash lengths, but you have no guaratee that this partial break isn't going to turn into a more complete, more severe break (which is exactly what happened with MD5).
distributed.net has already completed a 2^64 operation challenge a few years ago, which along with Moores law puts 2^69 ops into the realm of the possible.
What's interesting about this is that a project like this might actually have a chance of succeeding now.
See this link, section 1.2 for a little more detail on the subject.
While this doesn't help them with discovering Microsoft's private key, it could allow them to generate a modified version of a tool like GRUB who's bits hash to the same value as a Microsoft-approved binary.
Although not quite as cool as getting the actual key, this would allow running arbitray unsigned code without the need to buy a game and use a buffer overflow exploit, solder in a modchip, etc. This might also work for other game systems and similarly locked down devices.
Dipoles are 300 Ohm (that cheap wire antenna you get with an FM receiver is a dipole made out of 300 Ohm twin-lead), monopoles around 50 to 75.
There's nothing that says ALL "ladder lines" have to be 300 ohms or 450 ohm or any other specfic impedance. It's just a function of your wire diameter and the spacing.
Of course there are very good reasons that engineers choose the impedances they do. But it's still at least theoretically possible to make the whole passive repeater setup with two pieces of wire and some duct tape:)
A passive repeater seems to be the most sensible idea I've seen so far.
This guy should be able to build one for less than $20, and it's about as close to an instant, duct tape and bailing wire solution as you're going to get.
As far as easily availible, decent coax RG6 is what you want. It seems to be what the cable companies are switching over to, and it should be very easy to get at your local home despot.
Also, for Vp = 3E8 m/s a quarter wavelength is:
84 cm for 890 MHz
42 cm for 1800 MHz
Also note that your quarter wavelength section need to be supported by something non-metallic (like wood or plastic).
If someone wanted to create a true duct tape and bailing wire solution, it might actually be possible using a ladder-line type connection between the antennas. The losses at 1.8 GHz might make this unworkable, but if you're able to solve your problem with just some cheap wire, duct tape and a ruler, you'll look pretty badassed. I'll leave the transmission line spacing as an exercist for the reader:)
Slashdot Mirror
MOTU, M-Audio, Digidesign, and many other companies make audio interfaces capable of 24 bit 96 Khz audio encoding and decoding, which is well above the 16 bit 44.1 Khz that CDs use. Any of them should do.
Exactly.
Want good sound....buy pro gear.
Consumer stuff you get at Best Buy is crap made for people who don't know what they're buying and "audiophile" stuff is snake oil. Pro audio gear from a respectable manufacturer (Mackie for example) will be much better and actually includes enough specs so that you can make informed buying desisions.
The nice thing is that pro gear really isn't that expensive any more. Sites like Musician's Friend give you a place to by gear that will might just last the rest of your life at very low prices.
Pro gear has better interfaces, better connectors, more honest specs, higher reliability and is targeted at people who have actual money riding on their audio system.
All great ideas, but I, personally, would love to see wikipedia periodically archived somewhere in completely "frozen" version (like published editions of a book). This would make things a lot less of a headache if you wanted to cite something in an academic paper.
Right now a lot of the credibility problems wikipedia has stem not just from its constant state of flux, but also the relectancy of academics to accept that style of information in general.
Straight-up snapshots would give someone like me something to point to and say "See, it's just like editions of a book. Twenty years from now you'll still be able to go to that exact page, and all the line numbers will still match up. Just go to Wikipedia-stable-2004-rev2."
I guess what could be done is a combination of the two:
Sound good?
.the assumption that there will be two distinct sources of reference information in the future - the Wikipedia style on-line "texts", which may contain far greater detail than the Encyclopedia in your library on modern day topics, recent developments, and the short but almost 100% factually correct entry in that reference book from your library.
Actualy, what I would expect to see is "stable" and "unstable" branches of wikipedia, much like the linux kernel.
Periodically, the wikipedia database could have a snapshot taken and any undates to this snapshot except for "bug fixes" would be prohibited, meanwhile the "development" wikipedia branch would couldtinue to be updated, providing upto the minute information.
People would generally use the "stable" branch to get information about things like George Washington's birthday, but they would still be able to get up to-the-minute information on other subject from the "unstable" branch.
Perhaps I should email the wikipedia maintianers with this idea....
Microsoft is under no obligation to support updates to applications that are not running under the operating system listed on that magical little section on the side of the box that says "System Requirements."
I would LOVE to see you try to find an actual LAW that supports that position.
I can write anything I want on the side of a retail box. Unless the customer actually signs a contract, they are free to ignore it.
Meanwhile, consumer protection laws exist that make it illegal to do something like write "office suite" on the outside of the box, and put something inside that is not a functional office suite. Either the customer gets their money back, or the manufacturer has to fix it.
Furthermore, anti-trust laws exist that specfically forbid monopolies from engaging in this sort of behavior. (Using their monopoly position with one product to deliberatly break functionaly of a competitior's product in another market, so that they may expand their monopoly.)
When a person explicitly claims that they are recalling the last time they tried to install an operating system, ....
Not when they use the word "unsupported". It's one thing to not be able to get the drivers to work, it's a totally different thing to say they don't even exist.
Oh, and since you've posted that you had this stuff working 3 years ago, it's abundantly clear that not only are you a flamer with no class at all, you're also a liar and a shit disturber. I went looking at Hercules' website and checked the ALSA pages the last time I tried to get the thing working, and it sure as hell wasn't 3 years ago.
What's funny is that nothing you're saying here show's that I'm a liar. All the things I said I had working, I really did have working and you're not providing any evidence to the contrary. This is because you won't be able to, you can go to archive.org and actually see that this stuff did exist 3 years ago.
What's mildly interesting here is your total unwillingness to back off from your original position. You posted a bunch of statements about linux driver support that are blatantly and provably wrong, yet you continue to defend it.
As another poster put it:
"It's the eternal question: is the parent poster a Microsoft astroturfer, or just a damned idiot?"
A reasonable person might come to the realization that they should not have made a post claiming linux's lack of driver support for things that actually are supported and whose drivers have been part of the standard linux kernel for a while now. They might also see that if they had actually done a five second google search, they might have made that stuff work.
Furthermore, they might refrain from making these statements in the future until they are at least marginally competent. If you don't want to improve your knowedge of the subject that's fine, just please refrain from making any more bullshit statements about linux driver support until you do.
Glad to see things have been coming along, perhaps I'll give it another go.
/usr/src/linux/*" you would have seen that your RAID is supported. AFAIK Promise even hosts some raid drivers on their own site.
This isn't stuff that's new. It had this stuff I had working about 3 years ago.
Hopefully someone else will correct any errors in my post.
Hopefully next time you won't run around claiming thing don't work when very obviously haven't even done a basic search to check.
If you had done even the FIRST step of typing "promise raid linux" into google, or running "grep -R promise
You deserve to be flamed because you DIDN'T EVEN CHECK before you started calling things "unsupported".
My promise raid works fine.
2) Asus V7100 Geforce2 MX with TV input/output. TV Input unsupported. TV Output unsupported. Guess I'll have to buy a DVD player and throw my DivX collection away
I have a Gainward geforce 2 ti with VIVO. Both video input AND video output work.
3) S3 Virge PCI running secondary monitor. Supposedly it's supported, but I never managed to get it to work, and I spent almost a week working on it nightly. No more multi-monitor support.
I'm sorry dude, but you suck at linux.
There's not really a nicer way to say it. You're listing shit that I *KNOW* is supported and saying that it doesn't work. That gives you ZERO credibility.
Here are some links proving that so of this hardware ACTUALLY IS SUPPORTED:
If you were actually being honest and saying that you simply couldn't get these things to work, I wouldn't be so harsh, but it's pretty damned obvious that you didn't even try, and that things you're calling that "unsupported" ACTUALLY DO WORK.
As a result, your cluelessness is misleading people as to the capabilities of my favorite operating system. The issue here really is your inablity to use google and read directions, not Linux's lack of driver support.
I'm sure I could find more links to get some of his other hardware working, but my aim here is to prove that this guy is incompetent and should not attempt to speak authoritatively on linux driver support.
Let me state this again and very clearly:
I'm not flaming this guy because he couldn't get his hardware to work, that can be a hard thing to do sometimes. I'm flaming this guy because, by stating that something is "unsupported" he is implying that NOBODY has made his hardware work. This is really obviously false, and denies the existence of the hard work of some very nice people. If you can't be bothered to install the right drivers and edit the right config files.... fine, JUST DO GO AROUND IMPLYING THAT OTHER PEOPLE'S HARD WORK DOESN'T ACTUALLY EXIST.
How about a buttered toast Sphere? The buttered side would be inside the sphere, and non buttered out.
Using this as the base, a hovering vehicle could be only days away!
Except that this sphere could be in a state of continual freefall without violating and laws, it would just never hit the ground.
It would probably exhibit some annoying behavior like falling half the distance to the ground each second. If would never actually crash, but in a manner of minutes you may as well be walking.
As of January 1, 2000, the Federal Communications Commission (FCC) required all new television sets 13 inches or larger to contain the V-chip technology
WHICH THEY DID AFTER CONGRESS PASSED A LAW ALLOWING THEM TO.
You really missed the point.
If the FCC is going to have expanded powers, they have to be given them by congress.
If congress passed a law requiring all TVs to be broadcast flag compliant, then the FCC would have a mandate to enforce it. The FCC cannot, on their own, decide to place arbitrary requirements on electronic devices.
who mandates closed captioning in all tv's over 13" screensize and the lovely v-chip?
Congress, at least for the v-chip, probably for closed-captioning too.
If the FCC's power's are going to be expanded, then congress must pass a law doing so, otherwise it's like to post office suddenly deciding to liscense people to use the wireless spectrum, they simply don't have the authority to do so.
what about all those rules re; radio interferance and cell phone & wifi antenna/design registrations.
is that not dictate how electronic devices must be made
NO IT"S NOT.
The FCC (generally) only has the authority to dictate the use of the electromagnetic spectrum.
THEY DON'T TELL MANUFACTURERS HOW TO BUILD THINGS.
They don't tell them how to build Xboxes, cellphones, etc.
They tell they that you device must be designed in such a way that it will meet with their regulations on the EM spectrum.
This is all they are allowed to do, BY LAW.
If "the people" (a term I use very loosely...believe me) decide that the FCC should actually be able to tell manufactures to respect the broadcast flag, the a law must be passed saying they have the authority to do so.
This is what the cellphone industry pushed through for scanners and thing is what the television industry will have to do:
Buy a law.
Isn't democracy grand?
I KNOW I would be able to tell the difference between my turntable and my CD player.
I didn't ask you that.
Right now your system got Turntable=>Amp & Speakers. I am suggesting turntable=>CD=> Amp & speakers.
A lot of people who talk about the sound "quality" of one thing over another have actually never tested it. The thing this test could prove would be that you like the sound "coloration" provided by your CD player, not the "superior quality".
I can't hear above 22KHz, yet vinyl still sound superior to me.
You *like* the sound of vinyl.
Some people like the sound of 8-tracks.
You are not a calibrated laboratory instrument.
People still have these discussions because they *feel* a certain way. This does not mean those feelings are at all based on reality.
Do you honestly think you would be able to tell if I recorded the output of your turntable to a CD and played it again through the same amplifier and speakers you're using now? Do you think you could pass a double blind test?
Not true.
You loose information when you change algorithms, or when you run up against specfic algorithms with specfic glitches, but there's no reason you can't have a "lossy" codec that will go Codec=>WAV=>codec and give you the EXACT same bits as you had before.
I can't speak for any of the major audio codecs, but to say that this is a problem for ALL lossly codes is simply just not true.
In general, if you know enough about the system that did the coding, you could make a copy of a DRMed audio file via a WAV output with zero quality loss. The caveat will be that you're such using the EXACT same algorithm they did.
The only way this would not be true was if random number generators we somehow involved.
Let:
the original
Encoding algorithm = f(x)
Decoding algorithm = g(x)
Re-encoding algorithm = h(x)
The caveat here is that h(x) may of may not be the same as f(x), so while you may be able to go from MP3=>WAV=>MP3 without losing any data, the function you use at the second step may be a different one than the one originally used to encode the file.
Note:
It might not be possible to generate an inverse function for MP3, WMA, etc. I doubt this as we're talking about file formats that we designed for playback, not secure hashing functions.
In the weird event where an obvious algorithm is not available, at a bare minimum it is still possible to conduct a brute force search for Y by trying different input values to g(x) and comparing the output to Z.
Perhaps someone more versed than I in audio compression algorithms can comment on the availibilty of inverse functions for the popular decompression algorithms.
i don't think you got my point. you won't be running windows, you'll be running whatever it is that's on that CD and the thing won't be able to just run itself and it'll find it and get rid of it. that's why it checks it from the system itself and then boots off the cd and checks again. any discrepencies are obviously indicators of what files were affected.
I don't think you get my point.
This program works by looking for files that look different under the control of a virus than when you're running a trusted piece of software.
The thing is, it's pretty much trivial to get around if you let the virus decide where to look, which is what you're doing if you do anything but scan raw devices.
Even after you reboot and you're running you're trusted software, the virus is still deciding where you look because it has previously had the ability to alter filesystems, partition tables, etc.
Sure, but unless you check every single bit (NOT EVERY FILE) of persitent storage on the system, the virus can just shuffle itself around.
For example:
The only way to beat this is to hash every bit. If you do not do that, the virus will always be able to play a shell game with you.
In order to fool GhostBuster, the rootkit must 1) detect that such a checking program is running and either not lie to it or change the output as it's written to disk (in the limit this becomes the halting problem for the rootkit designer), 2) integrate into the BIOS rather than the
Although it's a clever idea, there are lots of ways to get around it.
The program could simply pull itself off that part of the hard disk and sit in RAM any time you try and read it, even if you try to trick it, it can intercept the ACPI power off command and write itself to the disk at the last second. Since it already owns the computer, it doesn't have to tell you that it's in RAM. (The program can tie itself to whatever calls it wants to that happen right before you shut the computer down.)
Probably an even better way to thwart this is to just jump around to different places on the hard disk. When you read section A, it stores itself to section B. When you read B, it goes back to A.
Still, the idea IS clever.
The right way to do it would be to do a hash of all the drives in the system, and this is very important... it would have to be below the filesystem level. You would have to hash the raw device.
Anything less than hashing every single bit of persistent storage on the system could be fairly easily hidden from.
As someone else pointed out - it is just a matter of how much computing power do you want to put behind your attempt to break an encryption.
NO IT'S NOT.
Moore's law applies to encryption as well as decryption. Sure we can crack keys faster than we ever could before, but we can also use longer key lengths.
Furthermore, Moore's law is understood to be a fact of life at this point so it's pretty easy to plan for future increases in computing power.
Even more importantly, a linear increase in key length results in and exponential increase in difficulty.
We basically are building our own nightmare.
Chill dude.... the sky is not falling.
Cryptography does not become irrelevant just because you've got a "fast" computer.
Good crypto, not-broken-at-the-algorithm-level relies on some frickin hard math problems. Things you wouldn't be able to solve in your lifetime if you turned every atom on the planet into a transistor.
I do see your point, but remember that you could argue the RSA is useless because if I did it over a 32 bit address space it's easy to prime-factorize any number and therefore increasing it to a 2048 bit space is "just avoiding the problem".
You are comparing apples to oranges.
We're talking about a mathematical breakthrough, not the release of the newest processor.
This problem isn't arising because we have faster processors, it's arising because someone has discovered a fundamental flaw in the algorithm. Sure you can take your chances and hope that this work won't beget more research which shows that SHA-1 can be comprimised even easier than we think now, but that would just make me think you weren't paying attention during the whole MD5 situation.
First somebody finds a chink in the armor.
The next person punches right through it.
Maybe somebody won't be able to take this finding any further, but I think it definately hasn't been out there long enough to be able to say that yet. Worry that someone else will be able to take this reseach and the newfound insight into the algorithm that it provides to show that SHA-1 is even less ecure than we think now.
Two reasons:
Note that there are circumstances where you don't care about this, because the original data is public and you just want to be sure it wasn't fiddled with.
It seems like the way to fix the problem (make the encrypted data difficult enough to decode using brute force methods) is to move up to stronger algorithms. This happens continuously, it doesnt mean that the old alogorithm was initially flawed, but rather it has become obsolete due to increasing computing power.
Actually, in this case the algorithm IS flawed.
The issue here is not that we have more computing power, it's that someone has found a mathematical method to "beat" SHA1.
The entire point of a secure hashing algorithm is to have no better means of finding a collision than simple brute force.
Since that is no longer true for SHA1, the algorithm is indeed broken. The break isn't a total worst case scenario, nor as bad as the recent MD5 break, but this hash is indeed broken.
Sure you can take a chance and up your hash lengths, but you have no guaratee that this partial break isn't going to turn into a more complete, more severe break (which is exactly what happened with MD5).
distributed.net has already completed a 2^64 operation challenge a few years ago, which along with Moores law puts 2^69 ops into the realm of the possible.
What's interesting about this is that a project like this might actually have a chance of succeeding now.
See this link, section 1.2 for a little more detail on the subject.
While this doesn't help them with discovering Microsoft's private key, it could allow them to generate a modified version of a tool like GRUB who's bits hash to the same value as a Microsoft-approved binary.
Although not quite as cool as getting the actual key, this would allow running arbitray unsigned code without the need to buy a game and use a buffer overflow exploit, solder in a modchip, etc. This might also work for other game systems and similarly locked down devices.
So what do you guys wanna bet that at least a few of these researchers have their phones tapped at this point?
I can't think of any intelligence agency that that wouldn't like a few days head start with any more findings these guys come up with.
I'm not really headed anywhere specfic with this comment, other than getting this thought out there. People have been bugged to gain access to much less exciting information than this.
Dipoles are 300 Ohm (that cheap wire antenna you get with an FM receiver is a dipole made out of 300 Ohm twin-lead), monopoles around 50 to 75.
:)
There's nothing that says ALL "ladder lines" have to be 300 ohms or 450 ohm or any other specfic impedance. It's just a function of your wire diameter and the spacing.
Check out this page for a calculator.
Of course there are very good reasons that engineers choose the impedances they do. But it's still at least theoretically possible to make the whole passive repeater setup with two pieces of wire and some duct tape
A passive repeater seems to be the most sensible idea I've seen so far.
:)
This guy should be able to build one for less than $20, and it's about as close to an instant, duct tape and bailing wire solution as you're going to get.
As far as easily availible, decent coax RG6 is what you want. It seems to be what the cable companies are switching over to, and it should be very easy to get at your local home despot.
Also, for Vp = 3E8 m/s a quarter wavelength is:
84 cm for 890 MHz
42 cm for 1800 MHz
Also note that your quarter wavelength section need to be supported by something non-metallic (like wood or plastic).
If someone wanted to create a true duct tape and bailing wire solution, it might actually be possible using a ladder-line type connection between the antennas. The losses at 1.8 GHz might make this unworkable, but if you're able to solve your problem with just some cheap wire, duct tape and a ruler, you'll look pretty badassed. I'll leave the transmission line spacing as an exercist for the reader