When you use a standard phone connection, it's virtually impossible for someone to eavesdrop. A physical interception of the wires must be made, and that is usually detectable.
In many places, phone lines are accessible from the outside. Often, one home's phone connection will run through someone else's phone closet. And in apartment buildings, everything runs through big phone closets.
You don't even have to install anything in the phone closet, you just run a wire (either hair thin or boldly imitating the other wiring) from the line you want to intercept to a line that makes monitoring more convenient for you. The phone company will occasionally do this for you (by accident, one would assume; this is how I found out how poor wired phone security really is).
If you prefer, you can put a little box somewhere along where the wire runs, pick something up inductively, and send it out wirelessly. Something like that is about the size of a sugarcube.
Wired phone conversations may beat broadcasting your connection to a satellite, by they are trivial to eavesdrop on.
The only safeguard against eavesdropping you have is cryptography. And if you are concerned with tampering, SSL and ssh won't do (man-in-the-middle attack), you need a secure communications channel. If anything, satellite connections are a bit better because, if implemented correctly, they may be a little less susceptible to man-in-the-middle attacks.
Despite sensational headlines like these, altogether, I'd still bet that people are protected against invasion of privacy and unreasonable police prosecution better in the UK than in the US.
There are lots of surveillance cameras everywhere in the US, often coupled to various forms of recording devices: in convenience stores, supermarkets, shopping malls, highways, toll plazas, parking lots, etc. US prosecutors can and will track down these cameras and use them as evidence in court. So, I'm not convinced that the situation in the UK is really all that different from the US when it comes to surveillance cameras and their uses by the police.
In fact, because surveillance cameras in the US are mostly private, they probably are subject to less scrutiny and regulations. Keep in mind that Europe's privacy laws are pretty strong and restrict what companies can do quite severely.
The police, prosecutorial, and court system in the UK is also quite different from the US. In the UK, prosecutors are not rewarded for cases they win in the same way they are in the US; they actually have much less of an incentive to try to convict people if there is some doubt.
If you want a program like xmove to present a hardware-independent visual to its clients, it could easily do whatever remapping you would consider sensible. Doing that kind of adaptation of visuals is no harder in xmove than it would be if it were built into X11.
We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.
We don't when we program in high-level interfaces like Gtk+, Qt, or FLTK (which you wrote yourself, so you know it's possible).
But no matter what abstraction you present to application code, you don't want to ship 32bpp bitmaps over the network to a 1bpp or 2bpp display. That's why at the X protocol level, those distinctions are made; Xlib merely exposes them. Furthermore, some applications really need to know about the differences between visuals, so an API that presents a convenient true color abstraction of all displays just isn't acceptable.
I think web-based mail, IM, chatting, bookmarks, aggregation/summarization, and specialized web publishing like photos should really be provided by the ISP you already pay for, in addition to their current services. In fact, ISPs are trying. To make this more attractive, they need to become interoperable.
But I think there is a reasonable chance that Yahoo! may be able to charge for their services as an "ISP add-on". However, for that to be really attractive, they have to revamp their site to be less advertising oriented and even more oriented to satisfying exactly and only the needs of their (then) paying customers.
As long as we are talking about open formats, I'm all for open source programs like xpdf honoring the copy protection bits on PDF files. By default, I have no intention of overriding the author's preferences. And if open source programs don't honor these preferences, companies like Adobe will either use closed extensions for their next release, or they'll figure out something truly secure,.
The reason why I like to keep the format and the "encryption"/copy control open is that I would like to be able to get at the data if it is absolutely necessary. Why would that be necessary? Those bits might be set by mistake, on my own documents or on some other documents. Just recently, I got a government form in PDF format that said "print this" but had the copy protection bits set. Having to download a separate "decryption" patch seems about at the right level of effort for solving that kind of problem.
Of course, I do see the worry that with the DMCA, silly bits like this may receive undue legal protection and not checking may actually be/become illegal. But for Debian to stick its neck out on that doesn't seem smart; it will only bring about a rash legal judgement. Let's look for a better test case and a lot more public discussion before forcing this issue.
lightweight clients: RDP, ICA, and VNC.
on
Low-Bandwidth X
·
· Score: 1
Keep in minnd that the RDP and ICA clients are pretty lighweight compared to a full X installation (there are even Java applet versions). And I believe they actually take an approach to remote displays that is closer to VNC than X; I believe they (often?) transfer images, not drawing commands.
I suspect that one can probably get close to RDP or ICA performance with careful tuning of the VNC protocol. TightVNC is an attempt to do that.
What would VNC need to become even faster? I think VNC right now has no provisions for drawing commands at all. Extending the protocol to add a few drawing commands might help; servers could generate them if they have the information to do it. For example, a simple BitBlt operation would make scrolling much faster. Maybe a clear or interpolated area fill could also help.
One can also push compression quite a bit farther.
Another trick that might make VNC appear faster is a multi-window frontend. That way, you don't have to wait for the background to fill in, and small windows have only little overhead.
Unfortunately, xmove can't adapt different visuals to one another: if the X server you are moving to has an incompatible visual from the X server you are moving from, it doesn't work. VNC, on the other hand, works between almost all kinds of visuals.
So, it's a tradeoff which one to use. VNC or TightVNC probably requires a bit more bandwidth than mlview-DXPC and xmove. On the other hand, unlike the X solution, the VNC client is tiny, easy to install, and almost always works.
I have had better luck with TightVNC; it compresses a bit better, but I think the main advantage is that it requires less computation per tile. I use it regularly over 256kbaud Internet connections with no problems, but it seems more responsive even for local and LAN VNC connections.
Thanks for the response. I did experiment with this and other things, and I think it's still pretty limited and doesn't quite help with overcoming the impression that KDE is very "Windows-like".
The set of keybindings labeled "Unix" that ship with KDE 2.1 still contain bindings like Ctrl-W for "Close Window" and "Ctrl-N" for "New". It was nice that the presence of a "Unix" set of bindings indicates that the KDE project is aware of the issue, but I think a bit more still would need to be done to come up with bindings that really feel natural to a traditional Emacs/Unix user.
I'm running KDE 2.1 and have modified the key bindings as much as seems possible. Given the tools and documentation, you cannot rebind everything, nor can you rebind things to Emacs-like command sequences. Furthermore, key bindings that you configure in the control center are not consistently used by all applications (even Konqueror ignores some of them).
You are also wrong on your history. X11 toolkits traditionally had key and event binding support that was quite powerful, well documented, could be changed dynamically, and was consistent across applications. Neither KDE nor Gnome come close either on documentation or consistency or flexibility.
Even if KDE bindings were fully and consistently reconfigurable, the default right now is not correct for what people expect on a current Linux desktop. At the very least, if it wants to shed its Windows-like image, KDE should address the consistency issues and ship with a set of Emacs/UNIX-like bindings out of the box that users can choose with the click of a button.
lbxproxy ships with X11. dxpc is another X11 protocol compressor you can find on the web.
VNC gives you full network transparency, is cross platform, and is pretty lightweight. The TightVNC version works quite well over ISDN-speed links. The client even runs on a PalmPilot through its serial port.
Despite its generality and power, neither Microsoft's nor the W3C's SOAP spec provides enough information to create interoperable RPC services; clients and servers need to know a lot more about each other in addition to supporting the SOAP spec and what data they want to exchange. For example, as it stands, the spec doesn't tell you the format for something as simple as a string that might contain arbitrary characters or a number.
I can't tell whether this is a strategy by Microsoft to appear open and get others to adopt SOAP without actually delivering interoperability, or whether the SOAP designers just don't care and don't think it's important
Either way, I wouldn't get my hopes up that Linux and Windows-based services can always reliably talk to each other through SOAP. As it stands, SOAP is not a complete RPC spec and cannot replace even many simple uses of CORBA or DCOM. If that's what you want, Sun XDR/RPC is probably a better choice for you: it's much better specified. Or, of course, we can try to track Microsoft's actual implementation (as opposed to their spec) as much as possible.
One thing that makes KDE feel so much like Windows and makes it such a nuisance for non-Windows users is the fact that it uses CUA bindings. A UNIX, Gnome, or Emacs user that tries to go four lines down in a text widget is faced with four new windows popping up. Or they may want to go to the beginning of a line, hit Control-A, type a character, and see all their text disappears. That happens again and again, and makes it difficult for many UNIX users to ever feel really at home in KDE. And the CUA bindings were really pretty poorly designed to being with.
In general, I think you are right, though. Both KDE and Gnome follow Microsoft quite a bit. And while that may be useful for mass market appeal, overall, I think it's a shame. Linux's GUI could be so much more useful than merely doing well what Windows already does.
system already widely deployed in the US
on
Fiddler on the RUF
·
· Score: 2
Actually, we already have this system. In fact, the personal vehicles are cheaper, healthier, and don't have any parking problems. You can see the personal vehicles here. And here is more information about one of the many US rail systems that are compatible with those personal vehicles.
I think it makes more economic sense to provide some decent car-by-rail service: you drive your (regular) car onto a train in NYC and arrive a few hours later in Boston, with your own car and no driving hassles. You save money on car rentals at your destination, you save gasoline, and you save wear-and-tear on your car; all of that offsets the price of the train ticket.
This non-collaboration policy actually works, as Brown has one of the top cs programs in the nation.
Just because Brown is currently one of the top-rated CS programs in the nation doesn't mean that its non-collaboration policy works. Many top-rated CS programs have an excellent reputation based on their theory, graphics, or AI groups. Whether the students that come out of such programs can afterwards succeed as programmers or independent researchers is an entirely separate question.
I find the thought of any academic department or software development program having a "strict anti-collaboration policy" distressing, and it's certainly no recommendation for a CS department in my book. Teach your students legal and ethical collaboration and attribution, don't turn them into loners and people who want to reinvent the wheel all the time.
The fundamental problem with both CDDB and FreeDB is that they use TOC-based matching. That is not very reliable or robust for CDs, and it doesn't help you at all label an MP3 correctly once you have extracted it but lost its name.
What we really need is content-based matching. That's a bit harder, but there are a bunch of pretty obvious methods that should work reasonably well.
Of course, many of those methods, obvious or not, are probably being patented or have been patented by now because they are also very useful for detecting MP3 copyright infringement and for a variety of other commercial purposes.
That you can't buy a PC from many vendors without paying for Windows. And Microsoft fully intends to bind installations of Windows to the hardware. So, rather than being able to run your copy of MS Windows under VMware or on another machine, you have to buy a new license.
Windows is getting more and more expensive, just as if Microsoft had a monopoly. Oh, wait, they do.
Slashdot Mirror
In many places, phone lines are accessible from the outside. Often, one home's phone connection will run through someone else's phone closet. And in apartment buildings, everything runs through big phone closets.
You don't even have to install anything in the phone closet, you just run a wire (either hair thin or boldly imitating the other wiring) from the line you want to intercept to a line that makes monitoring more convenient for you. The phone company will occasionally do this for you (by accident, one would assume; this is how I found out how poor wired phone security really is).
If you prefer, you can put a little box somewhere along where the wire runs, pick something up inductively, and send it out wirelessly. Something like that is about the size of a sugarcube.
Wired phone conversations may beat broadcasting your connection to a satellite, by they are trivial to eavesdrop on.
The only safeguard against eavesdropping you have is cryptography. And if you are concerned with tampering, SSL and ssh won't do (man-in-the-middle attack), you need a secure communications channel. If anything, satellite connections are a bit better because, if implemented correctly, they may be a little less susceptible to man-in-the-middle attacks.
There are lots of surveillance cameras everywhere in the US, often coupled to various forms of recording devices: in convenience stores, supermarkets, shopping malls, highways, toll plazas, parking lots, etc. US prosecutors can and will track down these cameras and use them as evidence in court. So, I'm not convinced that the situation in the UK is really all that different from the US when it comes to surveillance cameras and their uses by the police.
In fact, because surveillance cameras in the US are mostly private, they probably are subject to less scrutiny and regulations. Keep in mind that Europe's privacy laws are pretty strong and restrict what companies can do quite severely.
The police, prosecutorial, and court system in the UK is also quite different from the US. In the UK, prosecutors are not rewarded for cases they win in the same way they are in the US; they actually have much less of an incentive to try to convict people if there is some doubt.
We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.
We don't when we program in high-level interfaces like Gtk+, Qt, or FLTK (which you wrote yourself, so you know it's possible).
But no matter what abstraction you present to application code, you don't want to ship 32bpp bitmaps over the network to a 1bpp or 2bpp display. That's why at the X protocol level, those distinctions are made; Xlib merely exposes them. Furthermore, some applications really need to know about the differences between visuals, so an API that presents a convenient true color abstraction of all displays just isn't acceptable.
But I think there is a reasonable chance that Yahoo! may be able to charge for their services as an "ISP add-on". However, for that to be really attractive, they have to revamp their site to be less advertising oriented and even more oriented to satisfying exactly and only the needs of their (then) paying customers.
The reason why I like to keep the format and the "encryption"/copy control open is that I would like to be able to get at the data if it is absolutely necessary. Why would that be necessary? Those bits might be set by mistake, on my own documents or on some other documents. Just recently, I got a government form in PDF format that said "print this" but had the copy protection bits set. Having to download a separate "decryption" patch seems about at the right level of effort for solving that kind of problem.
Of course, I do see the worry that with the DMCA, silly bits like this may receive undue legal protection and not checking may actually be/become illegal. But for Debian to stick its neck out on that doesn't seem smart; it will only bring about a rash legal judgement. Let's look for a better test case and a lot more public discussion before forcing this issue.
I suspect that one can probably get close to RDP or ICA performance with careful tuning of the VNC protocol. TightVNC is an attempt to do that.
What would VNC need to become even faster? I think VNC right now has no provisions for drawing commands at all. Extending the protocol to add a few drawing commands might help; servers could generate them if they have the information to do it. For example, a simple BitBlt operation would make scrolling much faster. Maybe a clear or interpolated area fill could also help.
One can also push compression quite a bit farther.
Another trick that might make VNC appear faster is a multi-window frontend. That way, you don't have to wait for the background to fill in, and small windows have only little overhead.
So, it's a tradeoff which one to use. VNC or TightVNC probably requires a bit more bandwidth than mlview-DXPC and xmove. On the other hand, unlike the X solution, the VNC client is tiny, easy to install, and almost always works.
I have had better luck with TightVNC; it compresses a bit better, but I think the main advantage is that it requires less computation per tile. I use it regularly over 256kbaud Internet connections with no problems, but it seems more responsive even for local and LAN VNC connections.
The set of keybindings labeled "Unix" that ship with KDE 2.1 still contain bindings like Ctrl-W for "Close Window" and "Ctrl-N" for "New". It was nice that the presence of a "Unix" set of bindings indicates that the KDE project is aware of the issue, but I think a bit more still would need to be done to come up with bindings that really feel natural to a traditional Emacs/Unix user.
You are also wrong on your history. X11 toolkits traditionally had key and event binding support that was quite powerful, well documented, could be changed dynamically, and was consistent across applications. Neither KDE nor Gnome come close either on documentation or consistency or flexibility.
Even if KDE bindings were fully and consistently reconfigurable, the default right now is not correct for what people expect on a current Linux desktop. At the very least, if it wants to shed its Windows-like image, KDE should address the consistency issues and ship with a set of Emacs/UNIX-like bindings out of the box that users can choose with the click of a button.
VNC gives you full network transparency, is cross platform, and is pretty lightweight. The TightVNC version works quite well over ISDN-speed links. The client even runs on a PalmPilot through its serial port.
I can't tell whether this is a strategy by Microsoft to appear open and get others to adopt SOAP without actually delivering interoperability, or whether the SOAP designers just don't care and don't think it's important
Either way, I wouldn't get my hopes up that Linux and Windows-based services can always reliably talk to each other through SOAP. As it stands, SOAP is not a complete RPC spec and cannot replace even many simple uses of CORBA or DCOM. If that's what you want, Sun XDR/RPC is probably a better choice for you: it's much better specified. Or, of course, we can try to track Microsoft's actual implementation (as opposed to their spec) as much as possible.
In general, I think you are right, though. Both KDE and Gnome follow Microsoft quite a bit. And while that may be useful for mass market appeal, overall, I think it's a shame. Linux's GUI could be so much more useful than merely doing well what Windows already does.
Actually, we already have this system. In fact, the personal vehicles are cheaper, healthier, and don't have any parking problems. You can see the personal vehicles here. And here is more information about one of the many US rail systems that are compatible with those personal vehicles.
I think it makes more economic sense to provide some decent car-by-rail service: you drive your (regular) car onto a train in NYC and arrive a few hours later in Boston, with your own car and no driving hassles. You save money on car rentals at your destination, you save gasoline, and you save wear-and-tear on your car; all of that offsets the price of the train ticket.
Just because Brown is currently one of the top-rated CS programs in the nation doesn't mean that its non-collaboration policy works. Many top-rated CS programs have an excellent reputation based on their theory, graphics, or AI groups. Whether the students that come out of such programs can afterwards succeed as programmers or independent researchers is an entirely separate question.
I find the thought of any academic department or software development program having a "strict anti-collaboration policy" distressing, and it's certainly no recommendation for a CS department in my book. Teach your students legal and ethical collaboration and attribution, don't turn them into loners and people who want to reinvent the wheel all the time.
What we really need is content-based matching. That's a bit harder, but there are a bunch of pretty obvious methods that should work reasonably well.
Of course, many of those methods, obvious or not, are probably being patented or have been patented by now because they are also very useful for detecting MP3 copyright infringement and for a variety of other commercial purposes.
Windows is getting more and more expensive, just as if Microsoft had a monopoly. Oh, wait, they do.