No, not really. There are things that are difficult to do (the desktop sharing stuff in KDE probably suffers most), but the XFree guys are working on extensions that will solve them. There is no need to create a new window system because of that. X11 is very extendable, and that's why it has survived for such a long time.
Yes, but you should know that build-in encryption will make the latency very bad. It wont be fun to use on a LAN (over slow links the difference should be harder to notice).
That's the point. For a newbie it is not obvious if suddenly an obscure panel applet appears (which is a problem for itself, because of the placement of the applet) that is connected to krfb - if you remove the strange thing that suddenly appeared at some unusual place in the panel, a functionality doesnt work anymore...
(the kded thingy is called kinetd, and does not have any krfb-related code. It is the smaller problem though)
krfb only runs while somebody is connected. It never runs the rest of the time. But the web server needs to be available before the user connects. krfb can't start kpf because it is simply not running at the time kpf needs to be started.
Beside that, starting a panel applet to allow somebody to access krfb using a http server is not very logical for the user. If you want a hackish solution, just create a simple HTML page which contains the applet and publish it using kpf.
The applet is not the problem. It's the web server.
krfb has been carefully designed to minimize memory use. Even if you have it enabled all the time it shouldnt take more than a few kb, because the server only starts when you connect (listening on the TCP port is done by a tiny kded module)
Personally I don't like that we have more and more HTTP servers in KDE. kpf is a HTTP server, kxmlrpcd is a HTTP server, and krfb would have HTTP server number 3. There should be a HTTP server infrastructure in kde...
Re:VNC + KDE has been broken in the past.
on
KDE 3.1 Released
·
· Score: 1
The VNC support in 3.1 is not related to vncserver, but I used vncserver with KDE in the past without any problems.. my xstartup has only two lines:
Yes, I always found it dreadfully tedious to type vncserver at the prompt.
For the intended audience, newbies, it is difficult
I doubt that your vncserver has the ability to generate random one-time passwords that are invaildated automatically after one hour or after a successful login
... and I doubt that it helps you sending the passwords and a text that includes your IP address, instructions how to connect etc
Re:Support for SSH?
on
KDE 3.1 Released
·
· Score: 4, Interesting
No, no vnc over ssh ATM. (I think that ssh tunnels are pretty hackish btw, ssl should result in a smoother user experience).
RDP support is currently in CVS - but there is no RDP server for X11, and it would be a lot of work to write one... rather expect the ability to use X11 as protocol with a UI like VNC.
> 4. a real GUI for everything That one still needs a bit more elaboration.
Basically it frees you of having to read a manual and to remember command line options... and it offers 'profiles' for different network environments, so you do not need to know all the VNC codecs to have optimal settings(did you know that a -encodings "copyrect hextile" results in dramatically better latency values on local LANs than the default TightVNC settings?). And you can switch modes (fullscreen, scaled) while you are connected.
Also... This is an application, OK? Does it really require a desktop upgrade?
Not really, it is more about convenience for both user and developer. The newer KDE and Qt version fix a number of bugs that caused problems though. I do not have the time tomaintain backports, I rather work on improvements. You are, of course, free to provide backports for older KDE versions.
CCache only helps when you compile exactly the same source for a second time - usually done when re-building the source. It does not help you when you compile a file for the first time, when you compile a file that has changed or when a included header has changed. Pre-compiled headers do, even in the latter case (because the header has to be re-compiled only once, not in every file).
Unfortunately the pre-compiled GCC version requires some heavy modifications of the sources - you can only have one pre-compiled header per file! This makes it pretty useless right now. To make use of it you had to bundle all headers into a single file. This, however, would slow down compilations for GCC versions without pre-compiled header support. So the situation is not trivial...
X11 does not need more resources than RDP. It runs fine on low-end machines. It has even been written on low-end machines, it is 10 years old
It is naive to believe that it is easier to write a new window system, write new drivers for all chipsets and port all apps, toolkits and so on instead of fixing X11s problem by improving X11
Creating a new Window system does not solve your Windows-related problems. Now you have a X11 server that works badly, when you have a new window system you don't have a server at all (unless you write one, but it would be less work to improve the X11 port for Windows)
Re:And then the updater gets hacked
on
Due Diligence?
·
· Score: 2
I think that you can prevent this kind of problem if you make the number N large enough. If you, for example, wait 7 days before you turn the server off (and just send a mail to the admin immediately), you can still prevent most worms. Shutting the server down is only the last resort, when the sysadmin does not react. The most important advantage is, that the admin knows a) that there is a bug that affects a server he is responsible for and b) he gets a complete list of all affected machines.
Re:Servers should disable themselves...
on
Due Diligence?
·
· Score: 2
I dont care if responsible admins turn the option off. But the majority of servers are more or less umaintained. The majority of people doesn't care for security advisories, and those people can be protected by reasonable defaults that cause the server to deactivate itself if it is a danger for the (obviously naive) owner.
And BTW, dont forget that not only the owner of the server is harmed when a hacker compromises a server and starts a distributed DOS attacks...
Re:Servers should disable themselves...
on
Due Diligence?
·
· Score: 1
What happens when the information is not available is a policy issue that should be configured on a per-server base, as long as the defaults are reasonable. I guess that a server that can not access a HTTP source is not connected to the internet, and thus not such a large danger.
Re:Servers should disable themselves...
on
Due Diligence?
·
· Score: 1
You could prevent this if you have several providers for the information (for example the distributions) and you sign the information.
Servers should disable themselves...
on
Due Diligence?
·
· Score: 2, Interesting
IMHO the right way is to write a system that disables servers automatically if a vulnerability is known and the administrator did not fix it in n days. Either the functionality is integrated into the daemons, and they check (via http, mail, whatever) every day whether they are affected by a problem. Or each system should run a daemon that controls all server software. It should warn the admin before it turns the server off, of course, but a broken unmaintained server is always better than a hacked server.
Assuming that Mono works well and there is a Managed C++ compiler, it is relatively easy for KDE to switch to Mono.
For Gnome switching will be much more difficult because their current C with GObject style can not be easily converted without a major rewrite. (You can, of course, still write wrappers, but it's not much fun to go back to such a low-level system each time you want to enhance the core libraries) Another problem for Gnome will be that they have attracted many old-school hackers with their pure C policy. Do you think that they will they happily switch to C# for new developments?
but this is just the trailer! Is there something I'm not aware of about this trailer or movie that makes it so special as to justify a Slashdot front page post?
So far there has been a slashdot story for every single star wars or star trek trailer and teaser. Finding Nemo is much cooler... IMHO.
Slashdot Mirror
No, not really. There are things that are difficult to do (the desktop sharing stuff in KDE probably suffers most), but the XFree guys are working on extensions that will solve them. There is no need to create a new window system because of that. X11 is very extendable, and that's why it has survived for such a long time.
Yes, but you should know that build-in encryption will make the latency very bad. It wont be fun to use on a LAN (over slow links the difference should be harder to notice).
That's the point. For a newbie it is not obvious if suddenly an obscure panel applet appears (which is a problem for itself, because of the placement of the applet) that is connected to krfb - if you remove the strange thing that suddenly appeared at some unusual place in the panel, a functionality doesnt work anymore...
(the kded thingy is called kinetd, and does not have any krfb-related code. It is the smaller problem though)
krfb only runs while somebody is connected. It never runs the rest of the time. But the web server needs to be available before the user connects. krfb can't start kpf because it is simply not running at the time kpf needs to be started.
Beside that, starting a panel applet to allow somebody to access krfb using a http server is not very logical for the user. If you want a hackish solution, just create a simple HTML page which contains the applet and publish it using kpf.
The VNC support in 3.1 is not related to vncserver, but I used vncserver with KDE in the past without any problems.. my xstartup has only two lines:
#!/bin/sh
startkde &
Yup, no applet. It's not very high on my priority list, and doing it right would be a lot of work...
No, no vnc over ssh ATM. (I think that ssh tunnels are pretty hackish btw, ssl should result in a smoother user experience).
RDP support is currently in CVS - but there is no RDP server for X11, and it would be a lot of work to write one... rather expect the ability to use X11 as protocol with a UI like VNC.
Better yet, does the KDE viewer buffer the graphics?
Yes.
Btw, whatever happened to Keystone?
Nothing, it never supported any of the compression encodings. Porting the TightVNC client was easier than adding all the stuff to keystone...
> 4. a real GUI for everything
That one still needs a bit more elaboration.
Basically it frees you of having to read a manual and to remember command line options... and it offers 'profiles' for different network environments, so you do not need to know all the VNC codecs to have optimal settings(did you know that a -encodings "copyrect hextile" results in dramatically better latency values on local LANs than the default TightVNC settings?). And you can switch modes (fullscreen, scaled) while you are connected.
Also... This is an application, OK? Does it really require a desktop upgrade?
Not really, it is more about convenience for both user and developer. The newer KDE and Qt version fix a number of bugs that caused problems though. I do not have the time tomaintain backports, I rather work on improvements. You are, of course, free to provide backports for older KDE versions.
CCache only helps when you compile exactly the same source for a second time - usually done when re-building the source. It does not help you when you compile a file for the first time, when you compile a file that has changed or when a included header has changed. Pre-compiled headers do, even in the latter case (because the header has to be re-compiled only once, not in every file).
Unfortunately the pre-compiled GCC version requires some heavy modifications of the sources - you can only have one pre-compiled header per file! This makes it pretty useless right now. To make use of it you had to bundle all headers into a single file. This, however, would slow down compilations for GCC versions without pre-compiled header support. So the situation is not trivial...
I think that you can prevent this kind of problem if you make the number N large enough. If you, for example, wait 7 days before you turn the server off (and just send a mail to the admin immediately), you can still prevent most worms.
Shutting the server down is only the last resort, when the sysadmin does not react.
The most important advantage is, that the admin knows a) that there is a bug that affects a server he is responsible for and b) he gets a complete list of all affected machines.
I dont care if responsible admins turn the option off. But the majority of servers are more or less umaintained. The majority of people doesn't care for security advisories, and those people can be protected by reasonable defaults that cause the server to deactivate itself if it is a danger for the (obviously naive) owner.
And BTW, dont forget that not only the owner of the server is harmed when a hacker compromises a server and starts a distributed DOS attacks...
What happens when the information is not available is a policy issue that should be configured on a per-server base, as long as the defaults are reasonable. I guess that a server that can not access a HTTP source is not connected to the internet, and thus not such a large danger.
You could prevent this if you have several providers for the information (for example the distributions) and you sign the information.
IMHO the right way is to write a system that disables servers automatically if a vulnerability is known and the administrator did not fix it in n days. Either the functionality is integrated into the daemons, and they check (via http, mail, whatever) every day whether they are affected by a problem. Or each system should run a daemon that controls all server software.
It should warn the admin before it turns the server off, of course, but a broken unmaintained server is always better than a hacked server.
No, it means those .movs encoded with Sorenson v3. Including all newer trailers on Apple.com.
Assuming that Mono works well and there is a Managed C++ compiler, it is relatively easy for KDE to switch to Mono.
For Gnome switching will be much more difficult because their current C with GObject style can not be easily converted without a major rewrite. (You can, of course, still write wrappers, but it's not much fun to go back to such a low-level system each time you want to enhance the core libraries)
Another problem for Gnome will be that they have attracted many old-school hackers with their pure C policy. Do you think that they will they happily switch to C# for new developments?
Try this one:i nding_ nemo/trailer_750.asx
http://acw.activate.net/digitalmedia/bvim/f
but this is just the trailer! Is there something I'm not aware of about this trailer or movie that makes it so special as to justify a Slashdot front page post?
So far there has been a slashdot story for every single star wars or star trek trailer and teaser. Finding Nemo is much cooler... IMHO.
This is the first trailer on Apple's site (and the Pixar.com as well). There was a teaser on the Monsters Inc DVD though...