One of the surprises of the Apollo experience was how troublesome the lunar dust turned out to be. It obscured their vision on landing, clogged mechanisms, abraded the Extravehicular Mobility Suits (EMS), scratched the instrument covers, degraded the performance of radiators, compromised seals, irritated their eyes and lungs, and generally coated everything with surprising tenacity. Some of the EMS components were approaching failure at the end of these missions, which ranged from 21 to 75 hr on the lunar surface.
Also, the dust is far from a constant size, and is far more abrasive than you'll find here on earth, due to a lack of erosion mechanisms on the moon.
But, again, you need the machines to do the mining. I'm not convinced yet that we'll be able to get enough materials out of the moon to make any base mechanically self-sufficient...I think the dust will tear up any mining machinery faster than it will be able to provide any base with replacement parts. In that situation, the moon is no better than L5...there may be materials there, but we can't get them out easily.
(Note: I admit that I'm extrapolating from just a few facts, but given the state of the lunar rover and other stuff from the Apollo missions, I don't think I'm completely off base. I could still be wrong, but I'd like to see how.)
Re:I'm all for science/technology/astronomy but...
on
Back to Moon in 2015?
·
· Score: 1
Why do it in a gravitational well at all? As I mentioned in a different post, L5's a far better place to do that assembly...it's almost 0g, and a far weaker gravitational well.
Though it pains me to ask this (I'd love for us to be doing more space exploration), is building a base there really a good idea? From what I've read, the lunar dust is incredibly hard on mechanical things (gears, seals, etc)...that would make maintenance of any lunar base very difficult, and prohibitively expensive.
For all of that effort (both in the initial build, and in the launch/materials costs for maintenance)...what do we get? Not much, even in terms of science.
I'd love for us to do more space exploration, but honestly, I think a really big station at L4 or L5 would be a much better idea. Locally stable gravitiational point, but not a deep gravity well, far less dust, very low g environment, etc.
It's not as sexy as the moon, but really...L5's the place to be, not the moon.
Imagine a society where an orchestra couldn't play any classical music without acquiring the rights to that performance from a copyright holder that has been passed down through the centuries by inane copyright law and they end up paying a large amount of money for you to enjoy their performance.
That's already happening. Last time I checked, it was very difficult to get permission to perform "Eine Kleine Nichtmusik", a joke classical music piece, because Peter Schickele (the composer, aka PDQ Bach) was being a bastard about making sure people did it "right."
On the other hand, if you're looking to deploy a Linux box (which is happening a lot in the government), and there's "free" (as in, already paid for by another division) support for SUSE, that makes the distro choice very easy, and makes the management justification part easy as well.
Mostly, I think this will have the effect of slowly unifying the distro choice at HHS & NIH to SUSE. Linux is already happenning, this just makes the deployment more orderly.
I think "perfectly working" is a bit of a stretch. It loads, doesn't crash, and displays video and audio...fair enough. If you want them to sync up, though, you're out of luck.
Macromedia isn't showing much interest in making their Linux client much better (why should they?), so this effort is a perfectly reasonable one, I think.
I disagree...if they can really pull off 30 miles, that's a big deal (that covers big parts of most major metro areas), especially to radio.
Morning and evening drive-time are the biggest money-makers for radio (it's almost the only time many people listen to the radio anymore). If you give people the ability to stream indie feeds into their cars, drive-time suddenly gets much more competitive, especially if your cost to stream to cars approaches zero.
My only concern is: who's allowed to be a stream source? Anyone? Or just certain "approved" bodies? If it's anyone, I'm there.
Segfaults are no problem...config files, on the other hand, are a huge mess in Gentoo. I can't tell you the number of times I've had to manually tweak something after emerge decided that the config file for a given app needed a different format. (or, just for fun, they re-named an app...vcron vs vixie-cron, for example...very annoying)
Gentoo's fun for desktops and experimenting stations...but I shouldn't have to do that much constant tweaking on a server. Once I switched my servers to Deb, I fear not the "apt-get upgrade"...it won't break my config files.
Aside from the language stuff, I don't think these conclusions are unique to Africa. If you remove the phrase "in Africa" from each bullet point, you could have a very believable set of statements about lots of places. (this is also a bit of a blueprint to show where FOSS has holes that need to be filled.)
Re:Similar technology - Methane Farming...
on
Filling Up On Algae
·
· Score: 1
I really don't envy the guy whose job it is to put the diapers on the cows...ick.
This isn't a battle-type situation (though we keep using war terminology). It's more like a biological infection model...the "infection" (OSS use) starts in areas where the system isn't fighting it, and spreads as it's able to find new undefended areas. It won't eliminate all resistance, but it can spread quite far, if virulent enough. The question is, are we virulent enough yet?
And it would cost them at least 4x as much (in resources, salaries, etc).
How much is not hating a solution worth, if the mediocre solution gets the job done? Is not hating the program worth several programmer's salaries? Most companies would answer no. Things have to be *really* bad before the cost to the company is worth more staff to fix. That's why they don't roll their own.
The fact that they hate these programs just means that they have very little loyalty to them. If another program comes along that works better (or convinces the PHB's that it does), they'll switch.
On the other hand, there are some things that every (or at least many) companies are doing, like HR, payroll management, finances, inventory management, etc...why should everyone re-invent the wheel? There *should* be some value in off-the-shelf software for common tasks. It's just that it all sucks.
If anyone can build an OSS payroll/finance system that *works* and you can get support for...it'll take over corporations very quickly. Everyone I've talked to *hates* the one they've got presently.
And the problem, as the GP post pointed out, is that folks will even mark those confirmation requests as spam...not much a legit list can do in that case, except talk to the ISP, but you have to know it's happening first.
Have a look at the site: only the arin contact, postmaster@ or abuse@ are going to be able to get these stats. Customers, spammers (who don't own the IP space they're querying) and regular joe's are not going to be given this by MS (at least, not in this rev...we'll see what the future holds)
Spammers? probably not. But, the ISPs that are running mailing lists will. (Ie legitimate mail, not spam) I know a couple folks at my office are curious to see this, just to see how much of our mailing list traffic is getting dumped by a big provider.
(before you all start, yes, they're opt-in, and they're limited subject lists anyway, so there's no reason to spam with them.)
ummm....not that I'm disagreeing with you, but McVoy didn't write Subversion. SVN's an open-source project much like Arch, Monotone, etc. McVoy did Bitkeeper.
(just doing fact-checking....we now return you to your normally scheduled slashdot discussion)
News flash: this sort of coordination is already happening. The reason this is even a story is because Mozilla is breaking the norm. If there weren't a norm of cooperation, no one would care that Mozilla was going their own way. But, since they are breaking the norm, people are unhappy.
Have a look at BugTraq, FullDisclosure or other vuln discussion lists. When someone posts a vulnerability without notifying the vendor/author there are *very* snarky comments made about the responsibility of the post. The same thing happens when an (major) app releases a security fix without notifying the major distros.
Communication isn't optional anymore. Neither are the "coordinators" that you loathe.
You left out a variable: time. Releasing early widens the amount of time that the users relying on the distro for the patch are vulnerable. There is tons of evidence that vulnerabilities are attacked more after release of a patch, or announcement of a vulnerability. (Not to say it doesn't happen before, just that it happens *more* afterwards.)
So, it's in the general interest to get as many people patched *quickly* once the public announcement is made. Vendor patch systems are the best way to do that.
I disagree. Completely. It's in the general interest of everyone for the app writers and the distros to work together...the goal, after all, is for the end user to get patches quickly, effectively, and *before* there's an exploit. A lot of the distros have central patch distribution systems...these systems are the best way to get patches to the end user for that distro.
If an app releases a bug fix without working with the distro, it leaves the end user there to get screwed...either they wait for their distro to get the patch put together (running vulnerable code the whole time), or they break their use of the patch distribution system (meaning they have to either re-patch once the vendor releases, or never follow the vendor patch system for that app again). This isn't a choice we want to be giving the users. The best result is *absolutely* a coordinated response, where the authors, the distros and the original reporter of the problem all release simultaneously.
That isn't possible in this case, since there's no distro to work with for Windows. Mozilla is, in this situation, choosing to minimize the risk for their Windows users (who likely far outnumber their OSS users), at the expense of the distro coordination. It's not a fun choice to make, but a sensible one, given their situation.
Why cant mozilla stop hiding bugs and marking vulnerabilities as secret in bugzilla?
Open indeed...
I shouldn't respond to this troll, but I will.
Marking security-related bugs as secret is entirely appropriate. If the bug notes were public, they would serve as a blueprint to 0-day attacks on Mozilla, which the Moz folks are (rightly) attempting to prevent.
Attacking Mozilla for following standard security procedures for bugs is fucking childish.
Slashdot Mirror
http://gltrs.grc.nasa.gov/reports/2005/TM-2005-21
Also, the dust is far from a constant size, and is far more abrasive than you'll find here on earth, due to a lack of erosion mechanisms on the moon.
But, again, you need the machines to do the mining. I'm not convinced yet that we'll be able to get enough materials out of the moon to make any base mechanically self-sufficient...I think the dust will tear up any mining machinery faster than it will be able to provide any base with replacement parts. In that situation, the moon is no better than L5...there may be materials there, but we can't get them out easily.
(Note: I admit that I'm extrapolating from just a few facts, but given the state of the lunar rover and other stuff from the Apollo missions, I don't think I'm completely off base. I could still be wrong, but I'd like to see how.)
Why do it in a gravitational well at all? As I mentioned in a different post, L5's a far better place to do that assembly...it's almost 0g, and a far weaker gravitational well.
Though it pains me to ask this (I'd love for us to be doing more space exploration), is building a base there really a good idea? From what I've read, the lunar dust is incredibly hard on mechanical things (gears, seals, etc)...that would make maintenance of any lunar base very difficult, and prohibitively expensive.
For all of that effort (both in the initial build, and in the launch/materials costs for maintenance)...what do we get? Not much, even in terms of science.
I'd love for us to do more space exploration, but honestly, I think a really big station at L4 or L5 would be a much better idea. Locally stable gravitiational point, but not a deep gravity well, far less dust, very low g environment, etc.
It's not as sexy as the moon, but really...L5's the place to be, not the moon.
Debian will release stable...oh, wait.
Imagine a society where an orchestra couldn't play any classical music without acquiring the rights to that performance from a copyright holder that has been passed down through the centuries by inane copyright law and they end up paying a large amount of money for you to enjoy their performance.
That's already happening. Last time I checked, it was very difficult to get permission to perform "Eine Kleine Nichtmusik", a joke classical music piece, because Peter Schickele (the composer, aka PDQ Bach) was being a bastard about making sure people did it "right."
yes, knoppix can read ntfs. I've used knoppix to recover from trashed WINNT directories before...works fine.
On the other hand, if you're looking to deploy a Linux box (which is happening a lot in the government), and there's "free" (as in, already paid for by another division) support for SUSE, that makes the distro choice very easy, and makes the management justification part easy as well.
Mostly, I think this will have the effect of slowly unifying the distro choice at HHS & NIH to SUSE. Linux is already happenning, this just makes the deployment more orderly.
I think "perfectly working" is a bit of a stretch. It loads, doesn't crash, and displays video and audio...fair enough. If you want them to sync up, though, you're out of luck.
Macromedia isn't showing much interest in making their Linux client much better (why should they?), so this effort is a perfectly reasonable one, I think.
from here, which is the 802.11p spec (TFA says they're using 11p), it's got a range of 1000 meters, or 1km. No idea where the 30 stuff came from.
I disagree...if they can really pull off 30 miles, that's a big deal (that covers big parts of most major metro areas), especially to radio.
Morning and evening drive-time are the biggest money-makers for radio (it's almost the only time many people listen to the radio anymore). If you give people the ability to stream indie feeds into their cars, drive-time suddenly gets much more competitive, especially if your cost to stream to cars approaches zero.
My only concern is: who's allowed to be a stream source? Anyone? Or just certain "approved" bodies? If it's anyone, I'm there.
Segfaults are no problem...config files, on the other hand, are a huge mess in Gentoo. I can't tell you the number of times I've had to manually tweak something after emerge decided that the config file for a given app needed a different format. (or, just for fun, they re-named an app...vcron vs vixie-cron, for example...very annoying)
Gentoo's fun for desktops and experimenting stations...but I shouldn't have to do that much constant tweaking on a server. Once I switched my servers to Deb, I fear not the "apt-get upgrade"...it won't break my config files.
Aside from the language stuff, I don't think these conclusions are unique to Africa. If you remove the phrase "in Africa" from each bullet point, you could have a very believable set of statements about lots of places. (this is also a bit of a blueprint to show where FOSS has holes that need to be filled.)
I really don't envy the guy whose job it is to put the diapers on the cows...ick.
This isn't a battle-type situation (though we keep using war terminology). It's more like a biological infection model...the "infection" (OSS use) starts in areas where the system isn't fighting it, and spreads as it's able to find new undefended areas. It won't eliminate all resistance, but it can spread quite far, if virulent enough. The question is, are we virulent enough yet?
And it would cost them at least 4x as much (in resources, salaries, etc).
How much is not hating a solution worth, if the mediocre solution gets the job done? Is not hating the program worth several programmer's salaries? Most companies would answer no. Things have to be *really* bad before the cost to the company is worth more staff to fix. That's why they don't roll their own.
The fact that they hate these programs just means that they have very little loyalty to them. If another program comes along that works better (or convinces the PHB's that it does), they'll switch.
On the other hand, there are some things that every (or at least many) companies are doing, like HR, payroll management, finances, inventory management, etc...why should everyone re-invent the wheel? There *should* be some value in off-the-shelf software for common tasks. It's just that it all sucks.
If anyone can build an OSS payroll/finance system that *works* and you can get support for...it'll take over corporations very quickly. Everyone I've talked to *hates* the one they've got presently.
And the problem, as the GP post pointed out, is that folks will even mark those confirmation requests as spam...not much a legit list can do in that case, except talk to the ISP, but you have to know it's happening first.
Have a look at the site: only the arin contact, postmaster@ or abuse@ are going to be able to get these stats. Customers, spammers (who don't own the IP space they're querying) and regular joe's are not going to be given this by MS (at least, not in this rev...we'll see what the future holds)
Spammers? probably not. But, the ISPs that are running mailing lists will. (Ie legitimate mail, not spam) I know a couple folks at my office are curious to see this, just to see how much of our mailing list traffic is getting dumped by a big provider.
(before you all start, yes, they're opt-in, and they're limited subject lists anyway, so there's no reason to spam with them.)
ummm....not that I'm disagreeing with you, but McVoy didn't write Subversion. SVN's an open-source project much like Arch, Monotone, etc. McVoy did Bitkeeper.
(just doing fact-checking....we now return you to your normally scheduled slashdot discussion)
News flash: this sort of coordination is already happening. The reason this is even a story is because Mozilla is breaking the norm. If there weren't a norm of cooperation, no one would care that Mozilla was going their own way. But, since they are breaking the norm, people are unhappy.
Have a look at BugTraq, FullDisclosure or other vuln discussion lists. When someone posts a vulnerability without notifying the vendor/author there are *very* snarky comments made about the responsibility of the post. The same thing happens when an (major) app releases a security fix without notifying the major distros.
Communication isn't optional anymore. Neither are the "coordinators" that you loathe.
You left out a variable: time. Releasing early widens the amount of time that the users relying on the distro for the patch are vulnerable. There is tons of evidence that vulnerabilities are attacked more after release of a patch, or announcement of a vulnerability. (Not to say it doesn't happen before, just that it happens *more* afterwards.)
So, it's in the general interest to get as many people patched *quickly* once the public announcement is made. Vendor patch systems are the best way to do that.
I disagree. Completely. It's in the general interest of everyone for the app writers and the distros to work together...the goal, after all, is for the end user to get patches quickly, effectively, and *before* there's an exploit. A lot of the distros have central patch distribution systems...these systems are the best way to get patches to the end user for that distro.
If an app releases a bug fix without working with the distro, it leaves the end user there to get screwed...either they wait for their distro to get the patch put together (running vulnerable code the whole time), or they break their use of the patch distribution system (meaning they have to either re-patch once the vendor releases, or never follow the vendor patch system for that app again). This isn't a choice we want to be giving the users. The best result is *absolutely* a coordinated response, where the authors, the distros and the original reporter of the problem all release simultaneously.
That isn't possible in this case, since there's no distro to work with for Windows. Mozilla is, in this situation, choosing to minimize the risk for their Windows users (who likely far outnumber their OSS users), at the expense of the distro coordination. It's not a fun choice to make, but a sensible one, given their situation.
I shouldn't respond to this troll, but I will.
Marking security-related bugs as secret is entirely appropriate. If the bug notes were public, they would serve as a blueprint to 0-day attacks on Mozilla, which the Moz folks are (rightly) attempting to prevent.
Attacking Mozilla for following standard security procedures for bugs is fucking childish.