It was originally intended to be a system fair to all parties. The original copyright term was also something in the range of 17 years.
With the current system, I consider the pirates more honorable than the RIAA and the MPAA...AND their members. ALL of them.
Sorry to shout, but this is important. Yes, there should (probably) be a copyright law. The current one is vile, corrupt, and *much* worse than not copyright law at all.
If they hadn't knowingly and maliciously allowed the Sony rootkit in, then I would feel some sympathy for them. As it is... let's play "Sympathy for the Devil" again while we contemplate this knot.
It makes a bit of sense, as they already had a patch available. It won't prevent an exploit, but it will slow it down by a day or two. This give people time to either update or at least check and see whether the version they are running is vulnerable.
You are correct. I was mainly thinking about simultaneous execution of different "light weight threads" or processes, not logical threads. So that's where I did put all the emphasis.
I thought I had handled that case. Now admittedly if you have 256 general purpose registers, then you have a large number of choices as to what you can do next, while if you only have, say, 6 stacks then your choices are fewer. This doesn't mean that they disappear.
One can't run connected calculations out of order (except as provided by commutativity and associativity) no matter how many registers you have. With multiple stacks the requirement would merely be to ensure that each stack only contained the connected calculations in order to have several logical threads proceed simultaneously. (No, I'm not talking about calling a Thread Library...I'm talking about the logical thread linking the calculations.) It's true that this was a minor consideration, but I did think I'd covered it.
Actually, even that is too strong a statement, though one would desire for efficiency that the top of each stack be a logically connected series of entities (numbers, processes, return values, etc.)
It's not clear to me that this would be a particularly efficient approach, but that's far different from asserting that it's impossible.
Unfortunately, I no longer use a Mac as my primary computer...though I did at the time that Neon was alive. (I'm glad to hear that it's still going, however.)
I believe that your criticisms apply to only specific stack based architectures. That they do apply to the commonly presumed architectures I accept, but this is far from asserting them as general truths.
Actually, even asserting that register based computers solve the problems that you are describing is not a general truth. You need to specify how many registers of what type can deal with how many out of order processes. And I suspect that a stack computer with 5 or 6 stacks could deal as flexibly with that problem as is commonly required...with a bit of extra leeway. It would need to be able to implement rapid task switching based on a "high priority task stack"...and maintaining that would be a bit of a nuisance...but that particular stack could have a very short limit, say 50 items. I'll agree that this is one function that it would be better to handle in scratchpad memory, but it would be eminently possible to do it purely from a stack based approach. (Still, there's a good reason that priority queues are queues rather than stacks...and I would argue that a dequeue would be an even better approach.
Well, I'm neither a hardware engineer nor a computer system designer, so I could be wrong. OTOH, you're anonymous, which means that your arguments only deserve the weight that their own internal logic provides.
Sorry, but LISP (though I don't mean Common LISP) is just as much a stack language as FORTH. I think the first LISP that wasn't was LISP 1.5...but I'm rather vague on LISP history. Still, s-expressions are as stack oriented as FORTH is. The interesting thing is the first Algol 60 compiler (well...really an interpreter) I ever used was a stack machine. (That was why it was an interpreter. The real computer was an IBM 7090/7094 BCS system so it ran a stack machine program that Algol was compiled to run on. Whee!) So if you want a good stack computer language you could pick Algol 60. But FORTH is easier, and could even be the assembler language.
OTOH, most FORTHs I've seen use 3 or more stacks. I.e., most of them have a separate stack for floats. What would be *really* nice is if someone built a machine that used Neon as it's assembler. Neon is/was an Object-oriented dialect of FORTH for the Mac that allowed the user to specify early or late binding for variables. It was developed by Kyria Systems, a now-defunct software house. Unfortunately Neon died during a transition to MSWind95. I understand that it is survived by MOPS, but I've never had a machine that MOPS would run on, so I don't know how similar it was.
I think that FORTH would make a truly great assembler...and the more so if that dialect of FORTH were NEON. But I forget how many stacks it used. At least three, but I have a vague memory that it was actually four. The main stack, the return stack, the floating stack, and ??the Object stack??...I don't know.
ENIAC's a great machine. All you need to do is re-implement it in nano-technology. Unfortunately, it's analog, so you won't be able to translate C to run on it.
The problem is that we, for fairly good reasons, don't *trust* the authority that's telling us to take what are ostensibly reasonable actions. So we consider plausible downsides.
Look at it this way, if a shady character on the street walked up to you and told you that you needed to take one of the pills he was offering you *for FREE!* to, O, double your intelligence...would you take it?
Why do you trust the DHS more than that shady stranger?
Running diff will tell what changes they made. You'll still need to figure out the exploit.
P.S.: All security is security either through obscurity or through immutability. And immutabilities limits what you can do. But if you rely on obscurity it better REALLY be obscure, or you had better only rely on it for a short period of time.
When I think Sony I think rootkit. When I thing Sony I think denial of responsibility. When I think Sony, I wish it would go bankrupt quickly.
Sony isn't as bad as MS, but that is faint praise indeed.
OTOH, their rootkit *did* prove that ALL of the anti-virus companies are untrustworthy. I'm quite glad I no longer depend upon them. Apparently they deserve their rough treatment at the hands of MS. If Sony hadn't revealed them for the villians that they were I might feel sorry for them as MS drove them into extinction.
Even if it is what will be the cost and who will pay? Justice? I don't think so. Justice would require that nobody be prosecuted without probable cause.
They'll phase out paper money before bothering with that. After all, they don't usually need to. Most people aren't consistently paranoid enough to avoid the net. Of the ones that do, almost all are too paranoid to successfully conspire with others.
If Apple has any sense, it will now decide to lend a developer or two (more?) half-time to Neo-Office.
OpenOffice is nice on Linux and on MSWind, but the Mac version is very unpleasant unless you already use XWindow all the time. NeoOffice is about the same...but it runs native on the Mac OS. (I don't think Apple needs to worry about VirtualPC not being supported...but it should worry about having a good word processor/office suite.
Doubt if you want. I didn't "switch", I made decisions about future purchases. I run a mixed Apple/Linux environment with one MSWind95 machine. My decision was to hold off on any new purchases of Apple. And to think several times before recommending it to someone.
So they're switching back. I think I'll reserve judgement for a year. If they're really back, then I might consider buying an Apple again. (I'll agree that the Apple has advantages. It's also got a LARGE number of not clearly identified licenses that need to be periodically agreed to. And I really don't like that. And I find their file system (desktop) to be unintuitive...which is odd, because it's the ONLY file system (desktop) that I use which I find to be that way...and I didn't find the OS9 file system to be unintuitive. With OSX I have to stop and think. This is bad because the main user, my wife, has even more troubles with it than I do. (And she does have trouble with MSWind95...but not as much as with the Mac which is currently her main system.)
But Apple does have some really nice applications. If they are genuinely back as a peripheral member of the FOSS community rather than just doing a Sun-like flip-flop then I'll be considering them again because of those applications. If not I'll make do with the ones we've already purchased. (No, I'm not considering discarding them. That would require someone proving that they were being VERY sleazy with their EULA's.)
In that case, let's go the protocol encryption route. Most things I would want to download won't be paying any license fees to become "commercially licensed". (When did you last download a "commercially licensed" distro?)
This particular photographer has reputedly commited fraud before. I'll accept that *his* motive was financial gain. What was Reuter's motive for accepting work from a know producer of fraudulent news?
I've never seen anything decent from Hatch. If he's a sponsor, something is wrong with this bill. I may not know what it is, but something is wrong.
Never forget that Hatch is one of the names lending support to SCO. (Not the senator, but his son.) Trust something from him like you would trust a standard MicroSoft contract.
The thing is, different chemicals require different solvents. DMSO is great for transporting garlic, or the taste of the insides of your shoe...but this doesn't mean it would work for "anything". E.g. it's not particularly good at transporting the taste of iron filings.
My impression is that it works best with oil soluble chemicals...but it could be alcohol soluble or ether soluble and I wouldn't know, as I haven't done any personal experimentation, merely read a few things. But LSD is water soluble. This doesn't mean it *isn't* oil soluble, but it means not to expect it.
So my guess it that putting DMSO that had soaked in an old gym shoe on the door handle would have more effects. The smell is reported to come out on your breath for hours. (Of course, you don't want to get any on yourself:)
Which is cute...but is LSD even soluble in DMSO? Dissolving it in water will hydrolyse it after a very short period of time (which is what makes the threat of throwing it in a reservoir so funny...to hear).
You don't succeed by refusing to face problems. In the 1960's NASA had competent administrators and the support of the government. Today it has neither. Anyone who predicts success for a long term project in such a situation is a fool..unless all the pieces are readily available and he knows exactly how to proceed. (Possibly even then. Consider the fate of the Hubble under the current administration. It isn't all technical problems. Even more it's administrative. Until that is solved (which requires a desire on the part of the government that it be solved) more money will at best keep things from getting worse.
NASA has been a "designated failure" for several successive administrations. (I don't *think* Clinton actively sabotaged it, but he certainly didn't resurrect it. Of course, he was distracted a lot. Maybe he would have otherwise.)
Slashdot Mirror
It was originally intended to be a system fair to all parties. The original copyright term was also something in the range of 17 years.
With the current system, I consider the pirates more honorable than the RIAA and the MPAA...AND their members. ALL of them.
Sorry to shout, but this is important. Yes, there should (probably) be a copyright law. The current one is vile, corrupt, and *much* worse than not copyright law at all.
If they hadn't knowingly and maliciously allowed the Sony rootkit in, then I would feel some sympathy for them. As it is... let's play "Sympathy for the Devil" again while we contemplate this knot.
Content Scramble System. Of course! How could I have missed it for so long.
It makes a bit of sense, as they already had a patch available. It won't prevent an exploit, but it will slow it down by a day or two. This give people time to either update or at least check and see whether the version they are running is vulnerable.
You are correct. I was mainly thinking about simultaneous execution of different "light weight threads" or processes, not logical threads. So that's where I did put all the emphasis.
I thought I had handled that case. Now admittedly if you have 256 general purpose registers, then you have a large number of choices as to what you can do next, while if you only have, say, 6 stacks then your choices are fewer. This doesn't mean that they disappear.
One can't run connected calculations out of order (except as provided by commutativity and associativity) no matter how many registers you have. With multiple stacks the requirement would merely be to ensure that each stack only contained the connected calculations in order to have several logical threads proceed simultaneously. (No, I'm not talking about calling a Thread Library...I'm talking about the logical thread linking the calculations.) It's true that this was a minor consideration, but I did think I'd covered it.
Actually, even that is too strong a statement, though one would desire for efficiency that the top of each stack be a logically connected series of entities (numbers, processes, return values, etc.)
It's not clear to me that this would be a particularly efficient approach, but that's far different from asserting that it's impossible.
Unfortunately, I no longer use a Mac as my primary computer...though I did at the time that Neon was alive. (I'm glad to hear that it's still going, however.)
Sorry. I was assuming that the AC of ENIAC stood for Analog Computer, as I believe was usual.
I believe that your criticisms apply to only specific stack based architectures. That they do apply to the commonly presumed architectures I accept, but this is far from asserting them as general truths.
Actually, even asserting that register based computers solve the problems that you are describing is not a general truth. You need to specify how many registers of what type can deal with how many out of order processes. And I suspect that a stack computer with 5 or 6 stacks could deal as flexibly with that problem as is commonly required...with a bit of extra leeway. It would need to be able to implement rapid task switching based on a "high priority task stack"...and maintaining that would be a bit of a nuisance...but that particular stack could have a very short limit, say 50 items. I'll agree that this is one function that it would be better to handle in scratchpad memory, but it would be eminently possible to do it purely from a stack based approach. (Still, there's a good reason that priority queues are queues rather than stacks...and I would argue that a dequeue would be an even better approach.
Well, I'm neither a hardware engineer nor a computer system designer, so I could be wrong. OTOH, you're anonymous, which means that your arguments only deserve the weight that their own internal logic provides.
Sorry, but LISP (though I don't mean Common LISP) is just as much a stack language as FORTH. I think the first LISP that wasn't was LISP 1.5...but I'm rather vague on LISP history. Still, s-expressions are as stack oriented as FORTH is. The interesting thing is the first Algol 60 compiler (well...really an interpreter) I ever used was a stack machine. (That was why it was an interpreter. The real computer was an IBM 7090/7094 BCS system so it ran a stack machine program that Algol was compiled to run on. Whee!) So if you want a good stack computer language you could pick Algol 60. But FORTH is easier, and could even be the assembler language.
OTOH, most FORTHs I've seen use 3 or more stacks. I.e., most of them have a separate stack for floats. What would be *really* nice is if someone built a machine that used Neon as it's assembler. Neon is/was an Object-oriented dialect of FORTH for the Mac that allowed the user to specify early or late binding for variables. It was developed by Kyria Systems, a now-defunct software house. Unfortunately Neon died during a transition to MSWind95. I understand that it is survived by MOPS, but I've never had a machine that MOPS would run on, so I don't know how similar it was.
I think that FORTH would make a truly great assembler...and the more so if that dialect of FORTH were NEON. But I forget how many stacks it used. At least three, but I have a vague memory that it was actually four. The main stack, the return stack, the floating stack, and ??the Object stack??...I don't know.
ENIAC's a great machine. All you need to do is re-implement it in nano-technology. Unfortunately, it's analog, so you won't be able to translate C to run on it.
The problem is that we, for fairly good reasons, don't *trust* the authority that's telling us to take what are ostensibly reasonable actions. So we consider plausible downsides.
Look at it this way, if a shady character on the street walked up to you and told you that you needed to take one of the pills he was offering you *for FREE!* to, O, double your intelligence...would you take it?
Why do you trust the DHS more than that shady stranger?
Don't you *want* to double your intelligence?
No. I don't remember it. And in '98 I was starting to get interested in Linux. So it definitely wasn't a high profile action on anybody's part.
Running diff will tell what changes they made. You'll still need to figure out the exploit.
P.S.: All security is security either through obscurity or through immutability. And immutabilities limits what you can do. But if you rely on obscurity it better REALLY be obscure, or you had better only rely on it for a short period of time.
When I think Sony I think rootkit. When I thing Sony I think denial of responsibility. When I think Sony, I wish it would go bankrupt quickly.
Sony isn't as bad as MS, but that is faint praise indeed.
OTOH, their rootkit *did* prove that ALL of the anti-virus companies are untrustworthy. I'm quite glad I no longer depend upon them. Apparently they deserve their rough treatment at the hands of MS. If Sony hadn't revealed them for the villians that they were I might feel sorry for them as MS drove them into extinction.
Even if it is what will be the cost and who will pay? Justice? I don't think so. Justice would require that nobody be prosecuted without probable cause.
Yeah, too paranoid.
They'll phase out paper money before bothering with that. After all, they don't usually need to. Most people aren't consistently paranoid enough to avoid the net. Of the ones that do, almost all are too paranoid to successfully conspire with others.
If Apple has any sense, it will now decide to lend a developer or two (more?) half-time to Neo-Office.
OpenOffice is nice on Linux and on MSWind, but the Mac version is very unpleasant unless you already use XWindow all the time. NeoOffice is about the same...but it runs native on the Mac OS. (I don't think Apple needs to worry about VirtualPC not being supported...but it should worry about having a good word processor/office suite.
Doubt if you want. I didn't "switch", I made decisions about future purchases. I run a mixed Apple/Linux environment with one MSWind95 machine. My decision was to hold off on any new purchases of Apple. And to think several times before recommending it to someone.
So they're switching back. I think I'll reserve judgement for a year. If they're really back, then I might consider buying an Apple again. (I'll agree that the Apple has advantages. It's also got a LARGE number of not clearly identified licenses that need to be periodically agreed to. And I really don't like that. And I find their file system (desktop) to be unintuitive...which is odd, because it's the ONLY file system (desktop) that I use which I find to be that way...and I didn't find the OS9 file system to be unintuitive. With OSX I have to stop and think. This is bad because the main user, my wife, has even more troubles with it than I do. (And she does have trouble with MSWind95...but not as much as with the Mac which is currently her main system.)
But Apple does have some really nice applications. If they are genuinely back as a peripheral member of the FOSS community rather than just doing a Sun-like flip-flop then I'll be considering them again because of those applications. If not I'll make do with the ones we've already purchased. (No, I'm not considering discarding them. That would require someone proving that they were being VERY sleazy with their EULA's.)
In that case, let's go the protocol encryption route. Most things I would want to download won't be paying any license fees to become "commercially licensed". (When did you last download a "commercially licensed" distro?)
This particular photographer has reputedly commited fraud before. I'll accept that *his* motive was financial gain. What was Reuter's motive for accepting work from a know producer of fraudulent news?
I've never seen anything decent from Hatch. If he's a sponsor, something is wrong with this bill. I may not know what it is, but something is wrong.
Never forget that Hatch is one of the names lending support to SCO. (Not the senator, but his son.) Trust something from him like you would trust a standard MicroSoft contract.
The thing is, different chemicals require different solvents. DMSO is great for transporting garlic, or the taste of the insides of your shoe...but this doesn't mean it would work for "anything". E.g. it's not particularly good at transporting the taste of iron filings.
:)
My impression is that it works best with oil soluble chemicals...but it could be alcohol soluble or ether soluble and I wouldn't know, as I haven't done any personal experimentation, merely read a few things. But LSD is water soluble. This doesn't mean it *isn't* oil soluble, but it means not to expect it.
So my guess it that putting DMSO that had soaked in an old gym shoe on the door handle would have more effects. The smell is reported to come out on your breath for hours. (Of course, you don't want to get any on yourself
Which is cute...but is LSD even soluble in DMSO? Dissolving it in water will hydrolyse it after a very short period of time (which is what makes the threat of throwing it in a reservoir so funny...to hear).
You don't succeed by refusing to face problems. In the 1960's NASA had competent administrators and the support of the government. Today it has neither. Anyone who predicts success for a long term project in such a situation is a fool..unless all the pieces are readily available and he knows exactly how to proceed. (Possibly even then. Consider the fate of the Hubble under the current administration. It isn't all technical problems. Even more it's administrative. Until that is solved (which requires a desire on the part of the government that it be solved) more money will at best keep things from getting worse.
NASA has been a "designated failure" for several successive administrations. (I don't *think* Clinton actively sabotaged it, but he certainly didn't resurrect it. Of course, he was distracted a lot. Maybe he would have otherwise.)