And since we haven't discovered how the neuron depends on quantum mechanics to work (like how we've discovered how chloroplasts do just this past year), we need more physics too.
I'm not saying you're wrong, but that's a really, really bad argument. It basically boils down to "we don't completelly understand neurons, therefore we can't possibly build an intelligence that's at least as good as one based on neurons".
You have already given an example of why exactly it's a bad argument. We've only recently discovered how quantum effects play an important role in photosynthesis[1], but that didn't prevent us from building photoelectric cells that turn sunlight into usable energy (more efficiently than plants, by the way) before that.
The point is that we have no reason to believe that we'll have to to mimic neurons closely in order to build an AI. Other people already pointed that we have built things that work better than the human body (even though we don't completely understand the human body), and your answer has so far been "mechanical things are simple". That's a huge cop out: they're "simple" because they've been done -- can you imagine convincing a physicist from the 1700s that building a flying machine is simple?
Now, maybe AI is really not "simple" like that, maybe it's actually impossible without closely mimicking a neuron -- but nothing in your argument gives any reason to believe that.
Footnote [1]: I know the studies that have shown the quantum effects on photosynthesis by some bacteria, but nothing that uses chloroplasts. Do you have a source, or were you just referring to photosynthesis in general? (I'm not trying to be pedantic, I'd be really interested to read about studies like these in more advanced forms of photosynthesis).
That's a fair point, but you have to pay closer attention to what Carmack wrote:
I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.
He said functional programming style, that doesn't necessarily mean using a functional language -- the point is that he is going in the direction of functional style when writing C++, which would involve, among other things, making as much as possible immutable (hence being a "const nazi").
It's sad that this is modded so high; it's completely wrong.
A requests a secure channel to B from C. Instead C establishes a secure channel with A *claiming* that it's B, while also establishing a secure channel to B claiming that it's A.
You're describing a MITM attack, which is prevented by SSL and TLS by using certificates -- C can only fool A into thinking it's B if C knows B's private key (in which case, C has essentially stolen B's identity).
What happens in Nokia phone's case is that the browser happily trusts C to forward things to B without looking at what's being transmitted (the browser accepts C's certificate authority).
I think he's using the term "watered-down" to mean something like "with increased volume", but of course the usual meaning (what you find in the dictionary) is exactly the opposite: "diminished in force or effect".
There is absolutely no value in having random people review things.
Any sufficiently articulate reviewer can give me very valuable insight that helps me decide whether I'll likely enjoy a science fiction book from an author I've never read, for example.
You might have a point for reviews that are meant to deeply analyze high literature works. For most books sold on Amazon, what you wrote doesn't apply at all.
If you read the second link in the comment that started this thread, you'll see that
On average, elite male soccer players -- who often use their heads to direct the ball -- had a range of negative changes in white matter architecture compared with a group of competitive swimmers who were unlikely to have repetitive brain trauma
I think they picked the control group from professional athletes because they are more likely to have similar lifestyles. Even so, the authors of the study are cautious and note that
differences in head injury rates, sudden accelerations, or even lifestyle could contribute
So, like MightyMartian said, obviously researchers do their homework, otherwise their papers would be ridiculed during peer-review.
It's undeniable that microkernels open very cool possibilities, like the ones you mentioned.
But my first point was that, every time someone makes a microkernel that has to compete with the kernels we have today, they end up doing all kinds of compromises ("hybrid" approaches) which end up with all sorts of drivers (network, disk, graphics) in kernel space. Anything else just slows things down too much, to the point where very few people would want to use those kernels.
And, to be honest, while the kinds of things you mention would be useful, crashes in drivers for mainstream hardware are very rare, so there's very little practical reason to try too much to mitigate their effects. Unless, of course, you count gaming graphics cards (their drivers do tend to crash a lot) -- but in this case, trading a lot of performance (and if you remove the graphics driver from kernel space you do lose a lot of performance) for the ability to recover from a crash is really not what you want.
a kernel mode component can crash the system and leave no trace of what did it. Like pre X MacOS or DOS.
... and Linux, NT, and the Mac OS X kernel (XNU).
NT and the Mac OS X kernels are interesting cases: they started as microkernels, but soon moved on to "hybrid" approaches that keep a lot of drivers inside kernel space.
Everybody knows mircrokernels are slower. They are more stable. Misbehaving drivers are identified quickly. They usually have fewer issues and the issues they have don't take the whole system down.
That sounds great in theory, but if a disk or network driver crashes on a production server, how much do you care that the rest of the system is still working? These things must not crash, period -- if they do crash, the state of the rest of the system is usually irrelevant.
That's great to know, thanks! I look forward to more varied insults.
An #include influences the linker just in the most trivial sense that it changes the code seen by the compiler, and so it changes the compiled code seen by the linker. The point is that there's nothing magical about "stdio.h" that requires one to #include it; everything that can be done with #includes can be done without them. I keep repeating this point because I'm still not sure you understand it.
You at least *did* realize that your previous point about code compiling but not linking is complete and utter nonsense, right?
Ah, so you've finally realized you're wrong, and now are resorting to ad-hominem attacks...
That's fine, as long as we're clear that it is possible to write any C program as a one-liner, and #include is just a text-processing directive that doesn't influence the linker.
One more time: #include does exactly what I said: it just includes a file verbatim (I can't believe you haven't taken the time to check this, after all this time in this discussion). This means that, after you resolved all #includes, you can then proceed to put the contents of that result in one line, ant the result will be a one-line program. If the original program compiled and linked, then the one-liner also will, by construction.
Now, to the point of missing struct declarations:
If I am trying to link to something that takes a pointer to a struct and I don't include the headers for it, the linker won't work. So, with it the linker succeeds and without it it doesn't.
In your specific example, it will either fail during compilation or during execution, never at link time. That's because the information about return and argument types is gone by the time the linker runs (it might be present on debug sections of the object files, but the linker doesn't care about those). So, if the compiler is happy with the struct declarations, the linker will happily work -- even though the result might be undefined and crash during execution.
What happens when your function returns something other than int and you don't declare it first?
What happens is undefined behavior, according to the standard. But now you're changing your story.
In response to my examples (both of which are completely valid and contain no undefined behavior), you wrote nonsense like "It might compile, but it won't link, ergo it's not a valid program". Now you're trying to sound as you were talking about general programs.
The whole point is that #include does nothing magical that influences the linker. It's *exactly* the same as inserting a file verbatim at the #include point. Which means you don't *need* any #includes in C (in particular, they're not required by the linker). Ergo[1] it's possible to write any C program in one line, keeping in mind the limitation about the minimum line length the translator is required to accept, which I explained earlier.
OK, now it's clear that you have absolutely no idea what you're talking about -- you might want to read the C standard, or at least test it on a compiler.
If you're interested to learn, here's a general explanation:
The function declarations usually present in header files just tell the compiler what are the parameters accepted by the function, and what is the function return value. In C (not C++), these declarations are not required. If a function with no declaration is called, the compiler/interpreter/whatever uses an "implicit declaration" -- most compilers will give a warning saying that's what they're doing. An implicit declaration assumes that the function returns an int and receives the arguments that were passed in the call, with some promotions: for example, char is converted to int, float is converted to double, and so on (I don't remember all of the promotions rules, and I can't be bothered looking them up).
An #include directive has nothing to do with the linker, except in some non-standard extensions by compilers (e.g. Visual Studio has the #pragma comment(lib, "library.lib"), which tells the linker to link with "library.lib") which are found on some header files.
Note that some header files have more than just function declarations -- some also define macros (e.g. NULL). If you use them, you *must* include the header or define the macros yourself (e.g., #define NULL (void*)0): macros don't have an "implicit declaration". Of course, you might just expand the macros yourself (e.g., use (void*)0 instead of NULL): in this case, you obviously don't need to include the header.
It might generate a warning on some compilers, but it's a perfectly valid C program. In fact, since this program uses rand without declaration, it might as well use printf.
Nothing prevents one from doing this, though:
int rand(void); int printf(const char * restrict f,...); main() { ten: printf("%c", (rand()%2)?47:92); goto ten; }
(Remove the "restrict" before "f" for C89)
In general, though, ISO C doesn't require translators (the technical name the ISO uses for C compilers/interpreters) to accept lines greater than some limit (509 in ISO C89, 4095 in ISO C99), so technically it's debatable whether it's possible to write every C program as a one-liner: you *could*, but a compiler might correctly not accept it.
If everything at the quantum level always worked the same way forwards as it does backwards, then entropy would be constant; the universe would be in some kind of steady state and nothing would matter because we wouldn't be here.
That's not true. "Everything at the quantum level always working the same way forwards and backwards" is completely consistent with the second law of thermodynamics ("entropy never decreases"), and completely consistent with the observable universe (barring CP violation). All that's necessary is that the universe started with very low entropy -- like, say, the Big Bang.
See for example this from this Arrow of Time FAQ (from cosmologist Sean Carroll):
The observed macroscopic irreversibility is not a consequence of the fundamental laws of physics, it's a consequence of the particular configuration in which the universe finds itself. In particular, the unusual low-entropy conditions in the very early universe, near the Big Bang. Understanding the arrow of time is a matter of understanding the origin of the universe.
And a legitimate question: is the conversion rate constant?
It's exponential, following the formulax(t)=x(0)*(1/2)^(t/h), where h is the half life, x(t) is the amount left at time t and x(0) is the initial amount -- you can see that at time t=h (that is, after an amount of time equal to the half-life), you have x(h)=x(0)*(1/2)^1, that is, the half the initial amount is left.
Note that this is a statistical property. Each atom has a fixed probability to decay at every instant; but if you have a lot of atoms, the behavior of the "population" is fairly predictable.
If these are the only changes you want, then it's sufficient to change the current system so that:
1) an infringement can never prevent anyone from offering any products or services; and
2) licensing and punitive damages are set by designated experts (e.g. the USPTO).
These things are completely orthogonal to deciding who gets to pay for inventions -- i.e., the people who buy the products originating from inventions (the current system) versus the people who pay for the independent fund that finances inventors (your proposed system).
Of course, we still need a Patent bureau and a system to manage claims and the proper registrations of inventions. The system should be able to determine the usefulness and popularity of an invention and how much work went into researching and creating the invention. It should also be as automated as possible.
It seems to me that this system would have exactly the same problem we have today: that is, to determine whether if a particular device uses a particular invention. Except that, in your proposal, this information would be used to determine how much compensation the inventor receives. So, it doesn't solve the problem of patent trolls at all, it just changes who feeds the patent trolls (in your system, it would be whoever gives money to the independent fund, i.e., everyone).
If a kid wants to be an auto mechanic for the rest of his life, then let hem learn about that. If they're into business, then let them take the courses about business.
A kid doesn't have enough experience to decide what he wants to do for the rest of his life. The more you let people specialize at young age, the harder is for them to change their minds and pursue different interests later on.
There's nothing wrong with letting kids choose a few specialized classes (and that's done today, to a certain extent), but letting them decide they don't want to take any science classes (or writing classes, etc.) is an incredibly bad idea.
But this is what everybody keeps forgetting: it isn't just a timing (distance) signal. You have more information than that. The relative positions of the satellites themselves are known.
Did you see the paper I linked? It uses exactly this idea (the relative positions of the satellites) to do the calculations, completely eliminating the need to worry about time. Still, this reduces the number of equations from 4 (one for each satellite, involving position and time) to 3 (involving only position). But if you begin with only 3 satellites, you end up with 2 equations involving only position, which consists of 3 variables (x,y,z). So, I still don't understand how you can calculate the position of the receiver with only 3 satellites.
About differential GPS: from what I understand, you still need 4 satellites in addition to the ground station. The ground station just broadcasts the difference between the signals received from the satellites and the signals you'd get if there were absolutely no errors (it can do that because it knows its exact location and also the trajectories of the satellites). This information can then be used by GPS receivers to correct their readings and improve accuracy. That's still not perfect, because the corrections are exact only at the exact position of the ground station; so the farther you are from the station, the worse the correction gets (still, Wikipedia suggests that the corrections are still useful hundreds of miles away from the ground station).
It's interesting to note that initially, differential GPS was used to completely bypass the signal degradation that was built in the GPS system (the satellites used to intentionally introduce random errors in their time signals, a "feature" called "selective availability"). The differential GPS correction was so successful that "selective availability" became pointless, and in 2000 the US decided to stop degrading the GPS signal.
Right, in practice it doesn't matter. In practice, there are all lots of sources of errors, and if you try to naively solve the system of equations I wrote, you'll find no exact answer, because of these errors. And that's not even considering that, depending on the relative positions of the satellites, the equations might not even be independent (e.g. if all satellites are in the same plane, which is very unlikely, but can happen). The best you can do is to find the best approximation (i.e., the point that most closely satisfies the equations). A good way to do that is discussed in the paper I linked to.
I don't understand what you're trying to say; all the signals are received at exactly the same time (which I called t). If you receive the signals at different times, than the whole thing doesn't work, because then the relative positions of the satellites will have changed -- and the whole point is to use the relative positions of the satellites to determine your position.
As for the rest of what you wrote: no amount of manipulation on the equations can change the fact that you have only 3 independent equations and 4 variables. Any equation you derive by manipulating the initial equations (by substituting variables, etc.) will not be independent, so it changes nothing.
But if you want to play with GPS equations, I suggest reading the paper I linked to. It has the equations that are actually used by GPS devices; what I wrote is a simplified version just to show an overview of how the process works.
Slashdot Mirror
I'm not saying you're wrong, but that's a really, really bad argument. It basically boils down to "we don't completelly understand neurons, therefore we can't possibly build an intelligence that's at least as good as one based on neurons".
You have already given an example of why exactly it's a bad argument. We've only recently discovered how quantum effects play an important role in photosynthesis[1], but that didn't prevent us from building photoelectric cells that turn sunlight into usable energy (more efficiently than plants, by the way) before that.
The point is that we have no reason to believe that we'll have to to mimic neurons closely in order to build an AI. Other people already pointed that we have built things that work better than the human body (even though we don't completely understand the human body), and your answer has so far been "mechanical things are simple". That's a huge cop out: they're "simple" because they've been done -- can you imagine convincing a physicist from the 1700s that building a flying machine is simple?
Now, maybe AI is really not "simple" like that, maybe it's actually impossible without closely mimicking a neuron -- but nothing in your argument gives any reason to believe that.
Footnote [1]: I know the studies that have shown the quantum effects on photosynthesis by some bacteria, but nothing that uses chloroplasts. Do you have a source, or were you just referring to photosynthesis in general? (I'm not trying to be pedantic, I'd be really interested to read about studies like these in more advanced forms of photosynthesis).
That's a fair point, but you have to pay closer attention to what Carmack wrote:
He said functional programming style, that doesn't necessarily mean using a functional language -- the point is that he is going in the direction of functional style when writing C++, which would involve, among other things, making as much as possible immutable (hence being a "const nazi").
It's sad that this is modded so high; it's completely wrong.
You're describing a MITM attack, which is prevented by SSL and TLS by using certificates -- C can only fool A into thinking it's B if C knows B's private key (in which case, C has essentially stolen B's identity).
What happens in Nokia phone's case is that the browser happily trusts C to forward things to B without looking at what's being transmitted (the browser accepts C's certificate authority).
Yes, I found that extremely confusing.
I think he's using the term "watered-down" to mean something like "with increased volume", but of course the usual meaning (what you find in the dictionary) is exactly the opposite: "diminished in force or effect".
On Amazon, that's already possible; just click on the name of the author of the review.
Any sufficiently articulate reviewer can give me very valuable insight that helps me decide whether I'll likely enjoy a science fiction book from an author I've never read, for example.
You might have a point for reviews that are meant to deeply analyze high literature works. For most books sold on Amazon, what you wrote doesn't apply at all.
If you read the second link in the comment that started this thread, you'll see that
I think they picked the control group from professional athletes because they are more likely to have similar lifestyles. Even so, the authors of the study are cautious and note that
So, like MightyMartian said, obviously researchers do their homework, otherwise their papers would be ridiculed during peer-review.
It's undeniable that microkernels open very cool possibilities, like the ones you mentioned.
But my first point was that, every time someone makes a microkernel that has to compete with the kernels we have today, they end up doing all kinds of compromises ("hybrid" approaches) which end up with all sorts of drivers (network, disk, graphics) in kernel space. Anything else just slows things down too much, to the point where very few people would want to use those kernels.
And, to be honest, while the kinds of things you mention would be useful, crashes in drivers for mainstream hardware are very rare, so there's very little practical reason to try too much to mitigate their effects. Unless, of course, you count gaming graphics cards (their drivers do tend to crash a lot) -- but in this case, trading a lot of performance (and if you remove the graphics driver from kernel space you do lose a lot of performance) for the ability to recover from a crash is really not what you want.
... and Linux, NT, and the Mac OS X kernel (XNU).
NT and the Mac OS X kernels are interesting cases: they started as microkernels, but soon moved on to "hybrid" approaches that keep a lot of drivers inside kernel space.
That sounds great in theory, but if a disk or network driver crashes on a production server, how much do you care that the rest of the system is still working? These things must not crash, period -- if they do crash, the state of the rest of the system is usually irrelevant.
That's great to know, thanks! I look forward to more varied insults.
An #include influences the linker just in the most trivial sense that it changes the code seen by the compiler, and so it changes the compiled code seen by the linker. The point is that there's nothing magical about "stdio.h" that requires one to #include it; everything that can be done with #includes can be done without them. I keep repeating this point because I'm still not sure you understand it.
You at least *did* realize that your previous point about code compiling but not linking is complete and utter nonsense, right?
Ah, so you've finally realized you're wrong, and now are resorting to ad-hominem attacks...
That's fine, as long as we're clear that it is possible to write any C program as a one-liner, and #include is just a text-processing directive that doesn't influence the linker.
One more time: #include does exactly what I said: it just includes a file verbatim (I can't believe you haven't taken the time to check this, after all this time in this discussion). This means that, after you resolved all #includes, you can then proceed to put the contents of that result in one line, ant the result will be a one-line program. If the original program compiled and linked, then the one-liner also will, by construction.
Now, to the point of missing struct declarations:
In your specific example, it will either fail during compilation or during execution, never at link time. That's because the information about return and argument types is gone by the time the linker runs (it might be present on debug sections of the object files, but the linker doesn't care about those). So, if the compiler is happy with the struct declarations, the linker will happily work -- even though the result might be undefined and crash during execution.
What happens is undefined behavior, according to the standard. But now you're changing your story.
In response to my examples (both of which are completely valid and contain no undefined behavior), you wrote nonsense like "It might compile, but it won't link, ergo it's not a valid program". Now you're trying to sound as you were talking about general programs.
The whole point is that #include does nothing magical that influences the linker. It's *exactly* the same as inserting a file verbatim at the #include point. Which means you don't *need* any #includes in C (in particular, they're not required by the linker). Ergo[1] it's possible to write any C program in one line, keeping in mind the limitation about the minimum line length the translator is required to accept, which I explained earlier.
That's very funny, you gave me a good laugh!
[1] I can try to sound smart, too :)
OK, now it's clear that you have absolutely no idea what you're talking about -- you might want to read the C standard, or at least test it on a compiler.
If you're interested to learn, here's a general explanation:
The function declarations usually present in header files just tell the compiler what are the parameters accepted by the function, and what is the function return value. In C (not C++), these declarations are not required. If a function with no declaration is called, the compiler/interpreter/whatever uses an "implicit declaration" -- most compilers will give a warning saying that's what they're doing. An implicit declaration assumes that the function returns an int and receives the arguments that were passed in the call, with some promotions: for example, char is converted to int, float is converted to double, and so on (I don't remember all of the promotions rules, and I can't be bothered looking them up).
An #include directive has nothing to do with the linker, except in some non-standard extensions by compilers (e.g. Visual Studio has the #pragma comment(lib, "library.lib"), which tells the linker to link with "library.lib") which are found on some header files.
Note that some header files have more than just function declarations -- some also define macros (e.g. NULL). If you use them, you *must* include the header or define the macros yourself (e.g., #define NULL (void*)0): macros don't have an "implicit declaration". Of course, you might just expand the macros yourself (e.g., use (void*)0 instead of NULL): in this case, you obviously don't need to include the header.
It might generate a warning on some compilers, but it's a perfectly valid C program. In fact, since this program uses rand without declaration, it might as well use printf.
Nothing prevents one from doing this, though:
int rand(void); int printf(const char * restrict f, ...); main() { ten: printf("%c", (rand()%2)?47:92); goto ten; }
(Remove the "restrict" before "f" for C89)
In general, though, ISO C doesn't require translators (the technical name the ISO uses for C compilers/interpreters) to accept lines greater than some limit (509 in ISO C89, 4095 in ISO C99), so technically it's debatable whether it's possible to write every C program as a one-liner: you *could*, but a compiler might correctly not accept it.
I think the point is: why should the government pay for whatever the hell parents want to teach their kids?
That's not true. "Everything at the quantum level always working the same way forwards and backwards" is completely consistent with the second law of thermodynamics ("entropy never decreases"), and completely consistent with the observable universe (barring CP violation). All that's necessary is that the universe started with very low entropy -- like, say, the Big Bang.
See for example this from this Arrow of Time FAQ (from cosmologist Sean Carroll):
The observed macroscopic irreversibility is not a consequence of the fundamental laws of physics, it's a consequence of the particular configuration in which the universe finds itself. In particular, the unusual low-entropy conditions in the very early universe, near the Big Bang. Understanding the arrow of time is a matter of understanding the origin of the universe.
It's exponential, following the formula x(t)=x(0)*(1/2)^(t/h), where h is the half life, x(t) is the amount left at time t and x(0) is the initial amount -- you can see that at time t=h (that is, after an amount of time equal to the half-life), you have x(h)=x(0)*(1/2)^1, that is, the half the initial amount is left.
Note that this is a statistical property. Each atom has a fixed probability to decay at every instant; but if you have a lot of atoms, the behavior of the "population" is fairly predictable.
Yeah so my point still stands. Next time save yourself the time and effort in posting.
I completely disagree. He offered relevant information and clarified what the law says. Even if it doesn't invalidate your point, it's a good post.
Discussion is not about winning arguments, it's about exchanging ideas to better understand things.
If these are the only changes you want, then it's sufficient to change the current system so that:
1) an infringement can never prevent anyone from offering any products or services; and
2) licensing and punitive damages are set by designated experts (e.g. the USPTO).
These things are completely orthogonal to deciding who gets to pay for inventions -- i.e., the people who buy the products originating from inventions (the current system) versus the people who pay for the independent fund that finances inventors (your proposed system).
Of course, we still need a Patent bureau and a system to manage claims and the proper registrations of inventions. The system should be able to determine the usefulness and popularity of an invention and how much work went into researching and creating the invention. It should also be as automated as possible.
It seems to me that this system would have exactly the same problem we have today: that is, to determine whether if a particular device uses a particular invention. Except that, in your proposal, this information would be used to determine how much compensation the inventor receives. So, it doesn't solve the problem of patent trolls at all, it just changes who feeds the patent trolls (in your system, it would be whoever gives money to the independent fund, i.e., everyone).
If a kid wants to be an auto mechanic for the rest of his life, then let hem learn about that. If they're into business, then let them take the courses about business.
A kid doesn't have enough experience to decide what he wants to do for the rest of his life. The more you let people specialize at young age, the harder is for them to change their minds and pursue different interests later on.
There's nothing wrong with letting kids choose a few specialized classes (and that's done today, to a certain extent), but letting them decide they don't want to take any science classes (or writing classes, etc.) is an incredibly bad idea.
But this is what everybody keeps forgetting: it isn't just a timing (distance) signal. You have more information than that. The relative positions of the satellites themselves are known.
Did you see the paper I linked? It uses exactly this idea (the relative positions of the satellites) to do the calculations, completely eliminating the need to worry about time. Still, this reduces the number of equations from 4 (one for each satellite, involving position and time) to 3 (involving only position). But if you begin with only 3 satellites, you end up with 2 equations involving only position, which consists of 3 variables (x,y,z). So, I still don't understand how you can calculate the position of the receiver with only 3 satellites.
About differential GPS: from what I understand, you still need 4 satellites in addition to the ground station. The ground station just broadcasts the difference between the signals received from the satellites and the signals you'd get if there were absolutely no errors (it can do that because it knows its exact location and also the trajectories of the satellites). This information can then be used by GPS receivers to correct their readings and improve accuracy. That's still not perfect, because the corrections are exact only at the exact position of the ground station; so the farther you are from the station, the worse the correction gets (still, Wikipedia suggests that the corrections are still useful hundreds of miles away from the ground station).
It's interesting to note that initially, differential GPS was used to completely bypass the signal degradation that was built in the GPS system (the satellites used to intentionally introduce random errors in their time signals, a "feature" called "selective availability"). The differential GPS correction was so successful that "selective availability" became pointless, and in 2000 the US decided to stop degrading the GPS signal.
Right, in practice it doesn't matter. In practice, there are all lots of sources of errors, and if you try to naively solve the system of equations I wrote, you'll find no exact answer, because of these errors. And that's not even considering that, depending on the relative positions of the satellites, the equations might not even be independent (e.g. if all satellites are in the same plane, which is very unlikely, but can happen). The best you can do is to find the best approximation (i.e., the point that most closely satisfies the equations). A good way to do that is discussed in the paper I linked to.
I don't understand what you're trying to say; all the signals are received at exactly the same time (which I called t). If you receive the signals at different times, than the whole thing doesn't work, because then the relative positions of the satellites will have changed -- and the whole point is to use the relative positions of the satellites to determine your position.
As for the rest of what you wrote: no amount of manipulation on the equations can change the fact that you have only 3 independent equations and 4 variables. Any equation you derive by manipulating the initial equations (by substituting variables, etc.) will not be independent, so it changes nothing.
But if you want to play with GPS equations, I suggest reading the paper I linked to. It has the equations that are actually used by GPS devices; what I wrote is a simplified version just to show an overview of how the process works.