>Problem: X11 is inefficient. > >Answer: No, it isn't. X11 is pretty damned >efficient. Today's pixmap-laden interfaces can >run much more slowly over a network than the >original interfaces, whicch were mostly big, >flat-color rectangles, but the same is true of >VNC and similar.
Do you mean that X is efficient for flat-color rectangles but inefficient for pixmap-laden interfaces?
If so, the definition of efficiency needs to be updated. Today, efficiency means efficiency dealing with pixmap-laden interfaces. Anything is efficient for flat-color rectangles.
This efficiency is not comparative. "VNC and other interfaces are inefficient too" is not a good excuse for X to be inefficient as well.
>Problem: X's multiple-widget set system is a bad >idea. > >Answer: No, it isn't. [snip] >But, you say, this ignores the fact that Windows >and Mac OS have advanced through the years! Nope. >First, Windows widget sets *have* broken user >level compatibility on a regular basis. Menus in >Office XP now work a lot differently than menus >in 1987 did.
How is it different than GTK 1 and GTK 2? QT 1 and QT 2 and QT 3? As far as I know, most, if not all, applications have to be rewritten, so X widget sets *also have* broken user level compatibility on a regular basis.
Once an application have chosen a widget set, it is doomed in the sense that it has to be revised when the widget set does - it is unrelated to how many widget sets a system can support.
So, in this sense, the single widget set settings on Macs and Windows is NOT a disadvantage at all when compared with X.
>Second, some widget sets are >hamstrung by initial design flaws. The classic >MacOS widget set does not include a slider >widget, for example. As a result, years of >application developers misued the scrollbar >widget, made up their own widget (which led to >even worse user interface problems), or just >went without. The ability of X11 to evolve has >let things like KDE's tearable panes come to the >fore. Also, when it comes to APIs...the modern, >easy-to-use APIs of GTK and Qt blow away the >horrific Macintosh Toolbox API (note: I am not a >Cocoa developer, so things may have improved) or >the almost-as-grotty Win32
As QT and GTK and other X widgets can evolve, Macs and Windows widgets can evolve just as well. So the "ability to evolve" is not unique to X11. This argument of how X11 is "superior" is just plain nonsense.
>Problem: X11 is hard to use. > >Answer: No, it really isn't. Occasionally, piss- >poor setup on the part of distro makers has made >things more of a pain than it should be. If a >user isn't interested in remote windowing, he >shouldn't have to worry about xauth or xhost. >This is largely a problem of the past.
Show me a good way of pasting one selection over another selection under X without retyping.
>It's worth mentioning that, while Ahead HE AAC, >Vorbis, MP3pro and WMA were encoded in VBR mode, >Real Audio and QuickTime were encoded in CBR mode >since these codecs don't offer a VBR mode. >Lame MP3 was encoded at ABR mode because that's >how Lame performs better at this bitrate.
It explains. The "64kbit/s" is only an average.
In general adaptive sampling methods such as VBR should always outperform constant sampling methods like CBR.
It promotes interoperability when its platforms are not the dominant players in a field.
Remember how its efforts to get AIM opened? Now it's not asking it anymore since MSN is competitive enough.
Now it's apparent - how much market share does Apache have now? How about mod_php? How about IIS? ASP? Is there any wonder MS is seeking interoperability?
One thing that GNOME 2 developers fail to realize is that, usability studies are just "studies".
These researches are often performed with a few examples that the researcher THINK are good representations - and the sad thing is, they tend to arrive at SWEEPING conclusions.
For one, I bet that there's no end user who asked for the restriction of not being able to move windows behind a panel bar. i.e. this decision is a suggestion of "usability studies".
On the bug reports, on the other hand, there are people who complains about not being able to freely move *their* windows. "Panel bars seem to block windows I want to move", etc.
Yet, some GNOME developers, in their arrogance, replied that "it's a feature and won't be fixed".
Ah, thank you. This kind of attitude completely shows how the GNOME team totally forgets what, or more importantly, WHO, made them successful in the first place.
That is true -- Linus/Linux is not out to attack the MS monopoly. But RedHat, Mandrake, Suse, $FAVORITE_DISTRO are. RedHat, for example, has already recognized this issue, and started attacking it with 'BlueCurve'.
Slashdot Mirror
If your definition of "Modern" = QT or GTK, then you're right.
Ctrl+V means different things for a lot of other X11 programs.
Completely agree with the part that music has a definite definition.
Try playing music to babies. Good music seem to be well-received by infants. Bad "music" make them cry.
SMTP is not a problem. If people start configuring SMTP servers so that they ask for a login and a password, it would stamp out spam real good.
>Problem: X11 is inefficient.
>
>Answer: No, it isn't. X11 is pretty damned
>efficient. Today's pixmap-laden interfaces can
>run much more slowly over a network than the
>original interfaces, whicch were mostly big,
>flat-color rectangles, but the same is true of
>VNC and similar.
Do you mean that X is efficient for flat-color rectangles but inefficient for pixmap-laden interfaces?
If so, the definition of efficiency needs to be updated. Today, efficiency means efficiency dealing with pixmap-laden interfaces. Anything is efficient for flat-color rectangles.
This efficiency is not comparative. "VNC and other interfaces are inefficient too" is not a good excuse for X to be inefficient as well.
>Problem: X's multiple-widget set system is a bad
>idea.
>
>Answer: No, it isn't. [snip]
>But, you say, this ignores the fact that Windows
>and Mac OS have advanced through the years! Nope.
>First, Windows widget sets *have* broken user
>level compatibility on a regular basis. Menus in
>Office XP now work a lot differently than menus
>in 1987 did.
How is it different than GTK 1 and GTK 2? QT 1 and QT 2 and QT 3? As far as I know, most, if not all, applications have to be rewritten, so X widget sets *also have* broken user level compatibility on a regular basis.
Once an application have chosen a widget set, it is doomed in the sense that it has to be revised when the widget set does - it is unrelated to how many widget sets a system can support.
So, in this sense, the single widget set settings on Macs and Windows is NOT a disadvantage at all when compared with X.
>Second, some widget sets are
>hamstrung by initial design flaws. The classic
>MacOS widget set does not include a slider
>widget, for example. As a result, years of
>application developers misued the scrollbar
>widget, made up their own widget (which led to
>even worse user interface problems), or just
>went without. The ability of X11 to evolve has
>let things like KDE's tearable panes come to the
>fore. Also, when it comes to APIs...the modern,
>easy-to-use APIs of GTK and Qt blow away the
>horrific Macintosh Toolbox API (note: I am not a
>Cocoa developer, so things may have improved) or
>the almost-as-grotty Win32
As QT and GTK and other X widgets can evolve, Macs and Windows widgets can evolve just as well.
So the "ability to evolve" is not unique to X11. This argument of how X11 is "superior" is just plain nonsense.
>Problem: X11 is hard to use.
>
>Answer: No, it really isn't. Occasionally, piss-
>poor setup on the part of distro makers has made
>things more of a pain than it should be. If a
>user isn't interested in remote windowing, he
>shouldn't have to worry about xauth or xhost.
>This is largely a problem of the past.
Show me a good way of pasting one selection over another selection under X without retyping.
Emulation:
*Each assembly instruction interpreted by an interpreter
*Compile once to run N applications
"Translation":
*Each assembly instruction translated to a C macro
*Compile N times to run N applications
Looks like emulation wins. If an emulator has JIT then "translation" losses its only speed advantage too.
Brought to you by, Intel! Best run on Pentium EXXXTREME.
Randomize your benchmark. It'll take a few more runs to get an average performance figure, but then the benchmark is immune to cheating drivers.
Finally can upgrade from DOS 5.0 to DOS 6.0!!
>It's worth mentioning that, while Ahead HE AAC,
>Vorbis, MP3pro and WMA were encoded in VBR mode,
>Real Audio and QuickTime were encoded in CBR mode
>since these codecs don't offer a VBR mode.
>Lame MP3 was encoded at ABR mode because that's
>how Lame performs better at this bitrate.
It explains. The "64kbit/s" is only an average.
In general adaptive sampling methods such as VBR should always outperform constant sampling methods like CBR.
Did I say who's right?
Good question and nice try.
I'd rather use Ctrl+C and Ctrl+V and then have the ability of pasting over.
I find the involvement of the middle mouse button clumsy, at best.
That B20B is meant to be B18C~
Now make it US $25000, the price point of most compacts that makes similar power (B20B, H22A, K20A, 1.8T)
Then we'll talk.
It is what MS always does.
It promotes interoperability when its platforms are not the dominant players in a field.
Remember how its efforts to get AIM opened? Now it's not asking it anymore since MSN is competitive enough.
Now it's apparent - how much market share does Apache have now? How about mod_php? How about IIS? ASP? Is there any wonder MS is seeking interoperability?
How about we pre-empt Verisign by redirecting the 404 pages to this petition?
I wonder what is not "gay" then, let us know what you drive.
Interesting.
I'll consider getting one when these hybrids can do a 14 second quartermile.
Let me know when they do.
One thing that GNOME 2 developers fail to realize is that, usability studies are just "studies".
These researches are often performed with a few examples that the researcher THINK are good representations - and the sad thing is, they tend to arrive at SWEEPING conclusions.
For one, I bet that there's no end user who asked for the restriction of not being able to move windows behind a panel bar. i.e. this decision is a suggestion of "usability studies".
On the bug reports, on the other hand, there are people who complains about not being able to freely move *their* windows. "Panel bars seem to block windows I want to move", etc.
Yet, some GNOME developers, in their arrogance, replied that "it's a feature and won't be fixed".
Ah, thank you. This kind of attitude completely shows how the GNOME team totally forgets what, or more importantly, WHO, made them successful in the first place.
Damn you.
Sounds like the way our deity does things. I like it.
How about, "if we find your DMCA claim bogus, we'll censor your site for a year"...
How about a punitive action of taking away all official Kazaa sites from the search string Kazaa?
OMG, the drones from FSF are going to get you.
Outlaw submarine patents.
Disclose pending patents.
LOL!!!
Mod parent back up!!
Some moderators have no sense of humour at all...
Mars is also not Lambertian?
Is it the case for all the planets?