Well, this is unquestionably a Good Thing(tm), but it really would be nice if it were possible to do 3d graphics decently _without_ X, too. (none of this beating directly on the hardware in each individual app stuff)
While you unquestionably need some central facility to arbitrate access to and abstract the graphics hardware (which is why svgalib doesn't realy cut it -- each app banging on the hardware directly is NOT a modern or a safe way of operating), it'd be nice if you didn't have to pay for the memory overhead of X if you didn't really need it (and it is considerable). Or the startup time -- not all of us keep an X server running continuously.
It'd be nice to see the kernel doing its job with arbitrating access to hardware, although that usually means an in-kernel abstraction layer too, which we really don't want. Partly because it can be a severe cause of bloat, and partly because there's no real obvious way to abstract most graphics stuff without breaking the standard Unix 'everything-is-a-file' metaphor. Except maybe for abstracting really basic stuff, like the framebuffer, which is what fbcon does.
We do still need to arbitrate access to accelerated graphics though, especially in light of the existence of poorly-designed hardware where you can inadvertantly (or deliberately) lock the bus and other fun things by poking accel registers. Maybe KGI will mature someday; the design seems to manage that pretty well without foisting an ungainly abstraction layer on the kernel.
*sigh*
Or maybe I'm just blowing smoke. I dunno. I'm not faulting the 3dfx folks. There are a lot of times you want or need 3d in X, and DRI is the cleanest way to do that. It's also the only emerging "standard" way we have of doing this 3d stuff cleanly right now, in any environment.
One would think that anything that SGI GPLs will be credited to them, and creditors might justifiably claim it was a fire-sale move and get the technology transfer declared illegal.
> Anybody who's not running a continuous- > duty 'Server' application, who leaves the > system running 24/7 in order to log those oh-so- > important uptime hours is, well, playing a > little ego game.
Um, either that or extending the life of their hardware. Power cycling is extremely unkind to our silicon friends.
"Internix" was done by a third party sometime ago as a replacement for the (useless) POSIX subsystem in NT. I believe it'll be the new POSIX subsystem in W2K.
I'm not really overly worried, to be honest. VMWare and cygwin32 don't really seem to have had a major attenuating effect on Linux adoption (in fact, quite the reverse); I don't think this will either.
Is the key to Linux the apps or the kernel? If the apps are more or less present on both sides, then the kernel becomes the discriminator, and we win. ---
No. We're adding postscript next (think printers). However, you generally don't program directly to the OpenGL or postscript or whatever layer, there's an abstraction layer (DrawingKit) over top which is pretty much consistent. Which is not to say that you couldn't use the OpenGL stuff if you wanted to, and it is not to say that OpenGL won't be the 3d API of choice. ---
> Properly written programs on Unix use processes > not threads.
It depends on what you are writing. Some things demand multithreading -- SHM and fork(2) only get you so far, and fork(2), although efficient compared to the Windows equivalent, can waste resources in many instances.
> Threads are not necessary in Unix as they are > on Windows for performance.
Untrue. The situations that demand multithreading are the same as they are under Windows; it's just that under Unix you can fudge things using fork(2) in what would otherwise be transitional cases.
(That is sometimes desirable; fork(2) is more portable and the separate address spaces add robustness, although it does cost you some speed and memory, even with copy-on-write)
The main reason you don't see fork(2)-like stuff being done under Windows is because Windows physically has no way of simply implementing a clean copy-on-write clone of the current context. CreateProcess() just creates a new blank process and does the equivalent of an execvp(2). Best you could do is CreateProcess() with the same executable as the parent, and then use CreateRemoteThread() [ that API call is EVIL! ] and shared memory to copy as much state over as you could.
> They do help, but not nearly as much.
Wrong. For some purposes, they don't really help. For others, they net very dramatic improvements in performance. The situations under which multithreading is desirable, though, are basically the same under both Windows and Unix. ---
That's not really a significant problem. What's more of a problem is that Win32 programming requires a number of subtle changes to the C compiler to really do right -- i.e. Windows code in general is not pure ANSI C. "Strict" type checking comes to mind, although it's not the best example.
Now, in practice it's not that big a problem for most people (the differences are not normally a compatibility issue), but it has been a serious headache for the folks working on winelib with ANSI compilers that don't like the Microsoft-isms. ---
As callous as this sounds, I do hope they manage to get a good amount of their IRIX tech into Linux before they go belly-up. I doubt their creditors would be as free with it.
> And some bozo AOL spokesperson said "It's all > about loyalty" or something to that end. Screw > loyalty!
Heh. Yeah, "loyalty" in the sense that opressed masses in a totalitarian regime are loyal. 'Tis called vendor lock-in, folks.
> Loyalty only promotes inefficency. If we were > all "loyal" to Linux then there would be no > reason for it to improve. We use it because > it's great and keeps getting greater.
Disagree. There are two sides to this coin.
It's a lot easier to go somewhere else than it is to fix problems. If there weren't some loyal people willing to expend the effort to fix and improve things, Linux would have been quickly abandoned.
Real loyalty comes when you're willing to invest something of yourself in a thing or a person; when you have a vested interest in their well-being. It's loyalty to the software and to an ideal that by and large keeps the Free Software coders going. Even pragmatists like ESR have their own set of (largely pragmatic) ideals that they are loyal to, from which their loyalty to Linux stems.
I understand you're looking at loyalty from the standpoint of "we'll stand by you, no matter what", but there's just more to it than that.
It's not real loyalty if someone will stand by you, but then not bother to help you.
If people were not loyal to Linux, they would have no reason to improve it. ---
Re:I'm looking forward to the day they ditch X
on
Some KDE news
·
· Score: 1
The Belin project looks like a neat idea, but the usefulness of a 3D desktop environment currently escapes me. Integrating 3D with the 2D desktop seems like a very good idea, given the 2D screens we all use.
The Berlin stuff isn't 3D, strictly speaking. Since the coordinate systems are in 3d, and it can use OpenGL as a display target (also Postscript and some other things now), yes, you probably can do a 3d desktop with it. I guess the main thing is that we don't really have any very usable 3d desktop UI paradigms yet, so it looks like we'll be doing a more "traditional" UI first. The 3d capabilities are mainly there as a matter of planning ahead.
So, most likely (at least from what I see now), the first major Berlin releases are going to be a more or less conventional 2d desktop with some really neat features, and once they're out people are more likely to start exploring 3d UI elements with it.
(in response to the obvious question, no, the 3d stuff doesn't really cost you anything if you don't use it)
> My guess is the explanation that they sent the > letter to the lead coder on each of their > various packages seems the most reasonable to > me.
Nope. I am lead coder of a project, but unless MegaZeux is one of their packages (it's not), that can't be it.
Not to mention that I got a second copy of the IPO letter at my school address, which is (as far as I know) only associated with a single entry in the Bugzilla database...
Linux programmers have been able to create a mighty server OS, but these programmers are not going to be able to create an innovative GUI and Desktop that truly makes computers easier to use.
Absolutely. The coders who did the Linux kernel for the most part aren't cut from the same cloth as the types of programmers who do well with issues of ergonomics or user-interface.
However, those aren't the only types of coders that hang around in the Free Software community.
It's only now that the basic infrastructure has solidified, that the more UI-oriented developers can really start getting to work. I can certainly see this happening with the Berlin project.
Rogue Linux developers working independently can't create the next generation UI.
Rogue developers working independently can't produce a usable OS kernel, either. Fortunately, that's not the way Open Source projects work.
Does that mean that Intel is developing an entirely new CPU and chipset for it?
No, but it won't be a PC as we know it, either. Maybe a new chipset, actually -- in any case, it'll be about as much a PC as the SGI Visual Workstations are.
I have a nasty feeling EGA/VGA textmode support is going away too (haven't looked at the specs yet). Us console freaks are going to miss our hardware-acceleration.
(yes, I realize that these are low-end consumer boxes, but I strongly suspect that higher-end boxes will follow their example, especially where corners can be cut WRT hardware) ---
What, no one has anything good to say about Gtk? The _only_ complaints I can imagine someone having about Gtk are:
I'm afraid I'm guilty of unintentionally damning with faint praise... GTK is actually my favorite toolkit of the two, but I didn't want to deviate from the Win32 versus Linux+X11 discussion into a GTK advocacy discussion. I don't think it worked out to well.
1) it has to do dynamic type checking, rather than static type checking.
In the C binding. That's not an issue in the C++ binding.
2) writing your own widget tends to be a little involved.
Enh... I dunno. Not more than it has to be. I do a good deal of OO programming in C (unrelated to GTK), and I would have to say that that's just a result of having to do so much more of the OO stuff explicitly in C.
3) the code tends to be wordy.
WRT the C binding, yes. The wordiness is half the "evil" of it that I referred to. The C++ binding isn't bad at all.
GTK is actually my toolkit of choice, although I do like Qt's design better in some areas (not the ones I criticized). ---
> "and it's led to a big boom of GUI programs for > Linux. "
> Mostly frontends to "whois" etc...
Check freshmeat; wrappers for existing commandline software are a minority. 80-90% of GTK apps are "original" in design and often functionality. (you'll see similar numbers for Qt; I'm not making comparisons with other widget sets)
> By the way, you shouldn't compare Win32 API to > Xlib - those are on completely different > levels. It is more like Win32 API = GTK...
That's not actually an appropriate comparison either; GTK (or Qt for that matter) covers a very small subset of the functionality of the Win32 API (the remaining functionality is supplied by the POSIX stuff).
> And I agree with previous poster - GTK is ugly > and simply not pleasant to program in or use ( > hint ; try QT and you will see the truth..)
Qt's a nice piece of work, as far as C++ APIs go. GTK's C++ binding is _decent_ -- although it's not quite as good (or at least as complete) in some areas.
From the perspective of a C++ programmer, GTK's C binding is quite evil, but the problem is precisely that it IS C. There really isn't a better way to do that kind of OO thing in C -- Qt's C binding (yes, there is one), for instance, does not take anywhere near as good an advantage of inheritance and other OO constructs.
I guess one advantage of GTK over Qt, at least in C++, is that you can program GTK in standard C++. You can't (in most cases) with Qt; some of Qt's functionality necessitates its own special C++ variant, requiring a special preprocessor. On a practical basis, that's not that big a deal, but I do prefer to stick with accepted language standards.
These issues aside, Qt is better than GTK, yes. Just be aware of the caveats.
> if it *substitutes* the industrey endorsed bill, > then why would it be more favoreable as hemos > suggessts?
More favorable to law enforcement agencies, not the industry.
*sigh*
This sort of legislative bait-and-switch is not all that uncommon, you know. People get fired up about a certain piece of legislation, then at the last minute it gets replaced with another completely different piece of legislation under the same name. Of course, then the new bill gets voted in mainly because of the momentum the original had gained.
> do your part to keep the/. piece -- daveo
I'm keeping my piece in a shoebox under my desk. ---
Dear fellow, I feel rather obligated to point out to you that if you continue with such posts, our moderator friends are quite liable to ensure that you start with a default score of -1, rather than your current default of 0. Just keep that in mind. Good night. ---
> 1. Drop human population levels down to 2 > billion or so, which could easily be done in one > generation, and
Yeah! bring on the death camps!
> 2. Figure out someway of keeping superstitious > asian men with small penises happy. Viagra > donations, anyone?
Oh, that's easy. Just castrate them all. That'll also help take care of #1.
</SARCASM> ---
Re:GGI on DGA advantage
on
XFree86 News
·
· Score: 1
You cannot change resolution/mode at all with DGA. It's not within the DGA API. You can use the vidmode extension, which is XFree86 specific, to change resolution but not depth (as of 3.3.3).
This is true, and it is in fact exactly my point ("cannot be done with plain DGA") -- DGA by itself cannot change the resolution or depth. Even with vidmode, however, you still can't change the depth on-the-fly. At least not yet.
Programs like xmame and snes9x exploit this, with DGA used for speed and vidmode to change res.
I was aware of this.
LibGGI's DGA target can use fbcon, if present, to change both the resolution and depth, while getting access to the framebuffer via DGA. That's just kind of neat, and if vidmode or some other extension evolves to do the same, that's fine.
But you're a Berlin developer, no wonder you know nothing about X or XFree86 extensions.
Why the hostility? There's no need to resort to these sort of attacks just to correct a simple omission on my part. Honestly, what reason do you have here to feel either angry OR threatened? If GGI was intended to replace X in most situations, LibGGI wouldn't display on X, and they wouldn't have XGGI (an XFree86-derived server that uses LibGGI), would they?
Chill out, man. Us Berlin folks are just playing around with a heavily CORBA-ized Fresco-esque GUI. It's no threat to your hegemony unless Berlin turns out to be better for users and developers than X is. If it turns out to be a bad idea, you're safe. Let the ideas speak for themselves -- on their own merits and demerits -- and leave the ad hominem attacks out of this.
On the other hand, how much longer are you going to keep grafting extensions onto X to work around deficiencies in the initial design? It never hurts to experiment with a clean design once and a while under such conditions, and I really don't think the Berlin folks deserve to be vilified for doing so.
---
Fear not, it's being worked on...
on
XFree86 News
·
· Score: 1
see the Berlin project. Not that that kind of 3d flashiness is in and of itself a design goal, but the current design allows for it. ---
Just as a matter of interest, I seem to recall that if you use LibGGI with the DGA target and have fbcon, you can change the screen resolution/mode on-the-fly, which you cannot easily do with plain DGA.
And, of course, you get the usual LibGGI advantage of extreme display independence. No more releasing separate console and X versions. ---
No I am not saying that math is all useless just extremely difficult to understand (how many nice glossy textbooks have you seen on hyperdementional geometery).
Your logic seems "hyperdementional"[sic]. So... math is not simple. What difference does it make if it can't be put in books with pretty pictures?
And I am not saying that computers are useless (they do some rather interesting things) it is that people in areas of pure math (where most of cs started) do not really think about how to apply this knowledge to anything really useful to most.
I see... so... the "mathematical elite" have been using computers for their own purposes (more digits of PI) and not doing things that the masses want (AI, as you gave as an example in an earlier post)?
Problem is, we already know how to compute PI -- we do not know how to make a complete AI. You seem to be under the illusion that the computing resources going into, say, computing PI, could go into creating an AI instead, as if AI were as trivial a problem as PI. There are actually a LOT of the "mathematical elite" spending every waking hour of their lives on the problems with AI. Actually developing the theory necessary to make an AI requires more human talent and education (mathematical and more) than it does computing time, so you may as well compute PI while you're waiting, instead of letting the machines go to waste.
It wasn't until the math requirement went down that a person could really do anything in cs without a Phd.
Problems don't get magically less complex just because less skilled people are thrown at them. But nooo... math is hard... the people who know it should just get out of the way and let the rest of us try to implement an AI using bogo-sort, right?
There's a box in front of you right now, my friend. Nobody's denying you access to it. Go ahead, get all your like-minded friends together and make an AI. Write an RC5-like system to run it. Thanks to RMS, you have free (libre+gratis) tools availible to you. Go on, already! Where's that AI?
Slashdot Mirror
Well, this is unquestionably a Good Thing(tm), but it really would be nice if it were possible to do 3d graphics decently _without_ X, too. (none of this beating directly on the hardware in each individual app stuff)
While you unquestionably need some central facility to arbitrate access to and abstract the graphics hardware (which is why svgalib doesn't realy cut it -- each app banging on the hardware directly is NOT a modern or a safe way of operating), it'd be nice if you didn't have to pay for the memory overhead of X if you didn't really need it (and it is considerable). Or the startup time -- not all of us keep an X server running continuously.
It'd be nice to see the kernel doing its job with arbitrating access to hardware, although that usually means an in-kernel abstraction layer too, which we really don't want. Partly because it can be a severe cause of bloat, and partly because there's no real obvious way to abstract most graphics stuff without breaking the standard Unix 'everything-is-a-file' metaphor. Except maybe for abstracting really basic stuff, like the framebuffer, which is what fbcon does.
We do still need to arbitrate access to accelerated graphics though, especially in light of the existence of poorly-designed hardware where you can inadvertantly (or deliberately) lock the bus and other fun things by poking accel registers. Maybe KGI will mature someday; the design seems to manage that pretty well without foisting an ungainly abstraction layer on the kernel.
*sigh*
Or maybe I'm just blowing smoke. I dunno. I'm not faulting the 3dfx folks. There are a lot of times you want or need 3d in X, and DRI is the cleanest way to do that. It's also the only emerging "standard" way we have of doing this 3d stuff cleanly right now, in any environment.
---
One would think that anything that SGI GPLs will be credited to them, and creditors might justifiably claim it was a fire-sale move and get the technology transfer declared illegal.
That's a really good point I hadn't considered.
---
> It's the value people see in things that makes
> them stay. Not just loyalty.
You can't be loyal to something you honestly don't see any direct or indirect value in.
---
> Anybody who's not running a continuous-
> duty 'Server' application, who leaves the
> system running 24/7 in order to log those oh-so-
> important uptime hours is, well, playing a
> little ego game.
Um, either that or extending the life of their hardware. Power cycling is extremely unkind to our silicon friends.
---
"Internix" was done by a third party sometime ago as a replacement for the (useless) POSIX subsystem in NT. I believe it'll be the new POSIX subsystem in W2K.
I'm not really overly worried, to be honest. VMWare and cygwin32 don't really seem to have had a major attenuating effect on Linux adoption (in fact, quite the reverse); I don't think this will either.
Is the key to Linux the apps or the kernel? If the apps are more or less present on both sides, then the kernel becomes the discriminator, and we win.
---
> is Berlin supposed to be OpenGL only?
No. We're adding postscript next (think printers). However, you generally don't program directly to the OpenGL or postscript or whatever layer, there's an abstraction layer (DrawingKit) over top which is pretty much consistent. Which is not to say that you couldn't use the OpenGL stuff if you wanted to, and it is not to say that OpenGL won't be the 3d API of choice.
---
> Properly written programs on Unix use processes
> not threads.
It depends on what you are writing. Some things demand multithreading -- SHM and fork(2) only get you so far, and fork(2), although efficient compared to the Windows equivalent, can waste resources in many instances.
> Threads are not necessary in Unix as they are
> on Windows for performance.
Untrue. The situations that demand multithreading are the same as they are under Windows; it's just that under Unix you can fudge things using fork(2) in what would otherwise be transitional cases.
(That is sometimes desirable; fork(2) is more portable and the separate address spaces add robustness, although it does cost you some speed and memory, even with copy-on-write)
The main reason you don't see fork(2)-like stuff being done under Windows is because Windows physically has no way of simply implementing a clean copy-on-write clone of the current context. CreateProcess() just creates a new blank process and does the equivalent of an execvp(2). Best you could do is CreateProcess() with the same executable as the parent, and then use CreateRemoteThread() [ that API call is EVIL! ] and shared memory to copy as much state over as you could.
> They do help, but not nearly as much.
Wrong. For some purposes, they don't really help. For others, they net very dramatic improvements in performance. The situations under which multithreading is desirable, though, are basically the same under both Windows and Unix.
---
That's not really a significant problem. What's more of a problem is that Win32 programming requires a number of subtle changes to the C compiler to really do right -- i.e. Windows code in general is not pure ANSI C. "Strict" type checking comes to mind, although it's not the best example.
Now, in practice it's not that big a problem for most people (the differences are not normally a compatibility issue), but it has been a serious headache for the folks working on winelib with ANSI compilers that don't like the Microsoft-isms.
---
As callous as this sounds, I do hope they manage to get a good amount of their IRIX tech into Linux before they go belly-up. I doubt their creditors would be as free with it.
---
> And some bozo AOL spokesperson said "It's all
> about loyalty" or something to that end. Screw
> loyalty!
Heh. Yeah, "loyalty" in the sense that opressed masses in a totalitarian regime are loyal. 'Tis called vendor lock-in, folks.
> Loyalty only promotes inefficency. If we were
> all "loyal" to Linux then there would be no
> reason for it to improve. We use it because
> it's great and keeps getting greater.
Disagree. There are two sides to this coin.
It's a lot easier to go somewhere else than it is to fix problems. If there weren't some loyal people willing to expend the effort to fix and improve things, Linux would have been quickly abandoned.
Real loyalty comes when you're willing to invest something of yourself in a thing or a person; when you have a vested interest in their well-being. It's loyalty to the software and to an ideal that by and large keeps the Free Software coders going. Even pragmatists like ESR have their own set of (largely pragmatic) ideals that they are loyal to, from which their loyalty to Linux stems.
I understand you're looking at loyalty from the standpoint of "we'll stand by you, no matter what", but there's just more to it than that.
It's not real loyalty if someone will stand by you, but then not bother to help you.
If people were not loyal to Linux, they would have no reason to improve it.
---
The Belin project looks like a neat idea, but the usefulness of a 3D desktop environment currently escapes me. Integrating 3D with the 2D desktop seems like a very good idea, given the 2D screens we all use.
The Berlin stuff isn't 3D, strictly speaking. Since the coordinate systems are in 3d, and it can use OpenGL as a display target (also Postscript and some other things now), yes, you probably can do a 3d desktop with it. I guess the main thing is that we don't really have any very usable 3d desktop UI paradigms yet, so it looks like we'll be doing a more "traditional" UI first. The 3d capabilities are mainly there as a matter of planning ahead.
So, most likely (at least from what I see now), the first major Berlin releases are going to be a more or less conventional 2d desktop with some really neat features, and once they're out people are more likely to start exploring 3d UI elements with it.
(in response to the obvious question, no, the 3d stuff doesn't really cost you anything if you don't use it)
---
> My guess is the explanation that they sent the
> letter to the lead coder on each of their
> various packages seems the most reasonable to
> me.
Nope. I am lead coder of a project, but unless MegaZeux is one of their packages (it's not), that can't be it.
Not to mention that I got a second copy of the IPO letter at my school address, which is (as far as I know) only associated with a single entry in the Bugzilla database...
---
Linux programmers have been able to create a mighty server OS, but these programmers are not going to be able to create an innovative GUI and Desktop that truly makes computers easier to use.
Absolutely. The coders who did the Linux kernel for the most part aren't cut from the same cloth as the types of programmers who do well with issues of ergonomics or user-interface.
However, those aren't the only types of coders that hang around in the Free Software community.
It's only now that the basic infrastructure has solidified, that the more UI-oriented developers can really start getting to work. I can certainly see this happening with the Berlin project.
Rogue Linux developers working independently can't create the next generation UI.
Rogue developers working independently can't produce a usable OS kernel, either. Fortunately, that's not the way Open Source projects work.
---
Does that mean that Intel is developing an entirely new CPU and chipset for it?
No, but it won't be a PC as we know it, either. Maybe a new chipset, actually -- in any case, it'll be about as much a PC as the SGI Visual Workstations are.
I have a nasty feeling EGA/VGA textmode support is going away too (haven't looked at the specs yet). Us console freaks are going to miss our hardware-acceleration.
(yes, I realize that these are low-end consumer boxes, but I strongly suspect that higher-end boxes will follow their example, especially where corners can be cut WRT hardware)
---
What, no one has anything good to say about Gtk? The _only_ complaints I can imagine someone having about Gtk are:
I'm afraid I'm guilty of unintentionally damning with faint praise... GTK is actually my favorite toolkit of the two, but I didn't want to deviate from the Win32 versus Linux+X11 discussion into a GTK advocacy discussion. I don't think it worked out to well.
1) it has to do dynamic type checking, rather than static type checking.
In the C binding. That's not an issue in the C++ binding.
2) writing your own widget tends to be a little involved.
Enh... I dunno. Not more than it has to be. I do a good deal of OO programming in C (unrelated to GTK), and I would have to say that that's just a result of having to do so much more of the OO stuff explicitly in C.
3) the code tends to be wordy.
WRT the C binding, yes. The wordiness is half the "evil" of it that I referred to. The C++ binding isn't bad at all.
GTK is actually my toolkit of choice, although I do like Qt's design better in some areas (not the ones I criticized).
---
> "and it's led to a big boom of GUI programs for
...
..)
> Linux. "
> Mostly frontends to "whois" etc...
Check freshmeat; wrappers for existing commandline software are a minority. 80-90% of GTK apps are "original" in design and often functionality. (you'll see similar numbers for Qt; I'm not making comparisons with other widget sets)
> By the way, you shouldn't compare Win32 API to
> Xlib - those are on completely different
> levels. It is more like Win32 API = GTK
That's not actually an appropriate comparison either; GTK (or Qt for that matter) covers a very small subset of the functionality of the Win32 API (the remaining functionality is supplied by the POSIX stuff).
> And I agree with previous poster - GTK is ugly
> and simply not pleasant to program in or use (
> hint ; try QT and you will see the truth
Qt's a nice piece of work, as far as C++ APIs go. GTK's C++ binding is _decent_ -- although it's not quite as good (or at least as complete) in some areas.
From the perspective of a C++ programmer, GTK's C binding is quite evil, but the problem is precisely that it IS C. There really isn't a better way to do that kind of OO thing in C -- Qt's C binding (yes, there is one), for instance, does not take anywhere near as good an advantage of inheritance and other OO constructs.
I guess one advantage of GTK over Qt, at least in C++, is that you can program GTK in standard C++. You can't (in most cases) with Qt; some of Qt's functionality necessitates its own special C++ variant, requiring a special preprocessor. On a practical basis, that's not that big a deal, but I do prefer to stick with accepted language standards.
These issues aside, Qt is better than GTK, yes. Just be aware of the caveats.
---
> if it *substitutes* the industrey endorsed bill,
/. piece -- daveo
> then why would it be more favoreable as hemos
> suggessts?
More favorable to law enforcement agencies, not the industry.
*sigh*
This sort of legislative bait-and-switch is not all that uncommon, you know. People get fired up about a certain piece of legislation, then at the last minute it gets replaced with another completely different piece of legislation under the same name. Of course, then the new bill gets voted in mainly because of the momentum the original had gained.
> do your part to keep the
I'm keeping my piece in a shoebox under my desk.
---
Dear fellow, I feel rather obligated to point out to you that if you continue with such posts, our moderator friends are quite liable to ensure that you start with a default score of -1, rather than your current default of 0. Just keep that in mind. Good night.
---
> 1. Drop human population levels down to 2
> billion or so, which could easily be done in one
> generation, and
Yeah! bring on the death camps!
> 2. Figure out someway of keeping superstitious
> asian men with small penises happy. Viagra
> donations, anyone?
Oh, that's easy. Just castrate them all. That'll also help take care of #1.
</SARCASM>
---
You cannot change resolution/mode at all with DGA. It's not within the DGA API. You can use the vidmode extension, which is XFree86 specific, to change resolution but not depth (as of 3.3.3).
This is true, and it is in fact exactly my point ("cannot be done with plain DGA") -- DGA by itself cannot change the resolution or depth. Even with vidmode, however, you still can't change the depth on-the-fly. At least not yet.
Programs like xmame and snes9x exploit this, with DGA used for speed and vidmode to change res.
I was aware of this.
LibGGI's DGA target can use fbcon, if present, to change both the resolution and depth, while getting access to the framebuffer via DGA. That's just kind of neat, and if vidmode or some other extension evolves to do the same, that's fine.
But you're a Berlin developer, no wonder you know nothing about X or XFree86 extensions.
Why the hostility? There's no need to resort to these sort of attacks just to correct a simple omission on my part. Honestly, what reason do you have here to feel either angry OR threatened? If GGI was intended to replace X in most situations, LibGGI wouldn't display on X, and they wouldn't have XGGI (an XFree86-derived server that uses LibGGI), would they?
Chill out, man. Us Berlin folks are just playing around with a heavily CORBA-ized Fresco-esque GUI. It's no threat to your hegemony unless Berlin turns out to be better for users and developers than X is. If it turns out to be a bad idea, you're safe. Let the ideas speak for themselves -- on their own merits and demerits -- and leave the ad hominem attacks out of this.
On the other hand, how much longer are you going to keep grafting extensions onto X to work around deficiencies in the initial design? It never hurts to experiment with a clean design once and a while under such conditions, and I really don't think the Berlin folks deserve to be vilified for doing so.
---
see the Berlin project. Not that that kind of 3d flashiness is in and of itself a design goal, but the current design allows for it.
---
Just as a matter of interest, I seem to recall that if you use LibGGI with the DGA target and have fbcon, you can change the screen resolution/mode on-the-fly, which you cannot easily do with plain DGA.
And, of course, you get the usual LibGGI advantage of extreme display independence. No more releasing separate console and X versions.
---
No I am not saying that math is all useless just extremely difficult to understand (how many nice glossy textbooks have you seen on hyperdementional geometery).
Your logic seems "hyperdementional"[sic]. So ... math is not simple. What difference does it make if it can't be put in books with pretty pictures?
And I am not saying that computers are useless (they do some rather interesting things) it is that people in areas of pure math (where most of cs started) do not really think about how to apply this knowledge to anything really useful to most.
I see ... so ... the "mathematical elite" have been using computers for their own purposes (more digits of PI) and not doing things that the masses want (AI, as you gave as an example in an earlier post)?
Problem is, we already know how to compute PI -- we do not know how to make a complete AI. You seem to be under the illusion that the computing resources going into, say, computing PI, could go into creating an AI instead, as if AI were as trivial a problem as PI. There are actually a LOT of the "mathematical elite" spending every waking hour of their lives on the problems with AI. Actually developing the theory necessary to make an AI requires more human talent and education (mathematical and more) than it does computing time, so you may as well compute PI while you're waiting, instead of letting the machines go to waste.
It wasn't until the math requirement went down that a person could really do anything in cs without a Phd.
Problems don't get magically less complex just because less skilled people are thrown at them. But nooo... math is hard ... the people who know it should just get out of the way and let the rest of us try to implement an AI using bogo-sort, right?
There's a box in front of you right now, my friend. Nobody's denying you access to it. Go ahead, get all your like-minded friends together and make an AI. Write an RC5-like system to run it. Thanks to RMS, you have free (libre+gratis) tools availible to you. Go on, already! Where's that AI?
---
> um, why would the growth of capital be a linear
> function? especaly if population growth was
> exponential.
It's the Malthusian Fallacy all over again.
---
(the one about using speakfreely for callins)
killer idea.
---