I mean seriously - I'm glad my mail client has the option to supress the loading of remote images. I've had spam that makes my eyes burn:-(
Click... Click... Click... *ARRGGHH!* *thump*
I'm learning to love MimeDefang, as I no longer have to field complaints from embarrassed and irritated staff asking how the hell they make this stuff _go_ _away_.
Actually, you need about as much of an OS for ssh with X forwarding as for XDMCP-based remote X. Both need to boot up a local kernel and minimal userspace, the only difference is that one uses 'X -query' to do an XDMCP request, where the other SSH-es to a server and runs the desktop start script. Before starting X, the needs are the same, and the only extra thing the SSH -based one needs is the ssh program and a small shell script.
Thin clients are available that support getting a remote display over SSH with private key authetication, as an alternative to XDMCP. AFAIK LTSP also supports this.
Acrobat Reader, for example, does this with some success (it's statically linked to Motif, at least). I don't know how well it'll work when you want to properly interact with the desktop (have the same file chooser etc as other apps), though.
It's not an issue for me directly, as all my development work is in-house, but I still find it concerning in general.
It definitely sounds interesting, though I'm not enthused about breaking compatibility with the current *NIX "standard" X11 GUI, which I presume would be required.
I'm watching developments like Cairo, DPS, and such with interest, as they allow incremental moves and improvements. None the less, I'd be game to try something entirely different if it provided a mechanism to 'wrap' X apps (for example, an OSX-style rootless and well-integrated X server).
I suspect things are going in the direction of incrementally improving X at present, though. There's still plenty of headroom left in X by the looks of things;-) and the toolkit people are already working wonders. Compare qt3.0 with qt3.2.x over remote X - the improvement is astonishing.
That said, it would be really nice to introduce a way of doing higher-level widgets server-side, without locking apps into using a predefined set of widgets on the server (lest we find ourselves with another Motif situation down the track). It'd probably need to happen at the toolkit level, because apps wouldn't want to have to be aware of the fallback to client-side widgets if server support was missing.
I'll definitely keep my eye out for NEWS news, though - it sounds quite interesting.
XDMCP is just a protocol to request displays, set up authentication, and manage the display. All the actual X session traffic happens as normal - straight between the clients and servers using the normal X network protocol.
So no, XDMCP does not use compression, and I doubt there'd be much point compressing the occasional UDP messages it sends.
SSH encryption and compression would be quite a performance hit if we used it, but we don't, we use raw X sessions negotiated using XDMCP. Insecure: yes; fast: yes. The security issues are mitigated by the fairly secure network segment the terminal users are on.
Unfortunately, this makes application packaging a nightmare, and support even worse. You either need to build packages of all the various dependencies for all platforms you want to support, or hope that the user does it right.
Additionally, it sucks from a package management point of view.
It'd be good if it was easier to have multiple versions of libs installed in parallel. It's not too bad right now, but some improvement would still be useful - in particular tweaking package management to make it easier to manage mulitple parallel versions.
Remote desktop performance tends to be bound by network latency and local video hardware performance more than processor performance in my experience. I have P133s with 32MB of RAM that happily run KDE3.2 remotely in 1280x960 - they have GeForce4 MX/PCI video cards, and a lightly loaded switched 100baseTX link to a server on a gigabit uplink.
If they can improve X's issues with round-trips and latency, then I'll be all ears.
(a) Businesses don't want more source code. Well, to be strictly accurate they don't want to have to manage, worry about, maintain, etc more source code than they have to. I think that given the choice, most intelligent CIOs would definitely say "sure, we'd love the source and rights to use it" - but would probably prefer not to have to actually do much with it, and face the burden of maintaining changes etc.
OSS alleviates this to some extent by permitting changes to be submitted back upstream, but this only works if you have the resources to engineer you changes "properly" and not break anything else (even stuff you don't use or care about).
(b) If you write for RH9 or RHEL3, your app will not run on a stable release of Debian. Not if it's a GUI app that uses any GNOME/KDE libs, needs a recent QT, etc. It can be made to run by either packaging it with a lot of extra libs (see Ximian's RH8 builds of Evolution for an example of this approach), spending a lot more time to make it handle varying versions of libraries, or forcing the user to update their distro or libraries themselves. None of these are attractive.
I see this as a real issue, but not a distro one. It's actually more about _versions_ - the rapid change of OSS, including APIs etc for major libraries and toolkits, is the root of the issue. OTOH, the same thing keeps "ugly" decisions from hanging around, and permits much more rapid advancement.
I'd like to see a cleaner way of running multiple versions of things in parallel (within the package management systems), as a work-around for this issue.
(c) Also quite correct. Many open source apps do not follow established standards, and often the file formats, protocols, etc are defined largely or entirely by the source code of the app. While these protocols/formats are definitely open, they're not open standards and there's usually not much chance that other apps will work with them.
It's true that you do have more chance of enchancing other apps to work with the formats/protocols, time and money permitting, or enhancing the OSS apps to work with the protocls/formats of your choice. It's also true to say that many apps don't support standard protocols or formats because there is no standard in that application domain, or it's crap. These things do not change the truth of his statement.
Sadly, I must disagree. Modern apps - especially GUI apps - often depend heavily on services and libraries from the major toolkits and desktop environments, and this makes them less source-portable.
It is hard to write an app that'll run on even 2-year-old versions of the same distro it was written on.
OTOH, this is not due to forking at all, but rather the lack of care about stable APIs, combined with rapid release cycles, in a lot of open source software. This has it's advantages - ugly decisions don't lurk forever (witness Windows' APIs by comparison), and things can evolve quickly.
I'd call "forking" a secondary issue for app developers, over trying to support distros over more than about 2 releases.
As for ABIs... well, that's another story and one that's much more of a problem in the distro forking area.
This is far from the first time legal means have been used to stop a free software project. The most obvious one that comes to mind is BnetD, a Diablo II Battle.Net server, but I'm sure there are more. DeCSS, in fact, would probably qualify nicely.
I was referring, specifically, to a header I see on a lot of embedded boards that's referred to as an LVDS header or port. I don't have any cases open right now, but here's an example I found quickly:
http://www.2advancedcomputers.com/products/singl e board computers/via/PEAK603VL.htm
Extensive LCD Support: 36-bit DSTN/TFT flat panel interface with 256 gray shade support
Integrated 110 MHz LVDS interface
Support for all resolutions up to 1600x1200
So... ideas about what that would mean in this context? Might it be possible to "borrow" an LCD from an older laptop (PII-300 laptop, 12" 1024x768 display in this case) for use with an SBC like this?
One issue with your suggestion comes to mind immediately, and that's mailing lists. Are mailing lists not, in fact, reflectors designed to send email by proxy from another location?
I've been blacklisted
on
Paid To Spam
·
· Score: 2, Interesting
I've had my mailserver blacklisted, and I tell you - $1000 an hour couldn't possibly be enough to blacklist-bait yourself like that. You never realise just how totally your business relies on email until suddenly it mostly stops working.
Of course, then there's the fact that this proposal is offensive, anti-social, and just plain retarded.
How were we blacklisted, you ask? We use an exim server as the gateway, with sendmail internally. The gateway server was marked as a trusted host for relaying on the internal server (indirectly; it was part of a subnet of hosts that needed to be able to relay). Normally that's not an issue, because the exim gateway would refuse to accept messages asking for relaying anyway.
Unfortunately, the exim gateway permitted percent-hack messages to pass, permitting an attacker to bypass the gateway server's checks, and deliver a message for relaying to the sendmail server. Which promptly relayed it, because the gateway was a trusted host.
Fix: disable percent hack (Why TF is it even supported anymore anyway?) and set the gateway to be able to deliver, but not relay.
I tend to agree with the guy, personally. Blue LEDs, because they're usually stupidly bright, get really irritating, really fast.
There are great uses for them - for example, my new keyring light is one, and I can not only see to open doors etc but could probably blind a mugger permanantly as well;-)
I think the use of super-bright blue LEDs for indicator lights is rather silly, though. I've replaced a couple in hardware I own, and put electrical tape over a couple of others I can't easily replace, because they were really god dammn annoying.
My PC sits in the living room (connected to the TV), and I used to have to put something in front of it if we were going to watch a film to avoid blinding anyone on the opposite side of the room. The power LED produces almost as much light as my 19" monitor. This is stupid.
As for posters who say "don't buy things with blue LEDs then" - (a) often you don't know until you've installed it, and (b) it's downright stupid to have to select devices based on whether or not the power light will drill a hole through your skull, instead of minor things like reliability or required features.
Personally, I'm still astonished that nobody has mentioned
10 Giabit Ethernet, and said something like "Pfft! Who needs that pokey gigabit stuff anyway?"
Slashdot and people saying "you don't need something that fast" is strange and frightening. I can at least understand people pointing out that you are unlikely to get full gigabit speeds, but then those people go on to say "so you don't need gigabit" - completely missing the point.
PCI-X is "here" and has been for ages. It's just only found in server and high-end workstation boards. PCI-X is essentially 133MHz 64bit PCI, and while fast is otherwise uninteresting. You can get it now if you buy a high end Xeon, Athlon MP, or Opteron board. It's also available in many non-x86 systems, such as the Apple G5.
I suspect you mean PCI-Express, otherwise known as PCIe or PCI-E, which is the emerging replacement to the PCI standard.
Close. On re-reading, I note he was talking about the NICs, though he notes that the switches also get rather toasty.
The point is valid, though - my Intel Pro/1000 (PCI-X) gets rather hot when the server case is open, even with a large heat sink on it. With decent airflow through the case, I find this to be much less of an issue.
My LAN at work works wonderfully in a mixed 1000baseTX/100baseTX environment. The core switch has two gigabit uplinks (to the core servers), and all other clients are on 100baseTX ports.
I haven't observed any performance degradation for the 100Mb/s clients, and when communicating with the servers over gigabit things work extremely smoothly, with six clients often getting full speed transfers at once (not just file access; we use remote X and a lot of other things on our servers).
Fragmentation can be a reason for poor performance, but it depends on what you're doing, and what filesystem you're using. If you use FAT32 or HFS, then of course framentation will be a major problem, as the FS makes no effort whatsoever to reduce it.
If, on the other hand, you use NTFS, ext2, ext3, reiserfs, UFS, or any other modern filesystem, you will probably find framentation to be much less significiant.
Random-file I/O will always be much slower than sequential transfers of large files, of course - hence the issue of different workloads.
If your disks are getting that hot, too, you NEED TO COOL THEM BETTER OR THEY WILL FAIL. Set up at least dedicated fan cooling for the disks. My case has a cage for the disks in the lower front, with two large fans blowing over them - my disks only get a little hot when under very heavy loads.
Before messing with jumbo frames, make sure your TCP window sizes are sensible. Many OSes set them up stupidly, and an appropriate window size can make a massive amount of difference to throughput.
Slashdot Mirror
I mean seriously - I'm glad my mail client has the option to supress the loading of remote images. I've had spam that makes my eyes burn :-(
Click... Click... Click... *ARRGGHH!* *thump*
I'm learning to love MimeDefang, as I no longer have to field complaints from embarrassed and irritated staff asking how the hell they make this stuff _go_ _away_.
The way the US seems to be these days, he's really lucky they knocked instead of broke down the door with an armed squad.
;-)
I guess it's because he's not a script kiddie^W^W"Hacker"
Actually, you need about as much of an OS for ssh with X forwarding as for XDMCP-based remote X. Both need to boot up a local kernel and minimal userspace, the only difference is that one uses 'X -query' to do an XDMCP request, where the other SSH-es to a server and runs the desktop start script. Before starting X, the needs are the same, and the only extra thing the SSH -based one needs is the ssh program and a small shell script.
Thin clients are available that support getting a remote display over SSH with private key authetication, as an alternative to XDMCP. AFAIK LTSP also supports this.
Craig Ringer
Good point.
Acrobat Reader, for example, does this with some success (it's statically linked to Motif, at least). I don't know how well it'll work when you want to properly interact with the desktop (have the same file chooser etc as other apps), though.
It's not an issue for me directly, as all my development work is in-house, but I still find it concerning in general.
It definitely sounds interesting, though I'm not enthused about breaking compatibility with the current *NIX "standard" X11 GUI, which I presume would be required.
;-) and the toolkit people are already working wonders. Compare qt3.0 with qt3.2.x over remote X - the improvement is astonishing.
I'm watching developments like Cairo, DPS, and such with interest, as they allow incremental moves and improvements. None the less, I'd be game to try something entirely different if it provided a mechanism to 'wrap' X apps (for example, an OSX-style rootless and well-integrated X server).
I suspect things are going in the direction of incrementally improving X at present, though. There's still plenty of headroom left in X by the looks of things
That said, it would be really nice to introduce a way of doing higher-level widgets server-side, without locking apps into using a predefined set of widgets on the server (lest we find ourselves with another Motif situation down the track). It'd probably need to happen at the toolkit level, because apps wouldn't want to have to be aware of the fallback to client-side widgets if server support was missing.
I'll definitely keep my eye out for NEWS news, though - it sounds quite interesting.
XDMCP is just a protocol to request displays, set up authentication, and manage the display. All the actual X session traffic happens as normal - straight between the clients and servers using the normal X network protocol.
So no, XDMCP does not use compression, and I doubt there'd be much point compressing the occasional UDP messages it sends.
SSH encryption and compression would be quite a performance hit if we used it, but we don't, we use raw X sessions negotiated using XDMCP. Insecure: yes; fast: yes. The security issues are mitigated by the fairly secure network segment the terminal users are on.
Unfortunately, this makes application packaging a nightmare, and support even worse. You either need to build packages of all the various dependencies for all platforms you want to support, or hope that the user does it right.
Additionally, it sucks from a package management point of view.
It'd be good if it was easier to have multiple versions of libs installed in parallel. It's not too bad right now, but some improvement would still be useful - in particular tweaking package management to make it easier to manage mulitple parallel versions.
Remote desktop performance tends to be bound by network latency and local video hardware performance more than processor performance in my experience. I have P133s with 32MB of RAM that happily run KDE3.2 remotely in 1280x960 - they have GeForce4 MX/PCI video cards, and a lightly loaded switched 100baseTX link to a server on a gigabit uplink.
If they can improve X's issues with round-trips and latency, then I'll be all ears.
He's quite right there, though.
(a) Businesses don't want more source code. Well, to be strictly accurate they don't want to have to manage, worry about, maintain, etc more source code than they have to. I think that given the choice, most intelligent CIOs would definitely say "sure, we'd love the source and rights to use it" - but would probably prefer not to have to actually do much with it, and face the burden of maintaining changes etc.
OSS alleviates this to some extent by permitting changes to be submitted back upstream, but this only works if you have the resources to engineer you changes "properly" and not break anything else (even stuff you don't use or care about).
(b) If you write for RH9 or RHEL3, your app will not run on a stable release of Debian. Not if it's a GUI app that uses any GNOME/KDE libs, needs a recent QT, etc. It can be made to run by either packaging it with a lot of extra libs (see Ximian's RH8 builds of Evolution for an example of this approach), spending a lot more time to make it handle varying versions of libraries, or forcing the user to update their distro or libraries themselves. None of these are attractive.
I see this as a real issue, but not a distro one. It's actually more about _versions_ - the rapid change of OSS, including APIs etc for major libraries and toolkits, is the root of the issue. OTOH, the same thing keeps "ugly" decisions from hanging around, and permits much more rapid advancement.
I'd like to see a cleaner way of running multiple versions of things in parallel (within the package management systems), as a work-around for this issue.
(c) Also quite correct. Many open source apps do not follow established standards, and often the file formats, protocols, etc are defined largely or entirely by the source code of the app. While these protocols/formats are definitely open, they're not open standards and there's usually not much chance that other apps will work with them.
It's true that you do have more chance of enchancing other apps to work with the formats/protocols, time and money permitting, or enhancing the OSS apps to work with the protocls/formats of your choice. It's also true to say that many apps don't support standard protocols or formats because there is no standard in that application domain, or it's crap. These things do not change the truth of his statement.
Sadly, I must disagree. Modern apps - especially GUI apps - often depend heavily on services and libraries from the major toolkits and desktop environments, and this makes them less source-portable.
... well, that's another story and one that's much more of a problem in the distro forking area.
It is hard to write an app that'll run on even 2-year-old versions of the same distro it was written on.
OTOH, this is not due to forking at all, but rather the lack of care about stable APIs, combined with rapid release cycles, in a lot of open source software. This has it's advantages - ugly decisions don't lurk forever (witness Windows' APIs by comparison), and things can evolve quickly.
I'd call "forking" a secondary issue for app developers, over trying to support distros over more than about 2 releases.
As for ABIs
http://wwws.sun.com/software/solaris/binaries/get. html
It's pretty fussy about hardware etc, though, and very obviously not the equal of Solaris/Sparc.
Whoops. Sorry all - reading too late at night.
To quote a friend of mine: "Poppycock".
This is far from the first time legal means have been used to stop a free software project. The most obvious one that comes to mind is BnetD, a Diablo II Battle.Net server, but I'm sure there are more. DeCSS, in fact, would probably qualify nicely.
That's really useful info ; thanks.
l e board computers/via/PEAK603VL.htm
... ideas about what that would mean in this context? Might it be possible to "borrow" an LCD from an older laptop (PII-300 laptop, 12" 1024x768 display in this case) for use with an SBC like this?
I was referring, specifically, to a header I see on a lot of embedded boards that's referred to as an LVDS header or port. I don't have any cases open right now, but here's an example I found quickly:
http://www.2advancedcomputers.com/products/sing
Extensive LCD Support:
36-bit DSTN/TFT flat panel interface with 256 gray shade support
Integrated 110 MHz LVDS interface
Support for all resolutions up to 1600x1200
So
I've used a number of boards with LVDS connectors, which I understand are for LCD displays. I presume it's a different type of display or something?
One issue with your suggestion comes to mind immediately, and that's mailing lists. Are mailing lists not, in fact, reflectors designed to send email by proxy from another location?
I've had my mailserver blacklisted, and I tell you - $1000 an hour couldn't possibly be enough to blacklist-bait yourself like that. You never realise just how totally your business relies on email until suddenly it mostly stops working.
Of course, then there's the fact that this proposal is offensive, anti-social, and just plain retarded.
How were we blacklisted, you ask? We use an exim server as the gateway, with sendmail internally. The gateway server was marked as a trusted host for relaying on the internal server (indirectly; it was part of a subnet of hosts that needed to be able to relay). Normally that's not an issue, because the exim gateway would refuse to accept messages asking for relaying anyway.
Unfortunately, the exim gateway permitted percent-hack messages to pass, permitting an attacker to bypass the gateway server's checks, and deliver a message for relaying to the sendmail server. Which promptly relayed it, because the gateway was a trusted host.
Fix: disable percent hack (Why TF is it even supported anymore anyway?) and set the gateway to be able to deliver, but not relay.
I tend to agree with the guy, personally. Blue LEDs, because they're usually stupidly bright, get really irritating, really fast.
;-)
There are great uses for them - for example, my new keyring light is one, and I can not only see to open doors etc but could probably blind a mugger permanantly as well
I think the use of super-bright blue LEDs for indicator lights is rather silly, though. I've replaced a couple in hardware I own, and put electrical tape over a couple of others I can't easily replace, because they were really god dammn annoying.
My PC sits in the living room (connected to the TV), and I used to have to put something in front of it if we were going to watch a film to avoid blinding anyone on the opposite side of the room. The power LED produces almost as much light as my 19" monitor. This is stupid.
As for posters who say "don't buy things with blue LEDs then" - (a) often you don't know until you've installed it, and (b) it's downright stupid to have to select devices based on whether or not the power light will drill a hole through your skull, instead of minor things like reliability or required features.
I, of course, read the summary as:
A number of seniors will explode in the next two decades
Personally, I'm still astonished that nobody has mentioned 10 Giabit Ethernet, and said something like "Pfft! Who needs that pokey gigabit stuff anyway?"
Slashdot and people saying "you don't need something that fast" is strange and frightening. I can at least understand people pointing out that you are unlikely to get full gigabit speeds, but then those people go on to say "so you don't need gigabit" - completely missing the point.
PCI-X is "here" and has been for ages. It's just only found in server and high-end workstation boards. PCI-X is essentially 133MHz 64bit PCI, and while fast is otherwise uninteresting. You can get it now if you buy a high end Xeon, Athlon MP, or Opteron board. It's also available in many non-x86 systems, such as the Apple G5.
I suspect you mean PCI-Express, otherwise known as PCIe or PCI-E, which is the emerging replacement to the PCI standard.
Craig Ringer
The latest NForce3 has gigabit built in to the chipset - so it's not /all/ Intel.
Close. On re-reading, I note he was talking about the NICs, though he notes that the switches also get rather toasty.
The point is valid, though - my Intel Pro/1000 (PCI-X) gets rather hot when the server case is open, even with a large heat sink on it. With decent airflow through the case, I find this to be much less of an issue.
My LAN at work works wonderfully in a mixed 1000baseTX/100baseTX environment. The core switch has two gigabit uplinks (to the core servers), and all other clients are on 100baseTX ports.
I haven't observed any performance degradation for the 100Mb/s clients, and when communicating with the servers over gigabit things work extremely smoothly, with six clients often getting full speed transfers at once (not just file access; we use remote X and a lot of other things on our servers).
Fragmentation can be a reason for poor performance, but it depends on what you're doing, and what filesystem you're using. If you use FAT32 or HFS, then of course framentation will be a major problem, as the FS makes no effort whatsoever to reduce it.
If, on the other hand, you use NTFS, ext2, ext3, reiserfs, UFS, or any other modern filesystem, you will probably find framentation to be much less significiant.
Random-file I/O will always be much slower than sequential transfers of large files, of course - hence the issue of different workloads.
If your disks are getting that hot, too, you NEED TO COOL THEM BETTER OR THEY WILL FAIL. Set up at least dedicated fan cooling for the disks. My case has a cage for the disks in the lower front, with two large fans blowing over them - my disks only get a little hot when under very heavy loads.
Before messing with jumbo frames, make sure your TCP window sizes are sensible. Many OSes set them up stupidly, and an appropriate window size can make a massive amount of difference to throughput.