If the designers of this new OS can take some liberties and leave out support for Win16 stuff, then the whole thing can a true, non-bloated OS capable of running Win32 applications (which btw. are the only ones worth running and...
The windows OS's are riddled with a ton of 16bit code. I read about it in an article about the Crusoe processor. They originally optimized it for 32bit code. They found it performed very poorly because of the unexpected amount of 16bit code and had to redesign the chip.
I don't know about XML but IBM has provided a very important service to the Linux community regarding Java in the form of their JDK. Works pretty well too. Very fast.
We definitely need a good Usenet site for searching and timely browsing/retrieval. I have used deja religiously. When my company blocked it as explicit content I freaked and sent an e-mail to everyone in the company I knew. A slew of people backed me up and those are only the people who cc'd me. They wrote long descriptions of why the site was so valuable, ordering our firewall group to return it's access. Took about a week but we got it back.
We must start an open source project to provide this functionality. It is our duty to expose this wonderful free forum to the general internet community. The problem is the technical limitations. Such a program(probably distributed) must have these characteristics:
1) Fast Searching - this is rather tricky. Dejanews was, or still is, capable of searching the full text of 100 million articles VERY quickly. I don't know how they did it but I would imagine this would require custom database like functionality that could preprocess all articles indexing each word such that all the work was done in advance. This would certainly be the most difficult part of the project.
2) Quicker Posting/Retrieval Response Time - As it is deja does not respond too quickly to posts. It takes several hours I believe before a message is searchable on the site. I don't know about browsing particular groups but it would have to be on the order of minutes. This should be possible as MS Outlook News Reader is quite fast at this and we all know it has nothing to do with MS Software:~)
3) Ability to populate database with mailing lists. It would be a very cool feature if one could add an arbitrary mailing list such as that of an open source project to the indexable archive.
Also I believe someone could make a viable business out of it. A Usenet search site could be very profitable. I'm surprised no one has caught on to this. Deja dropped the ball and hid the "discussions" pages behind it's new facade. Odd. I can only imagine how many hits a site like that would get. If the USENET search capability was presented as the premiere offering of a site it might not seem so obscure to average users. They would perhaps discover Usenet as the great alternative source of information that it is. Usenet would be the latest and greatest thing! With all the "instant messaging" going on it would not seem so foreign to people. Also I would think some people would be willing to pay for this service. I would be willing to pay a small fee. Say $20 a year?
I think your taking the Java model a little too seriously Tim. Granted I beleive Java will have more of an influence than people think. They should start teaching it to the new kids in cs 101.
However I'm talking about low level OS libraries, not distributed computing. Static libraries are the way to go.
See the real problem we'd be addressing is how out of control apps get. I know people are in denial about this but our open source code is just as bloated as MS's I'm sad to say. Or it suffers from a lack of functionality. This is to say the're too many dependancies that transcend these applications turning the slightest modification into a nightmare.
In every application is code that could be librarified. Take something like vim. If you could isolate the functional parts of that and implement a standard TextEditor interface with it suddendly someone is much closer to writing a very nice email program. Then of course there would be a static library that implements the MailTranferAgent interface for conducting dialog with the popular MTAs. If they want to have a Word like editor instead they can just change one of the libraries properties and boom, they're using that then.
Your insight into stadardizing the interfaces rather than the libraries themselves is very good. I think there would need to be a select group of people with a wide variety of knowledge and excellent OO skills to design these interfaces. I think it would be important to get application maintainers to port their wares into these interfaces quickly at the expense of functionality to prove that they will work though.
One final note though. I think we would have to commit to the c language, use oo in c techniques where ever possible for the sake of speed, then c++ when you need abstractions that require the use of objects as data types. CORBA could be used to allow other languages to be used and of course people can always use c language bindings.
We need to librarify everything first. Just as this/. article with the troll title of UNIX Sucks! points out.
I'm totally into Java at the moment but I can appreciate the benifits(and know how to avoid the pitfalls of) object oriented programming and the need for reusable software components on unix.
We must librarify everything before we build apps! How bout that IBM? I mean it. I want to work on unix libraries. I'm not bad at c/c++.
There should be a very high quality library with a uniform API for e-mail, mathmatics/finance, network filesystem, distributed computing, configuration file API, logging for apps,... etc.
Examine everything that is common/and not so common to day to day computing, reduce it to it's primitives and freeze it into a portable library.
I can go on like this if someone wants to talk about it.
Excuse me but, the X Windows System is NOT a Joy to work with my friend.
Well, I'd like to start by commending all the XFree86 guys for doing such a excellent job with XFree86 v4.
I know we shouldn't complain because it's free but someone should really(as politely as possible) try to convey where the system is deficient. If we don't say anything, it will get worse.
My performance has improved a _lot_ from v3 to v4 (on Red Hat Linux 6.2),
Speed is not the real issue. I consider myself to be a pretty savvy Linux user since 2.0.34 and I still don't understand X. I've learned my way around through hard work like analyzing the Video Timings HOWTO or by applying whatever little tips hand hacks I could find. X is just too complicated. I have no idea how all of the resource files are actually laid out and there simply is no sane documentation on this stuff.
and the support for modular plug-in video drivers is a real bonus.
Mmm, so when would you really recognize this as a "bonus". Do you switch video drivers on a regular basis or something? This is really just a part of the build process labeled a feature.
... not just a method to dump some pixels on a local display. X Windows is as complicated as it is only because it offers so much.
This sounds like a plea but in reality it's denial. Perhaps the system should be something to "dump pixels to the local display". This should be an option. But the option should not be cryptic code in a so called configuration file. I like vi administration. But these configs are abominable.
This and the fact that nothing else I am aware of yet comes close, is one very good reason why its used today as the GUI by Linux, BSD and other *NIXs.
It's also very sad.
The thought of replacing X with an alternative that offers the same functionality and support, yet is faster, leaner and better designed is a huge long-term project, and joining such a project is going to mean more than just a few late nights.
Oh, ok, well then let's just give up on developing this area and accept X as the final product. Shudder.
Seriously, this is not true. Surely it would not be trivial but there is a concept in programming that is becoming readily clearer to programmers. If you can divide a problem into two parts cleanly you have more than reduced it's complexity by half. Actually if you don't break up such a problem as this into many subproblems the program will never reach maturity because the dependencies within cannot be understood by more than one person. Even if one person does understand the entire program it is an impossible amount of work to make even the slightest change because these procedural oriented dependencies transcend the system.
With a good object oriented design it should be possible to librarify everything and maintain good performance. Thus we would no longer be developing an "X Windowing System" as it is known. There would be several groups of developers, one writing the font renderer, another tweaking graphics routines,...etc. This cannot be done with the current X Windowing System because to add something like a graphic routine primitive would require knowledge of many other dependencies.
Now I'm making these particular examples up because I cannot even begin to come up with a good object oriented design for a graphics subsystem such as X. That would require someone who is familiar with existing graphic subsystems from which they could learn about what is required, what has worked, and where the system can be improved. Only then could such a person rationally create an high level design and begin to cleanly abstract pieces that could be delegated to otherwise unrelated teams of developers.
This design admittedly would have to be a very clever because you do not have the luxury of making many objects and abstracting the smallest of details(ie have an object for every potentially displayed character). This would be too costly. Perhaps objective c can help here. Right now X is not OO at all and this will not do. You need OO data types.
When I demonstrate Linux (with GNOME + SawFish) to people who have never seen it before, they love it. Why? Because it is well designed and things fit. Just because something is radical doesn't mean its going to be "better", particularly given existing user experience and training. There are too many exciting developments to spend time going through them all here.
People may like it initially but in reality I believe most of this functionality is cosmetic. There have been no additions to the X window system for as long as I can remember that really improved overall functionality. For example you cannot easily change the resolution of the screen. If they where required to use it for day to day office like activities I'm afraid they would come to hate it as would any group attempting to support it although the primary reasons for this are not the fault of X.
The current outcome? The combination of GNOME + SawFish WM + XFree86 v4 + Linux just blows me away.
Again, it make look cool but it doesn't impress anyone who has to just get some work done. I would have thought that X would have made more progress by now. When I see v4 I am willing to bet it is no different. Same awful configs, messed up keyboard and mouse problems, and of course there is now way a new version of X could solve the incompatibilities of layers above. Shouldn't it be effortless to specify a window manager such as WindowMaker without editing configs?
Want games with that? How about Quake III Arena with full 3D acceleration?! Now _that_ is a nice environment.
I don't care about games and acceleration too much alltough I believe this cannot be ignored as there is a great demand for it. But regardless of it's performance with Quake if it doesn't address some of the fundamental usage problems I fear everyone dependant on it will loose to MS.
EXAMPLES OF PROBLEMS:
1) Changing the color of a font for the system. I tried editing app-defaults to no avail. Properly designed software should provide a clear way to set such runtime constants in a clean way.
2) Interactions between all of the various componentry that might be layered on top. It's difficult for the user to manage window managers and desktops let alone try and troubleshoot a problem by trying to understand conceptually whats going on underneath. Perhaps interfaces at the various layers should be more clearly defined. At least guidance on good X programming etiquette should be provided and enforced.
3) Inconsistent usage by other layers on top. Perhaps they should have provided a bit more structure the windowing APIs. i.e. applications could be required to provide proper class attributes so that the window manager can properly handle the apps properties.
4) Poor mouse control. At high resolutions the parameters controlled by xset are not satisfactory to allow fine grained mouse movements.
5) Most importantly, don't assume users don't want to know whats happening on the inside. Savvy users should be able to explain the design and make educated judgements about what problem is coming from where based on that knowledge. This is where Microsoft has failed. I would rather have something with less functionality with hope of improvement than a black box.
This would not be complete without mentioning the Expect extensions to the Tcl language by Don Libes.
For those of you who are unfamiliar with Expect, it provides Tcl commands for scripting interactive processes like telnet, ftp, or other terminal driven apps. It's standard on most UNIX installations(man expect).
Nice for webifiying those pecular terminal driven tasks like telneting in to some machine and pulling down info to be displayed in an actual human readable format.
Check out the Expect Home Page. I know there's a CGI tutorial floating around somewhere but if you know Tcl it should be pretty obvious
Good point. They do sell Debian. In fact the're logo is on the cover of the version they sell. They offer support for it too. The site lies when they list VA as a vendor that "ONLY supports Red Hat". Makes you wonder about the validity of their other claims.
that the site will only serve to promote Red Hat because the message is that Red Hat is the best supported distro and that application vendors target it specifically.
Slashdot Mirror
If the designers of this new OS can take some liberties and leave out support for Win16 stuff, then the whole thing can a true, non-bloated OS capable of running Win32 applications (which btw. are the only ones worth running and ...
The windows OS's are riddled with a ton of 16bit code. I read about it in an article about the Crusoe processor. They originally optimized it for 32bit code. They found it performed very poorly because of the unexpected amount of 16bit code and had to redesign the chip.
KidSock
I don't know about XML but IBM has provided a very important service to the Linux community regarding Java in the form of their JDK. Works pretty well too. Very fast.
KidSock
pls mod this up
KidSock
Try hitting stop on the browser. Maybe that would kill tha JavaScript thats doing it.
We definitely need a good Usenet site for searching and timely browsing/retrieval. I have used deja religiously. When my company blocked it as explicit content I freaked and sent an e-mail to everyone in the company I knew. A slew of people backed me up and those are only the people who cc'd me. They wrote long descriptions of why the site was so valuable, ordering our firewall group to return it's access. Took about a week but we got it back.
We must start an open source project to provide this functionality. It is our duty to expose this wonderful free forum to the general internet community. The problem is the technical limitations. Such a program(probably distributed) must have these characteristics:
1) Fast Searching - this is rather tricky. Dejanews was, or still is, capable of searching the full text of 100 million articles VERY quickly. I don't know how they did it but I would imagine this would require custom database like functionality that could preprocess all articles indexing each word such that all the work was done in advance. This would certainly be the most difficult part of the project.
2) Quicker Posting/Retrieval Response Time - As it is deja does not respond too quickly to posts. It takes several hours I believe before a message is searchable on the site. I don't know about browsing particular groups but it would have to be on the order of minutes. This should be possible as MS Outlook News Reader is quite fast at this and we all know it has nothing to do with MS Software :~)
3) Ability to populate database with mailing lists. It would be a very cool feature if one could add an arbitrary mailing list such as that of an open source project to the indexable archive.
Also I believe someone could make a viable business out of it. A Usenet search site could be very profitable. I'm surprised no one has caught on to this. Deja dropped the ball and hid the "discussions" pages behind it's new facade. Odd. I can only imagine how many hits a site like that would get. If the USENET search capability was presented as the premiere offering of a site it might not seem so obscure to average users. They would perhaps discover Usenet as the great alternative source of information that it is. Usenet would be the latest and greatest thing! With all the "instant messaging" going on it would not seem so foreign to people. Also I would think some people would be willing to pay for this service. I would be willing to pay a small fee. Say $20 a year?
KidSock
I think your taking the Java model a little too seriously Tim. Granted I beleive Java will have more of an influence than people think. They should start teaching it to the new kids in cs 101.
However I'm talking about low level OS libraries, not distributed computing. Static libraries are the way to go.
See the real problem we'd be addressing is how out of control apps get. I know people are in denial about this but our open source code is just as bloated as MS's I'm sad to say. Or it suffers from a lack of functionality. This is to say the're too many dependancies that transcend these applications turning the slightest modification into a nightmare.
In every application is code that could be librarified. Take something like vim. If you could isolate the functional parts of that and implement a standard TextEditor interface with it suddendly someone is much closer to writing a very nice email program. Then of course there would be a static library that implements the MailTranferAgent interface for conducting dialog with the popular MTAs. If they want to have a Word like editor instead they can just change one of the libraries properties and boom, they're using that then.
Your insight into stadardizing the interfaces rather than the libraries themselves is very good. I think there would need to be a select group of people with a wide variety of knowledge and excellent OO skills to design these interfaces. I think it would be important to get application maintainers to port their wares into these interfaces quickly at the expense of functionality to prove that they will work though.
One final note though. I think we would have to commit to the c language, use oo in c techniques where ever possible for the sake of speed, then c++ when you need abstractions that require the use of objects as data types. CORBA could be used to allow other languages to be used and of course people can always use c language bindings.
Mike
We need to librarify everything first. Just as this /. article with the troll title of UNIX Sucks! points out.
I'm totally into Java at the moment but I can appreciate the benifits(and know how to avoid the pitfalls of) object oriented programming and the need for reusable software components on unix.
We must librarify everything before we build apps! How bout that IBM? I mean it. I want to work on unix libraries. I'm not bad at c/c++.
There should be a very high quality library with a uniform API for e-mail, mathmatics/finance, network filesystem, distributed computing, configuration file API, logging for apps, ... etc.
Examine everything that is common/and not so common to day to day computing, reduce it to it's primitives and freeze it into a portable library.
I can go on like this if someone wants to talk about it.
KidSock
But what can we do armed with knowledge of subatomic particles?
Will beams of Tau Nutrinos be usefull?
Excuse me but, the X Windows System is NOT a Joy to work with my friend.
Well, I'd like to start by commending all the XFree86 guys for doing such a excellent job with XFree86 v4.
I know we shouldn't complain because it's free but someone should really(as politely as possible) try to convey where the system is deficient. If we don't say anything, it will get worse.
My performance has improved a _lot_ from v3 to v4 (on Red Hat Linux 6.2),
Speed is not the real issue. I consider myself to be a pretty savvy Linux user since 2.0.34 and I still don't understand X. I've learned my way around through hard work like analyzing the Video Timings HOWTO or by applying whatever little tips hand hacks I could find. X is just too complicated. I have no idea how all of the resource files are actually laid out and there simply is no sane documentation on this stuff.
and the support for modular plug-in video drivers is a real bonus.
Mmm, so when would you really recognize this as a "bonus". Do you switch video drivers on a regular basis or something? This is really just a part of the build process labeled a feature.
This sounds like a plea but in reality it's denial. Perhaps the system should be something to "dump pixels to the local display". This should be an option. But the option should not be cryptic code in a so called configuration file. I like vi administration. But these configs are abominable.
This and the fact that nothing else I am aware of yet comes close, is one very good reason why its used today as the GUI by Linux, BSD and other *NIXs.
It's also very sad.
The thought of replacing X with an alternative that offers the same functionality and support, yet is faster, leaner and better designed is a huge long-term project, and joining such a project is going to mean more than just a few late nights.
Oh, ok, well then let's just give up on developing this area and accept X as the final product. Shudder.
Seriously, this is not true. Surely it would not be trivial but there is a concept in programming that is becoming readily clearer to programmers. If you can divide a problem into two parts cleanly you have more than reduced it's complexity by half. Actually if you don't break up such a problem as this into many subproblems the program will never reach maturity because the dependencies within cannot be understood by more than one person. Even if one person does understand the entire program it is an impossible amount of work to make even the slightest change because these procedural oriented dependencies transcend the system.
With a good object oriented design it should be possible to librarify everything and maintain good performance. Thus we would no longer be developing an "X Windowing System" as it is known. There would be several groups of developers, one writing the font renderer, another tweaking graphics routines, ...etc. This cannot be done with the current X Windowing System because to add something like a graphic routine primitive would require knowledge of many other dependencies.
Now I'm making these particular examples up because I cannot even begin to come up with a good object oriented design for a graphics subsystem such as X. That would require someone who is familiar with existing graphic subsystems from which they could learn about what is required, what has worked, and where the system can be improved. Only then could such a person rationally create an high level design and begin to cleanly abstract pieces that could be delegated to otherwise unrelated teams of developers.
This design admittedly would have to be a very clever because you do not have the luxury of making many objects and abstracting the smallest of details(ie have an object for every potentially displayed character). This would be too costly. Perhaps objective c can help here. Right now X is not OO at all and this will not do. You need OO data types.
When I demonstrate Linux (with GNOME + SawFish) to people who have never seen it before, they love it. Why? Because it is well designed and things fit. Just because something is radical doesn't mean its going to be "better", particularly given existing user experience and training. There are too many exciting developments to spend time going through them all here.
People may like it initially but in reality I believe most of this functionality is cosmetic. There have been no additions to the X window system for as long as I can remember that really improved overall functionality. For example you cannot easily change the resolution of the screen. If they where required to use it for day to day office like activities I'm afraid they would come to hate it as would any group attempting to support it although the primary reasons for this are not the fault of X.
The current outcome? The combination of GNOME + SawFish WM + XFree86 v4 + Linux just blows me away.
Again, it make look cool but it doesn't impress anyone who has to just get some work done. I would have thought that X would have made more progress by now. When I see v4 I am willing to bet it is no different. Same awful configs, messed up keyboard and mouse problems, and of course there is now way a new version of X could solve the incompatibilities of layers above. Shouldn't it be effortless to specify a window manager such as WindowMaker without editing configs?
Want games with that? How about Quake III Arena with full 3D acceleration?! Now _that_ is a nice environment.
I don't care about games and acceleration too much alltough I believe this cannot be ignored as there is a great demand for it. But regardless of it's performance with Quake if it doesn't address some of the fundamental usage problems I fear everyone dependant on it will loose to MS.
EXAMPLES OF PROBLEMS:
1) Changing the color of a font for the system. I tried editing app-defaults to no avail. Properly designed software should provide a clear way to set such runtime constants in a clean way.
2) Interactions between all of the various componentry that might be layered on top. It's difficult for the user to manage window managers and desktops let alone try and troubleshoot a problem by trying to understand conceptually whats going on underneath. Perhaps interfaces at the various layers should be more clearly defined. At least guidance on good X programming etiquette should be provided and enforced.
3) Inconsistent usage by other layers on top. Perhaps they should have provided a bit more structure the windowing APIs. i.e. applications could be required to provide proper class attributes so that the window manager can properly handle the apps properties.
4) Poor mouse control. At high resolutions the parameters controlled by xset are not satisfactory to allow fine grained mouse movements.
5) Most importantly, don't assume users don't want to know whats happening on the inside. Savvy users should be able to explain the design and make educated judgements about what problem is coming from where based on that knowledge. This is where Microsoft has failed. I would rather have something with less functionality with hope of improvement than a black box.
KidSock
This would not be complete without mentioning the
Expect extensions to the Tcl language by Don
Libes.
For those of you who are unfamiliar with Expect,
it provides Tcl commands for scripting
interactive processes like telnet, ftp, or other
terminal driven apps. It's standard on most
UNIX installations(man expect).
Nice for webifiying those pecular terminal driven
tasks like telneting in to some machine and
pulling down info to be displayed in an actual
human readable format.
Check out the Expect Home Page. I know there's
a CGI tutorial floating around somewhere but
if you know Tcl it should be pretty obvious
KidSock
Good point. They do sell Debian. In fact the're logo is on the cover of the version they sell. They offer support for it too. The site lies when they list VA as a vendor that "ONLY supports Red Hat". Makes you wonder about the validity of their other claims.
that the site will only serve to promote Red Hat because
the message is that Red Hat is the best supported
distro and that application vendors target it specifically.