'How toxic is this "Galinstan" compared to mercury?'
Not very toxic at all. That is kind of THE POINT in replacing mercury in thermometers, after all.
From the MSDS Inhalation: The extremely low vapor pressure of Galinstan makes absorption through inhalation negligible. Ingestion: No adverse health effect has been observed or reported. Galinstan passes through the digestive system without effect. Skin: Skin oils may be reduced through continuous contact. Eyes: Direct contact with the surface of the eye may cause irritation. Eye protection is recommended when potential direct eye contact is possible.
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
A bunch of niche OSs that you've never heard of, including Flex/OS, CPM/386, Coherent, and probably a few others. A fair number of embedded systems use at least the segmented memory model to some advantage, either in a custom OS, or within the application itself.
Using a segmented address space, where the Stack and Code are kept in what are effectively different address spaces, would do much to mitigate the effect of buffer overruns. On the other hand, the NX bit on x86-64 accomplishes basically the same thing, without the overhead of having to use long pointers to access data on the stack.
Neither of them are really all that robust though, since any time you can overwrite the return address on the stack, you can cause execution to veer off to somewhere else. Maybe you won't be able to insert shellcode into the program's address space, but if you can cause a function to "return" to something in the C standard library, like remove(), you can still cause havoc.
A more secure solution would split the stack such that function arguments and return addresses are not stored in the same space. This would give you a somewhat Forth-like runtime model, where return addresses are stored on one stack, and data values on the other. In that case, a buffer overrun in one function would still allow you to overwrite the arguments to another function, which is sub-optimal.
If you combine a split stack with growing the stack in the non-obvious direction, then you're probably as secure as you're going to get without eliminating the use of a stack altogether.
You can't have multiple System folders on the same partition anymore (not since Mac OS X 10.0). That's one advantage the old Mac OS had over the new one. On the other hand, multiple OS versions on different partitions works fine.
"when you take a small mass of radioactive material that gives off lethal amounts of radiation and spread it over a large geographic area you cannot get a lethal exposure. "
It really doesn't work that way. Highly-radioactive chunks of metal of various sizes hit the ground after Cosmos 954 crashed. Several of them could have delivered a lethal dose to a person whio handled them without proper protection.
Here's one reference And another reference That talk about the potential lethality of some of the recovered fragments from the satellite. Keep in mind that nobody knows how many of the fragments that hit the ground were actually recovered.
I checked on a current-revision G5, and the reserved bits are still ignored. No big deal, really, but it would have made it slightly harder to write shellcode.
I read through the shellcode example article again (thanks for the link by the way, I was going to look it up again for another project anyway), and I don't see how this is a problem that can really be solved, at least not by Apple.
There is always more than one way to get basically any value you might want loaded into the proper registers. Once the registers are loaded, there's a single instruction that's used to initiate a system call, the "sc" instruction.
The opcode for "sc" ALREADY includes two embedded NULs, so it looks like somebody was more-or-less on the ball there (or just lucky). Unfortunately, current PPC processors don't object if any of the "reserved, set to zero" bits in the instruction are actually set to one.
This is arguably a processor misfeature, and something that Freescale/IBM might want to look at changing in later processors. Actually, I should check this on the G5 - it's the kind of thing that easily could have changed without anybody remarking on it.
I can think of a couple of possible hacky things the OS could do to post-facto validate the code leading up to the sc instruction, but I suspect that'd be very bad for syscall performance. If I get the time, maybe I'll build myself a hacked Darwin kernel and play around with the idea a bit more.
Unfortunately, the first validation measure that came to my mind is easily worked around, so you're back in the usual technical arms race with the bad guys. The only bright spot there is that every additional step the shellcode needs to take makes it longer and more brittle. I wonder if you can make it adequately painful to write shellcode without totally tanking syscall performance?
In any case, as you noted, fixing the case of ASCII-only shellcode is only going to close down some of the available buffer-overflow exploits, not all of them.
"Is there actually any way to compare the life times of alkaline batteries with NiMHs?"
Sure. NiMH batteries will be dead in about a month or so from self-discharge. If the battery is to be used in an application where the current draw is low enough for that to be the dominant factor, then use non-rechargeable lithium batteries (or alkaline, if lithium cells aren't available in that size). Otherwise, use NiMH.
If you're not sure what the current draw of a particular application is, buy some cheap alkalines and put them in. If you still remember why you were doing the test when they go dead, replace them with rechargeable NiMHs. If you just look at them and think "why the hell did I put cheap alkaline batteries in here?", replace them with non-rechargeable lithium cells.
I am not aware of ANY applications for which alkaline batteries are the best technology - unless someone else is paying for the batteries, of course, which is why cheap alkalines are what comes with your $2.00 flashlight.
"What would make sense to me is mount some decent solar panels on a Prius, I haven't seen anyone do this yet."
I looked into this a bit, and the math doesn't look good. You can probably fit a few hundred watts (maybe 2x 175W) worth of solar panels on the top of the Prius.
If your Prius is parked outside your office for 8 hours a day in full sunlight, that's a maximum of (8 hours * 350 watts) = 2.8 Kilowatt-hours. The actual energy production would be half that, at best (the sun isn't always directly overhead). So figure your solar production at 1.4 KWh per day.
Gasoline is about 36 KWh per gallon, so each day, you'd be saving 0.039 Gallons of gas, which would have cost you about 8 cents.
Keeping in mind that those solar panels cost nearly $1500, not including the custom battery charger you'd need for the Prius' high voltage battery, it really doesn't seem worth it.
If you live 5 miles away from work, like I do, that'd change your mileage from 60MPG to 78MPG. Actually, that's not too bad, if you ignore the startup costs:-) On the other hand, if you have a 40-mile round-trip commute, you gain more like 4MPG.
"If they can get all the info they need from your credit card and check then why do they need the member card to idnetify you anyhow?"
Well, for one thing, the member card provides a link between credit card purchases (which have your personal info) and cash purchases (which would normally be anonymous). If you even once use a credit/debit card with your member card all of your previous and future purchases with that member card are then related to your name & address.
"All I can think of is that somehow the act of getting a member card is an authorization for them to collect that information."
Yes, among other things. Not that anybody ever reads these agreements, but it also gives them the right to sell your name and address, usually.
I can see the guy's point - the company he worked for has made probably many many millions of dollars off that invention. On the other hand, he signed a contract to work for them that didn't include any promises of profit-sharing on things he invented for them.
The contract I'm currently working under actually specifies that I'll get a (relatively small) bonus for any patented technology I develop. If the company made zillions of dollars off one of my ideas, I'd be surprised if they gave me a million dollars for it.
One additional complication that comes in is where do you draw the line? I'm sure more than just this one guy contributed to this invention. Should they all get millions of dollars? What about the guys in marketing and sales, where's their million-dollar bonus?
Assuming by "normal" you meant LED's, there isn't any way to make an LED out of Silicon. As far as I know, there are three mechanisms for producing light emiting devices from Silicon: 1. This method. 2. A poorly-understood process involving nanoscale emitters and electron tunneling (which only works in the lab, so far). 3. You can build an incandescent element out of Silicon:-)
Not a popular sentiment with the Slashdot crowd, I'm sure, but "because it would be cool" isn't a good reason to send people to Mars. Learning more about the universe we live in is a noble goal, but sending a small group of people to Mars as primarily a publicity stunt is a colossal waste of money.
Neither is it reasonable to suggest that a colony on Mars would be good "insurance" against a global catastrophe, as one loony did above. We are so far away from being able to build a self-supporting colony on Mars that it's laughable.
Nearly all of the money that NASA has spent on "human exploration" programs since the 1970's has been wasted. Some of the research on the effects of micro-gravity on human physiology are worthwhile, and need to be done IF long-term manned space missions are going to be considered. Unfortunately, the USSR (and later Russian) government was doing essentially the same research at the same time, for orders of magnitude less money.
The choice isn't necessarily between space research and social programs, although I'd argue that investing in affordable higher education for all qualified students would do much more to advance the state of human knowledge than a mission to Mars ever would.
The choice is between spending billions of dollars on keeping "astronauts" in space for PR reasons, rather than focussing NASA on basic research into the "hard problems" of space exploration.
NASA needs to focus more on basic research into self-contained environmental systems, better telerobotics/telepresence, more-sophisticated onboard intelligence for robotic spacecraft & rovers, automated materials processing, etc. All these things are prerequisites to getting people "out there" for a period of time where they might actually be able to accomplish something useful.
If they dropped support for the International Space Station and just de-orbited it into the sea, they could USE the money they saved on maintaining that albatross, and on re-fitting the Shuttle fleet, to increase basic research activity by several orders of magnitude.
There's nothing that would be accomplished by sending humans to Mars that couldn't be achieved more simply and vastly cheaper by a flotilla of robots.
You don't know much about DVD or CD recording, do you? Look up the terms CAV and CVL. All pressed DVD's and CD's are recorded with a constant linear velocity. This means that the spindle motor actually varies in speed depending on where on the disk you're reading.
I don't think I'd say that DVD's rotate at a "very low" RPM. At 1x speeds, a DVD rotates at about 1500 RPM at the outside edge. A computer DVD player can get up to over 10k RPM. That's pretty insane for a little plastic disk and a precision laser assembly that needs to sit very near the surface of the disk.
I'd think that physical damage to the inside of the player is very possible, even at the low end of the speed range.
The only time lack of synchronization would be a problem is if you were in a location where you could hear both sets of speakers at approximately equal volume. Then you'd hear some funky audio effects, I'm sure.
Given how slow the speed of sound is, though, you'll have real problems with that anytime you have speakers that are more than a few meters apart, anyway - even if you're driving them from the same amplifier.
Downloading music from Zazaa while demonizing somebody else for stealing source-code from Valve is intensely hypocritical. So I don't do that (download music off the Net).
Anybody who makes their living off of creative work (art, programming, music, science) will, if they think about for a minute, realize that illegal file-swapping represents a real threat to their financial well-being.
Having said that, I expect the vast majority of Slashdot readers are not actually working programmers, despite the "New for Nerds" tagline of the website. Based on the comments you'll often see attached to discussions on Slashdot, the majority of these comment authors are students, or just folks that like to play with their computers as a hobby. Having never had a financial interest in a creative work, they're probably not as aware of the contradictory nature of their positions.
I know I stand firmly on the "artists's rights" sides of both debates. Since I make my living as a software writer, it'd be more than a little hypocritical of me to
"Assuming Joe Seller has copied the CD, under fair use, can he keep his copy when he sells the original?"
No. Copyright law allows you to make copies *of recordings you own* for your own use. If you sell the original, then by definition, you don't own it any more, and therefore have no right to create or keep copies of it.
"What If someone steals my physical CD but I still have my high-quality MP3 on my player? Did my right to the MP3 get stolen too?"
No, again. You still "own" that CD, even if it's not still in your possession. That's what makes the copy the thief has "stolen". So, you still have a right to create and keep copies of the CD. Now, being able to prove that you have the right to that copy is going to be pretty hard if you don't have any evidence that you bought the CD.
Slashdot Mirror
'How toxic is this "Galinstan" compared to mercury?'
Not very toxic at all. That is kind of THE POINT in replacing mercury in thermometers, after all.
From the MSDS
Inhalation: The extremely low vapor pressure of Galinstan makes absorption through inhalation negligible.
Ingestion: No adverse health effect has been observed or reported. Galinstan passes through the digestive system without effect.
Skin: Skin oils may be reduced through continuous contact.
Eyes: Direct contact with the surface of the eye may cause irritation. Eye protection is recommended when potential direct eye contact is possible.
So don't take a bath in it or anything.
-Mark
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
-Mark
"The PowerPC stack grows downwards as well"
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
-Mark
"So what OS uses it at all?"
A bunch of niche OSs that you've never heard of, including Flex/OS, CPM/386, Coherent, and probably a few others. A fair number of embedded systems use at least the segmented memory model to some advantage, either in a custom OS, or within the application itself.
-Mark
Using a segmented address space, where the Stack and Code are kept in what are effectively different address spaces, would do much to mitigate the effect of buffer overruns. On the other hand, the NX bit on x86-64 accomplishes basically the same thing, without the overhead of having to use long pointers to access data on the stack.
Neither of them are really all that robust though, since any time you can overwrite the return address on the stack, you can cause execution to veer off to somewhere else. Maybe you won't be able to insert shellcode into the program's address space, but if you can cause a function to "return" to something in the C standard library, like remove(), you can still cause havoc.
A more secure solution would split the stack such that function arguments and return addresses are not stored in the same space. This would give you a somewhat Forth-like runtime model, where return addresses are stored on one stack, and data values on the other. In that case, a buffer overrun in one function would still allow you to overwrite the arguments to another function, which is sub-optimal.
If you combine a split stack with growing the stack in the non-obvious direction, then you're probably as secure as you're going to get without eliminating the use of a stack altogether.
-Mark
You can't have multiple System folders on the same partition anymore (not since Mac OS X 10.0). That's one advantage the old Mac OS had over the new one. On the other hand, multiple OS versions on different partitions works fine.
--Mark
"when you take a small mass of radioactive material that gives off lethal amounts of radiation and spread it over a large geographic area you cannot get a lethal exposure. "
It really doesn't work that way. Highly-radioactive chunks of metal of various sizes hit the ground after Cosmos 954 crashed. Several of them could have delivered a lethal dose to a person whio handled them without proper protection.
Here's one reference
And another reference
That talk about the potential lethality of some of the recovered fragments from the satellite. Keep in mind that nobody knows how many of the fragments that hit the ground were actually recovered.
I checked on a current-revision G5, and the reserved bits are still ignored. No big deal, really, but it would have made it slightly harder to write shellcode.
I read through the shellcode example article again (thanks for the link by the way, I was going to look it up again for another project anyway), and I don't see how this is a problem that can really be solved, at least not by Apple.
There is always more than one way to get basically any value you might want loaded into the proper registers. Once the registers are loaded, there's a single instruction that's used to initiate a system call, the "sc" instruction.
The opcode for "sc" ALREADY includes two embedded NULs, so it looks like somebody was more-or-less on the ball there (or just lucky). Unfortunately, current PPC processors don't object if any of the "reserved, set to zero" bits in the instruction are actually set to one.
This is arguably a processor misfeature, and something that Freescale/IBM might want to look at changing in later processors. Actually, I should check this on the G5 - it's the kind of thing that easily could have changed without anybody remarking on it.
I can think of a couple of possible hacky things the OS could do to post-facto validate the code leading up to the sc instruction, but I suspect that'd be very bad for syscall performance. If I get the time, maybe I'll build myself a hacked Darwin kernel and play around with the idea a bit more.
Unfortunately, the first validation measure that came to my mind is easily worked around, so you're back in the usual technical arms race with the bad guys. The only bright spot there is that every additional step the shellcode needs to take makes it longer and more brittle. I wonder if you can make it adequately painful to write shellcode without totally tanking syscall performance?
In any case, as you noted, fixing the case of ASCII-only shellcode is only going to close down some of the available buffer-overflow exploits, not all of them.
-Mark
"Is there actually any way to compare the life times of alkaline batteries with NiMHs?"
Sure. NiMH batteries will be dead in about a month or so from self-discharge. If the battery is to be used in an application where the current draw is low enough for that to be the dominant factor, then use non-rechargeable lithium batteries (or alkaline, if lithium cells aren't available in that size). Otherwise, use NiMH.
If you're not sure what the current draw of a particular application is, buy some cheap alkalines and put them in. If you still remember why you were doing the test when they go dead, replace them with rechargeable NiMHs. If you just look at them and think "why the hell did I put cheap alkaline batteries in here?", replace them with non-rechargeable lithium cells.
I am not aware of ANY applications for which alkaline batteries are the best technology - unless someone else is paying for the batteries, of course, which is why cheap alkalines are what comes with your $2.00 flashlight.
-Mark
"What would make sense to me is mount some decent solar panels on a Prius, I haven't seen anyone do this yet."
:-) On the other hand, if you have a 40-mile round-trip commute, you gain more like 4MPG.
I looked into this a bit, and the math doesn't look good. You can probably fit a few hundred watts (maybe 2x 175W) worth of solar panels on the top of the Prius.
If your Prius is parked outside your office for 8 hours a day in full sunlight, that's a maximum of (8 hours * 350 watts) = 2.8 Kilowatt-hours. The actual energy production would be half that, at best (the sun isn't always directly overhead). So figure your solar production at 1.4 KWh per day.
Gasoline is about 36 KWh per gallon, so each day, you'd be saving 0.039 Gallons of gas, which would have cost you about 8 cents.
Keeping in mind that those solar panels cost nearly $1500, not including the custom battery charger you'd need for the Prius' high voltage battery, it really doesn't seem worth it.
If you live 5 miles away from work, like I do, that'd change your mileage from 60MPG to 78MPG. Actually, that's not too bad, if you ignore the startup costs
-Mark
"If you ask for the BWX every morning in your third transmission, your COMSEC is shot to hell no matter how often to change the cods."
Please explain to me again how a fish can be used to secure communications?
"If they can get all the info they need from your credit card and check then why do they need the member card to idnetify you anyhow?"
Well, for one thing, the member card provides a link between credit card purchases (which have your personal info) and cash purchases (which would normally be anonymous). If you even once use a credit/debit card with your member card all of your previous and future purchases with that member card are then related to your name & address.
"All I can think of is that somehow the act of getting a member card is an authorization for them to collect that information."
Yes, among other things. Not that anybody ever reads these agreements, but it also gives them the right to sell your name and address, usually.
I can see the guy's point - the company he worked for has made probably many many millions of dollars off that invention. On the other hand, he signed a contract to work for them that didn't include any promises of profit-sharing on things he invented for them.
The contract I'm currently working under actually specifies that I'll get a (relatively small) bonus for any patented technology I develop. If the company made zillions of dollars off one of my ideas, I'd be surprised if they gave me a million dollars for it.
One additional complication that comes in is where do you draw the line? I'm sure more than just this one guy contributed to this invention. Should they all get millions of dollars? What about the guys in marketing and sales, where's their million-dollar bonus?
-Mark
Assuming by "normal" you meant LED's, there isn't any way to make an LED out of Silicon. As far as I know, there are three mechanisms for producing light emiting devices from Silicon: :-)
1. This method.
2. A poorly-understood process involving nanoscale emitters and electron tunneling (which only works in the lab, so far).
3. You can build an incandescent element out of Silicon
-Mark
At which point, it'll finally have reached feature parity with EMACS.
-Mark
Not a popular sentiment with the Slashdot crowd, I'm sure, but "because it would be cool" isn't a good reason to send people to Mars. Learning more about the universe we live in is a noble goal, but sending a small group of people to Mars as primarily a publicity stunt is a colossal waste of money.
Neither is it reasonable to suggest that a colony on Mars would be good "insurance" against a global catastrophe, as one loony did above. We are so far away from being able to build a self-supporting colony on Mars that it's laughable.
Nearly all of the money that NASA has spent on "human exploration" programs since the 1970's has been wasted. Some of the research on the effects of micro-gravity on human physiology are worthwhile, and need to be done IF long-term manned space missions are going to be considered. Unfortunately, the USSR (and later Russian) government was doing essentially the same research at the same time, for orders of magnitude less money.
The choice isn't necessarily between space research and social programs, although I'd argue that investing in affordable higher education for all qualified students would do much more to advance the state of human knowledge than a mission to Mars ever would.
The choice is between spending billions of dollars on keeping "astronauts" in space for PR reasons, rather than focussing NASA on basic research into the "hard problems" of space exploration.
NASA needs to focus more on basic research into self-contained environmental systems, better telerobotics/telepresence, more-sophisticated onboard intelligence for robotic spacecraft & rovers, automated materials processing, etc. All these things are prerequisites to getting people "out there" for a period of time where they might actually be able to accomplish something useful.
If they dropped support for the International Space Station and just de-orbited it into the sea, they could USE the money they saved on maintaining that albatross, and on re-fitting the Shuttle fleet, to increase basic research activity by several orders of magnitude.
There's nothing that would be accomplished by sending humans to Mars that couldn't be achieved more simply and vastly cheaper by a flotilla of robots.
-Mark
You don't know much about DVD or CD recording, do you? Look up the terms CAV and CVL. All pressed DVD's and CD's are recorded with a constant linear velocity. This means that the spindle motor actually varies in speed depending on where on the disk you're reading.
I don't think I'd say that DVD's rotate at a "very low" RPM. At 1x speeds, a DVD rotates at about 1500 RPM at the outside edge. A computer DVD player can get up to over 10k RPM. That's pretty insane for a little plastic disk and a precision laser assembly that needs to sit very near the surface of the disk.
I'd think that physical damage to the inside of the player is very possible, even at the low end of the speed range.
These folks might be able to help with plans for long-term backups of WikiPedia content.
-Mark
The only time lack of synchronization would be a problem is if you were in a location where you could hear both sets of speakers at approximately equal volume. Then you'd hear some funky audio effects, I'm sure.
Given how slow the speed of sound is, though, you'll have real problems with that anytime you have speakers that are more than a few meters apart, anyway - even if you're driving them from the same amplifier.
-Mark
The CF form-factor hard drive in the iPod mini doesn't work in (most?) cameras. Something's different about the firmware on the drive, I guess.
More details here
-Mark
Like I was saying...
Downloading music from Zazaa while demonizing somebody else for stealing source-code from Valve is intensely hypocritical. So I don't do that (download music off the Net).
Anybody who makes their living off of creative work (art, programming, music, science) will, if they think about for a minute, realize that illegal file-swapping represents a real threat to their financial well-being.
Having said that, I expect the vast majority of Slashdot readers are not actually working programmers, despite the "New for Nerds" tagline of the website. Based on the comments you'll often see attached to discussions on Slashdot, the majority of these comment authors are students, or just folks that like to play with their computers as a hobby. Having never had a financial interest in a creative work, they're probably not as aware of the contradictory nature of their positions.
Or they're just jerks...
-Mark
I know I stand firmly on the "artists's rights" sides of both debates. Since I make my living as a software writer, it'd be more than a little hypocritical of me to
"Assuming Joe Seller has copied the CD, under fair use, can he keep his copy when he sells the original?"
No. Copyright law allows you to make copies *of recordings you own* for your own use. If you sell the original, then by definition, you don't own it any more, and therefore have no right to create or keep copies of it.
"What If someone steals my physical CD but I still have my high-quality MP3 on my player? Did my right to the MP3 get stolen too?"
No, again. You still "own" that CD, even if it's not still in your possession. That's what makes the copy the thief has "stolen". So, you still have a right to create and keep copies of the CD. Now, being able to prove that you have the right to that copy is going to be pretty hard if you don't have any evidence that you bought the CD.
-Mark