Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : LINUX -- Ignore unavailable to you. Want to Upgrade?

To: JC Jaros who wrote (864)	1/17/1999 3:21:00 AM
From: E. Charters	Read Replies (2) \| Respond to of 2617

I draw umbrage at none of what you said but I must restate that the client-server notion is not dead by a long shot. Client-server perhaps should have been expanded and the idea added of moving the desktop control out of the program space of the client program and to the server OS. Programs will always be clients and the OS should always be a server. The services of window control and program interaction and service interaction with windows.. ie: mouse and cursor, should be controlled by a manager that is separate from the program. You have to have an integrated monitor of the windowing function that is called by the program to do its nefarious deeds. This will eliminate what is now serious program to program conflict in use of X resources. It will also allow such things that Gnome is attempting to do such as user control of things like windows controls (buttons slides etc), now the archane domain of the most intrepid X programmer. And that is another area where the X domain can be improved. Operating in a the same address space as X and passing through all X commands a client server architecture machine can extend its services and simplify mapping windows and creating them programmatically and at run time. Code may be passed to client programs in applicatio but windowing creation bandwidth on one machine or a remote vehicle would be vastly simplified. X programming is not just difficult, it is a herculean task beset by all kinds of incompatibilities that beset the system trying to do too many things to too many obsolete and unused systems. (Tcl/TK nothwithstanding) X's real forte is to serve remote machines with different GUI's and architectures. To run on terminals. This day is over. The cheapest best terminal is a PC or Alpha machine, which also scales to be a server. Why support a non-existent usage? It is true that windowing to remote clients per se can be standardized as can languages that access the client space (Java, etc) but he limitations that begat X are not longer with us and the baggage of its upside down and limited "flexibility" are more hindrance than help to development of serious programs. The ideal window manager would experience no conflict as the window code would be simplified to a Java like virtual machine, but compiled like a native machine with adjustments made for running on the server and the client at compile time. With remote clients the remote side window client is already compiled. All that has to pass is ultra high virtual machine commands to create destroy and manipulate what windows are necessary to the code and have the remote client serve them to its space with server control at its side. To create a window remotely all one has to do is say "create wind x,y; size 100, 400" and let the client which acts as a server to itself, take over and manage conflicts. This way as well the server can pass whole code segments for display to the remote client with minimal instruction code for manipulating display.. ie the java concept.. X can and does crash the OS. It will lock it and freeze it. Only way out is to reboot. Netscrape is the most serious offender but there are others. (I have seen Roaches do it) Windows will do this too with some programs. When X is moved out of lock up with the OS in its program functions this will no longer be a nightmare. Why all this client side server side stuff? Well anything a client server machine can do for others it can do for itself. A machine designed to eliminate remote conflicts will have few contentions with its own tasks. As well it allows better peer to peer program sharing, which I contend will be an ever increasing function of the looming ultra large and acceptable speed networks. It is obvious too that bandwidth will always be a beggar where the machine intra process will be king.. so it behoove us to find lean lean ways of sharing display code in common interfaces.. as much as possible has to remain "shared" and limited commands can do much. Ergo HTML, XML, CORBA..etc.. With standards of data/document interfacing we can still have unique presentations methods and uses of data. To this end Forum software and Browser software are much more powerful than most imagine. It is a mistake to make monolithic things like Netscape. External viewers and OS integration of the display concepts is better. I used netscape but only because the OS tools of are so impoverished. It would be vastly better to use the OS nakedly and all its powerful search and document services, if they were adapted to display and deal with the code transparently and cellularly root-level. In other words once you are net-connected to other machines you should stay in the GUI and have the GUI or the command line browse the net or WEB. An URL at the command line of the terminal should search and address. Display of text is the job of an editor and picture can be in a viewer. (ok, you could integrate) This way the OS may manipulate the net interface as parcel of its activities. you never lose the OS interface so to speak.. Sounds like a step back? I view it as a release from browser tyranny that attempts to become on OS but slowly and badly.. Why should it be so hard to use your browser as a off line viewer.. why is so poorly implemented? Is the browser a telco conspiracy to dominate networks and maintain connectedness? If you read the document on the net.. why not the same off net.. why two in(badly)translatable systems.. bleech... wakie wakie people! Document sharing means usage in all domains.. don't give me any more Java pages that attempt to be movies and conspire to fleece me with their version of electronic commerce.. I want info.. well displayed.. usable. Anything out on the net is information sharing.. networking.. not frozen TV for the idiots Many machines that can establish mutual trust or better fences may elect to share net, not web interaction that is more capable than mere HTML documents. CAD, 3D, and other things can be handled by better interfaces that rise as individual and more capable clients for that usage. Why should all machines just do browser interconnection? Documents demand more and databases demand more.. EC<:-}

To: JC Jaros who wrote (864)	1/18/1999 12:45:00 PM
From: g_m10	Read Replies (1) \| Respond to of 2617

From Unix Philosophy...Small is Beautiful, Make each program do one thing well, Choose portability over efficiency, Store numerical data in flat ascii files.. All it sounds so familiar. I've heard it so many times. Of course, this is KISS principle. No wonder Unix works<G>

To: JC Jaros who wrote (864)	1/18/1999 12:56:00 PM
From: Mitch Blevins	Read Replies (1) \| Respond to of 2617

Excellent Book. I'd also like to list the 10 'minor' tenets from the book: 1) Allow the user to tailor the environment 2) Make OS kernels small and lightweight 3) Use lower case and keep it short short. 4) Save trees. (avoid hardcopy) 5) Silence is Golden (no status messages except where action is required) 6) Think parallel. (multitask) 7) The sum of the parts is greater than the whole (an extension of staying small and modular) 8) Look for the 90% solution. (software is _never_ complete, so get 90% of it done right and fast) 9) Worse if better... there is the 'right' way, the 'wrong' way, the 'military' way, and the 'unix' way. Many of the idioms of unix are there because they survived despite going against conventional design theory. This should be respected. 10) Think heirarchically.