Instead of punishing other countries that are less wealthy, why not establish a international minimum wage. You can still impose tarrifs on those countries that don't have them, but this would as well protect people in your country and help people in less developed countries. And, of course, re-established international competition at a fairer level.
Indeed, i doubt that the network code is more than 0.1%... there is almost no difference between a TCP connection and the Unix Domain Sockets used for IPC.
Re:Time for the obvious X-Free rant
on
XFree86 Politics
·
· Score: 1
a) is basically what I said with 'more intelligence in the server'. b) is not possible unless the drivers are in the kernel, because only root is allowed to access the graphics device. NVidia's driver works like this, with a kernel module.
In fact, I have a hard time seeing the reasoning behind such an application, it seems to be copying Windows for the sake of it. For tech support, connecting via ssh/X is far easier to work with, and over a LAN X is more efficient.
ssh/x is ok (actually better) when you want to start a application on the computer for administration. The advantage of desktop sharing is that you can show things to the user while talking to her on the telephone. It's not strictly a remote administration tool, but rather useful for help desk.
Concerning windows, I started it before I heard of WinXP's Remote Assistance. I looked at it closely when I discovered it, and certainly took a few ideas.
Re:What we need is more radical than a fork of XFr
on
XFree86 Politics
·
· Score: 1
So far no one came up with a superior concept that convinced a significant number of people. It's quite likely that this won't change unless the requirements change dramatically. All the things that you listed would be possible using X11 extensions. X11 extensions are the reason why X11 survived for such a long time, and why it won't die in the next 10 years.
KDE's desktop sharing is different from what X11 provides. X11 lets a several applications use a single screen and coordinates things like input events, redraws etc between them. VNC uses a very simple, bitmapped-based protocol that transmits the complete screen. Implementing the desktop sharing use case in a x11 protocol derivative would have been very complex and time consuming, while VNC was quite easy to do. The disadvantage is that VNC's performance sucks compared to X11, or RDP, or the Citrix stuff.
Re:Time for the obvious X-Free rant
on
XFree86 Politics
·
· Score: 1
You always need the server when you have two or more independent applications (=processes) that work on the same screen. And Unix Domain Sockets are not slower than any other IPC mechanism for commands. For large data X11 already uses shared memory. The only thing that you may change is to put more intelligence into the server, like MacOS X does by having PDF display descriptions and backbuffers. But this is also possible with X11, as display postscript showed.
Re:A fork would be *bad*
on
XFree86 Politics
·
· Score: 2, Insightful
I don't know a single app that targets XFree directly. They all target X11. The apps may take advantage of XFree86 features, but run on any other X11 server. The same will be the case if they fork. But as the development in XFree is rather slow, and at least my impression is that all feature-improvements in the last 2 years have been partially or completely done by KeithP, I doubt that anyone would still bother to use XFree in another 2 years...
I know, but I meant 'glib-as-a-programming-framework'. I didnt talk about the toolkit. Gtk by principle would be ok, but the glib style (esp. GObject) is what makes it ugly to use.
Yes, GObject is really scary. You probaby need 10 time as long to create a simple class, and it is also very error-prone because you have to do it by hand (unless you want to use a obscure, undocumented object compiler). Simple things like virtuals become quite complicated. And KDE's object system does not stop at QObject. The meta-compiler also automatically generates code for signals/slots, DCOP and so on. This system is a significant part of what makes KDE programming so fun and productive.
No one doubts that, but the future will not be decided by the current state. JuK (which will appear in 3.2) is certainly already better than xmms in most aspects. Kopete will compete with gaim, and KMail's IMAP support in HEAD is already much better than 3.1's.
Most KDE developers have chosen KDE because they think it is superior. Otherwise they would have chosen Gnome. For example, I worked on Gnome stuff for a while but it was almost unusable for me. Then I decided to give KDE a try and never went back.
So today the fundamental rift is that KDE developers think that C++/Qt is the most productive environment. Using GLib is just no fun, it is painful compared to C++/Qt, Java, C#, basically every modern programmign environment. And I also think that it is not possible to compete with MacOS X and Windows using C/Glib technology. They are already years ahead, and trying to catch up using a more primitive programming environment is crazy. I could understand to go 100% Mono, but C/glib? I would rather stop developing on GUI software and/or buy a Mac than write GUI apps using glib.
Yes, but a email editor with three vertical panes isnt that revolutionary either. It just may be a good idea with todays resolutions (or maybe not, didnt try it).
*Very* few things in today's desktop systems are revolutionary. Most are just features from experimental systems in the past or copied from 3rd party products.
If it is cloning improvements: yes, certainly. It's not like MS would not clone features of the X11 desktop environment. For example the Longhorn previews showed CDE/KDE/Gnome-features like virtual desktops and panel applets.
I wonder what the security implications are. If every device is able to route, a malicious device could claim to have great connections to other devices in the mesh and then drop packets. Unless there is some way of authentication in the mesh (so that only authenticated devices can participate), it would need some trust/rating system so devices can exchange information about the reliability of other devices...
I guess the interesting parts is that all distros (Suse, Mandrake, Xandros) are KDE distros. So what is it? Some kind of KDE League revival with some extras (OpenOffice & CrossWeaver)?
AFAIK it is more compliant at the moment because it supports more SVG features. But librsvg is just a static renderer, whereas KSVG aims to offer a complete DOM model to KJS, KDE's JavaScript engine. This allows Macromedia Flash-like interactive animations using SVG+JavaScript.
Yes, but this is quite theoretical. While the GPL does not require you to release it, it does not forbid your employees, contractors and so on to release it. Anybody is allowed, and copyright doesnt stop you.
Re:Could run afoul of US Laws
on
Corporate KDE
·
· Score: 1
If this would be illegal, it would be illegal for the government to release software that it payed for as open source.
Then you should wait until 3.2, and then try Kontact (instead of Evolution) and Kopete (to replace gaim). There is currently nothing comparable to Eclipse, but maybe someone ports Eclipe's toolkit to Qt/KDE.
Re:Could run afoul of US Laws
on
Corporate KDE
·
· Score: 2, Informative
It is not, since it was contract work. It had to be release since it extended GPL'd software.
Re:strange
on
Corporate KDE
·
· Score: 5, Informative
The article is wrong: the german government did not fund work on KDE, a t least not directly. A number of companies have been contracted to extend KDE for the government. As the code is GPL, they have to release it to the public.
Slashdot Mirror
Instead of punishing other countries that are less wealthy, why not establish a international minimum wage. You can still impose tarrifs on those countries that don't have them, but this would as well protect people in your country and help people in less developed countries. And, of course, re-established international competition at a fairer level.
Indeed, i doubt that the network code is more than 0.1%... there is almost no difference between a TCP connection and the Unix Domain Sockets used for IPC.
a) is basically what I said with 'more intelligence in the server'. b) is not possible unless the drivers are in the kernel, because only root is allowed to access the graphics device. NVidia's driver works like this, with a kernel module.
In fact, I have a hard time seeing the reasoning behind such an application, it seems to be copying Windows for the sake of it. For tech support, connecting via ssh/X is far easier to work with, and over a LAN X is more efficient.
ssh/x is ok (actually better) when you want to start a application on the computer for administration. The advantage of desktop sharing is that you can show things to the user while talking to her on the telephone. It's not strictly a remote administration tool, but rather useful for help desk.
Concerning windows, I started it before I heard of WinXP's Remote Assistance. I looked at it closely when I discovered it, and certainly took a few ideas.
So far no one came up with a superior concept that convinced a significant number of people. It's quite likely that this won't change unless the requirements change dramatically. All the things that you listed would be possible using X11 extensions. X11 extensions are the reason why X11 survived for such a long time, and why it won't die in the next 10 years.
KDE's desktop sharing is different from what X11 provides. X11 lets a several applications use a single screen and coordinates things like input events, redraws etc between them. VNC uses a very simple, bitmapped-based protocol that transmits the complete screen.
Implementing the desktop sharing use case in a x11 protocol derivative would have been very complex and time consuming, while VNC was quite easy to do. The disadvantage is that VNC's performance sucks compared to X11, or RDP, or the Citrix stuff.
You always need the server when you have two or more independent applications (=processes) that work on the same screen. And Unix Domain Sockets are not slower than any other IPC mechanism for commands. For large data X11 already uses shared memory.
The only thing that you may change is to put more intelligence into the server, like MacOS X does by having PDF display descriptions and backbuffers. But this is also possible with X11, as display postscript showed.
I don't know a single app that targets XFree directly. They all target X11. The apps may take advantage of XFree86 features, but run on any other X11 server. The same will be the case if they fork.
But as the development in XFree is rather slow, and at least my impression is that all feature-improvements in the last 2 years have been partially or completely done by KeithP, I doubt that anyone would still bother to use XFree in another 2 years...
I know, but I meant 'glib-as-a-programming-framework'. I didnt talk about the toolkit. Gtk by principle would be ok, but the glib style (esp. GObject) is what makes it ugly to use.
Yes, GObject is really scary. You probaby need 10 time as long to create a simple class, and it is also very error-prone because you have to do it by hand (unless you want to use a obscure, undocumented object compiler). Simple things like virtuals become quite complicated.
And KDE's object system does not stop at QObject. The meta-compiler also automatically generates code for signals/slots, DCOP and so on. This system is a significant part of what makes KDE programming so fun and productive.
No one doubts that, but the future will not be decided by the current state. JuK (which will appear in 3.2) is certainly already better than xmms in most aspects. Kopete will compete with gaim, and KMail's IMAP support in HEAD is already much better than 3.1's.
Most KDE developers have chosen KDE because they think it is superior. Otherwise they would have chosen Gnome. For example, I worked on Gnome stuff for a while but it was almost unusable for me. Then I decided to give KDE a try and never went back.
So today the fundamental rift is that KDE developers think that C++/Qt is the most productive environment. Using GLib is just no fun, it is painful compared to C++/Qt, Java, C#, basically every modern programmign environment. And I also think that it is not possible to compete with MacOS X and Windows using C/Glib technology. They are already years ahead, and trying to catch up using a more primitive programming environment is crazy. I could understand to go 100% Mono, but C/glib?
I would rather stop developing on GUI software and/or buy a Mac than write GUI apps using glib.
It's not much different in Europe..
Yes, but a email editor with three vertical panes isnt that revolutionary either. It just may be a good idea with todays resolutions (or maybe not, didnt try it).
*Very* few things in today's desktop systems are revolutionary. Most are just features from experimental systems in the past or copied from 3rd party products.
on a more serious note is cloning the way to win?
If it is cloning improvements: yes, certainly. It's not like MS would not clone features of the X11 desktop environment. For example the Longhorn previews showed CDE/KDE/Gnome-features like virtual desktops and panel applets.
I wonder what the security implications are. If every device is able to route, a malicious device could claim to have great connections to other devices in the mesh and then drop packets. Unless there is some way of authentication in the mesh (so that only authenticated devices can participate), it would need some trust/rating system so devices can exchange information about the reliability of other devices...
Nice, but I already have a portable Ogg Vorbis player: tkcPlayer
I guess people would do if MS would release the source code. I guess that's the point of this Open Source thingy :)
I guess the interesting parts is that all distros (Suse, Mandrake, Xandros) are KDE distros. So what is it? Some kind of KDE League revival with some extras (OpenOffice & CrossWeaver)?
AFAIK it is more compliant at the moment because it supports more SVG features. But librsvg is just a static renderer, whereas KSVG aims to offer a complete DOM model to KJS, KDE's JavaScript engine. This allows Macromedia Flash-like interactive animations using SVG+JavaScript.
Yes, but this is quite theoretical. While the GPL does not require you to release it, it does not forbid your employees, contractors and so on to release it. Anybody is allowed, and copyright doesnt stop you.
If this would be illegal, it would be illegal for the government to release software that it payed for as open source.
Then you should wait until 3.2, and then try Kontact (instead of Evolution) and Kopete (to replace gaim). There is currently nothing comparable to Eclipse, but maybe someone ports Eclipe's toolkit to Qt/KDE.
It is not, since it was contract work. It had to be release since it extended GPL'd software.
The article is wrong: the german government did not fund work on KDE, a t least not directly. A number of companies have been contracted to extend KDE for the government. As the code is GPL, they have to release it to the public.