When you work on the core of X, on programs such as the X server, Xlib, and Xt, there is a practical reason not to use copyleft. The XFree86 group does an important job for the community in maintaining these programs, and the benefit of copylefting our changes would be less than the harm done by a fork in development. So it is better to work with the XFree86 group and not copyleft our changes on these programs. Likewise for utilities such as xset and xrdb, which are close to the core of X, and which do not need major improvements. At least we know that the XFree86 group has a firm commitment to developing these programs as free software.
you can find C++ source that simulates battles between up 30 attackers and up to 30 defenders. Then it prints out LaTeX source code for a nice table that lists
a) the probability that the attacker wins
b) _given_ that the attacker won, how many
armies would survive
... unless otherwise indicated, a client
SHOULD assume that the server will maintain a
persistent connection...
So Internet Explorer is correct when it assumes
that the connection is persistent, even without having seen a Connection: keep-alive.
Actually keep-alive is an obsolete token from HTTP 1.0; the only token used in HTTP 1.1 is "close". If the server did send a "close" token,
Internet Explorer would be violating HTTP 1.1 in sending the second request, but it wouldn't be violating TCP.
If the server calls shutdown() without sending
a Connection: close, it is not behaving as it SHOULD according to rfc2616, section 8.1.2.1:
If the server chooses to close the connection
immediately after sending the response,
it SHOULD send a
Connection header including
the connection-token close
If the FIN hasn't arrived at the time IE
does the read() in step 4 above, it has no
way of knowing that the connection was shut down
by the server. If the read provided enough content
that IE could send a new request, there is no reason it shouldn't do so.
I may be missing something, but it seems to me that IE is behaving exactly like it should, and that the packet traces actually just indicate that it has a good quality HTTP 1.1 implementation.
Re:This is not about tetris as you know it
on
Tetris Is Hard: NP-Hard
·
· Score: 2, Informative
>... a relatively simple dynamic program solves > the case of a constant-size gameboard in time > polynomial in the number of pieces
Here is one relatively simple dynamic programming solution.
Suppose the game board has size k. Each cell in the game board can be either on or off, so we can represent the state of the board in a bit vector with k bits. Now define a recursive procedure that takes a sequence of n blocks and a state of the game board as input:
def solve (c, B_1,..., B_n):
if n == 1:
(given c):
find best placement of B_1;
find the score you get with
that placement
return ([B_1], score)
best_so_far = ([], 0)
for each possible placement p of B_1:
c' = c with p applied
s = solve (c, B_2,..., B_n);
if (s is better than best_so_far)
best_so_far = s
return best_so_far
This will calculate the optimal solution, but unfortunately the program runs in exponential time. To fix that, observer that solve will only be called with 2^k * n different sets of parameters. This means that since the function only does constant work when we disregard the recursive calls, caching the results of calls to the procedure in a table of size 2^k * n, we can make it run in time O(n).
Note however that the O here is hiding a constant of size 2^k, where k is the size of the game board. This means that this algorithm, while nominally O(n), is not practical when the gameboard gets even moderately big.
I generally agree with you, but there are cases where threads can improve performance, even with a single CPU.
Suppose a server runs a poll()/select() loop and then gets hit by something that causes some rarely used code to be paged in (maybe an error handler). The server will block and do nothing useful until the disk i/o is finished.
In cases like that, where there is a possibility of blocking behaviour, distributing the work across a few threads is an advantage, but don't make the mistake of associating one thread with one job.
The image loaders in the gdkpixbuf library included with gtk+ 2.0 were
tested with random data. This caught a lot of bugs, including some in
the standard image manipulation libraries.
Just generating random data and trying to load it caught a lot of
bugs, but even more effective was to take a valid image and
modify the bytes in it at random, and then try to load it.
Of course, the reason this was so effective, is that the loaders would
get mostly what they expect, and then suddenly something illegal. This
is the kind of thing you tend to forget about when you write code.
Since it is so easy to attack your program with random data, this kind
of testing gives you a lot of bang for the buck, but on the other
hand, the bugs it find may not always be those that are likely to
occur in practice.
> Do you know how Windows currently sets these
> settings automatically?
I think there is a table in TrueType fonts that tells the sizes the font can be usefully antialiased. I'd guess Windows simply uses that, but I don't know for sure.
> the screen-shot still shows the flaws of antialiasing under Linux
You are right that the k and the W don't look good, but that does not have anything to do with your kernel, but rather the fact that Verdana and Times should not be antialiased at that size. Antialiasing these fonts at that size with hinting enabled is really font murder.
You don't want hinting enabled with antialiasing at that size, because hinting is a way to distort the fonts so that they can be rendered at very low resolution, and antialiasing is essentially a cheasy way to increase resolution. That is why you see the weird "k": the hints don't expect the resolution to be this high.
Here is a piece of an actual screenshot, showing Verdana mostly un-antialiased, and antialiased in the preview box in the fontselector.
As others pointed out, to match Windows in quality you will need high quality fonts. Of couse, the MS/Monotype fonts (Ariel, Verdana, Trebuchet, etc) are well done and especially well-hinted (if you don't antialias them at sizes where they shouldn't be), but actually the Luxi fonts that are shipping with XFree86 4.2 are not bad - their hints just need some work.
For fun, I hinted Luxi Sans (with the Gimp) at a few sizes. This is not a real screenshot, but it does show how it could look with better hints. (Note that the bold antialiased Luxi Serif is not hinted at all - a bit of careful hinting would probably improve it somewhat).
> anti-aliasing algorithms itself could
> probably be much improved, although the
> Freetype page points out that Apple patents
This is nonsens. The Apple patent covers the interpreter for the hints in TrueType fonts. Most distributions turn the interpreter on, regardless of the patent, and in fact the bad rendering of the "k" that you complain about is there precisely because both interpreter and antialiasing were used.
I'm talking about tearing between the frame and client, not flicker inside the client.
Yes, that's what I am talking about too. The tearing between frame and client is much less with tk than with gtk+ (CVS head). I think this is a matter of how many configure events the toolkit can respond to per time, and so an actual speed issue (or a slow CPU issue in my case).
With gtk+ 1.2, the tearing between client and frame is much less (as far as I can tell), but of course the client-internal tearing/flicker is really terrible.
The server-side backing store is better because it would be for the window manager frame and all subwindows.
I see, thanks.
(But wouldn't such double buffering lead to a "stuttering window" instead of tearing if the toolkit couldn't keep up with the configure events?)
Similarly when opaque resizing a window; it has nothing to do with quantization or speed, the problem is that the window manager frame and the client are not resized/drawn at the same time resulting in a "tearing" effect. This would be visible no matter how fast you make things.
With the tk toolkit, FVWM 2.4 and crappy hardware, I see almost no tearing. It is certainly nothing compared to the tearing that gtk+ produces.
And while I haven't looked at tk source code in detail, its widgets certainly look double buffered to me: they don't flicker at all, not even the small amount of flicker you get without double buffering and NorthWest gravity.
It could be done with an extension allowing us to push a backing store on a single X window during a resize, for example.
Why would this be substantially better than what gtk does now:
[create pixmap]
[draw on pixmap]
[blit pixmap to screen]
[delete pixmap]
Sure, the server would have the extra knowledge that the pixmap would only be used for backing store, so it coult possibly optimize a bit, but would it really matter?
The necessary shared libraries needed by the program are searched for in the following order
...
Using the environment variable LD_LIBRARY_PATH.
Except if the executable is a setuid/setgid binary,
in which case it is ignored.
...
and later:
LD_PRELOAD:
A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before
all others. This can be used to selectively override functions in other shared libraries. For
setuid/setgid ELF binaries, only libraries in the
standard search directories that are also setuid
will be loaded.
Slashdot Mirror
Don't believe the promises random people make on messageboards about what will be in the next version of gtk+.
The facts are:
- gtk+ 2.4 will have a new file selector
- gnome 2.4 will use gtk+ 2.2
- gnome 2.6 will use gtk+ 2.4
- hopefully most applications will be ported ver to the new file selector by gnome 2.6
Smith & Co. It's a Danish brand of bicycles.
At
http://www.daimi.au.dk/~sandmann/risk.cc
you can find C++ source that simulates battles between up 30 attackers and up to 30 defenders. Then it prints out LaTeX source code for a nice table that lists
a) the probability that the attacker wins
b) _given_ that the attacker won, how many
armies would survive
This thread has some explanation of why opaque resizing sucks.
-
-
-
I may be missing something, but it seems to me that IE is behaving exactly like it should, and that the packet traces actually just indicate that it has a good quality HTTP 1.1 implementation.Section 8.1.2 in rfc 2616:
So Internet Explorer is correct when it assumes that the connection is persistent, even without having seen a Connection: keep-alive.Actually keep-alive is an obsolete token from HTTP 1.0; the only token used in HTTP 1.1 is "close". If the server did send a "close" token, Internet Explorer would be violating HTTP 1.1 in sending the second request, but it wouldn't be violating TCP.
If the server calls shutdown() without sending a Connection: close, it is not behaving as it SHOULD according to rfc2616, section 8.1.2.1:
If the FIN hasn't arrived at the time IE does the read() in step 4 above, it has no way of knowing that the connection was shut down by the server. If the read provided enough content that IE could send a new request, there is no reason it shouldn't do so.
> the case of a constant-size gameboard in time
> polynomial in the number of pieces
Here is one relatively simple dynamic programming solution.
Suppose the game board has size k. Each cell in the game board can be either on or off, so we can represent the state of the board in a bit vector with k bits. Now define a recursive procedure that takes a sequence of n blocks and a state of the game board as input:This will calculate the optimal solution, but unfortunately the program runs in exponential time. To fix that, observer that solve will only be called with 2^k * n different sets of parameters. This means that since the function only does constant work when we disregard the recursive calls, caching the results of calls to the procedure in a table of size 2^k * n, we can make it run in time O(n).
Note however that the O here is hiding a constant of size 2^k, where k is the size of the game board. This means that this algorithm, while nominally O(n), is not practical when the gameboard gets even moderately big.
TeX can produce the error
"Interwoven alignment preambles are not allowed"
and all the TeXbook has to say about it is:
"If you have been so devious as to get this
message, you will understand it, and you will
deserve no sympathy"
I generally agree with you, but there are cases where threads can improve performance, even with a single CPU.
Suppose a server runs a poll()/select() loop and then gets hit by something that causes some rarely used code to be paged in (maybe an error handler). The server will block and do nothing useful until the disk i/o is finished.
In cases like that, where there is a possibility of blocking behaviour, distributing the work across a few threads is an advantage, but don't make the mistake of associating one thread with one job.
Just generating random data and trying to load it caught a lot of bugs, but even more effective was to take a valid image and modify the bytes in it at random, and then try to load it.
Of course, the reason this was so effective, is that the loaders would get mostly what they expect, and then suddenly something illegal. This is the kind of thing you tend to forget about when you write code.
Since it is so easy to attack your program with random data, this kind of testing gives you a lot of bang for the buck, but on the other hand, the bugs it find may not always be those that are likely to occur in practice.
> Do you know how Windows currently sets these
> settings automatically?
I think there is a table in TrueType fonts that tells the sizes the font can be usefully antialiased. I'd guess Windows simply uses that, but I don't know for sure.
Btw, may I recommend Microsoft's typography pages. There is a lot of useful information there.
> the screen-shot still shows the flaws of antialiasing under Linux
You are right that the k and the W don't look good, but that does not have anything to do with your kernel, but rather the fact that Verdana and Times should not be antialiased at that size. Antialiasing these fonts at that size with hinting enabled is really font murder.
You don't want hinting enabled with antialiasing at that size, because hinting is a way to distort the fonts so that they can be rendered at very low resolution, and antialiasing is essentially a cheasy way to increase resolution. That is why you see the weird "k": the hints don't expect the resolution to be this high.
Here is a piece of an actual screenshot, showing Verdana mostly un-antialiased, and antialiased in the preview box in the fontselector.
As others pointed out, to match Windows in quality you will need high quality fonts. Of couse, the MS/Monotype fonts (Ariel, Verdana, Trebuchet, etc) are well done and especially well-hinted (if you don't antialias them at sizes where they shouldn't be), but actually the Luxi fonts that are shipping with XFree86 4.2 are not bad - their hints just need some work.
For fun, I hinted Luxi Sans (with the Gimp) at a few sizes. This is not a real screenshot, but it does show how it could look with better hints. (Note that the bold antialiased Luxi Serif is not hinted at all - a bit of careful hinting would probably improve it somewhat).
> anti-aliasing algorithms itself could
> probably be much improved, although the
> Freetype page points out that Apple patents
This is nonsens. The Apple patent covers the interpreter for the hints in TrueType fonts. Most distributions turn the interpreter on, regardless of the patent, and in fact the bad rendering of the "k" that you complain about is there precisely because both interpreter and antialiasing were used.
Yes, that's what I am talking about too. The tearing between frame and client is much less with tk than with gtk+ (CVS head). I think this is a matter of how many configure events the toolkit can respond to per time, and so an actual speed issue (or a slow CPU issue in my case).
With gtk+ 1.2, the tearing between client and frame is much less (as far as I can tell), but of course the client-internal tearing/flicker is really terrible.
I see, thanks.
(But wouldn't such double buffering lead to a "stuttering window" instead of tearing if the toolkit couldn't keep up with the configure events?)
With the tk toolkit, FVWM 2.4 and crappy hardware, I see almost no tearing. It is certainly nothing compared to the tearing that gtk+ produces.
And while I haven't looked at tk source code in detail, its widgets certainly look double buffered to me: they don't flicker at all, not even the small amount of flicker you get without double buffering and NorthWest gravity.
Why would this be substantially better than what gtk does now:
[create pixmap]
[draw on pixmap]
[blit pixmap to screen]
[delete pixmap]
Sure, the server would have the extra knowledge that the pixmap would only be used for backing store, so it coult possibly optimize a bit, but would it really matter?