If GIF succeeds where PNG fails, even though PNG is clearly superior (can we say VHS vs Betamax?), what would happen with True-Color GIF once the LZW patent expires?
Point me (URL) to a place where I can buy a motherboard with 8GB (or more) RAM support (and NOT with that RAMBUS crap) and a 64-bit CPU that is supported by Linux or FreeBSD.
Scaling is a function of the workload, not of the CPU. If the CPU speed is half or twice, scaling is still proportionally the same. In other words, if you need twice the CPU to get the job done because the code performs at half the speed, then that's going to be the case at any workload level. What a higher CPU usage of something like HTML parsing will do is just make your tolerance threashold be reached sooner. Funny how it is people will switch and say CPU is not the issue if I bring up how their favorite tool is a CPU hog.
So.... get the best of both worlds. What you need is pre-parsed HTML templates that generate your servlets. Parse the HTML once, and the servlet code then "identifies" the session key insertion points by means of its (now) built-in code. Then compile the servlets down to binary once debugged.
But RAMBUS is moving towards more analog sensitivity. There may be fewer data lines but there are more discrete voltage levels and timing intervals between clock pulses to get screwed up by spurious signals. At least with pure 1's and 0's, ths signal is sufficiently quantized as to be readily corrected until the noise pushes it past the boundary. RAMBUS seems to be squeezing those boundaries ever closer. Lots of bandwidth improving technology has gone the way of more data lines, such as wide SCSI and gigabit ethernet. Generating noise vs. noise sensitivity seems to be the issue here.
One of the problems I do see in motherboard design is that the paths that data and addresses have to take between the various components in the layout is, in a large number of cases, not the shortest.
One of my motherboards, an Intel SR440BX, has a sinusoidal ringing pattern in sync with the horizontal sync pulses. The video has to traverse across the motherboard, unshielded, to reach the video connector. It's not actually getting any digital hash, but it is encountering the impedance variations along the way. Maybe this is just saying that motherboard designers don't get to (or can't) take all things into consideration as others (for example video card designers) could. Which end of a video card would you put the D/A conversion? Which end would you put the VRAM?
Sometimes I wonder if these digital designers were sleeping in Microwave RF Engineering class
When you send yours in for replacement, borrow some extra DIMMs and populate the mother to the max! They might replace the board in that case, but obviously it would have to be one that at least handles that much. Beware they might replace 4 128MB DIMMs with 2 256MB DIMMs on a board with only 2 DIMM sockets. Whatever number of sockets you do have, max them out with the largest DIMMs you can get. At worst case, you get your DIMMs back.
Why not just interleave 2 or 4 banks of SDRAM DIMMs into 4-way interleaved cache on the motherboard? Cost: 216 more data lines and a few more control lines, plus the larger cache (because there's really 4 caches), plus the fact that you have to have 4 identical DIMMs in place (2 for 2-way mode). How much would this design, with 512MB of RAM organized as 4x 128MB, cost, compared to 512MB of RIMMs and the associated technology?
I declined to choose the 810 or 820 chipsets anyway because they don't support ECC (which I suspect might even be more important with RAMBUS). So I'll be using BX technology unless and until someone makes a K7 based motherboard with correct server technology (The Abit KA7 board doesn't reboot on interrupted power, so I'm avoiding that for my servers).
Apparently the rumor is that the problem is in the motherboard and how it has designed around the i820. Perhaps other motherboards don't have this problem (or perhaps they have their own problems).
If you get a remarked CPU, you can discover that with the appropriate software tools. That should be sufficient, although opening it up to further show the fraud might be more convincing. If that "Mom and Pop" place still refuses a return on the clear case of fraud, then they should be run totally out of business.
I don't have a problem with retailers that refuse to take back DEAD stuff because I understand how this stuff can become DEAD. OTOH, I've gotten DEAD stuff from 2 local dealers and they both took it back (motherboard in one case and RAM in another). I'm not even certain that I didn't zap them myself. I was glad they did swap out for me, but they could have just as easily told me I must have static zapped it.
OTOH, if I get a clear case of fraud, I will EXPECT them to take it back (and to even follow up with their distribution source... e.g. get their own money back on the junk).
So how do you code a loop in these "fast templates"? Oh, wait... you code the loop separately in the macro and just drop in the template referring to that macro to position its output. Yeah, that's it. Scatter the code around in pieces so I have to jump around from file to file to see what the hell you are really doing. That's not unlike having a bunch of function calls. But I don't think the boundary between separated chunks of code should necessarily be forced to be aligned at syntax class boundaries.
The whole issue of code mixing is just a special case instance of the long time argument about whether separation or consolidation of code is the better choice. And each has its advantages and disadvantages. The difference here is that we are fixating on a boundary between steps that are each optimally coded in different languages.
The solution I generally use (and there are exceptions to this, too) is that if the modular element is (or can be made to be) a re-usable piece of code, then it should be separated (e.g. make the template) but if it is just a component of the current object (page) it should be consolidated. For example, if I have a menu of actions generated from what permissions a user actually has rights to do, it may be re-useable (if more than one page would have the same menu) or not (if each menu set on each page is different). One option is to make it like a function call if I can pass arguments to it (but I don't see how you might propose a syntax to do that) such as giving it a list of menu items appropriate for this page for it to actually output those the user has permission to do. Of course, once you do that (add argument passing systax) you're moving back to mixing code because you're going back to programmer, rather than layout, syntax.
Personally, I'm not opposed to mixing code at all. I can read HTML, and PHP, or even C, equally well. My C code typically has tons of printf calls generating large blocks of HTML anyway (though I am working on encapsulating re-useable chunks of that into separate functions or classes). There is the question of which way is the best way to mix code (assuming you can be convinced that mixing is allowed). Should I just have HTML in output statements, or should I integrate the syntax as ASP and PHP do? I am currently planning to explore the latter with C/C++ as the basis language.
... that's why they work so well. They aren't released until they really are ready. When you don't have media advertising for your product in the works, with everything set to a schedule months ahead of time, then what you do have is an opportunity to get it right, even if it does take a few months longer than expected. You might be steamed that Linux 2.4 or Debian 2.2 or whatever is next isn't really out yet. But you can appreciate it working well when it does come out, or go grab the beta copy to see if you can even make it crash.
English could work. Problem is it will probably be the defacto internet language, just out of shear momentum, whether it is cleaned up or not. Much can be learned from other languages like Esperanto (fix the spelling) and even Estonian, Finnish and Hungarian (genderless pronouns)
CyberAngel already does this
on
Laptop Lojack?
·
· Score: 2
CyberAngel already does this. It doesn't use radio that I know of (but that might be an interesting idea). It does use the modem (if the thief is dumb enough to hook it up, ANI will rat out his phone number). It can also be configured to wipe the hard drive if the unprompted password isn't entered within a certain time. And encrypted versions are also available.
I've been building a "fast install" of Linux based on Slackware 7.0 with many of my local mods (including a total rewrite of the sysinit rc scripts). The full install takes less than 8 minutes (when started from a HD based rescue partition) which is faster than some systems can even get booted up. Smaller configurations should go even faster. And this even includes repartitioning and reformatting. The configuration to be installed is entirely separate from the configuration of the system that serves the installation.
There is no concensus on what proper configuration management tools is, yet. What I am aiming for is less need to actually do any configuration. Right now the configuration I actually do involves editing files because there are no configuration tools around that know how to configure a collection of modularized installation feature groups as I have now. For those who prefer menu and/or graphical based central configuration, such tools will be needed. Since I'm not one who uses such tools, I would be a poor choice to program that part of the project. Maybe you could do that part?
I'm also currently looking at basing this from Debian 2.2. I would have to figure out how to change dpkg/apt so it can install into the installation repository instead of the host system, or run on the target machines and obtain configuration preferences from the central machine (e.g. what to install, etc).
Netscape 4 is horribly slow at rendering nested tables. It's not the web designer's fault that HTML was never designed to do what we expect of it today (and nested tables are one way to get a lot of stuff to lay out right). Netscape 3 is much faster, so it's clear that the problem is in the browser. But Netscape 4 has always sucked from day 1. How well Mozilla will do remains to be seen (it's horribly slow now, but I'm told that's because so many debug checks are still in there).
The creation of an uncompressed GIF does not imply the requirement of the LZW algorithm to uncompress it. The opening of the file is irrelevant to whether actually creating an uncompressed GIF is or is not using compression. The fact that you can open the file without LZW code allows the creation to be legal since it can be used entirely without any LZW implementation. The creator is not responsible for how the viewer opens it. You could open it with a text editor or a hex dump program, for all I care. Not using LZW is not using LZW, plain and simple. If you choose to use it on your end, that's your business.
An agreement on how to interpret such file by Microsoft, Netscape, and Opera Software, when displaying them via web browsers, as well as by Adobe and The GIMP development team in Photoshop and The GIMP for importing purposes, suggests to me that there is a prevailing concensus that the pallette change opinion has lost out to the full color rendering opinion. Remember that neither interpretation was ever standardized by the GIF89A specification. But the defacto standard seems to be clear. Even those programs that do not apply the full color method still don't do the pallette change method either. In fact I haven't seen any such program, ever. While I will stipulate that people certainly can interpret it to mean a pallette change, I have no doubt that today the prevailing intrepretation will be the one that is actually useful for something.
Courts have awarded patent royalties long after patents have expired, for the infringements that occurred while the patent was in force, when appropriate notifications were done at the right time. If Unisys claims you owe them royalties, you're not off the hook by stalling until 2003. You may even be liable for interest, as well.
The examples are here. And, yes, the file sizes, especially when not compressed due to no LZW, get huge. This is not the best way to do true-color imaging, but if it needs to be done, it can be.
Most photos generally do better as JPEGs than as GIFs or even as PNGs. The reason is that JPEG's lossy compression isn't really noticed in the graduations of the image. Lossless compression, such as GIF and PNG use, do better on images which have fewer colors, or would suffer from lossy blending.
It just dawned on me. Unisys and AccuWeather are competing providers of weather data, such as value added weather radar feeds. So my suspicion is that this may be more than just trying to get huge royalties. It may also be to try and cripple a competitor. I didn't see any mention of this in the CNET article, but I think it's important enough to bring up. It may even be relevant and further show why so many patents are really bad tools to put in the hands of business. It could help explain why they wanted so much from AccuWeather.
Slashdot Mirror
If GIF succeeds where PNG fails, even though PNG is clearly superior (can we say VHS vs Betamax?), what would happen with True-Color GIF once the LZW patent expires?
What GIF/PNG debate? PNG is superior, period.
Point me (URL) to a place where I can buy a motherboard with 8GB (or more) RAM support (and NOT with that RAMBUS crap) and a 64-bit CPU that is supported by Linux or FreeBSD.
Why can't it use generic sdram?
Scaling is a function of the workload, not of the CPU. If the CPU speed is half or twice, scaling is still proportionally the same. In other words, if you need twice the CPU to get the job done because the code performs at half the speed, then that's going to be the case at any workload level. What a higher CPU usage of something like HTML parsing will do is just make your tolerance threashold be reached sooner. Funny how it is people will switch and say CPU is not the issue if I bring up how their favorite tool is a CPU hog.
So.... get the best of both worlds. What you need is pre-parsed HTML templates that generate your servlets. Parse the HTML once, and the servlet code then "identifies" the session key insertion points by means of its (now) built-in code. Then compile the servlets down to binary once debugged.
But RAMBUS is moving towards more analog sensitivity. There may be fewer data lines but there are more discrete voltage levels and timing intervals between clock pulses to get screwed up by spurious signals. At least with pure 1's and 0's, ths signal is sufficiently quantized as to be readily corrected until the noise pushes it past the boundary. RAMBUS seems to be squeezing those boundaries ever closer. Lots of bandwidth improving technology has gone the way of more data lines, such as wide SCSI and gigabit ethernet. Generating noise vs. noise sensitivity seems to be the issue here.
One of the problems I do see in motherboard design is that the paths that data and addresses have to take between the various components in the layout is, in a large number of cases, not the shortest.
One of my motherboards, an Intel SR440BX, has a sinusoidal ringing pattern in sync with the horizontal sync pulses. The video has to traverse across the motherboard, unshielded, to reach the video connector. It's not actually getting any digital hash, but it is encountering the impedance variations along the way. Maybe this is just saying that motherboard designers don't get to (or can't) take all things into consideration as others (for example video card designers) could. Which end of a video card would you put the D/A conversion? Which end would you put the VRAM?
Sometimes I wonder if these digital designers were sleeping in Microwave RF Engineering class
When you send yours in for replacement, borrow some extra DIMMs and populate the mother to the max! They might replace the board in that case, but obviously it would have to be one that at least handles that much. Beware they might replace 4 128MB DIMMs with 2 256MB DIMMs on a board with only 2 DIMM sockets. Whatever number of sockets you do have, max them out with the largest DIMMs you can get. At worst case, you get your DIMMs back.
Why not just interleave 2 or 4 banks of SDRAM DIMMs into 4-way interleaved cache on the motherboard? Cost: 216 more data lines and a few more control lines, plus the larger cache (because there's really 4 caches), plus the fact that you have to have 4 identical DIMMs in place (2 for 2-way mode). How much would this design, with 512MB of RAM organized as 4x 128MB, cost, compared to 512MB of RIMMs and the associated technology?
I declined to choose the 810 or 820 chipsets anyway because they don't support ECC (which I suspect might even be more important with RAMBUS). So I'll be using BX technology unless and until someone makes a K7 based motherboard with correct server technology (The Abit KA7 board doesn't reboot on interrupted power, so I'm avoiding that for my servers).
Apparently the rumor is that the problem is in the motherboard and how it has designed around the i820. Perhaps other motherboards don't have this problem (or perhaps they have their own problems).
If you get a remarked CPU, you can discover that with the appropriate software tools. That should be sufficient, although opening it up to further show the fraud might be more convincing. If that "Mom and Pop" place still refuses a return on the clear case of fraud, then they should be run totally out of business.
... e.g. get their own money back on the junk).
I don't have a problem with retailers that refuse to take back DEAD stuff because I understand how this stuff can become DEAD. OTOH, I've gotten DEAD stuff from 2 local dealers and they both took it back (motherboard in one case and RAM in another). I'm not even certain that I didn't zap them myself. I was glad they did swap out for me, but they could have just as easily told me I must have static zapped it.
OTOH, if I get a clear case of fraud, I will EXPECT them to take it back (and to even follow up with their distribution source
So how do you code a loop in these "fast templates"? Oh, wait... you code the loop separately in the macro and just drop in the template referring to that macro to position its output. Yeah, that's it. Scatter the code around in pieces so I have to jump around from file to file to see what the hell you are really doing. That's not unlike having a bunch of function calls. But I don't think the boundary between separated chunks of code should necessarily be forced to be aligned at syntax class boundaries.
The whole issue of code mixing is just a special case instance of the long time argument about whether separation or consolidation of code is the better choice. And each has its advantages and disadvantages. The difference here is that we are fixating on a boundary between steps that are each optimally coded in different languages.
The solution I generally use (and there are exceptions to this, too) is that if the modular element is (or can be made to be) a re-usable piece of code, then it should be separated (e.g. make the template) but if it is just a component of the current object (page) it should be consolidated. For example, if I have a menu of actions generated from what permissions a user actually has rights to do, it may be re-useable (if more than one page would have the same menu) or not (if each menu set on each page is different). One option is to make it like a function call if I can pass arguments to it (but I don't see how you might propose a syntax to do that) such as giving it a list of menu items appropriate for this page for it to actually output those the user has permission to do. Of course, once you do that (add argument passing systax) you're moving back to mixing code because you're going back to programmer, rather than layout, syntax.
Personally, I'm not opposed to mixing code at all. I can read HTML, and PHP, or even C, equally well. My C code typically has tons of printf calls generating large blocks of HTML anyway (though I am working on encapsulating re-useable chunks of that into separate functions or classes). There is the question of which way is the best way to mix code (assuming you can be convinced that mixing is allowed). Should I just have HTML in output statements, or should I integrate the syntax as ASP and PHP do? I am currently planning to explore the latter with C/C++ as the basis language.
... that's why they work so well. They aren't released until they really are ready. When you don't have media advertising for your product in the works, with everything set to a schedule months ahead of time, then what you do have is an opportunity to get it right, even if it does take a few months longer than expected. You might be steamed that Linux 2.4 or Debian 2.2 or whatever is next isn't really out yet. But you can appreciate it working well when it does come out, or go grab the beta copy to see if you can even make it crash.
English could work. Problem is it will probably be the defacto internet language, just out of shear momentum, whether it is cleaned up or not. Much can be learned from other languages like Esperanto (fix the spelling) and even Estonian, Finnish and Hungarian (genderless pronouns)
CyberAngel already does this. It doesn't use radio that I know of (but that might be an interesting idea). It does use the modem (if the thief is dumb enough to hook it up, ANI will rat out his phone number). It can also be configured to wipe the hard drive if the unprompted password isn't entered within a certain time. And encrypted versions are also available.
More info right here and details over here.
Unfortunately, no BSD or Linux version. It's just for Windows. But I'm sure someone can put something like this together for BSD and Linux.
I've been building a "fast install" of Linux based on Slackware 7.0 with many of my local mods (including a total rewrite of the sysinit rc scripts). The full install takes less than 8 minutes (when started from a HD based rescue partition) which is faster than some systems can even get booted up. Smaller configurations should go even faster. And this even includes repartitioning and reformatting. The configuration to be installed is entirely separate from the configuration of the system that serves the installation.
There is no concensus on what proper configuration management tools is, yet. What I am aiming for is less need to actually do any configuration. Right now the configuration I actually do involves editing files because there are no configuration tools around that know how to configure a collection of modularized installation feature groups as I have now. For those who prefer menu and/or graphical based central configuration, such tools will be needed. Since I'm not one who uses such tools, I would be a poor choice to program that part of the project. Maybe you could do that part?
I'm also currently looking at basing this from Debian 2.2. I would have to figure out how to change dpkg/apt so it can install into the installation repository instead of the host system, or run on the target machines and obtain configuration preferences from the central machine (e.g. what to install, etc).
Netscape 4 is horribly slow at rendering nested tables. It's not the web designer's fault that HTML was never designed to do what we expect of it today (and nested tables are one way to get a lot of stuff to lay out right). Netscape 3 is much faster, so it's clear that the problem is in the browser. But Netscape 4 has always sucked from day 1. How well Mozilla will do remains to be seen (it's horribly slow now, but I'm told that's because so many debug checks are still in there).
The creation of an uncompressed GIF does not imply the requirement of the LZW algorithm to uncompress it. The opening of the file is irrelevant to whether actually creating an uncompressed GIF is or is not using compression. The fact that you can open the file without LZW code allows the creation to be legal since it can be used entirely without any LZW implementation. The creator is not responsible for how the viewer opens it. You could open it with a text editor or a hex dump program, for all I care. Not using LZW is not using LZW, plain and simple. If you choose to use it on your end, that's your business.
An agreement on how to interpret such file by Microsoft, Netscape, and Opera Software, when displaying them via web browsers, as well as by Adobe and The GIMP development team in Photoshop and The GIMP for importing purposes, suggests to me that there is a prevailing concensus that the pallette change opinion has lost out to the full color rendering opinion. Remember that neither interpretation was ever standardized by the GIF89A specification. But the defacto standard seems to be clear. Even those programs that do not apply the full color method still don't do the pallette change method either. In fact I haven't seen any such program, ever. While I will stipulate that people certainly can interpret it to mean a pallette change, I have no doubt that today the prevailing intrepretation will be the one that is actually useful for something.
Courts have awarded patent royalties long after patents have expired, for the infringements that occurred while the patent was in force, when appropriate notifications were done at the right time. If Unisys claims you owe them royalties, you're not off the hook by stalling until 2003. You may even be liable for interest, as well.
The examples are here . And, yes, the file sizes, especially when not compressed due to no LZW, get huge. This is not the best way to do true-color imaging, but if it needs to be done, it can be.
Most photos generally do better as JPEGs than as GIFs or even as PNGs. The reason is that JPEG's lossy compression isn't really noticed in the graduations of the image. Lossless compression, such as GIF and PNG use, do better on images which have fewer colors, or would suffer from lossy blending.
PNG = "Please No GIFs"
I use Netscape 3.04.
Netscape 4.X sucks because of bugs.
Opera still seems to crash a lot, but maybe it's better today.
Mozilla is coming along, but it's still slow and buggy.
Which one do you suggest I use today on Linux?
It just dawned on me. Unisys and AccuWeather are competing providers of weather data, such as value added weather radar feeds. So my suspicion is that this may be more than just trying to get huge royalties. It may also be to try and cripple a competitor. I didn't see any mention of this in the CNET article, but I think it's important enough to bring up. It may even be relevant and further show why so many patents are really bad tools to put in the hands of business. It could help explain why they wanted so much from AccuWeather.