This is a reminder of why software needs to be free. BeOS, QNX, MacOS X; these are attractive systems, but when you invest your time in learning them you surrender control to a corporation. You head down a road which can be pinched off into a dead end at any moment. That's why I steer clear of this stuff, no matter how nice it looks.
I'd rather have freedom than a nice GUI. As long as you have freedom, you might make a nice GUI. But without freedom, you can't even hold on to your nice GUI.
I wish these developers the best of luck in creating free software to replace BeOS.
I run xscreensaver on my workstation and it has saved me from this mistake numerous times. IIRC it catches ctrl-alt-del, which is good because Windows users might try to log in with that combination.
Background: Good KVM's are expensive. Cheap KVM's are awful. Many monitors now have a built-in high quality A/B switch. Many KVM users spend 95% of time on a workstation, and occasionally have to flip to a "headless" box to make a BIOS change or something.
Why not buy a cheap KVM, attach a cheap keyboard to it, and plug it into input B on the monitor? Then most of the time you have high quality video from the workstation to input A. When using the KVM, you probably don't care about quality. Of course, there is the danger of typing on the wrong keyboard.
Personally, I just use the monitor A/B both at home and at work. The B cable goes on whatever box I'm fixing/setting up at the moment. Once the box has networking, there is no need for KVM.
A buffer overflow could only target one specific systems architecture -- a x86 buffer overflow wouldn't work on a Sparc.
In practice, such a virus would target x86. Do you really think the proportion of desktop Linux/Sparc is high enough to have a damping effect on the spread of such a virus? Even if 75% of Linux boxes were Sparc, the virus could still propogate by mailing 5 or more copies. But the percentage of Linux boxes which are Sparc-based must be tiny.
The point is, real virus security means that every program which reads untrusted data must be free of buffer overflows. Look how long it's taken to flush out most of the exploits in the suid root programs. You know that the "non-security-critical" programs like image viewers are just as likely to have buffer overflows. Of course I'm posting this too late for you to see it.
Anyhow, you're right that Outlook has horrible flaws, but it offers attractive low-hanging fruit so the virus writers haven't needed to learn about buffer overflows.
I think war is a reasonable metaphor. Victory for free software would mean that Microsoft's power is broken. They could still sell/rent software, but they would not be able to dictate standards. This is like the US goal in fighting Iraq - Saddam is still in power, but not in a position to invade neighbor countries. Victory for Microsoft would mean that free software development is essentially stopped. Their would still be maintenance of legacy code, and some free software in specialized areas like science, but free software would not be an active, challenging force exerting constant pressure on their profits and marketshare. Free software would become an irrelevant, technical/hobbyist area, with no connection to current hardware, protocols and consumer trends.
Each side could accomplish its goal by cutting off the other side's air supply. Microsoft would like to use their proprietary protocols and formats to blockade the communication between Microsoft OS's and others. In other words, a siege. When they succeed, as with the British government web program, they win a battle. No matter how detached you may be from the fight, the fight affects you when you can't use your government's web sites, doesn't it? Or if the time comes when you cannot buy a computer that will boot Linux, will you realize that there was a war?
I agree. The tech was an idiot. Changing someone's OS, even if the software is unsupported is amazingly stupid, and almost criminally inept. He deserves to be fired.
I see. You've convicted the tech of idiocy based on the testimony of two disgruntled ex-employees. Have you ever worked in tech support? Have you ever had to enforce an unpopular policy? If so, you should know that:
Anyone who enforces policy will be hated by some users.
Users do not generally hear the explanations given by tech support. They only hear that they will not get what they want. It's quite possible that this incident is part of a larger, companywide initiative, and that the user was quite clearly informed about what was going to happen to the notebook.
Users lie. That is the single most important fact about tech support. Anything a user says about his past interactions with computers or tech support is suspect. They lie to conceal actions they should not have taken. They lie to keep their story consistent. They lie to present themselves as innocent, aggrieved parties in a dispute. They lie even when it should be obvious that logs or email will contradict their story.
If you don't believe any of the above, please at least believe this: There are two sides to every beef.
But "web site" is a compound. Does this person expect a computer program to pass judgement on every possible combination of two words? Also, a brief search on the internet shows that there is no consensus on the correctness of "web site". The idea of a professional writer delegating such an issue to a computer program irritates me, especially when the program is written by Microsoft. What if she spell-checked "Linux" in MS word and it offered "Linsux"? Would she accept that as gospel? I am happy to see an individual like this separated from a Linux vendor. Let her spew her spellchecked, smartquoted pages elsewhere.
SDL + C lets you do graphical stuff. It's not as simple as you want, but after a few days of immersion it's straightforward.
Postscript (via ghostscript). Type 'gs' and a window will pop up. At the prompt, type:
1 0 0 setrgbcolor/Times-Roman findfont 30 scalefont setfont 100 100 moveto (Hello) show to put some text on the screen. Type 200 200 moveto 200 300 lineto 300 300 lineto 300 200 lineto 200 200 lineto stroke to draw a box. Adobe has a postscript tutorial on their site. If you stick your commands in a file, it's a postscript program. You can print it on a postscript printer, or run it through ghostscript to create an image, or distill it into a PDF. Or try this:/red 0 def/green 0 def/x 0 def 0 1 10 { x 400 moveto red green 0.5 setrgbcolor 0 100 rlineto stroke/x 15 x add def/red red 0.1 add def/green green 0.1 sub def } for for a set of colored stripes.
I think the poster was talking about the US effect on foreign countries, not internal policy. Internally the US is very free. But the US has installed and supported corrupt and dictatorial governments in many countries.
Also, another benefit of the US is if you don't like something about the government it can be changed.
If you live in Saudi Arabia, your corrupt government is upheld by US troops in the country. Saudis don't get to choose whether they want to be ruled by a corrupt "Royal Family". The US has chosen for them.
As for the US being the "most hideous" - I doubt it. But the accusation I will certainly make is: The US has not lived up to its ideals. For the amount of blood and money we have spent around the world, we could have created many strong, stable democracies. Instead we acted in the short-term interests of US corporations.
Those of us who understand why.doc is not an appropriate format for data interchange are in the distinct minority. If we demand that others burden themselves with extra steps in order to communicate with us, we will be perceived as handicapped and possibly excluded from some discussions. Like it or not,.doc is dominant in the business world. To succeed in that world, we have to deal gracefully with.doc.
I missed the part where anyone outside Lutris contributed to the code (after its acquisition). How could they contribue when the source was never released? Could you point me to this please?
You're assuming that the virus author would invent a new exploit. In practice, discovering an exploit and using it in a virus are two different activities, usually performed by different people. Lots of people already work on finding vulnerabilities in Linux and software that runs on Linux. They post their exploits on Bugtraq. I don't think anyone is holding back for fear of ruining Linux's reputation.
Secondly, kernel exploits are rare. A real virus would probably use an exploit in glibc or in an application.
MSSQL is derived from Sybase. The TSQL procedural language comes from Sybase. I don't know how much MS has changed it since forking the code. Sybase is probably your easiest migration path.
I think the best scheduling software is Steltor's CorporateTime. It's cross-platform, robust, scalable, and cheap. You can set up an eval server for free and start playing with it.
Check out Steltor who sell probably the best scheduling system there is. It has clients for Windows, Mac (including native Carbon) and Linux, web, WAP and imode interfaces, and even an Outlook Connector which makes it work with Outlook. The backend, CorporateTime Server, runs on a wide range of platforms, including Linux. It is cheaper than Exchange, more robust, more scalable (designed for multi-server, multi-site scalability from the beginning) and very easy to install.
I know you asked for Open Source solutions, but at least CorporateTime is sane, open and Unix-friendly.
So quit dreading and set up an evaluation server (for free) now. It is very hard to dislodge a working solution. Use that to your advantage.
On the other hand, when one lives in a place where adultery can be fatal, discretion might be advisable. However since the internet is banned in Afghanistan I'm not sure how PGP would help.
Every singel enclosure have a resonance frequency!
Most enclosures have more than one resonant frequency. A typical rectangular box will have three major resonances related to the dimensions. That's why speakers don't have dimensions that are integer multiples of each other. A spherical shape puts all the resonance eggs in one basket. An enclosure shaped like Linus Torvalds would not have a sharp resonant peak.
Unless you build it VERY big then the peak will be outside och the frequency range you can hear.
The speed of sound is roughly 1100 ft/sec. An enclosure with parallel walls one foot apart will resonate at 1100 hz, which is certainly audible. Could you possibly have been thinking of radio waves?
The audio world is crawling with hopeful inventors who don't understand much about sound and electro-accoustics. I've had the privilege of seeing many of these "inventions" first hand. The article failed to address the key issue behind "inflatable speakers": rigidity. In a vented box, which is the most common type of low-frequency and very-low-frequency system, the walls need to be pretty rigid to prevent distortion and energy loss. If these inventors have some way to make a balloon as rigid as 3/4" birch plywood with closely spaced transverse braces, the article doesn't mention it.
The only kinds of speaker enclosure that aren't concerned with rigidity are those that simply enclose rigid horns made of fibreglas, plastic or wood. In these situations, the enclosure merely protects the components from dust, water and damage and does not serve an accoustic funciton. JBL among others has realized this and is making a series of touring speakers which are simply frames of metal tubing with no side walls. Again, inflatable walls would add nothing to such a system.
As for the "beach ball" idea, this can be interpreted in two different ways, due to the lack of detail in the article. If you make a conventional (sealed or vented box) speaker system with spherical form, it will have a sharp resonant peak related to the diameter of the sphere. This peak can be reduced by increasing the absorbent material inside the enclosure, but still reflects a design mistake. A sphere is the worst possible shape for a conventional speaker enclosure. A second application of a sphere is to place it in front of a speaker (possibly a tweeter) creating in effect a radial horn. By careful positioning, two or even three transducers could share one sphere. An inflated beach ball could work for high and even mid frequencies. As the frequency gets lower, however, the need for rigidity of the sphere increases. In general, the sphere should be hard and rigid.
Such a system will never work as well as separate, properly designed horns for the separate transducers. Its only benefit is visual gimmickry and possible cost savings.
It sounds nice in theory. In practice, you would create a class of "vendors" whose sole purpose is to suck this unearned money from the government. They would spend 75% of it on lobbying to get the subsidy increased, and the rest on "golden parachutes" and other ways to funnel it into executive pockets.
You make good points, but I think the layering you describe is not what the OP wants. All these layers of crud supporting Java on Unix are just to give it the abilities of BASIC on a VIC20 - input, output, RAM access. We have a good degree of code reuse for GENERIC purposes, as you illustrate. But we are not yet good at reusing task-oriented code.
I'll try to explain. How do you find out the temperature in a city? To start with, we still don't have a standard way of coding cities. I encountered this when trying to (automatically) draw a world map showing the hosts in a certain network. The location information for each host was free form. It took a large amount of effort and special casing to get a program that could locate 90% of the hosts on the map.
On every project I've seen, we reinvent the wheel. Not the OS or GUI, a higher-level wheel. What kind of contact info do you ask from a user? How do you validate it? I think MS is aiming at that problem with Passport. And SOAP may be the first step towards getting computers to talk on a high level without the explicit intervention of programmers. In fact SOAP may be the real answer to the OP's request. The only place I've seen real reusability (in the high-level sense) is CPAN.
...the way ifconfig communicates with grep via pipes is much more limited and hackish than the way khtml communicates with konq via kparts.
Perhaps, but there's a reason why this "hackish" communication is popular and effective. Ifconfig's text output is its API (the output half, anyway). Since I already type ifconfig to learn about interfaces on the machine, I don't have to learn a new API to stick data into a shell pipeline. Khtml may have this wonderful relationship with konq, but I feel left out. I read and write ASCII, not binary. Suppose I want to try using khtml for something - can I invoke it with different arguments in a few seconds and see what it does? And if I invest enough time to understand and use the interface, how do I troubleshoot it when it breaks? If a complex shell pipeline starting with ifconfig is malfunctioning, I could start by trying a plain 'ifconfig'. How will I isolate some K-component from its friends and see what it's putting out?
I think a lot of the power of Unix is the overlap between the machine-readable and the human-readable. When you can read and write a language yourself, it's easier to write code that reads and writes that language. And it's easier to debug.
Forgive the past tense, but it really is an obsolescing technology.
Why do you think that pipes and scripts are obsolescing? And when you say scripts, do you mean all programs written in interpreted languages? It seems to me that scripting languages are gaining, not declining in importance. And I think there are more people using pipes and scripts than ever before. I use pipes and other unix features heavily at work. I'm able to solve arbitrary problems much faster than the Windows programmers I work with because I have a better toolbox. Their only tool for bashing data is writing a custom program in C++.
I agree with your idea about GUIs. I think that the GUI (X application) should be a generic program unto itself, like a web browser. The GUI application would make a socket connection to the GUI and send it XML commands like "Pop a dialog box asking $question". or "Create a scrolling buffer called EVENTS". Then the GUI could be anything - running on the same host or different, on X11 or Windows or curses, written in any language, customized by the user or the system vendor in any way. And all the apps run through that GUI would look visually consistent.
Well, that's certainly the conventional wisdom. However I expect some enterprising virus writer to prove it wrong. For example, mail a.jpeg that contains a buffer overflow exploit for a popular image-viewing program. The virus would, among other things, look in likely places for mail messages: ~/mail, ~/Mail,/var/spool/mail/$user, harvest some addresses and mail itself out.
The email could say, "Where I work, they just installed a 5000-node beowulf cluster. Check out this picture."
Slashdot Mirror
This is a reminder of why software needs to be free. BeOS, QNX, MacOS X; these are attractive systems, but when you invest your time in learning them you surrender control to a corporation. You head down a road which can be pinched off into a dead end at any moment. That's why I steer clear of this stuff, no matter how nice it looks.
I'd rather have freedom than a nice GUI. As long as you have freedom, you might make a nice GUI. But without freedom, you can't even hold on to your nice GUI.
I wish these developers the best of luck in creating free software to replace BeOS.
I think a lot of time is spent moving around, typically by searching. The efficiency of search and navigation commands is important.
I run xscreensaver on my workstation and it has saved me from this mistake numerous times. IIRC it catches ctrl-alt-del, which is good because Windows users might try to log in with that combination.
Background: Good KVM's are expensive. Cheap KVM's are awful. Many monitors now have a built-in high quality A/B switch. Many KVM users spend 95% of time on a workstation, and occasionally have to flip to a "headless" box to make a BIOS change or something.
Why not buy a cheap KVM, attach a cheap keyboard to it, and plug it into input B on the monitor? Then most of the time you have high quality video from the workstation to input A. When using the KVM, you probably don't care about quality. Of course, there is the danger of typing on the wrong keyboard.
Personally, I just use the monitor A/B both at home and at work. The B cable goes on whatever box I'm fixing/setting up at the moment. Once the box has networking, there is no need for KVM.
In practice, such a virus would target x86. Do you really think the proportion of desktop Linux/Sparc is high enough to have a damping effect on the spread of such a virus? Even if 75% of Linux boxes were Sparc, the virus could still propogate by mailing 5 or more copies. But the percentage of Linux boxes which are Sparc-based must be tiny.
The point is, real virus security means that every program which reads untrusted data must be free of buffer overflows. Look how long it's taken to flush out most of the exploits in the suid root programs. You know that the "non-security-critical" programs like image viewers are just as likely to have buffer overflows. Of course I'm posting this too late for you to see it.
Anyhow, you're right that Outlook has horrible flaws, but it offers attractive low-hanging fruit so the virus writers haven't needed to learn about buffer overflows.
I think war is a reasonable metaphor. Victory for free software would mean that Microsoft's power is broken. They could still sell/rent software, but they would not be able to dictate standards. This is like the US goal in fighting Iraq - Saddam is still in power, but not in a position to invade neighbor countries. Victory for Microsoft would mean that free software development is essentially stopped. Their would still be maintenance of legacy code, and some free software in specialized areas like science, but free software would not be an active, challenging force exerting constant pressure on their profits and marketshare. Free software would become an irrelevant, technical/hobbyist area, with no connection to current hardware, protocols and consumer trends.
Each side could accomplish its goal by cutting off the other side's air supply. Microsoft would like to use their proprietary protocols and formats to blockade the communication between Microsoft OS's and others. In other words, a siege. When they succeed, as with the British government web program, they win a battle. No matter how detached you may be from the fight, the fight affects you when you can't use your government's web sites, doesn't it? Or if the time comes when you cannot buy a computer that will boot Linux, will you realize that there was a war?
I see. You've convicted the tech of idiocy based on the testimony of two disgruntled ex-employees. Have you ever worked in tech support? Have you ever had to enforce an unpopular policy? If so, you should know that:
- Anyone who enforces policy will be hated by some users.
- Users do not generally hear the explanations given by tech support. They only hear that they will not get what they want. It's quite possible that this incident is part of a larger, companywide initiative, and that the user was quite clearly informed about what was going to happen to the notebook.
- Users lie. That is the single most important fact about tech support. Anything a user says about his past interactions with computers or tech support is suspect. They lie to conceal actions they should not have taken. They lie to keep their story consistent. They lie to present themselves as innocent, aggrieved parties in a dispute. They lie even when it should be obvious that logs or email will contradict their story.
If you don't believe any of the above, please at least believe this: There are two sides to every beef.But "web site" is a compound. Does this person expect a computer program to pass judgement on every possible combination of two words? Also, a brief search on the internet shows that there is no consensus on the correctness of "web site". The idea of a professional writer delegating such an issue to a computer program irritates me, especially when the program is written by Microsoft. What if she spell-checked "Linux" in MS word and it offered "Linsux"? Would she accept that as gospel?
I am happy to see an individual like this separated from a Linux vendor. Let her spew her spellchecked, smartquoted pages elsewhere.
1 0 0 setrgbcolor
Or try this:/red 0 def
If you live in Saudi Arabia, your corrupt government is upheld by US troops in the country. Saudis don't get to choose whether they want to be ruled by a corrupt "Royal Family". The US has chosen for them.
As for the US being the "most hideous" - I doubt it. But the accusation I will certainly make is: The US has not lived up to its ideals. For the amount of blood and money we have spent around the world, we could have created many strong, stable democracies. Instead we acted in the short-term interests of US corporations.
Those of us who understand why .doc is not an appropriate format for data interchange are in the distinct minority. If we demand that others burden themselves with extra steps in order to communicate with us, we will be perceived as handicapped and possibly excluded from some discussions. Like it or not, .doc is dominant in the business world. To succeed in that world, we have to deal gracefully with .doc.
I didn't see any mention of such code contributions in the article. My understanding from reading the article is:
I agree with you about the problem of pseudo-free licenses, but that does not seem to be what is happening here.
I missed the part where anyone outside Lutris contributed to the code (after its acquisition). How could they contribue when the source was never released? Could you point me to this please?
You're assuming that the virus author would invent a new exploit. In practice, discovering an exploit and using it in a virus are two different activities, usually performed by different people. Lots of people already work on finding vulnerabilities in Linux and software that runs on Linux. They post their exploits on Bugtraq. I don't think anyone is holding back for fear of ruining Linux's reputation.
Secondly, kernel exploits are rare. A real virus would probably use an exploit in glibc or in an application.
MSSQL is derived from Sybase. The TSQL procedural language comes from Sybase. I don't know how much MS has changed it since forking the code. Sybase is probably your easiest migration path.
I think the best scheduling software is Steltor's CorporateTime. It's cross-platform, robust, scalable, and cheap. You can set up an eval server for free and start playing with it.
Check out Steltor who sell probably the best scheduling system there is. It has clients for Windows, Mac (including native Carbon) and Linux, web, WAP and imode interfaces, and even an Outlook Connector which makes it work with Outlook. The backend, CorporateTime Server, runs on a wide range of platforms, including Linux. It is cheaper than Exchange, more robust, more scalable (designed for multi-server, multi-site scalability from the beginning) and very easy to install.
I know you asked for Open Source solutions, but at least CorporateTime is sane, open and Unix-friendly.
So quit dreading and set up an evaluation server (for free) now. It is very hard to dislodge a working solution. Use that to your advantage.
On the other hand, when one lives in a place where adultery can be fatal, discretion might be advisable. However since the internet is banned in Afghanistan I'm not sure how PGP would help.
Most enclosures have more than one resonant frequency. A typical rectangular box will have three major resonances related to the dimensions. That's why speakers don't have dimensions that are integer multiples of each other. A spherical shape puts all the resonance eggs in one basket. An enclosure shaped like Linus Torvalds would not have a sharp resonant peak.
The speed of sound is roughly 1100 ft/sec. An enclosure with parallel walls one foot apart will resonate at 1100 hz, which is certainly audible. Could you possibly have been thinking of radio waves?
The audio world is crawling with hopeful inventors who don't understand much about sound and electro-accoustics. I've had the privilege of seeing many of these "inventions" first hand. The article failed to address the key issue behind "inflatable speakers": rigidity. In a vented box, which is the most common type of low-frequency and very-low-frequency system, the walls need to be pretty rigid to prevent distortion and energy loss. If these inventors have some way to make a balloon as rigid as 3/4" birch plywood with closely spaced transverse braces, the article doesn't mention it.
The only kinds of speaker enclosure that aren't concerned with rigidity are those that simply enclose rigid horns made of fibreglas, plastic or wood. In these situations, the enclosure merely protects the components from dust, water and damage and does not serve an accoustic funciton. JBL among others has realized this and is making a series of touring speakers which are simply frames of metal tubing with no side walls. Again, inflatable walls would add nothing to such a system.
As for the "beach ball" idea, this can be interpreted in two different ways, due to the lack of detail in the article. If you make a conventional (sealed or vented box) speaker system with spherical form, it will have a sharp resonant peak related to the diameter of the sphere. This peak can be reduced by increasing the absorbent material inside the enclosure, but still reflects a design mistake. A sphere is the worst possible shape for a conventional speaker enclosure. A second application of a sphere is to place it in front of a speaker (possibly a tweeter) creating in effect a radial horn. By careful positioning, two or even three transducers could share one sphere. An inflated beach ball could work for high and even mid frequencies. As the frequency gets lower, however, the need for rigidity of the sphere increases. In general, the sphere should be hard and rigid.
Such a system will never work as well as separate, properly designed horns for the separate transducers. Its only benefit is visual gimmickry and possible cost savings.
It sounds nice in theory. In practice, you would create a class of "vendors" whose sole purpose is to suck this unearned money from the government. They would spend 75% of it on lobbying to get the subsidy increased, and the rest on "golden parachutes" and other ways to funnel it into executive pockets.
You make good points, but I think the layering you describe is not what the OP wants. All these layers of crud supporting Java on Unix are just to give it the abilities of BASIC on a VIC20 - input, output, RAM access. We have a good degree of code reuse for GENERIC purposes, as you illustrate. But we are not yet good at reusing task-oriented code.
I'll try to explain. How do you find out the temperature in a city? To start with, we still don't have a standard way of coding cities. I encountered this when trying to (automatically) draw a world map showing the hosts in a certain network. The location information for each host was free form. It took a large amount of effort and special casing to get a program that could locate 90% of the hosts on the map.
On every project I've seen, we reinvent the wheel. Not the OS or GUI, a higher-level wheel. What kind of contact info do you ask from a user? How do you validate it? I think MS is aiming at that problem with Passport. And SOAP may be the first step towards getting computers to talk on a high level without the explicit intervention of programmers. In fact SOAP may be the real answer to the OP's request. The only place I've seen real reusability (in the high-level sense) is CPAN.
Perhaps, but there's a reason why this "hackish" communication is popular and effective. Ifconfig's text output is its API (the output half, anyway). Since I already type ifconfig to learn about interfaces on the machine, I don't have to learn a new API to stick data into a shell pipeline. Khtml may have this wonderful relationship with konq, but I feel left out. I read and write ASCII, not binary. Suppose I want to try using khtml for something - can I invoke it with different arguments in a few seconds and see what it does? And if I invest enough time to understand and use the interface, how do I troubleshoot it when it breaks? If a complex shell pipeline starting with ifconfig is malfunctioning, I could start by trying a plain 'ifconfig'. How will I isolate some K-component from its friends and see what it's putting out?
I think a lot of the power of Unix is the overlap between the machine-readable and the human-readable. When you can read and write a language yourself, it's easier to write code that reads and writes that language. And it's easier to debug.
Why do you think that pipes and scripts are obsolescing? And when you say scripts, do you mean all programs written in interpreted languages? It seems to me that scripting languages are gaining, not declining in importance. And I think there are more people using pipes and scripts than ever before. I use pipes and other unix features heavily at work. I'm able to solve arbitrary problems much faster than the Windows programmers I work with because I have a better toolbox. Their only tool for bashing data is writing a custom program in C++.
I agree with your idea about GUIs. I think that the GUI (X application) should be a generic program unto itself, like a web browser. The GUI application would make a socket connection to the GUI and send it XML commands like "Pop a dialog box asking $question". or "Create a scrolling buffer called EVENTS". Then the GUI could be anything - running on the same host or different, on X11 or Windows or curses, written in any language, customized by the user or the system vendor in any way. And all the apps run through that GUI would look visually consistent.
Well, that's certainly the conventional wisdom. However I expect some enterprising virus writer to prove it wrong. For example, mail a .jpeg that contains a buffer overflow exploit for a popular image-viewing program. The virus would, among other things, look in likely places for mail messages: ~/mail, ~/Mail, /var/spool/mail/$user, harvest some addresses and mail itself out.
The email could say, "Where I work, they just installed a 5000-node beowulf cluster. Check out this picture."