It'd be nice to have a/. user-preference option which says "Insert text between reply and signature:" and accepts an arbitrary HTML snippet. Then individual users could set this according to their own tastes.
Meanwhile, in your own.sig, you can put a tag in there too and it looks just like Usenet. For example:
<BR>--<BR>"People tell me one thing one day and out the other."
The school I went to used to use room-number as your address. Privacy concerns led to them switching to a mix-and-match DHCP randomization that decoupled names from rooms. Although annoying, it was probably a good thing.
if you show no interest in patenting your work during the post-disclosure window, someone else who sees value in it can patent it.
Not necessarily. Your work can be considered prior art, which can invalidate a patent in a number of different ways. Patents are supposed to extend the prior art, not duplicate it. Of course, IANAL. YMMV. HAND. *
--Joe
(*For the Usenet acronym impaired: I Am Not A Lawyer, Your Mileage May Vary, Have A Nice Day.) --
There's a SCSI/IDE emulation module for NT? I'm aware of one for Linux but not for Windows NT. Remember, the original poster was talking about using the NT port of cdrecord.
--Joe --
Re:Hex == Base 16 or Curse. Base 6 == Heximal.
on
Jesux is a Bad Pun
·
· Score: 1
By that argument, it should be decal (pronounced DESS al ??), not decimal. The reason it's Heximal instead of Hexal is that the "x" is a "soft" sound. The reason it's Octal instead of Octimal is that the "t" is a "hard" sound.
If your doing ISA->ISA translation, rollback is very, very useful. Suppose we have an x86-style instruction like this:
MOV [EAX*4 + 4], EBX
This particular instruction does several things: It reads EAX, multiplies it by 4, adds 4 to it, and then stores EBX at the address genereated to the desired location in memory. This might break up into several RISC-like ops: (these are written in the more traditional RISC form OP src, src, dst for clarity)
SHL EAX, 2, tmp1
ADD tmp1, 4, tmp2
STORE EBX, *tmp2
It doesn't take a brain surgeon to see that these steps could overlap their execution with other instructions. For instance, the instruction that calculates EBX could overlap execution with the left-shift and the add. If the original instruction was in a tight loop, then it could even overlap with itself! Why is this important?
Say you have some code which is stepping through the array, and say that the array spans a page boundary. And, say that the second page isn't "paged in." When the loop hits the page boundary, a fault will occur. Because the stores are being spooled extremely rapidly, the loop may not be informed that a particular STORE faulted until several other stores were executed. All stores after the faulting one need to be killed since we need to process exceptions in a precise order. Here's where the rollback becomes handy: We merely discard the extra, incorrect stores, and roll back the processor state to be consistent with the emulated state of the machine at the time of the fault.
This is what most current x86 clones do when they translate x86 instructions into "RISCops" or whatever they decide to call them. I'm guessing Transmeta is aiming to do a similar sort of translation, only with a more configurable flavor.
This patent exists because they can't determine ahead of time if there will be an error. This patent, inconjunction with one of their other patents, provides a method for them to muddle on in the usual case of no error and still have a means of rolling back in the less usual case of an error.
This particular patent convers stores that are speculatively executed, but may need to be killed because an instruction that occurred logically before them in the original code stream faulted.
A hardware queue which holds values that were stored by speculatively-executed instructions,
Logic which commits these stores to memory when the speculatively-executed instructions are retired,
Logic which discards these stores when the speculatively-executed instructions are killed,
Logic which maintains "checkpoints" or "tags" which delimit/identify groups of stores according to the speculative instruction flow, so that they may be committed or killed in these tagged groups.
The gist of this is that you can batch up groups of speculative stores, and either commit them or discard them in groups. This is important in an instruction translation environment, because a single emulated instruction may generate several stores when translated to a set of "native" instructions.
The hardware natively detects faults at native-instruction granularity, whereas the exceptions and errors need to be handled at the original emulated instruction granularity. So, the hardware needs a method for tagging writes that were due to a specific emulated instruction sequence that was speculated, so that it can kill the writes together and perform the appropriate exception processing. By doing this, you can allow the native instructions to execute in a more arbitrary order, since you can easily weed out the stores you wanted from the stores you did not.
Yes. The USPTO isn't exactly fast, and Transmeta hasn't been around all that long. So, I'm wagering the patents that we're seeing now were filed very early in Transmeta's life, and may have nothing to do with what Transmeta is doing today.
I know someone who works at a startup. While their basic technology hasn't changed, their target and application, and everything they wrap around it has as they've gone looking for money. Transmeta isn't much different.
Remember... Moore's Law keeps marching on. A technology that's neat and innovative today is scrap a couple years from now, so you have to change your approach with time if you end up taking too long. With a startup, that means the possibility of having to do something entirely different than you originally started with.
I grew up in a household built on respect. This included respect for my personal space and personal privacy. I personally find the idea of parents spying on their children to be highly objectionable. I personally prized the fact that my computer was mine, and its contents were private (much like a locked diary would be).
If parents need to know what their children are doing, they should ask. If they suspect that their child is misbehaving, they should confront their children directly. This is especially true for teenagers.
Children are people too. The worst emotional burden most people place on teenagers is that they expect them to behave as adults with most of the responsibilities of adults, but without respecting them as the adults they are becoming.
From the standpoint of "passing on the faith": "Faith by enforcement" is not faith at all. At some point your children must choose to be good people. Deleting porno files out of your child's directory for them after a random search does not make the child a good person -- even if you punish the child afterwards. (And even by the particularly shallow definition of good which would cast porno as bad.) The best you can do is to explain your expectations and reasons to your children, and listen to their thoughts and feelings. Both sides might actually learn something from the exchange.
Another bit of hypocrisy is the hierarchial filesystem... Why do parents need to spy on kids (but not vice-versa) if Christians have nothing to hide? Under Jesux, the default mode settings should be given by find / -print | xargs chmod a+r and find / -type d -print | xargs chmod a+x.
I think it's just a sad commentary on the fact that here in the US, often the reality isn't very far from the parodies. Just look at the whole Pro-{Choice|Life} issue. (I'm not going to say what side I'm on, because I'm liable to end up on somebody's hate list... and at this point, it doesn't matter which side! Come on, guys, you know who you are. Grow up!)
--Joe --
Hex == Base 16 or Curse. Base 6 == Heximal.
on
Jesux is a Bad Pun
·
· Score: 1
Hex alone does not mean "base 6". Hex as an abbreviation for Hexadecimal means base 16. Otherwise, Hex takes on the more traditional meanings of "curse" or "jinx". Base 6 would be called Heximal, I'd wager. --Joe --
Re:ZDNet doesn't want to admit its mistake
on
Jesux is a Bad Pun
·
· Score: 1
Ok, but why couldn't they type chmod a=rwx instead, and avoid using hexes?
This reminds me of how Austin Powers referenced an elevator (rather than lift) and worked for the Department of Defense instead of Defence. *sigh* Some people just don't know how to cover all their bases.
Five years ago, Linux couldn't handle the load. Not even close. File-descriptors were only one problem.
I would imagine that the "old school" effect also boils down to "Hey, there are a lot of shenanigans that go on in IRC land, and we've already proven X, Y, and Z work. The last time we tried Linux in any large way, it didn't work, so we're in no hurry to try it now."
All I can say is that I'm happier in Dilbert Land as an engineer than I was dealing with the stress of working at an ISP. At least engineers tend to be a little more rational than alot of the bozos you meet online. :-)
Actually, in your scenario, the most active pages will be in RAM twice -- once in the ramdisk and once in the disk cache. Since the bulk of the serving will be out of the cache, the ramdisk will sit there mostly idle -- and a waste of 50 MB of RAM.
I believe this is an incorrect statement under Linux. If I recall correctly, Linux' ramdisk driver just allocates pages for the ramdisk's filesystem in the disk-cache and just asks that they never be purged. That way, there aren't two copies of the same data in RAM, and you don't have to copy data back and forth between the ramdisk and the cache.
I imagine that the reason you saw better performance with those bdflush parameters is that more of the OS got cached into memory, fewer things got edged to swap, and logs that weren't on the ramdisk before (eg. everything in/var/adm) are benefitting from the huge flush period. I personally would not recommend going 10 minutes between flushes though. What happens, for instance, when a HD starts getting flaky?
I happened to think of one possible reason why so many phenomena might fit a lopsided curve better: The bell curve implies the possibility of infinite extension in both directions. If the mean of the distribution is near one physical extreme (for instance, looking at average rainfall levels -- you can't have negative rainfall), then the curve must become lopsided.
First, let me say that the graph in the article is poorly labeled (or at least their example poorly chosen), IMHO, since "rarity" is related to the number of standard deviations you are from the mean (whether or not the distribution is symmetrical), whereas their graph has rarity monotonically decreasing from left to right. I guess in this sense ("rarity of a species"), rarity != probability.
This new graph stikes me as a bit odd, since it's not symmetrical. With the bell curve, you only need to know how many standard deviations you are from the mean. With this curve, "above the mean" and "below the mean" are vastly different territories.
This curve brings up two questions for me:
Are there processes/events for which the mirror-image of this curve is the more appropriate distribution?
Whatever happened to the other distributions we know and love, like the Poisson distribution? Not all random events are evenly distributed, and we've known this for a long time.
I guess this new curve is just another way of saying that "Hey, there's a class of 'random' events out there that share a common non-uniform distribution!" While that's useful to know, I don't see it as the ultimate refutation of the Gaussian distribution.
Once upon a time, them and they were not specifically plural. Why not make them the gender-neutral pronouns? People do it everyday by accident, why not just make it the rule?
At the very least, everyone will understand what you're saying. Nobody should get offended, except for some grammar bigots out there that have close-minded views on the modern evolution of language.
It doesn't matter that Win64 was running. The original poster's point is still valid: A large reason why W2K ran at all is probably due to the large amount of legacy 32-bit code that's supported by the IA32 emulation on the chip.
After all, the reason the first Pentium Pro's didn't do so well when they came out was due to the fact that they didn't support 16-bit code very well. So, even though everyone was running a Win32 platform, most people didn't get much bang for their Pentium Pro buck due to the 16-bit code laying around under the hood.
It appears that certain operations are geared off of "registered IP addresses". So, if your brother has ever checked email from your machine, you can get to his account.
Slashdot Mirror
It'd be nice to have a /. user-preference option which says "Insert text between reply and signature:" and accepts an arbitrary HTML snippet. Then individual users could set this according to their own tastes.
Meanwhile, in your own .sig, you can put a
tag in there too and it looks just like Usenet. For example:
<BR>--<BR>"People tell me one thing one day and out the other."
See my .sig below for how it turns out.
--Joe--
Shouldn't that be kill instead of killall ?
Russian Roulette? while :; do kill -9 $RANDOM ; done
--Joe--
The school I went to used to use room-number as your address. Privacy concerns led to them switching to a mix-and-match DHCP randomization that decoupled names from rooms. Although annoying, it was probably a good thing.
--Joe--
Not necessarily. Your work can be considered prior art, which can invalidate a patent in a number of different ways. Patents are supposed to extend the prior art, not duplicate it. Of course, IANAL. YMMV. HAND. *
--Joe(*For the Usenet acronym impaired: I Am Not A Lawyer, Your Mileage May Vary, Have A Nice Day.)
--
There's a SCSI/IDE emulation module for NT? I'm aware of one for Linux but not for Windows NT. Remember, the original poster was talking about using the NT port of cdrecord.
--Joe--
By that argument, it should be decal (pronounced DESS al ??), not decimal. The reason it's Heximal instead of Hexal is that the "x" is a "soft" sound. The reason it's Octal instead of Octimal is that the "t" is a "hard" sound.
--Joe--
If your doing ISA->ISA translation, rollback is very, very useful. Suppose we have an x86-style instruction like this:
MOV [EAX*4 + 4], EBX
This particular instruction does several things: It reads EAX, multiplies it by 4, adds 4 to it, and then stores EBX at the address genereated to the desired location in memory. This might break up into several RISC-like ops: (these are written in the more traditional RISC form OP src, src, dst for clarity)
SHL EAX, 2, tmp1
ADD tmp1, 4, tmp2
STORE EBX, *tmp2
It doesn't take a brain surgeon to see that these steps could overlap their execution with other instructions. For instance, the instruction that calculates EBX could overlap execution with the left-shift and the add. If the original instruction was in a tight loop, then it could even overlap with itself! Why is this important?
Say you have some code which is stepping through the array, and say that the array spans a page boundary. And, say that the second page isn't "paged in." When the loop hits the page boundary, a fault will occur. Because the stores are being spooled extremely rapidly, the loop may not be informed that a particular STORE faulted until several other stores were executed. All stores after the faulting one need to be killed since we need to process exceptions in a precise order. Here's where the rollback becomes handy: We merely discard the extra, incorrect stores, and roll back the processor state to be consistent with the emulated state of the machine at the time of the fault.
This is what most current x86 clones do when they translate x86 instructions into "RISCops" or whatever they decide to call them. I'm guessing Transmeta is aiming to do a similar sort of translation, only with a more configurable flavor.
--Joe--
This patent exists because they can't determine ahead of time if there will be an error. This patent, inconjunction with one of their other patents, provides a method for them to muddle on in the usual case of no error and still have a means of rolling back in the less usual case of an error.
This particular patent convers stores that are speculatively executed, but may need to be killed because an instruction that occurred logically before them in the original code stream faulted.
--Joe--
The invention appears to be the following:
The gist of this is that you can batch up groups of speculative stores, and either commit them or discard them in groups. This is important in an instruction translation environment, because a single emulated instruction may generate several stores when translated to a set of "native" instructions.
The hardware natively detects faults at native-instruction granularity, whereas the exceptions and errors need to be handled at the original emulated instruction granularity. So, the hardware needs a method for tagging writes that were due to a specific emulated instruction sequence that was speculated, so that it can kill the writes together and perform the appropriate exception processing. By doing this, you can allow the native instructions to execute in a more arbitrary order, since you can easily weed out the stores you wanted from the stores you did not.
--Joe--
Yes. The USPTO isn't exactly fast, and Transmeta hasn't been around all that long. So, I'm wagering the patents that we're seeing now were filed very early in Transmeta's life, and may have nothing to do with what Transmeta is doing today.
I know someone who works at a startup. While their basic technology hasn't changed, their target and application, and everything they wrap around it has as they've gone looking for money. Transmeta isn't much different.
Remember... Moore's Law keeps marching on. A technology that's neat and innovative today is scrap a couple years from now, so you have to change your approach with time if you end up taking too long. With a startup, that means the possibility of having to do something entirely different than you originally started with.
--Joe--
Get it?
ObNerdJoke: Why do engineers get Halloween confused with Christmas? Because OCT(31) == DEC(25).
--Joe--
I grew up in a household built on respect. This included respect for my personal space and personal privacy. I personally find the idea of parents spying on their children to be highly objectionable. I personally prized the fact that my computer was mine, and its contents were private (much like a locked diary would be).
If parents need to know what their children are doing, they should ask. If they suspect that their child is misbehaving, they should confront their children directly. This is especially true for teenagers.
Children are people too. The worst emotional burden most people place on teenagers is that they expect them to behave as adults with most of the responsibilities of adults, but without respecting them as the adults they are becoming.
From the standpoint of "passing on the faith": "Faith by enforcement" is not faith at all. At some point your children must choose to be good people. Deleting porno files out of your child's directory for them after a random search does not make the child a good person -- even if you punish the child afterwards. (And even by the particularly shallow definition of good which would cast porno as bad.) The best you can do is to explain your expectations and reasons to your children, and listen to their thoughts and feelings. Both sides might actually learn something from the exchange.
--Joe--
Another bit of hypocrisy is the hierarchial filesystem... Why do parents need to spy on kids (but not vice-versa) if Christians have nothing to hide? Under Jesux, the default mode settings should be given by find / -print | xargs chmod a+r and find / -type d -print | xargs chmod a+x.
*sigh*
--Joe--
I think it's just a sad commentary on the fact that here in the US, often the reality isn't very far from the parodies. Just look at the whole Pro-{Choice|Life} issue. (I'm not going to say what side I'm on, because I'm liable to end up on somebody's hate list ... and at this point, it doesn't matter which side! Come on, guys, you know who you are. Grow up!)
--Joe--
Hex alone does not mean "base 6". Hex as an abbreviation for Hexadecimal means base 16. Otherwise, Hex takes on the more traditional meanings of "curse" or "jinx". Base 6 would be called Heximal, I'd wager. --Joe
--
Ok, but why couldn't they type chmod a=rwx instead, and avoid using hexes?
This reminds me of how Austin Powers referenced an elevator (rather than lift) and worked for the Department of Defense instead of Defence. *sigh* Some people just don't know how to cover all their bases.
--Joe--
Five years ago, Linux couldn't handle the load. Not even close. File-descriptors were only one problem.
I would imagine that the "old school" effect also boils down to "Hey, there are a lot of shenanigans that go on in IRC land, and we've already proven X, Y, and Z work. The last time we tried Linux in any large way, it didn't work, so we're in no hurry to try it now."
All I can say is that I'm happier in Dilbert Land as an engineer than I was dealing with the stress of working at an ISP. At least engineers tend to be a little more rational than alot of the bozos you meet online. :-)
--Joe--
I believe this is an incorrect statement under Linux. If I recall correctly, Linux' ramdisk driver just allocates pages for the ramdisk's filesystem in the disk-cache and just asks that they never be purged. That way, there aren't two copies of the same data in RAM, and you don't have to copy data back and forth between the ramdisk and the cache.
I imagine that the reason you saw better performance with those bdflush parameters is that more of the OS got cached into memory, fewer things got edged to swap, and logs that weren't on the ramdisk before (eg. everything in /var/adm) are benefitting from the huge flush period. I personally would not recommend going 10 minutes between flushes though. What happens, for instance, when a HD starts getting flaky?
--Joe--
Ack... my brain got sucked into the same trap as a few other people on this article. See subject.
--Joe--
You may have had a ticket on the clue bus, but I think you've lost your transfer.
Allaire's Cold Fusion web development product has little to do with Cygnus' Cold Fusion IDE, other than the obvious clash in names.
--Joe--
I happened to think of one possible reason why so many phenomena might fit a lopsided curve better: The bell curve implies the possibility of infinite extension in both directions. If the mean of the distribution is near one physical extreme (for instance, looking at average rainfall levels -- you can't have negative rainfall), then the curve must become lopsided.
Perhaps that's what they've stumbled onto?
--Joe--
First, let me say that the graph in the article is poorly labeled (or at least their example poorly chosen), IMHO, since "rarity" is related to the number of standard deviations you are from the mean (whether or not the distribution is symmetrical), whereas their graph has rarity monotonically decreasing from left to right. I guess in this sense ("rarity of a species"), rarity != probability.
This new graph stikes me as a bit odd, since it's not symmetrical. With the bell curve, you only need to know how many standard deviations you are from the mean. With this curve, "above the mean" and "below the mean" are vastly different territories.
This curve brings up two questions for me:
I guess this new curve is just another way of saying that "Hey, there's a class of 'random' events out there that share a common non-uniform distribution!" While that's useful to know, I don't see it as the ultimate refutation of the Gaussian distribution.
--Joe--
Once upon a time, them and they were not specifically plural. Why not make them the gender-neutral pronouns? People do it everyday by accident, why not just make it the rule?
At the very least, everyone will understand what you're saying. Nobody should get offended, except for some grammar bigots out there that have close-minded views on the modern evolution of language.
--Joe--
It doesn't matter that Win64 was running. The original poster's point is still valid: A large reason why W2K ran at all is probably due to the large amount of legacy 32-bit code that's supported by the IA32 emulation on the chip.
After all, the reason the first Pentium Pro's didn't do so well when they came out was due to the fact that they didn't support 16-bit code very well. So, even though everyone was running a Win32 platform, most people didn't get much bang for their Pentium Pro buck due to the 16-bit code laying around under the hood.
--Joe--
It appears that certain operations are geared off of "registered IP addresses". So, if your brother has ever checked email from your machine, you can get to his account.
--Joe--