Funny thing is, he didn't actually run the company. It was run by a lot of other much more experienced and savvy people. Didn't help in the end, but they got a lot farther than if he was actually doing something. I visited their offices on business once and met Shawn. He had absolutely *nothing* to do with the meeting, which you think he would have if he actually had anything to do with running the company. He was a face for the company, nothing more (and not even as much as Boies, if you think about it). And the technology he created was lame. Napster's technology *sucked*; it was just plain bad.
The fact that he's involved with "SnoCap" is not inspiring in any way. He's no technical heavy hitter, and he's no businessperson. His only benefit is likely to be the attention gained from having a "big name".
These are very cool keyboards, but they force you to relearn typing. They have placed some keys in very odd places. I don't think I'd ever get used to hitting enter with my thumb or having the tilde below the 'Z' key. Too weird. I'd rather just have the '6' key on the wrong side!!
I use only natural (i.e. split) keyboards, and have spent much time evaluating the various high and low end models. One flaw which is almost invariably present in all of them is that the '6' key is on the lefthand side. Touch typists like me object to this, as it forces you to unlearn correct typing. I was told by a keyboard manufacturer that this is because studies show it's more ergonomic that way. But I don't care - I want my 6 key where it belongs!! Unfortunately, this severely limits my field of keyboard choices. I wish someone made a split keyboard with movable, assignable keys. (Maybe they do, but I haven't found one.)
1] Keep it high level. Executives are dumb and detail confuses and scares them. That's counterproductive.
2] Keep it positive. Bitching makes them wonder if the problem is actually you.
3] Explain problems in terms of cause and effect. "If we don't upgrade the mail server, then in 3-6 months it won't be able to keep up and you won't get your mail."
4] Think about what issues you're going to raise ahead of time, and have reasons ready for raising them. Issues that seem half-baked won't be heard.
5] If you're married to dealing with a particular problem, at least don't be married to a particular solution. Have alternatives handy. Execs like to feel that they have a choice. If you don't offer them more than one, they may treat "ignore the problem" as one of them.
I'm curious: wouldn't that kind of content recognition kind of require that you already have a copy of what you are looking for
No. You search for, say, "Paperback Writer" by "The Beatles" by typing that into a search form. You click "go" and it searches for you. Anyone with files on their computer with a digital fingerprint matching that song shows up on your results, even if it's spelled "Beeetlas pay-per-BaCk ritter" or even "momma dogface in the banana patch".
Sure, it might work for finding the same file on multiple hosts. But even that is doubtful (at least I would rather know when I am downloading different parts of a file from different hosts, that I am downloading parts of the same file), and an ordinary hashing algorithm like SHA1 would definitely work better for such a purpose.
Of course, each file would have to be hashed to allow for concurrent download to ensure the file parts are identical. That goes without saying. But a hash is not good for identification in such a case as this, only verification of exact sameness.
I used pig latin simply to illustrate that spelling, grammar and punctuation variations can be negated by file recognition. And if you think the digital files out there are all *that* clean, textwise, you're dreaming. Sure, some of the files are well-tagged, but there are many that are not.
In any case this technology does work and will become pervasive in the near future. There are many uses beyond my single example, no matter how lame it is.
It's the future and will happen. However, I doubt "hashing" will be a big part of it. Digital fingerprinting will involve one of the many emerging audio and video recognition technologies, to avoid issues that come with applying a filter to a media file (or even changing a single byte). True recognition will be required, and will become a part of P2P life.
Whether this is used for good or evil depends upon who prevails in the courts and the moral disposition of the P2P developer. But media file recognition will eventually be an inseparable part of the P2P landscape.
I can think of at least *one* good use right off: wouldn't it be nice to look for a particular song and be able to find it without having to try various spelling variations, including pig latin?
Since when does Paul Thurrott, aka 'tuxlove,' post on/.?
I wasn't him the last time I looked in the mirror.
This crap isn't insightful. It's f*cking retarded, just like it was when Thurrott posted it.
Stop projecting and look at the statement. If it is true that HP's branded iPod will support WMA, then it is indeed ironic. If it's a rumor, then big deal. Rumors happen all the time. Truth is stranger than fiction, so I'm not betting against this just yet.
I'm certainly not betting against you ceasing to be an a**hole any time soon tho.
You seem to be ignoring that bandwidth was not the problem here. Given a low-to-medium-bandwidth SYN attack (i.e. SYN packets without a followup ACK to the host's subsequent SYN/ACK), SYN cookies will do just fine in solving the problem. If we're talking gigabits of SYN packets, well then, yes, it's a whole different ball of wax. But then again, that's not what we're talking. RTFA.
McBride seems to be claiming that unless you have the intent to make a profit and believe in making a profit off of your work, it can't be copyrighted?! Unbelievable. I thought his lawyers were supposed to be the best. I would have thought him better informed.
Slim Devices introduces SlimServer, our powerful and free Open Source software. Yeah, damn them, how creul [sic] and stupid of them.
Don't put words in my mouth. Better yet, why not read my comment? I noted that the server-side software would be a good thing for hackers to play with. I am not complaining about them keeping the software secret, because they're not. Duh, I read the story. I don't like it because I think such devices should be self-contained. Putting half of the smarts in the server rather than the device is sort of cheaping out, and also limits the device's capabilities. For example, if you have your MP3s on something like a SnapServer which is a self-contained NFS/SMB server, then you can't use the SliMP3. Period. Some may not agree that this is a weakness, and they are entitled to their erroneous opinion. But don't slam me for something I didn't say.
Going beyond the knee-jerk reactions against anything genetically engineered, the key to making these safe is to make sure they can't breed. There was a controversy over engineered trees that make better paper. The researcher noted that making them sterile greatly reduced whatever risk there might be for problems later on.
Man has no clue how to manage species in a way that is consistent with keeping balance in the environment. Every time we try to manipulate something there are unexpected consequences. (Well, okay, not every time. I am aware of two incidences where we successfully introduced a species to control another and it worked as planned. But our track record is 10000:1 against.)
You are clearly unaware that species considered pests, and in particular insects, are commonly controlled through the introduction of sterile individuals to interfere with the breeding of the larger population. Who is to say that if a hundred of these glowfish made sterile were dumped into a creek that it wouldn't cause population problems? What if indigenous females of some species found the glowfish males irresistible and didn't breed with fertile males for several seasons? You NEVER know what will happen when you introduce an animal to a place it's never been. Never.
We have a horrible track record with manipulating nature and have no fundamental understanding of how our changes affect other things. Do a little reading on some of our countless failures, especially in the area of genetic engineering, and maybe you'll begin to understand why the more informed people are concerned. There are ENDLESS examples of our failures and a handful of success stories. Having done a little learning on this topic myself, I fully agree with and support California's ban on these things. They serve no useful purpose other than being eye candy, so I hardly see why anyone would consider the risk worth taking.
Yikes! Welp, that's a good reason not to use an Audiotron. But who the heck has 30K songs anyway? Besides those with an unhealthy obsession, that is.:)
A very cool device, but it requires special server software. This is presumably because the unit itself does not have enough horsepower to support NFS/SMB/etc. for accessing MP3 files from a music server. Either that, or they were too lazy to put the required code into the player itself. In any case, a good player like the Audiotron can do this, and has ethernet/home plug, so I see little reason for buying this MP3 player. It would make a good hacker toy, since the guts apparently live on the server side, but otherwise I'd get something else. (Yes, the Audiotron does not yet support WiFi, but it will soon. You can also use a WET-11 or the like for an additional $50 or so.)
Why not UTF-8? I suppose that might have broken apps that expect ASCII-only, which
I guess is one of the reasons we now have base64 or quoted-printable encoding for email. But it sure would have been nice. Reading domain names in Punycode in many cases will not be a lot easier than reading binary...:(
I'm speechless at how brazen these guys are. I just don't know what to say, other than that I'm now afraid to buy their products. When I buy a product, I want it to work like it's supposed to work, not the way some marketing idiot thinks it should work. This is deceptive, possibly damaging, and certainly in violation of any number of specifications/RFCs. What are they thinking?
I hope they are also releasing the true originals, not just the remade originals from several years back. I was not entirely impressed by those. There were some definite improvements, but some things weren't. They were far too busy, with all sorts of things moving around and buzzing that weren't there before. And frankly, they didn't need to be. I think Lucas was acting like a kid in a candy store, "Hey let's do this and this and this, because we can!"
I really want to have the originals on DVD so I can remember Star Wars how it originally was.
Okay, that's the way it should work. I'm glad that's how they have it configured. So it sounds like the story was a bit overblown because the master copy of the kernel sources was never in doubt.
Same question. Why should anyone be able to check anything in except for the 5-10
people authorized to do so? The CVS/BitKeeper/Whatever daemon should not be reachable from the internet except for the IP addresses of the approved few. People other than them should not be allowed to check anything in or out, period, based on username, IP address and password. The public read-only server should be a mirror kept up to date through daily code pushes. Under these circumstances, even if the BitKeeper daemon was full of security holes, the master copy would be pretty darn hard to touch.
I think they are probably not following best practices, but I could be wrong because I don't know the ins and outs of how they have things set up. But what happend here should not be possible; else, it's probably set up wrong.
I don't see how Red Hat dropping its consumer product would make MS feel *more* threatened than it was before. Frankly, I think that's bad news for Linux. And Novell has a pretty horrible history with companies it buys, so I'm not sure this bodes well for SuSe. All in all, a pretty depressing week for Linux, IMHO.:(
Negligible gains over IDE? No. Significant gains.
RAID evens things out? No. The more disks you have to drive under IDE, the more your CPU bogs down.
Price/performance ratio better for IDE? No, under most circumstances.
SCSI is the only way to go if you care about speed. The SCSI commandset is also versatile - so much so that they borrowed it to extend IDE. IDE is ugly because the protocol is so closely tied to the hardware. Actual register addresses are part of the IDE specification, which just seems wrong somehow. And interrupts galore. Give me a nice smart SCSI controller (or even a dumb one these days) that only requires one or two register accesses to issue a command, and only interrupts at most once when a command completes. Yes, there are smart IDE controllers that hide most of this stuff from the system, but they still tend to run slower than SCSI controllers because their onboard CPUs, etc. tend to be much slower than that of the host system.
I once ran a test for weeks that drove 200 SCSI disks to the max, simultaneously on a single system (2 CPUs). The system had no trouble keeping the disks busy and still having power to spare. I don't think that would be possible with IDE - certainly not IDE drives directly connected to the system.
There are things about SCSI that are less than optimal, of course. I can't wait for the SCSI "bus" to die. It's too hardwarey. I worked on SCSI drivers/controllers for years, and nothing made it more agonizing than cabling problems. Bad terminators, bad cables, bad drive enclosures, argh! I was really hoping SCSI over Fibre Channel would take off, but that doesn't seem to be in the cards. Hopefully that will be solved some day soon with something like SATA.
Slashdot Mirror
Funny thing is, he didn't actually run the company. It was run by a lot of other much more experienced and savvy people. Didn't help in the end, but they got a lot farther than if he was actually doing something. I visited their offices on business once and met Shawn. He had absolutely *nothing* to do with the meeting, which you think he would have if he actually had anything to do with running the company. He was a face for the company, nothing more (and not even as much as Boies, if you think about it). And the technology he created was lame. Napster's technology *sucked*; it was just plain bad.
The fact that he's involved with "SnoCap" is not inspiring in any way. He's no technical heavy hitter, and he's no businessperson. His only benefit is likely to be the attention gained from having a "big name".
These are very cool keyboards, but they force you to relearn typing. They have placed some keys in very odd places. I don't think I'd ever get used to hitting enter with my thumb or having the tilde below the 'Z' key. Too weird. I'd rather just have the '6' key on the wrong side!!
I use only natural (i.e. split) keyboards, and have spent much time evaluating the various high and low end models. One flaw which is almost invariably present in all of them is that the '6' key is on the lefthand side. Touch typists like me object to this, as it forces you to unlearn correct typing. I was told by a keyboard manufacturer that this is because studies show it's more ergonomic that way. But I don't care - I want my 6 key where it belongs!! Unfortunately, this severely limits my field of keyboard choices. I wish someone made a split keyboard with movable, assignable keys. (Maybe they do, but I haven't found one.)
1] Keep it high level. Executives are dumb and detail confuses and scares them. That's counterproductive.
2] Keep it positive. Bitching makes them wonder if the problem is actually you.
3] Explain problems in terms of cause and effect. "If we don't upgrade the mail server, then in 3-6 months it won't be able to keep up and you won't get your mail."
4] Think about what issues you're going to raise ahead of time, and have reasons ready for raising them. Issues that seem half-baked won't be heard.
5] If you're married to dealing with a particular problem, at least don't be married to a particular solution. Have alternatives handy. Execs like to feel that they have a choice. If you don't offer them more than one, they may treat "ignore the problem" as one of them.
Lots more, but these are a good start.
I'm curious: wouldn't that kind of content recognition kind of require that you already have a copy of what you are looking for
No. You search for, say, "Paperback Writer" by "The Beatles" by typing that into a search form. You click "go" and it searches for you. Anyone with files on their computer with a digital fingerprint matching that song shows up on your results, even if it's spelled "Beeetlas pay-per-BaCk ritter" or even "momma dogface in the banana patch". Sure, it might work for finding the same file on multiple hosts. But even that is doubtful (at least I would rather know when I am downloading different parts of a file from different hosts, that I am downloading parts of the same file), and an ordinary hashing algorithm like SHA1 would definitely work better for such a purpose.
Of course, each file would have to be hashed to allow for concurrent download to ensure the file parts are identical. That goes without saying. But a hash is not good for identification in such a case as this, only verification of exact sameness.
I used pig latin simply to illustrate that spelling, grammar and punctuation variations can be negated by file recognition. And if you think the digital files out there are all *that* clean, textwise, you're dreaming. Sure, some of the files are well-tagged, but there are many that are not.
In any case this technology does work and will become pervasive in the near future. There are many uses beyond my single example, no matter how lame it is.
It's the future and will happen. However, I doubt "hashing" will be a big part of it. Digital fingerprinting will involve one of the many emerging audio and video recognition technologies, to avoid issues that come with applying a filter to a media file (or even changing a single byte). True recognition will be required, and will become a part of P2P life.
Whether this is used for good or evil depends upon who prevails in the courts and the moral disposition of the P2P developer. But media file recognition will eventually be an inseparable part of the P2P landscape.
I can think of at least *one* good use right off: wouldn't it be nice to look for a particular song and be able to find it without having to try various spelling variations, including pig latin?
Since when does Paul Thurrott, aka 'tuxlove,' post on /.?
I wasn't him the last time I looked in the mirror.
This crap isn't insightful. It's f*cking retarded, just like it was when Thurrott posted it.
Stop projecting and look at the statement. If it is true that HP's branded iPod will support WMA, then it is indeed ironic. If it's a rumor, then big deal. Rumors happen all the time. Truth is stranger than fiction, so I'm not betting against this just yet.
I'm certainly not betting against you ceasing to be an a**hole any time soon tho.
...considering that HPs decision to add WMA support to the iPod means that the iPod will *be* a Microsoft-enabled device.
You seem to be ignoring that bandwidth was not the problem here. Given a low-to-medium-bandwidth SYN attack (i.e. SYN packets without a followup ACK to the host's subsequent SYN/ACK), SYN cookies will do just fine in solving the problem. If we're talking gigabits of SYN packets, well then, yes, it's a whole different ball of wax. But then again, that's not what we're talking. RTFA.
McBride seems to be claiming that unless you have the intent to make a profit and believe in making a profit off of your work, it can't be copyrighted?! Unbelievable. I thought his lawyers were supposed to be the best. I would have thought him better informed.
Slim Devices introduces SlimServer, our powerful and free Open Source software. Yeah, damn them, how creul [sic] and stupid of them.
Don't put words in my mouth. Better yet, why not read my comment? I noted that the server-side software would be a good thing for hackers to play with. I am not complaining about them keeping the software secret, because they're not. Duh, I read the story. I don't like it because I think such devices should be self-contained. Putting half of the smarts in the server rather than the device is sort of cheaping out, and also limits the device's capabilities. For example, if you have your MP3s on something like a SnapServer which is a self-contained NFS/SMB server, then you can't use the SliMP3. Period. Some may not agree that this is a weakness, and they are entitled to their erroneous opinion. But don't slam me for something I didn't say.
Going beyond the knee-jerk reactions against anything genetically engineered, the key to making these safe is to make sure they can't breed. There was a controversy over engineered trees that make better paper. The researcher noted that making them sterile greatly reduced whatever risk there might be for problems later on.
Man has no clue how to manage species in a way that is consistent with keeping balance in the environment. Every time we try to manipulate something there are unexpected consequences. (Well, okay, not every time. I am aware of two incidences where we successfully introduced a species to control another and it worked as planned. But our track record is 10000:1 against.)
You are clearly unaware that species considered pests, and in particular insects, are commonly controlled through the introduction of sterile individuals to interfere with the breeding of the larger population. Who is to say that if a hundred of these glowfish made sterile were dumped into a creek that it wouldn't cause population problems? What if indigenous females of some species found the glowfish males irresistible and didn't breed with fertile males for several seasons? You NEVER know what will happen when you introduce an animal to a place it's never been. Never.
We have a horrible track record with manipulating nature and have no fundamental understanding of how our changes affect other things. Do a little reading on some of our countless failures, especially in the area of genetic engineering, and maybe you'll begin to understand why the more informed people are concerned. There are ENDLESS examples of our failures and a handful of success stories. Having done a little learning on this topic myself, I fully agree with and support California's ban on these things. They serve no useful purpose other than being eye candy, so I hardly see why anyone would consider the risk worth taking.
Yikes! Welp, that's a good reason not to use an Audiotron. But who the heck has 30K songs anyway? Besides those with an unhealthy obsession, that is. :)
A very cool device, but it requires special server software. This is presumably because the unit itself does not have enough horsepower to support NFS/SMB/etc. for accessing MP3 files from a music server. Either that, or they were too lazy to put the required code into the player itself. In any case, a good player like the Audiotron can do this, and has ethernet/home plug, so I see little reason for buying this MP3 player. It would make a good hacker toy, since the guts apparently live on the server side, but otherwise I'd get something else. (Yes, the Audiotron does not yet support WiFi, but it will soon. You can also use a WET-11 or the like for an additional $50 or so.)
Why not UTF-8? I suppose that might have broken apps that expect ASCII-only, which I guess is one of the reasons we now have base64 or quoted-printable encoding for email. But it sure would have been nice. Reading domain names in Punycode in many cases will not be a lot easier than reading binary... :(
I'm speechless at how brazen these guys are. I just don't know what to say, other than that I'm now afraid to buy their products. When I buy a product, I want it to work like it's supposed to work, not the way some marketing idiot thinks it should work. This is deceptive, possibly damaging, and certainly in violation of any number of specifications/RFCs. What are they thinking?
I hope they are also releasing the true originals, not just the remade originals from several years back. I was not entirely impressed by those. There were some definite improvements, but some things weren't. They were far too busy, with all sorts of things moving around and buzzing that weren't there before. And frankly, they didn't need to be. I think Lucas was acting like a kid in a candy store, "Hey let's do this and this and this, because we can!"
I really want to have the originals on DVD so I can remember Star Wars how it originally was.
Okay, that's the way it should work. I'm glad that's how they have it configured. So it sounds like the story was a bit overblown because the master copy of the kernel sources was never in doubt.
Same question. Why should anyone be able to check anything in except for the 5-10 people authorized to do so? The CVS/BitKeeper/Whatever daemon should not be reachable from the internet except for the IP addresses of the approved few. People other than them should not be allowed to check anything in or out, period, based on username, IP address and password. The public read-only server should be a mirror kept up to date through daily code pushes. Under these circumstances, even if the BitKeeper daemon was full of security holes, the master copy would be pretty darn hard to touch.
I think they are probably not following best practices, but I could be wrong because I don't know the ins and outs of how they have things set up. But what happend here should not be possible; else, it's probably set up wrong.
...is the primary CVS repository reachable? Nobody should be able to touch it, even just to read it, except the chosen few. Or am I mising something?
I don't see how Red Hat dropping its consumer product would make MS feel *more* threatened than it was before. Frankly, I think that's bad news for Linux. And Novell has a pretty horrible history with companies it buys, so I'm not sure this bodes well for SuSe. All in all, a pretty depressing week for Linux, IMHO. :(
...in name only.
Gator is spyware.
S-P-Y-W-A-R-E
I.e., software that spies.
Negligible gains over IDE? No. Significant gains.
RAID evens things out? No. The more disks you have to drive under IDE, the more your CPU bogs down.
Price/performance ratio better for IDE? No, under most circumstances.
SCSI is the only way to go if you care about speed. The SCSI commandset is also versatile - so much so that they borrowed it to extend IDE. IDE is ugly because the protocol is so closely tied to the hardware. Actual register addresses are part of the IDE specification, which just seems wrong somehow. And interrupts galore. Give me a nice smart SCSI controller (or even a dumb one these days) that only requires one or two register accesses to issue a command, and only interrupts at most once when a command completes. Yes, there are smart IDE controllers that hide most of this stuff from the system, but they still tend to run slower than SCSI controllers because their onboard CPUs, etc. tend to be much slower than that of the host system.
I once ran a test for weeks that drove 200 SCSI disks to the max, simultaneously on a single system (2 CPUs). The system had no trouble keeping the disks busy and still having power to spare. I don't think that would be possible with IDE - certainly not IDE drives directly connected to the system.
There are things about SCSI that are less than optimal, of course. I can't wait for the SCSI "bus" to die. It's too hardwarey. I worked on SCSI drivers/controllers for years, and nothing made it more agonizing than cabling problems. Bad terminators, bad cables, bad drive enclosures, argh! I was really hoping SCSI over Fibre Channel would take off, but that doesn't seem to be in the cards. Hopefully that will be solved some day soon with something like SATA.