Slashdot Log In
Let's Make UNIX Not Suck
Posted by
Hemos
on Wed Aug 09, 2000 10:45 AM
from the stop-the-sucking! dept.
from the stop-the-sucking! dept.
The above is a title of the talk that Miguel de Icaza of Gnome and now Helix Code fame gave at OLS concerning the look and feel of the UNIXs. From what I've heard from attendants the talk was great - and now you too, in the privacy of your own home/cube/lean-to/car can read it.
This discussion has been archived.
No new comments can be posted.
Let's Make Unix Not Suck
|
Log In/Create an Account
| Top
| 355 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:What's this got to do with UNIX? (Score:3)
But Unix doesn't use those things enough! The philosophy hasn't carried over to the graphical applications, so we have a schitzophrenic Unix where the little text tools try to do one thing well, and the GUI applications are monolithic and try to do everything.
If you like the idea of building a specialized text-processing app by combining some generic tools (e.g. grep, awk, sed, etc), then wouldn't you like to be able to build a specialized GUI app the same way (e.g. HTML renderer, image editor, calendar, etc)? Don't you see a difference between the beauty of grep and the disgusting bloat of Netscape Communicator?
---
Re:Proposal: Linux Unified Model (Score:4)
The point is that there needs to be some sort of policy that is loose enough so that anyone can use and understand it, but rigid enough to enforce a metaphore that works and in understandable by non-computer-cluefull people.
TM'd title (Score:3)
Posix system's aren't really aimed at beginners - that's what people keep forgeting. It was designed for use by people who know what they are doing and how _they_ want to do it - not the way a Redmond base drone wants them to...
Richy C. [beebware.com]
--
Re:UNIX's "problems" are really flexibility (Score:3)
Bollocks, pure and simple. The first Real-World deployment of Unix (i.e. outside ken's lab) was to the secretaries in the patent department of AT & T to enable them to write up patent applications, hence the emphasis on text-management and typesetting software in the early releases of the Unix system.
As for Unix being intended as a server OS - quick reality check required. Unix dates from the late 60s/early 70s. The client-server separation was fifteen years in the future - back then there were no clients. Unix was designed to support multiple terminals (tty0 - n) hanging off a central computer (originally a PDP8 IIRC) which displayed plain text in black and white: termcap files, full-screen editors and the like didn't arrive on the scene until the mid-70s and prior to that people edited with ed.
Get yourself a copy of the Unix Programming Environment and read it, then come back and post an informed comment.
--
Cheers
UNIX trademark (Score:3)
Re:TM'd title (Score:4)
No, people keep forgetting that everyone is a beginner at some point.
Making a system good for beginners does not mean crippling it for advanced users. I think we should be past the point where complexity for complexity's sake should be attractive...
I'm an investigator. I followed a trail there.
Q.Tell me what the trail was.
Re:Great Article... (Score:4)
There has to be a way that a system can serialize data, provide access control to serialized objects, and store thoose objects. This is what Linux is missing in a big way.
Componets are cool, but if we are going to add componets, lets add a constant model or policy, and flexability in. Let's also make it so that there is a common configuration interface, a block or object interface, and some heirchal or non-heirchal way of looking at it.
Middleware (Score:4)
What he's really pointing out is UNIX doesn't have a modern middleware layer.
The history of modern middleware begins with Visual Basic "buttons", which were invented by Alan Cooper. (Microsoft bought this technology; it wasn't developed there.) Visual Basic made it possible to write medium-sized business applications with graphical user interfaces without much pain. Code reuse worked well in that environment, and it was easy to access a database. You could have the good programmers write a "button" and let the lesser programmers drag and drop the button into their app. This was a major driver in moving corporate America off the green-screen IBM mainframe terminals and onto Windows.
Programmers were pushing the "button" idea way beyond its intended uses. So Microsoft expanded it into COM, DCOM, and Active-X. It turned into a huge proprietary do-anything object system. But a lot of work gets done with that toolset, even though it's become ugly.
de Icaza has correctly identified the lack of a comparable middleware system as a serious problem in the UNIX world. Whether he can fix it remains to be seen. It's very hard to get this right. The past is littered with failed middleware environments: OpenDoc and NextStep come to mind.
A big problem is that if you let the object fanatics design the thing, it ends up too abstract and complex. If you let the UI designers design the thing, it ends up not powerful enough. CORBA and Prograph are at opposite ends of the spectrum here. (If you let the hackers design the thing, it ends up like Perl. Perl, remember, started as a tool for reading text logs. It's a special-purpose language pushed way beyond its design basis.) This requires really good engineering judgement.
For some insight on how to make design decisions here, read Weaving the Web [amazon.com], by Tim Berners-Lee (you know, the guy who invented HTML and the Web), page 182, where he discusses why HTML isn't a programming language like TeX. He says it better than I can, and I'm not going to repeat him here.
I hope de Icaza can pull it off. From reading his article, he has the basic good sense needed to get it right. Best of luck to that project.
library dependencies (Score:3)
This is exactly one of the reasons UNIX is in so much trouble -- even something simple like the concept of shared libraries (at least in practice) is a relatively new thing in much of the UNIX world. It's not very well understood, let alone welcomed.
People bitch and moan about having to deal with getting a whole bunch of libraries because of runtime dependencies. Deal. It's the cost of componentizing software, and it's not like there aren't tools that can manage the complexity for you (e.g. apt-get).
And, for those of you who don't think you need shared libraries, try replacing all the binaries on your system with statically linked versions and see how much disk space you have left...
There is also a good deal of management flexibility and efficiency that you gain through using higher-level component systems, as well. I know the Unix pipeline has been offered as a viable model, but it's not really complete enough.
Unless you extend the role of the filesystem abstraction as in Plan 9, the UNIX file/pipeline metaphor is simply not a viable component model in and of itself -- if it were, every application could be written as a shell script (which you can mostly do in Plan 9, btw, even if it would be a bit slow).
There's a point where you just have to stop managing all of the complexity yourself, and delgate some of it to software. The untyped data streams of the Unix pipeline (without the additional policy/flexibility imposed by Plan 9) don't sufficiently allow that.
Failing a Plan 9-esque level of abstraction, you're going to have to settle for a higher-level layer like Bonobo to really function in a modern environment.
Re:First make GNOME not suck (Score:5)
lynx -source go-gnome.com | sh
We take care of the library issues for you, and you can focus on compiling Galeon (which we plan on including on Helix GNOME as well in the near future).
Miguel.
What's this got to do with UNIX? (Score:3)
Or maybe I just don't try to use UNIX as a component-based system, and as such don't see it suck. Maybe I'm not fitting a square peg in a round hole (or vice versa). When I want object-ness, I do use BeOS. UNIX!=User-friendly object-mish-mash-component-SOAP-XML-Hype. UNIX is a way of thinking that's different than other paradigms, and because of this UNIX sucks? I hardly don't think so.
Re:Miguel is sadly mistaken (Score:3)
I was asked once at Usenix, once at OLS "How long have you been using Unix?". At OLS someone just assumed I was a newcomer that had used a Mac all its life, that I had no idea of what I was talking about, and that I would be better of clicking icons on my Mac.
I have been using Unix since the early 90s. My first contributions to free software was in 1992.
I was the main author of the GNU Midnight Commander, a file manager that was a clone of the DOS file manager called the Norton Commander.
Later, I started working with David Miller on the SPARC port of Linux: I worked on the kernel and on a bunch of device drivers that made the system usable. I also ported three libcs and did significant work on the various dynamic linkers used on the port (the libc4, the libc5 and worked partially on the GNU libc port).
Afterwards, I worked with Ingo and Gadi on the Linux software RAID-1/4/5 implementation. Ingo later perfected it to the beautiful levels you see now.
Later I joined the Linux/Indy team in which I worked on various tasks to bring up a complete system to Linux on the Indy. I abandoned the work when I began working on GNOME, three years ago.
Miguel
Re:Complexity isn't the only problem here (Score:3)
No one is forcing you to use GNOME or KDE or XFce, and some people genuinely like them.
Re:UNIX's "problems" are really flexibility (Score:3)
If you only write stuff for hackers how do you think Linux is going to succeed in the desktop market ? You can't just ignore your user's needs.
There has to be a standard way of doing things.
Re:TM'd title (Score:3)
I'm an investigator. I followed a trail there.
Q.Tell me what the trail was.
Re:Component systems and versioning (Score:3)
One of the real weaknesses of the MS way is that (as it has been explained to me), there is no way to extend a COM interface - any new functionality requires creating a completely new interface that exists alongside and is (usually) a superset of the old one. Of course, you must still support the old interface for backward compatibility, but this isn't always done. (This really makes some sense, since the alternative is code bloat, but it breaks things, especially if app vendors "update" a MS-supplied DLL.)
The DLL hell problem is quite serious, and has some significant and largely unknown side effects - here is one big reason why even W2K isn't up to enterprise duty: The DLL problem prevents running test and production versions of the same application simultaneously. Of course, this is something the Unix folks have handled forever simply by starting in another directory and/or tweaking the search path variables for executables and libraries. (For those of you MS folks that think it can be done, I have it on good authority (Microsoft's) that it cannnot be. It is possible to tie a particular DLL version to a particular app, but there is no way of ensuring that you will get the right DLL if another version of the same DLL has already been loaded into memory by another application (or another version of the same application.))
This sort of behaviour *MUST* be avoided at all costs!
As an aside, although I'm starting to be quite impressed with GNOME and it's rate of improvement (although it's an inexcusable resource pig), I still wonder how much farther we might be if this had all been done in Java, leveraging all those other components that are already built? (And yes I realize the freedom issues of a year or two ago. I also think they're almost totally fixed and/or irrelevant today - there are a lot of alternative implementations out there.)
It just pains me to see so much effort thrown at reinventing the wheel yet again, but without the benefit of portable binaries and the attendant abilty to automatically and dynamically define the client/server(s) split point(s). This ability will eventually make Java or something like it the winner, since you can only pull that trick off with binary code that runs wherever you decide to send it...
Miguel, if you read this, I'd be interested in your take on this latter point in particular. And keep up the good work, you may convert me yet...
UNIX was one of the first component-based systems (Score:3)
Just because something's based on a command line with independent processes running in separate address spaces, and isn't object oriented, doesn't mean that it's not a modular, component-based architecture.
Re:TM'd title (Score:3)
Basic typeing and arrow keys work as expected.
Then I use search a lot: C-s.
undo is shift-underscore.
replace is (OBVIOUSLY...) M-%
cut can be achieved by C-space at one and and C-w (wipe) at the other. Copy is the same but M-w. Paste (yank) is C-y. Any M-y's after C-y's paste things that used to be cut/copied, very neat as you never lose any text. C-k cuts the rest of the line.
And of course quit is C-x C-c
then there are some long commands I use a lot
M-x enters minibuffer fo command typing
line-number-mode shows line numbers
sgml-mode, cc-mode, c-mode, html-mode etc go into those appropriate modes so you can use:
font-lock-mode for syntax highlighting.
Obviously there's much more, but that's 99.9% of what I use. Can be learned in 15 mins, really. stick it to the side of your screen.
Also useful is the tutorial C-h t
First make GNOME not suck (Score:3)
If I want to use some little GNOME program (say, Galeon), what do I need to do?
Download the program.
Figure out which libraries are needed for the GNOME stuff.
Figure out which libraries are needed BY the GNOME stuff.
Locate and download all those libraries.
Find a place to put all those libraries.
Debug all my existing applications because I just upgraded all my libraries (can you say "DLL hell"?)
Occasionally: Answer "NO" to a program that wants to "associate files of type ABC with this program"
I'm all for making things easy to learn. I am NOT in favor of making them just like Microsoft.
--
Posix (Score:3)
Posix is not the generic term for UNIX because even NT is Posix complient (barely, but it is) and we all know that NT is not UNIX.
As someone already mentioned in this thread, the UNIX trademark was sold by AT&T after the anti-trust ruling, AT&T had some major restrictions on anything not related to long distance communications. AT&T sold it to Novell, who sold it to SCO. From what I have been told SCO gave that trademark to some non-profit standards orginization, or something along those lines.
UNIX is not just a trademark but a standardization. In order for a product to legitamitly called UNIX it must follow certain conventions.
A more generic term is *nix, which refers to UNIX like. It covers UNIX, Linux, Minix, and several others.
Component systems and versioning (Score:4)
Is the interface definition used to determine "compatability" of an object for a particular purpose? Can interfaces evolve? Can an object add functionality, but still be used by other, older objects for the older purposes? Must an evolving object conform to several interfaces (adding bloat), or can there be v2.0 of an interface, after the designer realizes there's a Better Way to do it?
These are hard problems, and ones I was not able to answer to my satisfaction. Evidinced by their software, it seems that M$ has not either. Do you really want to embed an editable spreadsheet in a document, and deal with the bloat and crashes that will occur? Or is there a Better Way?
Of course, I could probably answer all these questions by digging into the Bonobo and CORBA documentation, but stimulating discussion is good too.
--Bob
Policy and lack thereof (Score:3)
The core of Miguel's argument is that the Unix world is in chaos because the designers of Unix have failed to form and enforce policy down the years. A good point.
But let's look at the history of Unix here:
Now, Miguel, could you please tell me precisely how is one going to enforce policy on such a disparate user base, most of whom are going to react with instinctive loathing towards anybody attempting to throw their weight around, to say my thing is The Right Thing damnit, for whatever reason?
Unix has survived precisely because there is no hallowed policy handed down from above. It evolves. It changes to meet new needs. Those components of Unix that are shared, like glibc, have developed through consensus and bitter experience. If you want to develop in an enforced-policy environment, well, there's Windows NT or VMS or OS/390.
The Cluetrain has already left the station, Miguel. You on it or under it?
--
Cat Mara
Love me, I'm a liberal!
CORBA isn't the answer (Score:3)
But I think neither COM nor CORBA are the answer. COM and CORBA are both rather complex systems because they are trying to patch up deficiencies in the underlying languages, C and C++. In an environment that encourages reuse, you should be able to just serialize and send objects to other components without lots of error-prone declarations. Such systems exist, and have existed for decades. But you simply can't build them reliably on top of C/C++.
Ten years ago, Objective-C was a pragmatic and efficient answer to that problem. Objective-C is simpler than IDL and gives programmers more power. Today, the obvious answer would seem to be Java, although even it is still more complex than it probably ought to be.
While I appreciate the short term utility of Gnome, I think in the long term, the effect of the Gnome project (and KDE, for that matter) is going to be harmful. It continues to encourage people to develop in and for an environment that is fundamentally not well suited to building software components and getting a lot of code reuse.
If people want to do something relevant for end users in an industry-standard environment, I think they should contribute to Java-based desktop application efforts. The Gnome programmers are smart and capable: if even a fraction of the Gnome effort went into open source Java implementation (e.g., kaffe [kaffe.org]) and Java desktop apps (e.g., JFA [javalobby.org]), we'd soon have a good environment that would be much easier to extend with new components than a big C/CORBA system.
Components at install level (Score:3)
Miguel touches on the mess of configuring services. He proposes a solution for working with existing configuration files using a perl backend and GUI frontend. This is an admirable short term solution for a larger, significant problem.
The inherent problem is that standard unix
In the spirit of the changes proposed by Miguel, I propose that applications and otherwise all packages be components even in the way they live in the system. Let every package have an arbirary, unique directory, and let everything owned by a package live only in that directory. Let there be a common system component that exposes packages and their configuration on request. Let all packages find and expose other packages only through this component. Let the system package component internally record at most where to find other packages. Further configuration is stored in the package's own directory.
There are a number of advantages to this model:
1. First order installation becomes trivial. Just dump everything into a directory. The system package component will automatically find it.
2. Complete uninstall becomes trivial. Just blow away the package's directory.
3. Exposing a package's configuration is standardized, stable, and protected through the system package component.
4. "Custom" packages and their configuration is trivially persistent across reinstalling the operating system.
This is a problem that has been clumsily attacked by both RPM's and the MS Window's reigstry. Both tried to solve the problem by making prodigious use of massive amounts of internal data - data that is subject to unneccesary and unwanted management and corruption. With the proposed system package component, the small amount of internal data is easily reconstructed by scanning the file system. If you assert that packages access even their own configuration data through the system package component (much like the interface to a registry), then each package's configuration data can be stored in something standard and sane, like config.xml.
I code. If you want help, I'll give it.
Down with global data! Down with
- Cory
Speaking of things that suck... (Score:4)
Miguel de Icaza seems like an otherwise intelligent guy, so I have to assume that CORBA is forcing the use of reference counting here. If that's so, then CORBA sucks even worse than I thought.
um, one foot before the other, you know? (Score:5)
You need something like DCOM implemented first before you can even think of implementing something like
Re:Component systems and versioning (Score:3)
Re:Great Article... (Score:4)
Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Except that GNOME is going about this entirely the wrong way. They're writing a lot of useful stuff (the canvas, html components, etc.) except they can't figure out why somebody would want to use this stuff outside of GNOME. GTK+ could benefit from the standard inclusion of some of these things and it's likie fighting for a firstborn to move them out of GNOME into GTK+.
Example: In the previous article about Miguel speaking (sorry, no reference), one poster mentioned how he had gotten flamed for taking the GNOME html component and removing the GNOME dependencies. Clearly, an html component that everybody can use is a good thing. Requiring GNOME to use this html component is not a good thing.
Write the reusable software at the right level; don't GNOMEify everything in the name of "software reuse".
-Nathan
Scary! A Linux nerd bashing Unix! (Score:4)
Wow, it's always tough when a true Indian wanders off the reservation!
Well, he has a point. Unix should be the first OS to use modularized components with rampant code-reuse, not one of the last. Remember part of the Hacker Ethic: do not re-invent the wheel.
Imagine! Maybe Microsoft does do some things very well! (I know IE has much better support of CSS than Netscape does -- not to beat a dead horse, but Mozilla isn't looking all that great either on several fronts). Could it be that this modularity (even done as slipshod as it is on Microsoft OSes) is part of what encourages people to write software for Microsoft? Ease of development? (I'm not a True Programmer, so <TAKE type="salt" size="grain">
I wish the best for Helixcode -- just before you get carried away with making it "easy to use", try to get some UI experts in there to help design things. Just because it has a button doesn't mean it's easy to use. Where the button is placed is just as important as having the button.
Great Article... (Score:5)