Well, OpenWindows was basically a port of the old SunView system, which was the original windowing system, to X11R3. SunView was rather revolutionary at the time and, I think, predates X by a number of years. Hence, it doesn't "follow industry standards" because it pre-dates them.
The Openwindows (or OpenLook) libraries are pretty well call for call compatible with the SunView library calls and look nothing like the normal X library stuff.. and are arguably easier to use, hence they were used quite widely in scientific applications.
For those who are used to the interface, moving to the other windowing systems and desktop environments can be quite a culture shock.
On our systems we have Openwindows, CDE, KDE 1, KDE 2.2 and GNOME 1.4. There are a number of people who I can't get to move from Openwindows, others who PREFER CDE, a lot who prefer KDE 1 to KDE 2 etc.
Each to their own, I say.
Re:Changes between 2.2 and 2.2.1
on
KDE 2.2.1 Up
·
· Score: 1
The main problem I have with the KDE development structure is that they stop fixing bugs, even pretty major ones, on the stable release just to concentrate on the new whizz-bang version coming up.
If they continued supplying bug fixes for the old stable release for a significant period of time after the initial realease and even overlapped these fixes with the full release of the next version (so that those people who need time to plan for upgrading the system on a large, multi-machine, multi-user system such as the one I run have a chance to keep bug-free) I would feel a whole lot happier.
PS. Oh, and if only kmail had the ability of having mailing list aliases it would also help. At the moment I'm having to kludge things for our users by using nmh's 'post' program as a mail posting agent so that aliases can be used properly. (Kaddressbook/Kab etc. don't have any such facility and there are a number of "Wish-list" bugs postingss for this which haven't even been replied to.)
The problem here is that you're looking at things from a purely Linux-centric viewpoint.
The other week I had a go at building and installing GNOME under Solaris so as to get a certain piece of scientific software running on our Sun Solaris systems (which range from versions 2.6 to 8).
I first went to the GNOME site and downloaded the libraries the web pages told me I needed.. plus everything else fromt he stable directory. I thought that as I'd read the instructions and downloaded all of the stable source I would be home and dry, it'd just need a lot of configure, build and install cycles.
Little did I know that most of the libraries in the "stable" branch required a multitude of libraries fromt eh unstable one, many of which didn't play well in the configure scripts (they assumed that/bin/sh == bash and a few other Linux-centric assumptions).
Basically, after a week of trying to build things, finding I needed yet another library or utility from an unstable branch or from an obscure web site somewhere I managed to build enough of the core libraries to build the application.
And before anyone says "Why didn't you download a binary version?" I did look into this but the version on SunFreeware was disgned as a single machine installation, not a network wide one. The recently released Sun beta release version of GNOME 1.4 is only for Soalris 8 AND half the libraries needed by the scientific application were newer than in the GNOME 1.4 "release."
If the library API's aren't standardised soon and kept stable then people will shun such things as GNOME. For someone tinkering on their own system it may be fine to play for weeks getting things working, but in the "real world" this is just untenable.
Given that risc instruction sets are supposed to be simpler than cisc ones, what makes you think that they would be harder to optimize for?
</pre>
RISC processors rely far more on the compilers optimising the instruction scheduling to get the best out of the processor. ie. by the compiler doing most of the instruction ording etc. the RISC core can be far simpler. It's just a trade-off.
The RISC processors also have more to worry about for the coder, such as register window size, register windows etc. This means that a poorly optimised RISC program will run many orders of magnitude slower than one in which the code has been fully optimised. It's not quite the same degree of performance hit for many CISC processors, though with the large superscalar instruction pipelines of the current CISC processors and the SIMD instructions, the imporatnce of proper instruction scheduling is getting greater.
Ah, I see.. I admit to have mis-read that pert of the article, thinking that you were testing the time taken to build a cross compiler, not to build an application using that compiler.
That is, indeed, a far better way of testing the systems. Please take my appology on this point.
I'm sure you'll agree, however, that even given that, it's not necessarily true to say that this is a definitive statement on the relative potential speeds of the two types of machine, as it depends upon the efficiency of the compilers involved. It takes a huge amount of work to get the best from a RISC processor and GCC isn't all that good in that area (relative to the manufacturer's own optimised compilers).
I'm sure this person THINKS he's testing the same thing on each machine. Unfortunately, he's not.
Firstly, the action of compiling on different architectures is very different, even without considering optimisation strategies. To compile code into the CISC code of the x86 architecture is very different from that of a RISC chip such as the PowerPC. For a start, instruction ordering etc. for a RISC chip, even for not really optimised code can take far more processing time. Then, if you add optimisation, which in a RISC architecture is a FAR more complex task.
All this means is that compiling on a RISC architecture is bound to be a great deal slower.
Basically, this "benchmark" is measuring not only the intrinsic speed differences of the architectures and chips but also degree of optimisation the native compilers used can cope with and the extra processing power needed to generate the code during the comile stages.
Basically, using compilation as a benchmark is not at all useful, other than to test the difference in speed of two similar peices of equipment using identical software (ie. compilers & OS) or the difference between two versions of the same OS or two versions of the same compiler.. Basically, you can only change one variable to deliver a meaningful benchmark if using the method chosen in this "study."
The only way to get a half-way meaningful benchmark for the two systems used here would be to write a program which did lots on disk I/O and integer manipulation, worrying about whether it's being biased for or against certain types of architecture or use (eg. loops sitting in cache etc.). This would give you an idea of the real-world speed differences between the two systems. However, you won't be just measuring the intrinsic speed of the machine but also the different ways the kernels have to do things on the two architectures, the degree of optimisation the compilers building the kernel and the program could generate and the speed of the hard disk built into the machine.
As you can see, it's a tricky thing comparing two types of machine.
At least, if it is happening from US gov't sites after June 25, 2001, you can sue them. Thanks to Section 508, any federal web site that is publically
accessible must meet many guidelines, including access for disabled people; the divisions whose sites are not compliant by this point without
sufficient reason to not be compliant can be sued by the public or have displinary action taken by other parts of the gov't. This includes not locking
out browsers (including text-based ones).
I think you'll find that both British government guidelines and an EU directive means that this site is technically in breach of the law here as well. Of course, this hasn't stopped the new government E-envoy's department from closing all the old portals and banning the use of Linux as a web server within all the departments.
All local and national government web sites HAVE to be accessable by the disabled and sight impared. This site, which blocks lynx and the like, breaks this rule as the site impared have to use text-only browsers to access it.
Oh and very slightly off topic.. many of you in the UK will have seen last night on the news the embarassing sight of Tony and Cherie Blair being given a demonstration (sales pitch) on Office XP at Microsoft's head office in the UK. The Labour Party and Microsoft in bed together? Nah, surely not?!
This all seems like an updated, uprated version of the old late 70's Horby Zero-1 system.
Basically, the Zero-1 system could control up to 16 locomotives and 99 "other" devices such as signals and points etc. Seeing as in the main unit it had a 4bit TI processor to control it, you can see why the 16 loco limit was there.
In each loco you had to install a circuit board which you coded to the loco's ID number using thin wire through holes in pads. The circuitboard sat between the motor and the power-pick-ups on the wheels, the circuit then rectified the AC current and controlled it to vary the motor speed with 16 voltage steps.
The data was sent to the locos and other things through the track using a modulated 16v AC system.
The major problems with the system were that the high frequencies of the current caused the tyres of the wheels to get burnt and pitted, causing poor contacts and the small number of units which could be controlled. Oh, and the half rectified DC from the circuits in the locos generally caused the motors to overheat and possibly burn out.
Recently, the games industry has discovered that
there are no more games hackers coming up
through the system. The majority of the coders
learnt their trade through spending night after
night playing with their ZX Spectrums and C64's
in the early 80's.
These days, with the shrink-wrapped games running
on undocumented programmer hostile operating
systems, only the hard core hackers play with
the machines, and these aren't the sort who
would be likely to play with writing games.
Adding a BASIC interpreter to the PSX2 is a smart
move. It'll give the game playing public a chance
to play at controlling their own machine and
compete with their peers about what their latest
neat game coding trick is.. creating a new
generation of games coders for the gaming industry.
On top of this, it may also be a ploy to persuade
the EU commission that the PSX2 is a computer and
not a games console, so they don't have to pay the
2.2% levy, of course.
The HURD is based upon the MicroKernel technology which was in vogue in the Computer Science community about 10 years ago. Time has moved on, people have taken the ideas from this technology and incorporated the best bits into the semi-monolithic kernels of today, Microkernels are looked upon as a relic.
MicroKernels are theoretically so much cleaner and efficient. They are built on the idea that every part of the system has its own thread of execution and that the "kernel" contains nothing more than a facility to pass messages between the threads. In some extremes of the idea even the scheduler is just another thread. This design means that everything is compartmentalised, clean, organised.
The problem with this approach is that in the real worl this deisng has a massive performance hit. Every thread context switch, every message passed needs CPU and/or memory overhead. If a processor was designed with internal massively parallel instruction streams and internal message passing this wouldn't be a problem.. with current processors it is.
What's wrong with Linux
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a lot of baggage from those days even though it's come a long way and been ported to many architectures.
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other architectures too.
There is also the problem of the "one size fits all" mentality.. it doesn't work!
Sure, you can have a family of kernels, each aimed at a different niche with what common code they can share shared, but don't try to force the same kernel onto everything otherwise everyone will loose out.
Before anyone tries to label me as a supporter of some other system saying that I'm only bashing their favourite because I have an axe to grind, I don't see any of the free or commercial operating systems today being able to be all things to all men.. and I don't see any being so in the future either.
Another problem is that all those colours are just waisting the colourmap of all those users who have palette-based 8bit displays.
As it is, KDE 1.0 steals too much of the colourmap for itself, stopping things such as Acrobat Reader 4 from running.
At the moment most of the effort in GUI design is colourful wrapping paper which gives a good first impression rather than making the thing nice to use in the long-term.
Who needs a good product if the marketting's right?
Imagine this: A windowing system where a programmer merely tells the system about the format of the data to be displayed and then sent the data to the windowing system..
No more worrying about re-draws, or where the window is on the screen in pixels.. just clean virtual co-ordinates, scaled by the windowing system at the display end. Buttons and input handled by the display and only important information sent back to the client as and when it it is needed, defined by the client's application when the object was created. Applications simple enough that in only a few lines of code an application can get a window displayed, scaled and controlled.
This is the dream of many a programmer. Instead, X is archaic, making the programmer at the application end do all the hard work, sending large pixel maps down the network every time a window is uncovered etc. all of which the display side of things should know how to control more efficiently anyway.
How many megabytes of code is written just to do the basic control of a simple window? Wouldn't it be better if all this is taken out of the application's hands, unless it asks to have that degree of control?
What's needed is a new windowing system which does all the hard work for the programmer and the application, is networked like X and gives an X api for backward compatibility.. but with the application being given it's own virtual display which is mostly managed for it by the windowing system.
This would solve three problems:
Application complexity.
Network bandwidth.
Backward compatibility.
The downside would be that the display system on the computer displaying the data would have to be more capable..it would have to know how to redraw windows for it's clients, it would have to know how to scale, scroll and generally transform the windows and their contents. it would need a get deal more computing power and memory than X, in other words. The other side of the coin would be that the code would only be there once.. the applications would be FAR smaller and FAR less complex, helping with stability and speed, especially over a network.
The only question is.. who is going to do the hard work and write such a system?
I'm sorry you feel that way about Oxford in general.
As a sysadmin at one of the science departments here at Oxford I can say that not all the people in the University should be tarred with the same brush.
Knowing the way the University works, it's probable that the decision to pull the page was probably made at the Proctor's office level and not at the OUCS (Computing Services) level.
I cannot talk for the people in the Computing Laboratories (CompSci department) but there ARE some really knowledgable and on-the-ball hackers (original meaning) running computers around the University.. and their average age is WELL below the 65 you state.
Myself, I would have tried to explain the technicalities to the powers that be.. however, in the end if this had happened within our department I would probably have had to bow to the pressure also.
I'm not saying that the student was right or wrong in putting the page up as he did, but every person who gets an account on any system within the University has to sign an agreement that includes the proviso to remove any service pending an investigation.
All this sort of stuff is new territory for everyone and there seems to be a great worry over setting the wrong president for the future.
Stephen Usher
(Note, I'm speaking for myself and not for the Department of Earth Sciences or the University of Oxford in any official manner. These are my opinions and mine alone.)
PS. What's wrong with Solaris or any other UNIX type OS for servers in a university? (Oh dear, I can hear those flame burners being lit as I type..:-))
Slashdot Mirror
Well, OpenWindows was basically a port of the old SunView system, which was the original windowing system, to X11R3. SunView was rather revolutionary at the time and, I think, predates X by a number of years. Hence, it doesn't "follow industry standards" because it pre-dates them.
The Openwindows (or OpenLook) libraries are pretty well call for call compatible with the SunView library calls and look nothing like the normal X library stuff.. and are arguably easier to use, hence they were used quite widely in scientific applications.
For those who are used to the interface, moving to the other windowing systems and desktop environments can be quite a culture shock.
On our systems we have Openwindows, CDE, KDE 1, KDE 2.2 and GNOME 1.4. There are a number of people who I can't get to move from Openwindows, others who PREFER CDE, a lot who prefer KDE 1 to KDE 2 etc.
Each to their own, I say.
The main problem I have with the KDE development structure is that they stop fixing bugs, even pretty major ones, on the stable release just to concentrate on the new whizz-bang version coming up.
If they continued supplying bug fixes for the old stable release for a significant period of time after the initial realease and even overlapped these fixes with the full release of the next version (so that those people who need time to plan for upgrading the system on a large, multi-machine, multi-user system such as the one I run have a chance to keep bug-free) I would feel a whole lot happier.
PS. Oh, and if only kmail had the ability of having mailing list aliases it would also help. At the moment I'm having to kludge things for our users by using nmh's 'post' program as a mail posting agent so that aliases can be used properly. (Kaddressbook/Kab etc. don't have any such facility and there are a number of "Wish-list" bugs postingss for this which haven't even been replied to.)
The problem here is that you're looking at things from a purely Linux-centric viewpoint.
/bin/sh == bash and a few other Linux-centric assumptions).
The other week I had a go at building and installing GNOME under Solaris so as to get a certain piece of scientific software running on our Sun Solaris systems (which range from versions 2.6 to 8).
I first went to the GNOME site and downloaded the libraries the web pages told me I needed.. plus everything else fromt he stable directory. I thought that as I'd read the instructions and downloaded all of the stable source I would be home and dry, it'd just need a lot of configure, build and install cycles.
Little did I know that most of the libraries in the "stable" branch required a multitude of libraries fromt eh unstable one, many of which didn't play well in the configure scripts (they assumed that
Basically, after a week of trying to build things, finding I needed yet another library or utility from an unstable branch or from an obscure web site somewhere I managed to build enough of the core libraries to build the application.
And before anyone says "Why didn't you download a binary version?" I did look into this but the version on SunFreeware was disgned as a single machine installation, not a network wide one. The recently released Sun beta release version of GNOME 1.4 is only for Soalris 8 AND half the libraries needed by the scientific application were newer than in the GNOME 1.4 "release."
If the library API's aren't standardised soon and kept stable then people will shun such things as GNOME. For someone tinkering on their own system it may be fine to play for weeks getting things working, but in the "real world" this is just untenable.
Ah, I see.. I admit to have mis-read that pert of the article, thinking that you were testing the time taken to build a cross compiler, not to build an application using that compiler.
That is, indeed, a far better way of testing the systems. Please take my appology on this point.
I'm sure you'll agree, however, that even given that, it's not necessarily true to say that this is a definitive statement on the relative potential speeds of the two types of machine, as it depends upon the efficiency of the compilers involved. It takes a huge amount of work to get the best from a RISC processor and GCC isn't all that good in that area (relative to the manufacturer's own optimised compilers).
I'm sure this person THINKS he's testing the same thing on each machine. Unfortunately, he's not.
Firstly, the action of compiling on different architectures is very different, even without considering optimisation strategies. To compile code into the CISC code of the x86 architecture is very different from that of a RISC chip such as the PowerPC. For a start, instruction ordering etc. for a RISC chip, even for not really optimised code can take far more processing time. Then, if you add optimisation, which in a RISC architecture is a FAR more complex task.
All this means is that compiling on a RISC architecture is bound to be a great deal slower.
Basically, this "benchmark" is measuring not only the intrinsic speed differences of the architectures and chips but also degree of optimisation the native compilers used can cope with and the extra processing power needed to generate the code during the comile stages.
Basically, using compilation as a benchmark is not at all useful, other than to test the difference in speed of two similar peices of equipment using identical software (ie. compilers & OS) or the difference between two versions of the same OS or two versions of the same compiler.. Basically, you can only change one variable to deliver a meaningful benchmark if using the method chosen in this "study."
The only way to get a half-way meaningful benchmark for the two systems used here would be to write a program which did lots on disk I/O and integer manipulation, worrying about whether it's being biased for or against certain types of architecture or use (eg. loops sitting in cache etc.). This would give you an idea of the real-world speed differences between the two systems. However, you won't be just measuring the intrinsic speed of the machine but also the different ways the kernels have to do things on the two architectures, the degree of optimisation the compilers building the kernel and the program could generate and the speed of the hard disk built into the machine.
As you can see, it's a tricky thing comparing two types of machine.
I think you'll find that both British government guidelines and an EU directive means that this site is technically in breach of the law here as well. Of course, this hasn't stopped the new government E-envoy's department from closing all the old portals and banning the use of Linux as a web server within all the departments.
All local and national government web sites HAVE to be accessable by the disabled and sight impared. This site, which blocks lynx and the like, breaks this rule as the site impared have to use text-only browsers to access it.
Oh and very slightly off topic.. many of you in the UK will have seen last night on the news the embarassing sight of Tony and Cherie Blair being given a demonstration (sales pitch) on Office XP at Microsoft's head office in the UK. The Labour Party and Microsoft in bed together? Nah, surely not?!
This all seems like an updated, uprated version of the old late 70's Horby Zero-1 system.
Basically, the Zero-1 system could control up to 16 locomotives and 99 "other" devices such as signals and points etc. Seeing as in the main unit it had a 4bit TI processor to control it, you can see why the 16 loco limit was there.
In each loco you had to install a circuit board which you coded to the loco's ID number using thin wire through holes in pads. The circuitboard sat between the motor and the power-pick-ups on the wheels, the circuit then rectified the AC current and controlled it to vary the motor speed with 16 voltage steps.
The data was sent to the locos and other things through the track using a modulated 16v AC system.
The major problems with the system were that the high frequencies of the current caused the tyres of the wheels to get burnt and pitted, causing poor contacts and the small number of units which could be controlled. Oh, and the half rectified DC from the circuits in the locos generally caused the motors to overheat and possibly burn out.
Recently, the games industry has discovered that
there are no more games hackers coming up
through the system. The majority of the coders
learnt their trade through spending night after
night playing with their ZX Spectrums and C64's
in the early 80's.
These days, with the shrink-wrapped games running
on undocumented programmer hostile operating
systems, only the hard core hackers play with
the machines, and these aren't the sort who
would be likely to play with writing games.
Adding a BASIC interpreter to the PSX2 is a smart
move. It'll give the game playing public a chance
to play at controlling their own machine and
compete with their peers about what their latest
neat game coding trick is.. creating a new
generation of games coders for the gaming industry.
On top of this, it may also be a ploy to persuade
the EU commission that the PSX2 is a computer and
not a games console, so they don't have to pay the
2.2% levy, of course.
The HURD is based upon the MicroKernel technology which was in vogue in the Computer Science community about 10 years ago. Time has moved on, people have taken the ideas from this technology and incorporated the best bits into the semi-monolithic kernels of today, Microkernels are looked upon as a relic.
MicroKernels are theoretically so much cleaner and efficient. They are built on the idea that every part of the system has its own thread of execution and that the "kernel" contains nothing more than a facility to pass messages between the threads. In some extremes of the idea even the scheduler is just another thread. This design means that everything is compartmentalised, clean, organised.
The problem with this approach is that in the real worl this deisng has a massive performance hit. Every thread context switch, every message passed needs CPU and/or memory overhead. If a processor was designed with internal massively parallel instruction streams and internal message passing this wouldn't be a problem.. with current processors it is.
What's wrong with Linux
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a lot of baggage from those days even though it's come a long way and been ported to many architectures.
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other architectures too.
There is also the problem of the "one size fits all" mentality.. it doesn't work!
Sure, you can have a family of kernels, each aimed at a different niche with what common code they can share shared, but don't try to force the same kernel onto everything otherwise everyone will loose out.
Before anyone tries to label me as a supporter of some other system saying that I'm only bashing their favourite because I have an axe to grind, I don't see any of the free or commercial operating systems today being able to be all things to all men.. and I don't see any being so in the future either.
waisting the colourmap of all those users who
have palette-based 8bit displays.
As it is, KDE 1.0 steals too much of the colourmap
for itself, stopping things such as Acrobat Reader
4 from running.
At the moment most of the effort in GUI design is
colourful wrapping paper which gives a good
first impression rather than making the thing
nice to use in the long-term.
Who needs a good product if the marketting's right?
No more worrying about re-draws, or where the window is on the screen in pixels.. just clean virtual co-ordinates, scaled by the windowing system at the display end. Buttons and input handled by the display and only important information sent back to the client as and when it it is needed, defined by the client's application when the object was created. Applications simple enough that in only a few lines of code an application can get a window displayed, scaled and controlled.
This is the dream of many a programmer. Instead, X is archaic, making the programmer at the application end do all the hard work, sending large pixel maps down the network every time a window is uncovered etc. all of which the display side of things should know how to control more efficiently anyway.
How many megabytes of code is written just to do the basic control of a simple window? Wouldn't it be better if all this is taken out of the application's hands, unless it asks to have that degree of control?
What's needed is a new windowing system which does all the hard work for the programmer and the application, is networked like X and gives an X api for backward compatibility.. but with the application being given it's own virtual display which is mostly managed for it by the windowing system.
This would solve three problems:
- Application complexity.
- Network bandwidth.
- Backward compatibility.
The downside would be that the display system on the computer displaying the data would have to be more capable..it would have to know how to redraw windows for it's clients, it would have to know how to scale, scroll and generally transform the windows and their contents. it would need a get deal more computing power and memory than X, in other words. The other side of the coin would be that the code would only be there once.. the applications would be FAR smaller and FAR less complex, helping with stability and speed, especially over a network.The only question is.. who is going to do the hard work and write such a system?
I'm sorry you feel that way about Oxford in general.
:-))
As a sysadmin at one of the science departments here at Oxford I can say that not all the people in the University should be tarred with the same brush.
Knowing the way the University works, it's probable that the decision to pull the page was probably made at the Proctor's office level and not at the OUCS (Computing Services) level.
I cannot talk for the people in the Computing Laboratories (CompSci department) but there ARE some really knowledgable and on-the-ball hackers (original meaning) running computers around the University.. and their average age is WELL below the 65 you state.
Myself, I would have tried to explain the technicalities to the powers that be.. however, in the end if this had happened within our department I would probably have had to bow to the pressure also.
I'm not saying that the student was right or wrong in putting the page up as he did, but every person who gets an account on any system within the University has to sign an agreement that includes the proviso to remove any service pending an investigation.
All this sort of stuff is new territory for everyone and there seems to be a great worry over setting the wrong president for the future.
Stephen Usher
(Note, I'm speaking for myself and not for the Department of Earth Sciences or the University of Oxford in any official manner. These are my opinions and mine alone.)
PS. What's wrong with Solaris or any other UNIX type OS for servers in a university? (Oh dear, I can hear those flame burners being lit as I type..