Because the moment you sell it, Qt isn't under the GPL anymore, its under the commercial use license. Qt/Free is GPL'ed only for non-profit products.
From the TrollTech FAQ:
Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software.
And...
I don't want to give away my source code. What do I do?
Then you need a Professional or Enterprise Edition license.
And...
Can I charge for my application?
If you have the Professional Edition: Yes, of course. If you use the Free Edition your software must be freely redistributable and you must include the source.
The Free Edition is intended for free software. We realize that CD-ROMs cost money to produce, for example, so you may charge a copying fee.
I'm rather wary of extension mechanisms. Take Xft for example. While it has worked pretty well for KDE (which is a really top-down, organized project), it hasn't worked as well for GNOME (gdkxft doesn't AA everything quite yet). It seems that unless there is a single team of developers behind all of the applications one uses, extensions won't get taken advantage off in all one's applications (there is nothing I hate more than non-homogeneity). For core stuff like fonts and rendering models, you really have to make changes to the core of the architecture, not tack them on as extensions.
It was originally on BeOS, so Gobe is Go Be Productive. Its a pun.
Re:What's most interesting..
on
Looking At Gobe
·
· Score: 2
Actually, I'm rather unimpressed by both the GNOME and OpenOffice projects (no not a troll, just a statement of facts;) but dude, have you seen how fast the KDE guys are going? KDE 2.2.1 finally got me to dump Windows, and KWord is a great Word replacement for almost anything I care to do. Given that KOffice didn't even exist a while ago (it came out with KDE-2!) that's damn impressive.
Computer theory is nice and all, but I wonder how often reality impinges on the nice though processes of theorists. The VM is an awefully low level piece of code. Almost everything else in the system touches the VM. Its just really hard to make something like that a module that can be swapped out. It has been done, but its very complex. Even in microkernels the VM is usually implemented partly in the kernel, with only the pager (the thing that decides what to page out) being a modular component.
A 32bit machine can address as much memory as it wants. First, 2^32 is 4GB, in theory Linux x86 programs should be able to address 3GB (since Linux uses 1GB for itself). Second, through the address window extensions (basically multiple banks of 4GB address spaces) the PPro series chips can address 64GB of RAM.
I can off the bat tell you the major problem software vendors are having: orgasm features. Things that make nerds' gonads tingle, but do little but take up space and speed for the user. Stuff like 90% of the things in MS Office, network transparency (99% people run local apps, besides, there is always Citrix), CORBA/DCOP (what's wrong with simple, FAST, COM?), "paradigms" (everything is a file, except the stuff that requires special hack system calls like ioctl() to actually do something useful), ease of development (KDE3's C bindings are automatically generated. Wonder how fast/optimized THOSE are?) I could go on for ever, but someone has already written up a list for me: check out www.gnome.org and www.kde.org. Of course, once in a blue moon, a useful feature slips in, like KDE's ioslaves (or MC's equivilant). But most of it is just jerk-of material for the developers.
PS> BTW, I'm typing this from a 99% (haven't figured out how grow XFS partition on the fly to include former Win2K partition, yet) Mandrake 8.1 box running KDE 2.2.1. It's cool as hell, but that doesn't make it any less slow.
Actually, MS does release documentation, you know. Check out any good OS book, they have fairly detailed info about the MS VM (try Modern Operating Systems by the MINIX fellow).
That's strange. mmap()'ing the file should be about as fast as read/write, since the Win2K VM implements read/write by mmap()'ing 256KB file regions into kenrel virtual memory and doing memcpy().
Actually, with 2.4.14-pre6 (I'm running the XFS CVS code with the preempt patches) Linus has apperently declared the VM fixed and dared people to break it. I've been using the kernel quite heavily for a few days, and its been great. I don't know how much of an improvement it is over 2.4.13, though. I had 2.4.13 for a total of a day before XFS CVS updated to the 2.4.14-pre series. (Linus releases pre kernels at an ungodly rate, and the XFS team manages to keep up.)
More features does not necessarily mean slower. Win2K had tons more features than NT4, but it was faster for most desktop-type uses. When you turn of Luna, XP is slightly faster (significantly faster in terms of app loading) than Win2K. (According to MaximumPC, whom I trust a hell of a lot more than InfoWorld, or any mainstream magazine for that matter.)
I've read the UVM paper twice (its like 200pp) and it really is a good design. I don't like the BSD idea of abstracting the VM away from the hardware so much (you spend a lot of memory in places you don't have to) but it does make the design cleaner. However, UVM is more of the mechanism part of the VM. Its the code that lets you share memory, memory map files, etc. What the Linux VMs are competing on, on the other hand, are the policy parts of the VM. What gets paged out and when. As it stands, UVM is probably tied with Linux on the low-level VM part (though UVM has a cleaner interface to the MMU hardare, IMO). The virtual memory filesystem cleaned up handling of shared memory segments significantly. (Before 2.4, swapping out normal memory and swapping out SysV shared memory were two different things). It has many more (cool) features, such as sharing address spaces, trading address space, etc, but few *NIX apps use those features (since its not standard *NIX API). FreeBSD probably has the best policy mechanism right now. The low-level VM is a heavily-tweeked one based on Mach's, but it doesn't have most of the modern features of UVM.
Of course, it all depends on the application one is using the system for. If you are running a webserver, you can tend towards the throughput side because latencies are going to be limited by the latency of the net connection (at least 20-30ms usually). If you're doing real time audio, you want to tend towards the latency side. On a desktop machine, it is probably best to tend towards latency. I doubt anybody minds a compile finishing 10% slower if it means that their MP3s don't skip and their mouse doesn't jump around. Interestingly, the 2.4 kernel is actually pretty good about both (maybe excluding VM and some filesystem code). With the preempt patches, latency is down to 2ms or so, while throughput is almost unchanged (or even sped up, depending on the task). Of course, you make the assumption that there are no other things limiting the performance of the app. Having used Linux GUIs for awhile, I'd say that's quite an assumption...
Look at it this way. Say 1GB of memory with VM will allow you to fit a 100 programs in RAM. Without VM, that number drops to 50. Your solution would be to just double your RAM, at which point I could have 200 programs with VM, but only 100 without. No matter how much memory you add, you can always find ways to fill it. VM doesn't incur a terribly large performance hit (at least when its not trashing) so its a no-brainer to include it. And its RAM, not core... damn grognards...
Actually, its a gradient thing. GNOME is fast enough not to choke while drawing the menus, but is slow enough to visibly redraw. Of course, thats a problem with a whole lot of X apps (GNOME and KDE included). Interestingly, though, I don't thing its X or GTK+ at fault. If you try resizing ROX-filer, you'll see that it does so as fast as any Windows program. A whole lot of the problem comes from lazy application programmers.
QNX sucks as a desktop OS precisely because it lacks a decent VM (and a decent FS, but that's another can of worms...)
A VM doesn't make the system any slower. The cost of maintaining mapping data and such is negligable compared to the other startup costs associated with applications. Also, most VMs do very little until the system memory becomes stressed. FreeBSD, for example, won't really bother keeping page ages up to date unless there is a lack of available pages. As long as you're not swaping, a VM-based system is no slower than a non-VM system. By the time you're swaping, however, a VM system has a lot more active processes (since the working set of each process is smaller than the total image) than a non VM system. Also, a VM system can deal with temporary demands for a huge amount of memory (such as compiling, in which the disk is getting trashed anyway), while a non-VM system can't. In fact, the QNX developers had to hack GCC to use their swap extensions because it wouldn't run on any sensible RAM config without VM.
You're comments about RAM are also questionable. While RAM might be getting cheaper, the uses for RAM are increasing. The more RAM you add, the more uses you can find for it, such as rendering bigger images, etc. There is no point in wasting a significant amount of it when you don't have to.
Lastly, the comments about process swaping are completely off the wall. App developers are inherently lazy, which is why modern systems take as much responsibility away from them as possible. If you left it up to the application developers to manage memory, then you'd end up with gigantic (more so than now, if that's possible) runtime footprints.
Dude, a VM is an awefully low level bit of code to make a compile option! XFS, for example, won't work the the AC kernels due to the different VM. Probably, the two seperate kernels are the best idea ATM.
Were not talking userspace applications here, we're talking about the kernel. Both the Linux and FreeBSD projects go to extreme lengths to optimize the performance of their kernels. The FreeBSD VM, for example, is very complex, but performs well due to that complexity.
Pervasive multithreading is great. It forces developers to design their apps for user responsiveness (something most Linux GUI apps SERIOUSLY lack). The whole idea of the drawing code being a part of the main application loop is sickening. The window update should not wait for the rest of the application to finish processing before it can run. That leads to the annoying "blank widgets" in busy apps. Its not terribly intelligent to force the design on normal parts of the application, but GUI updates are a very specific type of computing, and there is nothing wrong with having a drawing thread for each window. Note, BeOS is multithreaded mainly in the window update method of BWindows. Draw methods should ALWAYS (in any GUI system) be extremely short and simple. If you are doing lots of crazy things in your update callback, then something is wrong with your application design.
There aren't any real problems with the patches (I'm using them right now on an XFS kernel, btw), its just that they make an extensive change to spinlocks, which are a very basic part of the kernel. As such, they touch almost every piece of code in the system. Because of that, they are considered 2.5 material.
Its really easy to track the XFS tree on a workstation too. I have a little script that automatically gets the CVS sources off the SGI website. I tend to get the Pre kernels (running 2.4.14-pre3 right now) but it works OK so far.
Quote 2:
"The main reasons why I don't like Linux are the non-flexibility and the "chaos"."
If you don't like why do you use it?
>>>>>>>>>
I think he is making the distinction between Linux the kernel and Linux the OS. Linux is a great kernel. It is a sub-par desktop system.
Quote 3:
"For "performance" addicted people, a version of the app_server which will only use the XFree86 drivers will appear on the BlueOS v2, it means that BlueOS will not use the XServer anymore!"
I'm quite interested how he will do this.
>>>>>>>>>
XAA is the new X driver architecture. Its nice and clean, and any windowing system should be able to load X drivers and use them (in theory).
Slashdot Mirror
Because the moment you sell it, Qt isn't under the GPL anymore, its under the commercial use license. Qt/Free is GPL'ed only for non-profit products.
From the TrollTech FAQ:
Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software.
And...
I don't want to give away my source code. What do I do?
Then you need a Professional or Enterprise Edition license.
And...
Can I charge for my application?
If you have the Professional Edition: Yes, of course. If you use the Free Edition your software must be freely redistributable and you must include the source.
The Free Edition is intended for free software. We realize that CD-ROMs cost money to produce, for example, so you may charge a copying fee.
I'm rather wary of extension mechanisms. Take Xft for example. While it has worked pretty well for KDE (which is a really top-down, organized project), it hasn't worked as well for GNOME (gdkxft doesn't AA everything quite yet). It seems that unless there is a single team of developers behind all of the applications one uses, extensions won't get taken advantage off in all one's applications (there is nothing I hate more than non-homogeneity). For core stuff like fonts and rendering models, you really have to make changes to the core of the architecture, not tack them on as extensions.
!!!
Sorry, I couldn't resist. Even KDE-2 (which IMO is criminally bloated) is about 1.5M lines of code, while GNOME is over 4M lines.
It was originally on BeOS, so Gobe is Go Be Productive. Its a pun.
Actually, I'm rather unimpressed by both the GNOME and OpenOffice projects (no not a troll, just a statement of facts ;) but dude, have you seen how fast the KDE guys are going? KDE 2.2.1 finally got me to dump Windows, and KWord is a great Word replacement for almost anything I care to do. Given that KOffice didn't even exist a while ago (it came out with KDE-2!) that's damn impressive.
You're right.
Computer theory is nice and all, but I wonder how often reality impinges on the nice though processes of theorists. The VM is an awefully low level piece of code. Almost everything else in the system touches the VM. Its just really hard to make something like that a module that can be swapped out. It has been done, but its very complex. Even in microkernels the VM is usually implemented partly in the kernel, with only the pager (the thing that decides what to page out) being a modular component.
A 32bit machine can address as much memory as it wants. First, 2^32 is 4GB, in theory Linux x86 programs should be able to address 3GB (since Linux uses 1GB for itself). Second, through the address window extensions (basically multiple banks of 4GB address spaces) the PPro series chips can address 64GB of RAM.
I can off the bat tell you the major problem software vendors are having: orgasm features. Things that make nerds' gonads tingle, but do little but take up space and speed for the user. Stuff like 90% of the things in MS Office, network transparency (99% people run local apps, besides, there is always Citrix), CORBA/DCOP (what's wrong with simple, FAST, COM?), "paradigms" (everything is a file, except the stuff that requires special hack system calls like ioctl() to actually do something useful), ease of development (KDE3's C bindings are automatically generated. Wonder how fast/optimized THOSE are?) I could go on for ever, but someone has already written up a list for me: check out www.gnome.org and www.kde.org. Of course, once in a blue moon, a useful feature slips in, like KDE's ioslaves (or MC's equivilant). But most of it is just jerk-of material for the developers.
PS> BTW, I'm typing this from a 99% (haven't figured out how grow XFS partition on the fly to include former Win2K partition, yet) Mandrake 8.1 box running KDE 2.2.1. It's cool as hell, but that doesn't make it any less slow.
Actually, MS does release documentation, you know. Check out any good OS book, they have fairly detailed info about the MS VM (try Modern Operating Systems by the MINIX fellow).
That's strange. mmap()'ing the file should be about as fast as read/write, since the Win2K VM implements read/write by mmap()'ing 256KB file regions into kenrel virtual memory and doing memcpy().
Actually, with 2.4.14-pre6 (I'm running the XFS CVS code with the preempt patches) Linus has apperently declared the VM fixed and dared people to break it. I've been using the kernel quite heavily for a few days, and its been great. I don't know how much of an improvement it is over 2.4.13, though. I had 2.4.13 for a total of a day before XFS CVS updated to the 2.4.14-pre series. (Linus releases pre kernels at an ungodly rate, and the XFS team manages to keep up.)
More features does not necessarily mean slower. Win2K had tons more features than NT4, but it was faster for most desktop-type uses. When you turn of Luna, XP is slightly faster (significantly faster in terms of app loading) than Win2K. (According to MaximumPC, whom I trust a hell of a lot more than InfoWorld, or any mainstream magazine for that matter.)
I've read the UVM paper twice (its like 200pp) and it really is a good design. I don't like the BSD idea of abstracting the VM away from the hardware so much (you spend a lot of memory in places you don't have to) but it does make the design cleaner. However, UVM is more of the mechanism part of the VM. Its the code that lets you share memory, memory map files, etc. What the Linux VMs are competing on, on the other hand, are the policy parts of the VM. What gets paged out and when. As it stands, UVM is probably tied with Linux on the low-level VM part (though UVM has a cleaner interface to the MMU hardare, IMO). The virtual memory filesystem cleaned up handling of shared memory segments significantly. (Before 2.4, swapping out normal memory and swapping out SysV shared memory were two different things). It has many more (cool) features, such as sharing address spaces, trading address space, etc, but few *NIX apps use those features (since its not standard *NIX API). FreeBSD probably has the best policy mechanism right now. The low-level VM is a heavily-tweeked one based on Mach's, but it doesn't have most of the modern features of UVM.
Of course, it all depends on the application one is using the system for. If you are running a webserver, you can tend towards the throughput side because latencies are going to be limited by the latency of the net connection (at least 20-30ms usually). If you're doing real time audio, you want to tend towards the latency side. On a desktop machine, it is probably best to tend towards latency. I doubt anybody minds a compile finishing 10% slower if it means that their MP3s don't skip and their mouse doesn't jump around. Interestingly, the 2.4 kernel is actually pretty good about both (maybe excluding VM and some filesystem code). With the preempt patches, latency is down to 2ms or so, while throughput is almost unchanged (or even sped up, depending on the task). Of course, you make the assumption that there are no other things limiting the performance of the app. Having used Linux GUIs for awhile, I'd say that's quite an assumption...
Look at it this way. Say 1GB of memory with VM will allow you to fit a 100 programs in RAM. Without VM, that number drops to 50. Your solution would be to just double your RAM, at which point I could have 200 programs with VM, but only 100 without. No matter how much memory you add, you can always find ways to fill it. VM doesn't incur a terribly large performance hit (at least when its not trashing) so its a no-brainer to include it. And its RAM, not core... damn grognards...
Actually, its a gradient thing. GNOME is fast enough not to choke while drawing the menus, but is slow enough to visibly redraw. Of course, thats a problem with a whole lot of X apps (GNOME and KDE included). Interestingly, though, I don't thing its X or GTK+ at fault. If you try resizing ROX-filer, you'll see that it does so as fast as any Windows program. A whole lot of the problem comes from lazy application programmers.
QNX sucks as a desktop OS precisely because it lacks a decent VM (and a decent FS, but that's another can of worms...)
A VM doesn't make the system any slower. The cost of maintaining mapping data and such is negligable compared to the other startup costs associated with applications. Also, most VMs do very little until the system memory becomes stressed. FreeBSD, for example, won't really bother keeping page ages up to date unless there is a lack of available pages. As long as you're not swaping, a VM-based system is no slower than a non-VM system. By the time you're swaping, however, a VM system has a lot more active processes (since the working set of each process is smaller than the total image) than a non VM system. Also, a VM system can deal with temporary demands for a huge amount of memory (such as compiling, in which the disk is getting trashed anyway), while a non-VM system can't. In fact, the QNX developers had to hack GCC to use their swap extensions because it wouldn't run on any sensible RAM config without VM.
You're comments about RAM are also questionable. While RAM might be getting cheaper, the uses for RAM are increasing. The more RAM you add, the more uses you can find for it, such as rendering bigger images, etc. There is no point in wasting a significant amount of it when you don't have to.
Lastly, the comments about process swaping are completely off the wall. App developers are inherently lazy, which is why modern systems take as much responsibility away from them as possible. If you left it up to the application developers to manage memory, then you'd end up with gigantic (more so than now, if that's possible) runtime footprints.
Dude, a VM is an awefully low level bit of code to make a compile option! XFS, for example, won't work the the AC kernels due to the different VM. Probably, the two seperate kernels are the best idea ATM.
Were not talking userspace applications here, we're talking about the kernel. Both the Linux and FreeBSD projects go to extreme lengths to optimize the performance of their kernels. The FreeBSD VM, for example, is very complex, but performs well due to that complexity.
Pervasive multithreading is great. It forces developers to design their apps for user responsiveness (something most Linux GUI apps SERIOUSLY lack). The whole idea of the drawing code being a part of the main application loop is sickening. The window update should not wait for the rest of the application to finish processing before it can run. That leads to the annoying "blank widgets" in busy apps. Its not terribly intelligent to force the design on normal parts of the application, but GUI updates are a very specific type of computing, and there is nothing wrong with having a drawing thread for each window. Note, BeOS is multithreaded mainly in the window update method of BWindows. Draw methods should ALWAYS (in any GUI system) be extremely short and simple. If you are doing lots of crazy things in your update callback, then something is wrong with your application design.
There aren't any real problems with the patches (I'm using them right now on an XFS kernel, btw), its just that they make an extensive change to spinlocks, which are a very basic part of the kernel. As such, they touch almost every piece of code in the system. Because of that, they are considered 2.5 material.
Citrix ICA is also pretty fast, even over my 500K DSL connection.
Its really easy to track the XFS tree on a workstation too. I have a little script that automatically gets the CVS sources off the SGI website. I tend to get the Pre kernels (running 2.4.14-pre3 right now) but it works OK so far.
Quote 2:
"The main reasons why I don't like Linux are the non-flexibility and the "chaos"."
If you don't like why do you use it?
>>>>>>>>>
I think he is making the distinction between Linux the kernel and Linux the OS. Linux is a great kernel. It is a sub-par desktop system.
Quote 3:
"For "performance" addicted people, a version of the app_server which will only use the XFree86 drivers will appear on the BlueOS v2, it means that BlueOS will not use the XServer anymore!"
I'm quite interested how he will do this.
>>>>>>>>>
XAA is the new X driver architecture. Its nice and clean, and any windowing system should be able to load X drivers and use them (in theory).