I don't think there's necessarily anything wrong with using computer programs to solve problems like that - but you have to know how they work out their answers, so you can check if they make any sense (just like using a calculator to solve basic maths problems). I'd imagine that with engineering software, chances are you won't know how to use the software properly if you don't understand the principles anyway.
GTK free license allows comercial software to link to it. Thats not true for QT.
That's true, however the licensing of Qt is about as flexible as it can be whilst still allowing Trolltech to continue doing business. It's pretty reasonable if you ask me.
Any small change in the gpl version that is not owned by Trolltech will not be able to be licensed for comercial purposes.
Nobody is going to fork the Qt GPL version unless Trolltech start taking it in the wrong direction. Given the nature of Trolltech as a company, the people behind it, and their track record, that is unlikely.
I don't buy into the suggestion that allowing commercial developers to basically freeload without contributing back is a good thing. Qt is a quality toolkit which saves development time, so IMO it's not too much to ask commercial developers to either release the source code or pay for a commercial license.
Is it "possible" to write software that will run in linux that does not "require" GPL code?
Yes. Most libraries on Linux are released under the LGPL or other licenses that do not force you to distribute source code to applications that link to those libraries. Of course you should check the licence for each library you intend to use first (just as you should in the proprietary world).
Many source licenses and even documentation licenses from companies like Microsoft and Sun include explicit restrictions on what you can do after you have looked at the source code.
Even if that weren't the case, were it to come to court simply looking at the code and then going and working on something similar opens the door for a lawyer to suggest that was where you got some of your ideas from. All they have to do is draw enough parallels between the code and your product and put on a good enough show and that's it.
microsoft will build this into longhorn server. its called hypervisor. the virtualization is in the os. bye bye vmware.
Not really. Sure, it'll give you similar capabilities to VMware Workstation or Server, but I'd be surprised if they were able to provide the same level of VM infrastructure capabilities as VMware ESX Server has or even management tools that are as good as Workstation. It remains to be seen whether they can even offer the same level of performance, too.
Don't forget that AMD and Intel are building virtualisation capabilities into their next line of CPUs. That will be much more of a shakeup.
It seems to me that OS-level virtualization is a cool sounding idea that is pretty hopeless in the real world.
It depends on the application. If you're talking about a web host running lots of web servers it might make sense to use this approach, since the guest systems are likely to be very similar if not the same.
You missed the point, which is that it's not the naming scheme that's keeping more people from using these applications - otherwise the similar naming schemes used by Windows and Mac applications would be driving people away as well. A small minority seem to be hung up on the naming issue, however in my experience most of the people who complain about the naming don't have any interest in actually using the applications themselves, so it's not really a big problem.
Re:Killustrator, Kontour, Karbon14, Inkscape
on
KOffice 1.5 Released
·
· Score: 1
KIllustrator was renamed to Kontour because of legal issues. AFAIK after development work on Kontour basically stopped, Karbon14 was created and replaced Kontour as the drawing application for KOffice 1.3 and later.
I haven't used any of these applications seriously, but I imagine that what you get most from Karbon14 as opposed to Inkscape is better integration with KDE. The same applies to most of the other KOffice applications.
Whether it's the developers fault or not isn't important when you just want something to work.
True, most users may not make the distinction. It's still important though because the manufacturers hold all of the cards, so if the situation is to be fixed most of the time it can only be by them.
Some hardware works great with linux, other hardware doesn't. The problem is that it's totally inconsistant.
If a device does not work in Linux then it is likely the fault of the manufacturer for refusing to provide information on how to support the device, or write a driver themselves. Blame them, not Linux.
I don't disagree with what you're saying - I'm sure many of the problems I have seen in Windows networks are due to lack of knowledge about how to set things up correctly. However, aren't you just strengthening the parent poster's point? If Windows requires a high degree of specialist knowledge to run reliably, then doesn't that mean it's actually hard to administer properly?
Windows has an edge in making things *seem* easier for the user, there's no doubt about it. I would argue however that when something goes wrong, it's often easier to determine what the problem is with a Linux system than it is a Windows one. The Windows Event log, for example, often contains cryptic error messages that rival anything that you'd see in the system logs on a Linux box.
Actually, "using winelib" is almost exactly the same as running with the wine "emulator".
No, if you do it properly then it really isn't. If you're the developer of the app and you're linking it to winelib to get it running on Linux, and you're serious about it, then you're going to be able to go a lot further and produce a much more polished and functional product than the Win32 version running under WINE itself.
Perhaps you are thinking of KitchenSync? In newer versions of KDE this is going to be back-ended by OpenSync which is a universal syncing platform that can be used by all. OpenSync is perhaps a little rough around the edges at the moment but there is already support for quite a few mobile phones and PIM platforms (including those of KDE).
Slashdot Mirror
Wouldn't it make their interaction with the computer look more... natural? more belivable?
Tell that to the hojillion directors that have people typing with no text appearing on the screen.
Already been done (sort of).
I don't think there's necessarily anything wrong with using computer programs to solve problems like that - but you have to know how they work out their answers, so you can check if they make any sense (just like using a calculator to solve basic maths problems). I'd imagine that with engineering software, chances are you won't know how to use the software properly if you don't understand the principles anyway.
I know you were joking, but one study found that Germans actually have the best sense of humour.
Someone that is just starting to work as a freelancer in the 3rd world would never be able to afford for QT
c enses/licensing/smallbusiness
Well, in this situation there is another option provided by TrollTech:
http://www.trolltech.com/trolltech/products/qt/li
I dont see much sense in releasing free software and then complain that people are freeloading it.
This "freeloading" I speak of is against the spirit of the GPL, which is designed to encourage community contribution.
GTK free license allows comercial software to link to it. Thats not true for QT.
That's true, however the licensing of Qt is about as flexible as it can be whilst still allowing Trolltech to continue doing business. It's pretty reasonable if you ask me.
Any small change in the gpl version that is not owned by Trolltech will not be able to be licensed for comercial purposes.
Nobody is going to fork the Qt GPL version unless Trolltech start taking it in the wrong direction. Given the nature of Trolltech as a company, the people behind it, and their track record, that is unlikely.
I don't buy into the suggestion that allowing commercial developers to basically freeload without contributing back is a good thing. Qt is a quality toolkit which saves development time, so IMO it's not too much to ask commercial developers to either release the source code or pay for a commercial license.
imagine trolltech stop licensing it
1 89/
http://www.trolltech.com/developer/knowledgebase/
or if the distros just fork it
"The distros" could just as easily fork Gtk. Why is this issue specific to Qt?
Is it "possible" to write software that will run in linux that does not "require" GPL code?
Yes. Most libraries on Linux are released under the LGPL or other licenses that do not force you to distribute source code to applications that link to those libraries. Of course you should check the licence for each library you intend to use first (just as you should in the proprietary world).
I would assume SGI will need to sell its assets to cover debts, so someone else will end up with ownership of the IP.
I'd really like a list of the things that you say that they've done to make you less free.
I'll bite...
* The PATRIOT act
* No-Fly lists
* "Free Speech" Zones
Those are just three examples I can think of off the top of my head.
Many source licenses and even documentation licenses from companies like Microsoft and Sun include explicit restrictions on what you can do after you have looked at the source code.
Even if that weren't the case, were it to come to court simply looking at the code and then going and working on something similar opens the door for a lawyer to suggest that was where you got some of your ideas from. All they have to do is draw enough parallels between the code and your product and put on a good enough show and that's it.
I'm pretty sure Windows and Office don't fall into this category, though.
You can already do this kind of high-res surveillance using a line-scanning camera (which would be a mounted CCTV type camera). It works very well.
microsoft will build this into longhorn server. its called hypervisor. the virtualization is in the os. bye bye vmware.
Not really. Sure, it'll give you similar capabilities to VMware Workstation or Server, but I'd be surprised if they were able to provide the same level of VM infrastructure capabilities as VMware ESX Server has or even management tools that are as good as Workstation. It remains to be seen whether they can even offer the same level of performance, too.
Don't forget that AMD and Intel are building virtualisation capabilities into their next line of CPUs. That will be much more of a shakeup.
I think you can disable adding hardware using a group policy in Windows. Wouldn't that solve this issue?
It seems to me that OS-level virtualization is a cool sounding idea that is pretty hopeless in the real world.
It depends on the application. If you're talking about a web host running lots of web servers it might make sense to use this approach, since the guest systems are likely to be very similar if not the same.
You missed the point, which is that it's not the naming scheme that's keeping more people from using these applications - otherwise the similar naming schemes used by Windows and Mac applications would be driving people away as well. A small minority seem to be hung up on the naming issue, however in my experience most of the people who complain about the naming don't have any interest in actually using the applications themselves, so it's not really a big problem.
KIllustrator was renamed to Kontour because of legal issues. AFAIK after development work on Kontour basically stopped, Karbon14 was created and replaced Kontour as the drawing application for KOffice 1.3 and later.
I haven't used any of these applications seriously, but I imagine that what you get most from Karbon14 as opposed to Inkscape is better integration with KDE. The same applies to most of the other KOffice applications.
Amnd oyu rof kamign em drae hatt.
If you're going to make up an April Fools hoax at least make it remotely plausible. Only a total muppet could believe this story.
Whether it's the developers fault or not isn't important when you just want something to work.
True, most users may not make the distinction. It's still important though because the manufacturers hold all of the cards, so if the situation is to be fixed most of the time it can only be by them.
Some hardware works great with linux, other hardware doesn't. The problem is that it's totally inconsistant.
If a device does not work in Linux then it is likely the fault of the manufacturer for refusing to provide information on how to support the device, or write a driver themselves. Blame them, not Linux.
I don't disagree with what you're saying - I'm sure many of the problems I have seen in Windows networks are due to lack of knowledge about how to set things up correctly. However, aren't you just strengthening the parent poster's point? If Windows requires a high degree of specialist knowledge to run reliably, then doesn't that mean it's actually hard to administer properly?
Windows has an edge in making things *seem* easier for the user, there's no doubt about it. I would argue however that when something goes wrong, it's often easier to determine what the problem is with a Linux system than it is a Windows one. The Windows Event log, for example, often contains cryptic error messages that rival anything that you'd see in the system logs on a Linux box.
Actually, "using winelib" is almost exactly the same as running with the wine "emulator".
No, if you do it properly then it really isn't. If you're the developer of the app and you're linking it to winelib to get it running on Linux, and you're serious about it, then you're going to be able to go a lot further and produce a much more polished and functional product than the Win32 version running under WINE itself.
The Sync
Perhaps you are thinking of KitchenSync? In newer versions of KDE this is going to be back-ended by OpenSync which is a universal syncing platform that can be used by all. OpenSync is perhaps a little rough around the edges at the moment but there is already support for quite a few mobile phones and PIM platforms (including those of KDE).