Not to worry. IBM can't really use Linux without helping Linux. My impression is that IBM is in this for the long haul, with Linux ranging from network appliances to 64-bit mainframes. Replacing dumb terminals (isn't that what your Windoze box really is?) comes somewhat later. The real money comes if IBM can leverage ancient COBOL systems into the 21st century. Lotsa luck! You'll need it.
Easiest way to visualize aliasing. Imagine a perspective view of an infinite black-and-white checkerboard receding off into the horizon. In the foreground, you see nice squares. In the background, you see unusual artifacts due to rounding effects which determine whether a pixel is black or white. It's called aliasing because high-frequency effects show up at a different (lower) frequency.
If you want to keep the integrity of the font, it is much more important to anti-alias small point sizes. Bitmapped fonts are carefully designed to look self-consistent within a particular point size, but are very inconsistent from size to size.
Characteristics like relative boldness cannot be preserved by bitmapped fonts at nearly equal point sizes. Line weights are 1, 2, possibly 3 pixels. Anti-aliasing takes advantage of shades of gray on the edges to give the effect of a resolution much greater than actual.
Microsoft's rationale is probably that at small point sizes you can't really tell what the font looks like, so any vague approximation that looks readable will do. At larger point sizes you can actually tell what the font is supposed to look like, and the jaggies can no longer be hidden by distorting the typeface.
Yep. That sounds like OpenBSD. They have closed many holes that nobody knows about. Not all of them, I'm sure, but if they find one, they try to close all similar holes. FreeBSD seems to be playing a good game of catch-up.
>just another typical slashdot knee-jerk witchhunt that is completely unfounded.
Maybe that's why I read/. (at -1 yet).
I have no problem with giving the authors a bit of time to fix the problem before making it public, but I know that I would much rather read about a potential problem that experience it first-hand. Keeping bugs and exploits secret doesn't really work very well.
>As this list proves,
Try that idea of a proof in a math (or logic) course.
>cutting computer-related unproductive time by as much as 41 percent.
No, I do not want to reduce my./ reading time.
>the average system uptime of Windows 2000 Professional was over 50 times that of Windows 98 and 17 times that of Windows NT Workstation 4.0.
Then why are Windows 98 and NT 4.0 so bad? And now Windows 2000 is suddenly so good??? At this point I'd say that RedHat 7.0 is almost as stable as RedHat 4.2. Can't really tell. They don't go down often enough to make a comparison.
>Mobile computing is simpler and more efficient
Right. Leave your computer, and it's files at home or work, and securely run programs on it from elsewhere as different users? Simultaneously!
>comprehensive security features...
Does this mean that my browsing/. would be secure with Windows 2000?
Nope, the analogy is pretty good. It is always much easier to destroy than to create.
Considering vehicle weight, probably better to overinflate slightly rather than underinflate slightly. If the goons in the tire shop know that, then maybe everybody is a tad safer.
... but the meaning is lost.
The real trick is to distinguish between code that is bad and code that you think is bad.
[usually because I'm not used to how it goes about solving the problem]
It's somewhat like judging German grammar from a knowledge of English grammar.
Substituting "read" for "figure out" glosses over the difficulties of understanding something foreign. It's just not that easy.
Finally, this illustrates a problem with rewriting something without carefully looking. It's far too easy to lose the original purpose of the system in the process of cleaning up just what you understand. The parent post is not clean and smooth-flowing, and maybe that is part of the point (s)he is making. It would take a far better wordsmith than I to clean it up without losing its value.
Rewrite it, but do NOT change the real system. One of two things will happen. Most likely, you find where the cans of worms are, find that the existing system is more complex and complicated than you thought and duct tape and chewing gum is the answer. Possibly, the rewrite is definitively better than the original. Only then should you or management commit to doing something that maybe shouldn't even be started.
In many cases, the best way to understand something is to program it. In many cases, keep the understanding, dump the program.
>>If by deleting code you're adding functionality, then the system needs a rewrite.
I haven't seen that before, but that looks like the simplest and best test imaginable. The situation happens because code that has been added to increase functionality has actually had the opposite effect. In that case you stand a very good chance of understanding _everything_ the system is doing that it should be doing, which is the sine qua non for redesigning something.
It can be fascinating to watch the programming go away and the functionality go up. If you haven't seen it, you wouldn't believe it.
Ugly. Extremely effective criterion for changing something.
Nope. He's right. You can replace a bad design completely by a succession of tiny incremental changes. Mother Nature has been doing it for a few billion years.
An impression from long ago that a lot of problems come from trying to rescue bad code.
Rewriting is better if you can dominate the design of the old system (much easier said than done). The old system with its cruft has the advantage that it has been tuned, that the bugs that matter have been squashed at the expense of bugs that do not matter. Most likely, by now, nobody knows or understands what the old system is or should be doing.
If (when) you rewrite it, you MUST understand it better than the original authors plus the accumulation of bug-fixes. You do have one thing going in your favor. Almost certainly the old system is wasting a lot of resources (including or especially program complexity) attempting to solve non-problems. If you can identify several of these, you can un-level the playing field enough so that a rewrite is feasible.
>>Lets get in perspective, this IS serious news for Hotmail users and anyone trying to get past a DNS look-up area.
Like anyone trying to go through MSN dialup to anywhere else.
riason de etre. (sp?)
reason to be
reason for existence
without this, nothing.
Somehow I think this gives an idea of the future of.NET
Msn.com isn't down. Neither is Microsoft.com. What is down is all four (4) of MSN's DNS servers, so that anything that is relying on those name servers is effectively disconnected from the internet. This is posted on Internet Explorer running on NT4 through a dialup connection to MSN. The only reason this works is that I have entries for slashdot.org in admin$\system32\drivers\etc\hosts.
Just like with the LoveBug,/. seems to be the only available place with current information for severe problems with Microsoft software.
1. Everybody likes to gripe. At least the gripes are what are heard.
2. It does function as a wake-up call to use a bit of caution instead of blindly blundering on. It also gives a bit of a clue as to what to look out for.
Hmmm. Compaq Office. Sell the (supported) binaries. Give away the source (GPL).
I think most consumers would be willing to buy what they could download for free.
Ultimately, Open Source means that "You've got the source. Find and fix the problem. Send us your patches and if we like them enough, we will consider putting them into the next release." Paying a bit for a phone# and some hand-holding seems reasonable.
Attempting to privatize something GPL's seems like a bad idea even if it were ethical and moral, since it would isolate itself from the mainstream.
Seems like a Relational database system would have relations and a Transactional database system would have transactions.
With Transactions the code is to write first then check. If there are problems, you can always rollback.
With MySQL (other than with transactions on BDB), the update is atomic. It either succeeds or fails. It's a different paradigm and in many cases a better paradigm. You do need to do better analysis and coding, though.
Calculate the REAL cost of Exchange/Outlook.
Not to worry. IBM can't really use Linux without helping Linux. My impression is that IBM is in this for the long haul, with Linux ranging from network appliances to 64-bit mainframes. Replacing dumb terminals (isn't that what your Windoze box really is?) comes somewhat later. The real money comes if IBM can leverage ancient COBOL systems into the 21st century. Lotsa luck! You'll need it.
Easiest way to visualize aliasing. Imagine a perspective view of an infinite black-and-white checkerboard receding off into the horizon. In the foreground, you see nice squares. In the background, you see unusual artifacts due to rounding effects which determine whether a pixel is black or white. It's called aliasing because high-frequency effects show up at a different (lower) frequency.
If you want to keep the integrity of the font, it is much more important to anti-alias small point sizes. Bitmapped fonts are carefully designed to look self-consistent within a particular point size, but are very inconsistent from size to size.
Characteristics like relative boldness cannot be preserved by bitmapped fonts at nearly equal point sizes. Line weights are 1, 2, possibly 3 pixels. Anti-aliasing takes advantage of shades of gray on the edges to give the effect of a resolution much greater than actual.
Microsoft's rationale is probably that at small point sizes you can't really tell what the font looks like, so any vague approximation that looks readable will do. At larger point sizes you can actually tell what the font is supposed to look like, and the jaggies can no longer be hidden by distorting the typeface.
Yep. That sounds like OpenBSD. They have closed many holes that nobody knows about. Not all of them, I'm sure, but if they find one, they try to close all similar holes. FreeBSD seems to be playing a good game of catch-up.
>just another typical slashdot knee-jerk witchhunt that is completely unfounded. /. (at -1 yet).
Maybe that's why I read
I have no problem with giving the authors a bit of time to fix the problem before making it public, but I know that I would much rather read about a potential problem that experience it first-hand. Keeping bugs and exploits secret doesn't really work very well.
Seems like I've heard this stuff before.
./ reading time.
...
/. would be secure with Windows 2000?
>As this list proves,
Try that idea of a proof in a math (or logic) course.
>cutting computer-related unproductive time by as much as 41 percent.
No, I do not want to reduce my
>the average system uptime of Windows 2000 Professional was over 50 times that of Windows 98 and 17 times that of Windows NT Workstation 4.0.
Then why are Windows 98 and NT 4.0 so bad? And now Windows 2000 is suddenly so good??? At this point I'd say that RedHat 7.0 is almost as stable as RedHat 4.2. Can't really tell. They don't go down often enough to make a comparison.
>Mobile computing is simpler and more efficient
Right. Leave your computer, and it's files at home or work, and securely run programs on it from elsewhere as different users? Simultaneously!
>comprehensive security features
Does this mean that my browsing
Nope, the analogy is pretty good. It is always much easier to destroy than to create.
Considering vehicle weight, probably better to overinflate slightly rather than underinflate slightly. If the goons in the tire shop know that, then maybe everybody is a tad safer.
You have good reason to be nervous. Even a hint of supression and you would be safer if the exploits were published before the fixes!
Fortran, LISP, Algol, PL/I, Ada
I think various compilers for these use no C or Assembly.
So, relocate to Banf, or better, Jasper.
Public roads, streets, and sidewalks.
Official weights and measures.
Sucker bait. "than I" only looks like "I" is the object of a preposition. ....
... better wordsmith than me is a wordsmith
... but the meaning is lost.
The real trick is to distinguish between code that is bad and code that you think is bad.
[usually because I'm not used to how it goes about solving the problem]
It's somewhat like judging German grammar from a knowledge of English grammar.
Substituting "read" for "figure out" glosses over the difficulties of understanding something foreign. It's just not that easy.
Finally, this illustrates a problem with rewriting something without carefully looking. It's far too easy to lose the original purpose of the system in the process of cleaning up just what you understand. The parent post is not clean and smooth-flowing, and maybe that is part of the point (s)he is making. It would take a far better wordsmith than I to clean it up without losing its value.
Rewrite it, but do NOT change the real system. One of two things will happen. Most likely, you find where the cans of worms are, find that the existing system is more complex and complicated than you thought and duct tape and chewing gum is the answer. Possibly, the rewrite is definitively better than the original. Only then should you or management commit to doing something that maybe shouldn't even be started.
In many cases, the best way to understand something is to program it. In many cases, keep the understanding, dump the program.
>>If by deleting code you're adding functionality, then the system needs a rewrite.
I haven't seen that before, but that looks like the simplest and best test imaginable. The situation happens because code that has been added to increase functionality has actually had the opposite effect. In that case you stand a very good chance of understanding _everything_ the system is doing that it should be doing, which is the sine qua non for redesigning something.
It can be fascinating to watch the programming go away and the functionality go up. If you haven't seen it, you wouldn't believe it.
Ugly. Extremely effective criterion for changing something.
Rule of thumb (from 2nd generation mainframe days)
If one programmer can do it in one year, two programmers can do it in two years.
Nope. He's right. You can replace a bad design completely by a succession of tiny incremental changes. Mother Nature has been doing it for a few billion years.
An impression from long ago that a lot of problems come from trying to rescue bad code.
Rewriting is better if you can dominate the design of the old system (much easier said than done). The old system with its cruft has the advantage that it has been tuned, that the bugs that matter have been squashed at the expense of bugs that do not matter. Most likely, by now, nobody knows or understands what the old system is or should be doing.
If (when) you rewrite it, you MUST understand it better than the original authors plus the accumulation of bug-fixes. You do have one thing going in your favor. Almost certainly the old system is wasting a lot of resources (including or especially program complexity) attempting to solve non-problems. If you can identify several of these, you can un-level the playing field enough so that a rewrite is feasible.
>>Lets get in perspective, this IS serious news for Hotmail users and anyone trying to get past a DNS look-up area.
.NET
Like anyone trying to go through MSN dialup to anywhere else.
riason de etre. (sp?)
reason to be
reason for existence
without this, nothing.
Somehow I think this gives an idea of the future of
Msn.com isn't down. Neither is Microsoft.com. What is down is all four (4) of MSN's DNS servers, so that anything that is relying on those name servers is effectively disconnected from the internet. This is posted on Internet Explorer running on NT4 through a dialup connection to MSN. The only reason this works is that I have entries for slashdot.org in admin$\system32\drivers\etc\hosts. /. seems to be the only available place with current information for severe problems with Microsoft software.
Just like with the LoveBug,
1. Everybody likes to gripe. At least the gripes are what are heard.
2. It does function as a wake-up call to use a bit of caution instead of blindly blundering on. It also gives a bit of a clue as to what to look out for.
Hmmm. Compaq Office. Sell the (supported) binaries. Give away the source (GPL).
I think most consumers would be willing to buy what they could download for free.
Ultimately, Open Source means that "You've got the source. Find and fix the problem. Send us your patches and if we like them enough, we will consider putting them into the next release." Paying a bit for a phone# and some hand-holding seems reasonable.
Attempting to privatize something GPL's seems like a bad idea even if it were ethical and moral, since it would isolate itself from the mainstream.
Seems like a Relational database system would have relations and a Transactional database system would have transactions.
With Transactions the code is to write first then check. If there are problems, you can always rollback.
With MySQL (other than with transactions on BDB), the update is atomic. It either succeeds or fails. It's a different paradigm and in many cases a better paradigm. You do need to do better analysis and coding, though.
re Old El Paso.
I'd bet the best picante sauce IS made in New York City.