It is all so amazing and we must realize that any theories we come up with will never be able to describe things as a whole. It is basically the universe trying to understand itself...when it already knows. Dang....now I am getting into Zen philosophy so I will jsut shut up becasue I don't know where this is leading towards.
Have you read Heisenberg's "Physics and Philosophy?"
The major problem people are having with QM, the reason this "Zen" thing keeps coming up, is that QM says something incredibly strange about the world: the results of any experiment or measurement are inextricably tied up with the very act of measurement. QM seems to shatter the idea that an objective universe exists independently of the observer.
What QM is trying to tell us is that there is no way to actually draw a line between observer and observed. That's why people always bring up Zen (or Buddhism in general), since one of its major philosophical principles is that the separation between self and universe is an illusion.
Sounds like a good way to reduce land fill space. Just pulverize everything to the molecular level shake and let settle.
Two reasons that would be really stupid: first, the amount of energy it would take is enormous. The energy is probably coming from a fossil-fuel power plant, so you're contributing to CO2 emissions.
Second, breaking up the organic material in the landfill would speed up biological activity (more surface area for the bacteria to grow on), leading to a huge increase in methane production in the short term (methane is also a greenhouse gas). I wouldn't want to be anywhere near such a landfill with a lit cigarette...
Since this scheme causes in-game objects to have real material value, wouldn't selling or trading such objects between players be subject to sales tax? E.g., I'm a player in Michigan, and I sell a valuable item to another player who also lives in Michigan. Do I owe the state of Michigan sales tax?
What if I trade an object worth $0.19 for an object worth $0.22 (suppose the other guy thought this trade was worth it for some reason). Is this trade subject to capital gains tax?
It seems like throwing "real" money in makes the whole thing a lot more complicated and less fun, since real money implies real rules and laws governing what you can and can't do.
What is the power consumption of these systems? What a waste of cheap electricity.
Actually, I thought a piece of hardware would last longer the fewer times you power cycle it. Turn it off, boards cool down and contract. Turn it back on, things warm up and expand again. This might eventually lead to contacts wearing out as they rub against the slots, traces cracking, etc...
In theory power cycling a machine every day could lead to its untimely death (as in, it might have last longer if left powered up all the time). I've never seen any hard evidence of this, either way, though.
You use a hybrid stack. You push two kinds of objects onto this stack: environment frames and cleanup frames. When you use the TRY macro to open a new exception frame, you push an environment frame onto the stack. This frame includes a jmp_buf struct which is filled in by a call to setjmp(). If an exception is thrown, control will transfer back via longjmp(), using this jmp_buf.
Then, as you allocate memory, open files, lock mutexes, or whatever, you register cleanup functions with another macro. This pushes a cleanup frame onto the stack indicating a function to call along with a single argument.
Then, if an exception is thrown, you just pop cleanup frames off the stack and execute them, until you hit an environment frame. At that point you call longjmp() to transfer control to the user-code exception handler, inside the CATCH macro block. That user code can choose to do cleanup or error recovery, or it can THROW again and continue propagating the exception up the stack.
Figuring out how to implement the TRY, CATCH, ENDCATCH, and THROW macros is fun, so I won't give away exactly how to do it. It's simple, and involves a creative use of a do-while statement.
Regardless of who is "in charge", our government is fucked. Not fucked beyond the point of no return, but fucked none the less.
The frightening thing is, it could be fucked beyond the point of no return. What if this insanity continues for 25 years? An entire generation of people will have grown up, from birth, under this "New America." They won't even UNDERSTAND what the older people are talking about when they talk about freedom of speech, freedom of religion, the Fifth Amendment, or any of those things. And if an entire generation of people in this country have lost their sense of freedom and liberty then the whole idea of America as it was will be lost forever.
We need to stop what is happening in this country, and we need to stop it NOW.
This is what my "data stack" is trying to fix and do it fully portably. And alloca() still can't be used to allocate return values from it, which I think is the most useful feature gained by using data stack. I don't know about you, but I use a lot of functions that need to return dynamically allocated memory.
I'm not seeing the difference between your data stack and a memory pool, except that you can divide it into frames which you can collectively pop off, and free entire contexts at once. But by making the data stack independent of the call stack, you introduce the possibility of the two getting out of sync. A context frame should probably always map to a single function invocation. Or to put it another way, a data frame pushed in a particular function call should always be popped by that same function call. And that kind of defeats the purpose of being able to return stack-allocated data UP the call stack.
In contrast alloca() is a simple manipulation of the hardware stack pointer, which will be automatically undone by the hardware itself at the end of the call frame (on any sane architecture, that is). There's no possiblity for abuse.
Any strlcat(), strlcpy(), etc. don't solve the underlying problem in all string operations, which is making sure you always have enough room. They prevent overflows, but they can still truncate data without you realizing it's happened. Unless you check first. See my other
comment.
Truncating string copies are always wrong, no matter whether you use them correctly.
What if the result would be bigger than the output buffer? strncat() does the "right" thing, and doesn't overflow the buffer. But your string just got truncated! That's probably bad. So, suppose you check for this problem, by examining the string lengths beforehand. You verify that the result will fit, and not be truncated.
But now that you've gone to that trouble, and you know that the result will fit, why bother with the strncat()? Since you already know there is no overflow, you can go ahead and use the (faster) function strcat().
Now, in order to avoid these problems, you might write your own string concatenation function, that first computes the total size needed for the result, allocates it, and then copies the strings into this new buffer. Now, the issue of buffer ownership comes up, and you introduce a new class of possible bugs: memory leaks.
The fact is, in any non-garbage-collected language like C, string handling is a pain in the ass. The problem runs deep, and can't be solved by any quick hack like strlcat().
It's a good start at a HOWTO, but needs some serious fleshing out. These are common tricks that most serious, experienced C programmers have in their bag.
Some of my personal favorites include:
Exceptions in C. You can get quite natural-looking exception handling in C, with some convoluted macros. I'm sure most hardcore C coders have come up with their own implementations. Many security bugs happen in parts of the code that handle errors, precisely because errors are rare, and those parts of the code don't get tested well. Using a unified, exception-driven approach to error handling can cut down the risks. IF you do it right.
The alloca() function. This allocates memory directly off the stack, which is freed when the function returns. Very useful for cases where you want a stack buffer but aren't sure how big it needs to be. Like any other stack buffer, you need to take care not to overflow it. There are portability concerns with this function, but it can still be useful.
Variable-sized block-chained allocators, which pull chunks of memory out of preallocated segments. The segments are chained together in a linked list. Very effective when you need to make a lot of variable-sized allocations, and do it fast, dammit. It also makes freeing the allocated memory blazingly fast, although it's a "free all or none" approach.
"Hardened" allocators, which allocate blocks in multiples of the page size, and set memory protections in such a way that buffer overruns cause crashes. This is the easiest way to prevent ANY kind of buffer overrun vulnerability, but wastes memory. See Electric Fence.
Look people.. It takes a keen eye and major discipline to write secure C code. It is not impossible. You have to get in the habit of subconsciously checking yourself at EVERY turn. "Am I accessing a stack variable? Am I doing it CORRECTLY?"
DISCIPLINE, DISCPLINE, DISCIPLINE. I fully expect to see the usual barrage of comments to the tune of: "C is outdated, insecure, brittle, yadda yadda..." No. Some PROGRAMMERS are "outdated, insecure, and brittle."
The C language doesn't write bugs. Programmers write bugs. If the programmer can't handle C, then take it away from him. But don't try to take it away from ME.
It makes sense for them to nip this thing before that happens. Legislation, software filters, whatever...
You mention "legislation" and "software filters" together, as if they were equally good options. But they're in completely different universes!
Software filters allow us fine-grained control over what mail we will and will not receive/forward through mail servers and clients. A software solution keeps power in our hands.
Legislation to stop spam would give the government power to control the content of email messages sent over the Internet. Now, the government has the last word on what is and is not legal. Not us.
WTF is this? It's bad enough having to compete for a job with people who flat-out lie. Now am I going to lose out just because some dickhead spammed more buzzwords around his resume?
Dude, seriously... Don't sweat it. Why would you ever want to work at a company where recruitment and hiring is performed by a computer?
In other words, if some stupid company hires Joe Blow because his resume contains six more occurrences of "PHP" than yours, do you really want to work there? Imagine what your new boss would be like...
Note that the printed Domesday Book, on which the digital project was modeled, is still quite accessible after almost 1000 years.
Not really. Even if I could understand the language, I still can't search it with regular expressions, automatically create indexes, incorporate it in a knowledge base, read it out loud through a speech synthesizer, or anything else useful.
Printed material is nice for reading, but reading alone doesn't imply accessibility.
That really is quite funny. I think we've hit on a new tech-term: counterprogramming - noun - to use the front-end of a software program to perform operations with which the backend program should have been able to do in the first place.
Good first cut, but I think a better definition would be:
counterprogramming - mitigating the erroneous behavior of a computer system by applying unusual or inconsistent inputs; counteracting the effect of badly designed software by placing the system in a state where the malfunctioning component is disabled or overridden, usually via specially designed inputs
No shit, Sherlock. We're all aware that/. editors post repeats, and that the problem is getting worse. We see it for ourselves, and we hear about it ad nauseum from twerps like yourself who are looking for a quick, cheap karma boost. Your comment is not insightful or informative. It is irritating and wasteful. STFU already.
And to the moderators: shame on you for falling for such an obvious whoring technique.
Did any of you actually read the article? They've chosen particular isotopes which emit only beta radiation, because beta radiation cannot penetrate the skin (well, ok, high-energy betas can, but I assume they've chosen isotopes that produce low-energy betas). Beta radiation is composed of fast electrons -- that's it!
I would definitely be cautious using a battery like this, but I wouldn't be automatically opposed to trying it. Besides, if lots of radiation was leaking out of this thing, then that would be a pretty inefficient battery, wouldn't it?
I have always been under the impression that for part 15 devices that the power is given in mv/m.
mV/m is not power. It is electric field strength. The power is proportional to the square of the field, so (mV/m)^2 is (proportional to) power.
Of course, since this is an EM wave, mV/m is actually an RMS value, and (mV/m)^2 is actually the average power. And of course it's not power that matters, but the power density, otherwise known as irradiance. That would be measured in mV^2/m^3. And of course there's also power spectral density, measured in watt-seconds.
Assume that in order to break a 109-bit keyspace you need to try half of the keys. In other words, you need to try 2^108 keys. They managed to do this in 4 years. This gives a base rate (rate as of now) of 8.11e31 keys/year.
Since we assume computing speed increases exponentially, doubling every 18 months, we need to multiply this base rate by 2^(t/1.5), where t is the time in years from the present date. This gives a keyrate of 8.11e31*2^(t/1.5) keys/year at time t.
Now, we want to break a 163-bit keyspace. Again, we assume we need to try half the keys, so we need to try a total of 2^162 keys. We integrate the rate from time t=0..x on the left, and equate that to 2^162. This gives the equation:
err not to say the first guy was right but 2^54 !=54......
and if thats not what you meant then could you reexplain it?
It's precisely what I meant. Each bit doubles the number of operations. Computer speeds double every 18 months. Therefore, for computer speeds to double 54 times (in order to keep up with the keyspace doubling in size, 54 times), you need 54*18 months.
Yes yes, I appreciate your calculus, but we're talking rough estimates here:) And that would only apply if your computer smoothly transitioned and somehow became faster and faster at the rate of Moore's law.
In any case, it's certainly different from billions of aeons!
What I don't understand is why spoofing is possible at all. Can't your uplink router just take a look at your spoofed packet and decide, "Well crap, there's no way in HELL a legitimate packet from THAT IP address could have come from THIS interface, so I'll just drop it on the floor."
Ok, so you can still spoof the addresses of other people on your segment (or possibly subnet, if you are using dumb switches), but shouldn't routers be able to figure out when packets are OBVIOUSLY bogus?
If your primary concern is tabbed browsing, why not just use Opera in the interim, while Mozilla gets a little stabler? It's really not hard to simply ignore the little ad banner at the upper-right of the free Opera copy. It's not like we aren't exposed to twenty thousands ads every day anyway...
Of course, if you like Opera I suggest purchasing a copy.
The record companies seem to be trying to drive people into getting so pissed off at the lot of them, that they actually do stop buying albums in the store. This way they can get new legal remedies passed.
How the hell is this going to work? If I'm pissed now, I'll be even more pissed when they pass laws. How is this going to cause me to GIVE THEM MY MONEY?! What exactly do they expect, something like this?
Me: "I'm pissed. I can't play CDs in my computer anymore!"
BMG: "FOAD, you worthless consumer. I've bought out politicians who will make your entire computer ILLEGAL!"
Slashdot Mirror
Have you read Heisenberg's "Physics and Philosophy?"
The major problem people are having with QM, the reason this "Zen" thing keeps coming up, is that QM says something incredibly strange about the world: the results of any experiment or measurement are inextricably tied up with the very act of measurement. QM seems to shatter the idea that an objective universe exists independently of the observer.
What QM is trying to tell us is that there is no way to actually draw a line between observer and observed. That's why people always bring up Zen (or Buddhism in general), since one of its major philosophical principles is that the separation between self and universe is an illusion.
Why is Rational considering a sale to another corporation, anyway? Do they just need a boost, or are they a sinking ship?
Two reasons that would be really stupid: first, the amount of energy it would take is enormous. The energy is probably coming from a fossil-fuel power plant, so you're contributing to CO2 emissions.
Second, breaking up the organic material in the landfill would speed up biological activity (more surface area for the bacteria to grow on), leading to a huge increase in methane production in the short term (methane is also a greenhouse gas). I wouldn't want to be anywhere near such a landfill with a lit cigarette...
What if I trade an object worth $0.19 for an object worth $0.22 (suppose the other guy thought this trade was worth it for some reason). Is this trade subject to capital gains tax?
It seems like throwing "real" money in makes the whole thing a lot more complicated and less fun, since real money implies real rules and laws governing what you can and can't do.
Actually, I thought a piece of hardware would last longer the fewer times you power cycle it. Turn it off, boards cool down and contract. Turn it back on, things warm up and expand again. This might eventually lead to contacts wearing out as they rub against the slots, traces cracking, etc...
In theory power cycling a machine every day could lead to its untimely death (as in, it might have last longer if left powered up all the time). I've never seen any hard evidence of this, either way, though.
Just curious. I live near Portland myself.
You use a hybrid stack. You push two kinds of objects onto this stack: environment frames and cleanup frames. When you use the TRY macro to open a new exception frame, you push an environment frame onto the stack. This frame includes a jmp_buf struct which is filled in by a call to setjmp(). If an exception is thrown, control will transfer back via longjmp(), using this jmp_buf.
Then, as you allocate memory, open files, lock mutexes, or whatever, you register cleanup functions with another macro. This pushes a cleanup frame onto the stack indicating a function to call along with a single argument.
Then, if an exception is thrown, you just pop cleanup frames off the stack and execute them, until you hit an environment frame. At that point you call longjmp() to transfer control to the user-code exception handler, inside the CATCH macro block. That user code can choose to do cleanup or error recovery, or it can THROW again and continue propagating the exception up the stack.
Figuring out how to implement the TRY, CATCH, ENDCATCH, and THROW macros is fun, so I won't give away exactly how to do it. It's simple, and involves a creative use of a do-while statement.
The frightening thing is, it could be fucked beyond the point of no return. What if this insanity continues for 25 years? An entire generation of people will have grown up, from birth, under this "New America." They won't even UNDERSTAND what the older people are talking about when they talk about freedom of speech, freedom of religion, the Fifth Amendment, or any of those things. And if an entire generation of people in this country have lost their sense of freedom and liberty then the whole idea of America as it was will be lost forever.
We need to stop what is happening in this country, and we need to stop it NOW.
I'm not seeing the difference between your data stack and a memory pool, except that you can divide it into frames which you can collectively pop off, and free entire contexts at once. But by making the data stack independent of the call stack, you introduce the possibility of the two getting out of sync. A context frame should probably always map to a single function invocation. Or to put it another way, a data frame pushed in a particular function call should always be popped by that same function call. And that kind of defeats the purpose of being able to return stack-allocated data UP the call stack.
In contrast alloca() is a simple manipulation of the hardware stack pointer, which will be automatically undone by the hardware itself at the end of the call frame (on any sane architecture, that is). There's no possiblity for abuse.
Any strlcat(), strlcpy(), etc. don't solve the underlying problem in all string operations, which is making sure you always have enough room. They prevent overflows, but they can still truncate data without you realizing it's happened. Unless you check first. See my other comment.
What if the result would be bigger than the output buffer? strncat() does the "right" thing, and doesn't overflow the buffer. But your string just got truncated! That's probably bad. So, suppose you check for this problem, by examining the string lengths beforehand. You verify that the result will fit, and not be truncated.
But now that you've gone to that trouble, and you know that the result will fit, why bother with the strncat()? Since you already know there is no overflow, you can go ahead and use the (faster) function strcat().
Now, in order to avoid these problems, you might write your own string concatenation function, that first computes the total size needed for the result, allocates it, and then copies the strings into this new buffer. Now, the issue of buffer ownership comes up, and you introduce a new class of possible bugs: memory leaks.
The fact is, in any non-garbage-collected language like C, string handling is a pain in the ass. The problem runs deep, and can't be solved by any quick hack like strlcat().
Some of my personal favorites include:
- Exceptions in C. You can get quite natural-looking exception handling in C, with some convoluted macros. I'm sure most hardcore C coders have come up with their own implementations. Many security bugs happen in parts of the code that handle errors, precisely because errors are rare, and those parts of the code don't get tested well. Using a unified, exception-driven approach to error handling can cut down the risks. IF you do it right.
- The alloca() function. This allocates memory directly off the stack, which is freed when the function returns. Very useful for cases where you want a stack buffer but aren't sure how big it needs to be. Like any other stack buffer, you need to take care not to overflow it. There are portability concerns with this function, but it can still be useful.
- Variable-sized block-chained allocators, which pull chunks of memory out of preallocated segments. The segments are chained together in a linked list. Very effective when you need to make a lot of variable-sized allocations, and do it fast, dammit. It also makes freeing the allocated memory blazingly fast, although it's a "free all or none" approach.
- "Hardened" allocators, which allocate blocks in multiples of the page size, and set memory protections in such a way that buffer overruns cause crashes. This is the easiest way to prevent ANY kind of buffer overrun vulnerability, but wastes memory. See Electric Fence.
Look people.. It takes a keen eye and major discipline to write secure C code. It is not impossible. You have to get in the habit of subconsciously checking yourself at EVERY turn. "Am I accessing a stack variable? Am I doing it CORRECTLY?"DISCIPLINE, DISCPLINE, DISCIPLINE. I fully expect to see the usual barrage of comments to the tune of: "C is outdated, insecure, brittle, yadda yadda..." No. Some PROGRAMMERS are "outdated, insecure, and brittle."
The C language doesn't write bugs. Programmers write bugs. If the programmer can't handle C, then take it away from him. But don't try to take it away from ME.
You mention "legislation" and "software filters" together, as if they were equally good options. But they're in completely different universes!
Software filters allow us fine-grained control over what mail we will and will not receive/forward through mail servers and clients. A software solution keeps power in our hands.
Legislation to stop spam would give the government power to control the content of email messages sent over the Internet. Now, the government has the last word on what is and is not legal. Not us.
Which option would you rather take?
Dude, seriously... Don't sweat it. Why would you ever want to work at a company where recruitment and hiring is performed by a computer?
In other words, if some stupid company hires Joe Blow because his resume contains six more occurrences of "PHP" than yours, do you really want to work there? Imagine what your new boss would be like...
Not really. Even if I could understand the language, I still can't search it with regular expressions, automatically create indexes, incorporate it in a knowledge base, read it out loud through a speech synthesizer, or anything else useful.
Printed material is nice for reading, but reading alone doesn't imply accessibility.
Good first cut, but I think a better definition would be:
counterprogramming - mitigating the erroneous behavior of a computer system by applying unusual or inconsistent inputs; counteracting the effect of badly designed software by placing the system in a state where the malfunctioning component is disabled or overridden, usually via specially designed inputs
Good enough for the Hacker dictionary?
So which way was it done? It's been so long since I used DOS, and I don't think I ever piped more than a few hundred bytes of data, ever...
No shit, Sherlock. We're all aware that /. editors post repeats, and that the problem is getting worse. We see it for ourselves, and we hear about it ad nauseum from twerps like yourself who are looking for a quick, cheap karma boost. Your comment is not insightful or informative. It is irritating and wasteful. STFU already.
And to the moderators: shame on you for falling for such an obvious whoring technique.
I would definitely be cautious using a battery like this, but I wouldn't be automatically opposed to trying it. Besides, if lots of radiation was leaking out of this thing, then that would be a pretty inefficient battery, wouldn't it?
mV/m is not power. It is electric field strength. The power is proportional to the square of the field, so (mV/m)^2 is (proportional to) power.
Of course, since this is an EM wave, mV/m is actually an RMS value, and (mV/m)^2 is actually the average power. And of course it's not power that matters, but the power density, otherwise known as irradiance. That would be measured in mV^2/m^3. And of course there's also power spectral density, measured in watt-seconds.
Yes, this sure does get confusing fast...
Assume that in order to break a 109-bit keyspace you need to try half of the keys. In other words, you need to try 2^108 keys. They managed to do this in 4 years. This gives a base rate (rate as of now) of 8.11e31 keys/year.
Since we assume computing speed increases exponentially, doubling every 18 months, we need to multiply this base rate by 2^(t/1.5), where t is the time in years from the present date. This gives a keyrate of 8.11e31*2^(t/1.5) keys/year at time t.
Now, we want to break a 163-bit keyspace. Again, we assume we need to try half the keys, so we need to try a total of 2^162 keys. We integrate the rate from time t=0..x on the left, and equate that to 2^162. This gives the equation:
1.76e32*exp(0.462*x)-1.76e32 = 5.85e48.
Solving this for x yields x = 82.33 years.
Quite close to the original estimate.
It's precisely what I meant. Each bit doubles the number of operations. Computer speeds double every 18 months. Therefore, for computer speeds to double 54 times (in order to keep up with the keyspace doubling in size, 54 times), you need 54*18 months.
Yes yes, I appreciate your calculus, but we're talking rough estimates here :) And that would only apply if your computer smoothly transitioned and somehow became faster and faster at the rate of Moore's law.
In any case, it's certainly different from billions of aeons!
Ok, so you can still spoof the addresses of other people on your segment (or possibly subnet, if you are using dumb switches), but shouldn't routers be able to figure out when packets are OBVIOUSLY bogus?
If Moore's law holds up that long, I'll eat my hat.
Of course, if you like Opera I suggest purchasing a copy.
How the hell is this going to work? If I'm pissed now, I'll be even more pissed when they pass laws. How is this going to cause me to GIVE THEM MY MONEY?! What exactly do they expect, something like this?
Me: "I'm pissed. I can't play CDs in my computer anymore!"
BMG: "FOAD, you worthless consumer. I've bought out politicians who will make your entire computer ILLEGAL!"
Me: "Gee, I really really want a CD now!"