Which is the point -- it must be a option to be with, and an option to be without -- given the former, that latter is trivial, the X peoples' problem is the other way around.
Sorry about the messed up previous message -- HTML formatting got put on by accident (but this time on purpose).
I personally see nothing much wrong with implementing anti-aliased fonts, not implementing them as an extension (the creeping featurism can easily be solved by removing most of the legacy X font support and placing it into a demand loaded module).
The rewriting of applications talked about is less than people say, since modifying GTK and Qt alone would do most of the work for most applications (though Motif maybe a lost cause (in this respect -- it's a lost cause in general anyhow)).
That said, does anyone have any pointers to discussions detailing how exactly AA would break applications?
Also, for use on laptops, adding a 19" 1280x1024 monitor isn't really an option -- and being able to use both AA and sub-pixel AA would be useful -- the ability to have AA should be considered far more important than actually having AA (think maximal generality) such that it could be added and removed transparently to the applications using the display. Given that UN*X is known for its tendency to have its tools used in ways not originally designed for them (e.g. using a tar-tar pipe to recursively copy a directory and preserve the file dates), ruling a feature out becuase "I can just get a higher res display" seems to be very short sighted.
>640x480 is just a PITA with X, for reasons other >than fonts. True -- X has a reputation for inflexibility. (Why does it ALWAYS have to work at pixel level?)
I personally see nothing much wrong with implementing anti-aliased fonts, not implementing them as an extension (the creeping featurism can easily be solved by removing most of the legacy X font support and placing it into a demand loaded module). The rewriting of applications talked about is less than people say, since modifying GTK and Qt alone would do most of the work for most applications (though Motif maybe a lost cause (in this respect -- it's a lost cause in general anyhow)). That said, does anyone have any pointers to discussions detailing how exactly AA would break applications? Also, for use on laptops, adding a 19" 1280x1024 monitor isn't really an option -- and being able to use both AA and sub-pixel AA would be useful -- the ability to have AA should be considered far more important than actually having AA (think maximal generality) such that it could be added and removed transparently to the applications using the display. Given that UN*X is known for its tendency to have its tools used in ways not originally designed for them (e.g. using a tar-tar pipe to recursively copy a directory and preserve the file dates), ruling a feature out becuase "I can just get a higher res display" seems to be very short sighted.
After being bought up by Scottish Telecom. Demon really have gone downhill. This is just another example of the sad decline of one of the original pioneers of flat rate internet access.
This is reasonably simple given a good OO architecture
Basically, you just take the interface for the entire scrollbar, subclass it, and then change (override) the routines that handle the actual positioning of buttons -- applications drawing the scrollbars are non the wiser. (Remember that the container will get size etc. attributes from the scrollbar, allocate screen space, and then pass any redrawing of the area taken by the widget to the widget (which then handles the drawing and mouse captuting on its 'turf' from then on))
The problem with GTK themes is the lack of a decent OO framework (p.s. OO UI programming in C is never a good idea if you can avoid it -- C++ is not really suitable, but you can get by with it (it should be though of as the absolute bottom line choice for an OO language -- anything worse should not be used for OOP)
Such a comment is to be expected when you leave your employer under anything other than friendly terms -- I imagine that Raster won't bash RH much further (if he does, then you are correct, if not then you should give him the BOTD)
So far as window management standards go, I hope that Raster can get together with (at least) the KDE people, and use E to set the new standard. (If he were to team up with Alfredo, so far as interoperabiliy was concerned, to the point that E becomes a drop-in replacement for WM and vice versa, then things will get interesting)
> We have the Gnome coordinator slagging off KDE Since the justification for GNOME is a political one, GNOME should be ignored with similar justification -- Miguel needs to grow up.
So far as GPL-all-the-way is concerned, we really need to stop and ask ourselves whether that is so much of a good idea -- are we more interested in the software being free? or anti-proprietary?
I, personally, am for it being free over a-p, and find RMS's agressive (GPL you libraries) stance to be short sighted, and in contradiction with his goals (first, GPL'd libraries produce the need for a replacement library for everyone else, second, the 'It's my software, its my license' type whining is exactly what he set out to OPPOSE -- see the Stockholm speech)
p.s. I was impressed with GNOME until I took a look at the memory consumption -- now I just run WMaker (but use the GNOME terminal)
So far as the 'wish Qt was GPL' bit -- that is silly, libraries MUST allow for non-GPL development (bear in mind that there can be no GPL-compatible copyleft that can 'survive' contact with GPL'd code (the GPL must take precidence)). Sure, GPL-everything seems an attractive proposition for the immediate future, but look a few years ahead and things look a little different. Never forget that Free Software is more than (and not necessarily the same thing as) GPL'd Software (trying to have a you-can-do-what-you-like-with-it and you-cant-take-advantage-of-it license is trying to have your cake and eat it -- not possible).
As I imagine you well know, inflicting X on someone with less than a pentium is not pretty.
It would be interesting if E could be lined up as a build in WM system for a non-X system (i.e run in the displayserver). Sure the theme programming language needs a complete rewrite for this purpose, but... (that said, what I am basically describing is more like Berlin, though an abstract display architecture sans CORBA would be nice)
The implementation (for the base OpenGL features) is probably similar, I would expect that the major differences between the chipset (apart from speed) are the added features, so the drivers will probably share a lot of code.
We can't really judge the general speed...
on
Mozilla M6 released
·
· Score: 1
I very much doubt that they have done overall speed optimisations yet. The layout engine itself is very fast and very stable. Don't judge it as if it a release version -- it isn't.
This is also a good (in name at least) place to look as to where to start setting up such a legal fund. What WOULD be a good idea (if the funds could be generated for it) is to sort out the legal situation in as many countries as possible, and let everybody know where they stand w.r.t the law of their land (I'm a UK citizen).
I had a cyrix once (didn't last long, went back under warranty, and I got it refunded and bought a pentium).
When the 6x86 was brought out, Cyrix published benchmarks of 'floating-point applications'. They claimed that raw benchmarks were not truly representative, and so used non-fp-intensive, integer-intensive applications instead (so that the Cyrix P166+ came to about 1% ahead of an iP150). Running quake was a joke (most of the speed increase over my old 486/66 was due to the PCI graphics card (PCI Grafixstar 600 as opposed to an ISA Cirrus 5422). An iP90 happily outpaced it at FP intensive applications.
A frient bought a MII-300 (@233Mhz), and a similar story resulted (it getting slaughtered by a K6-233 with a slower graphics card).
I heard recently about theories concerning 'tension' of space -- and indications that, to some degree, Einstein was right to add the cosmological constant.
When people talk about the edge of the universe (and sometimes qualify it by saying 'observable universe'), they are referring to the 'shell' from which a photon of light, if it started travelling at the start of the universe, would have just reached us. In essence, it provides a limit to what we can see or be affected by
If you travel indefinitely in one particular direction, then you will obviously not meet the edge, since (naively) to stop it 'pulling away' you must travel at the speed of light (Since that is the speed at which it is receeding)
If I recall, space (if closed) can be thought of as an expanding 4D hypersphere
This IS news, but only because the record went over 1TB. If they set one over 2TB, that will be news, and the same if they do it over, say, 5TB -- 1TB, like the 1TFLOP in supercomputing (though less significant) is important, because another order of magnitude of transfers has been reached.
Also, EGCS c++ has some bugs...
on
GCC-2.95 in July
·
· Score: 1
I think that you meant 331372 bytes and 3296 bytes.
On topic: the reason that I would consider this a long shot, is that
Making that many 'abstract' definitions will not go down well with a judge.
the prior art (as mentioned somewhere else) needs to satisfy nearly all of the claims listed -- where nearly means within obviousness of the patented apparatus.
Its not as simple as saying that 'this bit has this bit, and that has that' -- it has to be clear prior art.
I doubt that the larger cache on a PII would make that much of a difference
consider that if you're dealing with a 20Mb image, then the cache will do very little so far as reading is concerned, and the 512Kb will only make an effective difference over the 128Kb cache if you are writing back between 64Kb and 256Kb of changed data -- otherwise the cache will be force to continuously flush data, and be no help writing, (and not be able to do much with reading back either) OR (on the
That said, I don't know that much about the current caches that are used in processors, so I could well be wrong about this -- anyone care to comment?
Cyrix chips may make wonderful hobs to cook on, but they really dont make much of a CPU -- after my brief encounter, I would never touch a Cyrix again, and I know a few others who wouldn't tough them either.
Slashdot Mirror
Which is the point -- it must be a option to be with, and an option to be without -- given the
former, that latter is trivial, the X peoples'
problem is the other way around.
I personally see nothing much wrong with implementing anti-aliased fonts, not implementing them as an extension (the creeping featurism can easily be solved by removing most of the legacy X font support and placing it into a demand loaded module).
The rewriting of applications talked about is less than people say, since modifying GTK and Qt alone would do most of the work for most applications (though Motif maybe a lost cause (in this respect -- it's a lost cause in general anyhow)).
That said, does anyone have any pointers to discussions detailing how exactly AA would break applications?
Also, for use on laptops, adding a 19" 1280x1024 monitor isn't really an option -- and being able to use both AA and sub-pixel AA would be useful -- the ability to have AA should be considered far more important than actually having AA (think maximal generality) such that it could be added and removed transparently to the applications using the display. Given that UN*X is known for its tendency to have its tools used in ways not originally designed for them (e.g. using a tar-tar pipe to recursively copy a directory and preserve the file dates), ruling a feature out becuase "I can just get a higher res display" seems to be very short sighted.
>640x480 is just a PITA with X, for reasons other >than fonts. True -- X has a reputation for inflexibility. (Why does it ALWAYS have to work at pixel level?)
I personally see nothing much wrong with implementing anti-aliased fonts, not implementing them as an extension (the creeping featurism can easily be solved by removing most of the legacy X font support and placing it into a demand loaded module). The rewriting of applications talked about is less than people say, since modifying GTK and Qt alone would do most of the work for most applications (though Motif maybe a lost cause (in this respect -- it's a lost cause in general anyhow)). That said, does anyone have any pointers to discussions detailing how exactly AA would break applications? Also, for use on laptops, adding a 19" 1280x1024 monitor isn't really an option -- and being able to use both AA and sub-pixel AA would be useful -- the ability to have AA should be considered far more important than actually having AA (think maximal generality) such that it could be added and removed transparently to the applications using the display. Given that UN*X is known for its tendency to have its tools used in ways not originally designed for them (e.g. using a tar-tar pipe to recursively copy a directory and preserve the file dates), ruling a feature out becuase "I can just get a higher res display" seems to be very short sighted.
After being bought up by Scottish Telecom. Demon really have gone downhill. This is just another example of the sad decline of one of the original pioneers of flat rate internet access.
This is reasonably simple given a good OO architecture
Basically, you just take the interface for the entire scrollbar, subclass it, and then change (override) the routines that handle the actual positioning of buttons -- applications drawing the scrollbars are non the wiser. (Remember that the container will get size etc. attributes from the scrollbar, allocate screen space, and then pass any redrawing of the area taken by the widget to the widget (which then handles the drawing and mouse captuting on its 'turf' from then on))
The problem with GTK themes is the lack of a decent OO framework (p.s. OO UI programming in C is never a good idea if you can avoid it -- C++ is not really suitable, but you can get by with it (it should be though of as the absolute bottom line choice for an OO language -- anything worse should not be used for OOP)
Such a comment is to be expected when you leave your employer under anything other than friendly terms -- I imagine that Raster won't bash RH much further (if he does, then you are correct, if not then you should give him the BOTD)
So far as window management standards go, I hope that Raster can get together with (at least) the KDE people, and use E to set the new standard. (If he were to team up with Alfredo, so far as interoperabiliy was concerned, to the point that E becomes a drop-in replacement for WM and vice versa, then things will get interesting)
> We have the Gnome coordinator slagging off KDE
Since the justification for GNOME is a political
one, GNOME should be ignored with similar
justification -- Miguel needs to grow up.
So far as GPL-all-the-way is concerned, we really
need to stop and ask ourselves whether that is
so much of a good idea -- are we more interested
in the software being free? or anti-proprietary?
I, personally, am for it being free over a-p,
and find RMS's agressive (GPL you libraries)
stance to be short sighted, and in contradiction
with his goals (first, GPL'd libraries produce
the need for a replacement library for everyone
else, second, the 'It's my software, its my
license' type whining is exactly what he set
out to OPPOSE -- see the Stockholm speech)
p.s. I was impressed with GNOME until I took
a look at the memory consumption -- now I just
run WMaker (but use the GNOME terminal)
So far as the 'wish Qt was GPL' bit -- that is
silly, libraries MUST allow for non-GPL
development (bear in mind that there can be no
GPL-compatible copyleft that can 'survive'
contact with GPL'd code (the GPL must take
precidence)). Sure, GPL-everything seems an
attractive proposition for the immediate future,
but look a few years ahead and things look a
little different. Never forget that Free Software
is more than (and not necessarily the same thing
as) GPL'd Software (trying to have a you-can-do-what-you-like-with-it and you-cant-take-advantage-of-it license is trying
to have your cake and eat it -- not possible).
As I imagine you well know, inflicting X on
someone with less than a pentium is not pretty.
It would be interesting if E could be lined up
as a build in WM system for a non-X system (i.e
run in the displayserver). Sure the theme
programming language needs a complete rewrite
for this purpose, but... (that said, what
I am basically describing is more like Berlin,
though an abstract display architecture sans
CORBA would be nice)
The implementation (for the base OpenGL features) is probably similar, I would expect that the major differences between the chipset (apart from speed) are the added features, so the drivers will probably share a lot of code.
I very much doubt that they have done overall speed optimisations yet. The layout engine itself is very fast and very stable. Don't judge it as if it a release version -- it isn't.
The organisation (or what ever there is of it these days) that was about this type of thing, is the League for Programming Freedom.
see http://lpf.ai.mit.edu
This is also a good (in name at least) place to look as to where to start setting up such a legal fund. What WOULD be a good idea (if the funds could be generated for it) is to sort out the legal situation in as many countries as possible, and let everybody know where they stand w.r.t the law of their land (I'm a UK citizen).It would be nice to have a (moderated) /.)
forum that people could discuss how to actually
make such a format. (a little like ask
Something that would be longer lived than the
news.
I had a cyrix once (didn't last long, went back
under warranty, and I got it refunded and bought
a pentium).
When the 6x86 was brought out, Cyrix published
benchmarks of 'floating-point applications'. They
claimed that raw benchmarks were not truly
representative, and so used non-fp-intensive,
integer-intensive applications instead (so that
the Cyrix P166+ came to about 1% ahead of an
iP150). Running quake was a joke (most of the
speed increase over my old 486/66 was due to
the PCI graphics card (PCI Grafixstar 600 as
opposed to an ISA Cirrus 5422). An iP90
happily outpaced it at FP intensive applications.
A frient bought a MII-300 (@233Mhz), and a
similar story resulted (it getting slaughtered
by a K6-233 with a slower graphics card).
In short, NEVER buy a Cyrix.
I heard recently about theories concerning
'tension' of space -- and indications that,
to some degree, Einstein was right to add
the cosmological constant.
When people talk about the edge of the universe (and sometimes qualify it by saying 'observable universe'), they are referring to the 'shell' from which a photon of light, if it started travelling at the start of the universe, would have just reached us. In essence, it provides a limit to what we can see or be affected by
If you travel indefinitely in one particular direction, then you will obviously not meet the edge, since (naively) to stop it 'pulling away' you must travel at the speed of light (Since that is the speed at which it is receeding)
If I recall, space (if closed) can be thought of as an expanding 4D hypersphere
This IS news, but only because the record went over 1TB. If they set one over 2TB, that will be news, and the same if they do it over, say, 5TB -- 1TB, like the 1TFLOP in supercomputing (though less significant) is important, because another order of magnitude of transfers has been reached.
I think that you meant 331372 bytes and 3296 bytes.
Take a look at
http://www.cco.caltech.edu/~ja fl/jx/egcs_complain.html
Try either of
make menuconfig
make dep
I know that one of these does the trick (or at
least it did for my housemate)
Can anybody improve on this?
Just wondering...
On topic: the reason that I would consider this a long shot, is that
- Making that many 'abstract' definitions will not go down well with a judge.
- the prior art (as mentioned somewhere else) needs to satisfy nearly all of the claims listed -- where nearly means within obviousness of the patented apparatus.
Its not as simple as saying that 'this bit has this bit, and that has that' -- it has to be clear prior art.Anybody know of any UK suppliers?
I doubt that the larger cache on a PII would make that much of a difference
consider that if you're dealing with a 20Mb image, then the cache will do very little so far as reading is concerned, and the 512Kb will only make an effective difference over the 128Kb cache if you are writing back between 64Kb and 256Kb of changed data -- otherwise the cache will be force to continuously flush data, and be no help writing, (and not be able to do much with reading back either) OR (on the
That said, I don't know that much about the current caches that are used in processors, so I could well be wrong about this -- anyone care to comment?
Faster... until you need the memory bandwidth.
If you can do without it, then fine.
If not, then you'll need the overclocked 450a's
so that you can get a 100Mhz memory bus.
Cyrix chips may make wonderful hobs to cook on, but they really dont make much of a CPU -- after my brief encounter, I would never touch a Cyrix again, and I know a few others who wouldn't tough them either.