In the embedded video, they indicate that hard disks need to be wrapped in some material the vendor apparently provides, presumably for just this reason. Not sure how well the wrapping transfers heat.
Ares V - unmanned rocket with huge lift capability.
Ares I - manned rocket designed to be extremely safe and get a manned capsule to LEO, period.
Plans for a moon shot involve using Ares V to launch the hardware, Ares I to launch the people, and a rendezvous in orbit before proceeding to the moon. Read all about it.
Routers are cheap. Buy a WRT54GL. Note the 'L', this is the "Linux" version and is more or less equivalent to a WRT54G, version 4 (v5 is when they started to suck). Install dd-wrt, the flavor with QoS.
I have basically the same setup as you, Vonage, home network, occasional BT use. dd-wrt is configured to give highest priority to the port the Vonage box is plugged in to, and bulk (lowest) priority to traffic in the bittorrent port range. Works very well for me.
All the QoS settings are in the dd-wrt GUI, you don't need to know Linux per se.
But per the article they are even forging the SYN/ACK response to a SYN connection request. (Hell, to ssh connections even!) This meets the definition of an impersonation attack. Much more closely than the definition of traffic shaping, anyway.
(Coming soon - Comcast hires mobsters to whack every third customer, but "it's not homicide, it's traffic shaping!")
Recently while checking bags at the airport ticket counter, something caught my eye...
Apparently one of the machines that sniffs for explosive residue in those swabs they wipe luggage with had stopped working. They fixed it with a power cycle, and I was greeted with a familiar sight... the Windows 98 boot screen. Be afraid.
Re:Java's not exactly pining for the fields just n
on
Java vs .NET
·
· Score: 0, Offtopic
I think you mean pining for the fjords, something that norwegian blues are known to do.
Agreed, using the same vehicle for crew and cargo clearly compromises safety and capability for both.
I'm a bit perturbed, though, by the idea that we should go back to launching crew in single-use vehicles a-la 1960. Sure, it would probably be safer than the shuttle, but (and I'm getting tired of hearing it) safety should not be NASA's primary goal. If you want safety, stay home already. Safety as an open-ended goal cannot be satisfied; it is both a money sink and a rhetorical ace-up-the-sleeve. Witness the current "safety from terrorism" efforts.
Part of NASA's reason for being is to advance the state of the art for the public benefit; redeploying fourty year old technology won't do that. The purpose of the Mercury and Gemini projects were to make mistakes and learn from them, to eventually culminate in Apollo. The shuttle is the Mercury of reusable ships. Twenty-five years between technology generations is far too long. Let's learn from our mistakes and (with the cargo-carrying requirement dropped as a mistake) build the next generation shuttle already.
Reusable crew vehicles are ultimately preferred, as they have greater inherent capacity for safety than single-use craft. Which flight of an airliner would you rather be on - its 1000th, or its very first?
Launch the cargo on big dumb boosters but develop an elegant, safe way to get people to and from LEO .
Not to slam the FSF, but for important distribution sites is it feasible to host the files from read-only media? Like burned CD-R or perhaps (for ease of update) a SCSI HD with the write disable jumper in place?
Seems like keeping the authoritative archive on machines unconnected to the 'net would be the way to go. Hard to beat physical security. But maybe this would be too much a pain-in-the-ass.
Anybody know of a site using a similar strategy?
Re:Duh. Its called reflection
on
Hijacking .NET
·
· Score: 2, Interesting
This is not necessarily true.
If a SecurityManager is installed (as one would be in the applet environment or any other environment running less-than-completely-trusted code) Class.getDeclaredField() for a non-public member may throw a SecurityException (depending upon the policy enforced by the particular SecurityManager).
Just some trivia, for those pointing out that sour milk is yogurt, cheese, etc.
That is only true for non-pasteurized milk. Once milk has been pasteurized, it will not sour, only spoil. Of course, it takes longer to spoil this way then it would if it was not pasteurized.
Milk that goes bad in your fridge is not on its way to sour cream, yogurt, cheese, or anything else edible. It's just rotten, and not particularly safe to drink.
I think everybody understands that we're a long way from realizing a non-polluting transportation infrastructure with any technology.
In the shorter term, yes, generating electricity produces pollution, but electricity still wins if generating it creates less pollution than what it replaces. Centralizing generation makes it economically feasible to spend the big bucks on super-efficient gas-turbine generation, stack scrubbers, etc., which you can't do in a distributed system (i.e., everyone burning their own fossil fuels).
My personal vision of eco-nirvana is super-efficient, cheap solar cells coupled with small, efficient hydrogen production (from water) technology. Every household has one, generates during the day, converts hydrogen to electricity at night, can sell/buy from the grid as necessary, and as a bonus can fuel their hydrogen car before heading out... A guy can dream, right?
General aviation flying is not safer than driving. If memory serves, the stats for light planes and motorcycles are similar. Scheduled commercial flying (FAR part 121 operations) is, but parachutes aren't practical there and likely never will be.
Well, fifty years is a damn long time, so who knows.
That said, historically raw computing power has increased more rapidly than network bandwidth. Rsync is essentially about using compute power to save bandwidth, using hashes and checksums to avoid transferring unnecessary bytes. So the cost/benefit will likely still hold. The network may be faster, but the files will be bigger and the CPU will be faster still.
That said, rsync as a command-line utility will almost surely be gone, but the ideas in rsync may well migrate directly into the application layer or even the network stack. At least, it's more likely to be around than samba, which is a fantastic yet special purpose tool for a specialized problem (Windows compatible file-sharing).
Besides, tridge got his CompSci Ph.D. for his rsync work, so nobody should be surprised he's proud of it.:-) Check out his thesis at http://samba.org/~tridge.
Beyond the technology transfers well enumerated by other posts, I'd wager that a healthy percent of today's scientists/engineers would be making a living in some other field. I know I would.
Don't underestimate the value of wonder and inspiration, particularly to children.
AT&T purchased TCI, so now in areas of the country where TCI offered @Home the service is billed as "AT&T/@Home". @Home remains an independent entity, not considering that Excite and @Home merged some time ago.
It's fairly shocking how misleading DSL purveyors are in their advertising...consider, from the DSL vs cable modem section at pacbell.com.
"DSL service is flexible enough to grow with the skills and interests of our users." That's one vague sentence...in fact, I'm not even sure what it means. Marketing 101 - play up the unquantifiable advantages. They can't be argued with.
"DSL is as reliable as your phone." Duping the simple masses who think same wire == same reliability. Whatever. Several of my friends with DSL feel differently...
"DSL speed... stays consistent, as opposed to the shared systems used by cable companies where speed may decrease as more users sign up." So every customer has a dedicated T1 to each major NAP? Bitchin'.
And the winner...
"Cable modem services often do not support a wide variety of Internet applications." Wow. Talk about menacingly vague. Anyone have a cable modem that won't work with everything (not counting Network Neighborhood, of course...;-)
I'm surprised they're not being sued. Or maybe they are.
Others have already pointed out the dubious value of "interactivity". For me, interactivity is but one means to the end of enjoyable experience. The "new media" seems to be in love with interactivity as its own end.
I'd suggest, actually, that better music/movies/entertainment is in fact interactive. Great entertainment manages to engage the mind and the heart at the same time. There's no less interaction just because I'm not manipulating the medium myself.
And thank heavens! I tried writing fiction once, and it sucked. Hard. I'm thrilled to let people who have devoted their lives to the craft take the reins. We all get to live with our ideas nearly 24/7 - what refreshment there is in letting someone else drive for a bit.
Incestuous, self-centered, feedback-loop interactivity doesn't interest me one bit.
I was hopeful - the first episode Gibson co-wrote was pretty good, I thought. A similar "AI gone wrong" premise, but at least it didn't feature TLG futzing with a hard drive power connector while prattling about building a "kill switch"(!?!)
The X-file here (even though you could see it coming a mile away) was a digital character affecting the real world, and they didn't even attempt to explain that. Add plot holes big enough to drive a truck through (would you enter a machine that just killed someone without explanation??) and CC's annoying pseudo-intellectual Mulder voice-over...
CSS isn't about copy protection at all. The MPA likes to pretend it is, because plenty of people feel the way you do (myself included), plus they get to wield copyright law as a powerful weapon in the courts.
But as soon as writable DVD's with equal capacity to regular DVDs are available, anyone will be able to copy a DVD - just like anyone can copy an audio CD now. Read encrypted bytes, write encrypted bytes. No big deal.
CSS is about maintaining control over the decoding mechanism, for purposes of maximizing profit. By encrypting content with a key, keys much be purchased by DVD decoder manufacturers and DVD authors - and for a pretty penny. But more insidious, the DVD consortium gets to ensure that any decoding design enforces features intended to maximizing the DVD consortium's revenue, like region codes, by denying keys to noncompliant implementations. And what are region codes but legalized price discrimination?
CSS is about protecting the revenue stream of the DVDCCA, not protecting the rights of content authors. I support the rights of business to make a profit, but not at the expense of individual speech rights. The way to protect the rights of authors is to enact and enforce laws against selling copies of copyrighted material - laws we already have. When was the last time you went to your neighborhood mall and bought a CDR some guy burned in his bedroom?
Only when for-profit violations of copyright go unenforced are the livelyhoods of content authors at risk.
A quick addition to my reply - just wanted to acknowledge that a good bit of what I just wrote is quite client-centric (I'm working on a client right now...or should be...:). I still think that the simplicity of blocking I/O outweighs marginal performance gains, especially if the JVM has to jump through hoops to simulate asynchronous.
Granted. And it's certainly a paradigm common elsewhere in Java. I guess I had my head wrapped around UNIX-style asynch I/O while writing.
There are still a great many thorny issues, though - what thread does your "listener" receive data "events" on, for example? The AWT event thread is the only one that would make any sense, as it's the only one in which it is safe to update UI (for Swing, at least). With a mouse click, all the data relevant to the click can be delivered at once. But with I/O, if data isn't delivered in a chunk size big enough to make UI changes with, you'd have to batch it somehow. Why not batch it in a separate thread? But now we're back where we started.
Life would be much more interesting for people implementing their own filter streams - underlying streams would have to pass data up into the filter, to determine if data was available to pass out of the filter. If you're chaining filters, when does the data cross the thread boundary? (As it will need to if being delivered in the event thread.) The current model makes writing your own I/O manipulation simple, and I think there's a lot of value in that.
I/O is inherently complex enough that trying to hide the complexity behind an event model is probably counterproductive.
That's not to say I haven't wished I could addSocketListener() from time to time. I just don't think it'd be less painful, ultimately.
Slashdot Mirror
In the embedded video, they indicate that hard disks need to be wrapped in some material the vendor apparently provides, presumably for just this reason. Not sure how well the wrapping transfers heat.
Um, you just described the Ares program.
Ares V - unmanned rocket with huge lift capability.
Ares I - manned rocket designed to be extremely safe and get a manned capsule to LEO, period.
Plans for a moon shot involve using Ares V to launch the hardware, Ares I to launch the people, and a rendezvous in orbit before proceeding to the moon. Read all about it.
Routers are cheap. Buy a WRT54GL. Note the 'L', this is the "Linux" version and is more or less equivalent to a WRT54G, version 4 (v5 is when they started to suck). Install dd-wrt, the flavor with QoS.
I have basically the same setup as you, Vonage, home network, occasional BT use. dd-wrt is configured to give highest priority to the port the Vonage box is plugged in to, and bulk (lowest) priority to traffic in the bittorrent port range. Works very well for me.
All the QoS settings are in the dd-wrt GUI, you don't need to know Linux per se.
Forging RSTs is one thing.
But per the article they are even forging the SYN/ACK response to a SYN connection request. (Hell, to ssh connections even!) This meets the definition of an impersonation attack. Much more closely than the definition of traffic shaping, anyway.
(Coming soon - Comcast hires mobsters to whack every third customer, but "it's not homicide, it's traffic shaping!")
But wouldn't that kill the fish?
Recently while checking bags at the airport ticket counter, something caught my eye...
Apparently one of the machines that sniffs for explosive residue in those swabs they wipe luggage with had stopped working. They fixed it with a power cycle, and I was greeted with a familiar sight... the Windows 98 boot screen. Be afraid.
Although not so much when they're dead.
Agreed, using the same vehicle for crew and cargo clearly compromises safety and capability for both.
I'm a bit perturbed, though, by the idea that we should go back to launching crew in single-use vehicles a-la 1960. Sure, it would probably be safer than the shuttle, but (and I'm getting tired of hearing it) safety should not be NASA's primary goal. If you want safety, stay home already. Safety as an open-ended goal cannot be satisfied; it is both a money sink and a rhetorical ace-up-the-sleeve. Witness the current "safety from terrorism" efforts.
Part of NASA's reason for being is to advance the state of the art for the public benefit; redeploying fourty year old technology won't do that. The purpose of the Mercury and Gemini projects were to make mistakes and learn from them, to eventually culminate in Apollo. The shuttle is the Mercury of reusable ships. Twenty-five years between technology generations is far too long. Let's learn from our mistakes and (with the cargo-carrying requirement dropped as a mistake) build the next generation shuttle already.
Reusable crew vehicles are ultimately preferred, as they have greater inherent capacity for safety than single-use craft. Which flight of an airliner would you rather be on - its 1000th, or its very first?
Launch the cargo on big dumb boosters but develop an elegant, safe way to get people to and from LEO .
Not to slam the FSF, but for important distribution sites is it feasible to host the files from read-only media? Like burned CD-R or perhaps (for ease of update) a SCSI HD with the write disable jumper in place?
Seems like keeping the authoritative archive on machines unconnected to the 'net would be the way to go. Hard to beat physical security. But maybe this would be too much a pain-in-the-ass.
Anybody know of a site using a similar strategy?
This is not necessarily true.
If a SecurityManager is installed (as one would be in the applet environment or any other environment running less-than-completely-trusted code) Class.getDeclaredField() for a non-public member may throw a SecurityException (depending upon the policy enforced by the particular SecurityManager).
is people!!!
Just some trivia, for those pointing out that sour milk is yogurt, cheese, etc.
That is only true for non-pasteurized milk. Once milk has been pasteurized, it will not sour, only spoil. Of course, it takes longer to spoil this way then it would if it was not pasteurized.
Milk that goes bad in your fridge is not on its way to sour cream, yogurt, cheese, or anything else edible. It's just rotten, and not particularly safe to drink.
I think everybody understands that we're a long way from realizing a non-polluting transportation infrastructure with any technology.
In the shorter term, yes, generating electricity produces pollution, but electricity still wins if generating it creates less pollution than what it replaces. Centralizing generation makes it economically feasible to spend the big bucks on super-efficient gas-turbine generation, stack scrubbers, etc., which you can't do in a distributed system (i.e., everyone burning their own fossil fuels).
My personal vision of eco-nirvana is super-efficient, cheap solar cells coupled with small, efficient hydrogen production (from water) technology. Every household has one, generates during the day, converts hydrogen to electricity at night, can sell/buy from the grid as necessary, and as a bonus can fuel their hydrogen car before heading out... A guy can dream, right?
General aviation flying is not safer than driving. If memory serves, the stats for light planes and motorcycles are similar. Scheduled commercial flying (FAR part 121 operations) is, but parachutes aren't practical there and likely never will be.
Well, fifty years is a damn long time, so who knows.
:-) Check out his thesis at http://samba.org/~tridge.
That said, historically raw computing power has increased more rapidly than network bandwidth. Rsync is essentially about using compute power to save bandwidth, using hashes and checksums to avoid transferring unnecessary bytes. So the cost/benefit will likely still hold. The network may be faster, but the files will be bigger and the CPU will be faster still.
That said, rsync as a command-line utility will almost surely be gone, but the ideas in rsync may well migrate directly into the application layer or even the network stack. At least, it's more likely to be around than samba, which is a fantastic yet special purpose tool for a specialized problem (Windows compatible file-sharing).
Besides, tridge got his CompSci Ph.D. for his rsync work, so nobody should be surprised he's proud of it.
Matt
Yeah, and stealing things that aren't tied down is perfectly ethical.
Don't underestimate the value of wonder and inspiration, particularly to children.
AT&T purchased TCI, so now in areas of the country where TCI offered @Home the service is billed as "AT&T/@Home". @Home remains an independent entity, not considering that Excite and @Home merged some time ago.
Matt
What they did was actually pretty intelligent. They didn't "scan the entire thing in", just the pages with signatures, stamps, and other boilerplate.
"DSL service is flexible enough to grow with the skills and interests of our users."
That's one vague sentence...in fact, I'm not even sure what it means. Marketing 101 - play up the unquantifiable advantages. They can't be argued with.
"DSL is as reliable as your phone."
Duping the simple masses who think same wire == same reliability. Whatever. Several of my friends with DSL feel differently...
"DSL speed ... stays consistent, as opposed to the shared systems used by cable companies where speed may decrease as more users sign up."
So every customer has a dedicated T1 to each major NAP? Bitchin'.
And the winner...
"Cable modem services often do not support a wide variety of Internet applications." ;-)
Wow. Talk about menacingly vague. Anyone have a cable modem that won't work with everything (not counting Network Neighborhood, of course...
I'm surprised they're not being sued. Or maybe they are.
I'd suggest, actually, that better music/movies/entertainment is in fact interactive. Great entertainment manages to engage the mind and the heart at the same time. There's no less interaction just because I'm not manipulating the medium myself.
And thank heavens! I tried writing fiction once, and it sucked. Hard. I'm thrilled to let people who have devoted their lives to the craft take the reins. We all get to live with our ideas nearly 24/7 - what refreshment there is in letting someone else drive for a bit.
Incestuous, self-centered, feedback-loop interactivity doesn't interest me one bit.
I was hopeful - the first episode Gibson co-wrote was pretty good, I thought. A similar "AI gone wrong" premise, but at least it didn't feature TLG futzing with a hard drive power connector while prattling about building a "kill switch"(!?!)
The X-file here (even though you could see it coming a mile away) was a digital character affecting the real world, and they didn't even attempt to explain that. Add plot holes big enough to drive a truck through (would you enter a machine that just killed someone without explanation??) and CC's annoying pseudo-intellectual Mulder voice-over...
Pretty awful.
CSS isn't about copy protection at all. The MPA likes to pretend it is, because plenty of people feel the way you do (myself included), plus they get to wield copyright law as a powerful weapon in the courts.
But as soon as writable DVD's with equal capacity to regular DVDs are available, anyone will be able to copy a DVD - just like anyone can copy an audio CD now. Read encrypted bytes, write encrypted bytes. No big deal.
CSS is about maintaining control over the decoding mechanism, for purposes of maximizing profit. By encrypting content with a key, keys much be purchased by DVD decoder manufacturers and DVD authors - and for a pretty penny. But more insidious, the DVD consortium gets to ensure that any decoding design enforces features intended to maximizing the DVD consortium's revenue, like region codes, by denying keys to noncompliant implementations. And what are region codes but legalized price discrimination?
CSS is about protecting the revenue stream of the DVDCCA, not protecting the rights of content authors. I support the rights of business to make a profit, but not at the expense of individual speech rights. The way to protect the rights of authors is to enact and enforce laws against selling copies of copyrighted material - laws we already have. When was the last time you went to your neighborhood mall and bought a CDR some guy burned in his bedroom?
Only when for-profit violations of copyright go unenforced are the livelyhoods of content authors at risk.
A quick addition to my reply - just wanted to acknowledge that a good bit of what I just wrote is quite client-centric (I'm working on a client right now...or should be...:). I still think that the simplicity of blocking I/O outweighs marginal performance gains, especially if the JVM has to jump through hoops to simulate asynchronous.
There are still a great many thorny issues, though - what thread does your "listener" receive data "events" on, for example? The AWT event thread is the only one that would make any sense, as it's the only one in which it is safe to update UI (for Swing, at least). With a mouse click, all the data relevant to the click can be delivered at once. But with I/O, if data isn't delivered in a chunk size big enough to make UI changes with, you'd have to batch it somehow. Why not batch it in a separate thread? But now we're back where we started.
Life would be much more interesting for people implementing their own filter streams - underlying streams would have to pass data up into the filter, to determine if data was available to pass out of the filter. If you're chaining filters, when does the data cross the thread boundary? (As it will need to if being delivered in the event thread.) The current model makes writing your own I/O manipulation simple, and I think there's a lot of value in that.
I/O is inherently complex enough that trying to hide the complexity behind an event model is probably counterproductive.
That's not to say I haven't wished I could addSocketListener() from time to time. I just don't think it'd be less painful, ultimately.